Blog

Wiele zespołów Scrum próbuje mierzyć swoją dojrzałość poprzez analizę, jak zmieniało się ich velicoty na przestrzeni ostatnich kilkunastu, a często kilkudziesięciu Sprintów. Tymczasem velicoty 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. 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ć to w górę, to w dół, 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 planowania wydań. W pierwszym przypadku średnie velocity z ostatnich dziesięciu Sprintów pozwoli zespołowi określić ile wymagań może zaakceptować do realizacji bez nadmiernego ryzyka, że nie uda się ich dokończyć. Oczywiście w kalkulacji owego średniego velocity lepiej pominąć te Sprinty, w których nic nie udało się dostarczyć (takie się zdarzają nawet najlepszym zespołom).

Product Owner mając wyznaczoną datę wydania, może wykorzystać minimalne i maksymalne velicoty za ostatnich dziesięć Sprintów do oceny, co prawie na pewno powinno znaleźć się w planowanym wydaniu (tu przyda się wartość minimalna velocity), a co być może się „zmieści” (tu użyje wartości maksymalnej). A jeśli to nie data, tylko zakres zrealizowanych wymagań wyznacza, kiedy nastąpi wydanie produktu – również przy pomocy velocity da się określić orientacyjną najbardziej optymistyczną i najbardziej pesymistyczną datę.

Definition of Done

Jednym ze sposobów pozwalających na dobrą ocenę dojrzałości zespołu jest przyjrzenie się jego Definition of Done (DoD) i temu, jak zmieniało się ono w czasie. DoD opisuje listę działań, które Zespół Developerski musi wykonać w ramach pracy z wymaganiem, zanim stwierdzi, że to wymaganie jest w pełni zrealizowane i zintegrowane z produktem nadającym się do potencjalnego wydania. Obejmuje to zatem nie tylko napisanie kodu, ale też udokumentowanie produktu (jeśli to potrzebne), jego przetestowanie, zintegrowanie, postępowanie wedle określonych zasad z wykorzystaniem jasno zdefiniowanej listy narzędzi i technik.

Można powiedzieć, że DoD jest zapisem tego, co zespół potrafi robić w sposób powtarzalny i określa pewne minimum, poniżej którego nie może zejść, o ile nie chce doświadczyć regresu i spowodować spadku jakości produktu, który dostarcza. To zaś oznacza, że jak tylko zespół posiądzie jakąś nową umiejętność, powinien dodać ją do DoD. Jeśli organizacja developerska utrzymuje jedną wspólną Definicję, te bardziej dojrzałe zespoły śmiało mogą (i powinny!) ją rozszerzyć dla siebie o to, co potrafią ponad absolutne minimum zdefiniowane dla wszystkich.

Im zespół dojrzalszy, tym bardziej wymagające będzie DoD, jakie stosuje. Ta dojrzałość obejmuje też umiejętność poddawania inspekcji i adaptacji samej Definicji. Warto zauważyć, że w sytuacjach, w których velocity dramatycznie się zmienia z przyczyn niezależnych od zespołu, DoD najczęściej nie ulega zmianie – a przynajmniej nie od razu. Nowe umiejętności, praktyki, reguły postępowania (czyli usprawnienia procesu) dopisane zostaną do DoD, jeśli zespół uzna, że potrafi je stosować w sposób powtarzalny.

Kłopoty z DoD

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” DoD 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 to z DoD 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. Każdy nowy element 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ół rozpoczyna 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 DoD – bo te są niezbędne – developerzy muszą ocenić, co będą w stanie kontynuować, a gdzie niezbędne będzie określenie, w jakim kontekście element Definicji ma zastosowanie. I tak na przykład zamiast ogólnego wpisu 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. Jak tylko zespół nauczy się jak efektywnie automatyzować testy aplikacji natywnych na urządzenia mobilne, usunie to rozróżnienie.

DoD musi być żywe

Warunkiem rozwoju jest podnoszenie sobie – powoli, ale konsekwentnie – poprzeczki. Zespół może to robić przez dążenie do tego, by jego DoD opisywało 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.

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

Cóż, odpowiedź jest jedna: 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 „metryki”, z których najczęstszą jest velocity (cudzysłów zamierzony, bo velocity metryką nie jest, ale 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ć.