Blog

Wyobraźmy sobie, że trwa spotkanie, w którego trakcie Product Owner wraz z Developerami 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ść” wszystkie elementy rozwiązania. Developerzy 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

Podział dużego wymagania na kilka mniejszych w ten sposób, że dopiero po zrealizowaniu ich wszystkich w określonej kolejności uzyska się wartościowe rozwiązaniem, oznacza w praktyce, że nie została dokonana żadna dekompozycja. Jest ona wyłącznie zabiegiem księgowym w Backlogu Produktu. Wciąż bowiem trzeba zrealizować całość, zanim pojawi się coś, co ma szansę przynieść wartość. I nie po pierwszym Sprincie, w którym ukończony zostanie pierwszych kilka kawałków (być może tylko jeden), ale dopiero po wielu iteracjach można będzie empirycznie potwierdzić, że wybrane rozwiązanie faktycznie zaspokaja potrzeby interesariuszy. Lub odkryć, że jest całkowicie nieskuteczne, chybione albo zbędne.

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 marny pomysł 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ąż się zdarza a.d. 2018.

Kolejny chybiony 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 na raz, 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 scenie opisanej na początku artykułu Scrum Master wspominał o podziale wertykalnym podczas dekompozycji wymagania. O co chodzi? Zamiast kroić produkt na plasterki (warstwy) lub rozszarpywać na kawałki (komponenty), dzielmy go pionowymi paskami, przechodzącymi przez wszystkie warstwy technologiczne tak, by zrealizować jakąś funkcjonalność. Nie będzie ona finalnym rozwiązaniem, które całościowo rozwiązuje wszystkie aspekty problemu opisanego wymaganiem, ale będzie w pełni obsługiwać przynajmniej jeden z możliwych przypadków użycia produktu.

Na przykład, jeśli produkt to aplikacja z formularzami, do których wprowadza się dane, z których wyliczane są jakieś raporty, takim wertykalnym wycinkiem może być możliwość zdefiniowania minimalnego zestawu danych niezbędnych, które pozwolą wygenerować jedną informację – najprostszy raport, albo chociaż jego kluczową część składową. Dzięki temu już po zrealizowaniu jednego wymagania z kilku, jakie powstały w wyniku dekompozycji, uzyskamy coś, co naprawdę działa i potencjalnie może być użyte.

Mowa o potencjalnym użyciu, bo choć jest ono możliwe, użytkownicy nie byliby skłonni korzystać z produktu o tak ograniczonych możliwościach. Natomiast jego istnienie pozwala na potwierdzenie, czy te funkcjonalności, które już powstały, są zbieżne z oczekiwaniami interesariuszy (przede wszystkim użytkowników). To zdecydowanie lepsza sytuacja niż pozorne istnienie dużej liczby funkcjonalności w produkcie, który w rzeczywistości nie działa i służy jedynie do prezentacji tego, co by było, gdyby kiedyś w przyszłości zadziałał.

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 dodając do niego coraz bardziej zaawansowane możliwości. Innym razem rozwój produktu zacznie się od obsługi jednego scenariusza, do którego z czasem dodawane będą kolejne. A może najpierw zrobione zostanie coś dla jednej grupy użytkowników, potem dla innych, a na końcu produkt udostępniony zostanie 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 dekompozycji przeprowadzić, najczęściej u źródeł owego niedasizmu leży jeden lub wiele z wymienionych poniżej braków.

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żą zdolność obnażania, ż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 go i 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 (a dokładniej od Developerów w nim), by co najmniej raz na Sprint powstał działający, w pełni ukończony, nadający się do użycia produkt. Metoda nazywa go Przyrostem (ang. Increment). 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ć.

Dlaczego potencjalnie? Bo obowiązku użycia nie ma. O tym, czy użytkownicy zaczną korzystać z produktu, decyduje wiele czynników, z których najważniejszym jest to, czy będzie on na tym etapie rozwoju użyteczny, czy raczej kłopotliwy. Oczywiście nie chodzi tu o jakiekolwiek niedociągnięcia techniczne i niedoróbki – bo mowa o produkcie nadającym się do użycia. Chodzi o braki funkcjonalności, których nie ma, bo jeszcze nie zostały wytworzone (a nie niedziałanie funkcjonalności, które ponoć powstały).

Kto podejmuje decyzję o przekazaniu produktu użytkownikom? Cały Zespół Scrum, ponieważ Developerzy są w stanie określić kondycję techniczną rozwiązania (na ile użycie produktu w jego bieżącej formie jest bezpieczne dla użytkowników), a Product Owner dołożyć do tego może ocenę skutków biznesowych.

Jak w praktyce ta potencjalna używalność 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 użytkownikom. Wiele z funkcjonalności tego rozwiązania wymagać będzie inkrementalnego rozwoju od podstawowego działania, poprzez te bardziej skomplikowane do mechanizmów naprawdę bardzo złożonych.

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 Developerzy ukończą nad nim pracę, to w takim zakresie, jaki ustalono w trakcie Planowania Sprintu, formularz ten będzie działał.

Zespół Scrum może uznać wtedy, że nawet takie proste i mocno ograniczone rozwiązanie ułatwi użytkownikom pracę i umożliwi korzystanie z formularza. Najprawdopodobniej jednak wszyscy zgodzą się, że trzeba nad formularzem jeszcze trochę popracować, by dodać kilka z owych opcjonalnych pól, jakąś walidację wprowadzanych danych i może nieco upiększyć wygląd.

Brak zrozumienia na czym polega inkrementalny rozwój produktu

Odwrotnością podejścia opisanego powyżej jest dążenie do zrobienia funkcjonalności raz-a-dobrze, które mogłoby wyglądać tak: w pierwszym Sprincie powstaje kompletny pięknie wyglądający formularz, który działa wadliwie w wielu przypadkach (bo Developerom brakło czasu na przetestowanie go w wystarczającym stopniu) albo w ogóle by nie działa (bo wisi w próżni, nieprzypięty do niczego, stanowiąc jedynie wizualizację przyszłego rozwiązania, którego jednak jeszcze nie ma).

Raz-a-dobrzyzm często wynika z przekonania, że Przyrostem w Scrumie może być wyłącznie kompletne i finalne rozwiązanie, a to przecież kłóci się kompletnie z ideą rozwoju produktu w sposób, nomen omen, przyrostowy i empiryczną kontrolą procesu.

Jednym z powodów, dla których w Scrumie pracuje się w iteracjach, jest właśnie rozkładanie złożonych problemów na mniejsze kawałki, z którymi Zespół radzi sobie po kolei. Wytworzenie złożonej funkcjonalności w produkcie jest oczywistym tego przykładem. Sprinty nie służą przecież wyłącznie podziałowi pracy na etapy, ale w szczególności takiemu jej ułożeniu, by szybko powstało coś, co faktycznie działa i co może być użyte do potwierdzenia, że Zespół zmierza w dobrą stronę.

Dzięki temu nie jest konieczne szczegółowe zaprojektowanie rozwiązania i przewidzenie, jak przebiegać będzie jego implementacja. Zamiast tego można zacząć od tego, co najważniejsze, albo najprostsze, albo najbardziej ryzykowne – różne strategie mogą mieć tutaj zastosowanie – i na początek uzyskać coś, co potem jest dalej rozbudowywane. Szczegóły ujawniają się w trakcie prac, podobnie jak problemy, które trzeba rozwiązywać, a których z góry nie dałoby się przewidzieć.

Obrazowo mówiąc, zamiast długo szykować się do wytworzenia końcowej wersji rozwiązania, próbując przewidzieć przyszłość i mnożąc spekulacje przez założenia (które potem się nie potwierdzają), lepiej zacząć budować produkt najszybciej, jak to możliwe i zacząć empirycznie sprawdzać, co jest możliwe, czego tak naprawdę potrzebują użytkownicy, czy dobrze zrozumiane zostały wymagania itd. Jest bardzo duża szansa, że dzięki temu właściwy produkt, który jest lepiej zrobiony, powstanie szybciej, bo nie będzie w nim zbędnych rzeczy.

Niestety, wiele Zespołów nie akceptuje podejścia inkrementalnego, bo wymaga ono często przerabiania rozwiązań, jakie zostały wytworzone w poprzednich Sprintach – ze względu na zmienność potrzeb interesariuszy. Padają oskarżenia o „dokładanie sobie pracy” i wygrywa wspomniany raz-a-dobrzyzm. A jest on fundamentalnie sprzeczny z ideą dekompozycji wymagań, bo przecież kompletne rozwiązanie problemu w wyniku podziału przestaną być kompletne, czyż nie? Oczywiście to bzdura, bo dekompozycja to podział problemu, a nie rozwiązania, ale zrozumienie tego ewidentnie bywa problemem.

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. W naturalny sposób będzie starał się 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. Następnie 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ń i odfiltrowanie z nich tego, co jest nieważne, mało wartościowe albo wręcz niepotrzebne. Drugim będzie zapewnienie, że Product Owner i 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 produktu) zacznie dbać o to, by takich zmian dało dokonywać się łatwiej, bezpieczniej i szybciej. To już jednak temat na zupełnie osobny artykuł.