Kryterium Gotowości

styczeń 6, 2010 autor: Andy Brandt
Kategoria: Artykuły 

Widoczną tendencją w społeczności praktyków i trenerów Scruma jest rosnące docenienie roli Product Ownera. Efektem tego są propozycje praktyk i rozwiązań, które mają usprawnić pracę Product Ownerów. Jedną z nich przedstawiam poniżej.

Po dobrym wdrożeniu Scruma (i innych praktyk agile) w zespołach często występuje efekt „odkurzacza” na backlogu. Polega on na tym, że wraz ze wzrostem efektywności zespołu „czyści” on backlog z zadań powodując, że Product Owner nie nadąża z dobrym definiowaniem odpowiedniej liczby nowych zadań. Kończy się to najczęściej tworzeniem przez Product Ownera zadań naprędce podczas spotkania Planowania Sprintu po to tylko, by zespół miał co robić – by jakoś wypełnić sprint. Oczywiście, takie wymyślone na poczekaniu zadania mają małe szanse być naprawdę wartościowe.

Aby temu zapobiec praktycy Scruma tacy jak Jeff Sutherland czy Serge Beaumont proponują usprawnienie zarządzania backlogiem przez wprowadzenie do Scruma nowej, dodatkowej definicji jakościowej.

Jak wiadomo w każdym projekcie prowadzonym w Scrumie ustala się kryterium ukończenia (ang. definition of done). Określa ono kiedy realizowane zadanie można uznać za wykonane. Jeśli zadanie kryterium tego na końcu sprintu nie spełnia, to niezależnie od tego jak zaawansowane były prace na nim spada ono z powrotem na backlog – nie jest dostarczone.

Najczęściej kryterium ukończenia wyrażone jest mniej więcej tak: „Historyjka użytkownika zaimplementowana, pokryta testami jednostkowymi, zatwierdzona w teście akceptacyjnym, skonsolidowana z resztą projektu, nadająca się do wydania na serwer produkcyjny.”

Innowacja polega na wprowadzeniu analogicznego kryterium na początku sprintu – kryterium gotowości (ang. definition of ready), które określa jakie cechy ma posiadać zadanie aby mogło być wzięte przez zespół „do sprintu” podczas Planowania Sprintu. Zadania nie spełniające tego kryterium nie są brane pod uwagę – nie będą przy planowaniu sprintu rozpatrywane.

Kryterium takie może wyglądać na przykład tak: „Zadanie w pełni zrozumiałe dla zespołu, oszacowane przez zespół, z przygotowanym wstępnym projektem sposobu realizacji, bez otwartych pytań do product ownera”.

Rolę obu kryteriów można porównać do swego rodzaju filtrów. Kryterium ukończenia „odsiewa” nieukończone zadania – określa się je po to, by ustalić pożądaną jakość produktu końcowego. Kryterium gotowości „odsiewa” zadania źle lub niejasno zdefiniowane – określa się je po to, by zespół pracował nad wartościowymi i zrozumiałymi dla niego zadaniami.

Konsekwencją wprowadzenia kryterium gotowości jest pojawienie się różnych stanów (statusów) zadań na backlogu projektu. W najprostszym przypadku będą to przynajmniej dwa stany: zadania „nowe” i „gotowe”. Zadania świeżo wprowadzone na backlog są „nowe”, zadania spełniające kryterium gotowości – „gotowe”. Product Owner stara się doprowadzić zadania do stanu „gotowe”, a więc do tego by spełniały one kryterium gotowości.

Zakłada się, że Product Ownerowi pomaga w tym także i zespół. Dobrą okazją do tego jest oszacowywanie zadań. Niewątpliwie zadania oszacowywać powinien zespół, zarazem, powinno się to odbywać nie tylko podczas spotkań Sprint Planning. W praktyce Scruma zaleca się, aby zespół (wraz z Product Ownerem) poświęcał przynajmniej 5% czasu w sprincie na tak zwaną pielęgnację baclogu. Czas ten można spożytować na dyskusję z Product Ownerem nad najważniejszymi jego zdaniem zadaniami „nowymi” tak, by stały się one dla zespołu na tyle jasne i zrozumiałe, by mógł dokonać ich dobrego oszacowania i uznać je za „gotowe”.

W najprostszym wydaniu proces przechodzenia od zadań „nowych” do „gotowych” wygląda zatem następująco:

  1. Product Owner umieszcza nowe zadanie na backlogu (w części dla zadań „nowych”).
  2. Product Owner sortuje zadania “nowe“.
  3. Zespół oszacowuje pewną liczbę zadań nowych (znajdujących się na szczycie backlogu w części dla zadań „nowych”).
  4. Jeśli są pytania, wątpliwości – następuje dyskusja z Product Ownerem. Czasem potrzebuje on zwrócić się do interesariuszy by wyjaśnić pewne kwestie, czasem zadanie trzeba rozbić na mniejsze lub zmienić na bardziej zrozumiałe, precyzyjniej określone.
  5. Zespół oszacowuje zadanie, jest ono oznaczanie jako „gotowe” i przenoszone do właściwego backlogu.

Oczywiście, można sobie wyobrazić więcej kroków prowadzących od „nowe” do „gotowe” zależnie od potrzeb danej organizacji czy projektu. Przykładowo, może istnieć publiczny backlog (tzw. lodówka – ang. „cooler”), gdzie każdy w organizacji może zgłaszać pomysły. Z „lodówki” Product Owner wybiera zadania i przenosi do backlogu dla zadań „nowych”, skąd po wyjaśnieniu i oszacowaniu trafiają na backlog „gotowe”.

W każdym przypadku zaleca się, aby status „gotowe” miało przynajmniej tyle zadań, by przy średniej prędkości (ang. velocity) zespołu wystarczyło ich na około 2 sprinty pracy. Dzięki temu nawet kiedy wystąpi jakieś spowolnienie w „dostawach” nowych zadań zespół będzie w stanie przepracować kolejny sprint robiąc coś sensownego i wartościowego.

Warto zauważyć, że o ile kryterium ukończenia w dużym stopniu wynika z konkretnych uwarunkowań projektu (np. inne będzie dla zespołu pracującego nad aplikacją desktopową, inne dla pracującego nad aplikacjami webowymi) i powinno być określane przy dużym udziale Product Ownera (jeśli nie wprost przez niego), tak kryterium gotowości bardziej zależy od wymagań konkretnego zespołu i powinno być przez ów zespół określane. Ponadto, o ile kryterium ukończenia może się zmieniać w czasie (np. z chwilą przejścia od fazy budowy wewnętrznego prototypu do fazy, w której wyniki pracy trafiają na serwer produkcyjny), o tyle kryterium gotowości jest stabilne.

Ze swojej praktyki mogę dodać, że istotnie często zdarza się, że bałagan wprowadzany przez Product Ownera utrudnia osiągnięcie płynnego przepływu zadań przez zespół, a przez to osiągnięcie przezeń pełnej możliwej wydajności. Zgodnie z założeniami Scruma w każdej chwili można drastycznie zmienić kierunek prac, jednak kiedy zespół jest w kolejnym sprincie zaskakiwany zadaniami, których się nie spodziewał powoduje to spowolnienie jego pracy. Innymi słowy, zmiany kierunku – choć możliwe – kosztują. Dlatego w praktyce jest lepiej jeśli już w czasie bieżącego sprintu zespół wie jakie mniej-więcej zadania czekają go w następnym. Dużo lepsze efekty osiągnie się zatem, jeśli w czasie bieżącego sprintu zespół przeznaczy 5% czasu na wspólne z Product Ownerem oszacowanie i przygotowanie zadań na następne 1-2 sprinty.

Podsumowując, wprowadzenie kryterium gotowości ma na celu poprawę współpracy pomiędzy Product Ownerem (a więc za jego pośrednictwem także i innymi interesariuszami) a zespołem doprowadzając do utworzenia płynnego przepływu zadań (ang. flow) do zespołu. Ponieważ przy takiej organizacji pracy zespół z góry wie jakie zadania czekają go w następnym sprincie praca ma szansę przebiegać płynnie, a co za tym idzie jeszcze bardziej wydajnie. Dlatego właśnie warto poważnie rozważyć wprowadzenie tej praktyki.

Andrzej K. Brandt
Code Sprinters

Tagi: , , ,

Komentarze

Napisz co myślisz...
jeśli chcesz dodać Twoje zdjęcie do komentarza zdobądź gravatar!