Dokumentacja Agile: równoważenie szybkości i retencji wiedzy

Różne dokumenty, artefakty i procesy związane z ich generowaniem to tylko niektóre z głównych symboli modelu Wodospadu. Zapożyczając od Lean, Agile traktuje wiele dokumentacji jako „odpady”, które należy wyeliminować, aby usprawnić cykl rozwoju.

Dla wielu kierowników projektów zrozumienie, w jaki sposób fazy wodospadu zamieniają się w sprinty, nie jest dużym wyzwaniem — ta sama praca jest wykonywana; jest po prostu inaczej zorganizowany. Jednak usunięcie większości dokumentacji jest trudniejszą do przełknięcia pigułką, ponieważ podkreśla zupełnie inny sposób pracy. Wymaga rozluźnienia wodzy kontroli, przyjęcia nieznanego i umożliwienia zespołowi dostawczemu podejmowania decyzji na miejscu.

Tradycyjne podejście do dokumentacji jest kwestionowane

W metodologii Waterfall dużo czasu poświęca się na udokumentowanie wymagań projektowych i uszczegółowienie rozwiązań. Ten proces działa, gdy wymagania są całkowicie jasne i jesteśmy pewni, że nic nie zmieni się w stosunku do tego, co zostało uchwycone i ustalone. Jednak doświadczenia większości firm z ostatnich kilkudziesięciu lat pokazują, że prawie nigdy nie jest to prawdą. W dzisiejszym świecie tempo zmian jest tak dynamiczne, że wraz z zakończeniem fazy dokumentacji potrzeby klienta zmieniają się znacząco.

Agile koncentruje się na wykonywaniu zadań i dodawaniu wartości interesariuszom. Jest zbudowany w taki sposób, że model zniechęca do pracy na peryferiach i do czynności, które nie dodają bezpośrednio i od razu wartości dla klienta.

Dokumentacja w Waterfall vs. Agile

Każda firma ma inny poziom dokumentacji, który może różnić się nawet na poziomie projektu. Ale oto jak wyglądają typowe procedury dokumentacyjne w projektach Waterfall i Agile:

Sprawa dokumentacji

Waterfall promuje znacznie bardziej rygorystyczne podejście do dokumentacji, które może wydawać się przesadne. Ale zanim odrzucimy to jako „odpady”, oto kilka korzyści płynących z posiadania solidnych procedur dokumentacji.

Szansa na strategiczne myślenie

Ci, którzy nie planują, planują porażkę. Dokumentacja zmusza kierownika projektu do usiąść i przemyśleć, a następnie znaleźć najlepsze rozwiązania. Ludzie czasami błędnie interpretują wartość Agile działającego oprogramowania w porównaniu z obszerną dokumentacją, co oznacza, że ​​żadna dokumentacja nie jest wymagana. Następnie pędzą na rynek, co Paul Adams, wiceprezes ds. produktu w firmie Intercom, opisuje jako rzucanie różnymi przedmiotami w ścianę i sprawdzanie, co się trzyma. Projektowanie rozwiązań, tworzenie planów, rozważanie działań – te działania tworzą wartość, oszczędzając czas na nierozwijaniu każdego pomysłu na funkcję, który przychodzi do głowy.

UX i spójność funkcjonalna

W miarę jak firmy rozwijają się od kilku założycieli do setek lub tysięcy pracowników, wiele różnych zespołów zaczyna pracować nad tymi samymi lub powiązanymi produktami. Zespół A może pomyśleć, że to, nad czym pracują, nie jest związane z tym, nad czym pracuje zespół B, ale dla użytkownika końcowego jest to ten sam produkt. Zamiast wielozadaniowych zespołów robiących swoje, przejrzysta dokumentacja dotycząca doświadczenia użytkownika i poziomów funkcjonalnych pozwala uniknąć niespójnego przepływu użytkowników.

Dokumentację można przekształcić w podręczniki użytkownika

W Waterfall dużo czasu poświęca się na szczegółowe omówienie rozwiązań i sposobu ich wykorzystania. Zdjęcia projektów o wysokiej wierności są tworzone dla programistów front-end. Przekształcenie wszystkich tych zasobów w wewnętrzne lub zewnętrzne podręczniki użytkownika wymaga mniej pracy niż tworzenie ich od podstaw.

Jak Agile zmniejsza zapotrzebowanie na dokumentację

Czynnikiem, który wielokrotnie pojawia się jako pretekst do zlecania dokumentacji, jest rotacja pracowników. Menedżerowie obawiają się utraty wiedzy instytucjonalnej, gdy ludzie odchodzą, a nowi dołączają, aby ich zastąpić. Skąd będą wiedzieć, co zostało wdrożone i jak to działa? Jak długo zajmie im nadrobienie zaległości? Czy obecny zespół będzie miał przepustowość, aby obsłużyć nowych członków zespołu?

Mamy nadzieję, że dobra dokumentacja szybko przyśpieszy nowych pracowników, którzy pracują przeważnie samodzielnie. Jednak Agile z natury zmniejsza potrzebę dokumentacji dzięki technikom współpracy, które jednocześnie skracają czas wdrażania. Oto kilka sposobów, w jakie Agile zmniejsza potrzebę dokumentacji.

Regularna interakcja między zespołami ds. produktów a członkami zespołu Agile

Manifest Agile promuje „osoby i interakcje ponad procesy i narzędzia”. Ponieważ wymagania zmieniają się w trakcie projektu i pojawiają się nowe pomysły, Agile zapewnia wyjaśnianie wymagań bezpośrednio ze źródła, zamiast polegać na pisemnych artefaktach, które wymagają ciągłej aktualizacji.

Pielęgnacja i planowanie dzieli zadania na sekcje

Uporządkowanie zaległości i planowanie sprintu dzielą funkcje na konkretne, możliwe do wdrożenia części, które są łatwe do zrozumienia i można nad nimi pracować niezależnie. Stwarza to możliwość dla nowo zatrudnionych pracowników na wczesnym etapie produktywności, nie rozumiejąc jeszcze pełnego obrazu całego projektu.

Historie użytkowników zapewniają wydajną dokumentację

Prosty format historyjek użytkownika pozwala kierownikom projektów na uchwycenie minimalnych wymagań, które tworzą wspólne zrozumienie między wszystkimi członkami zespołu. Nawet jeśli historyjka użytkownika nie zamieni się w sprint, marnotrawstwo związane z tworzeniem tego artefaktu dokumentacji jest bardzo niskie. W miarę jak historyjki użytkowników przechodzą do sprintów, można je uzupełniać i uzupełniać o inne wymagane informacje, takie jak szkielety, projekty, kryteria akceptacji itp. Proces ten zapewnia bardzo wydajne dostarczanie dokumentacji, która jest wysoce jednorazowa i tworzona na najbardziej odpowiednich etapach rozwoju.

Zmniejszona potrzeba dokumentacji kodu

Techniki, takie jak programowanie w parach i przegląd kodu, stwarzają ciągłe możliwości rozpowszechniania wiedzy technicznej w całym zespole, zwłaszcza nowym członkom zespołu. Ciągłe informacje zwrotne prowadzą do wspólnego zrozumienia, które ma również elastyczność w dostosowywaniu się do nowych okoliczności, zamiast szybko stać się nieaktualnymi w jakimś dokumencie.

Ceremonie Agile

Codzienne standupy, przeglądy sprintów i retrospektywy stwarzają szerokie możliwości rozwiązywania problemów i podejmowania decyzji twarzą w twarz, zamiast polegać na wiadomościach e-mail i dokumentach. Ograniczone ramy czasowe wszystkich ceremonii zapewniają, że priorytet mają tylko najważniejsze informacje, zamiast spędzać czas na dokumentowaniu wszystkiego, nawet jeśli prawdopodobnie nigdy nie zostaną wykorzystane.

Wszystkie powyższe, bezpośrednio lub pośrednio, ograniczają dokumentację i nadają priorytet realizacji celów projektu, zapewniając jednocześnie, że nic tak naprawdę nie zostanie utracone z powodu braku dokumentacji.

Hybrydowe podejścia do dokumentacji

Niektóre firmy nadal wolą mieć dokumentację, nawet w środowisku Agile. Agile nie ma charakteru nakazowego, ponieważ każdy projekt jest inny i ma unikalny zestaw okoliczności, którymi należy się zająć.

Poniżej znajduje się kilka przykładów tego, jak Agile można połączyć z bardziej czasochłonnymi metodami dokumentacji.

Łączenie UML i Agile

Rozważ użycie standardowego języka modelowania, takiego jak Unified Modeling Language (UML), który jest bardzo ustrukturyzowany i ma zdefiniowane jednostki do wizualizacji systemu. Dzięki temu treść jest bardzo prosta i skupiona na potrzebach oraz zapewnia minimalne użycie języka pisanego. Wygodnymi opcjami są między innymi narzędzia takie jak StarUML i Draw.io.

Generatory dokumentacji kodu

Innym podejściem jest upewnienie się, że kod jest dużo bardziej czytelny, poprzez wprowadzenie bardziej ustrukturyzowanych i szczegółowych komentarzy jako części szczegółów klasy, szczegółów metod, użycia parametrów, zależności i tak dalej. Istnieje wiele narzędzi automatyzujących proces generowania przydatnych dokumentów z kodu źródłowego i nazywane są one generatorami dokumentacji. Obejmują one od ogólnych po specyficzne dla języka programowania.

Szczegółowy projekt i dokumenty UX

Definiowanie wymagań za pomocą makiety, makiet, diagramów przepływu użytkownika, diagramów sekwencji itp. pomaga uprościć przepływ projektu, a także jasno wyjaśnia zespołowi technicznemu, co należy opracować. Dokumenty projektowe to świetny sposób na posiadanie bardziej sztywnej dokumentacji na różnym poziomie. Do tych zadań dostępne są różne narzędzia do tworzenia szkieletów i UX.

Narzędzia do zarządzania projektami Automatyzacja dokumentacji

Wydajniejsze zarządzanie projektami i powiązane narzędzia, takie jak JIRA, Confluence, Asana i Basecamp, umożliwiają przechowywanie wszystkich informacji związanych z projektem w jednym miejscu. Zadania można łączyć, oznaczać, zagnieżdżać i przypisywać różnym członkom zespołu, którzy mogą następnie zostawiać komentarze i zgłaszać wszelkie problemy. Wszystkie te działania, wraz z elastycznością dostosowania tych narzędzi, mogą stworzyć znaczną ilość dokumentacji przy niewielkim lub zerowym wysiłku.

Ponadto historycznie część potrzeb w zakresie dokumentacji wynika z wymogów sprawozdawczych. Interesariusze chcą mieć dostęp do wyników zespołu lub innych istotnych wskaźników. Narzędzia do zarządzania projektami ułatwiają automatyzację niestandardowych pulpitów nawigacyjnych i widoków, które odzwierciedlają postęp projektu i łączą się z odpowiednią dokumentacją w narzędziu.

Zarządzanie dokumentacją to ustawa bilansująca

Twórcy Manifestu Agile piszą, że cenią „działające oprogramowanie ponad obszerną dokumentację”. Dodają jednak również zastrzeżenie, że „podczas gdy przedmioty po prawej stronie mają wartość, [oni] bardziej cenią przedmioty po lewej stronie”. Agile nie sugeruje usuwania całej dokumentacji, ponieważ część dokumentacji oczywiście dostarcza wartości; sugeruje po prostu, że priorytetem powinno być działające oprogramowanie i dodawanie dokumentacji tylko w razie potrzeby, w zależności od okoliczności projektu i bez znacznego utrudniania postępu rozwoju.

Kierownicy projektów muszą osiągnąć równowagę między spędzaniem mniej czasu na dokumentacji i poświęcaniem większej ilości czasu na dostarczanie działającego oprogramowania i faktyczne ustalenie, gdzie jakaś forma dokumentacji jest niezbędna do długoterminowego sukcesu.