Garść wniosków z obserwacji SCRUMa w praktyce - no, może nie odnośnie całego frameworka, a jedynie dwóch jego aspektów - estymacji i planowania. Zacznę od krótkiego SCRUMowego przypomnienia - otóż, jak wszyscy doskonale wiemy, jednym z artefaktów SCRUMa jest Backlog (lista zaległości produktu) - to lista zmian, które mają zostać wprowadzone w produkcie przez pracujący nad nim zespół deweloperski (bądź zespoły). Widniejące na takiej liście zmiany (zadania) zespół deweloperski omawia w trakcie spotkań nazywanych "refinmentem" (doskonaleniem), czyli w trakcie spotkań porządkowania listy zalogłości produktu (choć należy zauważyć, iż "refinement" przez Scrum Guide jest opisywany jako "proces ciągly", więc podejście do "porządkowania" może wyglądać różnie w różnych zespołach; w zespołach, w których ja miałem okazję pracować przyjęta była akurat zasada organizowania raz w tygodniu spotkania w celu omawiania zadań z backloga). Tak więc, w trakcie "refinementu" zespół stara się oszacować (wyestymować) ilość pracy potrzebną na realizację zadań (usuwanie zaległości) spisanych w backlogu. Szacunki dotyczą oczywiście poszczególnych zadań, a nie całości backloga, który może być oszacowany jedynie bardzo... ogólnie (przynajmniej w teorii). I tutaj pojawia się pierwszy problem: jak szacować ilość pracy potrzebą na realizację określonego zadania?
Podejść jest oczywiście kilka (sam Scrum Guide milczy w tej kwestii). W zespole, w którym ja pracuję wykorzystujemy tzw. "story points" (SP). Idea SP jest prosta choć jednocześnie to chyba właśnie ona sprawia najwięcej problemów (i prowokuje najwięcej dyskusji) - do SP więc za chwilę powrócę, teraz prześledźmy jeszcze szybko co dzieje się dalej na SCRUMowym taśmociągu produkcji. Bazując na szacunkach poczynionych podczas porządkownia backlogu zespół może następnie określić, w trakcie innego spotkania, nazywanego "planowaniem sprintu", ile zadań z góry listy zaległości, którą wg swoich priorytetów sortuje Product Owner (PO - właściciel produktu), będzie możliwe do wykonania w nadchodzącym "sprincie" (czyli stałym dla zespołu okresie czasu realizacji zadań). Moje doświadczenia ograniczają się do sprintów dwutygodniowych, ale to oczywiście jest kwestia umowna - Scrum Guide określa długość sprintu jako miesiąc bądź krócej.
I tak to mniej więcej się kręci - po zakończeniu jednego sprintu, planowany i realizowany jest kolejny, i kolejny, i kolejny.
Jedna uwaga: pomijam tutaj wiele szczegółów i nie tylko szczegółów - niniejszy artykuł nie ma na celu opisu SCRUMa jako takiego, chcę skupić się tylko i wyłącznie na problemie estymacji i planowania!
No dobrze - przyjmijmy, że naszym rozwiązaniem problemu pierwszego ("jak szacować?") są SP, czas więc na problem drugi: relację SP do czasu. Definicja story pointów (podlinkowana we wstępie) zawiera dość istotne zdanie: "Story points do not relate to hours". Okazuje się, że to dość trudna kwestia. Wyobraźmy sobie sytuację, w której zespół otrzymał backlog produktu i został poproszony o jego wyestymowanie (krótko przypomnę, że w tym artykule znacznie upraszczam procesy SCRUMowe). Umówmy się, iż przyjęto, że estymacje będą w SP i zespół od razu zabrał się do pracy, dostarczając, po długim i burzliwym spotkaniu, pięknie wyestymowany backlog (każdemu z zadań została przypisana jakaś wartość w SP). Teraz zespół udaje się na kolejne spotkanie w celu zaplanowania pierwszego sprintu. Wyobraźmy sobie zespół na tym właśnie spotkaniu - z jednej strony mamy pięknie wyestymowany backlog (w SP, które nie mają związku z czasem), a z drugiej strony mamy Sprint, który określony jest tylko jedną wartością - długością trwania, a więc czasem!
Jak połączyć jedno z drugim? Bo przecież musimy zdecydować, ile zadań jesteśmy w stanie "wziąć" do sprintu (czyli wykonać w czasie jego trwania), a nasze SP nie mówią nic o czasie (takie już te SP są). I ponownie - rozwiązań tego problemu jest oczywiście co najmniej kilka (jeżeli nie tyle co SCRUMowych zespołów), ja skupię się na dwóch.
Romantyczna miłość.
W literaturze spotykałem się z terminem "obietnica". W tym podejściu nie przejmujemy się zbytnio konsekwencjami - bierzemy tyle ile wydaje się nam, że jesteśmy w stanie udźwignąć. To w sumie całkiem dobre podejście w przypadku początkujących teamów bądź teamów rozpoczynających pracę nad nowym produktem. Daje ono zespołowi duży komfort pracy - w końcu nasz sprint backlog (czyli lista zadań w sprincie) to tylko "obietnica" (presja związana z terminem realizacji praktycznie więc nie istnieje)! W takim podejściu biznes może starać się zapewnić sobie pewne minimum pracy, która musi zostać wykonana, poprzez wyznaczanie celi sprintów (cel sprintu definiuje zadania, które MUSZĄ zostać wykonane, aby sprint mógł być uznany za udany). Bądź przez ułożenie zadań w sprint backlogu w kolejności ich znaczenia dla biznesu (czyli jeżeli coś nie zostanie zrobione, to będą to zadania bardziej z dołu listy, niż te o wyższych priorytetach, umieszczone na górze sprint backloga). "Romantyczna miłość" jest podejściem, powiedzmy, mało wymagającym. Planowanie sprintu jest tutaj dość szybkie - po prostu bierzemy z góry backloga jakąś ilość zadań i tyle, co ma być - to będzie. Nasz główny problem, czyli relacja czasu do SP, nie wydaje się tutaj jakoś bardzo istotny. Nie musimy się nim specjalnie przejmować i szukać sposobu na "pogodzenie" naszych dwóch światów (backloga z zadaniami wyestymowanymi w SP i sprintu, określonego tylko czasem trwania), ponieważ tak naprawdę nie ma potrzeby dokładniejszej weryfikacji naszych szacunków (no może, poza sytuacjami, gdy zadanie wyestymowane na 1 SP zajmuje czterem deweloperom całe dwa tygodnie!). Ok, a wracając do naszego problemu, jak się okazuje, nie zawsze trzeba specjalnie się przejmować pogodzeniem SP z czasem, istnieją praktyki, w których po prostu nie jest to wymagane. Niestety ma to, w moim odczuciu, pewne negatywne konsekwencje - sprawia, że nasz projekt staje się bardziej "chaotyczny".
Biznesowe zobowiązanie
I ponownie - w literaturze można spotkać się z terminem "zobowiązanie", przymiotnik "biznesowe" dodałem od siebie. To jakby drugi koniec skali - "totalna opozycja" do opisanej w poprzednim paragrafie "romantycznej miłości". W "zobowiązaniu" wszystkie zadania wybrane do sprint backloga można traktować jako sprint goal (cel sprintu), nie jest koniecznym priorytetyzowanie zadań (w sprint backlogu) - wszystkie są tak samo ważne i niewykonanie któregokolwiek z nich powoduje, iż cały sprint zostaje uznany za spalony. Z góry zaznaczę, iż wątpię, aby tak rygorystyczne zasady coś poprawiały - praca z tak wysoko postawioną poprzeczką byłaby chyba bardzo... wyniszczająca. Moim zdaniem, święty Gral SCRUMa to coś pomiędzy "romantyczną miłością" a "biznesowym zobowiązaniem". Być może, im bliżej "biznesowego zobowiązania" i im dalej od "romantycznej miłości", tym bardziej "zaawansowany" (w sensie SCRUMa) zespół? Może tak, może nie - w każdym razie, patrząc z punktu widzenia biznesu, "biznesowe zobowiązanie" wydaje się opcją o wiele bardziej korzystną. Tutaj niepewność co do ostatecznej "zawartości" kolejnego przyrostu jest ograniczona do minimum, choć negocjacje podczas planowania sprintu mogą być dużo bardziej zacięte czy długie.
Romantyczna miłość czy biznesowe zobowiązanie?
Gdzie znajduje się "pokrętło", które zamienia naszą "romantyczną miłość" w "biznesowe zobowiązanie" i odwrotnie? Moim zdaniem, takim pokrętłem jest właśnie proces planowania sprintu i podejście do problemu "mapowania" zadań estymowanych w SP na sprint (określony tylko czasem). Czym dokładniej wykonany zostanie ten proces, czym więcej poświęcimy mu czasu, tym bardziej przesuwamy się w stronę "biznesowego zobowiązania" i tym większe oczywiście prawdopodobieństwo (pełnego) sukcesu! Warto zauważyć, że Scrum Guide określa czas trwania ceremonii planowania sprintu na 8 godzin dla sprintu trwającego miesiąc (zaznaczając, iż ten czas powinien być odpowiednio krótszy w przypadku krótszych sprintów), więc mimo, iż nie ma dokładnych informacji o tym jak takie spotkanie powinno wyglądać, 8 godzin może sugerować, iż twórcy SCRUMa mają na myśli jednak bardziej zaawansowane podejście do tego tematu, niż proste wybranie do sprintu zadań z "góry" backloga których suma SP odpowiada aktualnemu velocity (średnia liczba SP per sprint) zespołu. Poza tym Scrum Guide daje następujące wskazówki co do przebiegu samego planowania:
Sprint Planning answers the following:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
Drugi punkt jest chyba zaniedbywany przy podejściu typu "romantyczna miłość". Oczywiście zespół może dysponować dość szczegółowymi informacjami o tym jak (z technicznego punktu widzenia) rozwiązać poszczególne zadania, ale plan ogólny (co, kto, kiedy?) będzie czystą improwizacją.
Mapowanie
Krótko przypomnę z czym się zmagamy - mamy już wyestymowane w SP zadania (backlog), teraz przyszedł czas, aby zaplanować sprint. Załóżmy, że chcemy zaplanować nasz sprint jak najdokładniej, starając się jak najbardziej zbliżyć do dokładności “biznesowego zobowiązania" (oczywiście wybieranie jednego zadania na sprint nie jest rozwiązaniem w myśl zasady, że niedoszacowanie jest równie złe jak przeszacowanie). Czy możemy się tutaj wspomóc jakimś "narzędziem", czy pozostaje jedynie liczyć na własne doświadczenie oraz znajomość produktu? W jednym z zespołów, w którym pracowałem, koledzy stosowali bardzo ciekawą metodę - nie jestem teraz w stanie powiedzieć, czy było (jest) to rozwiązanie autorskie, czy też wykorzystano tu jakąś ogólną (udokumentowaną i znaną) praktykę - jeżeli to drugie i ktoś mógłby wskazać link do jakiegoś opisu to proszę o informację!
Ogólna zasada jest dość banalna, jednak różne zespoły mogą różnie podchodzić do szczegółów. Bazą jest tabela zespół per czas (dni) sprintu, w której kolumny to dni sprintu, wiersze natomiast to poszczególni developerzy. W tak przygotowanej tabeli możemy rozplanować kto, kiedy i czym się będzie zajmował (numery zadań wpisujemy w pola tabeli na przecięciu wiersza przypisanego danemu deweloperowi z kolumną przypisaną danemu dniu).
Moja praktyka pokazuje, że wykorzystanie takiej tabeli czyni kolosalną różnicę - oto pierwsza weryfikacja naszego planu! Sprawdzenie czy w ogóle mamy wystarczającą ilość zasobów (czasu / ludzi) na jego realizację. Zaczynamy rozpracowywać więc nasz podstawowy problem - przekładanie SP na czas! No dobra, ale skoro SP nie zawierają informacji o czasie to jak rozkładać je na "dni" w sprincie? Chyba jedyne możliwe w tej sytuacji rozwiązanie, to pozwolić określić czas wymagany na wykonanie danego zadania deweloperowi, który tym zadaniem będzie się zajmował - i tak właśnie postępowaliśmy w zespole, w którym spotkałem się z tą praktyką. Uważam, że to naprawdę dobre rozwiązanie. Metoda ta może również pomóc nam zrozumieć dlaczego nie powinniśmy "łączyć" czasu z SP - to samo zadanie, może zostać rozłożone na różną ilość dni w zależności od tego, który z deweloperów będzie się nim zajmował - to powinno być zupełnie naturalne, jak również to, że zadania wyestymowane na tę samą ilość SP mogą rozkładać się na różną ilość dni (bo będą wykonywany przez różnych deweloperów - z różnym doświadczeniem, stażem pracy, różną znajomością produktu, itd...).
Oczywiście - pozwólcie doprecyzować - z tego co pamiętam, nie staraliśmy się wypełniać zawsze dokładnie wszystkich dni zadaniami. W przypadku koderów (ludzi odpowiedzialnych za kod) końcówki sprintu raczej pozostawały puste, testerzy natomiast mają wtedy przeważnie urwanie głowy. No i pisząc "puste" nie mam na myśli "nogi na biurko" i takie tam - jeżeli naprawdę nie ma już nic do roboty (nie ma komu pomóc, wszystkie zaległości uzupełnione), to zawsze można przeglądać backlog i przygotowywać się na kolejny refinement :)
Pisałem, że ta metoda może różnić się w szczegółach wśród różnych zespołów. Głównie, z mojego doświadczenia, chodzi o to co w takiej "tabeli zadań" umieszczać. Ja skłaniam się za umieszczaniem wszystkich rodzajów zadań na których skupia się zespół w trakcie sprintu - czyli dewelopmentu, code review, testów. Z tego co pamiętam, to w takiej formie działało to najlepiej. Możliwym jest oczywiście zaznaczanie tylko dewelopmentu, bez CR i testów (zaznaczanie testów bez określenia, kiedy ma być zrobione CR to już po prostu loteria - zasada: "każdy dzień zacznij od CR" może rekompensować brak wpisywania CR do naszej tabelki, jednak praktyka, w moim przypadku, pokazuje, że jak czegoś nie ma w tabelce, to... może ktoś to zrobi, a może nie :))
Podsumowanie
Tyle, jeżeli chodzi o moje przemyślenia na temat estymacji i planowania - temat jak widać nie jest banalny. A czy w ogóle warto poświęcać czas na planowanie? Jeżeli ktoś uważa, że nie, to z pewnością spodoba mu się Kanban - w SCRUMie od planowania nie uciekniemy. Oczywiście nasze podejście do tego planowania może się różnić, może to być planowanie mało precyzyjne bądź bardzo dokładne - wszystko zależy od zespołu, jego wyników, zadowolenia PO z postępów, itd... Jeżeli wszystko idzie dobrze, to chyba nie ma sensu zwiększać presji i starać się "przesuwać" w kierunku "zobowiązania". Inna rzecz, jeżeli uważamy, że nie wszystko się klei - wtedy większy nacisk na dokładność być może, pomoże zespołowi znów nabrać wiatru w żagle. W przypadku różnych zespołów mogą więc sprawdzać się różne podejścia - złotego środka chyba brak :)