Co oznaczają 3C dla User Story?
We wczorajszym wpisie Daniel wspomniał o User Story
…z definicji powinno być małe (a przynajmniej mieścić się w sprincie) i dostarczać wartość biznesową. Z doświadczenia i obserwacji, to jest najtrudniejsza część dla zespołów programistycznych, dekompozycja.
Zatrzymajmy się na dekompozycji, którą Daniel określił jako najtrudniejszą. Czemu to jest tak trudne? Jeżeli zapytam, jak wygląda dobre User Story, większość przytoczy z pamięci dobrze znaną strukturę.
As a who wants to accomplish something >,
I want < what they want to accomplish >
So that < why they want to accomplish that thing >
Dobre User Story będzie też opisane przez Acceptance Criteria, będzie miało priorytet, business value, jakie niesie dla klienta. Jeżeli myślimy o User Story, jak o kolejnym elemencie na JIRA może mieć też wiele innych elementów, które będą istotne dla zespołu w procesie developmentu.
Czy któreś z wymienionych przeze mnie elementów pomaga w dekompozycji User story? Mnie stanowczo nie. User Story nie powstały po to, żeby można było zbudować backlog produktu i umieszczać je w systemie, gdzie będą czekać, aż nadejdzie pora na ich implementację.
Zasada 3C
Dobre User Story oparte będzie o 3 filary, gdzie każdy z nich rozpoczyna się od litery C.
Card
Historyjka użytkownika powinna być na tyle mała, żeby zmieścić ją na tak zwanym memo card.
Conversation
Każda historyjka użytkownika powinna być przedyskutowana przez zespół odpowiedzialny za jej implementację. Poznajemy kontekst użycia omawianej historyjki użytkownika. W trakcie rozmowy o konkretnym US jesteśmy w stanie omówić przypadki brzegowe, wyjątki, które mogą być na tyle duże, że będzie potrzeba wydzielania, stworzenia osobnego User Story.
To jest to miejsce, gdzie powinniśmy starać się dekomponować User Story, bazując na rozmowie z klientem. Bardzo ciężko będzie podjąć się dekompozycji bez poznania szczegółów dotyczących nowej funkcjonalności, które uzyskamy tylko poprzez rozmowę, najlepiej z użytkownikami końcowymi.
Confirmation
Historyjka użytkowania powinna, być zrozumiała przez wszystkich w ten sam sposób, dlatego po jej omówieniu należy potwierdzić to, na co wszyscy zaangażowaniu się zgodzili. Najczęściej będą to Acceptance Criteria zapisane na odwrocie Card.
User Story wywodzi się z eXtreme Programming, które odwołuje się do praktycznych umiejętności. Twórcy (m.in Kent Beck i Alistair Cockburn), formułując podstawowe założenia XP, nie odwoływali się do szablonu User Story, a do praktycznych działań. Jeżeli zainteresowałeś się User Story w ujęciu XP, zajrzyj tutaj.