Dobrze zdefiniowany element backlogu produktu powinien spełniać kilka kryteriów. Dzięki temu jego realizacja nie przysporzy dodatkowych problemów. Możesz osiągnąć ten cel stosując zasadę INVEST. Pomoże ci ona zdefiniować poprawne kryteria akceptacji i umożliwi sprawne ukończenie historyjki użytkownika.
Czym jest User Story
User Story, czyli po polsku Historyjka Użytkownika, jest sposobem na opis wymagań, które realizuje zespół. W klasycznej formie polega na ich zapisaniu w następującym formacie:
Jako <rola> chcę <potrzeba>, aby <cel do osiągnięcia>
Przykładowo może to być następujące zdanie:
Jako moderator forum chcę zobaczyć listę najnowszych postów, aby sprawdzić ich zgodność z regulaminem.
Zasada INVEST może być pomocna także wtedy, jeśli nie stosujesz zapisu User Story. Elementy backlogu produktu na pewno zyskają na jej użyciu, niezależnie od wybranej formy.
Problemy z Historyjkami Użytkownika
User Story może być bardzo przydatnym narzędziem, jednak należy wiedzieć, jak je stosować poprawnie. W wielu backlogach produktu można spotkać wymagania zapisane w tym formacie, które nie mają zdefiniowanej prawdziwej roli w aplikacji, mylą oczekiwania z powodem działania, są zbyt duże, bezwartościowe lub zdefiniowane zbyt szczegółowo.
Metoda INVEST pomoże zdefiniować wartościowe User Story
Zasada INVEST, którą stworzył Bill Wake, opisuje sześć elementów, o które powinieneś zadbać tworząc elementy backlogu produktu. Nazwa stanowi akronim od angielskich słów Independent (niezależny), Negotiable (negocjowalny), Valuable (wartościowy), Estimable (estymowalny), Small (mały) oraz Testable (testowalny).
Stosowanie metody INVEST powoduje, że elementy backlogu produktu będą mniejsze, a kryteria akceptacji nie będą długą listą. Dzięki temu będzie można dostarczać je znacznie sprawniej i wcześniej uzyskać feedback na temat postępów.
Independent, czyli niezależny
Elementy backlogu produktu powinny być w możliwym stopniu niezależne od siebie. Powinieneś unikać sytuacji, gdy praca nad User Story jest zablokowana przez realizację innej historyjki.
Dana Historyjka Użytkownika powinna stanowić pewną odrębną i logiczną całość. Nie oznacza to jednak, że musimy się pozbyć wszelkich zależności. Zawsze istnieje jakaś kolejność pracy, na przykład zanim stworzysz koszyk zakupów w sklepie internetowym, powinieneś wcześniej zaimplementować możliwość przeglądania produktów.
Negotiable, czyli negocjowalny
Historyjka Użytkownika oraz uszczegóławiające ją Kryteria Akceptacji nie mogą być wyryte w kamieniu. Powinny dawać możliwość dyskusji, negocjacji oraz zmiany podejścia.
Definiując User Story musisz określić kto, co i dlaczego potrzebuje twojej pracy, ale sposób realizacji zależy od deweloperów. Techniczne historyjki użytkownika oraz zbyt szczegółowe kryteria akceptacji mogą powodować różne problemy.
Valuable, czyli wartościowy
User Story powinno stanowić wartość dla użytkownika końcowego, a nie być twoją zachcianką. Pamiętaj, że czasem ta wartość nie wynika bezpośrednio z realizowanej historyjki. Przykładowo refaktoring kodu może spowodować szybszą realizację kolejnych zadań, ale nie daje użytkownikowi żadnej nowej funkcjonalności.
Przed rozpoczęciem pracy powinieneś zawsze zastanowić się, czy dane User Story ma odpowiednią wartość i na podstawie tego zdecydować, czy opłaca się je realizować z punktu widzenia użytkownika.
Estimable, czyli możliwy do estymowania
Poprawny element backlogu produktu powinien być możliwy do oszacowania. Po pierwsze musi być więc zrozumiały dla całego zespołu. Jeśli któryś deweloper nie wie dokładnie, na czym ma polegać realizacja User Story, powinien zadać odpowiednie pytania zanim rozpoczniecie estymowanie.
Jeśli oszacowanie danego elementu backlogu jest niemożliwe, nie powinien on trafić do iteracji. Przeszkodą mogą tu być zbyt niejednoznaczne kryteria akceptacji lub zbyt duży rozmiar. Na ten ostatni problem zwraca uwagę kolejny element metody INVEST.
Small, czyli mały
Historyjka Użytkownika powinna być odpowiednio mała, aby było możliwe ukończenie jej w jednej iteracji. Unikaj worków bez dna, dokładając kolejne wymagania. Jeśli kryteria akceptacji stanowią długą listę, powinieneś się zastanowić, czy nie można podzielić tego User Story na kilka mniejszych elementów.
Mniejsza Historyjka Użytkownika jest łatwiejsza do zdefiniowania, istnieje mniejsze ryzyko niespodziewanych problemów, a jej estymacja będzie dokładniejsza.
Testable, czyli testowalny
Pracując nad elementem backlogu produktu dochodzisz do momentu, w którym potwierdzasz, że jest gotowy. W jaki sposób to zrobisz?
Według zasady INVEST Historyjka Użytkownika powinna być zdefiniowana w taki sposób, aby na koniec pracy było możliwe przeprowadzanie testu, który potwierdzi działanie. Może on być automatyczny, co ma dodatkowe zalety, lub manualny. Pamiętaj o tym już na etapie definiowania User Story, pomoże to w lepszym określeniu zakresu prac oraz wyborze podejścia do realizacji.
Be First to Comment