- wymagania niefunkcjonalne - są dopisywane gdzieś na boku US, spisywane w SRSach albo są w głowach
- to, że nie wszystkie "wymagania" przekładają się na konkretne funkcjonalności
- epiki mogą dotyczyć rzeczy przekrojowych przez funkcjonalności (btw: dobra definicja epika "Since an epic becomes an epic if the team can’t commit to it")
- to, że wymagania mogą pochodzić z różnych źródeł i świadomość istnienia wszystkich interesariuszy wnosi lepsze zrozumienie pracy
Dla w/w rzeczy jakby nie było miejsca w backlogu, więc plątają się to tu to tam i każdy ma własny pomysł na ich przechowywanie. Brak jednolitego sposobu na przechowywanie wszystkich wymagań utrudnia ich komunikowanie, a zespołowi utrudnia złapanie szerszego kontekstu tego, co ma do zrobienia.
Format historyjki świetnie nadaje się do spisanie wszystkich punktów widzenia na tworzony produkt. Poniżej przykłady:
- Jako Klient chcę zamówić szkolenie, aby wziąć w nim udział
- Jako Zarząd chcemy dowiadywać się, jaki jest aktualny obrót, aby mieć informacje o aktualnych przychodach z portalu
- Jako Architekt chcę, aby system S czerpał informacje o klientach z naszego systemu V nadzorującego procesy biznesowe
- Jako Zespół chcemy pozbyć się ORMa, bo do tego typu projektu kompletnie się nie nadaje i spowalnia naszą pracę
- Jako Grafik, chcę aby używano Velocity zamiast JSP, abym mógł szybciej przygotowywać widoki
Jasne, że nie wszystkie wymienione historyjki idą na tablicę. Przynajmniej nie w pierwotnej postaci. Przede wszystkim:
- Zespołowi dają szerszy ogląd projektu
- Nie uciekają historyjki techniczne; niby powinny być podczepione pod US, ale zauważyłem, że jak coś nie jest wprost nazwane, to lubi się zagubić w mrokach niepamięci
Po za w/w wspomaganie się hisotryjową strukturą (Jako X, chcę Y, aby Z, bardzo pomaga w zbieraniu wymagań. Zazwyczaj jeśli, ktoś nie potrafi sformułować Z, czyli konkretnego powodu powiązanego z projektem, to sam z wymagania rezygnuje, bez większej przykrości.
No comments:
Post a Comment