Agile INVEST – 6 świetnych wytycznych dla historii użytkownika

Agile wykorzystuje historie użytkownika do wyrażania problemów, które produkt lub system powinien rozwiązać. Wytyczne Agile INVEST to zestaw rekomendacji opracowanych przez Billa Wake’a, aby pomóc w testowaniu i tworzeniu wysokiej jakości historii użytkownika (lub ogólniej: elementów listy produktu), które wspierają skutecznązarządzanie projektami agile.

Zgodnie zAgile INVESTwytycznymi, wysokiej jakości historie użytkownika są łatwe do:

• Zrozumienia
• Wdrożenia
• Testowania
• Pokażenia klientowi
• Być niezależnym

Ale rozłóżmy, co oznacza naprawdę skrót INVEST.

Agile INVEST – Niezależność

Oznacza to, że historia może istnieć jako element listy produktu (PBI) z własnym priorytetem, może być oszacowana niezależnie i nie zależy od żadnych innych historii.

Priorytet przypisany do historii użytkownika powinien być jedynym czynnikiem decydującym o czasie jej wdrożenia. Jeśli priorytet jest niższy, historia znajduje się niżej na liście i jest wdrażana później; jeśli wyższy, zespół przesuwa ją wyżej na liście, aby zapewnić szybsze dostarczenie. Gdy historie użytkownika są wzajemnie zależne, to zależność – a nie priorytet – decyduje o czasie ich wdrożenia.

Agile INVEST – Negocjowalność

Dobra historia użytkownika oddaje istotę potrzeb klienta. Jeśli pojawiają się pytania, zespół omawia je z klientem, aby określić właściwą wartość historii. Zespół deweloperski może negocjować z właścicielem produktu i interesariuszami. W ten sposób współpraca między zespołem projektowym (dostawcą i klientem) tworzy wspaniały produkt lub usługę.

Czy zespół agile nie ma nic do zapytania, ponieważ wszystko jest zapisane w historii użytkownika agile? Wtedy ktoś zespół analizy biznesowej napisał wymagania.

Będą pewne elementy niemal nie do negocjowania (często niemerytoryczne), takie jak:

• Zasady bezpieczeństwa związane z kontami użytkowników
• Wymagania dotyczące wydajności, takie jak liczba użytkowników równocześnie obsługiwanych przez system

To jest w porządku – o ile szczegóły samej funkcjonalności pozostają otwarte i zachęcają do rozmowy.

Agile INVEST – Wartościowy

Odwołując się do zasad agile, „wartościowy” oznacza, że możemy przedstawić klientowi żądaną funkcję lub jej działanie podczas spotkania przeglądu sprintu.

Podczas dzielenia historii użytkownika zespoły muszą dzielić je pionowo (reprezentując również literę „V”), a nie poziomo. Dzięki temu otrzymujemy pełną funkcjonalność na końcu sprintu i zwiększamy potencjalnie dostarczalny przyrost produktu.

Zespoły mogą uznać za bardziej interesujące wdrażanie technicznych elementów listy produktu, ale nie zawsze przynoszą one bezpośrednią wartość klientowi – co sprzeczne jest z jednym zzasad agile: spełnianie klienta poprzez wczesne i ciągłe dostarczanie wartościowego oprogramowania.

Agile INVEST – Szacowalny

Dobra historia użytkownika musi być szacowalna. W agile szacowanie jest względne — porównywane do innych historii użytkownika w backlogu. Popularne metody obejmują ciąg Fibonacciego, Wielkość T-shirt (S, M, L itd.), i więcej.

Dyskusja na temat szacowania pomaga całemu zespołowi osiągnąć zgodę na warunki potrzebne do ukończenia historii. Czasem historia nie jest szacowalna, co jest normalne, jeśli historia jest zbyt duża lub zawiera wiele funkcji w jednym elemencie. W takich przypadkach należy podzielić historię na kilka mniejszych historii. W innych sytuacjach istnieje zbyt dużo nieznanych czynników, które wymagają badań.

Agile INVEST – Mały

Historie powinny trwać od kilku godzin do maksymalnie jednego pełnego Sprintu. W przeciwnym razie pojawiają się różne problemy — takie jak prędkość (jak zespół odpowiada za punkty dostarczenia), trudność w dokładnym szacowaniu i inne.

Agile INVEST – Testowalny

W tym kontekście „testowalny” odnosi się do kryteriów akceptacji określonych podczas analizy.

Nie możemy uznać historii użytkownika za „zakończoną”, chyba że spełnia kryteria akceptacji. Jedynym sposobem, by to wiedzieć, jest testowanie i weryfikacja.

Kryteria akceptacji nie są przypadkami testowymi. Odpowiadają na pytanie: „Jak będę wiedział, że skończyłem tą historię użytkownika?”

Przypadki testowe wyliczają kroki wymagane do przetestowania funkcjonalności.

Klient może powiedzieć, jak wygląda środowisko testowe i jakie warunki testowe sprawiają, że zespół uznaje historię użytkownika za ZROBIONE.