Proces zwinny: jak i co należy udokumentować?

Jakiś czas temu firma, dla której pracuję, zleciła projekt rozwojowy stronie trzeciej. Przy opracowywaniu rozwiązania zastosowali zwinne praktyki. Jednak poproszeni o dokumentację, powiedzieliby tylko, że była wymagana, ponieważ została włączona do wiki lub jako część ich sprintu.

Po zakończeniu projektu odeszli ze wszystkimi zespołami projektowymi oprócz jednego. Witryna wiki projektu została zamknięta, gdy miała miejsce roczna subskrypcja.

Kiedy odeszli, wzięli większość wiedzy i zrozumienia tego, co zostało z nimi rozwinięte.

Mam więc 2 główne pytania;

1. Czy to jest normalne dla zwinnego, czy tylko usprawiedliwieniem, że nie chcesz tego pisać?
2. Jakie są normy branżowe dotyczące dokumentacji w zwinnych projektach, aby rejestrować wymagania dotyczące rozwoju, projekty, kluczowe decyzje i kontekst?

Czy to jest normalne dla zwinnego, czy tylko usprawiedliwieniem, że nie chcesz tego pisać?

Moja teoria jest taka, że ​​to dlatego zwinne rozprzestrzenianie się tak szybko, szczególnie scrum . Widziałem zbyt wiele zespołów chcących zwinnie się chronić (zamiast całej firmy). Problem polega na tym, że w wielu przypadkach metodologia jest wykorzystywana przez kierownictwo (ponieważ oni też chcą się chronić!).

Czy to oznacza, że ​​zwinny w ogóle nie działa? Oczywiście, że nie, to tylko oznacza, że ​​zwinny pomaga rozwiązać kilka typowych problemów, ale nadal kierujesz wszystkimi innymi. W wielu przypadkach zwinność po prostu nie jest odpowiednia dla tego zespołu w tej firmie.

Jakie są normy branżowe dotyczące dokumentacji w zwinnych projektach, aby rejestrować wymagania dotyczące rozwoju, projekty, kluczowe decyzje i kontekst?

Krótko mówiąc:

Zespół powinien określić, ile dokumentacji potrzebuje

Znają domenę, są ekspertami i, co ważniejsze, budują to!

To właśnie oznacza działające oprogramowanie w stosunku do obszernej dokumentacji w Manifeście Agile .

Czy zostawili ci zestaw testów TDD, testów akceptacyjnych lub innych testów jednostkowych? Wykonują dobrą robotę, dokumentując działanie aplikacji i oczekuje się, że będzie działać, a także zapewniając przykładową implementację sposobu wykorzystania opracowanej aplikacji.

Chociaż w żadnym wypadku nie jestem ekspertem Agile, oto moja próba odpowiedzi:

1. Czy istniała historia / wymaganie dotyczące konkretnej dokumentacji? Jeśli nie, jest to część problemu, ponieważ do pewnego stopnia dostajesz to, o co prosiłeś. To wymówka i zastanawiam się, co rozumiesz przez „normalne” tutaj. Czy to tylko większość z tych zasad Agile sprawia, że ​​coś jest normalne, czy też jest częścią ogólnego procesu, którego należy się spodziewać? To są dwa poglądy, które mogłem zobaczyć. EDYCJA: Wątpię, czy jest coś, co większość zespołów robi tak samo, jeśli chodzi o dokumentację, ale to zgaduję z mojej strony.

2. Kilka linków, które mogą być interesujące, dotyczy tego, co mogę najlepiej zrobić w tej sprawie:

   • Najlepsze praktyki dotyczące dokumentacji Agile / Lean
   • Dokumentacja zwinna i techniczna

Agile ma kilka konkretnych punktów w manifeście , w których wskazałbym ten wraz z notatką:

Działające oprogramowanie w obszernej dokumentacji

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

Są po prostu okropne. Nie wierzę, że zwinność oznacza brak dokumentacji. Powinny one przynajmniej śledzić opis aplikacji. Uzyskanie eksportu ich wiki byłoby miło lub pozwoliłoby komuś innemu na podniesienie opłaty za usługę.

To może nie być tak szczegółowe, jak niektóre próby. Teoria polega na tym, że w czasach kryzysu specyfikacje i tak nie są już zgodne z kodem. Masz więc wystarczającą dokumentację, aby napisać kod, a nie próbować go szczegółowo definiować (tak jak pisanie kodu w pseudo-werbalizowanym tekście / diagramie, a następnie w rzeczywistym kodzie).

Twój problem nie ma nic wspólnego z Agile. Powinni byli przygotować dokumentację, o którą prosiliście. Projekt był źle zarządzany.

Gdzieś powinien być przynajmniej opis funkcji, historii użytkowników i przypadków testowych . IT może znajdować się w plikach ReadMe w projektach, może być w komentarzach do kodu źródłowego, może znajdować się w dokumentach projektowych; może to być wszystko powyższe ... lub może to być MIA!

Z mojego doświadczenia wynika, że ​​zawsze wiele osób wymaga dokumentacji (byłem jedną z nich), ale w praktyce nikt tak naprawdę nie ma czasu ani chęci ich tworzenia. Czasami podejmowane są wysiłki, ale tworzona dokumentacja zwykle bardzo szybko staje się przestarzała i nie jest zsynchronizowana z rzeczywistym funkcjonowaniem systemu. Prowadzi to do sytuacji, w której nawet jeśli masz dokumentację, nikt tak naprawdę nie męczy jej sprawdzenia, ponieważ po prostu nie ufają jej dokładności.

Aby uzyskać prawdziwą dokładność i wiarygodne informacje, sprowadza się to do umiejętności odczytu kodu i testów. Klient, który chce (ponownie) odkryć, co robi jego system, może zawsze przeprowadzić wywiad i zapytać programistę, który może następnie (z pewnym dochodzeniem) przedstawić fakty na temat systemu.

Tworzenie dobrej dokumentacji nie jest trywialne i może być dość kosztowne. Po drugie, można zastanawiać się nad publicznością, dla kogo jest dokumentacja i do czego ma ona służyć?