Wprowadzenie do lekkiej metodyki zarz dzania projektami Scrum

Transkrypt

1 Wprowadzenie do lekkiej metodyki zarz dzania projektami Scrum Andrzej Skowron Wydziaª Matematyki i Informatyki Uniwersytet Šódzki Programowanie zespoªowe A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 1 z 49

2 Cel zaj Podziaª na 4-5 osobowe grupy. Realizowanie projektu metodyk Scrum. Wykorzystanie narz dzi do zarz dzania Scrumem. Wykorzystanie systemu kontroli wersji Git. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 2 z 49

3 Projekt a proces I Projekt Wiele denicji. Zorganizowane dziaªanie zmierzaj ce do osi gni cia zamierzonego celu. Problem przeznaczony do rozwi zania. Okre±lone w czasie dziaªanie podejmowane w celu osi gni cia konkretnego celu. Podstawowe cechy: Unikalny, niepowtarzalny, innowacyjny. Jest interdyscyplinarny. Ma zaªo»ony czas trwania. Ma cele. Potrzebuje zasobów. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 3 z 49

4 Projekt a proces II Proces Ukierunkowany na zmiany. Wi»e si z wysokim ryzykiem niepowodzenia. Wymaga du»ego zaanga»owania zespoªu kierowniczego i pracowników. Powtarzalny ci g czynno±ci, bez zaplanowanego ko«ca. Przykªadem mo»e by wyprodukowanie partii towaru na linii produkcyjnej. Podstawowe cechy: Realizuje znany przepis, rutynowy. Niewielkie zagro»enie pora»k. Nie ma zaªo»onego czasu trwania. Niewielkie zaanga»owanie zespoªu kierowniczego i pracowników. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 4 z 49

5 Co mo»e by projektem Zaprojektowanie, implementacja i wdro»enie projektu informatycznego. Kampania wyborcza, reklamowa. Prace naukowe. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 5 z 49

6 Dlaczego wiele projektów upada Okazuje si,»e blisko 20% projektów informatycznych ko«czy si pora»k, a okoªo 50% przekracza termin realizacji. Do najwa»niejszych przyczyn tego stanu zaliczmy: 1 Zªo»ono± projektu. 2 Nieodpowiednie metody pracy. 3 Nieodpowiednie narz dzia. Na punkt drugi skªadaj si m.in.: 1 zaªamanie komunikacji; 2 zªe planowanie; 3 sªaba kontrola jako±ci; 4 zªe zarz dzanie zasobami; 5 brak ±ledzenia post pu prac; 6 zªe zarz dzanie. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 6 z 49

7 Metodyka a metodologia Metodyka zarzadzania projektem Ustandaryzowane podej±cie do wytwarzania projektów informatycznych. Metodologia Metodologia jest to nauka o metodach bada«naukowych, ich skuteczno±ci i warto±ci poznawczej. Metodyka koncentruje si na poszukiwaniu odpowiedzi na pytanie: Jak to nale»y robi? Natomiast zadaniem metodologii jest odpowied¹ na pytanie: Co nale»y robi? Generalnie metodyka bardziej kieruje si ku praktyce wykonawczej. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 7 z 49

8 Wybrane metodyki zarz dzania projektami Klasyczne (ci»kie): PMI od Project Management Institute; PRINCE/PRINCE2 od Projects In a Controlled Environment - Projekty w sterowanym ±rodowisku. Lekkie, zwinne (Agile): Scrum; Programowanie ekstremalne od extreme Programming, XP; Feature Driven Development (FDD). A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 8 z 49

9 Manifest Agile I W 2001 roku 17 programistów utworzyªo tzw. Manifest Agile (ang. Agile Manifesto). Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych do±wiadcze«zacz li±my przedkªada : Ludzi i ich wzajemne interakcje (wspóªdziaªanie) ponad procedury i narz dzia. Dziaªaj ce oprogramowanie nad wyczerpuj c dokumentacj. Wspóªprac z klientem nad negocjacje umów. Reagowanie na zmiany nad realizowanie planu. Oznacza to, ze wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak bardziej cenimy to co wymieniono po lewej. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 9 z 49

10 Manifest Agile II Ta tre± znajduje si pod adresem i mo»na si pod ni podpisa. Tam równie» znajdziemy Zasady kryj ce si za Manifestem Zwinnego Wytwarzania Oprogramowania A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 10 z 49

11 Zasady programowania zwinnego I Zasady kryj ce si za Manifestem Zwinnego Wytwarzania Oprogramowania: Najwa»niejsze dla nas jest zadowolenie Klienta wynikaj ce z wcze±nie rozpocz tego i ci gªego dostarczania warto±ciowego oprogramowania. B d¹ otwarty na zmieniaj ce si wymagania nawet na zaawansowanym etapie projektu. Zwinne procesy wykorzystuj zmiany dla uzyskania przewagi konkurencyjnej Klienta. Cz sto dostarczaj dziaªaj ce oprogramowanie od kilku tygodni do paru miesi cy, im krócej tym lepiej z preferencj krótszych terminów. Wspóªpraca mi dzy lud¹mi biznesu i programistami musi odbywa si codziennie w trakcie trwania projektu. Twórz projekty wokóª zmotywowanych osób. Daj im ±rodowisko i wsparcie, którego potrzebuj i ufaj im, ze wykonaj swoj prac. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 11 z 49

12 Zasady programowania zwinnego II Najwydajniejszym i najskuteczniejszym sposobem przekazywania informacji do i ramach zespoªu jest rozmowa twarz w twarz Podstawow i najwa»niejsz miar post pu jest dziaªaj ce oprogramowanie. Zwinne procesy tworz ±rodowisko do równomiernego rozwijania oprogramowania. Równomierne tempo powinno by nieustannie utrzymywane poprzez sponsorów, programistów oraz u»ytkowników. Poprzez ci gªe skupienie na technicznej doskonaªo±ci i dobremu zaprojektowaniu oprogramowania zwi ksza zwinno±. Prostota sztuka maksymalizacji pracy niewykonanej jest zasadnicza. Najlepsze architektury, wymagania i projekty powstaj w samoorganizuj cych si zespoªach. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 12 z 49

13 Zasady programowania zwinnego III W regularnych odst pach czasu zespóª zastanawia si jak poprawi swoj efektywno±, dostosowuje lub zmienia swoje zachowanie. W skrócie: 1 Priorytetem jest osi gni cie zadowolenia klienta poprzez wczesne i nieprzerwane dostarczanie mu oprogramowania wysokiej jako±ci. 2 Podstawow miar post pu jest dziaªaj ce oprogramowanie. 3 Zmiany w specykacji nie maja destrukcyjnego wpªywu na proces wytwarzania oprogramowania. 4 Nale»y dostarcza dziaªaj ce wydania oprogramowania cz sto, raz na kilka tygodni do kilku miesi cy, z tendencj do krótszych okresów. 5 Klient i programi±ci musz pracowa razem codziennie. 6 Bezpo±redni kontakt, jako najlepsza forma komunikacji w zespole i poza nim. 7 Klient i programi±ci powinni móc ±ledzi post p stale i bez ogranicze«. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 13 z 49

14 Zasady programowania zwinnego IV 8 Nale»y dostarczy zespoªowi ±rodowisko pracy i wszelkie wsparcie oraz zaufa,»e wykona swoj prac. 9 Samozarz dzalno± zespoªów. 10 W regularnych odst pach czasu zespóª winien rozwa»a, jak zwi kszy swoj wydajno± i zgodnie z tym zmienia swoje metody pracy. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 14 z 49

15 Korzy±ci metodyk typu agile Klient jest zadowolony, gdy» oprogramowanie speªnia jego oczekiwania, zostaªo dostarczone w planowanym czasie, kosztowaªo tyle ile planowano. Zespóª jest zadowolony, poniewa»: ma satysfakcj z wykonanej pracy, jest dobrze zmotywowany. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 15 z 49

16 Scrum - wst p I Scrum (ang. mªyn) jest metod usprawniania procesów wytwarzania zªo»onych produktów. Ogólne zaªo»enia metodyki zostaªy zaprezentowane przez Hirotaka Takeuchi i Ikujiro Nonaka w artykule The New Product Development Game, opublikowanym w Harvard Business Review w styczniu 1986 roku. Peªna metodyka oraz denicja zostaªa sformalizowana przez Kena Schwabera w 1986 roku. Jest obecny w Polsce, wiele ró»nej wielko±ci rm go u»ywa. To najbardziej popularna ze wszystkich zwinnych metod, okoªo 58%. W ramach tej metodyki oprogramowanie powstaje w kolejnych iteracjach metod przyrostow. Scrum pozwala klientowi i u»ytkownikom uzyska caªkowit kontrol nad kierunkiem i zakresem prac projektu. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 16 z 49

17 Scrum - wst p II Scrum dobrze pasuje do maªych zespoªów (od 5 do 9 programistów). W obr b Scruma wchodz : Zespoªy Scrumowe (Scrum Teams) oraz zwi zane z nimi role, zdarzenia, artefakty i reguªy post powania. Wszystkie te elementy sªu» konkretnym celom i wszystkie s niezb dne do osi gni cia sukcesu w stosowaniu Scruma. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 17 z 49

18 Scrum najwa»niejsze poj cia Rejestr Produktu (ang. Product Backlog) jest list prac, które nale»y wykona. Sprint - o pojedyncza iteracja, zespóª ustala czas jego trwania od 2 do 4 tyg. Rejestr Sprintu - (ang. Sprint Backlog) lista prac wybranych z Rejestr Produktu przez Wªa±ciciela Produktu do realizacji w danym Sprincie. Cel sprintu okre±la biznesowe uzasadnienie dla tego konkretnego sprintu. Opowie±ci U»ytkownika (ang. User Stories) - wymagania u»ytkownika w stosunku do produktu s najcz ±ciej zapisane w postaci opowie±ci u»ytkownika, cechuje je j zyk naturalny, brak technicznych sformuªowa«. Wchodz w skªad Rejestru Produktu. Np. Jako u»ytkownik musz mie mo»liwo± wprowadzania oferty sprzeda»y. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 18 z 49

19 Zespóª Scrumowy I W skªad Zespoªu Scrumowego wchodz : Wªa±ciciel Produktu (Product Owner), Zespóª Deweloperski (Development Team), Scrum Master. Oto cechy, które musi posiada ka»dy zespóª Scrumowy. Zespoªy Scrumowe s samoorganizuj ce si i wielofunkcyjne (interdyscyplinarne). Samoorganizuj ce si zespoªy samodzielnie decyduj, w jaki sposób najlepiej wykonywa prac, nie s przy tym w»aden sposób kierowane przez osoby spoza zespoªu. Zespoªy wielofunkcyjne posiadaj wszelkie kompetencje niezb dne do uko«czenia pracy, nie b d c zale»nymi od osób niewchodz cych w skªad zespoªu. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 19 z 49

20 Zespóª Scrumowy II Model zespoªu zaproponowany w Scrumie zostaª zaprojektowany tak, aby zoptymalizowa elastyczno±, kreatywno± i produktywno±. Zespoªy Scrumowe dostarczaj produkty iteracyjnie i przyrostowo, zwi kszaj c szanse na wczesne uzyskanie informacji zwrotnej. Przyrostowe dostarczanie Uko«czonego produktu zapewnia,»e jego potencjalnie u»yteczna i funkcjonalna wersja jest zawsze dost pna. Omówimy role w zespole: Wªa±ciciel Produktu ang. Product Owner jest odpowiedzialny za maksymalizacj warto±ci produktu i pracy Zespoªu Deweloperskiego. Wªa±ciciel Produktu jest jedyn osob zarz dzaj c Rejestrem Produktu (Product Backlog). Poj cie zarz dzania Rejestrem Produktu mie±ci w sobie: 1 Jasne artykuªowanie elementów Rejestru Produktu, 2 Okre±lanie kolejno±ci elementów Rejestru Produktu w sposób zapewniaj cy osi ganie zaªo»onych celów i misji, 3 Zapewnianie warto±ci pracy wykonywanej przez Zespóª Deweloperski, A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 20 z 49

21 Zespóª Scrumowy III 4 Zapewnianie,»e Rejestr Produktu jest dost pny, przejrzysty oraz jasny dla wszystkich, a tak»e,»e dobrze opisuje to, czym Zespóª Scrumowy b dzie si zajmowaª w dalszej kolejno±ci oraz, 5 Zapewnianie,»e Zespóª Deweloperski rozumie elementy Rejestru Produktu w wymaganym stopniu. Wªa±ciciel Produktu mo»e wykonywa powy»sze zadania samodzielnie lub zleca je Zespoªowi Deweloperskiemu, jednak to Wªa±ciciel Produktu pozostaje za nie odpowiedzialny. Zespóª Deweloperski zªo»ony jest z profesjonalistów, których zadaniem jest dostarczenie, na zako«czenie ka»dego Sprintu, gotowego do wydania Przyrostu (Increment) produktu. Tylko czªonkowie Zespoªu Deweloperskiego s zaanga»owani w wytwarzanie Przyrostu. Zespoªy Deweloperskie s uprawnione przez organizacj do samodzielnego organizowania i zarz dzania swoj wªasn prac. Synergia, b d ca rezultatem takiego post powania, zwi ksza ogóln wydajno± i efektywno± Zespoªu Deweloperskiego. Charakterystyka Zespoªów Deweloperskich jest nast puj ca: A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 21 z 49

22 Zespóª Scrumowy IV S samoorganizuj ce si. Nikt (nawet Scrum Master) nie mo»e mówi Zespoªowi Deweloperskiemu, jak nale»y przeksztaªca elementy Rejestru Produktu w Przyrosty gotowej do wydania funkcjonalno±ci, Zespoªy Deweloperskie s wielofunkcyjne, w swoim skªadzie posiadaj wszystkie umiej tno±ci niezb dne do wytworzenia Przyrostu, Scrum nie przewiduje tytuªów innych ni» Deweloper dla czªonków Zespoªu Deweloperskiego. Reguªa ta obowi zuje bez wzgl du na charakter pracy wykonywanej przez dan osob i nie ma od niej wyj tków, Mimo, i» pojedynczy czªonkowie Zespoªu Deweloperskiego mog posiada wyspecjalizowane umiej tno±ci oraz mog skupia si na konkretnych dziedzinach, odpowiedzialno± za wykonywan prac ponosi caªy Zespóª Deweloperski oraz, Zespoªy Deweloperskie nie skªadaj si z podzespoªów przeznaczonych do wykonywania konkretnych rodzajów zada«, jak na przykªad testowanie czy analiza biznesowa. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 22 z 49

23 Zespóª Scrumowy V Scrum Master jest odpowiedzialny za to, by Scrum byª rozumiany i stosowany. Scrum Masterzy dokonuj tego poprzez upewnianie si,»e Zespóª Scrumowy stosuje si do zaªo»e«teorii Scruma, jego praktyk i reguª post powania. Scrum Mastera mo»na okre±li mianem przywódcy sªu»ebnego w stosunku do Zespoªu Scrumowego. Scrum Master pomaga tak»e osobom spoza Zespoªu Scrumowego zrozumie, które z ich interakcji z Zespoªem Scrumowym s pomocne, a które nie. Scrum Master pomaga zmienia te zachowania celem zmaksymalizowania warto±ci wytwarzanej przez Zespóª Scrumowy. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 23 z 49

24 Zdarzenia w Scrumie - Sprint Sercem Scruma jest Sprint ograniczenie czasowe trwaj ce jeden miesi c lub krócej, podczas którego wytwarzany jest Przyrost Uko«czonej, u»ywalnej i potencjalnie gotowej do wydania funkcjonalno±ci. Sprinty maj staª dªugo± przez caªy okres trwania prac. Nowy Sprint rozpoczyna si bezpo±rednio po podsumowaniu poprzedniego. Sprinty zawieraj i skªadaj si z Planowania Sprintu, Codziennych Scrumów, wytwarzania, Przegl du Sprintu i Retrospektywy Sprintu. Podczas Sprintu: Niedozwolone s zmiany, które wpªyn na Cel Sprintu, Skªad Zespoªu Deweloperskiego i jego cel jako±ciowy pozostaj niezmienne, Zakres prac mo»e by wyja±niany i renegocjowany pomi dzy Wªa±cicielem Produktu oraz Zespoªem Deweloperskim zawsze, gdy odkrywane s nowe aspekty pracy. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 24 z 49

25 Zdarzenia w Scrumie - Planowanie Sprintu I Planowanie Sprintu ang. Sprint Planning Meeting Praca wykonywana w trakcie Sprintu jest planowana podczas Planowania Sprintu. Plan ten powstaje w wyniku wspólnej pracy caªego Zespoªu Scrumowego. Planowanie Sprintu jest spotkaniem ograniczonym do o±miu godzin dla miesi cznego Sprintu. Dla krótszych Sprintów jest ono proporcjonalnie krótsze. Na przykªad planowanie dwutygodniowego Sprintu trwa maksymalnie cztery godziny. Planowanie Sprintu skªada si z dwóch cz ±ci. Ka»da z nich jest ograniczona do poªowy czasu trwania caªego spotkania. Obie cz ±ci Planowania Sprintu daj odpowied¹ na nast puj ce pytania: Co zostanie dostarczone w Przyro±cie b d cym rezultatem najbli»szego Sprintu? Jak praca, prowadz ca do uko«czenia Przyrostu, zostanie wykonana? A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 25 z 49

26 Zdarzenia w Scrumie - Planowanie Sprintu II Cz ± pierwsza - co b dzie zrobione w tym Sprincie, obejmuje: Prognozowanie zakresu funkcjonalno±ci, który zostanie zrealizowany w trakcie najbli»szego Sprintu. Wªa±ciciel Produktu prezentuje Zespoªowi Deweloperskiemu uporz dkowany Rejestr Produktu, nast pnie caªy Zespóª Scrumowy wspólnie pracuje nad zrozumieniem pracy przewidzianej na najbli»szy Sprint. Wej±ciem do tego spotkania jest Rejestr Produktu, ostatni Przyrost, przewidywana pojemno± Zespoªu Deweloperskiego w Sprincie i ostatnie odczyty wydajno±ci tego zespoªu. Decyzja o liczbie wybranych elementów Rejestru Produktu nale»y tylko i wyª cznie do Zespoªu Deweloperskiego. Tylko on mo»e oceni, ile jest w stanie osi gn w nadchodz cym Sprincie. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 26 z 49

27 Zdarzenia w Scrumie - Planowanie Sprintu III Po oszacowaniu, ile elementów Rejestru Produktu Zespóª Deweloperski b dzie w stanie dostarczy, caªy Zespóª Scrumowy ustala Cel Sprintu. Jest to cel, który zostanie osi gni ty w ramach Sprintu poprzez implementacj wybranych elementów Rejestru Produktu. Uzasadnia, w jakim celu Zespóª Deweloperski buduje Przyrost. Cz ± druga - jak wybrana praca b dzie wykonana, obejmuje: Po wybraniu zakresu pracy do Sprintu, Zespóª Deweloperski ustala, jak zamieni t funkcjonalno± w Uko«czony Przyrost w trakcie trwania Sprintu. Wybrane elementy Rejestru Produktu wraz z planem ich wykonania nazywane s Rejestrem Sprintu. Zespóª Deweloperski zwykle rozpoczyna od stworzenia projektu systemu i planu prac niezb dnych do przetworzenia elementów Rejestru Produktu w dziaªaj cy Przyrost produktu. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 27 z 49

28 Zdarzenia w Scrumie - Planowanie Sprintu IV Przed ko«cem tego spotkania, praca przewidziana na pierwsze dni Sprintu jest dekomponowana na jednostki wielko±ci jednego dnia roboczego lub mniejsze. Zespóª Deweloperski samodzielnie organizuje si tak, aby móc podj si pracy nad Rejestrem Sprintu, zarówno podczas Planowania, jak i w ci gu caªego Sprintu. Wªa±ciciel Produktu mo»e by obecny podczas drugiej cz ±ci Planowania Sprintu, aby wyja±nia wybrane elementy Rejestru Produktu lub pomaga osi ga kompromisy. Je±li Zespóª Deweloperski zadecyduje,»e ma za du»o lub za maªo pracy, mo»e renegocjowa elementy Rejestru Sprintu z Wªa±cicielem Produktu. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 28 z 49

29 Zdarzenia w Scrumie - Planowanie Sprintu V Zespóª Deweloperski mo»e tak»e zaprosi na to spotkanie inne osoby, aby wsparªy Zespóª wiedz techniczn lub domenow. Zanim Planowanie Sprintu dobiegnie ko«ca, Zespóª Deweloperski powinien móc wytªumaczy Wªa±cicielowi Produktu i Scrum Masterowi, w jaki sposób ma zamiar pracowa, organizuj c si samodzielnie, by osi gn Cel Sprintu i wytworzy oczekiwany Przyrost. Cel Sprintu Cel Sprintu istnieje, aby da Zespoªowi Deweloperskiemu pewn swobod co do sposobu, w jaki dana funkcjonalno± zostanie zaimplementowana w najbli»szym Sprincie. W trakcie prac Zespóª Deweloperski pami ta o Celu Sprintu. Aby go osi gn, wprowadza nowe funkcjonalno±ci i technologie. Je±li charakter prac okazuje si by inny ni» oczekiwano, Zespóª Deweloperski wspóªpracuje z Wªa±cicielem Produktu w trakcie Sprintu, aby renegocjowa zakres Rejestru Sprintu. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 29 z 49

30 Zdarzenia w Scrumie - Codzienny scrum (Daily Scrum) I Codzienny Scrum jest spotkaniem dla Zespoªu Deweloperskiego, ograniczonym czasowo do pi tnastu minut, podczas którego bie» ce zadania s synchronizowane i powstaje plan dziaªania na najbli»sze 24 godziny. Jest to osi gane poprzez inspekcj prac, które zostaªy wykonane od ostatniego Codziennego Scruma i prognozowaniu prac, które mog zosta wykonane przed kolejnym spotkaniem. Aby zredukowa zªo»ono± Codzienny Scrum ma wyznaczone staªe miejsce i czas. Podczas tego spotkania ka»dy z czªonków Zespoªu Deweloperskiego wyja±nia: 1 Co zostaªo wykonane od ostatniego spotkania? 2 Co zostanie wykonane przed kolejnym spotkaniem? 3 Jakie przeszkody stoj na drodze? A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 30 z 49

31 Zdarzenia w Scrumie - Codzienny scrum (Daily Scrum) II Scrum Master musi zagwarantowa,»e Zespóª Deweloperski spotyka si w ramach Codziennego Scruma, jednak to Zespóª Deweloperski jest odpowiedzialny za przeprowadzenie samego spotkania. Scrum Master egzekwuje zasad,»e tylko Zespóª Deweloperski bierze udziaª w Codziennym Scrumie. Spotkanie to nie jest spotkaniem raportowym (statusowym) i przeznaczone jest dla osób, które bior aktywny udziaª w przeksztaªcaniu elementów Rejestru Produktu w Przyrost. Codzienne Scrumy poprawiaj komunikacj, eliminuj dodatkowe spotkania, identykuj i usuwaj przeszkody, sprzyjaj szybkiemu podejmowaniu decyzji i podnosz poziom wiedzy Zespoªu Deweloperskiego na temat przebiegu projektu. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 31 z 49

32 Zdarzenia w Scrumie - Przegl d Sprintu I Przegl d Sprintu ang. Sprint Review Meeting Podczas Przegl du Sprintu Zespóª Scrumowy i interesariusze wspólnie omawiaj to, co zostaªo uko«czone w Sprincie. Na tej podstawie oraz na podstawie zmian wprowadzonych do Rejestru Produktu w trakcie Sprintu, uczestnicy spotkania wspólnie pracuj nad tym, co mogªoby by wykonane w nast pnej kolejno±ci. Jest to nieformalne spotkanie, a prezentacja Przyrostu ma na celu uzyskanie informacji zwrotnej i pobudzenie wspóªpracy. Przegl d Sprintu jest maksymalnie czterogodzinnym spotkaniem dla miesi cznego Sprintu i proporcjonalnie krótszym dla krótszych Sprintów. Na przykªad dwugodzinnym dla dwutygodniowych Sprintów. Przegl d Sprintu obejmuje nast puj ce punkty: 1 Wªa±ciciel Produktu stwierdza, które funkcjonalno±ci zostaªy Uko«czone, a które nie, A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 32 z 49

33 Zdarzenia w Scrumie - Przegl d Sprintu II 2 Zespóª Deweloperski omawia, co poszªo dobrze w trakcie Sprintu, jakie napotkano problemy, oraz jak te problemy rozwi zano, 3 Zespóª Deweloperski prezentuje Uko«czon prac i odpowiada na pytania dotycz ce Przyrostu, 4 Wªa±ciciel Produktu omawia Rejestr Produktu w aktualnej jego postaci. Na tej podstawie przewiduje termin zako«czenia prac bior c pod uwag dotychczasowe post py i tempo prac, 5 Caªa grupa wspólnie omawia kolejne kroki. W ten sposób Przegl d Sprintu dostarcza warto±ciowego wkªadu w nast puj ce po nim kolejne Planowania Sprintu. Wynikiem Przegl du Sprintu jest uaktualniona wersja Rejestru Produktu, która deniuje najbardziej prawdopodobne elementy dla najbli»szego Sprintu. Caªy Rejestr Produktu mo»e tak»e zosta zmieniony tak, aby jak najlepiej wykorzysta otwieraj ce si mo»liwo±ci. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 33 z 49

34 Zdarzenia w Scrumie - Retrospektywa Sprintu I Retrospektywa Sprintu ang. Sprint Retrospective Retrospektywa Sprintu jest okazj dla Zespoªu Scrumowego do przeprowadzenia inspekcji swoich dziaªa«i opracowania planu usprawnie«, który zostanie wcielony w»ycie w najbli»szym Sprincie. Retrospektywa Sprintu przeprowadzana jest po Przegl dzie, a przed kolejnym Planowaniem Sprintu. Spotkanie to trwa nie dªu»ej ni» trzy godziny dla Sprintów miesi cznej dªugo±ci. Retrospektywa Sprintu ma na celu: Sprawdzenie, co dziaªo si w ostatnim Sprincie, bior c pod uwag ludzi, zale»no±ci, procesy i narz dzia, Zidentykowanie i uporz dkowanie istotnych elementów, które sprawdziªy si w dziaªaniu oraz tych, które kwalikuj si do poprawy oraz, A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 34 z 49

35 Zdarzenia w Scrumie - Retrospektywa Sprintu II Stworzenie planu wprowadzania w»ycie usprawnie«sposobu wykonywania pracy przez Zespóª Scrumowy. Scrum Master zach ca czªonków Zespoªu Scrumowego do usprawniania, w ramach Scruma, procesu i praktyk wytwórczych tak, aby w kolejnym Sprincie uczyni wykonywan prac bardziej efektywn i daj c wi cej satysfakcji. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 35 z 49

36 Artefakty Scruma I Rejestr Produktu Rejestr Produktu to uporz dkowana lista wszystkiego, co mo»e by potrzebne w produkcie oraz jedyne ¹ródªo wymaganych zmian, które maj by do produktu wprowadzone. Odpowiedzialnym za Rejestr Produktu, w tym jego zawarto±, dost pno± i uporz dkowanie, jest Wªa±ciciel Produktu. Rejestr Produktu nigdy nie jest kompletny. Jego wczesna wersja jedynie nakre±la pocz tkowo znane i najlepiej zrozumiane wymagania. Rejestr Produktu ewoluuje wraz z produktem i ±rodowiskiem, w którym produkt ten b dzie u»ywany. Rejestr Produktu istnieje tak dªugo, jak istnieje produkt. Elementy Rejestru Produktu posiadaj nast puj ce atrybuty: opis, kolejno± i oszacowanie (estymacj ). A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 36 z 49

37 Artefakty Scruma II Rejestr Produktu jest cz sto uporz dkowany wedªug warto±ci, ryzyka, priorytetów lub zapotrzebowania. Elementy na najwy»szych pozycjach prowadz do najbli»szych prac wytwórczych. Rejestr Sprintu Rejestr Sprintu jest to zbiór elementów Rejestru Produktu wybranych do Sprintu rozszerzony o plan dostarczenia Przyrostu produktu i realizacji Celu Sprintu. Rejestr Sprintu to prognoza czyniona przez Zespóª Deweloperski odno±nie tego, jakie funkcjonalno±ci znajd si w kolejnym Przyro±cie i jak prac nale»y wykona, aby te funkcjonalno±ci dostarczy. Rejestr Sprintu uwidacznia caª prac, jak Zespóª Deweloperski uznaje za niezb dn do osi gni cia Celu Sprintu. Rejestr Sprintu to plan wystarczaj co szczegóªowy, by post py prac byªy zrozumiaªe podczas Codziennego Scruma. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 37 z 49

38 Artefakty Scruma III Zespóª Deweloperski modykuje Rejestr Sprintu w czasie trwania caªego Sprintu. Je±li pojawia si potrzeba wykonania dodatkowej pracy, Zespóª Deweloperski dodaje j do Rejestru Sprintu. W miar jak praca jest wykonywana albo ko«czona, aktualizowane jest oszacowanie pozostaªej do wykonania pracy. Jedynie Zespóª Deweloperski mo»e zmienia swój Rejestr Sprintu w trakcie Sprintu. Rejestr Sprintu jest dobrze widocznym, tworzonym w czasie rzeczywistym obrazem pracy, jak Zespóª Deweloperski planuje wykona w trakcie Sprintu i nale»y tylko i wyª cznie do Zespoªu Deweloperskiego. Przyrost Przyrost jest sum wszystkich elementów Rejestru Produktu zako«czonych podczas Sprintu i wszystkich Sprintów poprzednich. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 38 z 49

39 Artefakty Scruma IV Na koniec Sprintu nowy Przyrost musi by Uko«czony, co oznacza,»e musi on by u»ywalny i zgodny z Denicj Uko«czenia tego Zespoªu Scrumowego. Wykres spalania ang. burndown chart Na koniec ka»dego dnia pracy, ka»dy czªonek zespoªu aktualizuje wykres malej cy (ang. burndown chart) przedstawiaj cy ilo± pracy pozostaªej do wykonania w Sprincie. Ka»dy czªonek zespoªu dokonuje aktualizacji wyª cznie w zakresie zada«które wykonywaª. Dzi ki temu wykresowi ka»dy mo»e ªatwo zobaczy, czy sprint idzie pomy±lnie, czy te» wyst piªy jakie± zdarzenia wymagaj ce korekty planów. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 39 z 49

40 Scrum w praktyce Rysunek: Scrum A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 40 z 49

41 Tworzenie Rejestru produktu I Co prawda za Rejestr Produktu odpowiada Wªa±ciciel produktu, ale w praktyce caªy zespóª jest zaanga»owany w jego tworzenie. Opiera si on na opowie±ciach u»ytkownika. Ich pisanie nie jest ªatwe, ale Mike Cohn zaproponowaª nast puj cy szablon ich pisania: Jako rola/osoba chc /potrzebuj funkcji/rzeczy, z powodu... Np. Jako programista potrzebuj kawy, aby nie usn. Wedªug Billa Wake dobre opowie±ci u»ytkownika maj nast puj ce cechy: s od siebie niezale»ne, s warto±ciowe dla klienta, da si oznaczy ich wag i pracochªonno±, s raczej maªe. Na pocz tku rejestr musi zawiera wystarczaj c list zada«na pierwszy sprint. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 41 z 49

42 Tworzenie Rejestru produktu II Jego wykonanie powinno zaj okoªo 1 dnia (bez ustalenia kolejno±ci i rozmiaru zada«). Nast pnie rejestr musi by posortowany wedªug warto±ci biznesowej, jednym ze sposobów, aby tego dokona jest satysfakcja klienta z realizacji zada«. Nie wszyscy mog robi wszystko. Trzeba zidentykowa role (rodzaje u»ytkowników), stworzy dla ka»dej z nich odr bne zestawy opowie±ci. Ustalamy z klientem co kto mo»e, decydujemy kto jest wa»niejszy i ukªadamy w tej kolejno±ci w rejestrze. Jakie operacje u»ytkownicy wykonuj cz sto a jakie sporadycznie? Ukªadamy opowie±ci w rejestrze od najcz ±ciej do najrzadziej wykorzystywanych. Ustalamy jakie dane s gromadzone, przetwarzane, przesyªane. Czy mo»na ograniczy ich ilo± /typ/zakres/rozmiar? Czy zamiast skomplikowanych formatów danych mo»emy u»y pliku tekstowego? A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 42 z 49

43 Tworzenie Rejestru produktu III Ustalamy sposób komunikacji z systemem. Czy zamiast rozbudowanego GUI mo»emy u»y konsoli, a? W jaki sposób komunikujemy si ze sprz tem (wprowadzanie i wyprowadzanie danych)? W jaki sposób komponenty komunikuj si ze sob? Co mo»na upro±ci, pomin? Jakie operacje musimy przeprowadzi a jakie kroki mo»emy opu±ci? Jakie dane, w jakich okoliczno±ciach musz bezwzgl dnie podlega walidacji? Do ustalania kolejno±ci u»ywamy punktów opowie±ci (ang. story points), wi ksze warto±ci s dla du»ych zada«. Rejestr mo»na pó¹niej poprawi i zmieni kolejno± zada«. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 43 z 49

44 Planowanie Sprintu Pierwsza cz ± : Scrum Master bierze pierwsz histori z rejestru i pyta zespóª: czy zdoªamy to zrobi w czasie sprintu? Zespóª dyskutuje wymagania tej historii. Pytanie to jest kontynuowane do momentu, gdy zespóª nie zgodzi si na wi ksz liczb zada«. Druga cz ± Analizowane s kolejne wybrane historie. Dyskusja zespoªu deweloperskiego nad wybranymi zadaniami: Jakie interfejsy musz by napisane? Jaka architektura musi by stworzona? Jakie komponenty musz by stworzone/poprawione? Jak wiele czasu to zajmie? Zespóª rozkªada wybrane pozycje rejestru produktu na rejestr sprintu. Cz sto u»ywana jest do tego tablica. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 44 z 49

45 Bibliograa Do Better Scrum, The Scrum Primer, A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 45 z 49

46 Jakie narz dzia b d wykorzystane? I Do zarz dzania projektem wykorzystywa b dziemy: Acunote - Jest to proste narz dzie oparte na stronie WWW do zwinnego zarz dzania projektami. Inne narz dzia WWW tego typu to: S te» dost pne narz dzia desktopowe do Scruma: i A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 46 z 49

47 Jakie narz dzia b d wykorzystane? II Do zarz dzania ¹ródªami wykorzystamy system Git oraz serwis GitHub: ewentualnie nakªadk GUI Je±li chodzi o ±rodowisko deweloperskie (IDE), to mo»e by dowolne. Visual Studio, Eclipse, Netbeans, Komodo, Intellij Idea. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 47 z 49

48 Jakie narz dzia b d wykorzystane? III Pami tamy o: standardach kodowania, wybieramy standard j zyka PHP PSR2 i narz dzie do jego testowania PHP_CodeSnier. odpowiednim komentowaniu kodu, które posªu»y do automatycznego stworzenia dokumentacji za pomoc phpdocumentor. A. Skowron (WMiI UŠ) Multimedia Wprowadzenie 48 z 49