Problemy z wymaganiami

Jak zajawiłem w artykule poświęconym problemom z niezrozumieniem i nieprawidłowym wykorzystaniem Story Points, drugim, równie popularnym, narzędziem, wprowadzanym do zwinnych zespołów w sposób mechaniczny, bezrefleksyjny i z mylnym założeniem – tak trzeba robić w Scrumie – są User Stories.

Temat jest niezwykle istotny jako, że obie wspomniane techniki wykorzystywane są w newralgicznych miejscach procesu wytwarzania oprogramowania – zapisywania wymagań (User Stories) i szacowania ich wielkości, w konsekwencji czasochłonności (Story Points). A zatem skutki ich nieprawidłowego wykorzystywania mogą być doprawdy opłakane.

Dodatkowym problemem jest też fakt, że usilne przymuszanie Product Ownerów i deweloperów do pisania wymagań w formacie User Stories jest jednym z popularnych źródeł zniechęcenia do używania Scruma, jako, że zamiast skupić się na programowaniu czy rozwoju produktu, czas tracony jest na wtłaczaniu wymagań do określonego wzorca.

Cóż, o punktach już było w przywołanym na początku tekście, przyszedł zatem czas na wymagania. I tym razem zacznę od krótkiego wtrętu semantyczno – lingwistycznego.

Analogicznie, jak w przypadku Story Points, poniekąd wbrew sobie, uważam że pojęcia User Stories nie należy spolszczać, szczególnie dosłownie. Pojęcie “historyjka” brzmi – w moim odczuciu i sztucznie, i infantylnie, podobnie jak “ajtemy” czy “tickety”. Z kolei “historia”, “opowieść” czy “element backlogu” – straszliwie nadęcie.

Z drugiej strony, klasyczne “wymaganie” jest przez wielu agile’owców szykanowane, jako słowo negatywnie nacechowane i z samej swojej definicji (za Słownikiem Języka Polskiego PWN: warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać) będące w sprzeczności ze zwinnym tworzeniem wymagań, gdzie powinno być miejsce na zmienność.

Innymi słowy, zawsze musi być jakiś problem.

Kto wymyślił pojęcie User Story? Jedni przypisują je Alistairowi Cockburnowi, inni oddają palmę pierwszeństwa Kentowi Beckowi, który miał je wprowadzić w eXtreme Programming. Tak czy inaczej, wszystko pozostaje w zwinnej rodzinie, obaj panowie są współtwórcami i sygnatariuszami Manifestu Agile. Znaczące cegiełki do popularyzacji terminu i sposobu jego wykorzystali dołożyli przede wszystkim: Ron Jeffries w 2001 artykułem Essential XP: Card, Conversation, Confirmation, Bill Wake znakomitym tekstem INVEST in Good Stories, and SMART Tasks z 2003 roku i w końcu niezrównany Mike Cohn, który rok później  wydał książkę – klasyk gatunku User Stories Applied. W zasadzie, to lektury obowiązkowe, jeśli w ogóle chcemy tę technikę wykorzystywać.

W telegraficznym skrócie przyjrzyjmy się jej najważniejszym założeniem User Stories.

Po pierwsze – powinny być pisane z perspektywy rzeczywistego użytkownika tworzonego systemu/funkcjonalności i wskazywać jego oczekiwanie. Ma to spowodować nasze pełne skupienie na jego perspektywie i potrzebach.

Po drugie – powinny jasno wskazywać, wyjaśniać po co wspomnianemu użytkownikowi taka, a nie inna funkcjonalność, dlaczego jej potrzebuje, co chce nią osiągnąć. To z kolei ma wykonawcom zadania wyeksponować jego motywację i umożliwić zaproponowanie różnych rozwiązań, mogących doprowadzić do osiągnięcia oczekiwanego rezultatu. Dodatkowo, znając potrzebę po co coś robimy, nasze zaangażowanie rośnie. Kiedy wiemy jaki problem rozwiązujemy, co należy uzyskać, możemy nie tylko coś zaproponować, ale wręcz zweryfikować i skontestować przyjęte założenia, być może całkowicie je zmienić, odkrywając rzeczywistą potrzebę klienta.

Po trzecie – i być może najważniejsze – powinny być przede wszystkim przyczynkiem do dyskusji. Nie dokumentacją czy oczekiwaniem, a zachętą do rozmowy. Konwersacja taka powinna odbyć się w gronie całego Zespołu Scrumowego (najczęściej w praktyce odbywa się to w trakcie Pielęgnacji Backlogu – czy to realizowanego w formie osobnego spotkania, czy to krótkiej sesji np. odbywającej się po Daily). Wszelkie wątpliwości, szczegóły, pytania powinny się rozgrywać na polu bezpośredniej rozmowy pomiędzy wykonawcami, a zleceniodawcą. Po latach zrozumieliśmy w IT, że – cytując Mike’a Cohna – mając wymaganie w formie zapisanej, zleceniodawca w najlepszym wypadku dostaje to, co zostało zapisane, a nie to, czego oczekiwał.

Mamy tu zatem spory przewrót w stosunku do waterfallowych czasów i przejście z wymagań zapisywanych, dyktowanych do dyskutowanych. Jak niezwykle trafnie twierdzi – znów – Mike Cohn, pisanie wymagań dotyczących oprogramowania, to problem komunikacyjny.  W swojej prezentacji z Norwegian Developer’s Conference z 2014 roku, słusznie zauważa, że tej komunikacji, nie może zdominować ani zleceniodawca (może wtedy nastąpić problem oderwania wymagań od rzeczywistości i możliwości) ani wykonawca (w efekcie mamy m.in. nadmiar technicznego żargonu).

A skoro już jesteśmy przy temacie zapisu to, po czwarte, User Stories powinny być zwięzłe, krótkie i napisane prostym, zrozumiałym dla każdego językiem.

Po piąte – szczegóły implementacyjne ich dotyczące powinny być wypisywane w tzw. kryteriach akceptacji. Są tacy, jak Roman Pichler, którzy twierdzą, że takowych kryteriów powinno być od trzech do pięciu, ja osobiście proponowałbym trzymać się po prostu zdrowego rozsądku.

W końcu, po szóste, i co jest chyba źródłem największych problemów, do zapisywania User Stories, stosuje się określony format.

Ten najpopularniejszy to:

Jako <użytkownik> chciałbym <funkcjonalność>, żeby <cel>.

A wariacji jego jest multum, od prostych, zmieniających szyk powyższego zdania, po nieco bardziej od niego odbiegające.

Jakie są główne różnice zwinnego zapisywania oczekiwań zleceniodawcy w stosunku do wcześniej dominujących modeli? To przede wszystkim postawienie na dyskusję, rozmowę z wykonawcami, zostawienie dla nich przestrzeni na przedstawienie swojego punktu widzenia – pomysłów, obaw. Oczekiwanie ma być dopiero punktem wyjścia do stworzenia rozwiązania, a nie – jak wcześniej – rozpisanym w najdrobniejszych szczegółach gotowym zestawem, który po prostu należy zrealizować zgodnie z tym, jak zostało to zapisane. Nastąpiło odejście od wielostronicowych szczegółowych dokumentów na rzecz zestawu niewielkich, krótkich oczekiwań, na bazie których wypracowuje się finalne rozwiązanie. I dopiero po ich zrealizowaniu tworzy się dokumentację. 

To jakie najczęściej widzę problemy z tymi User Stories?

1. Lepsze wrogiem dobrego

W zasadzie mógłbym przekopiować tak samo zatytułowany passus z tekstu o Story Points, zamieniając tylko używane pojęcie.

Jak świat długi i szeroki, tak niezwykle powszechne jest, że jeśli pracujemy zwinnie, to szacować musimy z wykorzystaniem Story Points, a wymagania zapisywać w formacie User Stories. Oczywiście, nic bardziej mylnego. Tradycyjnie, jako jedno ze źródeł tego można żartobliwie wskazać popularną JIRĘ, która wszak definiuje story jako odrębny typ wymagania ( w stosunku do zadania (task) czy błędu (bug)), natomiast oczywiście nie tu leży problem rozpowszechnienia tego mylnego podejścia.

User Story to kolejny przykład zwinnej techniki, która wydaje się banalna a w rzeczywistości jest złożona. Naprawdę trzeba sporo poczytać, sporo przepracować, przerobić w praktyce, żeby móc wykorzystać jej profity.

Zanim więc wywrócimy w naszych zespołach stoły i przymusimy, pardon, poprosimy Product Ownerów i innych o pisanie User Stories, odróbmy porządnie lekcje. Apeluję o to, aby decyzję o wprowadzeniu tego formatu, techniki, dobrze przemyśleć, mając na względzie przede wszystkim to co chcemy za jego pomocą osiągnąć, co uzyskać.

A przede wszystkim uprzednio dobrze przyjrzeć się jaki mamy punkt wyjścia, jak do tej pory wyglądał sposób zapisu i przekazywania zespołom deweloperskim wymagań. Może wystarczy go tylko lekko usprawnić?

Może wystarczy wzmocnić stopień partycypowania zespołu w tworzeniu finalnego rozwiązania, dać mu większe prawo głosu? Może trzeba tylko mocniej uwypuklić perspektywę, cel, do którego dążymy?

Żeby to zrobić nie potrzebujemy żadnych formatek, typów użytkowników. Formatów dobrego zapisywania wymagań użytkowników jest masa, a User Stories to tylko jedno z wielu możliwości. Nie zapominajmy o tym.

2. Jeden użytkownik

Jak pisałem wyżej, w centrum User Story, znajduje się – nomen omen – użytkownik. I tu zaczyna się podstawowa trudność. Trzeba bowiem takowych użytkowników swojego systemu zidentyfikować, rozpoznać, scharakteryzować. Zanim przystąpimy do pisania User Story, musimy na wylot znać naszych userów w kontekście używania przez nich naszego systemu. Inaczej po prostu nie ma to najmniejszego sensu. Jak mamy wczuć się w danego użytkownika i jego potrzebę, jeśli go nie znamy.. Wtenczas klient staje się emanacją naszego widzimisię i patrzymy na zadania do realizowania z własnej, a nie jego perspektywy.

Jak tych użytkowników poznać? To proste – rozmawiając z nimi, w sposób mniej (formularze) lub bardziej (rozmowa) bezpośredni i obserwując ich zachowania w systemie.

UXowcy tworzą i wykorzystują do reprezentacji użytkowników systemu tzw. persony, warto się z tym tematem dobrze zapoznać.

Tymczasem najczęściej w praktyce znamy jeden typ użytkownika naszego systemu, nazywamy go użytkownik i jedziemy z Jako użytkownik. 

W tym momencie pisanie User Stories mija się z jakimkolwiek celem. Owszem, mając zapisaną intencję, część po co/aby/dlaczego, mamy jakiś wycinek wiedzy po co daną funkcjonalność realizujemy, czemu ma służyć. Jest to jednak za mało, jeśli wszystkich naszych użytkowników umieszczamy w jednej szufladce, nie ma sensu bawić się w format User Stories. Bo to zbędny narzut.

Doprawdy mniejszość systemów, które tworzymy ma tylko jeden typ użytkownika. Najczęściej możemy rozpoznać ich kilka, wykorzystujących naszą aplikację wedle różnych intencji, potrzeb i wedle z grubsza określonych schematów. Weźmy prościutki przykład aplikacji pogodowej. Inne oczekiwania wobec jej interfejsu będzie miał ktoś, kto szybko potrzebuje tylko sprawdzić czy jutro będzie potrzebował parasola, od osoby, która przygotowuje tor na mecz żużlowy i musi dokładnie wiedzieć gdzie, kiedy i jak intensywne będą opady. A dodajmy do tego, na przykład, turystę, który planuje całodniową górską wycieczkę czy rodzinę zastanawiającą się nad miejscem weekendowego wypadu.

Dobrze rozpoznając i rozpisując charakterystyki swoich użytkowników, możemy faktycznie czerpać z dobrodziejstwa User Stories, bo poza konkretną, wyrażoną w danym wymaganiu potrzebą, znamy jeszcze lepiej kontekst – oczekiwania, typowe zachowania, sposób wykorzystywania systemu osoby, która dane oczekiwanie wyraża.

Nie zabierajmy się za User Stories, nie znając swoich użytkowników.

3. Aplikacja dla Product Ownerów

Kolejny typowy błąd, to pisanie User Stories rozpoczynających się od Jako Product Owner. Mają one sens tylko w jednym przypadku – gdyśmy pisali aplikację dla Product Ownerów, co jednak, jak sądzę, jest przyjemnością, omijającą znaczącą część naszych czytelników.

Kilka przykładów z życia wziętych:

Jako Product Owner chciałbym opomiarować ilość kliknięć w guzik “ok”, aby móc podejmować jak najlepsze decyzje biznesowe.

Jako Product Owner potrzebuję panel administratora forum, w którym będę mógł zarządzać użytkownikami (tworzyć, usuwać, edytować, czytać dane o nich)

Jako Product Owner chciałbym sprawdzić jakie są możliwości walidacji formularza rejestracji i  czasochłonność ich wykonania, żeby móc wybrać najlepsze rozwiązania, rozwijające aplikację. 

No właśnie… Najczęściej tak sformułowane User Stories widzę, kiedy trzeba zrealizować potrzebę istotną z punktu widzenia zarządzającego aplikacją i jej rozwojem, a niekoniecznie widoczną, istotną, wnoszącą cokolwiek dla końcowego użytkownika. Przykładowo: różnego rodzaju opomiarowania, funkcje administracyjne, tzw. “proof of concept” czy “researche”.

Czasem mamy tu po prostu mylny punkt widzenia i piszemy z punktu widzenia Product Ownera, bo tak  po prostu jest łatwiej. A czasem – najczęściej – próbujemy po prostu wcisnąć w format User Stories coś, co nie ma żadnego związku z użytkownikiem.

Wspomniane

Jako Product Owner potrzebuję panel administratora forum, w którym będę mógł zarządzać użytkownikami (tworzyć, usuwać, edytować, czytać dane o nich)

jest wymaganiem typowym z punktu widzenia użytkownika – administratora systemu, a nie Product Ownera i tu – odpowiednio je przeredagowując – moglibyśmy, z pewnym zyskiem uzyskać fajne User Stories, podkreślając rzeczywistą potrzebę administratora forum, nie Product Ownera.

Z kolei pierwsze i trzecie wymaganie ze wspomnianej listy? Warto zapisać je po prostu w inny sposób, dobrze podkreślając swoją intencję.

Na koniec tego punktu zastanówmy się nad różnicą pomiędzy wymaganiem zapisanym w sposób taki:

Jako redaktor młynarze.com, chciałbym napisać artykuł o problemach z wymaganiami, ponieważ dostrzegam, że temat ten powoduje sporo problemów wśród wielu adeptów Scruma.

i taki:

Jako początkujący Scrum Master, chciałbym dowiedzieć się co charakteryzuje technikę User Stories i kiedy ją stosować, żeby móc efektywnie ją wykorzystywać.

Która z wersji powinna przynieść mi więcej wartości, aby przygotować lepszy (czy, bardziej marketingowo: umiejętniej stargetowany) artykuł?

4. Używane do wymagań technicznych

Ten problem wzbudza we mnie chyba największy smutek i złość.

Ileż to się naczytałem wymagań typu:

Jako system chciałbym działać szybciej w momencie łączenia się z systemem bankowym, żeby użytkownicy byli ze mnie bardziej zadowoleni.

Jako programista chciałbym, aby moduł łączenia się z systemami bankowymi działał szybciej, żeby nie było ryzyka błędów 408 i 500.

Jako programista chciałbym, żeby klasa CorrosionOfConformity została zrefaktoryzowana, żebym mógł szybciej i sprawniej dokonywać w niej zmian.

Jako programista chciałbym, po wysłaniu requestu GET na endpoint /foofighters otrzymać 200 OK z JSONem zawierającym listę pojazdów w formacie stringa i sklad ich załogi w formacie tablica zawierającej stringi.

Kiedy czytamy takie wymagania, na myśl przychodzi słowo – groteska. Ale jakże często na takie wymagania natrafiamy. I nie wiem kto tu jest bardziej winny: Scrum Master, który coś takiego wymusza lub przyzwala, toleruje, czy deweloper, który zagryza zęby i wypisuje takie rzeczy.

Ciężko jest typowo techniczne, programistyczne zadanie przełożyć na standardowy format User Story. Jeszcze trudniej znaleźć odpowiedź na pytanie, po jaką cholerę to robić?

Można powiedzieć, że jest to krok dalej od typowego wymagania technicznego autorstwa programisty typu:

zmienić wszystkie stare exceptiony na multicatche 

zoptymalizować importantButSlowLoader.js

zobaczyć czy rzeczy z QueenAlbums da się przenieść na traitsy

Niemniej jednak niewielki.

Na pewno powinniśmy dbać o ten typ wymagań, tak samo jak o każdy inny. I nie powinno być tu żadnej taryfy ulgowej, uproszczeń, skrótów, innych standardów.

Według mnie jednakże wystarczy na początek zapewnić dwie sprawy.

A zatem: dbajmy o to, żeby w wymaganiach typowo technicznych, dotyczących refactoringów, testów, usprawnień dotyczących kodu itp. zawsze znalazła się informacją po co chcemy to robić, czemu ma to służyć, jakie profity chcemy uzyskać. I zapiszmy to wszystko w sposób zrozumiały, pozbawiony technicznego slangu.

A po drugie: omówmy sobie zawsze takie wymaganie z Product Ownerem. Miejmy pewność, że jest tu pełne zrozumienie i akceptacja tego co ma zostać zrobione.

5. Wszystko User Stories

Podsumowując dwa wcześniejsze punkty, jednym z głównych problemów z User Stories i backlogami jest działanie na zasadzie wszystko albo nic. 

Jeśli już są wprowadzane User Stories, to chcemy mieć je wszędzie, stosować do wszystkich wymagań. 

O ile, jak wspomniałem chwilę temu, warto mieć konkretny standard oczekiwań wobec wymagań trafiających do backlogu i konsekwentnie tego wymagać i się tego trzymać (wprowadzając na przykład tak zwane Definition Of Ready), tak niekoniecznie w tym standardzie powinien być wymuszony określony format czy typ użytkownika.

Trzymajmy się przede wszystkim zasady wskazywania intencji, celu, dyskusji, pisania zrozumiałym językiem, pamiętajmy o zasadzie INVEST. Format jest doprawdy najmniej istotny.

6. Brak możliwości dyskusji

Jednym z charakterystycznych problemów pracy z “zewnętrznym” Product Ownerem, a już zwłaszcza takim, dostępnym dla zespołu tylko zdalnie, w innym mieście, czy czasami innej strefie czasowej, jest jego niewystarczająca obecność w życiu zespołu. Problemów jakie to niesie i które trzeba rozwiązać, jest mnóstwo, natomiast jednym z głównych jest brak możliwości należytego przedyskutowania wymagań.

Najczęściej, przy utrudnionym kontakcie z zespołem, siłą rzeczy Product Owner stara się podesłać wtedy w wymaganiu najwięcej szczegółów, wskazując wręcz gotowe rozwiązania. I wraca “stare”, mimo że często opakowane w “szlachetne” Jako użytkownik.

Mniejsza już tu – dla odmiany – o formę, chodzi oczywiście o kwestię braku dyskusji. W tym momencie wracamy do klimatu dokumentacji zamiast dyskusji i  spekulacji na temat rzeczywistych potrzeb.

W takiej sytuacji niełatwym obowiązkiem Scrum Mastera jest próba wyciśnięcia co się da z takiej konfiguracji pracy z Product Ownerem/interesariuszem. Najważniejsze jest doprowadzenie do interakcji pomiędzy nim, a zespołem w kontekście realizowanych zadań. Nawet, jeśli na początku będzie się to odbywało tylko w formie pisanej, jest to już coś. Ważne jednak, żeby miało to miejsce jeszcze przed podjęciem danego zadania do wykonania, a nie na zasadzie pytań skupiających się już na samej realizacji i uzyskiwania potrzebnych szczegółów.

Wspomniałem, że to typowe dla pracy z zewnętrznymi Product Ownerami. Niestety, nie ma tak dobrze i sytuacja występuje także kiedy klient jest “wewnętrzny”, a zespół i Product Owner pracują w jednym budynku. Tyle, że wówczas możliwości Scrum Mastera są dużo szersze i łatwiejsze do wdrożenia.

Na koniec

Nie będziemy mieć dobrze działającego zespołu, z zadowolonymi ludźmi na pokładzie, sprawnie i szybko dostarczającego działające oprogramowanie, jeśli nie zadbamy o porządek w procesie formułowania i zapisywania wymagań, które trafiają do backlogu.

Pamiętajmy, że najważniejsza jest ich klarowność, czytelność, zrozumiałość, jasność powodu wykonywania i dyskusja na ich temat w gronie zleceniodawca – wykonawca.

Miejmy w pamięci INVEST – dbajmy o to, żeby wymagania były wartościowe, możliwie niezależne od innych, a ich wielkość pozwalała na ich realizację w krótkim czasie, na przykład jednego sprintu.

Nie przykładajmy nadmiernej wagi do formy. A przede wszystkim nie bądźmy jej niewolnikiem.

I wykorzystujmy User Stories, tam gdzie możemy w pełni wykorzystać profity skupienia na perspektywie dobrze rozpoznanego użytkownika.

#backlog#ProductOwner#ScrumMaster#UserStories#wymagania