Tworzenie historyjek (stories), co oznacza INVEST oraz 3C
Historyjki użytkownika (User stories) maj swój pocztek w eXtreme Programming. Zespoły SCRUM'owe implementuja w zależności od swojego doświadczenia i potrzeb różne techniki takie jak eXtreme programming, Test Driven Development oraz aktywne programowanie w parach lub całym zespołem przy jednym komputerze.
Dobrze przemyślana historyjka powinna zawierać tytułowe 3C czyli:
Dobrze przemyślana historyjka powinna zawierać tytułowe 3C czyli:
- Card,
- Conversation,
- Confirmation
Jeżeli chcemy sprawdzić czy historyjka jest poprawnie napisana powinniśmy także rozpatrzyć jej zawartość pod katem INVEST czyli:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
3C
CARD
Historyjkę możemy tworzyć w postaci karty (lub samoprzylepnej karteczki ;)) np: jako nowe stories w Jira lub po prostu kawałek kartki na ścianie. Historyjka taka powinna mieć powtarzalny szablon, który odpowiada na pytania np.
A) who? what? why?.
B) I would like it because?
Dzięki takiemu rozwiązaniu nie trzeba się za każdym razem zastanawiać jak zacząć np:
As a <user role> of the product
I can <action>
So that <benefit>
CONVERSATION
Każdy członek zespołu przed rozpoczęciem opisywania historyjki powinien się do niej przygotować na ile jest to możliwe. Im wcześniej mamy potrzebne informacje i dobrze wykorzystany czas na analizę tym mniej zajmie nam implementacja. Więc jeżeli mamy wątpliwości musimy rozmawiać z Właścicielem Produktu i mu oraz całemu zespołowi je przedstawiać. Powinniśmy także zapraszać osoby bezpośrednio związane z historyjka np. osoby z biznesu lub przedstawicieli z innych zespołów.
CONFIRMATION
Właściciel produktu oraz zespół wspólnie zgadzaj się że historyjka jest kompletna i może być poddana implementacji. Muszą ze sobą współpracować pro aktywnie. Historyjka musi zawierać kryteria akceptacji dzięki, którym wszystkie strony będą mogły stwierdzić czy jest ukończona.
Akronim INVEST to:
INDEPENDENT
Historyjki musza być jak najbardziej niezależne. Im mniej zależności np. technicznych tym lepiej
NEGOTIABLE
Wszystko jest zmienne szczególnie musza sobie to wziąć do serca zespoły pracujące w metodologi AGILE. Powinniśmy więc zostawić przestrzeń na jej modyfikację.
VALUABLE
Musimy także wiedzieć jaka wartość biznesowa ma historyjka. Wszystkie historyjki powinny być połczone z jasno określonymi celami biznesowymi.
ESTIMABLE
Historyjka musi być na tyle zrozumiana przez zespół aby mógł określić ile czasu zajmie mu jego wykonanie. Nie oznacza to że powinniśmy już znać każdy szczegół implementacji.
SMALL
Historyjka musi być na tyle mała aby zmieścić się w jednym sprincie. Jednym z dobrych sposobów na podział to sprawdzenie gdzie w opisie występuje słowo lub oraz i, inne metody to:
- Podział na podstawie kolejnych kroków użytkowania,
- Podział na podstaiwe I/O channel, każdy kanał może być oddzielna historia.
- Podzial ze wzgledu na dostepne opcje w funkcjonalności
- Podział ze względu na wykonywań roę, osobę
- Podział ze względu na datę. Każdy ważniejszy okres może być wykonany w oddzielnej historyjce,
- Podział ze względu na operacje CRUD.
Ważna uwaga. Nigdy dzielcie historyjek ze względu na system, komponent, szczegół architektury.
TESTABLE
Każda osoba zaangażowana w historyjkę musi się zgodzić w jaki sposób będzie ona testowana. Najlepiej aby każdy zespół miał zdefiniowane DoD (definition of done).
Przykładowe konwencje:
As .. I want .. Then ..
As Product Owner
I want to see welcome screen while login for the web portal
Then I'm able to see my accounts
And I see my transactions
Given ..When .. Then
Given I have already logged in to web portal on my computer
And I have never logged in to web portal on my mobile
When I log in web portal on my mobile
Then I can see log in screen
Komentarze
Prześlij komentarz