Jak zarządzanie wymaganiami działa w długim okresie z projektami Agile?

Zarządzanie wymaganiami w krótkim okresie dla projektów zwinnych wydaje mi się rozwiązanym problemem.

Z punktu widzenia Scruma nowe wymagania lub zmiany w istniejących wymaganiach są dostarczane poprzez Historie użytkowników. Opowiadania użytkowników pogrupowane według epickiej lub fabularnej funkcji ułatwiają realizację bardziej złożonych wymagań.

Oczywiście historia użytkownika nie jest technicznie dokumentem wymagań. Jest to zarządzalna grupa prac, która odwzorowuje coś, co często nazywa się Pionowym Kawałkiem funkcjonalności. A zakres tych historii można jednoznacznie określić za pomocą kryteriów akceptacji (AC).

Tak więc, chociaż Historie użytkowników nie są wymaganiami formalnymi, przeglądanie ich może dać całkiem jasny obraz ich podstawowych wymagań. W krótkim terminie.

Mówię krótko, ponieważ wraz z postępem projektu liczba historii użytkowników rośnie. Dlatego przeglądanie stale rosnącej listy artykułów w celu znalezienia wymagania staje się z czasem coraz mniej wydajne.

Ten problem jest spotęgowany, gdy weźmie się pod uwagę Historie użytkowników, które rozszerzają, zastępują, a nawet negują poprzednie Historie.

Teraz wyobraź sobie dwuletnią przerwę między iteracjami rozwojowymi projektu (stabilna w produkcji). Pierwszego zespołu nie ma, podobnie jak cała ich wiedza.

Jeśli pierwotny zespół wiedział, że tak się stanie (np. Jest to charakter działalności), to jakie środki mogłyby podjąć, aby pomóc kolejnym zespołom?

Oczywiście, zaległości dostarczą pewnych informacji, ale nie są one w formie łatwej do przeglądania.

Co więc można zrobić, aby kolejne zespoły zrozumiały stan projektu, w tym dlaczego i jak go zrealizowano ?

Z mojego doświadczenia wynika, że ​​następujące rzeczy nie działają:

• Przygotowywanie zaległości w celu usunięcia lub aktualizacji poprzednich historii użytkownika, aby zaległości można było odczytać jako dokument wymagań.
• Dokumentacja Sprinty, w których zadaniem członków zespołu jest dokumentowanie bieżącego stanu systemu.
• Dokumentacja poprzez testy behawioralne . To podejście jest jedynym, które widziałem, że jest bliskie pracy. Niestety testy zachowania kodowanego są ofiarami problemu nazewnictwa. Chociaż testy mogą poprawnie udokumentować system, zmobilizowanie zespołu programistów do napisania testów zgodnie z tą samą terminologią, brzmieniem i stylem Domeny jest prawie niemożliwe.

Powtórzmy więc:

Jak zarządza się wymaganiami projektu Agile w perspektywie długoterminowej?

Wydaje mi się, że to niewypowiedziany słoń w pokoju z projektami Agile: w jaki sposób zapobiegasz ich przemianie w chaos?

Spójrzmy przez chwilę na Manifest Agile. Zwinne pragnienia:

1. Wczesna i ciągła dostawa
2. Uwzględnianie zmieniających się wymagań
3. Częste dostarczanie działającego oprogramowania
4. Programiści i interesariusze biznesowi współpracują codziennie
5. Budowanie projektów wokół zmotywowanych osób, zapewnianie im środowiska i wsparcia, którego potrzebują, oraz ufanie im w wykonywaniu pracy
6. Rozmowa twarzą w twarz jako podstawowy tryb komunikacji
7. Działające oprogramowanie jako podstawowa miara postępu
8. Zrównoważony rozwój
9. Ciągła dbałość o doskonałość techniczną i dobry design
10. Prostota - maksymalizacja pracy, której nie musisz wykonywać
11. W regularnych odstępach czasu zespół zastanawia się, jak stać się bardziej skutecznym, a następnie odpowiednio dostosowuje i dostosowuje swoje zachowanie

Podkreśliłem ostatnie cztery. Dlaczego? Ponieważ to one zapobiegają zawaleniu się projektu pod własnym ciężarem.

Zrównoważony rozwój oznacza, że ​​(mam nadzieję) masz kogoś, kto nadzoruje cały proces rozwoju, kogoś, kto może poprowadzić statek poza rozwijanie oprogramowania naraz, kogoś, kto ma nadrzędną wizję całego projektu, kogoś z głęboką wiedzą architektury oprogramowania, projektowania systemu, zasad logiki biznesowej i ergonomii interfejsu użytkownika. Innymi słowy, architekt.

Architekt mówi: „Wiem, że o to prosiłeś, ale jeśli zbudujemy tę inną rzecz, możemy uniknąć tych trzech innych funkcji, które są po prostu mylące i skupić się na podstawowym wymogu”. To on daje zespołowi czas na zmniejszenie długu technicznego. To on wnosi do projektu nadrzędną strukturę i organizację. To on zwołuje spotkania, podczas których zespół się spotyka i pyta: „Jak możemy zrobić coś lepiej?”

I to on utrzymuje dokument wymagań głównych.

W książce Mastering the Requirements Process autorzy utrzymują, że istnieją trzy rodzaje klientów, trzy rodzaje projektów oprogramowania: Króliki, Konie i Słonie. Króliki to małe projekty oprogramowania, które wymagają jedynie nieformalnych wymagań; pracujesz bezpośrednio z klientem w małych sprintach, zakres projektu jest dość ograniczony, a oprogramowanie wykonuje się w stosunkowo krótkim czasie. Słonie to te gigantyczne projekty, które wymagają dużo wstępnego planowania, ogromnej ilości dokumentacji i długiego horyzontu czasowego. Prawdopodobnie nie są one zwinne, chociaż można je podzielić na mniejsze projekty, które można zbudować za pomocą zwinnego.

To projekty koni, które są nieco mylące ze zwinnej perspektywy. Nadal można je budować iteracyjnie, nadal można korzystać z krótkich sprintów, ale bez pewnej dyscypliny w gromadzeniu wymagań i procesach planowania mogą z łatwością zjechać z torów. Są to projekty, które mogą skorzystać ze zdyscyplinowanego procesu zbierania wymagań, a następnie ostrożnego dostosowania i modyfikacji tych wymagań w miarę rozwoju projektu, przy jednoczesnym zachowaniu nadrzędnej wizji całego projektu.

Z osobistego punktu widzenia współpracuję z niewielkim zespołem kilkunastu programistów. W dowolnym momencie możemy pracować nad trzema projektami oprogramowania w tym samym czasie, od kilku tysięcy wierszy kodu do ponad 100 000. Nasz klient myśli, że to królik, ale tak naprawdę to koń. Klient jest zaangażowany, ale nie codziennie.

Zdecydowanie naszym najsłabszym obszarem jest gromadzenie konkretnych, testowalnych, mierzalnych wymagań i zarządzanie oczekiwaniami klienta w odniesieniu do zakresu projektu. Ale pracujemy nad tym.

Pytanie nie jest do końca jasne, ale wygląda na to, że zajmujesz się śledzeniem wymagań . Z mojego doświadczenia wynika, że ​​jednym z pomysłów, które gubi się w Agile, jest to, że wymagania biznesowe są tym, czego klient chce od systemu, podczas gdy historie użytkowników są naprawdę funkcjonalnymi wymaganiami, które określają sposób działania systemu. „Jako użytkownik chcę mieć możliwość X.” Ale ma to na celu spełnienie wymagań, które mogą zostać utracone w historii użytkownika.

Z mojego doświadczenia wynika, że ​​łączę wymagania biznesowe i historie użytkowników w obu kierunkach. BR # 1 może być realizowany przez historie A i B. Historia C może obejmować BR # 2 i # 3. Umieść to w swoim trackerze projektu, arkuszu kalkulacyjnym, cokolwiek używasz.

W dłuższej perspektywie pomaga to powiązać to, o co prosi klient (BR) z tym, co robi system (historie), aby spełnić te wymagania. Powinna to być dość minimalna dokumentacja, która nie jest uciążliwa w utrzymaniu, przy zachowaniu zwinnego sposobu myślenia o nieprodukowaniu dokumentacji, której nikt nie potrzebuje i jest obowiązkiem na bieżąco.

Zapewnia to również nowym członkom projektu możliwość przyspieszenia, ponieważ mają coś do przejrzenia, aby poznać historię, dlaczego oprogramowanie robi to, co robi.

Właściwie pracuję nad projektem konserwacji Kanban dużego sklepu internetowego, w którym oryginalni programiści nie są już dostępni.

każda historia użytkownika / wymaganie / poprawka ma numer biletu, a każda zmiana kodu źródłowego jest powiązana z numerem biletu w polu komentarza kontroli źródła.

sourcecontrol-checkin-s (svn) atomatycznie aktualizuje bilet z rdzeniem, tak że w bilecie mam link do wszystkich zestawów zmian sourceconrtol.

Jeśli moduł / funkcja jest nowo zaimplementowana, w kodzie źródłowym znajdują się również numery biletów.

W systemie biletowym (redmine) bilety są ze sobą powiązane, ponieważ (jest duplikatem, jest błędem, jest udoskonaleniem, ...)

dzięki czemu możesz śledzić zgłoszenia i zobaczyć zmiany wymagań w czasie.

Przykład: muszę znaleźć coś na „stronie internetowej OrderConfirmation”. W kodzie źródłowym strony widzę komentarz: „stworzony dla” # 4711 ”, więc mogę połączyć mój nowy bilet ze starym biletem„ 4711 ”lub jednym z jego następców.

Osobiście odrzucam historie użytkowników jako źródło dokumentacji na temat tego, co może zrobić system. O ile nie podjęto aktywnych kroków w celu stworzenia dokumentacji (co zrobiliśmy dla niektórych naszych bardziej tradycyjnych klientów), baza aplikacji jest naprawdę najlepszą dostępną dokumentacją.

Chociaż to nic nowego.

Jeśli używasz bardziej skalowanej wersji Agile (takiej jak SAFe ), będziesz mieć inne zaległości, które nie są zaległościami implementacyjnymi. Zasadniczo wygląda to tak:

1. Portfolio Backlog (strategiczne planowanie eposów i budżetów)
2. Rejestr programu / wydania (funkcje i epiki)
3. Backlog projektu / zespołu (historie, kolce, błędy)

Nie polecałbym dokumentowania na poziomie Backlogu Zespołu. Jest zbyt szczegółowy i rzadko ktoś chce przejść do tego poziomu szczegółowości. Nie wspominając, że w wydaniu mogą znajdować się historie, które są sprzeczne z poprzednimi historiami w zaległościach zespołu.

Zamiast tego zalecam pracę na poziomie Backlog wydania w celu dostarczenia dokumentacji na poziomie Release. Historie te rzadko wysadzają się po przypisaniu do konkretnego wydania i mogą być stabilnym i szybkim sposobem na sprawdzenie, nad czym pracują poszczególne wydania.