obrazek cegieł, jako metafora przyrostów

Dlaczego istotnym elementem Scruma jest Przyrost?

Przyrost jest kawałkiem Produktu dostarczanym przez Zespół Scrumowy w trakcie Sprintu. Jest artefaktem formalnie wpisanym we framework Scrum. Wdrożony na środowisko produkcyjne jest w stanie przynieść użytkownikom i biznesowi wartość. Takie inkrementalne podejście do tworzenia produktu jest istotą empiryzmu metod zwinnych.

Co o Przyroście mówi Scrum guide?

„Przewodnik po Scrumie” [1] określa Increment (pol. Przyrost) jako jeden z trzech artefaktów zdefiniowanych w Scrumie. Każdy Przyrost powinien być krokiem w kierunku osiągnięcia Celu Produktu (o tym czym jest Cel Produktu i jak go definiować pisałam w tym artykule).

Każdy kolejny Przyrost rozbudowuje poprzednie. Przyrostem możemy zatem nazwać sumę poprzednich Przyrostów oraz elementów Product Backlogu, które zostały zrealizowane w danym Sprincie i spełniają Definicję Ukończenia.

Aby dostarczać wartość Przyrost musi być używalny. Będą z tego wynikać aspekty takie jak konieczność testowania spójności poszczególnych wersji (np. za pomocą testów regresyjnych), zapewnienia wymaganej jakości, czy możliwość wdrożenia na środowisko produkcyjne.

Wszystkie te wymagania powinny być ujęte w Definicji Ukończenia, która jest formalnym zobowiązaniem Zespołu w stosunku do Przyrostu. Elementy Product Backlogu, które ją spełniają będą tworzyć Przyrost. W Scrum Guide jest wprost napisane „Kiedy element Product Backlogu osiąga zgodność z Definicją Ukończenia, powstaje Increment”. Wynika z tego, że nigdy nie powstanie Przyrost, jeżeli elementy, które mają go tworzyć nie spełniają Definicji Ukończenia.

W trakcie Sprintu może powstać więcej niż jeden Przyrost. Każdy musi spełniać Definicję Ukończenia.

Przyrost a empiryzm

Generowanie co Sprint ukończonego i używalnego Przyrostu jest istotą Scruma, dzięki której możemy w praktyce realizować ideę empiryzmu w pracy Zespołu Scrumowego, czyli opierać się o trzy filary: przejrzystość, inspekcję i adaptację.

Dzięki krótkiej kadencji Sprintu (maksymalnie 1 miesiąc), umożliwiamy nie tylko tworzenie odpowiedniego poziomu przejrzystości oraz częstą inspekcję i adaptację, ale przed wszystkim jesteśmy w stanie małymi krokami dostarczać wartość użytkownikom Produktu. Regularne wdrożenia umożliwiają analizowanie osiąganych rezultatów produktowych, uczenie się na bazie doświadczeń oraz planowanie przyszłych prac w oparciu o wyciągnięte wnioski.

Przyrost a przejrzystość

Każdy Przyrost daje wgląd w aktualny stan rozwoju Produktu [4], stwarzając przejrzystość procesu i jakości. Ukazuje wszystkim zainteresowanym (organizacji i Interesariuszom) jaka praca została wykonywana oraz buduje wspólne rozumienie sytuacji, ułatwiając tym samym prowadzenie wartościowych rozmów o dalszym rozwoju. 

Dla uzyskania pełnej przejrzystości istotne jest stosowanie wypracowanej przez Zespół Definicji Ukończenia. Dopiero w momencie, gdy elementy Product Backlogu spełniają Definicję Ukończenia, powstaje Przyrost, który może posłużyć jako baza do rozmów z Interesariuszami podczas Sprint Review. Pokazywanie nieukończonej pracy, może przynosić fałszywe poczucie gotowości i dostępności rozwiązania dla użytkowników, zaburzając tym samym przejrzystość [3].

Przyrost a inspekcja i adaptacja

Tworzenie Przyrostu co Sprint umożliwia inspekcję i adaptację. Kluczową (choć nie jedyną) sposobnością ku temu jest Sprint Review. Podczas tego spotkania roboczego z Interesariuszami ukazujemy i rozmawiamy o wykonanej pracy, osiągniętych celach, napotykanych przeszkodach i planowanych rezultatach. Pokazujemy działającą wersję Produktu i zbieramy opinie.

Sprawdzamy jak Przyrost będzie przybliżał Zespół do osiągnięcia Celu Produktu [2]. Taka inspekcja umożliwia korygowanie dalszych działania w taki sposób, by obrać jak najlepszy kurs na osiągnięcie oczekiwanego stanu Produktu w przyszłości.

Interdyscyplinarny zespół

Cały Zespół Scrumowy jest odpowiedzialny za dostarczania wartościowego Przyrostu co Sprint. Istotny przy tworzeniu Przyrostów jest interdyscyplinarny Zespół, czyli taki, który posiada wszystkie konieczne umiejętności by go wytworzyć i tym samym dostarczyć wartość.

Co to oznacza w praktyce?

Mam doświadczenie w tworzeniu produktu medycznego, dla którego „gotowy” Przyrost oznacza, że spełnia on różnego rodzaju warunki jakościowe i proceduralne. Developerzy muszą tworzyć oprogramowanie zgodnie z obowiązującymi procedurami. Do wymogów mogą należeć wymagania jakościowe kodu i testów. Przyrost musi spełniać również liczne wymagania formalne, takie jak: wykonana jest analiza ryzyka dla wprowadzanych funkcjonalności, konieczna dokumentacja jest sporządzona, jeżeli zmiany tego wymagają, dział compliance / prawny jest poinformowany.

Aby po Sprint Review Product Owner mógł podjąć decyzję o wdrożeniu, Przyrost na tym etapie musi spełniać wszystkie powyższe wymagania. Stąd niezwykle istotne jest, by Zespół tworzyły osoby, które mogą wykonać wszystkie wymagane prace. Chcemy unikać sytuacji, w której po ukończeniu Przyrostu konieczne są dodatkowe działania by go wdrożyć. W szczególności, jeżeli związane by to było z zależnościami zewnętrznymi.

Warto zatem przeanalizować wszystkie wymagania, które mogą być nałożone na Produkt, i rozważyć czy Zespół posiada wszystkie konieczne umiejętności: techniczne, UX, testowania i związane z wymaganiami formalnymi [4]. W przeciwnym wypadku trudno będzie Zespołowi wytwarzać prawdziwie gotowe Przyrosty i zwinnie dostarczać wartość.

Jak tworzyć ukończone Przyrosty?

Stworzenie dobrego interdyscyplinarnego Zespołu to jednak nie wszystko. By sprawnie dostarczać ukończone Przyrosty istotne jest również sposób w jaki poszczególni członkowie Zespołu pracują ze sobą.

Współpraca i skupienie

Zespół powinien współpracować w poczuciu odpowiedzialności za ukończenie Przyrostu w Sprincie. Powinien być skupiony na wyznaczonym Cel Sprintu i codziennie podczas Daily Scrum, adaptować wspólny plan na jego osiągnięcie. Taka współpraca ułatwi tworzenie wartościowych Przyrostów z kreatywnymi i efektywnymi rozwiązaniami w Produkcie.

Częstym antywzorcem jest realizowanie rozłącznych zadań przez poszczególnych członków Zespołu. Każdy realizuje inne niepowiązane ze sobą zadanie. Ludzie nie współpracują ze sobą. Każdy czuje odpowiedzialność jedynie za ukończenie swojego kawałka pracy, bez wspólnego skupienia na osiągnięciu celu. Wskaźnikiem, który pomaga wykryć tę sytuację jest ilość pracy w toku (ang. Work in Progress, WIP). W Zespołach pracujących w taki sposób WIP jest zwykle wysoki.

Product Owner może wspierać skupienie Zespołu, chroniąc go przed niepotrzebnymi zmianami w zakresie Sprintu. Zdarza się, że Interesariusze pojawiają się z pilnymi zadaniami do realizacji „na już”. Dobry Product Owner będzie potrafił racjonalnie ocenić sytuację i asertywnie odłożyć tematy na kolejne Sprinty, dzięki czemu Zespół uniknie kosztownych zmian kontekstu.

Rozwiązywanie przeszkód

Do sprawnego dostarczania ukończonych Przyrostów konieczne jest usuwanie napotykanych przeszkód. Efektywne wykorzystywanie Retrospektyw pozwala identyfikować przeszkody, omawiać je i planować ich usuwanie. Bez tego trudno będzie usprawniać proces wytwórczy, a Zespół będzie stale napotykał na powtarzające się problemy, uniemożliwiające dostarczanie Przyrostów.

Podsumowanie

Dostarczanie ukończonych Przyrostów co Sprint jest istotnym elementem zwinnego tworzenia Produktów. Tylko dzięki iteracyjnemu tworzeniu rozwiązań możemy wystarczająco często dostarczać użytkownikom wartość, ucząc się jednoczenie na doświadczeniach. Jeżeli wnioski z tych doświadczeń wykorzystujemy do kreowania planów na przyszłość, to można mówić o empiryzmie. Do efektywnego dostarczania Przyrostów musimy budować interdyscyplinarne Zespoły, które będą współpracować w skupieniu na celach oraz sprawnie usuwać napotykane wyzwania.

Bibligrafia

[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf

[2] What is an Increment and how Does it Connect with the other Elements of Scrum; https://www.scrum.org/resources/blog/what-increment-and-how-does-it-connect-other-elements-scrum

[3] How are Done and your Increment related?; https://www.scrum.org/resources/blog/how-are-done-and-your-increment-related-74

[4] What does Cross-Functional really bring to your Increment?; https://www.scrum.org/resources/blog/what-does-cross-functional-really-bring-your-increment-63

[5] 5 Challenges Creating a Done Increment; https://www.scrum.org/resources/blog/5-challenges-creating-done-increment

Leave a Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *