3 metody pozwalające podzielić wymagania funkcjonalne na mniejsze

Zespoły miewają kłopoty w tym, by podzielić elementy Backlogu na kawałki mieszczące się w jednej iteracji. Jak to zrobić? W poniższym artykule opisałem trzy metody uszczegóławiania, doprecyzowywania i zmniejszania wymagań (w artykule będę używał słowa “cięcie”). Są one jednymi z popularniejszych na rynku.

Dlaczego wymagania mają być małe?

Chcemy, aby wymagania (historyjki) były jak najmniejsze. Dlaczego? Jest kilka argumentów:



  • zarządzanie ryzykiem. W przypadku wymagań przejawia się ta kwestia przede wszystkim jako ruch na tablicy (czy to analogowej czy elektronicznej). Duże zadania są w statusie “in progress” całe dni, albo i tygodnie. Nie wiadomo co się w nich dzieje, na daily słyszymy, że jeszcze brakuje jakiegoś wymagania, że trzeba jeszcze zrobić jakieś wymaganie. Mniejsze zadania pozwalają zauważyć ruch, czyli tak naprawdę pracę. Innymi słowy mniejsze zadania mitygują ryzyko związane z późnym zidentyfikowaniem problemów,
  • mniejszymi zadaniami łatwiej jest się dzielić między sobą w zespole,
  • mniejsze zadania pozwalają lepiej zidentyfikować, co tak naprawdę jest do zrobienia,
  • przy odpowiednim uszczegółowieniu zadania można lepiej wykorzystać potencjał danego pracownika,
  • “słonia da się zjeść tylko po kawałku”. Znana metafora ale jakże prawdziwa w tym przypadku. I najlepiej, aby te kawałki były wertykalne, aby przecinały wszystkie warstwy docelowej aplikacji (uogólniając backend, frontend),
  • przyrost wartości biznesowej. Poniższy rysunek pokazuje, czego możemy się spodziewać realizując “Big Bang”, duże wymagania (duże User Stories) oraz wymagania pocięte maksymalnie, jak tylko potrafimy.

Na przedstawionym rysunku widać, że wraz z upływem czasu wartość biznesowa jest zależna od przyjętej metody wdrażania i przygotowania wymagań. Im mniejsze wymagania, tym szybciej możemy wdrażać i tym szybciej możemy z klientami weryfikować, czy podążamy w dobrym kierunku.

Metoda 1 – Richard Lawrence (Agile For All) – How to split a user story

Pierwsza z technik cięcia wymagań. Jak pobierzecie plik zamieszczony na stronie, w pierwszym momencie może on zniechęcić. Jest to jednak tylko mapa myśli związana z procesem zmniejszania wymagań i da się z niej łatwo skorzystać.

Wejściem do procesu jest spełnienie przez historyjkę kryteriów INVEST. Kryteria te charakteryzują każde dobrze napisane wymaganie. Elementami są:

  • I – Independent. Niezależność historyjki oznacza, że nie ma ona zależności z innym wymaganiem znajdującym się w naszym rejestrze,
  • N – Negotiable. Wymaganie powinno mieć “miejsce” na jego przedyskutowanie np z zespołem,
  • V – Valuable. Historyjka powinna dostarczyć wartość biznesową dla interesariuszy/ klientów,
  • E – Estimable. Wymaganie jest zrozumiałe dla zespołu tak, aby był on w stanie je wyestymować,
  • S – Small. Zadanie nie może być za duże. Za duże oznacza, że niemożliwe jest jego zaplanowanie, priorytetyzacja oraz określenie zadań podrzędnych (np zadań technicznych).
  • T – Testable. Opis wymagania dostarcza niezbędne wymagania związane z jego przetestowaniem.

Drugim krokiem w opisywanej metodzie jest odpowiedzenie sobie na szereg pytań dotyczących wymagania. Nie będę tutaj przytaczał wszystkich. Niektóre z nich:

  • Czy historyjka opisuje przepływ (workflow)?
    • Czy możesz tak podzielić historyjkę, aby w pierwszej kolejności wykonać jedynie pierwszy i ostatni krok przepływu? Następnie stworzyć historyjki rozbudowujące przepływ o pominięte, środkowe kroki?
    • Czy możesz wyciąc głowną / kluczową część przepływu (dzieląc go wzdłuż), a później rozbudować go o brakujące fragmenty?
  • Czy historyjka zawiera wiele operacji (np. dotyczy zarządzania czymś, lub konfigurowania czegoś)?
    • Czy możesz wydzielić poszczególne operacje na oddzielne historyjki?

Jak widzicie powyżej (choć są to tylko dwa pierwsze pytania), praca nad uszczegółowieniem wymagania może być bardzo długotrwała, ponieważ wymaga od zespołu przeanalizowania różnych możliwości realizacji. Ale z drugiej strony chyba każde cięcie wymagań tego wymaga, prawda? Pocieszające może być to, że proces zabiera dużo czasu na początku, kiedy Zespół uczy się myśleć o wymaganiach w inny sposób, a z czasem będzie wykonywany sprawnie. Nie przyjmuje ich “tak jak są”, ale rozmyśla, jakby je zrealizować w sposób inny, prostszy, tworząc wiele mniejszych.

Ostatnim, trzecim elementem metody jest sprawdzenie, czy realizowane przez nas czynności doprowadziły do odpowiedniej wielkości (metoda rekomenduje 6 do 10 wymagań per iteracja; (przyp. red. z podzadaniami czy bez?)), spełnienia przez nowe wymagania kryteriów INVEST, łatwego zidentyfikowania historyjki początkowej.

Metoda 2 – Gojko Adzic – Hamburger method

Metoda stworzona przez Gojko, znanego m.in. z BDD, bazująca na Story Mapping Jeff’a Pattona. Opiera się ona na założeniu, że hamburgera możemy zjeść, gryząc go  przez wszystkie warstwy, a nie osobno bułka, mięso, warzywa. Oczywiście jest to prawda w 95% przypadków :).

Pierwszym krokiem jest identyfikacja zadań technicznych, pozwalających na implementację zadania biznesowego. Jak w opisie metody stanowi Gojko, zadania techniczne stają się niejako warstwami hamburgera, reprezentując mięso, bułkę, sos, itd. Na rysunku staraliśmy się odtworzyć opisaną sytuację, zakładając, że mamy do czynienia z zadaniem dotyczącym całej nowej funkcjonalności dla klienta, począwszy od bazy danych (np. przetrzymywania informacji), aż po stronę wizualną (interfejs użytkownika zaprojektowany przez specjalistę UX, grafika, badacza).

Drugim i chyba najważniejszym w opisywanej metodzie krokiem, jest identyfikacja możliwych implementacji dla poszczególnych zadań technicznych. Możemy wyobrazić sobie tutaj oś. Z jej jednej strony (np lewej) będziemy mieli rozwiązania, które mogą dostarczyć wartość dla użytkownika, ale nie muszą być jeszcze w pełni automatycznymi lub nie muszą jeszcze wprowadzać pełnej integracji z powiązanymi systemami. Na drugim końcu osi (np prawym) będą zadania, które dostarczają pełną funkcjonalność / zakres, zadania “idealne”.

W kroku piątym metody (kroki trzy i cztery dotyczą pokazania opcji realizacji danego zadania z uwzględnieniem pracochłonności i jakości), zatytułowanym “Take the first bite” określamy najprostszą wersję realizacji danego wymagania (lewa strona naszej osi). Kolejny etap to już zjedzenie hamburgera kolejnymi gryzami.

Metoda 3 – Alistair Cockurn i Henrik Kniberg – Elephant Carpaccio

Metoda najbardziej praktyczna z przytoczonych. Polega na dekompozycji algorytmu jaki jest do wykonania aż do poziomu pojedynczych działań i implementacji ich po kolei (na żywo!). Oczywiście wdrażana aplikacja jest przykładowa i może nią być dowolna funkcjonalność. Najważniejsza część w tym ćwiczeniu to:

  • usłyszenie o wizji produktu,
  • przemyślenie wymagań (zbudowanie backlogu),
  • ich implementacja w określonym czasie (timebox).

Całość ćwiczenia jest bardzo dobrze wytłumaczona w załączonym linku do metody. Moje zdanie jest takie, że przytoczone ćwiczenie jest najlepsze z opisanych i uczy co to znaczy tak projektować wymagania, aby skupić się na jak najszybszym dostarczeniu wartości dla użytkownika końcowego.

Podsumowanie

Powyżej przeczytaliście o kilku metodach pozwalających na uszczegółowienie wymagania, jego doprecyzowanie i w konsekwencji zmniejszenie. Niektóre z nich pozwalają tylko na pracą z wymaganiem, inne są bardziej praktyczne i uczą Zespół jak ma pracować zanim zacznie zajmować się rzeczywistymi wymaganiami.

Jakie inne techniki znacie? Podzielcie się nimi w komentarzach.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x