Dzień 8 – Historyjki użytkownika

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Co to jest historyjka użytkownika (user story)?

Historyjki użytkownika to metoda formułowania wymagań często wykorzystywana przez zespoły Scrum. Historyjki mają często formę “Jako <rola>, chcę <funkcja>, żeby <wartość>.”. Jeśli nigdy wcześniej nie słyszałeś o historyjkach znajdziesz niezłe wprowadzenie w serwisie Mountain Goat Software, Mike’a Cohn’a.

Czego można się spodziewać po historyjkach?

Co jakiś czas pomagamy zespołom rozpocząć stosowanie historyjek użytkownika. Najczęściej obserwujemy następujące korzyści:

1. Lepszą komunikację – Historyjki użytkownika przenoszą dyskusję z poziomu technicznego na poziom opowieści z żywymi aktorami, które dużo lepiej wspierają bezpośredni dialog z odbiorcami, niezbędny do dostarczania najbardziej przydatnych rozwiązań.
2. Lepszą selekcję – Częste zadawanie pytań: “Dla kogo to robimy?” “Co on z tego będzie miał?” pozwala odrzucić dużą część zadań a oszczędzony czas zainwestować w szybsze dostarczenie priorytetowych ulepszeń, podniesienie jakości tworzonego kodu i/lub stopniową spłatę długu technicznego.
3. Więcej kreatywności – Inżynierom bardzo łatwo koncentrować się na rozwiązaniach. Jeśli jednak konkretne rozwiązanie zostanie wdrukowane w wymagania na zbyt wczesnym etapie zabieramy sobie możliwość odkrycia czegoś lepszego.
4. Więcej satysfakcji – to często niedoceniana korzyść, a znacznie wpływa na długofalową produktywność zespołu. Regularnie widząc konkretną wartość w rekach użytkowników członkowie zespołu mogą czerpać więcej dumy ze swojej pracy, w porównaniu z mechanicznym odhaczaniem zadań.

Na co warto uważać w kontekście historyjek?

Jak wszystkie inne metody organizacji pracy, także historyjki użytkownika nie są magiczną różdżką rozwiązującą wszelkie problemy. W naszej pracy z zespołami najczęściej przewijają się następujące problemy, które w dużej mierze sprowadzają się do próby opakowania w język historyjek dotychczasowych przyzwyczajeń:

1. Opowieści o wodospadzie – jeśli w naszym backlogu pojawiają się historyjki typu “Jako zespół chcę przygotować koncepcję rozwiązania, żeby móc kontynuować prace” lub “Jako zespół chcę przetestować system, żeby upewnić się, że nie ma w nim błędów.” to Scrum nie przyniesie nam oczekiwanych korzyści. Dzieląc pracę w ten sposób odkładamy na później dostarczenie konkretnego rozwiązania, a co za tym idzie nie skorzystamy z możliwości wcześniejszego odkrycia problemów. Zostawiając testy na koniec będziemy też mniej uwagi poświęcać jakości realizowanych historyjek i w konswekwencji nie będziemy pewni postępów, bo każda “dostarzczona” historyjka może się okazać pełna błędów i wymagać jeszcze dużo pracy.
2. Brak (samo)dyscypliny – w pogoni za źle pojętym poczuciem sukcesu zdarza się, że zespoły, nawet w porozumieniu z Właścicielem Produktu zgadzają się na uznanie za zakończone historyjek, które nie spełniają w uzgodnionych Kryteriów Akceptacji i Definicji Ukończenia. Najczęściej ofiarą są w takim przypadku testy. Podobnie jak w dziedzinie higieny osobistej szkody nie przyjdą natychmiast, ale w środowisku pełnym zarazków, jedynie kwestią czasu jest pojawienie się poważniejszych zakarzeń.
3. Podział według pracy do wykonania, a nie wartości do dostarczenia – dużą pokusą dla istniejących organizacji jest podział prac według komponentów systemu lub specjalistycznych zespołów. Podobnie jak w przypadku opowieści o wodospadzie prowadzi to do opóźnienia dostarczenia gotowych rozwiązań i późniejszego wykrywania problemów. Tak często jak to możliwe chcemy “kroić tort” czyli dostarczać smakowite kąski obejmujące wszystkie warstwy produktu. Pytaniem, jakie powinniśmy sobie zadawać nie jest “Jak podzielić naszą pracę na historyjki?”. Dużo łatwiej skorzystać z silnych stron tej metody pytając “Jak zorganizować naszę pracę, by w najbliższym sprincie dostarczyć największą możliwą wartość?”
4. Dylemat “Czy to historyjka?” – Najwięcej czasu zajmują zawsze dyskusje, w których nie ma jednoznacznych odpowiedzi. Czasem lepiej jest po prostu uciąć taką dyskusję. Ogólna zasada jest taka, że wszystko co ma zrobić zespół z produktem powinno być w Backlogu. Dla każdego elementu Backlogu warto też zadać pytania o odbiorcę i wartość, lecz jeśli mimo to zadanie nie pasuje do formy user story to nie warto na siłę wtłaczać go w ten gorset. Tak jak wspomnieliśmy wczoraj: eksperymenty techniczne, bugi i inne zadania też mogą być częścią backlogu.

Jakie pisać dobre historyjki?

Pełna odpowiedź na to pytanie wykracza poza zakres niniejszego artykułu. Oprócz oczekiwanych korzyści i ostrzeżeń opisanych powyżej dobrą techniczną wskazówką jest analog SMART-celów w postaci skrótowca INVEST. Więcej o pisaniu dobrych historyjek można też przeczytać w książce “User Stories Applied” Mike’a Cohn’a.

Pytania dla Was:

1. Czy dla każdego zadania zadajecie sobie pytanie komu ma ono służyć i im ma dać?
2. Jak często nieudana próba odpowiedzi na te pytania powoduje, że odrzucacie zadanie?
3. Czy w Waszym zespole obserwujecie spodziewane korzyści z wykorzystania historyjek? Czy obserwujecie któryś z typowych problemów z historyjkami użytkownika? Jak możecie mu zaradzić?
   1. Jeśli tak to jak moglibyście jeszcze wzmocnić ten efekt?
   2. Jeśli nie to jaki jest źródłowy powód? Zadajcie pięć razy pytanie “dlaczego?”.
4. Jak możecie podnieść Wasze (zespołu, PO, Klientów) umiejętności pisania i czytania historyjek użytkownika? Czy pomogłoby Wam zorganizowania wspólnych warsztatów treningowo-roboczych?