Przyrost produktu w Scrumie

Na koniec każdego Sprintu w Scrumie powinniśmy otrzymać Przyrost funkcjonalności produktu. Obserwując pracę Zespołów Scrumowych, można dojść do wniosku, że nie jest to trywialne zadanie. Czym jest Przyrost produktu oraz na co zwrócić uwagę podczas jego tworzenia, dowiesz się z poniższego artykułu.

Co to jest Przyrost produktu?

Zwięzłą definicję Przyrostu można znaleźć w najnowszym wydaniu Przewodnika po Scrumie. Przeczytasz w nim, że “Przyrostem jest namacalny rezultat wykonanej pracy, podlegający empirycznej inspekcji na zakończenie Sprintu. Reprezentuje on krok w kierunku wizji lub celu”.

Istnieje kilka ważnych aspektów, które można wyczytać z tej definicji. Omówiłem je w szczegółach poniżej.

Przyrost to namacalny rezultat pracy

Praca wykonana przez Zespół Deweloperski w trakcie Sprintu powinna być czymś konkretnym oraz widocznym. Często obserwuję zespoły, którym nie można odmówić pracowitości w trakcie Sprintu, jednak gdy przychodzi czas Przeglądu Sprintu, nie mogą pochwalić się namacalnym efektem pracy.

W osiągnięciu konkretnego Przyrostu pomaga dobrze zdefiniowany Cel Sprintu. Mówi on zwykle o konkretnych założeniach, które Zespół Deweloperski planuje osiągnąć jako efekt pracy w Sprincie.

Przykładowe namacalne rezultaty pracy dla różnego rodzaju wytwarzanych produktów, mogą wyglądać następująco:

  • Dodanie możliwości zapamiętania ostatnich wyszukiwań w wyszukiwarce (tworzenie oprogramowania)
  • Przeprowadzenie ankiety wśród pracowników i przygotowanie zbiorczego podsumowania rezultatów (zarządzanie działem w firmie)
  • Dodanie sekcji “rekomendacje od klientów” do szablonu oferty wysyłanej do klientów (firma usługowa)
  • Zmiana mikrofonu używanego podczas nagrywania podkastu z mikrofonu wbudowanego w telefon na profesjonalny przenośny rejestrator dźwięku (nagrywanie podkastu)

Prostym i skutecznym sposobem wspierającym osiąganie konkretnych efektów Sprintu jest zadanie sobie pytania podczas Planowania Sprintu “Co otrzyma użytkownik produktu w efekcie naszej pracy w Sprincie?”.

Przyrost jest wytwarzany w sposób iteracyjny i przyrostowy

Przyrost funkcjonalności produktu w Scrumie powinien być wytwarzany przystowo oraz iteracyjnie. Innymi słowy, zaczynając pracę nad złożonym produktem, powinniśmy zacząć od stworzenia możliwie najprostszej wersji naszego produktu i stopniowo rozbudowywać ją o nowe funkcjonalności.

Przykładowo, głównymi funkcjonalnościami edytora tekstowego są możliwość otwarcia pliku, zmiana jego treści oraz zapisanie pliku. Gdybym miał stworzyć edytor tekstu, zaczynałbym od powyższych funkcjonalności, a dopiero później zastanawiał się nad mniej istotnymi możliwościami, taki jak szablony dokumentów czy możliwość wstawiania tabel i wykresów.

Takie podejście pozwala wcześniej dostarczyć produkt odbiorcom końcowym a także na bieżąco implementować informację zwrotną uzyskiwaną na skutek dokonywania regularnej inspekcji oraz adaptacji produktu.

Przydatnym narzędziem wspierającym iteracyjno-przyrostowe wytwarzanie produktu jest Story Mapping autorstwa Jeffa Pattona. Podejście to bazuje na budowaniu obrazu tego, jak użytkownik wchodzi w interakcję z produktem, dekomponowaniu tych aktywności na mniejsze części oraz układaniu ich w kolejności zgodnej z tym, jak użytkownicy w rzeczywistości korzystają z produktu.

Przyrost to zintegrowana wersja produktu

Najprościej rzecz ujmując, Przyrost to kolejna, trochę lepsza wersja produktu. Jest gotowy do użycia, zintegrowany oraz przetestowany. Warto przy planowaniu kolejnego Przyrostu produktu myśleć w taki sposób, że może to być nasz ostatni Sprint.

Takie myślenie o rozwoju produktu pozwala uzyskać faktyczną zwinność. Stwarza możliwość podjęcia decyzji o zmianie kierunku rozwoju produktu lub decyzji o nie startowaniu kolejnych Sprintów (bo Przyrost produktu, który aktualnie posiadamy, realizuje już nasze cele), tylko skupienie się na innym produkcie lub obszarze działań. Aby wejść na ten poziom zwinności, trzeba opanować sztukę dostarczania produktu w krótkich iteracjach oraz dzielenia funkcjonalności produktu na bardzo małe części.

Niestety, na bazie mojego doświadczenia, mało który Zespół Scrumowy myśli o rozwoju Przyrostu w wyżej wymieniony sposób. Większość zespołów i firm, pomimo deklaratywnego zapewnienia o stosowania Scruma, rozwija produkt po staremu: przygotowują rozbudowany plan na kilka-kilkanaście iteracji i dopiero po realizacji całego planu, otrzymują zdatny do użycia produkt. Takie podejście stoi w sprzeczności z podejściem iteracyjno-przyrostowym i klasyfikuje się jako antywzorzec postępowania zwany “Water Scrum Fall”.

Przyrost poddajemy inspekcji na koniec Sprintu

Koniec Sprintu to moment, w którym Przyrost poddawany jest inspekcji. W szczególności, jeśli Właściciel Produktu oraz interesariusze nie mieli okazji zobaczyć wczesnych rezultatów pracy w trakcie Sprintu, jest to kluczowe wydarzenie w Scrumie z punktu widzenia zarządzania rozwojem produktu.

Regularne poddawanie Przyrostu produktu inspekcji obniża ryzyko wytworzenia niewłaściwego produktu, a także pozwala na bieżąco usprawniać produkt o nowe funkcjonalności. Stąd istotny jest aspekt wspomniany na początku artykułu, aby rezultat Sprintu był na tyle konkretny, aby można było swobodnie podyskutować na jego temat.

Przyrost spełnia Definicję Ukończenia

Przyrost to suma elementów Backlogu Produktu dostarczonych w trakcie bieżącego Sprintu i wszystkich poprzednich Sprintów. W takim rozumieniu, na koniec każdego Sprintu Przyrost produktu powinien spełniać Definicję Ukończenia i być gotowy do użycia. Jest to istotna informacja, wymaga bowiem od zespołu nie tylko zapewnienia, że wybrane elementy Backlogu Produktu należące do bieżącego Sprint spełniają DoD, ale także Przyrost jako całość.

Przykładowo, jeżeli nowo dodane funkcjonalności w bieżącym Sprincie działają poprawnie i spełniają Definicję Ukończenia, a jednocześnie w procesie integracji produktu zepsuliśmy inne, wcześniej dodane funkcjonalności, to nie możemy mówić o tym, że Przyrost spełnia Definicję Ukończenia.

Co wpływa na jakość dostarczanych Przyrostów?

Jest kilka elementów, które na bazie moich doświadczeń w pracy z zespołami scrumowymi wpływają na jakość dostarczanych Przyrostów produktu.

  • Wiedza biznesowa zespołu o budowanym produkcie – im głębsze zrozumienie wizji produktu oraz kontekstu biznesowego, tym wytwarzane Przyrosty lepiej odpowiadają na potrzeby użytkowników. Bardzo pomocnym podejściem zwiększającym zrozumienie produktu w zespole jest angażowanie członków Zespołu Deweloperskiego w proces odkrywania produktu.
  • Dobrze przygotowany Backlog Produktu – czytelnie przygotowane elementy Backlogu Produktu pomagają zwiększyć szanse na sensowną realizację Przyrostu produktu w Sprincie. Polecanym, wspomniany już w artykule narzędziem, który wspiera ten proces jest Story Mapping.
  • Jasny Cel Sprintu – dobrze przygotowany Cel Sprintu pomaga Zespołowi Deweloperskiemu zrozumieć kontekst biznesowy wykonywanej pracy, daje swobodę działania oraz wspiera współpracę w zespole. Warto dbać o to, aby Cel Sprintu był konkretny i łatwy do oceny, czy faktycznie został osiągnięty.
  • Skuteczne Planowanie Sprintu – porządnie przygotowany plan dostarczenia Przyrostu produktu zwiększa szanse na dostarczenie namacalnego Przyrostu na koniec Sprintu. Wykorzystywanie metod wizualnych, realizowanie sesji podsumowania planu przez zespół po zakończeniu budowy planu czy mocna dekompozycja zadań, to tylko niektóre ze sposobów zwiększających szanse na dobrze przygotowany plan.
  • Efektywny Codzienny Scrum – regularne przeprowadzanie inspekcji bieżącego postępu prac oraz adaptacja planu dostarczenia Sprintu zwiększa szanse, że na koniec Sprintu Zespół Deweloperski będzie mógł pochwalić się konkretnym Przyrostem produktu. Warto zadbać o to, aby nie wpaść w popularne pułapki Codziennego Scruma i skupić się na sumiennym zaplanowaniu całym zespołem planu działania na najbliższe 24 godziny pracy.

Podsumowanie

Regularne dostarczanie Przyrostu produktu co Sprint to obietnica, która stoi za frameworkiem Scrum. Nie jest to trywialne zadanie, jednak gdy tylko będzie konsekwentnie realizowane, będziemy mogli czerpać z korzyści iteracyjnego oraz przyrostowego wytwarzania produktu.

Jak radzicie sobie z regularniem dostarczaniem Przyrostu produktu? Koniecznie podzielcie się w komentarzach!

Źródło zdjęcia: https://www.flickr.com/photos/hajdekr/45577359915/

Jeden komentarz do wpisu: “Przyrost produktu w Scrumie


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x