W zeszłym tygodniu pisałem o dobrych cechach Rejestru Produktu. Dziś chciałbym przybliżyć dobre cechy historyjki użytkownika.
Dobra historyjka użytkownika powinna spełniać kryteria INVEST.
INVEST to:
Independent – niezależność
Negotiable – negocjowalność
Valuable – wartościowość
Estimatable – ocenialność
Sized correctly – dobry rozmiar
Testable – testowalność
Połączenie tych cech pozwala na budowanie sensownych i użytecznych historyjek użytkownika.
Niezależność
Niezależność historyjki użytkownika oznacza, że są mogą być one zaimplementowane niemal autonomicznie. Implementacja historyjki pozwala dostarczyć konkretnej wartości Właścicielowi produktu.
Historyjki, które są bardzo zależne od innych powodują problemy z planowaniem i nadawaniem priorytetów.
„Historyjki są niezależne, jeżeli możemy je implementować w dowolnej kolejności. Takie podejście bardzo ułatwia planowanie pracy w sprincie, w szczególności ustalanie priorytetów” [4].
Negocjowalność
Historyjka powinna być napisana w taki sposób by Zespół Deweloperski mógł w trakcie planowania sprintu uzupełnić jej szczegóły. Zazwyczaj szczegóły są uzupełniane w zakresie wymagań niefunkcjonalnych. Historyjki użytkownika nie mogą być traktowane jako kontrakt lub „pełna” specyfikacja wymagań.
Wartościowość
Historyjka użytkownika ma wtedy sens i wtedy powinna być w Rejestrze Produktu, gdy dostarcza Właścicielowi produktu konkretną wartość.
Ocenialność
Historyjki powinny dać się oceniać przez zespół deweloperski, który będzie je projektował, budował i testował. Dobra historyjka pozwoli na określenie jej złożoności za pomocą punktów. Przy Planowaniu Sprintu będzie można podzielić ją na zadania i określić jej pracochłonność. Rozmiar historyjki jest o tyle istotny, że dzięki temu parametrowi Właściciel Produktu będzie mógł nadać jej odpowiedni priorytet. Jeśli powstają problemy z oceną historyjki to prawdopodobnie jest ona za duża. Trzeba ją wtedy podzielić na kilka mniejszych tak by miały one dobry rozmiar.
Dobry rozmiar
„Historyjki powinny mieć odpowiedni rozmiar, pasujący do czasu, w którym chcemy rozpocząć nad nimi pracę. Historyjki przeznaczone do sprintów powinny być małe. Wykonując kilkutygodniowy sprint, chcemy mieć kilkanaście historyjek o rozmiarze kilku dni każda. W przypadku dwutygodniowego sprintu nie chcemy historyjki o rozmiarze dwóch tygodni, ponieważ istnieje zbyt duże ryzyko, że nie damy rady jej ukończyć. Zatem w ostatecznym rozrachunku potrzebujemy historyjek małych, chociaż duży rozmiar historyjki niekoniecznie oznacza, że jest ona zła. Historyjka ma odpowiedni rozmiar tak długo, jak długo nie chcemy jej brać do sprintu„[1].
„Każdy zespół wypracowuje definicje we własnym zakresie. Dla mnie historyjka jest mała, jeżeli jesteśmy w stanie zaimplementować ją w jednym sprincie. Takie podejście jest dobre, bardzo dobrze pokazuje względność wielkości pracy — „małe” dla zespołu A może oznaczać „duże” dla zespołu B. Rozmiar historyjek zależy od zespołu, jego doświadczenia, a także technologii, których używa„[4].
Testowalność
Każda historyjka powinna dać się przetestować. Jako testowanie rozumiem potwierdzenie, że implementacja danej historyjki użytkownika w 100% spełnia oczekiwania Właściciela Produktu. Kluczowym, wobec powyższego, jest już na etapie Rejestru Produktu lub najpóźniej Rejestru Sprintu dokładnie określić kryteria akceptacji historyjki użytkownika. Kryteria akceptacji pozwolą na Przeglądzie Sprintu wykazać zero/jedynkowo, że dana historyjka została wykonana. Co więcej kryteria akceptacji dostarczą dodakowych detali dla zespołu deweloperskiego co w konsekwencji ułatwi mu (zespołowi deweloperskiemu) ocenę rozmiaru historyjki.
Spełnienie wyżej wymienionych cech pozwala na podniesienie jakości całego procesu scrum. W tym miejscu pragnę polecić wpis Mariusza Charpko http://mariuszchrapko.com/dzielic-historyjki-uzytkownika-9-wzorcow/ dotyczący wzorców historyjek.
Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.
Reklama
Dzięki za polecenie mojego wpisu. Mam nadzieję, że Twoi Czytelnicy na tym skorzystają 🙂