Oskar Dudycz

Pragmatycznie o programowaniu

Scrum i Team Foundation Server cz.1 - wprowadzenie do Scrum

2011-11-09 oskar dudyczAgile

cover

1. Wst─Öp

W kilku najbli┼╝szych postach postaram si─Ö przybli┼╝y─ç ide─Ö zarz─ůdzania projektem w metodyce Scrum przy pomocy Team Foundation Server (TFS). W tym po┼Ťcie opisz─Ö zasady i cechy jakimi charakteryzuje si─Ö SCRUM. W kolejnych przedstawi─Ö jak TFS mo┼╝e nam pom├│c w prowadzeniu projektu w tej metodyce. Poniewa┼╝, mimo posiadanego do┼Ťwiadczenia w niej nie czuj─Ö si─Ö ekspertem b─Öd─Ö bardzo rad z ka┼╝dego, nawet najbardziej krytycznego komentarza, kt├│ry pozwoli udoskonali─ç mi te wpisy.

2. Troch─Ö historii

Pierwsze systemy komputerowe by┼éy zwykle tworzone dla organizacji rz─ůdowych, wojskowych lub du┼╝ych korporacji. Wszystkie one mia┼éy zwykle ┼Ťci┼Ťle okre┼Ťlone normy, przepisy, kt├│re mia┼éy cechowa─ç tworzone systemy. Dzi─Öki temu mo┼╝na by┼éo sobie pozwoli─ç na to, ┼╝eby przed powstaniem systemu przeprowadzi─ç d┼éug─ů i kompleksow─ů analiz─Ö biznesow─ů, architektoniczn─ů z tonami dokumentacji i dopiero po uko┼äczeniu tego etapu wzi─ů─ç si─Ö do prac programistycznych, a na samym ko┼äcu testerskich. Cykl ┼╝ycia tych projekt├│w zwykle opiera┼é si─Ö na modelu kaskadowym lub modelu spiralnym. Popularno┼Ť─ç zdoby┼éy takie metodyki jak PRINCE2 lub RUP. Wraz z rozwojem komputer├│w osobistym oraz popularyzacj─ů Internetu na prze┼éomie XX i XXI wieku okaza┼éo si─Ö, ┼╝e systemy informatyczne przesta┼éy by─ç domen─ů du┼╝ych firm i organizacji ÔÇô r├│wnie┼╝ ma┼ée i ┼Ťrednie przedsi─Öbiorstwa zacz─Ö┼éy ich potrzebowa─ç.

Okaza┼éo si─Ö, ┼╝e metody prowadzenia projekt├│w dla du┼╝ych przedsi─Öbiorstw nie koniecznie s─ů dobre dla ma┼éych. D┼éugotrwa┼éy proces analizy, bez ┼╝adnych widocznych efekt├│w w postaci gotowych fragment├│w by┼é nie do zaakceptowania dla firm oczekuj─ůcych szybkich efekt├│w. Cz─Östo okazywa┼éo si─Ö r├│wnie┼╝, ┼╝e mimo d┼éugiego etapu analizy po zako┼äczeniu implementacji i test├│w wewn─Ötrznych, klient m├│wi┼é, ┼╝e ÔÇťon inaczej to sobie wyobra┼╝a┼é nie dzia┼éa to tak jak powinnoÔÇŁ. Prowadzi┼éo to do zmian, kt├│re jak wiadomo im p├│┼║niej s─ů robione tym s─ů bardziej czasoch┼éonne, a co za tym idzie kosztowne.

Na przeciw tym zmieniaj─ůcym si─Ö realiom wysz┼éy metodyki zwinne (Agile). W 2001 roku zosta┼é og┼éoszony Manifest Agile (Agile Manifesto), w kt├│rym m.in. Martin Fowler, Ken Schwaber okre┼Ťlili og├│lne zasady dla wszystkich metody z tej grupy. Oto one:

ÔÇťWytwarzaj─ůc oprogramowanie i pomagaj─ůc innym w tym zakresie,

odkrywamy lepsze sposoby wykonywania tej pracy.

W wyniku tych do┼Ťwiadcze┼ä przedk┼éadamy:

Ludzi i interakcje ponad procesy i narz─Ödzia.

Dzia┼éaj─ůce oprogramowanie ponad obszern─ů dokumentacj─Ö.

Współpracę z klientem ponad formalne ustalenia.

Reagowanie na zmiany ponad pod─ů┼╝anie za planem.

Doceniamy to, co wymieniono po prawej stronie,

jednak bardziej cenimy to, co po lewej.ÔÇŁ

Opr├│cz tego przedstawiono 12 zasad wytwarzania zwinnego oprogramowania (numeracja dodana przeze mnie):

1. Najwa┼╝niejsze dla nas jest zadowolenie Klienta wynikaj─ůce z wcze┼Ťnie rozpocz─Ötego i ci─ůg┼éego dostarczania warto┼Ťciowego oprogramowania.

2. B─ůd┼║ otwarty na zmieniaj─ůce si─Ö wymagania nawet na zaawansowanym etapie projektu. Zwinne procesy wykorzystuj─ů zmiany dla uzyskania przewagi konkurencyjnej Klienta.

3. 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.

4. Współpraca między ludźmi biznesu i programistami musi odbywać się codziennie w trakcie trwania projektu.

5. Tw├│rz projekty wok├│┼é zmotywowanych os├│b. Daj im ┼Ťrodowisko i wsparcie, kt├│rego potrzebuj─ů i ufaj im, ze wykonaj─ů swoj─ů prac─Ö.

6. Najwydajniejszym i najskuteczniejszym sposobem przekazywania informacji do i ramach zespo┼éu jest rozmowa twarz─ů w twarz.

7. Podstawow─ů i najwa┼╝niejsz─ů miar─ů post─Öpu jest dzia┼éaj─ůce oprogramowanie.

8. 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.

9. Poprzez ci─ůg┼ée skupienie na technicznej doskona┼éo┼Ťci i dobremu zaprojektowaniu oprogramowania zwi─Öksza zwinno┼Ť─ç.

10. Prostota ÔÇô sztuka maksymalizacji pracy niewykonanej ÔÇô jest zasadnicza.

11. Najlepsze architektury, wymagania i projekty powstaj─ů w samoorganizuj─ůcych si─Ö zespo┼éach.

12. W regularnych odst─Öpach czasu zesp├│┼é zastanawia si─Ö jak poprawi─ç swoj─ů efektywno┼Ť─ç, dostosowuje lub zmienia swoje zachowanie.

Te zasady sta┼éy s─ů punktem wyj┼Ťciowych dla metodyk Agile ÔÇô w tym r├│wnie┼╝ dla Scrum. Jakie cechy j─ů charakteryzuj─ů? Dlaczego warto jej u┼╝ywa─ç?

3. Scrum

Jako si─Ö rzek┼éo Scrum jest zwinn─ů, iteracyjn─ů metodyk─ů. Jej nazw─Ö zaproponowa┼é wymieniony ju┼╝ wcze┼Ťniej Ken Schwaber. Uzna┼é, ┼╝e zasady gry w rugby ┼Ťwietnie obrazuj─ů to jak powinien wygl─ůda─ç proces wytwarzania oprogramowania. Gra w rugby wygl─ůda tak, ┼╝e co jaki┼Ť czas nast─Öpuje przerwa w grze, w kt├│rej ustalany jest plan tego jak rozpocz─ů─ç kolejn─ů akcj─Ö, ca┼éa dru┼╝yna ustawia si─Ö w pozycj─Ö zwan─ů ÔÇťm┼éynemÔÇŁ (z ang. scrum). Rozpoczynana jest gra, wyst─Öpuje pr├│ba realizacji planu, a┼╝ do momentu zatrzymania gry.

Dok┼éadnie w ten spos├│b wygl─ůda proces wytwarzania oprogramowania w metodyce Scrum. Cykl ┼╝ycia aplikacji podzielony jest na okresy zwane sprintami, w kt├│rych wyst─Öpuje etap planowania, realizacji, podsumowania. No ale po kolei.

Elementy metodyki Scrum mo┼╝na podzieli─ç na:

  • zesp├│┼é (z podzia┼éem na role),
  • zdarzenia,
  • artefakty,
  • regu┼éy post─Öpowania.

Wszystkie te elementy daj─ů pe┼éen obraz zasad, kt├│re kieruj─ů Scrumem. Zostan─ů one opisane w kolejnych punktach.

4. Zespół Scrumowy

W przeciwie┼ästwie do metodyk ÔÇťtwardychÔÇŁ w Scrumie nie ma du┼╝ej ilo┼Ťci r├│l, zosta┼éy zdefiniowane tylko 3 role:

  • W┼éa┼Ťciciel Produktu,
  • Scrum Master
  • Zesp├│┼é

stfs

4.1 W┼éa┼Ťciciel Produktu (Product Owner) ÔÇô osoba b─Öd─ůca ┼é─ůcznikiem pomi─Ödzy zespo┼éem a klientem. Odpowiada za ustalenie wymaga┼ä biznesowych, nadanie im priorytet├│w oraz ocen─Ö ich realizacji. Osoba ta kontaktuje si─Ö z klientem, ustala jego zapotrzebowania i oczekiwania.

4.2 Scrum Master ÔÇô odpowiada za to, ┼╝eby proces wytwarzania i oddawania produktu przebiega┼é p┼éynnie i bez zak┼é├│ce┼ä. Czuwa nad tym, ┼╝eby wszystkie zasady by┼éy stosowane, ┼╝eby cz┼éonkowie zespo┼éu mogli skupi─ç si─Ö tylko na swoich zadaniach, nie byli rozpraszani, rzez inne nie b─Öd─ůce w ich kompetencjach. Nie jest zalecane, ┼╝eby Scrum Master by┼é r├│wnie┼╝ W┼éa┼Ťcicielem Produktu.

4.3 Zesp├│┼é (Team) ÔÇô tutaj sytuacja jest bardziej zamglona i trudniejsza do okre┼Ťlenia. Liczebno┼Ť─ç Zespo┼éu powinna si─Ö waha─ç od 5 do 9 os├│b. Zgodnie z zasadami scrum, Zesp├│┼é jest odpowiedzialny za utworzenie produktu. Ka┼╝dy z cz┼éonk├│w zespo┼éu jest sobie sterem, ┼╝eglarzem, okr─Ötem powinien pe┼éni─ç funkcje analityka, testera, programisty. Aby to by┼éo mo┼╝liwe projekt powinien by─ç prowadzony zgodnie z zasadami Test Driven Development (TDD), wed┼éug kt├│rych funkcjonalno┼Ťci (szczeg├│lnie przep┼éywy biznesowe) powinny posiada─ç testy pozwalaj─ůce na weryfikacj─Ö ich dzia┼éania.

5. Zdarzenia

Tak jak ju┼╝ wspomnia┼éem wcze┼Ťniej cykl wytwarzania produktu podzielony jest na Sprinty. Sprint jest najmniejsz─ů jednostk─ů czasow─ů w scrumie. Ka┼╝dy sprint jest zamkni─Öt─ů ca┼éo┼Ťci─ů. W jego obr─Öbie nast─Öpuje planowanie, realizacja i podsumowanie prac projektowych. Po jego zako┼äczeniu powinna zosta─ç dodana konkretna, weryfikowalna warto┼Ť─ç biznesowa do projektu. Sprinty powinny trwa─ç taki sam przedzia┼é czasu. Dzi─Öki temu wprowadzona do projektu zostaje wi─Öksza systematyczno┼Ť─ç. Pozwala to r├│wnie┼╝ lepiej okre┼Ťli─ç jaki zakres pracy zesp├│┼é jest w stanie wykona─ç podczas jednego Sprinta. Sugerowany czas trwania sprinta to od dw├│ch do pi─Öciu tygodni.

Opr├│cz tego sprint cechuj─ů nast─Öpuj─ůce zasady:

  • nie mo┼╝na dokonywa─ç zmian maj─ůcych wp┼éyw na realizacj─Ö cel├│w sprintu,
  • nie mo┼╝na zmienia─ç sk┼éadu Zespo┼éu w trakcie sprintu,
  • nie mo┼╝na obni┼╝a─ç cel├│w jako┼Ťciowych,
  • czas zada┼ä nie powinien si─Ö zmienia─ç. Kiedy jest jednak taka potrzeba to mo┼╝e to by─ç dokonane tylko po konsultacjach pomi─Ödzy Zespo┼éem a W┼éa┼Ťcicielem Produktu.

W obr─Öbie sprinta wyst─Öpuj─ů nast─Öpuj─ůce zdarzenia:

  • codzienny scrum,
  • planowanie sprintu,
  • przegl─ůd sprintu,
  • retrospektywa sprintu.

stfs

5.1 Codzienny scrum jest spotkaniem Zespo┼éu maj─ůcym na celu zrelacjonowanie post─Öp├│w w realizacji zada┼ä, pojawiaj─ůcych si─Ö problem├│w oraz przedstawienie swoich plan├│w na najbli┼╝szy dzie┼ä pracy. Powinny one si─Ö odbywa─ç z rana o jednakowej godzinie, nie trwa─ç d┼éu┼╝ej ni┼╝ 15 minut na stoj─ůco. Najlepiej w tym samym miejscu. Dlaczego na stoj─ůco? Dla niewygody. Dzi─Öki tej niezbyt przyjemnej do dyskusji pozycji zmniejszamy szans─Ö na to, ┼╝e osoby uczestnicz─ůce b─Öd─ů si─Ö rozwodzi┼éy bardziej nad swoimi rzeczami ni┼╝ to konieczne.

Wa┼╝ne jest r├│wnie┼╝ to, ┼╝e w trakcie Codziennego Scruma nie rozwi─ůzujemy problem├│w, relacjonujemy je i ewentualnie ustalamy, czy jest kto┼Ť kto ma pomys┼é na jego rozwi─ůzanie.

Scrum Master na tych spotkaniach odgrywa rol─Ö moderatora.

5.2 Planowanie sprintu odbywa si─Ö jak mo┼╝na si─Ö ┼éatwo domy┼Ťle─ç na pocz─ůtku sprintu. Okre┼Ťlane w nim jest to co ma zosta─ç wykonane w jego obr─Öbie. Nie powinno ono trwa─ç d┼éu┼╝ej ni┼╝ 8h dla sprintu 4 tygodniowego, 4h dla dwutygodniowego.

Pierwszym etapem planowania jest wybranie z po┼Ťr├│d puli zada┼ä dla ca┼éego projektu (zwanym Rejestrem Produktu lub z ang. Product Backlog) tych kt├│re zostan─ů w nim wykonane (zadania te zostaj─ů wrzucone do puli zwanej Rejestrem Sprintu lub z ang. Sprint Backlog). Odbywa si─Ö on poprzez dialog Zespo┼éu z W┼éa┼Ťcicielem Produktu. Oszacowany zostaje r├│wnie┼╝ wst─Öpny czas jaki jest potrzebny na zrobienie danego zadania.

Przy wyborze zadań do Sprintu powinny być brane pod uwagę takie czynniki jak:

  • liczebno┼Ť─ç zespo┼éu,
  • analogie z poprzednimi sprintami, por├│wnanie ile uda┼éo si─Ö w nich zrobi─ç,
  • oraz to, ┼╝eby zadania sk┼éada┼éy si─Ö w logiczn─ů ca┼éo┼Ť─ç, tak, ┼╝eby po zako┼äczeniu Sprintu zosta┼éa oddana konkretna warto┼Ť─ç biznesowa.

Okre┼Ťlony zostaje r├│wnie┼╝ Cel Sprintu. Jest nim zwykle kamie┼ä milowy w obr─Öbie danego produktu np. utworzenie konkretnego modu┼éu, funkcjonalno┼Ťci. W drugiej cz─Ö┼Ťci planowania Zesp├│┼é okre┼Ťla szczeg├│┼éy implementacji wybranych zada┼ä. Dekomponuje je na podzadania, tak aby odzwierciedla┼éy one lepiej etapy programistyczne konieczne do ich wykonania. Weryfikowane s─ů r├│wnie┼╝ poprzednie szacunki czas├│w wykonania zada┼ä. Mo┼╝liwa jest te┼╝ zmiana zawarto┼Ťci Rejestru Sprintu, ale tylko i wy┼é─ůcznie po konsultacji i akceptacji W┼éa┼Ťciciela Produktu.

5.3 Przegl─ůd Sprintu ÔÇô jest to podsumowanie dokonywane na zako┼äczenie Sprintu. Ustalane jest na nim co si─Ö uda┼éo a co si─Ö nie uda┼éo zrobi─ç. Okre┼Ťlone zostaje jak du┼╝y by┼é Przyrost (Effort) wykonany w trakcie Sprintu. Omawiane zostaj─ů r├│wnie┼╝ problemy na jakie natrafiono w trakcie realizacji zada┼ä. Zadania, kt├│re nie zosta┼éy zrealizowane wracaj─ů do Rejestru Produktu.

Zwykle odbywa si─Ö prezentacja aktualnej wersji produktu dla W┼éa┼Ťciciela Produktu, kt├│ry jest osob─ů akceptuj─ůc─ů realizacj─Ö zada┼ä. Okre┼Ťlana jest te┼╝ wst─Öpna wizja tego co b─Ödzie dzia┼éo si─Ö w kolejnym Sprincie.

Przegl─ůd nie powinien trwa─ç d┼éu┼╝ej ni─ç 4 godziny dla Sprintu 4 tygodniowego i 2 godziny dla 2 tygodniowego.

5.4 Retrospektywa Sprintu ÔÇô Odbywa si─Ö ona po przegl─ůdzie. Jest to chwila, w kt├│rej Zesp├│┼é mo┼╝e przeanalizowa─ç to co dobrego/z┼éego wydarzy┼éo si─Ö w ostatnim Sprincie. Zesp├│┼é powinien okre┼Ťli─ç co i jak mo┼╝na by┼éo by poprawi─ç, kt├│re dzia┼éania, metody nale┼╝a┼éo by kontynuowa─ç. Zadaniem Scrum Mastera jest przeprowadzi─ç tak dyskusj─Ö, ┼╝eby ka┼╝dy z cz┼éonk├│w zespo┼éu aktywnie bra┼é udzia┼é w opracowywaniu nowych zalece┼ä. Spotkanie to nie powinno trwa─ç d┼éu┼╝ej ni┼╝ 3 godziny.

6. Artefakty

Artefakty s─ů to elementy, kt├│re opisuj─ů wykonywan─ů prac─Ö wykonywan─ů podczas trwania projektu w Scrumie. S─ů to:

  • Rejestr Produktu (Product Backlog),
  • Rejestr Sprintu (Sprint Backlog),
  • Przyrost (Effort)

    6.1 Rejestr Produktu ÔÇô jest to zbi├│r wymaga┼ä, zmian oraz zada┼ä, kt├│re musz─ů zosta─ç wykonane, ┼╝eby produkt zosta┼é utworzony w ca┼éo┼Ťci. Zadania te s─ů zwykle w postaci Historii U┼╝ytkownika (User Stories), czyli opisu tego jakie ma by─ç zachowanie systemu w kontakcie z u┼╝ytkownikiem. Ka┼╝da historia u┼╝ytkownika powinna zawiera─ç kryteria akceptacji jego realizacji.

Za zarz─ůdzanie i piel─Ögnacj─Ö Rejestru Produktu odpowiada W┼éa┼Ťciciel Produktu. Rejestr Produktu ewoluuje wraz z produktem. Na podstawie kontakt├│w z u┼╝ytkownikami, pracami Zespo┼éu w trakcie sprint├│w pojawiaj─ů si─Ö uwagi, doprecyzowania, zmiany, b┼é─Ödy. Rejestr Produktu pozostaje pusty dopiero gdy nie b─Öd─ů dokonywane ┼╝adne prace nad produktem.

6.2 Rejestr Sprintu ÔÇô w trakcie realizacji produktu, wraz z kolejnymi Sprintami przenoszone zostaj─ů elementy z Rejestru Produktu do Rejestr├│w kolejnych Sprint├│w. Wszystkie te elementy wchodz─ů w sk┼éad zdefiniowanego celu dla danego sprintu. Poniewa┼╝ Historie U┼╝ytkownika nie s─ů wystarczaj─ůco precyzyjn─ů form─ů opisu zada┼ä dla Zespo┼éu, zwykle dzielone s─ů na podzadania, wg logicznego programistycznego podej┼Ťcia.

Jedynie Zesp├│┼é mo┼╝e zadecydowa─ç o dodaniu czego┼Ť lub usuni─Öcia z Rejestru Sprintu. Po zako┼äczeniu Sprintu Zesp├│┼é wraz z W┼éa┼Ťcicielem Produktu decyduj─ů co zrobi─ç z niezrealizowanymi historiami u┼╝ytkownik├│w (czy je zamkn─ů─ç czy wrzuci─ç z powrotem do Rejestru Produktu).

6.3. Przyrost ÔÇô jest to wska┼║nik, m├│wi─ůcy o tym co do tej pory uda┼éo si─Ö zrealizowa─ç. Ka┼╝da historia u┼╝ytkownika jest opisana przez punkty przyrostu. Poprzez sum─Ö przyrost├│w poszczeg├│lnych Historii U┼╝ytkownika wyra┼╝ona jest ilo┼Ť─ç zrealizowanych funkcjonalno┼Ťci.

Ufff. Troch─Ö si─Ö spisa┼éem, a i tak wydaje mi si─Ö, ┼╝e p├│ki co przeskoczy┼éem tylko po ┼éebkach przez tematy zwi─ůzane ze Scrumem. W kolejnych wpisach przedstawi─Ö jak Team Foundation Server mo┼╝e nam pom├│c w codziennej pracy ze Scrumem, jak j─ů u┼éatwi─ç i pozwoli─ç sprawnie go prowadzi─ç.

Tak jak wspomina┼éem prosz─Ö Was gor─ůco o uwagi co do niejasno┼Ťci/b┼é─Öd├│w/zamglonych opis├│w.

Kolejny wpis to instalacja i wst─Öpna konfiguracja TFS.

Źródła:

  • ┬ę Oskar Dudycz 2020 - 2021