Staram się opanować sprawne zarządzanie projektami (dzięki Pivotal Tracker), ale wciąż próbuję zdefiniować kilka pierwszych historii projektu. Weźmy na przykład tę bardzo prostą historię:
„Użytkownik powinien mieć możliwość oznaczenia produktu”
Zakładając, że zdefiniowałem już „produkt” gdzie indziej, ta historia prawdopodobnie obejmowałaby napisanie polimorficznego systemu znakowania pod maską, po zakończeniu tego systemu mógłbym w końcu dodać możliwość oznaczenia produktu.
Mój problem dotyczy ilości pracy ukrytej w tej historii. Mogę zdefiniować zadania, które pozwolą wykonać historię, ale historie jako całość powinny mieć 1-2 dni pracy? Nie wydaje mi się słuszne, że historia ujawnia tylko wierzchołek góry lodowej, ale to jedyna część, która dotyczy Użytkownika.
Jak przezwyciężyć tego rodzaju rzeczy? Jakie są najlepsze praktyki?
AKTUALIZACJA 25/08 Dziękujemy wszystkim za wskazówki, skorzystałem z wszystkich porad na temat definiowania historii. Teraz przechodzę na Jira Grasshopper, która ma lepszą obsługę zadań w opowieściach (zadania, szacunki itp.) I śledzenie zadań programistycznych po rozpoczęciu sprintu.
Odpowiedzi:
Jeśli potrzebujesz, aby twoje historie trwały od 1 do 2 dni pracy programisty, być może powinieneś podzielić każdą historię na konkretne zadania użytkownika, które trwają od 1 do 2 dni pracy programisty.
Rozważ następującą „historię użytkownika:”
Pomyśl o tym, co dotyczy samego projektu bazy danych, dając użytkownikowi taką możliwość. Potrzebujesz tabeli klientów, tabeli nagłówka faktury i tabeli pozycji wiersza faktury, a my nawet nie rozmawialiśmy o akceptowaniu płatności.
W rzeczywistości historie użytkowników nie są takie proste. Kompletne historie użytkowników zawierają opis kroków użytkownika:
i tak dalej. Krótko mówiąc, musisz podzielić swoje historie użytkowników na bardziej szczegółowe.
źródło
Historie nie powinny być „1-2 dniami pracy”. Pod historiami Scruma ocenia się zwykle przy użyciu Punktów opowieści, względnego systemu wielkości. Jeśli używasz planowania pokera, historie mają wartość punktową - czas potrzebny na wdrożenie zależy od prędkości ustalonej przez Twój zespół.
Jeśli uważasz, że historia kryje złożoność (możesz ją nazwać epicką historią), powinieneś podzielić ją na mniejsze historie. Upewnij się, że nowe historie spełniają kryteria INVEST .
Ale może to przeciążasz; obowiązuje tutaj zasada XP YAGNI . Mówiąc wprost, nie powinieneś wdrażać „polimorficznego systemu znakowania pod maską”, chyba że naprawdę go potrzebujesz. Nawet wtedy należy go zaprojektować poprzez ulepszenie istniejącego systemu, który opracowałeś za pomocą dobrego zestawu testów.
Jeśli jesteś pewien, że potrzebujesz tego złożonego systemu tagowania, powinieneś zawołać złożoność w osobnych historiach. Mike Cohn opisuje podejście do projektowania jako „ zamierzone, ale powstające ”
źródło
YAGNIwynosi około: Nawet nie próbuj do pełnego polimorficzny system znakowania jeszcze . Zrób prosty dla jednego konkretnego przypadku użycia. Jeśli właściciel produktu powróci z inną historią na temat oznaczania innych rzeczy, wówczas rozszerzysz prosty istniejący system na polimorficzny system oznaczania. To, że uważasz, że będzie to konieczne, nie oznacza na pewno, że tak będzie; może się okazać, że tagowanie innych modeli nie będzie przez jakiś czas potrzebne, wtedy wszyscy o tym zapomną i nigdy nie stanie się to wymogiem. Stąd „Nie będziesz go potrzebował”.Wygląda na to, że mylisz historie i zadania.
Historia użytkownika
Historia użytkownika jest kompletną „funkcją”, która po dodaniu do produktu zapewnia większą wartość produktu.
Historia użytkownika nie powinna być większa niż można ją wdrożyć podczas sprintu . Podczas pierwszej części planowania sprintu decydujesz, z którymi historiami użytkowników chcesz pracować podczas sprintu. Celem sprintu jest uzupełnienie historii użytkowników, co zwiększy wartość produktu.
Zadanie
Podczas drugiej części fazy planowania sprintu programiści dzielą historię na zadania . Zadania są zadaniami programistycznymi. Mogą to być na przykład „Dodaj kolumnę do bazy danych”, „Rozszerz usługę x” itp. Zadanie nie powinno być większe niż można je wykonać w ciągu jednego dnia.
Podczas codziennego scrum oceniasz postępy tych zadań. Jeśli zadanie trwa od więcej niż jednego codziennego scrumu, trwa to zbyt długo, a ty, jako zespół, jesteś odpowiedzialny za rozwiązanie tej sytuacji.
Pamiętaj, że historie użytkowników reprezentują wartość biznesową dla interesariuszy. Interesariusze powinni być zainteresowani ukończeniem historii użytkowników, a nie zadaniami.
Podział zadań jest narzędziem dla zespołu programistów do zarządzania sprintem, monitorowania postępu historii użytkowników podczas sprintu i wizualizacji potencjalnych problemów.
Zainteresowane strony nie powinny zajmować się tymi zadaniami rozwojowymi. Niestety, często to robią moje doświadczenia, szczególnie w przypadku organizacji, które dopiero zaczynają sprawnie rozwijać. Jednak radzenie sobie z tą sytuacją to inna sprawa.
Epicki
Jeśli historia użytkownika jest większa niż myślisz, że możesz ją ukończyć jednym sprintem, nazywa się to epicką. Aby zespół mógł zacząć nad nim pracować, należy go podzielić na kilka mniejszych historii użytkowników.
Pamiętaj, że historia użytkownika stanowi wartość dodaną dla użytkownika końcowego, więc podzielenie eposu na „front-end” i „back-end” nie jest właściwą drogą. Dodanie zaplecza dla nowej funkcji nie stanowi samo w sobie wartości dla użytkowników końcowych.
Podział epiki na historie użytkowników, którymi można zarządzać w ramach sprintu, nie zawsze jest łatwy, jeśli nie masz do tego doświadczenia.
Korzystanie z Pivotal Tracker
Myślę, że Pivotal Tracker to świetne narzędzie do śledzenia historii użytkowników. Ale nie jest to narzędzie Scrum jako takie, a sposób, w jaki Scrum uczy dzielenia historii na zadania, nie jest łatwo obsługiwany przez kluczowy moduł śledzący. Możesz włączyć możliwość dodawania zadań do historii użytkowników. Ale jeśli prowadzisz projekt za pomocą scrum, sugerowałbym użycie białej tablicy i karteczek do śledzenia postępu zadań podczas sprintu.
źródło
Cel projektu polegający na wdrożeniu polimorficznego systemu znakowania jest w porządku, ale nadal powinieneś skupić się na implementacji funkcji, których chce klient. Może to oznaczać, że z drobnoziarnistej historii użytkownika z drobnoziarnistej historii użytkownika twój system z czasem ewoluuje w kierunku polimorficznego systemu znakowania. Jednak w dowolnym momencie tej podróży powinieneś mieć system złożony z wielu małych i testowalnych funkcji, opisanych przez zaimplementowaną kolekcję Historie użytkowników.
W tym przypadku brzmi to tak, jakby „Oznaczanie produktów” w systemie mogło być epicką, tj. Czymś znacznie większym niż pojedyncza historia użytkownika i przy odrobinie wysiłku można ją podzielić na kilka mniejszych historii. Biorąc sporo licencji artystycznej, mogę wymyślić następujące historie użytkowników, które mogą z grubsza mieć zastosowanie do twoich wymagań:
... i mógłbym kontynuować.
Wątpię, aby którykolwiek z nich był tak realistyczny, że będziesz z nich korzystać, ale mam nadzieję, że ilustrują one rodzaj szczegółów, do których możesz przejść ze swoimi Historiami użytkowników.
Jeśli Historii użytkownika naprawdę nie można podzielić na mniejsze historie i nadal uważasz, że jest zbyt duża, aby spróbować wdrożyć ją za jednym razem, możesz podzielić ją na pionowe plastry. Jest to technika, która oznacza dostarczanie tylko części funkcji w ramach każdej Historii użytkownika, ale każda część jest testowalnym przekrojem przez wszystkie odpowiednie warstwy technologii, np. W przypadku witryny internetowej może to oznaczać zmianę warstwy bazy danych, aplikacji i interfejsu użytkownika. Unikaj posiadania jednej historii użytkownika do pracy z bazą danych, innej dla aplikacji i innej dla interfejsu użytkownika, ponieważ nie będą one indywidualnie testowane.
Biorąc jeszcze większą licencję artystyczną, mogę podzielić „Jako użytkownik systemu chcę mieć możliwość dołączenia jednego tagu do jednego produktu”. w następujące pionowe plastry:
Każdy z nich można przetestować - jeśli nie jest sam w sobie szczególnie cenny.
źródło
Są książki napisane wyłącznie w celu znalezienia właściwego sposobu na opisanie i rozbicie twoich wymagań. To nie jest łatwe zadanie.
Często zdarza się, że zespoły programistów szukają kompleksowych rozwiązań zamiast najprostszych. Może to wynikać z samej historii lub z tego, że zespół chce wybrać zbyt skomplikowane rozwiązanie, które nie tylko rozwiązuje tę historię, ale także stanowi podstawę dla opowieści x, y i z. To dobra intencja, ale rozdęcie zakresu, w którym ta sama praca może być wykonana przy mniejszej ilości pracy. Zawsze trudno jest ocenić, ile projektowania musi wnieść historia, aby nie zepsuć przyszłych historii, psując projekt. Ta decyzja należy do zespołu.
Jako właściciel produktu możesz na to wpłynąć tylko poprzez podzielenie historii na mniejsze części. Powinieneś zadać sobie pytanie: czy ta historia jest najmniejszym rozwiązaniem, jakie możemy obecnie wymyślić? Czy możemy rozbić go na zredukowane zestawy funkcji, które pewnego dnia staną się „wielkim elastycznym systemem tagowania, o którym zawsze marzyłem”. Możesz zacząć od systemu tagów dla pojedynczego tagu, następnie rozszerzyć go, aby zawierał listę wstępnie wybranych tagów, a następnie pozwolić użytkownikowi definiować tagi itp.
Dla zespołu deweloperów sprowadza się to do: Czy możemy znaleźć prostsze podejście do realizacji historii, ale nadal mamy solidną architekturę, która wykona zadanie dzisiaj, bez uszczerbku dla przyszłych funkcji.
Jeśli jesteś otwarty na przyjmowanie rozwiązań pośrednich, a zespół programistów stara się również zaoferować najprostsze, ale dobre rozwiązanie, prawdopodobnie znajdziesz miejsce, w którym rozmiar opowiadań, które chcesz zrobić, jest odpowiedni (im mniejszy, tym lepszy) . Nie oznacza to, że masz tylko małe historie. Niektóre są większe niż inne, to tylko fakt, który musisz zaakceptować, a jeśli są zbyt duże, podziel historie na mniejsze części.
źródło