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

Jak wygląda 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 taką formę. Bardzo rzadko jednak okazuje się to być dobrą jej formą, bo przez ogrom warunków ciężko zastosować je 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 po nawiązać do nich wprost, lub stworzyć ich listę i w Definicji wymagać, by wszystkie były spełnione. Rozbudowany zapis zostanie zredukowany w ten sposób 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 stosowanymi narzędziami. Jeśli Zespół tak zrobi, nie będzie musiał detalicznie opisywać ich w Definicji, zamiast tego po prostu będzie wymagał wykonania jakiegoś procesu lub posłużenia się 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 przyład:

  • „zaszyć” 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 manualne uruchamianie walidacji i testów.

W ten sposób 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. Powinien on oczywiście referować do jakiegoś szerokiego opisu praktyk i narzędzi, do którego może w dowolnym momencie sięgnąć każdy Developer, jeśli ma wątpliwości, jak je stosować i co powinno zostać zrobione.

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 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 to z innego zapisu, który w tej Definicji jest. Piszę „najprawdopodobniej”, ponieważ można w tym redukowaniu Definicji posunąć się zbyt daleko, pozostawiając zbyt wiele zapisów jako coś „domyślnego, niewymagającego zapisania”. O ile więc 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óra będzie mogła nie być przestrzegana, 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 zobowiązaniem całego Zespołu Scrum, więc powinien on mieć intencję jej spełnienia. Jeśli jedynym Developerzy nie będą dbać o to, by budować dobry produkt, żadna Definicja, choćby superprecyzyjna, nie zmusi ich do tego. 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 tego, 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ść co do Definicji Ukończenia

Ponieważ do spełnienia Definicji Ukończenia doprowadzić muszą Developerzy, to choć Definicja jako taka jest zobowiązaniem całego Zespołu Scrum, Developerzy zawsze mają ostatnie zdanie co 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ą, dopisanie takiego wymogu jest więc bez sensu. Definicja nie stanie się „spełnialna” tylko dlatego, że ktoś coś do niej dopisze.

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 zapis lub zapisy, które stanowiły punkt sporny, ale ostatecznie nie znalazły się w Definicji, będą wskazówką, 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ś, z czym się nie zgadza, że jest potrzebne.

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ł na siłę 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 „bo tak”, tylko muszą mieć do tego dobry powód.

A co w sytuacji, gdy Developerzy uprą się na zapisy, które przekraczają oczekiwania Product Ownera, organizacji i interesariuszy co do jakości produktu? Gdy próbują budować doskonały, ale nieracjonalnie drogi produkt, którego wytwarzanie będzie trwać 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 tej 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 jakiegoś zapisu lub zapisów, a potem i tak pracować tak, jakby one nadal obowiązywały, „robiąc swoje”. Scrum Master odpowiada za to, 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 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 bazie 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 w ciągu krótkiego Sprintu.

To, że 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), nie znaczy, że to ma cokolwiek wspólnego ze Scrumem. Definicja Ukończenia, jakaś jej pierwsza wersja, musi istnieć przed rozpoczęciem pracy w Scrumie. 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ć tę 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 to zobowiązanie Zespołu, a takie podejście do jej stworzenia oznaczałoby, że Zespół nie czuje się do niczego zobowiązany, bawi się jedynie 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 (mamy 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 poddać ją sprawdzeniu i ocenie, czy nie wymaga ona 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 czasie 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 odbytej 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ąć 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”.

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ą dyskusji, może 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 pochylam się nad nieco rzadziej pojawiającymi się pytaniami i wątpliwościami co do sposobu określania Definicji Ukończenia i jej stosowania w Scrumie.