W drugim artykule w ramach krótkiego cyklu opisałem trzy perspektywy, jakie należy wziąć pod uwagę podczas sporządzania Definicji Ukończenia: perspektywę produktu, standardów i potrzeb Developerów. W tej części zajmę się tym, jak przekuć pozyskaną w ten sposób wiedzę w sensowną Definicję Ukończenia.

Definicja Ukończenia w praktyce

Czy może to być po prostu zapis wszystkich poczynionych wcześniej ustaleń w formie listy? Właściwie tak i istotnie, czasami Definicja ma taki kształt. Bardzo rzadko jednak okazuje się to być dobrą jej formą, bo z powodu ogromu warunków, które zawiera, ciężko zastosować ją w praktyce. W efekcie Definicja staje się bardzo szybko martwym zapisem na jakieś ścianie (jeśli Zespół pracuje w biurze) lub w jakimś dokumencie (jeśli Zespół pracuje zdalnie). A to nie ma sensu, bo oznaczać będzie, że Definicji de facto nie ma.

Zespół musi uzgodnić, jakie zapisy muszą się znaleźć w Definicji i jaką będą mieć formę, by nie było ich zbyt wiele, a jednocześnie by były jednoznaczne i obejmowały wszystko, co wynika z analizy każdej z omawianych przeze mnie perspektyw. Niemożliwe? Nie, całkiem wykonalne i w sumie proste.

Referencje do standardów i automatyzacja ich stosowania

Najłatwiej poradzić sobie ze standardami. Gdzieś już są przecież zdefiniowane (skoro obowiązują), można więc nawiązać do nich wprost, lub stworzyć ich listę i w Definicji wymagać, by wszystkie były spełnione. Rozbudowany zapis zostanie zredukowany do jednego punktu – odnośnika do standardu lub listy standardów.

Jeśli chodzi o standardy, bardzo często da się do pewnego stopnia zautomatyzować ich stosowanie, czyli wymusić je procesem lub użyciem konkretnych narzędzi. Zespół nie musi wtedy detalicznie opisywać ani wymieniać standardów w Definicji – wystarczy, że zawrze w niej wymóg posłużenia się wskazanym procesem, określoną praktyką albo narzędziem.

Posłużmy się przykładem Zespołu budującego sklep internetowy. Zamiast wypisywać wszystkie możliwe standardy, jakie ma spełniać oprogramowanie, a potem dodawać do tego listę czynności, jakie należy wykonać, aby potwierdzić zgodność oprogramowania z tymiż standardami, można na przykład:

  • zaimplementować automatyczne sprawdzenie tych standardów wprost w narzędziu, jakiego Developerzy używają do pisania kodu,
  • wymagać użycia narzędzi, które automatycznie walidują kod pod kątem zgodności ze standardami,
  • odpowiednio skonfigurować narzędzia testowe, by nie było konieczne ich manualne uruchamianie, dzięki czemu walidacja następować będzie automatycznie.

W takim reżimie pracy Developerów zrobienie czegoś niezgodnie ze standardami zostanie wykryte niemal natychmiast albo wręcz będzie niemożliwe.

Czy w związku z tym w Definicji Ukończenia będzie trzeba napisać literalnie, że ma być użyte takie i takie narzędzie do tego i tego? Nie, w samej Definicji wystarczy mocno zredukowany zapis, który odwołuje się do opisu standardowych praktyk wykorzystywanych w ramach organizacji. W razie wątpliwości, jak postąpić w określonej sytuacji, każdy Developer znajdzie szczegółowe wyjaśnienia nie tyle w Definicji Ukończenia, ile w miejscu przez tę Definicję wskazanym.

Generalizacja bez utraty precyzji

Kolejny mechanizm redukcji wielkości Definicji Ukończenia jest mniej oczywisty, ale również skuteczny: wiele klauzul z automatu obejmować będzie w sobie szereg innych, bez których ta nadrzędna nigdy nie będzie spełniona.

Na przykład niekoniecznie jest sens, by rozpisywać w Definicji wszystkie rodzaje testów, jakie należy wykonać, aby potwierdzić, że produkt został dobrze zbudowany. Definicja może wymagać, by wszystkie testy, jakie zostały zdefiniowane, zostały wykonane i by ich rezultat okazał się pozytywny. Detaliczna lista tego, jakie to mają być testy, może być umieszczona w innym miejscu albo wręcz zaszyta w procesie i narzędziach, jakim posługują się Developerzy.

Dopóki zapisy tej Definicji są dla Zespołu jednoznaczne i pozwalają mu na binarne stwierdzenie, czy jest spełniona, czy też nie, najprawdopodobniej Definicja ma dobrą formę. To, że czegoś w Definicji nie ma, nie oznacza, że nie wynika z innego zapisu, który w tej Definicji jest. Piszę najprawdopodobniej, ponieważ można w tym redukowaniu Definicji posunąć się zbyt daleko, pomijając zbyt wiele zapisów jako oczywiste, a więc niewymagające jawnego wskazania i utrwalenia. O ile ogromna Definicja byłaby błędem, o tyle przesadnie lakoniczna też będzie nieskuteczna.

Ktoś może zaprotestować, że to spowoduje rozluźnienie Definicji, której można będzie nie przestrzegać i że najlepiej byłoby mieć listę twardych warunków, bardzo klarownych, maksymalnie kompletną. Cóż, nie do końca się z tym zgodzę. Definicja jest przecież deklaracją intencji całego Zespołu Scrum, więc powinien on dążyć do jej stosowania nie ze względu na ten czy inny zapis, ale z racji dążenia do zbudowania dobrego produktu. Definicja Ukończenia ma to Zespołowi ułatwiać, a nie wymuszać działania, których bez niej nikt nie raczyłby podjąć.

Jeśli Developerzy nie mają zamiaru dbać o swój produkt, żadna Definicja, choćby superprecyzyjna, nie będzie skuteczna. Prawdę mówiąc, im bardziej będzie rozbudowana, tym częściej zdarzy się, że formalnie jest spełniona, a produkt nadal jest marny.

Dokonując redukcji zapisów w Definicji Ukończenia do rozsądnego i bezpiecznego minimum, pamiętać musimy o innych użytkownikach Definicji, w szczególności o interesariuszach. Nie muszą oni zrozumieć każdego zapisu, ale powinni móc go zrozumieć, jeśli zechcą.

Jeśli więc redukujemy zapisy w Definicji, którą się posługujemy, dobrą praktyką jest zachowanie referencji do niezredukowanej listy wszystkiego, co kryje się pod uproszczonymi zapisami. Sam Zespół będzie czasami do tego sięgał, czy to przy dyskusji o zmianach w Definicji, czy podczas wprowadzania do Zespołu nowej osoby albo po prostu w sytuacji, gdy pojawi się wątpliwość, czy faktycznie Definicja została w jakiś konkretnym przypadku spełniona.

Ostateczna decyzyjność przy ustalaniu Definicji Ukończenia

Ponieważ do zaspokojenia warunków zawartych w Definicji Ukończenia doprowadzić muszą Developerzy, to mimo iż Definicja jako taka jest zobowiązaniem całego Zespołu Scrum, Developerzy zawsze mają ostatnie zdanie odnośnie do jej formy i zawartości. Nie może Product Owner lub Scrum Master wymusić dodania do Definicji czegoś, czego Developerzy nie chcą w niej mieć. Dlaczego?

Oczywista odpowiedź może być taka: jeśli Developerzy nie potrafią czegoś zrobić, to i tak tego nie zrobią, więc dopisanie takiego wymogu jest bezskuteczne. W najlepszym razie nie uda się wytworzyć produktu odpowiadającego wymogom takiej Definicji i ten fakt wywoła jakąś refleksję w Zespole, który nie potrafił się dogadać i zadziałać bardziej pragmatycznie. W najgorszym przypadku produkt nie będzie spełniał deklarowanych standardów, a mimo to zostanie uznany za nadający się do użytku, przez co zapis dodany do Definicji Ukończenia wbrew woli Developerom stanie się martwy.

Jeśli faktycznie to, co Product Owner albo Scrum Master chcą dodać do Definicji, jest potrzebne, ale Developerzy nie mogą tego zawrzeć w Definicji Ukończenia, cały Zespół (choć pewnie zwłaszcza Developerzy) muszą dążyć do tego, by jak najszybciej Definicję rozszerzyć. W ten sposób wszystkie zapisy, które stanowiły punkt sporny i ostatecznie nie znalazły się w Definicji, będą listą tego, czego pilnie trzeba się nauczyć, by móc Definicję udoskonalić i zapisy te w niej uwzględnić.

Mniej oczywista odpowiedź jest taka: to Developerzy odpowiadają za wytworzenie Przyrostu, a jest nim tylko to, co spełnia Definicję Ukończenia. Nie może być więc tak, że ktoś brałby na siebie odpowiedzialność za coś, na co nie ma wpływu i z czym się nie zgadza.

Z reguły Zespołom udaje się bez trudu dogadać, jaka będzie obowiązywać Definicja Ukończenia. Jeśli pojawia się problem, Scrum Master ma zadbać o to, by ani Product Owner, ani nikt inny nie narzucił Developerom Definicji Ukończenia. Jednocześnie ma pomóc w ustaleniu takiej Definicji, która maksymalizuje jakość produktu, jaki będzie powstawał. Inaczej mówiąc, Developerzy nie powinni usuwać sensownych zapisów z Definicji bez naprawdę dobrego powodu.

A co w sytuacji, gdy Developerzy uprą się na zapisy, które przekraczają oczekiwania Product Ownera, organizacji i interesariuszy odnośnie do jakości produktu? Gdy próbują budować doskonały, ale nieracjonalnie drogi produkt, którego wytwarzanie potrwa wieki i będzie absolutnie nieopłacalne? Nadal nie można Developerów zmusić do zmiany Definicji Ukończenia, natomiast jej nadmiarowość uczyni boleśnie widocznym fakt, że ten Zespół (z tymi Developerami i taką Definicją) nie jest właściwy do budowania tego konkretnego produktu. Albo więc trzeba znaleźć inny Zespół do wykonania pracy, albo Developerzy muszą zracjonalizować Definicję.

Przy czym istotne jest to, że zgoda Developerów na zmianę Definicji musi być faktyczna, a nie pozorna. Bo przecież mogą oni zgodzić się na usunięcie niektórych zapisów, a potem i tak pracować tak, jakby one nadal obowiązywały. Scrum Master odpowiada za spowodowanie, by do takiej sytuacji nie doszło.

Tu warto wspomnieć, że Definicja Ukończenia określa faktyczne minima jakościowe i nie zabrania Developerom zrobienia czegoś ponad nie. Zazwyczaj zrobienie więcej, niż to minimum, ma sens i jest pożądane. No, chyba że znajdziemy się w skrajnej sytuacji, jak opisana powyżej – wtedy byłoby to szkodliwe dla organizacji. Scrum Master ma dbać o skuteczność (ang. effectiveness) Zespołu Scrum, której ciężko dopatrywać się w budowaniu produktu zbyt kosztownego w stosunku do możliwości i potrzeb.

Kiedy musi powstać Definicja Ukończenia?

Jedyna możliwa odpowiedź brzmi tak: zanim rozpocznie się pierwszy Sprint, Definicja Ukończenia już musi być ustalona. W jej kontekście odbywać się będzie pierwsze Planowanie Sprintu, na jej podstawie Zespół prognozował będzie, co w jego ocenie możliwe jest do osiągnięcia przed końcem iteracji. Gdyby Definicji Ukończenia nie było, nie da się dokonać takiej oceny. Bo skoro nie jest jasne, co właściwie trzeba zrobić, ani co to znaczy zrobione, nie wiadomo, co jest możliwe do wytworzenia w ciągu krótkiego Sprintu.

Wiele Zespołów tak niestety działa, czyli nie ma Definicji Ukończenia, a przeprowadziło już kilka albo kilkanaście „Sprintów” (cudzysłów celowy), ale niewiele ma to wspólnego ze Scrumem. Definicja Ukończenia, jakaś jej pierwsza wersja, musi istnieć przed rozpoczęciem pracy w Sprintach. Oczywiście z czasem ta pierwsza Definicja zostanie empirycznie (bo jakże by inaczej!) udoskonalona – rozbudowana, uzupełniona, doprecyzowana itd.

Z drugiej strony nie oznacza to, że można stworzyć pierwszą Definicję Ukończenia na odczepnego, żeby „zacząć z czymkolwiek” i móc twierdzić, że „to Scrum, bo mamy Definicję Ukończenia”. Przypominam, że Definicja jest zobowiązaniem Zespołu do budowania produktu o określonej minimalnej jakości, a takie podejście do jej stworzenia oznaczałoby, że Zespół nie czuje się do niczego zobowiązany i bawi się w formalne zaspokojenie zapisów w Scrum Guide. Znów: to, że wygląda to na pierwszy rzut oka jak Scrum, nie oznacza wcale, że to jest Scrum.

Ważne jest też, że od samego początku Definicja Ukończenia powinna zapewniać przejrzystość odnośnie do tego, co jest zrobione. Dlatego, jeśli w wyniku dyskusji o tym, jaka powinna być Definicja, powstanie lista, z której Zespół może realnie spełnić tylko połowę rzeczy, jego Definicja powinna obejmować tylko tę połowę rzeczy. Druga połowa zostanie dodana do Definicji dopiero wtedy, gdy Zespół będzie w stanie taką Definicję spełnić. Jeśli powoduje to, że produkt na razie nie może być realnie używany, to przynajmniej jest ten fakt boleśnie widoczny i nikt nie ma złudzeń, że jest inaczej (istnieje pełna przejrzystość stanu spraw).

Kiedy można zmienić Definicję Ukończenia?

Właściwym do tego zdarzeniem w Scrumie jest Retrospekcja Sprintu, ponieważ to w czasie tego spotkania Zespół Scrum zastanawia się nad sposobem, w jaki buduje produkt. Istotny wpływ na to ma właśnie Definicja Ukończenia, dlatego należy regularnie poddawać ją sprawdzeniu i ocenie, czy nie wymaga udoskonalenia, doprecyzowania, zmiany, uproszczenia itd. A jeśli tak, należy takiego dostosowania dokonać.

Częstym błędem niedoświadczonych Zespołów jest ustalanie w czasie Planowania Sprintu, jaka ma być „Definicja Ukończenia na ten Sprint”. To nieporozumienie, niemające wiele związku ze Scrumem. Robiąc tak, Zespół zaczyna dopasowywać poziom jakości do tego, co akurat ma do zrobienia w bieżącej iteracji. Bardzo szybko okaże się, że jakość spada, bo ważne jest zwiększenie tempa prac i dowiezienie tego, co zostało zaplanowane. Tymczasem Definicja Ukończenia ma być gwarantem minimalnego poziomu jakości, jaki Zespół niejako gwarantuje – zobowiązuje się (stąd nazwa: zobowiązanie) go uzyskać i utrzymywać w sposób stały.

Poza tym Planowanie Sprintu służy, jak sama nazwa wskazuje, planowaniu tego, co zrealizowane zostanie w Sprincie w kontekście obowiązującej Definicji Ukończenia, a nie ustalaniu samej Definicji.

Czy można zmienić Definicję w czasie Sprintu? Nie ma takiego zakazu, ale to wyjątkowo nielogiczne i spowodować może spore problemy. Zdecydowanie należy z tym poczekać do Retrospekcji Sprintu. Dlaczego? Rozważmy trzy scenariusze.

Pierwszy: Developerzy chcą podnieść jakość produktu, który budują. To chwalebne, ale nie wymaga przecież natychmiastowego zmienienia Definicji. Ona określa minima jakościowe, nie zabraniając przy tym zrobienia czegoś więcej. Jeśli Developerzy uznają za zasadne zrobienie czegoś, co wymagane nie jest, mogą to zrobić. A na koniec Sprintu, w trakcie Retrospekcji, na spokojnie mogą ocenić, czy takie działanie faktycznie powinno stać się czymś obowiązkowym od kolejnej iteracji.

Drugi scenariusz: Developerzy chcą doprecyzować zapisy w Definicji Ukończenia, które okazały się niejasne. Podobnie, jak wcześniej, nie wymaga to natychmiastowej zmiany. W tak krótkiej perspektywie czasowej, jaką jest pojedynczy Sprint, pracujący blisko ze sobą ludzie są w stanie zapamiętać ustalenia z przeprowadzonej dopiero co dyskusji. Zdecydowanie warto zapisać propozycję zmian i się ich trzymać, ale formalnej zmiany Definicji dokonać na spokojnie, w czasie Retrospekcji. Pozwoli to uniknąć pochopnego podjęcia złych decyzji, poza tym dyskusja może wymagać czasu, a niewykluczone, że w Sprincie pojawią się kolejne propozycje zmian w Definicji, więc lepiej zrobić wszystkie za jednym zamachem.

Trzeci scenariusz: Developerzy chcą coś usunąć z Definicji. Cóż, to marny pomysł. Sprint był planowany w kontekście jakiejś Definicji, dlatego powinien być zgodnie z nią realizowany. Jeśli Developerzy będą mogli zmieniać zasady gry w trakcie gry, może okazać się, że aby zdążyć przed końcem iteracji, usuną coś z Definicji tylko po to, by kupić sobie nieco czasu. A potem, gdy już Sprint zakończy się „sukcesem”, usunięty zapis doda się w ramach „udoskonalania” Definicji. Nie ma to nic wspólnego z Definicją rozumianą jako zobowiązaniem Zespołu i dbaniem o jakość. Co więcej, może doprowadzić do traktowania wszystkich zapisów jako coś opcjonalnego, do zastosowania „gdy mamy na to czas”.

Inaczej mówiąc, jeśli to nieuniknione, Zespół powinien zrealizować mniej zmian w produkcie, ale w pełni ukończyć pracę nad nimi i dostarczyć produkt, który zachowuje jakość wymaganą przez interesariuszy. Definicja Ukończenia ma utrudnić Zespołowi wybór innej strategii, polegającej na realizowaniu zmian w produkcie byle jak, byle tylko było ich jak najwięcej, choćby kosztem jakości.

Nawet jeśli nie ma takich negatywnych intencji wśród Developerów, podejmowanie istotnych decyzji (zmiana Definicji Ukończenia zdecydowanie jest taką!) w biegu, w czasie Sprintu, gdy trwa intensywna praca developerska, to nierozsądny pomysł. Pośpiech i nawał pracy nie sprzyjają merytorycznej dyskusji, mogą prowadzić do rozmycia Definicji, spadku jej jednoznaczności itd. Lepiej poczekać do Retrospekcji Sprintu i porozmawiać na spokojnie, a zmienionej Definicji użyć od kolejnej iteracji.

Ciąg dalszy nastąpi

W czwartej części cyklu pochylam się nad nieco rzadziej pojawiającymi się pytaniami i wątpliwościami odnośnie do sposobu określania Definicji Ukończenia i jej stosowania w Scrumie.