Przyrost

Na zakończenie każdego Sprintu zespół dostarcza nową wersję rozwijanego produktu, w Scrumie nazywaną Przyrostem albo Inkrementem (ang. Increment). Przyrost ten musi być w stanie pozwalającym na jego użycie (wydanie). Innymi słowy Przyrost to nowa wersja produktu, która może być przekazana użytkownikom bez konieczności wykonania dodatkowych prac niezbędnych do doprowadzenia go do działania.

Przyrost jest potencjalnie używalny ponieważ nie ma obowiązku przekazania go do wykorzystania przez użytkowników – Product Owner może uznać, że ma on wciąż za mało wartości (zbyt ograniczoną funkcjonalność) i konieczny jest dalszy rozwój. Natomiast Przyrost ma być w stanie pozwalającym na takie użycie.

Każdy Przyrost powstaje poprzez modyfikację ostatniego Przyrostu, jaki powstał wcześniej – jest więc wynikiem jego inkrementalnego (przyrostowego) rozwoju – stąd też bierze się nazwa tego artefaktu w Srumie. Przyrost jest zarazem nową wersją produktu, przy czym Przyrost nie jest tożsamy z produktem, ponieważ produkt istnieje długo i jest zmienny w czasie (poddawany jest modyfikacjom). Natomiast Przyrost, gdy już powstanie, jest niezmienny – jego dalsza modyfikacja i doprowadzenie ponownie do stanu, w którym nadaje się on do użycia, prowadzi do powstania kolejnego Przyrostu.

Stąd wniosek, że w każdym momencie jednocześnie może istnieć tylko jeden Przyrost związany z jakimś produktem – najnowszy, jaki powstał. Oczywiście można sięgnąć i zdecydować o użyciu Przyrostu, który powstał wcześniej, natomiast nie mogą w tym samym momencie powstać dwa różne Przyrosty tego samego produktu. Jeśli więc nad rozwojem produktu pracuje więcej niż jeden Zespół Scrumowy, konieczne jest zapewnienie, że:

• istnieje jeden Backlog Produktu,
• zarządzany jest on przez jednego Product Ownera (wspólnego dla wszystkich tych Zespołów Scrum),
• wszystkie Zespoły pracują nad jednym Celem Produktu, choć mogą w swoich Sprintach uzgodnić z Product Ownerem różne Cele Sprintów,
• do powstania Przyrostu niezbędne jest zintegrowanie efektów prac wszystkich Zespołów Scrum,
• Przegląd Sprintu jest wspólnym zdarzeniem, w którym uczestniczą wszystkie Zespoły Scrum.

W czasie Sprintu może powstać cały szereg Przyrostów, Scrum nie ogranicza tej możliwości ani nie wymaga, by Przyrost powstał jedynie raz, na koniec iteracji. Jest wręcz odwrotnie: praca zespołowa Developerów powinna skutkować realizacją poszczególnych wymagań sekwencyjnie (jedno po drugim), a jej efektem powinna być seria Przyrostów, każdy będący rozwinięciem poprzedniego.

Przyrost w Scrumie jest artefaktem niezbędnym do zapewnienia przejrzystości stanu produktu na koniec każdego Sprintu. Dzięki temu, że Zespół Scrum dostarcza interesariuszom działający produkt, którego da się użyć, staje się możliwe określenie, jaką ona ma wartość, a czego w nim brakuje. Eliminuje to znany z klasycznym metod problem, gdy postęp prac mierzony w procentach realizacji planów ciągle rośnie mimo, iż realnie nic nie jest ukończone.

Definicja Ukończenia

W Scrumie z Przyrostem związane jest zobowiązanie (ang. commitment) – Definicja Ukończenia (ang. Definition of Done). Określa ona kryteria, jakie spełnić musi nowa wersja produktu, by można było uznać go za Przyrost. Inaczej mówiąc Przyrost powstaje za każdym razem, gdy spełnione zostaną warunki opisane Definicją Ukończenia.

Definicja Ukończenia powinna określać, jaki produkt uznawany jest za nadający się do użycia – ale nie określa, czy to taki produkt, jakiego oczekują użytkownicy lub interesariusze. Jest to więc zbiór kryteriów związanych z jakością strukturalną produktu, odnoszących się do tego, jak on został zrobiony. Definicja Ukończenia nie jest natomiast listą kryteriów akceptacji i nie odnosi się w związku z tym do jakości funkcjonalnej ani wartości produktu.

Wynika z tego wniosek, że Definicja Ukończenia jest co do zasady stała dla produktu, o ile Zespół Scrum nie podejmie decyzji o świadomej zmianie jakości rozwiązania (przypominam: jakości strukturalnej, czyli tego jak produkt jest zrobiony). Definicja może również zmienić się, jeśli przedefiniowaniu ulegnie sam produkt, przez co zmienią się warunki, jakie musi spełniać, by w ogóle można uznać go za ukończony.

Jeśli wiele Zespołów Scrum rozwija jeden produkt, muszą one mieć wspólną Definicję Ukończenia, której nieusuwalną częścią musi być wymóg integracji produktu w jedną całość. Jest dopuszczalne, by jeden z takich Zespołów rozszerzył wspólną Definicję na swoje potrzeby (np. o jakieś działanie, które ułatwia mu organizację pracy w Sprincie) – nie może jednak być to zmiana prowadząca do niezgodności z Definicją stosowaną przez pozostałe Zespoły.

W jaki sposób powstaje Definicja Ukończenia dla produktu

• Product Owner przynosi kontekst użycia produktu: czym on jest, przez kogo będzie używany, w jaki sposób. Z analizy tego kontekstu wynika lista cech produktu, które są niezbędne, aby produkt mógł być użyty.
  • Konieczność nadania produktowi tych cech oraz sprawdzenia, że istotnie je uzyskał, określi działania Developerów, jakie w związku z tym trzeba wykonać.
  • Przykładem takiego kontekstu jest informacja, że produkt będzie używany przez osoby słabo widzące i niewidome, albo że jednocześnie będzie z niego korzystać kilka tysięcy użytkowników – aby takie wykorzystanie produktu było możliwe, trzeba zbudować go w określony sposób.
• Produkt budowany jest przez organizację, która może posługiwać się różnego rodzaju standardami i konwencjami, zapewniającymi np. spójność architektoniczną rozwiązań i ich stabilność. Standardy takie mogą również mieć formę wymogów prawnych, norm branżowych albo praktyk, które związane są z określoną technologią.
  • Z tego wynikać może konieczność zapewnienia produktowi kolejnych cech i wykonania określonych działań, przy czym mogą to być zarówno działania niezbędne do uzyskania wspomnianych cech, albo wprost wymagane przez standardy.
  • Może być też tak, że standardy i normy wymuszają zastosowanie specyficznego procesu w czasie budowania produktu.
  • Przykładem cechy, jaka może być wymagana, to zgodność urządzenia elektrycznego z normą określającą sposób zabezpieczenia przed porażeniem prądem.
  • Przykładem działania jest wymóg wytworzenia dokumentacji, bez której produkt nie może być dopuszczony do użycia, albo przejścia audytu dopuszczającego produkt do wykorzystania.
  • Przykładem wymogu procesowego jest nakaz regulatora rynku (np. KNF w Polsce), by działania związane z systemami informatycznymi używanymi przez klientów banku wykonywane były przez inne osoby niż Developerzy, którzy te systemy budują (tzw. segregation of duties).
• Efektywność w działaniu wymaga również, aby zaspokoić potrzeby Developerów, którzy bez użycia określonych praktyk i narzędzi (zależnych od technologii) mogą nie być w stanie nadać produktowi niezbędnych cech ani działać zgodnie ze standardami i konwencjami.
  • Z tego wynika konieczność zastosowania w określony sposób narzędzi, praktyk a być może konkretnego procesu.
  • Może też być niezbędne nadanie produktowi stosownych cech, które nie są niezbędne użytkownikom i interesariuszom, ale wspierają Developerów w działaniu.
  • Przykładem takiego użycia narzędzia, praktyki i jednocześnie procesu jest ustalenie zasad przeglądu kodu (ang. code review) przez Developerów wytwarzających oprogramowanie.
  • Przykładem działania jest ustalenie jakie testy są wymagane, w jakim zakresie, kto i kiedy powinien je wykonywać.
  • Przykładem funkcjonalności produktu, o którą należy zadbać, aby był on ukończony, jest wytworzenie dokumentacji developerskiej (służącej Developerom) albo zapewnienie dostępności mechanizmów, które są niezbędne do automatyzacji testów, monitorowania aplikacji.

Definicja Ukończenia jest połączeniem tych wszystkich potrzeb. Nie jest to „Definicja Developerów” ale całego Zespołu Scrum, przy czym to Developerzy muszą ostatecznie zdecydować, jakie zapisy znajdą się w Definicji. Skoro bowiem Definicja Ukończenia ma zapewnić przejrzystość stanu produktu (a więc określić co to znaczy, jak Zespół Scrum mówi, że coś jest ukończone), nie mogą w niej zostać zawarte warunki, których Developerzy nie będą w stanie spełnić.

Definicja Ukończenia a możliwości Developerów

Jeśli istnieje różnica między tym, jaka powinna być Definicja Ukończenia, aby produkt był w pełni ukończony, a co potrafią aktualnie Developerzy, można:

• Uzupełnić kompetencje w Zespole Scrum tak, by potrafił on spełnić Definicję Ukończenia opisującą produkt nadający się do użytku. Co oczywiste, praca w Sprintach i budowanie produktu z użyciem Scruma będzie mogło się rozpocząć dopiero wtedy, gdy taki Zespół powstanie.
• Uzgodnić Definicję Ukończenia obejmującą jedynie to, co Developerzy potrafią zrobić i w kolejnych Sprintach podnieść kompetencje w Zespole tak, by Definicję można było rozbudować. Oznacza to, że produkt nie będzie mógł być użyty dopóki Definicja Ukończenia nie zostanie odpowiednio rozszerzona, a praca związana z dostosowaniem produktu do wymogów takiej Definicji nie zostanie wykonana.
  • Dzięki temu zapewniona zostaje przejrzystość tego, co wciąż musi zostać zrobione, aby produktu użyć (często praca ta zostaje umieszczona w Backlogu Produktu w elementach, które zostaną zrealizowane po rozszerzeniu Definicji Ukończenia).
  • Jasne też stanie się nad rozwojem jakich kompetencji powinien Zespół Scrum pracować w ramach usprawnień w kolejnych Sprintach.

Niezgodnym ze Scrumem będzie natomiast takie działanie, że Definicja Ukończenia będzie opisywać to, co powinno być robione, ale w praktyce niektóre warunki będą pomijane. To spowoduje, że produkt, który przekazywany będzie użytkownikom, nie będzie miał ustalonego stanu (brak będzie przejrzystości), a rozwój produktu odbywał się będzie nie empirycznie, tylko w oparciu o założenia, że produkt będzie działał.

Sytuacja, gdy Definicja Ukończenia jest ograniczona w stosunku do tego, co niezbędne, aby produkt nadawał się do użytku, nie jest pożądana i nie powinna być długotrwała (trwać to może klika Sprintów, zdecydowanie nie miesiące ani lata). Powstaje wtedy produkt np. „gotowy do testów wydajnościowych”, ale same testy (niezbędne do użycia produktu) nie są na razie wykonywane. Co ważne, w takim przypadku powstaje Przyrost (bo Definicja Ukończenia jest spełniona), który jednakże nie może być realnie użyty.

Definicja Ukończenia a kryteria akceptacji

Wiele Zespołów Scrumowych myli Definicję Ukończenia z kryteriami akceptacji. Tworzenie takich kryteriów jest opcjonalną praktyką, której można użyć w Scrumie, ale robiąc tak nie zastępujemy nimi Definicji Ukończenia. Definicja Ukończenia dotyczy produktu jako całości (jak wyjaśniamy to powyżej). Kryteria akceptacji ustalane są oddzielnie dla każdego wymagania (elementu Backlogu Produktu), choć oczywiście nie mogą być sprzeczne z Definicją Ukończenia, bo wtedy realizacja wymagania wiodłaby do powstania produktu nienadającego się do użycia.

Jeśli Zespoły Scrum posługują się kryteriami akceptacji, nierzadko z rozpędu dodają wymóg ich spełnienia do swojej Definicji Ukończenia. Nie jest do dobra praktyka, ponieważ Definicja Ukończenia musi być spełniona najpierw, zanim w ogóle będzie możliwe sprawdzenie, czy zaspokojone zostały kryteria akceptacji. Nie da się bowiem powiedzieć, że zbudowany został produkt, który zaspokaja potrzeby użytkowników, jeśli jednocześnie nie nadaje się on do użycia (a więc w praktyce nie powstał). Taka Definicja jest więc niemożliwa do spełnienia.

Innym powodem, dla którego nie warto umieszczać wymogu spełnienia kryteriów akceptacji w Definicji Ukończenia jest fakt, że zmusza to Zespół Scrum do definiowania kryteriów również tam, gdzie nie ma to większej wartości, a co gorsza wywiera presję na Developerów, by przede wszystkim „zaspokoili kryteria akceptacji”. Tymczasem produkt, jeśli tylko nadaje się do użycia, może okazać się wartościowy dla użytkowników również wtedy, gdy – z uzasadnionych powodów – niektóre z kryteriów akceptacji nie zostały spełnione.

Scrum służy do rozwiązywania złożonych problemów, w przypadku których nie da się określić na pewno, jakie rozwiązanie będzie dobre – można to jedynie prognozować. Tym samym zarówno wymagania jak ich kryteria akceptacji są jedynie prognozą – hipotezą, że takie właśnie rozwiązanie okaże się najwłaściwsze. Sprinty służą potwierdzeniu tej hipotezy, a często w trakcie iteracji okazuje się ona błędna, co nie oznacza, że nie można zaproponować innego rozwiązania. Przegląd Sprintu służy właśnie do dyskusji o tym, a nie do rytualnego sprawdzenia, czy na pewno wszystkie kryteria akceptacji zostały spełnione. Dlatego lepiej, by wymogu ich spełnienia w Definicji Ukończenia nie było, bo to daje przestrzeń do zbudowania Przyrostu z okazjonalnym pominięciem niektórych z tych kryteriów.

Zapobieganie kumulacji długu technicznego

Definicja Ukończenia bywa określana jako narzędzie eliminacji długu technicznego w produkcie. Wiele Zespołów świadomie tak konstruuje swoje Definicje Ukończenia, by utrudniała ona zaciąganie długu technicznego (a więc budowaniu produktu w sposób, który powoli produkt ten degraduje od strony technicznej, coraz bardziej spowalniając dalszy rozwój). Natomiast żadna Definicja Ukończenia nie gwarantuje, że dług techniczny nie powstanie. Nie jest zresztą możliwe całkowite wyeliminowanie długu, ponieważ technologia nieustannie się zmienia i wraz z upływem czasu rozwiązania będące początkowo absolutnym majstersztykiem mogą stać się nieoptymalne.

Należy dążyć do tego, by Definicja Ukończenia utrudniała nieświadome zaciąganie długu, albo przynajmniej czyniła fakt jego zaciągnięcia widocznym. Nieświadome zaciągnięcie długu nie oznacza przy tym wyłącznie popełnienia błędu i braku zrozumienia konsekwencji podjęcia złych decyzji technicznych albo procesowych. Nieświadomym zaciągnięciem długu będzie również świadoma rezygnacja z działań, które powinny być wykonane, co może prowadzić do konsekwencji nie dających się w ogóle oszacować. Inaczej mówiąc chodzi o każdy sposób zaciągnięcia długu, który prowadzi do utraty przejrzystości stanu produktu.

Przykładem takiego działania jest np. odstąpienie od testowania – bez testów nie sposób powiedzieć, czy produkt będzie działał, czy nie, ani czy spełnia wymogi Definicji Ukończenia.

Co ważne, można dług techniczny zaciągnąć świadomie, np. podejmując decyzję o zbudowaniu nieoptymalnej architektury, która jednakże jest wykonana w pełni zgodnie z Definicją Ukończenia. Jest to działanie świadome, bo dokładnie wiadomo, jaki dług został zaciągnięty, wiadomo jak należy go spłacić (i jak kosztowne to będzie), a także jakie konsekwencje w produkcie dług ten spowoduje do czasu, zanim zostanie spłacony.

Zmiana Definicji Ukończenia

Definicja Ukończenia może być zmieniona gdy Zespół Scrum odkryje, że z jakiegoś powodu nie jest ona adekwatna – nie pozwala budować produktów nadających się do użycia. Może to wynikać z chęci podniesienia jakości produktu, doprecyzowania zapisu, ale może być skutkiem odkrycia luki w Definicji Ukończenia. Zdarza się też, że Definicja nie tyle jest zmieniana, co doprecyzowana tak, by jej zapisy były „binarne” – pozwalając jednoznacznie określić, czy są spełnione, czy nie. Jest to kluczowe, ponieważ brak pewności, że Definicja Ukończenia jest spełniona oznacza, że nie powstał Przyrost.

Zmiana Definicji Ukończenia nie powinna być dokonywana w czasie Sprintu, ponieważ na Planowaniu Sprintu prognoza tego, co możliwe, tworzona jest z założeniem stałości Definicji (w jej kontekście Developerzy oceniają, jakich zmian w produkcie zdołają dokonać w ciągu iteracji). Poza tym Definicja Ukończenia określa minimum jakościowe, więc Developerzy mogą zrobić więcej, niż wynikałoby to z Definicji, jeśli odkryją taką potrzebę, A sama Definicja zostanie rozszerzona na koniec Sprintu. Stosownym momentem na dokonanie zmiany jest więc Retrospekcja Sprintu.

Uaktualnienie Definicji Ukończenia najczęściej prowadzi do podniesienia wymogów jakościowych. To oznacza, że w kontekście tak rozszerzonej Definicji produkt, który powstał do tej pory, może okazać się niegotowy do użycia i w związku z tym należy wykonać pracę, aby doprowadzić go do stanu zgodności z Definicją. W jaki sposób zostanie zorganizowana taka praca, zależy od indywidualnej decyzji Zespołu Scrum; możliwe jest opisanie tych działań w dedykowanym elemencie Backlogu Produktu, ale lepiej po prostu uwzględnić tę pracę w czasie Planowania Sprintu – a więc dodać stosowne elementy do Backlogu Sprintu.

Okazjonalnie zdarza się, że Definicja Ukończenia jest zmieniana w sposób prowadzący do obniżenia wymogów jakościowych, jeśli okaże się, że powstaje produkt mocno przekraczający oczekiwania, ale przez to nadmiernie kosztowny. Tak długo jak po tej zmianie produkt wciąż będzie nadawał się do użycia, może być ona uzasadniona. Warto jednak pamiętać, że to nietypowa sytuacja, a ciągła presja na podnoszenie jakości rozwiązań może spowodować, że w przyszłości Definicję Ukończenie trzeba będzie i tak rozszerzyć, oczywiście ponosząc koszty dostosowania samego produktu.