W pierwszej części artykułu opisałem najczęstsze problemy z Pielęgnacją Backlogu Produktu, z jakimi się zetknąłem. Pora opisać kilka kolejnych.

Problem #6: kryteria akceptacji jako kontrakt

Spisywanie kryteriów akceptacji jest do tego stopnia popularnie, że w wielu Zespołach uznaje się tę praktykę za coś obowiązkowego w metodach zwinnych. W rzeczywistości ani Scrum, ani prawie żadna inna metoda Agile wprost nie wymaga formalizowania warunków, jakie muszą być spełnione, aby wymaganie uznać za zrealizowane.

Tu dygresja: należy rozróżnić pojęcie Definicji Ukończenia (znanej np. ze Scruma) od kryteriów akceptacji – to nie to samo. Definicja Ukończenia opisuje kryteria, które musi spełnić produkt jako całość, by w ogóle uznać, że prace nad nim zostały zakończone, i by zapewnić jego minimalną wymaganą jakość strukturalną (technologiczną). To, że powstał taki produkt, nie determinuje jeszcze, czy to jest właściwy produkt. Za zapewnienie tego odpowiadają kryteria akceptacyjne, jeśli się nimi posłużymy.

Przykładowo, jeśli produkowalibyśmy krzesła, Definicja Ukończenia spowoduje, że powstanie mebel, na którym da się siedzieć, i którego da się bezpiecznie użytkować. Przy czym może okazać się, że obicia miały być czerwone – a są niebieskie, konstrukcja miała być drewniana – a jest stalowa, i brakuje podłokietników – choć miały być zamontowane. Ta niezgodność z oczekiwaniami nie spowoduje, że krzesło przestanie być krzesłem – wciąż będzie się na nim dało siedzieć, bo jest ukończone. A mówiąc precyzyjnie: jest ono ukończone, choć nie spełnia zdefiniowanych wymagań. Spełnia Definicję Ukończenia, ale nie spełnia niektórych (lub nie spełnia żadnych) kryteriów akceptacyjnych.

Jeśli wymogi odnośnie do kolorów, rodzaju materiału czy specyficznych funkcji krzesła, zapisane zostaną jako kryteria akceptacji – ich niespełnienie oznaczać będzie, że zbudowaliśmy niewłaściwy mebel, najpewniej wymagający poprawki. Spisywanie takich kryteriów ma spowodować, że prace Developerów nie pójdą w złym kierunku. Przy czym to, że kryteria wytyczają kierunek, nie powinno oznaczać, że stanowią kontrakt, który musi być literalnie wypełniony.

Jeśli użyjemy kryteriów akceptacji jako nienaruszalnych warunków oceny, czy powstało właściwe rozwiązanie, jesteśmy zmuszeni do zdefiniowania z góry, jakie to „właściwe rozwiązanie” ma być. A więc spróbujemy zrobić to, czego właściwie nie da się zrobić skutecznie w środowisku o niestabilnej złożoności (zmiennym, nieprzewidywalnym i jednocześnie skomplikowanym). Wszak używamy np. Scruma dlatego, że nie mamy pewności, jaki produkt odpowie dobrze na zmienne potrzeby interesariuszy. Jak więc moglibyśmy ze stuprocentową pewnością określić, jaki produkt będzie właściwy?

Co więcej, takie traktowanie kryteriów akceptacji stanowi silny sygnał dla Developerów, że organizacji, która ich zatrudnia, nie chodzi o pragmatyczne poszukiwanie najlepszych i najbardziej wartościowych rozwiązań, możliwych do wytworzenia w realnym czasie, tylko o literalne „dowiezienie” tego, co zapisane zostało w wymaganiach. A stąd już krok do uznania, że nieważne, co robimy i jak to robimy, byleby robione to było zgodnie z opisem w Backlogu Produktu i na czas. Takie użycie metod zwinnych jest wyjątkowo marne, bo daje znikome korzyści.

Jeśli więc posługujemy się kryteriami akceptacyjnymi, bądźmy gotowi do ich modyfikacji już na etapie realizacji wymagań albo odstąpienia od spełnienia niektórych z nich. Wracając do przykładu z krzesłem: to, że ma inny kolor i zrobione jest z innego materiału, nie oznacza, że nie nada się ono do tego, do czego miało zostać użyte – zanim zaczniemy je przerabiać, zapytajmy o zdanie tych, którzy krzesło zamówili.

Z kronikarskiego obowiązku: sytuacja, w której nie udało się wytworzyć produktu zgodnie z Definicją Ukończenia, a mimo to twierdzimy, że spełniliśmy kryteria akceptacji, byłaby kuriozalna. Bo cóż z tego, że nasze krzesło byłoby ze stali, z odpowiednimi obiciami i podłokietnikami, gdyby się rozlatywało, raniło, plamiło lub nie było stabilne? Taki „produkt” nie ma przecież żadnej wartości i nie da się uznać go za nadający do użycia.

Problem #7: formalizm, czyli Definicja Gotowości

Inną formą zbędnego formalizmu, który negatywnie wpływa na Pielęgnację Backlogu Produktu, jest ustanowienie przez Zespół Definicji Gotowości. Pisałem już o tym, więc jedynie pokrótce przypomnę, że wiele Zespołów sporządza zapis kryteriów, jakie muszą być wypełnione, by wymaganie „nadawało się do realizacji” – po czym rzadko robią to po to, by faktycznie mieć podpowiedź, o co warto zadbać w czasie Pielęgnacji. Częściej chodzi o uzyskanie możliwości odmowy podjęcia wymagań do realizacji, jeśli niespełnione są jakieś warunki z obowiązującej Definicji Gotowości. Czyli o pewną formę zabezpieczenia się przed koniecznością realizacji „źle zdefiniowanych” elementów Backlogu.

Im bardziej formalny staje się proces Pielęgnacji, tym bardziej będzie szczegółowy i tym więcej decyzji będziemy podejmować z dużym wyprzedzeniem. Definicja Gotowości jest niezłym generatorem wielu z opisanych wcześniej problemów i błędów w procesie Pielęgnacji. Jest też całkiem skuteczna w psuciu relacji między Developerami a Product Ownerem w Zespole, gdzie te relacje już są nienajlepsze. Pozytywny wpływ tej Definicji na sposób pracy Zespołu jest potencjalnie możliwy, ale… no, właśnie, potencjalnie – ja jeszcze takiego Zespołu nie spotkałem.

Jeżeli Zespół umie ze sobą rozmawiać, ma wspólny cel i zależy mu na jego osiągnięciu – Definicja Gotowości jest zbędna. Zamiast wprowadzać formalizmy tego typu, Zespół dokona wspólnej oceny czy wymaganie jest dostatecznie małe i zrozumiałe, oraz czy Developerzy będą w stanie zaplanować jego realizację i ukończyć je w Sprincie. Oczywiście to zawsze jest prognoza – im wcześniej zaczniemy działać (zamiast spierać się o „gotowość” i z uporem maniaka doprecyzować na podstawie spekulacji i analiz), tym wcześniej dowiemy się, jak jest naprawdę.

Problem #8: zapisywanie wszystkiego jako User Story

Panaceum na wszystkie problemy związane z Pielęgnacją ma być, zdaniem wielu Zespołów, zapisanie ich w formacie „jako użytkownik chcę tego i tego, aby osiągnąć to i tamto”, wywodzącym się z popularnej techniki opisywania Historyjek Użytkownika. Niestety, to panaceum nie działa, z kilku powodów.

Pierwszym jest oczywisty fakt, że nie wszystkie wymagania opisują potrzeby użytkowników. Wiele zmian w produkcie dokonywanych jest z powodów czysto technologicznych, czasami wynika to z konieczności dostosowania rozwiązania do jakichś standardów, przepisów prawa, ograniczeń wydajnościowych itd.

Można, rzecz jasna, na siłę poszukiwać użytkownika, któremu przypiszemy taką potrzebę – ale wtedy, zamiast podnosić przejrzystość Backlogu Produktu, mamy sporą szansę ją obniżyć. Pojawią się bardzo „generyczne” hasła, które w sumie niewiele znaczą, a o co chodzi w „historyjce” (cudzysłów celowy), dowiedzieć się będzie można dopiero z lektury komentarzy, załączników itd.

Drugim powodem, mocno związanym z poprzednim, jest częsta generalizacja aktora sporządzanych na siłę „historyjek”. Zamiast wybrać naprawdę specyficzną personę lub konkretnego użytkownika, wszystkie wymagania (albo większość z nich) rozpoczynamy od „jako użytkownik…”. Taki zapis nie niesie żadnego głębszego kontekstu i w sumie usunięcie tej części „historyjki” nie uczyniłoby jej żadnej wymiernej szkody. I faktycznie, zdarzają się Zespoły, które wręcz zapisują „JU…” na początku każdego wymagania, żeby było krócej.

Tymczasem technika Historyjek Użytkownika opiera się właśnie na tym, że opisujemy konkretne potrzeby konkretnych użytkowników, im bardziej specyficznie da się to zrobić, tym lepiej.

Trzecim powodem, dla którym użycie wszędzie i do wszystkiego Historyjek Użytkownika nie ma sensu, jest nieuchronne pojawienie się wymagań opisujących potrzeby całego działu firmy, systemów informatycznych, konkretnego narzędzia czy technologii, paragrafu obowiązującego prawa itd. Powstają wtedy „historyjki użytkownika” pozbawione użytkownika.

Czemu to złe? Bo ideą zapisywania Historyjek była konwersacja z użytkownikiem, którego potrzebę opisujemy i jej potwierdzenie z tymże użytkownikiem. Jak rozmawiać z działem firmy? Albo z systemem informatycznym? Co może nam doprecyzować narzędzie? Na jakie pytanie odpowie technologia?

I tak dochodzimy do czwartego powodu: prawdziwe Historyjki Użytkownika, wykorzystane jako jeden ze sposobów pracy z wymaganiami (uwaga: niejedyny!), to nie tylko format zapisu, ale cały proces dyskusji o potrzebach. Taka Historyjka Użytkownika służy jako stymulator konwersacji i token komunikacyjny, ułatwiający przypomnienie sobie, o czym i z kim rozmawialiśmy, i czy w ogóle taka rozmowa się odbyła.

Użycie „historyjek użytkownika”, czyli wyłącznie formatu zapisu znanego z tej techniki, nijak nie pozwala na lepsze zrozumienie potrzeb użytkowników i zbudowanie właściwszego produktu. Tym formatem można posługiwać się bez jakiejkolwiek bezpośredniej komunikacji. Z drugiej strony prawdziwe Historyjki Użytkownika mogą być zapisywane w dowolnym formacie, bo przecież to nie o format zapisu w tej technice chodzi.

Wiąże się z tym kolejny powód nikłej wartości używania na siłę Historyjek Użytkownika: punktem wyjścia do nich w takim przypadku jest prawie zawsze rozwiązanie, a nie potrzeba. Inaczej mówiąc, najpierw wymyślamy, co chcemy zbudować, po czym kombinujemy, jakiego użytkownika do tego rozwiązania „dopiąć” i jak opisać jego „potrzebę” tak, by ktoś domyślił się, o co nam tak naprawdę chodzi. Taki sposób tworzenia „historyjek użytkownika” jest dokładnym przeciwieństwem techniki, którą rzekomo stosujemy.

Upór, by pisać Historyjki Użytkownika i trzymać się kurczowo „obowiązkowego formatu”, ma jeszcze jedną wadę: te zapisy stają się wtedy bardzo rozbudowane, bo przecież trzeba jakoś upchnąć w jednym zdaniu wszystko, o co nam chodzi.

A przecież prawdziwe Historyjki Użytkownika to przede wszystkim opis potrzeby, dostarczenie kontekstu użytkownika, wyjaśnienie wartości, do której osiągnięcia on dąży. Takiemu „nagłówkowi wymagania” często musi towarzyszyć wiele dodatkowych informacji: przykładów, propozycji rozwiązań, zapisów różnych ustaleń, być może lista kryteriów akceptacji – cokolwiek uczyni wymaganie bardziej użytecznym.

Przy czym sama Historyjka Użytkownika ma pomóc uniknąć sytuacji, że zrobimy wszystko, o czym była mowa, ale rozminiemy się z potrzebą użytkownika. Ułatwia też pozostawienie niektórych kwestii nierozstrzygniętych do momentu, kiedy wymaganie będzie realizowane – pozostawiając decyzję Developerom.

I na koniec chyba najważniejszy problem, jaki powoduje takie podejście do Historyjek – traktowanych jako coś obowiązkowego. Gdy zaczynamy ich używać po prostu jako opisów zmian w produkcie, naturalne będzie to, że jednej zmianie odpowiadać będzie jedna „historyjka”. No, bo po co pisać dwie „takie same historyjki”?

Tymczasem Historyjki Użytkownika, takie prawdziwe, opisują potrzeby – jeśli więc są dwie różne potrzeby jednego użytkownika albo „takie same” potrzeby dwóch różnych użytkowników, sporządzimy dwie Historyjki. Po pierwsze dlatego, że jednak potrzeby nie muszą ostatecznie być „takie same” (stąd cudzysłów). Po drugie dlatego, że może się okazać, iż nawet dokładnie taka sama potrzeba dwóch użytkowników wymaga zupełnie różnych rozwiązań. I wreszcie po trzecie: bo będziemy wiedzieć czyje potrzeby i z jakiego powodu zaspokajamy. Zrozumienie tego, co robimy, ułatwia podejmowanie decyzji o tym, co i jak robić, oraz czego nie robić.

Dlatego, zamiast używać „historyjek użytkownika” na siłę, użyjmy Historyjek Użytkownika tam, gdzie ma to sens – posługując się tą techniką poprawnie (czyli nie traktując jej tylko jako format zapisu). Pielęgnacja obejmować wtedy będzie nie tylko samą pracę z zapisywaniem wymagań, ale też konwersację o nich z użytkownikami, ekspertami i każdym, kto ma wpływ na produkt i kierunek jego rozwoju.

Natomiast wymagania, które nie są związane z potrzebami konkretnych użytkowników, zapisujmy w sposób, jaki będzie dla nich najefektywniejszy. Np. jako scenariusze behawioralne czy Przypadki Użycia (ang. Use Cases).

Specyficzne podejście może być niezbędne w przypadku wymagań niefunkcjonalnych, czyli takich związanych z wydajnością, bezpieczeństwem, użytecznością itd. Czasami będą miały po prostu formę wymagania opisanego tekstem, być może z listą warunków, jakie muszą być spełnione. Nierzadko zostaną dołączone do innych wymagań (w tym Historyjek Użytkownika) jako ich kryteria akceptacyjne.

Natomiast po tym, jak uda się takie wymogi niefunkcjonalne zaspokoić, osiągnięty w ten sposób stan produktu powinien być utrzymywany na stałe. Aby zapewnić, że uzyskanej wydajności czy stabilności nie utracimy, nie będziemy już dodawać co Sprint nowych wymagań albo kryteriów akceptacyjnych – zamiast tego uzupełnimy Definicję Ukończenia stosownymi zapisami.

To jeszcze nie koniec…

Zachęcam do lektury trzeciej części artykułu, w której opisuję kolejnych kilka błędów związanych z procesem Pielęgnacji Backlogu Produktu.

Zdjęcie: Loan