Historie użytkowników stanowią serce zwinnego rozwoju. Są one podstawowym materiałem wejściowym dla zespołu scrumowego. Bierze on historie użytkowników i tworzy przyrosty produktu oparte na ukończeniu tych historii. Niestety, tworzenie historyjek użytkownika nie jest takie proste.
Więcej informacji o historyjkach użytkownika można znaleźć tutaj:
Właściciele Produktu muszą nauczyć się, jak tworzyć historyjki użytkownika, które spełniają potrzeby zespołu. Aby tworzyć dobre user stories, zacznij od pamiętania o tym, aby INWESTOWAĆ w dobre user stories. INVEST to akronim, który obejmuje następujące pojęcia składające się na dobrą historyjkę użytkownika:
Independent: Element Backlogu Produktu (PBI) powinien być samowystarczalny.
Negatywny: Powinien pozostawiać miejsce na dyskusję.
Valuable: Musi dostarczać wartość dla interesariuszy.
Estimable: Zawsze musisz być w stanie oszacować rozmiar PBI.
Small: Powinieneś więc być w stanie go zaplanować, zadać i nadać mu priorytety.
Testable: Rozwój powinien być możliwy do przetestowania.
Historie powinny być jak najbardziej niezależne i powinieneś być w stanie pracować nad nimi w dowolnej kolejności. Pozwala to na prawdziwą priorytetyzację każdej z historii. Kiedy w grę wchodzą zależności, wdrożenie wartościowej historyjki może okazać się niemożliwe bez wdrożenia innych, znacznie mniej wartościowych historyjek.
Negocjowalne
Dobra historyjka jest negocjowalna, a nie jest kontraktem. Dobra opowieść jest zaproszeniem do rozmowy. Dobra opowieść oddaje istotę tego, co jest pożądane. Rzeczywisty rezultat musi być wynikiem wspólnych negocjacji pomiędzy Właścicielem Produktu a zespołem deweloperskim. Celem jest zaspokojenie potrzeb klienta.
Wartościowe
Powieści użytkownika powinny być uszeregowane w backlogu według wartości biznesowej. Tworzenie pozycji, które są naprawdę fajne do kodowania, ale nie przynoszą żadnej wartości dla interesariuszy, narusza jedną z zasad Agile, która mówi o ciągłym dostarczaniu wartościowego oprogramowania
Estymulacyjny
Deweloperzy muszą być w stanie oszacować historię. Powinna być ona napisana w taki sposób, aby programiści mogli ją zrozumieć i mieć pomysł jak ją zaimplementować. Kluczowymi czynnikami przy szacowaniu są wiedza o domenie i wiedza techniczna.
Małe
Dobre historie mają tendencję do bycia małymi, ale jak małe powinny być? Odpowiedź zależy od zespołu i stosowanej metodologii. Wielu Product Ownerów sugeruje dwutygodniowe iteracje, które pozwalają na tworzenie historyjek użytkownika trwających średnio trzy lub cztery dni pracy. Obejmuje to całą pracę, aby doprowadzić historyjkę do stanu „zrobiona”.
Testowalna
Opowiadania powinny być testowalne, aby pomóc w określeniu kompletności. Historyjka powinna mieć kryteria akceptacji. Kryteria akceptacji powinny być obiektywne. Unikaj używania kryteriów takich jak, łatwy w użyciu, szybki lub wolny od błędów. Try to write criteria that can be measured and tested.
Via: