W pierwszej części artykułu opisałem najczęstsze problemy z utrzymaniem Backlogu Produktu, z jakimi się zetknąłem. Pora opisać kilka kolejnych sposobów na wyrządzenie szkód za pomocą pielęgnacji.

Sposób #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 chyba żadna inna metoda Agile wprost nie wymaga formalizowania warunków, jakie muszą być spełnione, aby wytworzony produkt uznać za właściwy.

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 warunki, które muszą zostać spełnione, aby produkt jako całość nadawał się do użycia, a prace nad nim mogły być traktowane jako w pełni zakończone. Inaczej mówiąc, Definicja ma zapewnić jego minimalną jakość strukturalną (technologiczną). Jej spełnienie nie oznacza automatycznie, że produkt jest zgodny z oczekiwaniami użytkowników. Te ostatnie mogą być opisane właśnie za pomocą kryteriów akceptacyjnych, które definiują oczekiwany poziom jakości funkcjonalnej (użytkowej).

Przykładowo, jeśli klienci oczekują drewnianego krzesła ze skórzanymi obiciami, to Definicja Ukończenia określała będzie, w jaki sposób takie krzesło ma być budowane, a kryteria akceptacji wskażą rodzaj materiałów, które powinny zostać do tego użyte. Jeśli z jakiegoś powodu powstanie krzesło metalowe z pluszowymi obiciami, które nadaje się do użytku (warunki Definicji Ukończenia będą zaspokojone), to rozminięcie się z kryteriami akceptacyjnymi nie spowoduje, że na meblu nie będzie się dało siedzieć.

Definiowanie kryteriów akceptacyjnych ma ułatwić Developerom lepsze zrozumienie oczekiwań interesariuszy, ale nie powinny one nigdy stanowić kontraktu, który musi być literalnie wypełniony. Z kilku powodów.

Po pierwsze, to wymagałoby określenia z góry jaki produkt będzie właściwy i to na tyle jednoznacznie, by dało się to zapisać w formie konkretnych warunków, których spełnienie można bezspornie wykazać. W środowisku o niestabilnej złożoności (zmiennym, nieprzewidywalnym i jednocześnie skomplikowanym) tego nie da się zrobić. Wszak używamy np. Scruma dlatego, że nie mamy pewności, jaki produkt odpowie dobrze na zmienne potrzeby interesariuszy.

Po drugie, takie traktowanie kryteriów akceptacji stanowi silny sygnał dla Developerów, że powinni skupić się na „dowiezieniu” tego, co zapisane zostało w kryteriach akceptacji zamiast na poszukiwaniu najlepszych i najbardziej wartościowych rozwiązań. A stąd już krok do uznania, że nieważne, co robią i jak to robią, byleby robione to było zgodnie z opisem w Backlogu Produktu i na czas. Takie użycie metod zwinnych jest wyjątkowo marne.

Po trzecie, kryteria akceptacji traktowane jako „warunki odbioru” nie mogą być zbyt ogólne, a jednocześnie im będzie ich więcej, im bardziej szczegółowe się staną i im bardziej formalnie będą traktowane, tym mniej przestrzeni pozostanie dla Developerów do podejmowania samodzielnych decyzji. Poczucie, że są bardziej wykonawcami prac zleconych niż współtwórcami produktu, nie będzie sprzyjać ich motywacji do pracy.

Z tym wiąże się pośrednio kolejna kwestia: jeśli Developerzy są rozliczani ze spełnienia kryteriów akceptacji, to oczywiste, że będą naciskać na ich kompletność i precyzję. Zespół poświęcał będzie na pielęgnację Backlogu Produktu mnóstwo czasu, a niewykluczone, że wykształci się w nim wąska grupa „analityków”, którzy będą heroicznie walczyć o „dobrze zdefiniowane wymagania”. Z czasem proces rozwoju produktu będzie coraz bardziej przywodził na myśl klasyczne metody projektowe.

I wreszcie po piąte: podstawą wszystkich metod zwinnych jest współpraca z interesariuszami i szybkie reagowanie na zmiany (kłaniają się dwa ostatnie punkty Manifestu Agile), czego nie da się realnie uzyskać bez minimum elastyczności ze strony wszystkich uczestników procesu rozwoju produktu. Nie można oczekiwać od Developerów podjęcia szybkich działań bez wcześniejszego użarcia się o „bezpieczne” dla nich kryteria akceptacyjne, jeśli z ich spełnienia są potem rozliczani.

Jeśli więc posługujemy się kryteriami akceptacyjnymi, bądźmy gotowi do ich modyfikacji już na etapie realizacji zmian w produkcie, albo do rezygnacji z niektórych z nich. Wracając do przykładu z krzesłem: to, że ma zły kolor i zrobione jest z niewłaściwego materiału, nie oznacza, że nie nada się ono do tego, do czego miało zostać użyte – zapytajmy o zdanie tych, którzy krzesło zamówili.

Z kronikarskiego obowiązku dodam, że 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. Jeśli produkt nie nadaje się do użycia, nie da się też za jego pomocą zaspokoić czyichkolwiek potrzeb, a bez tego, żadne kryterium akceptacji spełnione być nie może.

Sposób #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ę.

Sposób #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.