Potencjalnie Wdrażalny czy Użyteczny? - #białko czyli Scrum i Agile

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.