Jak już zaznaczałam wielokrotnie, pisanie kodu to tylko jedno z codziennych zadań programisty. Najczęściej developer nie pracuje solo, a jest częścią składową zespołu, który musi się w jakiś sposób komunikować. Należałoby też w jakiś sposób wyznaczać sobie cele, jakoś się z nich rozliczać i planować rozkład pracy. Do tego wszystkie służą różne metodyki zarządzania projektami, w tym między innymi Scrum.
W swoim dotychczasowym doświadczeniu zawodowym – nie tylko programistycznym – spotkałam się z kilkoma sposobami zarządzania projektem, np. Prince2 czy Kanban. Z metodyki Kanban korzystam od dłuższego czasu na własne potrzeby i dzięki narzędziu Trello jestem w stanie zarządzać moimi własnymi projektami – przez projekt rozumiem tu nie tylko pisanie własnej aplikacji, ale również np. organizację eventu czy przygotowania do występu.
W moim obecnym projekcie korzystamy z Nexusa, czyli Scruma, który można skalować dla większych projektów. Różnice z grubsza polegają na tym, że jest więcej wydarzeń i więcej ról niż w tradycyjnej wersji. Framework ten został stworzony przez Kena Schwabera, twórcę Scruma, który opisał jego funkcjonowanie w tym przewodniku.
Ale co to jest ten Scrum?
Jak podaje Wikipedia, Scrum to:
„…iteracyjne i przyrostowe ramy postępowania (ang. framework) zgodne ze Scrum Guide. Może mieć zastosowanie w realizacji projektów w oparciu o metodyki zwinne zgodne z manifestem Agile. Rozwój produktu podzielony jest na trwające maksymalnie jeden miesiąc iteracje, zwane sprintami. Po każdym sprincie zespół powinien być w stanie dostarczyć działającą wersję produktu. Scrum jest często stosowany podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej dziedziny.”
Tyle definicja. Gdybym miała wytłumaczyć komuś własnymi słowami jak ja to rozumiem, to powiedziałabym, że Scrum to pewna metodyka zarządzania projektem. Najważniejsze założenia to planowanie i rozliczanie pracy w ustalonych krótkich interwałach czasowych oraz samostanowienie zespołu. A jak to wygląda w praktyce?
Kto jest kim
Jest kilka głównych ról w Scrumie. Są to:
- Scrum Master
To osoba, która pilnuje, żeby Scrum był prawdziwym Scrumem. Są do niego podręczniki i certyfikacje, rządzi się swoimi prawami – niektóre można modyfikować, innych nie należy. SM w praktyce zajmuje się wsparciem zespołu, usuwaniem przeszkód w realizacji celów i doradzaniem. Pomaga Product Ownerowi w zarządzaniu backlogiem produktu. - Product Owner
To osoba, która zarządza listą zadań niezbędnych do realizacji produktu (backlogiem). Reprezentuje klienta, dostarcza zespołowi informacje na temat zakresów zadań. - Zespół developerski
To samostanowiący zespół niezbędny do wytwarzania przyrostu, czyli kolejnych funkcjonalności produktu. Po ludzku programiści, testerzy, designerzy, etc.
Scrum w akcji
Interwał czasowy, o którym wspomniałam powyżej, nazywa się sprint. Sprint w moim projekcie ma długość dwóch tygodni. Ze sprintu na sprint planujemy pracę, wyceniamy zadania, dzielimy się obowiązkami. Trzeba mieć zatem świadomość, że z 10 dni roboczych w sprincie realnie na pracę zostaje niecałe 9. Jeżeli dodać do tego to, że ukończenie zadania zależy od spełnienia kryteriów DoD (Definition of Done), czyli przejście code review, przetestowanie przez testera oraz umieszczenie na środowisku testowym, to szybko okaże się, że na wykonanie zadań w sprincie developerzy mają maksymalnie 8 dni roboczych (a ktoś to code review też musi zrobić…).
Szacowanie
Koniec każdego sprintu zazębia się z początkiem kolejnego. Wszystko zaczyna się od szacowania, czyli spotkania, na którym developerzy wyceniają zadania z backlogu. Backlog to lista zadań, jakie należy wykonać aby ukończyć projekt. Zasada jest taka, że u góry znajdują się zadania najważniejsze, najpilniejsze do wykonania i to od nich – w miarę możliwości – należy zacząć pracę.
Estymacja (szacowanie) może odbywać się w różnych jednostkach. Niektóre zespoły preferują wycenę w tzw. man-dayach, czyli jednostce pracy jednego człowieka przez jeden dzień. Można również szacować w story points, czyli jednostce względnej oddającej stosunek jednego zdania do innych w kolejnych liczbach z ciągu Fibonacciego. Oznacza to tyle, że jeden zespół może wycenić zadanie na 5 a drugi na 13 i wszystko będzie ok, bo zależy tylko od tego jaką miarę przyjmą na zadanie za 1 story point.
Szacowanie może przebierać różne ciekawe formy. Jedną z nich jest Planning Poker, czyli zabawa w której każdy członek zespołu musi wyszacować każde zadanie w procesie. Następnie osoby, które podały skrajne wartości (najwyższą i najniższą) proszone są o uzasadnienie swojego wyboru. Gra gwarantuje niesamowite skupienie na planowaniu, niestety jest bardzo kosztowna czasowo: na samo planowanie trzeba poświęcić kilka bitych godzin.
Planning
O ile w szacowaniu uczestniczą członkowie zespołu, o tyle na planningu obecny jest Product Owner. Planning to nic innego jak dobieranie zadań do sprintu z uwzględnieniem tzw. spadów, czyli zadań nieukończonych w poprzednim sprincie. Zadania dociąga się do sprintu do granicy znanego velocity, czyli średnia ilość zrealizowanych przez zespół jednostek (np. story points) w sprincie. Reszta zadań pozostaje w backlogu.
Po ustaleniu zakresu sprintu należy ustalić jeszcze cel sprintu, czyli podsumowanie zadań w formie zdania.
W końcu praca!
Po wielu godzinach spędzonych na spotkaniach nadchodzi wreszcie czas na wypracowywanie celu sprintu. I tak pierwszy dzień nowego sprintu zaczyna się od… spotkania, a jakże! Każdego dnia rano zespół zbiera się na Daily Scrum (inne nazwy to DS, Daily, Standup), gdzie każdy z członków zespołu mówi czym zajmował się wczoraj, czym będzie zajmował się dziś i jakie napotkał przeszkody w pracy (jeśli jakieś wystąpiły).
Codzienny Daily Scrum pozwala każdemu członkowi zespołu dowiedzieć na jakim etapie są prace nad realizacją celu sprintu i z jakimi problemami borykają się inne osoby. Spotkanie powinno trwać maksymalnie 15 minut.
Przegląd sprintu
Po zakończonym sprincie przychodzi czas na przyjrzenie się z bliska temu, co zostało wytworzone przez ostatnie dwa tygodnie. W przypadku mojego projektu ma to formę demo, każdy z zespołów kolejno prezentuje wykonane zadania w akcji. Oczywiście nie zawsze są to piękne GUI dostosowane do wymyślnych makiet od grafików albo świeżutki CMS. Często to zadania związane z zarządzaniem danymi, gdzie nie ma miejsca na ładne obrazki.
Podczas przeglądu sprintu prezentowana jest też statystyka wpływająca na velocity, tzn ile story points zespół spalił podczas sprintu (wykonał zgodnie z DoD) oraz ile zadań to spady przechodzące na kolejny sprint.
Retrospektywa sprintu
Ostatnim spotkaniem domykającym sprint jest tak zwane retro. To spotkanie mające na celu poprawę działania w kolejnych sprintach. To czas dla zespołu, żeby zastanowić się wspólnie co można zrobić, żeby było nam lepiej a praca szła sprawniej. W moim projekcie korzystamy z tablicy FunRetro. To aplikacja, która zbiera wirtualne stickery („żółte karteczki”) w trzech kategoriach, które kolejno odpowiadają na pytania:
- Co poszło dobrze?
- Co nie poszło dobrze?
- W jaki sposób możemy poprawić tę sytuację?
Karteczki zaczynamy zbierać z kilkugodzinnym wyprzedzeniem i analizujemy jest podczas spotkania. Z reguły retro rozpoczyna się od wyświetlenia tablicy z poprzedniego sprintu i przeanalizowaniu tego co zostało zrobione, żeby poprawić sytuację (tzw. action items, kolumna odpowiadająca na trzecie pytanie). Potem następuje przejście przez wszystkie elementy tablicy i wspólne ich omówienie.
Narzędzie scrumowe
No dobrze, jest projekt, jest zespół, jest produkt i gdzieś jest też ten magiczny backlog, ale przecież gdzieś trzeba trzymać te zadania do wykonania? Tutaj z pomocą może przyjść wiele narzędzi dedykowanych Scrumowi. W moim projekcie jest to Jira, czyli oprogramowanie do zarządzania projektami. Jira pozwala na na tworzenie backlogu produktu i zarządzanie nim poprzez tworzenie sprintów, zmianę statusów każdego z zadań, rozbijanie zadań na podzadania czy wpisywanie wyszacowanej ilości jednostek.
Podsumowanie
Scrum i agile (którego w tym wpisie nawet nie wspomniałam, zdecydowanie wrócę do tego tematu w przyszłości) to bardzo obszerne zagadnienia, które były dla mnie dość trudne do wyobrażenia zanim zaczęłam mieć z nimi bezpośrednią styczność. Mam nadzieję, że w tym wpisie choć trochę przybliżyłam ten temat i nawet osoba, która nie ma doświadczenia w pracy programisty złapie mniej więcej na czym praca w Scrumie polega. Po więcej informacji odsyłam do mojego ulubionego bloga o Srumie białko.eu.