Blog

Wiele Zespołów Scrum próbuje mierzyć swoją dojrzałość poprzez analizę, jak zmieniało się ich velocity na przestrzeni ostatnich kilkunastu, a często kilkudziesięciu Sprintów. Tymczasem velocity potrafi zmieniać się z przyczyn zupełnie niezależnych od Zespołu i jego dojrzałości. Zmiana technologii, w której wytwarzany jest produkt, może na tyle ułatwić development, że nagle uda się dostarczać o wiele więcej w tym samym czasie. Rozpoczęcie pracy z nowym produktem (a więc i nowym Backlogiem Produktu) na pewno spowoduje spadek velocity na jakiś czas. Wpływ na velocity będzie też miało pojawienie się dobrego narzędzia, które ułatwi testowanie, uproszczenie lub skomplikowanie reguł biznesowych na skutek decyzji regulatora i zmian w prawie, zwiększenie liczby Zespołów pracujących nad jednym Backlogiem… Powody, dla których velocity będzie się zmieniać, jest mnóstwo.

Do czego użyć velocity

Tak naprawdę velocity nadaje się tylko do dwóch sensownych działań: do planowania Sprintów i prognozowania potencjalnych dat ukończenia elementów Backlogu Produktu.

Średnie velocity z ostatnich Sprintów podpowie Developerom, ile wymagań mogą zaakceptować do realizacji bez nadmiernego ryzyka, że nie uda się ich dokończyć. Rzecz jasna Developerzy wcale nie muszą z tej podpowiedzi skorzystać, ani nawet wyliczać swego velocity. Jeśli już to robią, do kalkulacji wartości średniej powinni pominąć Sprinty w jakikolwiek sposób nietypowe, np. krótsze ze względu na dni świąteczne, albo takie, w których nic nie udało się dostarczyć – o ile faktycznie taka sytuacja zdarza się bardzo sporadycznie.

Product Owner może wykorzystać wiedzę o minimalnym i maksymalnym velocity za ostatnich kilka lub kilkanaście Sprintów do sporządzenia prognoz potencjalnych dat realizacji poszczególnych elementów Backlogu Produktu. Prognoza przyszłych Sprintów będzie szczególnie przydatna, gdy Product Owner posłuży się nie tyle średnią wartością velocity, ile jej uśrednioną wartością maksymalną (np. średnią z trzech najlepszych Sprintów) oraz minimalną (np. średnią z trzech Sprintów zdecydowanie najsłabszych).

Rozziew pomiędzy prognozą pesymistyczną (z użyciem velocity minimalnego) i optymistyczną (z użyciem maksymalnego velocity) jest niemal nieunikniony i będzie tym większy, im dalej w przyszłość sięgają prognozy. Im bardziej prognozy te różnią się od siebie, tym mniej prawdopodobne jest potwierdzenie się przewidywanych przez Product Ownera dat realizacji.

Definition of Done

Jednym ze sposobów pozwalających na dobrą ocenę dojrzałości Zespołu jest przyjrzenie się jego Definicji Ukończenia (ang. Definition of Done) i temu, jak zmieniało się ono w czasie. Definicja opisuje listę działań, które Developerzy muszą wykonać, zanim stwierdzą, że prace nad modyfikacją produktu zostały ukończone, a sam produkt nadaje się do użycia. Obejmuje to zatem nie tylko np. napisanie kodu (gdy produktem jest oprogramowanie), ale też udokumentowanie tego kodu (jeśli to potrzebne), jego przetestowanie, zintegrowanie i postępowanie wedle określonych zasad z wykorzystaniem jasno zdefiniowanej listy narzędzi i technik.

Można powiedzieć, że Definicja Ukończenia jest zapisem tego, co Developerzy potrafią robić w sposób powtarzalny i określa pewne minimum, poniżej którego nie mogą zejść, o ile nie chcą doprowadzić do regresu i spowodować spadku jakości produktu, który dostarczają. To zaś oznacza, że gdy tylko Developerzy posiądą jakąś nową umiejętność, która istotnie wpływa na jakość budowanego produktu, powinni dodać wymóg jej stosowania do Definicji Ukończenia.

Jeśli organizacja developerska utrzymuje jedną wspólną Definicję, te bardziej dojrzałe Zespoły śmiało mogą (i powinny!) rozszerzyć ją dla siebie o to, co potrafią ponad absolutne minimum zdefiniowane dla wszystkich. Im Zespół dojrzalszy, tym bardziej wymagająca będzie Definicja Ukończenia, jaką stosuje, a dojrzałość ta obejmuje też umiejętność poddawania inspekcji i adaptacji samej Definicji.

Kłopoty z Definicją Ukończenia

Czasami zdarza się tak, że Zespół przerzucony zostaje do pracy z produktem i technologią, których w ogóle nie zna. Wydawać by się mogło, że to oznacza reset Definicji Ukończenia do poziomu odzwierciedlającego faktyczne możliwości Developerów względem wymagań i produktu, z którym teraz mają do czynienia. A skoro tak, jak użyć Definicji do oceny dojrzałości Zespołu po takim dramatycznym jej uproszczeniu?

W rzeczywistości niczego nie trzeba upraszczać. Zespół przecież wciąż potrafi to, czego nauczył się już wcześniej. Nie ma zatem powodu, by coś z Definicji Ukończenia usuwać, trzeba jedynie jasno określić, do czego te umiejętności się odnoszą. A wszystko, co wymaga uczenia się od nowa, będzie de facto rozszerzeniem Definicji, gdy już Zespół się tego nauczy. Każdy nowy element Definicji dodany w ten sposób stanowi przejaw rozwoju Zespołu.

Weźmy na przykład Zespół, który zajmował się do tej pory utrzymywaniem systemów z webowymi interfejsami użytkownika. Developerzy potrafili w pełni zautomatyzować testy, dokonywać automatycznych wydań na środowiska testowe i produkcyjne, stosowali praktyki takie jak CI i CD, efektywnie korzystali z TDD, BDD czy Specification by Example.

A potem ten sam Zespół rozpoczął pracę z aplikacjami natywnymi na urządzenia mobilne, w zupełnie nowej technologii (język programowania, platforma etc.) i w zupełnie nowym obszarze biznesowym. Części swoich praktyk nie będzie w stanie zastosować w taki sposób, jak robił to uprzednio, części w ogóle będzie uczył się na nowo (na przykład testowania automatycznego).

Dokonując zmian w Definicji Ukończenia – bo te są niezbędne – Developerzy muszą ocenić, co będą w stanie kontynuować, a gdzie niezbędne będzie określenie, w jakim wymiarze element Definicji ma zastosowanie. I tak na przykład, zamiast ogólnego zapisu o konieczności pełnej automatyzacji testów funkcjonalnych interfejsu użytkownika, pojawi się informacja, że jest to wymagane dla aplikacji webowych, natomiast dla aplikacji mobilnych Zespół (na razie) automatyzował będzie tylko krytyczne pozytywne ścieżki, uzupełniając to testowaniem manualnym. Gdy tylko Developerzy nauczą się jak efektywnie automatyzować testy aplikacji natywnych na urządzenia mobilne, usuną to rozróżnienie.

Definition of Done musi być żywe

Warunkiem rozwoju jest podnoszenie sobie – powoli, ale konsekwentnie – poprzeczki. Zespół może to robić przez dążenie do tego, by jego Definicja Ukończenia opisywała coraz bardziej zaawansowane i dojrzałe praktyki. W istocie, o ile Zespół potrafi działać empirycznie, Definicja jest żywym artefaktem, poddawanym ciągłym usprawnieniom. Choć oczywiście nie jest artefaktem w rozumieniu Scruma, jest bowiem cechą związaną z innym artefaktem w tej metodzie – Przyrostem (ang. Increment).

Kto powinien oceniać dojrzałość Zespołów?

Przede wszystkim one same. Oczywiście żaden Zespół nie funkcjonuje w próżni, zatem jacyś kierownicy przyglądają się, co robią ich podwładni i szukają sposobów oceny, kto pracuje dobrze a kto niekoniecznie. To osobny temat.

Natomiast trzeba wyraźnie podkreślić, że niedojrzałość w Scrumie nie musi oznaczać, że Zespół pracuje źle. Niestety, wszelkiej maści kierownicy mają ciągoty do porównywania ludzi i Zespołów poprzez łatwo dostępne „miary”, z których najczęstszą jest velocity (cudzysłów zamierzony, bo velocity miarą efektywności ani dojrzałości nie jest, mimo że często jest tak traktowana). Tymczasem bardziej istotna jest umiejętność rozwoju niż bycie już, tu i teraz, w pełni dojrzałym.

Zespół, który na razie potyka się o własne nogi, ale powoli wypracowuje własną drogę do rozwoju, może w dłuższej perspektywie okazać się bardziej efektywny i wartościowy dla organizacji niż ten, który od początku sobie świetnie radził, ale w ogóle się nie rozwija. W szczególności ten pierwszy Zespół, przerzucony do nowego obszaru (technologii, biznesu), poradzi sobie bez trudu; ten drugi może nie potrafić dostosować się do drastycznej zmiany warunków, w jakich funkcjonuje. Warto o tym pamiętać.