Blog

Wyobraźmy sobie, że trwa spotkanie, na którym Product Owner wraz z zespołem dyskutuje o wymaganiach w backlogu produktu. Niektóre z nich są tak duże, że żadną miarą nie mieszczą się w sprincie i konieczna jest ich dekompozycja na kilka mniejszych. Uczestnicy dyskusji naprężają neurony z całych sił, ale brak pomysłu na to jak sensownie owe ogromne wymagania podzielić. Wygląda na to, że mniejsze już być nie mogą. Rośnie napięcie i zniechęcenie, wszyscy mają już dość spotkania.

W końcu pada propozycja, by zidentyfikować komponenty techniczne i dokonać zmian w każdym z nich osobno, na koniec zaś zrealizować pracę „spinającą w całość” tak przygotowane elementy większego rozwiązania. Zespół i Product Owner oddychają z ulgą, Scrum Master coś tam mruczy o braku czegoś „wertykalnego”, ale nikt go nie słucha, bo przecież problem został rozwiązany i planowanie kolejnych sprintów będzie można przeprowadzić.

Podział horyzontalny i inne kiepskie pomysły

Dekomponując duże wymagania w ten sposób, że dopiero po zrealizowaniu ich wszystkich w określonej kolejności, uzyska się wartościowe rozwiązanie w istocie… nie dokonujemy żadnej dekompozycji. Jest ona wyłącznie „zabiegiem księgowym” w backlogu produktu. Wciąż bowiem trzeba zrealizować je wszystkie ciągiem, niezależnie od tego, czy zajmie to dwa czy może pięć sprintów. I dopiero na koniec okaże się, czy było warto to robić.

Podział na komponenty z intencją złożenia ich w całość na końcu to jeden z przykładów na mało zwinną dekompozycję wymagań. Inny to podział prac na etapy: analizę, zrobienie projektu, development, integrację, testowanie… brzmi znajomo, prawda? Taka jawna „waterfallizacja” Scruma na szczęście zdarza się niezbyt często, choć niestety wciąż można to zobaczyć (a.d. 2018).

Kolejny marny sposób podziału wymagań to poszatkowanie produktu na warstwy technologiczne i opisanie zmian w każdej z nich osobnym wymaganiem. Pozornie dokonujemy tu zmiany w całym produkcie, a nie w jednym komponencie… ale wciąż, aby spełnić wymaganie biznesowe, zrealizować trzeba prace we wszystkich takich warstwach. Nie da się bowiem użyć bazy danych, jeśli do niczego nie jest przypięta; nie da się skorzystać z interfejsu użytkownika, jeśli pod spodem brak obsługi tego, co pieczołowicie w nim wpisujemy…

Co z tym „wertykalnym” podziałem?

W opisanej scence Scrum Master wspominał o podziale wertykalnym podczas dekompozycji wymagania. O co chodzi? Zamiast kroić produkt na plasterki, dzielmy go pionowymi „paskami” przechodzącymi przez wszystkie warstwy technologiczne tak, by zrealizować jakąś – niekoniecznie kompletną biznesowo – funkcjonalność.

Na przykład jeśli produkt to aplikacja z formularzami, do których wprowadza się dane, w oparciu o które wyliczane są jakieś raporty, takim wertykalnym wycinkiem może być możliwość zdefiniowania minimalnego zestawu takich danych i wyliczenia z nich jednej, prostej informacji. Dzięki temu już po zrealizowaniu jednego wymagania z kilku, jakie powstały z podziału, uzyskamy coś, co działa. Oczywiście jest to zapewne działanie zbyt niedoskonałe, by takiego produktu zacząć używać, ale dużo lepiej mieć taki produkt i szansę na jego przetestowanie, niż mający jedynie teoretyczną wartość „kawałek” produktu, którego nie da się nawet uruchomić.

Rzecz jasna strategii dekompozycji jest wiele i należy dobierać je do problemu, jaki opisuje wymaganie, które chcemy podzielić na kilka mniejszych. Czasem zaczynamy od rozwiązania prostego, potem bardziej złożonego. W innym przypadku najpierw robimy obsługę jednego typu transakcji, po czym dokładamy kolejne. A może najpierw zrobimy, by coś działało dla jednego użytkownika, a potem dopiero umożliwimy korzystanie z produktu tysiącom osób jednocześnie?

Każde wymaganie da się zdekomponować na kilka mniejszych

Niezależnie od przekonań i braku wiary w prawdziwość tego stwierdzenia, to naprawdę możliwe. Jeśli nie potrafimy tego zrobić, najczęściej u źródeł owego „niedasizmu” znajdziemy brak zrozumienia jednej lub kilku kluczowych dla zwinności kwestii.

Brak wiedzy o produkcie lub zrozumienia wymagań

Pierwszą z nich jest brak zrozumienia samego wymagania. Ciężko przecież podzielić na kilka sensownych, wartościowych kawałków coś, czego nie ogarniamy jako całości. Proces dekompozycji wymagań ma dużą siłę w ujawnianiu, że pozornie oczywisty i dobrze zrozumiany problem biznesowy wcale nie jest taki oczywisty. I dobrze, że tak się dzieje, bo to daje możliwość doprecyzowania, ustalenia co tak naprawdę jest potrzebne.

Bywa niestety i tak, że brak rozumienia wymagania jest pochodną braku wiedzy o samym produkcie. Tak czy inaczej, jeśli już ów deficyt się ujawni w zespole, trzeba się z nim zmierzyć. Rychło okaże się, że wraz ze wzrostem poziomu wiedzy o produkcie, praca z wymaganiami staje się jakby prostsza…

Brak zrozumienia czym jest potencjalnie używalny produkt

Scrum wymaga od zespołu developerskiego, by co najmniej raz na sprint wytworzył działający, w pełni ukończony, nadający się do użycia produkt. Metoda mówi o tym produkcie, że jest to potencjalnie używalny przyrost produktu. Mówiąc po ludzku to nowa wersja, obejmująca wszystkie wcześniej istniejące cechy i funkcjonalności produktu, nad którą prace developerskie w pełni się ukończyły, i której potencjalnie można zacząć używać.

Potencjalnie? Czemu tylko potencjalnie? Ano, potencjalnie. Ten produkt może zostać użyty, ale nie musi, ponieważ o tym decyduje Product Owner. Warto tu podkreślić, że podejmuje decyzję kierując się oceną wartości produktu, a nie stanem technologicznym, w jakim ów produkt się znajduje. Zespół developerski ma zapewnić, że jeśli Product Owner zechce użyć czegoś, co zostało ukończone, to to coś rzeczywiście do użytku się nadaje.

Jak w praktyce ta „potencjalność używalności” działa? Wyobraźmy sobie, że robimy bardzo złożony system informatyczny, który wymaga miesięcy pracy, zanim będzie można udostępnić go biznesowi. Wiele z funkcjonalności tego rozwiązania wymagać będzie inkrementalnego rozwoju od podstawowego działania, poprzez te bardziej złożone.

I tak, na przykład, jeśli budowany będzie jakiś formularz do wprowadzania danych, to zapewne w pierwszej wersji nie będzie on zbyt piękny, brakować w nim może pól opcjonalnych, niekoniecznie będzie informował o błędnie wprowadzonych danych itd. Jeśli zespół developerski ukończy nad nim pracę, to w takim zakresie, jaki ustalono w czasie planowania, formularz ten będzie działał.

Gdyby w tym momencie Product Owner uznał, że takie proste i mocno ograniczone rozwiązanie może zostać użyte, może to zrobić – bo jest ukończone, i do użytku się nadaje. Najprawdopodobniej jednak Product Owner uzna, że trzeba nad formularzem jeszcze trochę popracować, by dodać kilka z owych opcjonalnych pól, jakąś walidację wprowadzanych danych i może troszkę warto upiększyć wygląd samego formularza. Tym samym rozwiązanie jest potencjalnie używalne: może, ale nie musi być użyte.

Dążenie do zrobienia funkcjonalności „raz-a-dobrze”, a nie do wytworzenia kilku coraz bardziej zaawansowanych potencjalnie używalnych wersji produktu zanim ostatecznie się jej używa, utrudnia podział wymagań na mniejsze. Bo te mniejsze często opisują właśnie rozwiązania, które biznesowo nie są wystarczające, by produktu od razu użyć. Gdy przestaniemy dążyć do stworzenia od razu pełnego, kompletnego, docelowego rozwiązania, dzielenie wymagań stanie się dużo prostsze.

Brak zrozumienia na czym polega inkrementalny rozwój produktu

W Scrumie pracuje się w iteracjach, ale iteracyjność to nie jedyny wymóg, by mówić o zwinnym wytwarzaniu rozwiązań. Konieczne jest też ich budowanie inkrementalne (przyrostowe). Dużego produktu nie da się wytworzyć od razu w jego docelowym kształcie z dwóch powodów: bo będzie to trwać niezmiernie długo i nie jesteśmy w stanie z góry przewidzieć, jaki ten docelowy kształt powinien być.

Aby sobie poradzić z tymi dwoma ograniczeniami, budujemy kolejne wersje produktu: zaczynamy od najprostszej, po czym dokładamy do niej coraz to nowe funkcje i cechy, po drodze upewniając się, że to, co powstaje odpowiada aktualnym potrzebom. W końcu dochodzimy do rozwiązania, które zostanie użyte, im wcześniej, tym lepiej.

Niestety, wiele zespołów nie akceptuje podejścia inkrementalnego, bo wymaga ono często przerobienia czegoś, co zostało wytworzone w poprzednich sprintach tak, by odpowiadało nowym potrzebom lub aktualnemu stanowi wiedzy o produkcie. Odzywa się tu „raz-a-dobrzyzm”, o którym pisałem już wcześniej. Powoduje on opór przed dzieleniem dużych wymagań w sposób, który może wymagać kilkukrotnego przerobienia jakiejś funkcjonalności. Padają oskarżenia o „dokładanie sobie pracy”, dąży się do wymyślenia jak docelowo rozwiązanie ma działać, by od razu zbudować coś takiego, a nie bawić się w eksperymentowanie…

Zwinne zespoły z dekompozycją nie mają problemów

Jeśli zespół potrafi efektywnie korzystać ze Scruma (ale też innych metod zwinnych), z dekompozycją nie będzie miał problemu. Bo w naturalny sposób będzie dążył wraz z Product Ownerem, by najpierw zrealizować takie prace, które pozwolą potwierdzić, że rozwój produktu zmierza w dobrą stronę. Potem poszukiwany będzie sposób na jak najszybsze użycie produktu. Dopiero potem zacznie się udoskonalanie już działających rozwiązań.

Dzięki sensownej dekompozycji, pojawią się jeszcze dwa pozytywne rezultaty. Pierwszym będzie przesianie dużych wymagań tak, by „wytrząsnąć” z nich mało istotne zmiany, i by to, co pozostanie, a co jest wartościowe, można było dostarczyć szybciej. Drugim będzie zapewnienie, że Product Owner i wszyscy developerzy tak samo rozumieją potrzeby opisane wymaganiami (zmiany, jakich trzeba dokonać w produkcie), a to ułatwi podejmowanie decyzji i przyspieszy czynności takie jak szacowanie wymagań czy planowanie sprintu.

A najciekawsze jest to, że rozumiejąc czym jest potencjalna używalność produktu i jego inkrementalny rozwój, i nie obawiając się konieczności częstych zmian we wcześniej zrealizowanych funkcjonalnościach, zespół również od strony technologicznej (w tym architektury) zapewnia, by takich zmian dało dokonywać się łatwiej, bezpieczniej i szybciej. Ale to już temat na zupełnie osobny wpis.