.st0{fill:#FFFFFF;}

Potencjalnie Wdrażalny czy Użyteczny? 

 14 września, 2021

Tomasz Dzierżek

Niektórzy mówią, że to Increment, a inni – Przyrost. To tylko semantyka, którą na naszym blogu zajmowaliśmy się nie raz. Czasami jednak różnice w używanych określeniach to coś więcej, niż tylko kwestia językowa. Bo „potencjalnie wdrażalny” i „użyteczny” to nie jest to samo.

 

Potencjalnie Wdrażalny Przyrost

Trudno uwierzyć, że nasz pierwszy tekst opisujący Increment (czyli Przyrost) popełniliśmy ponad 3 lata temu. Od tamtego czasu idea pozostaje ta sama, jednak zmieniła się nieco optyka i nacisk który Podręcznik Scrum kładzie na różne rzeczy.

„Cały Scrum Team ponosi odpowiedzialność za wytworzenie wartościowego, użytecznego Incrementu co Sprint.” – Scrum Guide

Wraz ze zmianami w Scrum Guide 2020 sformułowanie „potencjalnie wdrażalny” (ang. potentially releasable) zostało zastąpione przez słowo „użyteczny” (ang. useable). Ta zmiana wynikała z kilku czynników. Po pierwsze, z dokumentu zostały usunięte wszystkie odwołania do IT. W wielu obszarach nie mamy do czynienia z „wdrożeniami”. To słowo to typowo informatyczny slang. Ale są też inne przyczyny tej zmiany, nieco mniej oczywiste.

„Potencjalnie wdrażalny” to bardzo problematyczna fraza. Dlaczego nie mówimy po prostu o „wdrażalnym”? Skąd się bierze to słowo „potencjalnie”? Stąd, że Product Owner wcale nie musi się zdecydować na wypuszczenie nowej wersji naszego produktu. Gdybyśmy jednak chcieli mieć po prostu „wdrażalny” produkt to w kontekście tworzenia oprogramowania wiązałoby się to zapewne z przygotowaniem odpowiedniej, gotowej paczki wdrożeniowej leżącej gdzieś na serwerze i zbierającej wirtualny kurz (patrz: waste). Przygotowanie wdrożenia to często dużo zachodu, szkoda więc robić to co Sprint w sytuacji, w której wdrażamy się z mniejszą częstotliwością.

 

Użyteczny Przyrost

Pozbycie się tej nieszczęsnej „potencjalnej wdrażalności” pozwoliło podkreślić „użyteczność”. Żeby nie było, w „starym” Scrum Guide słowo „useable” też występowało. Dociekliwi nawet sprawdzą, że znaleźć je można dokładnie cztery razy i za każdym razem opisuje ono Increment. To nie tak, że dużo się zmieniło. Chodzi o skupienie się na wartości i użyteczności. Jeśli umiemy zrobić tak, żeby nasz Przyrost miał te dwie cechy, a nie był wdrażalny to gratulacje.

„Aby dostarczyć wartość, Increment musi być użyteczny.” – Scrum Guide

Co z tego, że mamy „potencjalnie wdrażalny” Increment, skoro nie dostarcza on żadnej wartości i nie jest zdatny do użytku? Łatwo schować się za „wdrażalnością” niczym za tarczą – „zgodnie ze scrumowymi wymaganiami nasz Przyrost jest wdrażalny, więc przymknijmy oko na to, że nie jest ani wartościowy, ani użyteczny”. Nie tędy droga. Nie wystarczy, że działa. Musi jeszcze być przydatny.

 

Kiedy powstaje przydatny Increment?

„Praca nie może zostać uznana za część Incrementu, jeśli nie jest zgodna z Definicją Ukończenia. (…) Kiedy element Product Backlogu osiąga zgodność z Definicją Ukończenia, powstaje Increment.” – Scrum Guide

Te dwa zdania wyrwane z dwóch różnych części Scrum Guide’a powinny rozwiać wszelkie nasze wątpliwości, jeżeli chodzi o to, kiedy powstaje Przyrost. A skoro powstaje niejako sam z siebie, to musi też mieć wszystkie te cechy, o których dyskutowaliśmy to tej pory. Przy dobrze zarządzanym backlogu nie powinno to być problemem.

Zakładamy, że wymagania które realizujemy są wartościowe. Ponadto, jeżeli spełniliśmy kryteria Definition of Done, to powinno to znaczyć, że osiągnęliśmy wymaganą jakość i skończyliśmy wymagane prace. Z drugiej strony – bez spełnienia DoD nie możemy powiedzieć, że coś jest zrealizowane lub zakończone.

Przyrost powstaje więc w tym momencie, w którym spełnimy Kryteria Akceptacji i kryteria Definition of Done pierwszego wymagania. Wtedy też powinna pojawić się pierwsza wartość.

 

Przyrostowo czy Iteracyjnie?

Można mieć wiele różnych Przyrostów w trakcie jednego Sprintu, ale tylko jeden na jego końcu. Innymi słowy, każde wymaganie zrealizowane zgodnie z Definition of Done tworzy nam kolejny Przyrost. Nic nie stoi na przeszkodzie, aby oddać go do użytku („wdrożyć”) jeszcze przed końcem iteracji. Natomiast na samym końcu, na Sprint Review, będziemy omawiać i pokazywać ten Increment, który powstał jako ostatni. Bo z definicji przecież, zawiera on też wszystkie poprzednie.

To też jest dobra informacja w kontekście dzisiejszego tematu. Jeśli po zrealizowaniu jednego z dziesięciu wymagań ze Sprint Backlogu mamy już użyteczny i wartościowy Przyrost, to znaczy, że po zrealizowaniu każdego kolejnego nadal on taki pozostanie! Dodając do niego więcej funkcjonalności nie pozbędziemy się przecież wartości czy użyteczności. O ile oczywiście nasza praca jest dobra jakościowo i zrealizowanie jednego wymagania nie powoduje destrukcji całego produktu.

Kwestia regresji to już jednak temat testów w Scrum, który mam wrażanie, że jest zbyt często pomijany. A skoro tak, to zajmiemy się nim niedługo – zarówno na naszym blogu, jak i na liście mailingowej, na której między innymi dzielimy się naszymi luźniejszymi przemyśleniami bez autocenzury.

Na dziś pamiętajmy, że słowo „użyteczny” jest kluczowe w kontekście Incrementu. „Potencjalna wdrażalność” to tylko jedna z cech użyteczności. Zapytajmy więc na Sprint Review, „Jak użytkownicy naszego Produktu mogą odczuć większą wartość płynącą z tego konkretnego Przyrostu?” Abstrahując od tego, czy ten Increment udostępnimy odbiorcom, skupmy się na tym, aby jego wartość zwiększała się co Sprint. Przecież o to w tym całym Scrumie chodzi.

Tomasz Dzierżek


23+ lat doświadczenia w IT, 15+ lat doświadczenia w Scrum i agile, PSM III (i inne), konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

  1. A co z tematami, które są bardzo duże, np. wdrożenie całkiem nowego modułu do systemu, który bez ficzerasów jest i tak sporych rozmiarów i nie za bardzo da się go jakoś podzielić? Ewentualnie można zrobić tak, że najpierw zrobi się back, a potem front. Co wówczas? Czy taki back to też użyteczny przyrost? Czy można tutaj mówić o wartości / użyteczności dla klienta wewnętrznego, bo na jego podstawie zrobimy front i skończymy cały moduł?

    1. Robienie backendu i frontendu osobno to jedna z największych pułapek, bo jedno bez drugiego absolutnie nie niesie ze sobą żadnej wartości biznesowej. Patrz też: https://bialko.eu/agile/bledy-tworzenie-zespolow-scrumowych/ Droga, którą w takiej sytuacji polecamy to dzielenie biznesowe. Np. nowy moduł trzeba będzie skonfigurować, czyli np. konfiguracja może być osobną, zamkniętą częścią. A może odwrotnie, niektóre rzeczy można wrzucić do bazy, nie tworzyć interfejsów do konfiguracji, tylko zająć się „mięsem”? Możliwości jest wiele, mamy nawet szkolenie dedykowane pod „zwinne” dzielenie wymagań – https://bialko.eu/wymagania-projekty-agile/

      1. Dzięki za szybką odpowiedź.
        OK – rozumiem, że podział na backend i frontend to kiepski przykład. Aczkolwiek rozumiem, że dopuszczalne jest, by w danej iteracji zrobić np. tylko settingsy? Wiem, że nie trzeba ich wydawać – bo niby po co?
        Jednak jak w takiej sytuacji rozumieć wartość biznesową i użyteczność takich settingsów? Chodzi mi o to, że bez "reszty" nie stanowią one żadnej wartości dla usera. Jak o takiej iteracji / sprincie należy "myśleć"? Jak go postrzegać? Zawsze pojmowałem sprinty w ten sposób, że powinna je kończyć realizacja w pełni wartościowego incrementu, a same settingsy nie stanowią pełnowartościowego "elementu", bo user nic z tym nie zrobi, dopóki nie damy mu wspomnianej reszty.

        P.S. Czy te wszystkie szkolenia agile'owe prowadzi ktoś z Waszego teamu #bialko?
        P.S. 2 Czy prowadzicie także konsultacje na godziny? Mam więcej tego typu pytań i chętnie bym uzupełnił brakującą wiedzę.

        1. Wartościowość/użyteczność oceniamy pod kątem tego, czy ktoś będzie z tego kiedykolwiek korzystał i czerpał korzyść. Ja lubię do tego też dodawać "zrobiliśmy to i już nie będziemy do tego wracać", dzięki czemu przynajmniej możemy śledzić postępy prac. Jeżeli "settingsy" pozwalają nam zweryfikować, czy uda nam się wszystko skonfigurować biznesowo, to są wartościowe – możemy wykonywać już część naszej pracy. Jeśli to tylko "nick i avatar oraz liczba elementów na stronie", to pewnie jest to wartościowe mniej… ale nadal w jakiś sposób jest. Najważniejsze, że to jest docelowe rozwiązanie, które używamy i możemy zweryfikować, że "to jest to, o co nam chodziło".

          Być może ten sposób dzielenia wymagań nie jest najbardziej szczęśliwy jako przykład. Wyobraźmy więc sobie ten "cały nowy moduł" i to, jak z niego będą korzystali użytkownicy. Czy najpierw muszą zasetupować całe przedsięwzięcie, czy też najpierw będą korzystali z jakiegoś małego fragmentu? Jak wygląda flow? Od czego możemy zacząć, żeby jak najszybciej powstało coś faktycznie "użytecznego"? Klasyczny i obrazowy przykład to "najpierw zróbmy rejestrowanie wniosków, bo ustawa nas zobowiązuje do ich przyjmowania, a na ich faktyczne walidowanie i procesowanie przyjdzie czas". Ktoś może powiedzieć, że samo przyjęcie wniosku i zapisanie go w bazie nie ma wartości, ale bez tego byśmy np. zapłacili karę. Dzielenie wymagań w podejściu zwinnym to prawdziwa sztuka. 🙂

          Odpowiadając na PS-y – wszystkie szkolenia prowadzone są przez team #białko, a konsultacje na godziny również oferujemy. Najłatwiej skontaktować się z nami przez formularz na stronie https://bialko.eu/kontakt/

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}