Kiedy przestać pisać historie użytkowników i zacząć pisać?

Kiedy odkrywając historie pierwszego sprintu, skąd wiesz, kiedy przestać pisać i iść naprzód?

Zapytałem kilka osób, które znam, a odpowiedź w zasadzie jest taka, że ​​zależy to od kontekstu, w jakim projekt istnieje, oraz od tego, jak bardzo cały projekt jest chroniony czasowo.

Czy jest jakiś standardowy sposób, aby wiedzieć, kiedy przestać pisać historie użytkowników, a jeśli tak, to na jakiej podstawie i jak ma to zastosowanie do przyszłych sprintów?

Musisz oszacować każdą historię po jej opracowaniu - zakłada to, że twoje historie są uporządkowane według priorytetów i że są wystarczająco opracowane do opracowania.

Po oszacowaniu wystarczającej ilości iteracji rozpocznij kodowanie.

Gdy masz pełny portfel produktów i dobre kompletne historie użytkowników ze wszystkich przypadków. Następnie podziel je na iteracje i rozpocznij programowanie.

Te dwie czynności nie są antagonistyczne.

Pisanie opowiadań polega na definiowaniu pożądanych potrzeb pod warunkiem zapewnienia wartości biznesowej.

Rozpoczęcie kodowania odbywa się w trakcie sprintu. Aby rozpocząć sprint, jedynym warunkiem jest zdefiniowanie zaległości sprintu - nadanej priorytetowo przez PO (autora historii) i wybranej przez zespół.

Powinieneś przestać pisać opowiadania (= zatrzymać projekt), gdy marginalna korzyść z wdrożenia opowiadania w porównaniu z kosztem wdrożenia i zaktualizowanym kosztem operacyjnym zdefiniowanej funkcji jest ujemna.

Powinieneś zacząć kodować w kontekście sprintu, kiedy historia jest zrozumiana (analiza), a testy i implementacja są zdefiniowane (projekt) - klasyczne podejście do tworzenia oprogramowania.

kiedy opowieści stają się wystarczająco szczegółowe, aby przekształcić się w programowalną logikę .. i kiedy programiści mogą przyznać pewną liczbę punktów opowieści, które mieszczą się w osi czasu sprintu ...

historia, którą szacuje się na 50 godzin / punkty historii byłaby trudna (IMO) do wzięcia udziału w tygodniowym sprincie. Dalsza analiza historii pozwoliłaby innym na podjęcie różnych części zadania, ale gdyby kod nie mógł być rozwijane równolegle, to prawdopodobnie jest tak krótkie, jak tylko możesz.

Czy jest jakiś standardowy sposób, aby wiedzieć, kiedy przestać pisać historie użytkowników, a jeśli tak, to na jakiej podstawie i jak ma to zastosowanie do przyszłych sprintów?

Nie znam osobiście standardowej metody. To naprawdę sprowadza się do połączenia twojej metodologii i oczekiwań klienta.

Przekonałem się, że lepiej zacząć kodowanie, gdy tylko masz wystarczająco dużo historii od klienta, aby zacząć. Jak powiedzieli inni, może to dotyczyć pojedynczej iteracji, jednak może być dłuższe. Miarą wystarczającą powinno być kierowanie się tym, jak często zamierzasz udostępnić działający kod klientowi, a nie zlecać klientowi dostarczenie ci nieskończonej listy historii (z których wiele prawdopodobnie nigdy nie zostanie ukończonych, może się zmienić lub nie, wyznacz swój główny termin wydania), lepiej zapytać klienta o pierwsze 3-5 najważniejszych i najwyższych priorytetów. Gdy zostaną one wykonane i wydane klientowi, zbierasz kolejne najważniejsze 3-5 funkcji i tak dalej. Poproś o mniej więcej, w zależności od tego, jak prawdopodobne będą twoje iteracje.

Twój klient, umowa lub termin może być może wskazać, kiedy faktycznie przestać pytać o historie, ale w międzyczasie prosiłeś o historie i zatrzymywałeś się tak często, jak masz iteracje. Gdy w drodze porozumienia ty i klient poczujesz, że produkt jest wystarczająco kompletny, możesz zdecydować, co zrobić z pozostałymi historiami, których klient jeszcze nie dał.

Główną zaletą tego podejścia jest to, że ostatecznie dostarczasz klientowi największą wartość, a wraz z rozwojem projektu i upływem czasu ilość dostarczanej klientowi wartości spada do punktu, w którym klient może uzyskać decyzja o „ostatnich 20% funkcji”, których mogliby sobie życzyć, a których w rzeczywistości nigdy nie można wykorzystać. Skraca również czas marnowany na trywialne przedmioty o niskim priorytecie, nakładając odpowiedzialność (i stres) na ustalanie priorytetów i planowanie iteracji z powrotem na klienta, a wszystko to wyłącznie w oparciu o potrzeby klienta. Nie oznacza to jednak, że nie powinieneś udzielać wskazówek klientowi, aby uniknąć trudności w planowaniu wąskich gardeł, które mogą się ujawnić podczas rozmowy z klientem o wymaganiach.

Przeczytaj Lean Software Development Poppendeicks, jeśli chcesz bardziej szczegółowy opis tego podejścia w szerszym kontekście.

nigdy nie przestajesz pisać opowiadań. Po prostu, gdy masz wystarczająco dużo opowiadań do sprintu 1, zaczniesz planowanie sprintu i twój zespół zacznie działać zgodnie z zaległościami sprintu.

Właściciel produktu będzie nadal pielęgnował zaległości produktu, tj. Pisanie kolejnych historii użytkowników, dzielenie dużych historii, np. Epików, na mniejsze, opracowywanie dalszych kryteriów akceptacji historii, ustalanie priorytetów ...