S.P.I.D.R.

Wczoraj poruszyliśmy temat jak tworzyć wartościowe (także dla biznesu) historyjki użytkownika. A dziś czas poznać odpowiedź na to jak pająk może pomóc przy dzieleniu historyjek na mniejsze?

Skróty, wszędzie skróty…

Okazuje się, że INVEST to nie jedyny mnemonik w służbie user stories. Poza standardowym problem jak tworzyć wartościowe US pojawia się kolejne pytanie:

Jak podzielić moje historyjki? Kiedy historyjka jest za duża?

To bardzo dobre pytanie, na które napotyka się wiele zespołów. Ten problem stał się na tyle popularny, że Mike Cohn przygotował zestaw heurystyk, który opisał w artykule (oraz wideo), które zebrał w kolejny skrótowiec.

Pająk w służbie User Stories – S.P.I.D.R.

Ten skrótowiec grupuje 5 popularnych aktywności i heurystyk, które pomagają przy dzieleniu US na mniejsze. W oryginale wygląda to następująco:

Spike – A research activity can give you the knowledge you need to split a complex story.
Paths – If a user can do something in multiple ways, that’s a great area for splitting.
Interfaces – Splitting your story by browser, or hardware, or deliver a complex interface in iterations.
Data – You may be able to deliver value in an iteration by focusing on one type of data.
Rules – Relaxing support for the rules in an iteration can make large stories smaller.

Mike Cohn

Przeanalizujmy je zatem po kolei.

Spike

Spike to w tym przypadku określenie, którego autorem jest Kent Beck, odpowiadające na pytanie:

– What is the simplest thing we can program that will convince us we are on the right track?

Such stepping outside the difficulties at hand often led us to simpler and more compelling solutions. Kent dubbed this a Spike. I found the practice particularly useful while maintaining large frameworks.

Ward Cunningham pyta Kenta Becka

I w przypadku US taki rekonesans może zachować nas przed stratą i podążaniem w niewłaściwym kierunku. Ważne jest jednak kilka elementów dot. takiej aktywności:

• Po pierwsze – musi mieć jasno określone ramy czasowe. Musimy je zakończyć w skończonym czasie, idealnie mniejszym niż iteracja. Nie możemy zajmować się tym w nieskończoność.
• Wynik tego działania musi jasno pokazywać, że podążamy we właściwym kierunku lub musimy go zmienić, aby uniknąć problemów. To oznacza, że po zakończeniu zadania musimy mieć albo częściowe rozwiązanie, lub wiedzę, jak tego nie robić. Wynikiem Spike nie jest odpowiedź na pytanie: czy coś robimy? tylko jak coś robimy i czy robimy to dobrze?

Paths

To pierwsza z 4 zgromadzonych heurystyk, która jasno wskazuje, że historyjka powinna pokrywać jedną ścieżkę dającą wartość użytkownikowi. Jeśli próbujemy pokryć wiele z nich na raz to oznacza, że upakowaliśmy w nią zbyt wiele i powinniśmy ją podzielić, lub zastanowić się nad przeniesieniem ścieżek do acceptance criteria (ale tylko wtedy, gdy zgodzimy się w zespole, że implementacyjnie nie ma zbyt wielkiej różnicy i nie wpływa to na estymatę).

Interfaces

Kolejna heurystyka, która stanowi dobre kryterium podziału to interfejsy, czyli sposób dostępu. Oczywiste wydaje się myślenie tutaj w kategorii interfejsów użytkownika lub np. rodzaju aplikacji mobilnej (np. iOS lub Android). Natomiast warto zwrócić uwagę, że jeśli mamy kilka mechanizmów dostępu do danej funkcjonalności, które dają biznesową wartość i zgadzają się z INVEST, możemy również je podzielić (przykładem może być dostęp po webowym GUI dla klientów B2C i po API dla partnerów B2B).

Data

Następnym miejscem w którym warto postawić granice są zakresy lub podzbiory danych. Jeśli część z naszej funkcjonalności dostarcza wartość użytkownikom tylko z podzbiorem danych, to warto w tym miejscu dokonać podziału. Przykłady:

• Nasza aplikacja mobilna proponuje turystom popularne atrakcje w mieście. Może warto podzielić historyjki na proponowane muzea, potem restauracje i dodawać kolejne.
• Być może spotkaliście się z historyjkami, które atakują użytkownika danymi przedstawionymi tabelach o wymaganiach dot. wszystkich możliwych kryteriów filtrowania, sortowania, stronicowania. Może warto na początku przygotować czystą tabelkę wyświetlającą dane z paginacją, w następnym US dodać sortowanie, w następnym proste filtrowanie tekstowe, a w kolejnym zaawansowany język wyszukiwań (który i tak możemy podzielić na kolejne elementy).

Rules

I na koniec reguły. Często widzimy, że dana historyjka jest straszliwie rozbudowana, ponieważ pokrywa wszystkie reguły biznesowe na raz. Ale bardzo często w etapach pośrednich nie potrzebujemy mieć ich wszystkich zaimplementowanych od razu, możemy je odrobinę poluzować. Dzięki temu uzyskujemy dodatkową elastyczność i punkty podziału.

Podsumowanie

To na pewno nie jest wyczerpująca lista dobrych praktyk, i pewnie nawet część z Was ma własne pomysły – jestem bardzo ciekaw czego używacie na co dzień. Niemniej, jestem pewien, że posiadanie takiej listy pomaga – bo jest łatwiej proces rozpocząć i od czegoś zacząć.

W końcu pająki to pożyteczne zwierzątka, prawda?