Jak śledzić dokument wymagań w zwinnym zespole?

Rozumiem, że Historie użytkowników dominują w zwinnym świecie, ale w jaki sposób są przechowywane artefakty, aby nowi programiści, którzy dołączają do zespołu, mogli sprostać wymaganiom?

Co się stanie, jeśli historia użytkownika zmieni się później, jak zostanie zaktualizowana i zachowana jako artefakt? Widziałem wiele zespołów po prostu otwierających nowe zgłoszenie / zgłoszenie funkcji / raport o błędzie zamiast śledzić oryginalną historię.

Po pierwsze, prawie nic w odpowiedzi @ DXM nie odpowiada mojemu doświadczeniu z Agile, a zwłaszcza ze Scrumem.

Agile Manifesto stwierdza, że choć niepełna dokumentacja jest wartościowy, działa oprogramowanie jest bardziej wartościowe. Dokumentacja z pewnością nie jest złą rzeczą, ale powinna naprawdę służyć tworzeniu działającego oprogramowania.

Osoby i interakcje dotyczące procesów i narzędzi

Działające oprogramowanie w obszernej dokumentacji

Współpraca z klientami w zakresie negocjacji umów

Reagowanie na zmianę po wykonaniu planu

Oznacza to, że chociaż w przedmiotach po prawej stronie znajduje się wartość, bardziej cenimy przedmioty po lewej stronie.

Dopracowanie każdego szczegółu przed rozpoczęciem kodowania okazało się bezużyteczne, więc dokumentacja jest na ogół rozpatrywana w JIT (na czas). Oznacza to, że dokumentujesz, co faktycznie zamierzasz kodować.

Jednym z popularnych sposobów robienia Scruma jest korzystanie z historii użytkowników, które są przechowywane przez właściciela produktu i przechowywane w rejestrze produktu. Backlog produktu to dość wysoka lista wszystkich rzeczy, które musi wykonać rozwiązanie, a User Story to ogólnie dobry sposób na opisanie każdej rzeczy na liście. Historie użytkowników nie są obowiązkowe, ale wydają się dobrym sposobem, aby nie przesadzić z szczegółami i zamiast tego zainspirować do współpracy.

Tak więc, w każdym razie, gdy historia jest gotowa - zespół stworzył, przetestował i wdrożył coś, co spełnia kryteria akceptacji, historia nie jest WYZNACZONA, jest po prostu oznaczona jako ukończona w zaległości - więc zaległości mają pewne wskazania o tym, co zostało zrobione w każdym sprincie - historie i związane z nimi punkty. To pozwala ci obliczyć prędkość i jest cenną dokumentacją samą w sobie.

To powiedziawszy, historia użytkownika może być całą dokumentacją potrzebną do zrozumienia wymagań, ale bardziej prawdopodobne jest, że jest to coś, co może wygenerować rozmowę między klientem a zespołem programistów. W związku z tym podczas rozmowy można wykonać dowolną liczbę czynności. Jeśli jest to rzecz ad hoc, jak to często bywa, analityk / programiści mogą (i być może, w zależności od organizacji, powinni) zapisać wszelkie podjęte decyzje i zapisać je gdzieś, takie jak Wiki lub repozytorium dokumentacji. Jeśli jest to rozmowa e-mail, możesz zapisać wiadomości e-mail. Jeśli jest to sesja tablicy, zrób zdjęcie tablicy za pomocą telefonu komórkowego i zapisz ją. Chodzi o to, że te rzeczy pomagają ci wykonać kod i mogą ci pomóc później, jeśli będziesz musiał dowiedzieć się, jak i dlaczego zrobiłeś to tak, jak to zrobiłeś.

Inną metodą przechwytywania wymagań jest natychmiastowe osadzenie ich w przypadkach testowych (co moim zdaniem było celem DXM). Może to być naprawdę wydajne, ponieważ i tak musisz przetestować każde wymaganie. W takim przypadku możesz skutecznie przechowywać swoje wymagania w narzędziu testowym.

Jeśli historia jest ukończona (i zaakceptowana), a następnie użytkownik zmienia swoją potrzebę, cóż, prawdopodobnie musisz stworzyć nową historię. Jeśli korzystasz z wiki w swojej dokumentacji, możesz połączyć nową historię z oryginałem, a także link tej oryginalnej historii do nowych rzeczy, aby ktoś, kto na nią spojrzy, wiedział, że coś się zmieniło. To miło w wiki - łączenie rzeczy jest łatwe i dość bezbolesne. Jeśli stosujesz podejście oparte na testach, możesz zaktualizować przypadek testowy, aby poradzić sobie ze zmianą, lub utworzyć nowe przypadki testowe dla nowej historii, jeśli nowe i stare nie wykluczają się wzajemnie.

Ostatecznie zależy to od twoich potrzeb. Jeśli najważniejsze jest szybkie przyspieszenie ludzi, prawdopodobnie dobrym pomysłem jest napisanie dokumentu z prośbą o pomoc. Niech ktoś to zrobi. Jak wspomniałem, Wiki są świetnym narzędziem do utrzymywania tego rodzaju rzeczy, więc możesz rozważyć rozwiązania Atlassian, które mogą zintegrować Wiki Confluence z Jira i Greenhopper do śledzenia twoich historii / zadań / defektów i ogólnego zarządzania projektem. Istnieje również wiele innych narzędzi do wyboru.

[aktualizacja nr 1] Jak zauważył @MatthewFlynn, jego doświadczenie ze zwinnością, a także z wieloma innymi (w tym moją własną) bardzo różni się od odpowiedzi, którą tu przedstawiam. Odpowiedź tutaj opiera się na moich spostrzeżeniach o tym, co w przeszłości działało i nie działało w moim zespole, w połączeniu z wieloma książkami i blogami, które czytałem na ten temat ...

większość dążeń do sprawnego rozwoju jest szczególnie ukierunkowana na eliminację dokumentów wymagań.

Zwinny próbuje pozbyć się większości dokumentacji, a ja zgadzam się z ich pomysłami, ale ze wszystkimi dokumentami, wymagania były jak dotąd największe na pierwszy rzut oka. Powodem tego jest to, że dokumenty wymagań są najbardziej oddalone od rzeczywistego działającego kodu i wszystkich dokumentów, co czyni je

• najmniej dokładne
• najtrudniejszy do utrzymania
• najmniej użyteczny

Aby wskazać zespołowi, co należy dalej opracować, Agile zamienia dokumenty wymagań na zaległe historie, które określają, co powinieneś pracować przy elementach o najwyższym i najwyższym priorytecie z największym hukiem za złotówkę (zarówno obecną, jak i przyszłą złotówkę) są zazwyczaj umieszczane na pierwszym miejscu na tej liście.

Zaległości nie należy jednak mylić z dokumentem wymagań:

• W zaległościach tylko N liczba artykułów powinna zawierać szczegóły. Im dalej jest historia, tym mniej szczegółów należy w nią wpisać (tj. Nie marnuj czasu na próby zdefiniowania czegoś, co nie wydarzy się przez pół roku ).
• Poza pewnym punktem elementy „wymagań” nie powinny nawet być umieszczane w zaległościach, jeśli wypadają więcej niż 2 cykle wydawnicze (inaczej potencjalne przyrosty wysyłkowe (PSI)). Nawet jeśli wiesz, że wymaganie jest ważne i musi zostać wykonane w pewnym momencie, oprzyj się pokusie dodania go do zaległości. Jeśli to naprawdę ważne, ktoś zapamięta to w następnym wydaniu. Jeśli nikt tego nie pamięta, to najprawdopodobniej dlatego, że nie było to wcale takie ważne.

Po zakończeniu historii historia ta jest usuwana z zaległości i zostaje WYMIENIONA ⁽¹⁾ . Znów historie nie są wymaganiami. Mówią TYLKO zespołowi nad czym dalej pracować; nie są dla celów historycznych.

Jednak przy odpowiednim zwinnym procesie, za każdym razem, gdy dostarczasz pracę, częścią tej dostawy powinny być testy jednostkowe / integracyjne / akceptacyjne. Testy te są bardzo cenne, ponieważ mają wiele celów. Nie przejdę do pełnej listy, ale jednym z tych celów jest dokumentacja twojego obecnego oprogramowania produkcyjnego.

Test dokumentuje zachowanie oprogramowania, biorąc pod uwagę pewien zestaw danych wejściowych i warunków wstępnych. Dokumentuje również, jak korzystać z publicznych (i wewnętrznych) interfejsów API twojego kodu. Służy również jako siatka bezpieczeństwa, dzięki czemu gdy nowy programista wejdzie do zespołu i przypadkowo coś zepsuje, ten błąd zostanie wykryty, jak tylko zostanie sprawdzony.

Zwinny proces oczywiście promuje maksymalne wykorzystanie zautomatyzowanych testów jednostkowych, ale wszyscy wiemy, że nie wszystko można zautomatyzować. Twój pakiet oprogramowania będzie zawsze zawierał zestaw testów, które należy wykonać ręcznie. Jednak: a) programiści powinni aktywnie pracować nad automatyzacją w możliwie największym stopniu; oraz b) zespół testów jakości powinien regularnie wykonywać zespół ds. Kontroli jakości, aby jak najszybciej wykryć wszelkie przerwy w działaniu.

⁽¹⁾ - Odkąd otrzymałem kilka odpowiedzi dla części „wyrzuconej”. W ciągu 5 lat od przejścia na zwinność mój zespół nigdy nie wyrzucił ani jednej historii, nawet 30% tych, które zostały zaplanowane, a następnie odroczone, a następnie zapomniane. Mój szef chciał zachować je „w celach informacyjnych”, a jednak nikt nigdy nie oglądał żadnej z tych historii.

Ludzie są na ogół przywiązani do swoich danych i wiem, że trudno jest pojąć coś, co już masz, ale trzymanie pod ręką zapasów (fizycznych lub elektronicznych) nie jest darmowe, a im więcej o tym myślę, tym bardziej się zgadzam. z „chuck”. To jest z „Agile Software Wymagania: Wymagania Lean Praktyk dla zespołów, Programy, a Enterprise” (str.190) - „Historie użytkowników mogą być bezpiecznie wyrzucone po wdrożeniu To pozwala im lekki, utrzymuje je zespół przyjazny i. sprzyja negocjacjom, ale testy akceptacyjne trwają przez cały okres użytkowania aplikacji ... ”

Co się stanie, jeśli historia użytkownika zmieni się później, jak zostanie zaktualizowana i zachowana jako artefakt? Widziałem wiele zespołów po prostu otwierających nowe zgłoszenie / zgłoszenie funkcji / raport o błędzie zamiast śledzić oryginalną historię.

Zarządzanie dowolną dokumentacją może być trudne bez względu na to, czy korzystasz ze zwinnych historii, czy z dużego dokumentu z góry. Aby zmniejszyć obciążenie, dokumentacja powinna być minimalna i aktualizowana stopniowo, tak aby odpowiadała wysiłkom włożonym w testy i wdrożenie. Jak jednak wspomniał PO, po prostu aktualizacja dokumentacji grozi utratą historii ewolucji oprogramowania w czasie.

Czy to naprawdę ważne? Czasami może być. W większości chcesz po prostu przeglądać historie / UML / cokolwiek wraz z testami i samym kodem w chwili obecnej, jednak gdy pojawiają się pytania, dlaczego dana funkcja została zaimplementowana w określony sposób, często może to być przydatna spojrzeć na historię, aby zobaczyć, jak funkcja uległa zmianie w miarę upływu czasu, aby malować jaśniejszy obraz, dlaczego opcja implementacja X został wybrany zamiast opcji Y .

Istnieje kilka sposobów śledzenia takich artefaktów. Jedną z lepszych opcji może być przechowywanie opowieści w narzędziu, które pozwala na wersjonowanie tekstu opowieści w podobny sposób jak wersjonowanie kodu źródłowego. Wiki są w tym bardzo dobre, podobnie jak niektóre narzędzia do zarządzania projektami / problemami, takie jak Trac lub Redminektóre przechowują historię zmian samych problemów, a także strony wiki w tych systemach. Można to jednak zrobić nieco dalej, aby poprawić możliwość śledzenia zmian od problemu do obiektu, zapewniając, że nowe historie lub problemy są w jakiś sposób powiązane ze starszymi pokrewnymi problemami i historiami. Może to być tak proste, jak dodanie starszego numeru wydania / historii do tekstu nowszego numeru / historii, ale można je znacznie ulepszyć, dodając dowolny numer lub identyfikator historii do komentarza w mowie za każdym razem, gdy wprowadzasz zmiany w systemie kontroli wersji . Ta metoda ma jednak największą wartość, jeśli twoje zobowiązania są częste i ograniczają się do jednej historii lub problemu.

Największą trudnością jest oczywiście to, że tego rodzaju podejście wymaga starannej uwagi i zaangażowania każdego członka zespołu, aby być konsekwentnym i utrzymywać swoje małe i częste zobowiązania, a osoby zarządzające historiami i / lub systemami śledzenia problemów / projektów zachować na podstawie artefaktów, które zapewniają połączenia między obecnym stanem implementacji a wszystkimi poprzednimi zmianami.

To zostało powiedziane wcześniej, ale myślę, że sedno tego jest następujące:

• wymagania mogą obejmować wiele aspektów i zwykle skutkują więcej niż jedną historią.

• historia organizuje pracę zespołu w częściach, które są wystarczająco małe, aby zmieścić się w granicach czasowych sprintu.

• często istnieje wiele szczegółów, które należy zdefiniować, aby niektóre funkcje działały poprawnie. Właśnie wtedy zaczyna się przydawać trzymanie tych definicji w osobnym dokumencie wymagań - dla jasności, wspólnego zrozumienia i późniejszego odniesienia.

Rozważ legendarny przykład sklepu zoologicznego:

• Historia może brzmieć: „Jako użytkownik chcę zobaczyć podatek VAT wydrukowany na moim rachunku…”. Teraz obliczanie podatku VAT (podatku od wartości dodanej) może być skomplikowaną sprawą i prawdopodobnie wymaga więcej pracy, niż sugeruje ta historia.
• Może istnieć dodatkowa historia, która wymaga obliczenia podatku VAT (powiedzmy, pomnożyć całkowitą kwotę sprzedaży przez stawkę VAT ), ale prawdopodobnie nie obejmuje wszystkich odmian tego obliczenia.
• Na początku zespół skupiłby się na zapewnieniu podstawowego modułu, powiedzmy, biorąc listę towarów i ich ceny sprzedaży, i zwracając kwotę VAT. To jest coś, co zespół może osiągnąć w krótkim czasie.
• Prawdopodobnie będzie o wiele więcej historii obejmujących wszystkie możliwe przypadki obliczania podatku VAT.
• Aby zachować wiele różnych zasad obliczania podatku VAT widocznych w pojedynczych sprintach i poza nimi, warto zachować osobny dokument wymagań, w którym wymieniono wszystkie różne sposoby obliczania podatku VAT. Ten dokument może ewoluować z czasem. W rzeczywistości dodanie nowej sekcji może być częścią zadania, które należy wykonać.

Możesz użyć Freemind, aby zebrać listę funkcji. Jak to zrobić, spójrz na ten samouczek (gdzieś pośrodku).

Gdy masz listę funkcji, zaczynasz pisać historie użytkowników. Można to zrobić za pomocą prostego pliku tekstowego, dokumentu tekstowego lub czegoś tak złożonego jak zwinne narzędzie do zarządzania .

Gdy skończysz z historiami użytkowników, będą one traktowane priorytetowo. Później, z historii użytkowników, ludzie tworzą zadania, ludzie biorą zadania i implementują je w kodzie.

Wszystko to można zobaczyć, jak od samego początku zarządzany jest projekt ac # jesienią zwinnej serii obsady wideo .