Kiedy myślę o postawach zwinnego wytwarzania oprogramowania, zawsze przychodzi mi do głowy Manifest Agile. Jednak nie zawsze tak było! Kiedyś, jako osoba początkująca, uważałam, że źródłem wiedzy jest Scrum Guide… Bardziej wprawieni w boju wiedzą, że o ile Scrum „był pierwszy”, to właśnie Manifest Agile opisuje fundament. Moje ostatnie refleksje skłaniają mnie nawet do stwierdzenia, że gdyby nie istniała żadna metodyka, to tworząc produkty, ludzie empirycznie doszliby, posługując się zasadami Manifestu, do podobnych efektów. Bo liczy się właśnie to, co stanowi podstawę. Dziś, jako kontynuację artykułu „Ludzie i interakcje” biorą na warsztat kwestie dokumentacji. Zapraszam do lektury!
Dlaczego działające oprogramowanie ponad obszerną dokumentację?
Zastanawiałam się, jak twórcy Manifestu doszli do tego punktu. W pierwszym momencie pomyślałam o tym, że w podejściu klasycznym, kaskadowym, na początku powstaje szczegółowa dokumentacja. Później, w kolejnych fazach się ją omawia, estymuje potrzebną pracę i do końca projektu realizuje punkt po punkcie ustalony plan. Zatem, skoro dokumentacja kojarzy się z czymś “mało zwinnym” to trzeba postawić ją jasno na drugim miejscu.
Druga moja myśl dotyczyła chęci minimalizacji rzeczy (w tym przypadku dokumentacji), które zespół musi utrzymywać i aktualizować. Bo jak już zrobimy dokumentację, a okaże się, że jednak idziemy w inną stronę, coś uległo zmianie, a pierwotne założenia nie są już w mocy, to czas poświęcony do dokumentację jest stracony. W takim podejściu lepiej najpierw zrobić i oddać kawałek produktu, a potem go opisać.
Po dłuższym namyśle, doszłam do wniosku, że za bardzo skupiłam się na samej dokumentacji. To co tak naprawdę jest ważne, to działające oprogramowanie. Agile to podejście, które ma w założeniu tworzyć szybką pętlę zwrotną. Wypuszczamy na rynek oprogramowanie, obserwujemy jego użycie przez klientów, wyciągamy wnioski i adaptujemy produkt do najnowszej wiedzy z rynku.
Zatem, wydaje się, że w wielu przypadkach dokumentacja w Agile może zatrzymać lub spowolnić taką pętlę. Przychodzą mi do głowy dwa angielskie powiedzenia „better done than perfect” i „progress over comfort” – oba oznaczają dla mnie jedno podejście, dążenie do przodu zamiast pozostawanie w perfekcyjnym układzie, doprecyzowywaniu lub pozostawaniu w komforcie.
Dokumentacja w Agile też jest istotna
Zacznę od opowieści. Wyobraź sobie duży produkt, wiele zależności, sporo pracujących nad oprogramowaniem developerów. Nagle, jeden z nich, doświadczony, posiadający ogrom wiedzy o produkcie odchodzi. Razem z nim z firmy wyjdzie potężna dawka informacji, o tym jak działa pewna część środowiska, jego wady i zalety, jak wygląda praca z problemami i pewnie nierzadko rozwiązywanymi błędami. Co w takim wypadku może zrobić zespół? Oczywiście, można zrobić przejęcie wiedzy, spróbować zebrać od tej osoby jak najwięcej porad itd. Ale czy to wystarczy? Czy nic nie zostanie pominięte? Plus, czy to właściwe nastawienie, że dopiero w momencie kryzysu ratujemy się pozyskaniem wiedzy?
Często w projektach mówi się o silosach kompetencyjnych i to właśnie widzimy w powyższej historii. Gdyby zespół miał dobrze udokumentowane funkcjonalności, kod i zależności to może takie odejście nie byłoby problemem? Rzecz jasna, człowiek i jego indywidualne atuty wspierające produkt są nie do zastąpienia. Jednocześnie, posiadanie dobrej dokumentacji pozwala na utrzymanie produktu w dobrej kondycji. Nawet jeśli nie, to przynajmniej stanowi to dobre źródło informacji.
Nie raz miałam okazję obserwować odchodzenie z zespołu osób o ogromnym zasobie wiedzy produktowej. W tych miejscach, gdzie dokumentacja była ostatnią rzeczą o jakiej się myślało, zawsze wywoływało to strach i problemy. Tam, gdzie dokumentowanie produktu i kodu szło dobrze – nie stanowiło to zagrożenia.
Podsumowanie
W swoich rozważaniach skupiłam się głównie na problemie „utraty wiedzy” i tym, jak w takich wypadkach wspiera nas dokumentacja w Agile. Jest to oczywiście, tylko jeden z argumentów w zakresie tego, dlaczego dokumentowanie jest ważne. Przecież często dokumentacja jest wymagana ze względu na różnorakie formalności). Chciałam jednak zwrócić uwagę na to, że niby prosty, czy codzienny przypadek odejścia kogoś z zespołu, może zagrozić wiedzy w organizacji. Prostym rowziązaniem, czy też lepszym zabiegiem, czyli zapobieganiem takim sytuacjom może być ustalenie poziomu dokumentowania wiedzy i wzajemne egzekwowanie odpowiedzialności. Brak spisanej wiedzy może zagrozić działającemu oprogramowaniu, a to w Manifeście zostało postawione na pierwszym miejscu. Warto zatem popatrzeć na pisanie dokumentacji jak na zabezpieczenie i utrzymanie produktu.
Jak widać, i co z resztą wielokrotnie jest w zwinnym świecie jest powtarzane – prawa strona jest mniej istotna (dokumentacja) niż lewa (działające oprogramowanie), ale obie są ważne. Dokumentacja stanowi źródło wiedzy, ułatwia poznanie produktu, czy po prostu pozwala na wrócenie do niej gdy coś ucieknie z głowy.
Sprawdź nasze poprzednie wpisy:
- Rozgrzewka przed retrospektywą
- #WTMDareToBe i Agile Hunters już 26 kwietnia we Wrocławiu!
- Po co Product Ownerowi Kanban?
