W pierwszej części cyklu 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 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ą (techniczną). 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 produktem są krzesła, to Definicja Ukończenia określała będzie, w jaki sposób mają one być budowane, a kryteria akceptacji wskażą rodzaj materiałów, które powinny zostać do tego użyte, oczekiwaną kolorystykę itd. Jeśli z jakiegoś powodu powstanie krzesło metalowe zamiast drewnianego, z pluszowymi obiciami zamiast skórzanych, to będzie można na nim siedzieć, jeśli tylko warunki Definicji Ukończenia będą zaspokojone (powstanie mebel nadający się do użytku). Rozminięcie się z kryteriami akceptacyjnymi nie spowoduje, że krzesło przestanie być krzesłem – będzie to natomiast sygnał, że nie jest to krzesło zgodne z oczekiwaniami.

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 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 muszą być precyzyjne i jednoznaczne, 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 wykłócenia 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: restrykcyjna 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 element Backlogu Produktu „nadawał się do realizacji” – przy czym rzadko robią to po to, by faktycznie mieć podpowiedź, o co warto zadbać w czasie pielęgnacji. Częściej chodzi o możliwość odmowy podjęcia jakiegoś elementu Backlogu do realizacji, jeśli niespełniony jest choć jeden warunek 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ędzie podejmowanych 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, zwłaszcza jeśli już są one chłodne. 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, które elementy Backlogu Produktu są dostatecznie małe i zrozumiałe, oraz czy Developerzy będą w stanie zaplanować ich realizację i ukończyć je w Sprincie. Oczywiście to zawsze jest prognoza i nie ma gwarancji, że już w trakcie realizacji nie ujawnią się nieprzewidziane trudności. Warto jednak pamiętać, że nawet ciągnąca się w nieskończoność pielęgnacja owocuje jedynie przewidywaniami. Im wcześniej Zespół zacznie coś robić, tym wcześniej zastąpi spekulacje i domysły wiedzą, jak jest naprawdę.

Sposób 8: zapisywanie wszystkiego jako user stories

Panaceum na wszystkie problemy związane z pielęgnacją ma być, zdaniem wielu Zespołów, zapisanie elementów Backlogu Produktu 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 elementy Backlogu 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, dowiedzieć się będzie można dopiero z lektury komentarzy do niej, załączników itd.

Drugim powodem, mocno związanym z poprzednim, jest częsta generalizacja aktora sporządzanych na siłę historyjek. Nie odwołują się one do naprawdę specyficznej persony lub konkretnego użytkownika, tylko rozpoczynają się zawsze od frazy „jako użytkownik…”. W praktyce wydłuża to jedynie zapis, nie wnosząc do niego żadnej przydatnej informacji. Zdarzyło mi się spotkać Zespoły, które rozpoczynały każdą historyjkę skrótem „JU…”, żeby nie tracić czasu i miejsca na ekranie…

Tymczasem praktyka tworzenia historyjek użytkownika opiera się właśnie na tym, że opisujemy potrzeby konkretnych użytkowników i im bardziej specyficznie da się to zrobić, tym lepiej.

Trzecim powodem, dla którego użycie wszędzie i do wszystkiego historyjek użytkownika nie ma sensu, jest nieuchronne pojawienie się elementów Backlogu Produktu opisujących potrzeby całego działu firmy albo wymogi systemów informatycznych, konkretnego narzędzia, technologii, paragrafów 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 elementami Backlogu Produktu to nie tylko format zapisu, ale cały proces dyskusji o potrzebach. Taka historyjka 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 praktyki, nijak nie pozwala na lepsze zrozumienie potrzeb użytkowników i zbudowanie lepszego 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 praktyce chodzi.

Wiąże się z tym kolejny powód nikłej wartości używania na siłę historyjek użytkownika: punktem wyjścia do ich tworzenia 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 w jaki sposób opisać jego „potrzebę”, by ktoś domyślił się, o co nam tak naprawdę chodzi. Taki sposób tworzenia „historyjek użytkownika” jest dokładnym przeciwieństwem zasad praktyki, którą rzekomo stosujemy.

Upór, by pisać historyjki użytkownika i trzymać się kurczowo „obowiązkowego formatu” (przypominam: nieistniejącego), 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 elementu Backlogu Produktu 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 ten element klarownym i wystarczająco dobrze zdefiniowanym.

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 element Backlogu Produktu będzie realizowany – pozostawiając decyzję Developerom.

I na koniec chyba najważniejszy problem, jaki powoduje traktowanie historyjek 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 skoro historyjki użytkownika opisują potrzeby, to jeśli 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.

Dlatego, zamiast używać historyjek użytkownika na siłę, użyjmy ich tam, gdzie ma to sens – posługując się tą praktyka poprawnie (czyli nie traktując jej tylko jako format zapisu). Pielęgnacja obejmować wtedy będzie też konwersację z użytkownikami o historyjkach, które ich dotyczą.

Natomiast wymagania, które nie są wynikiem istnienia potrzeb 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, 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 np. do historyjek użytkownika jako ich kryteria akceptacyjne.

Przy czym ja zachęcam do uczynienia ich po prostu jednym z wymogów zawartych w Definicji Ukończenia, którą posługuje się Zespół. Wszak po uzyskaniu wymaganej wydajności czy stabilności trzeba ten stan utrzymywać już na stałe.

To nadal nie koniec

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