Jak pisać dokumentację w Agile / Scrum?
Agile/Scrum jest ostatnio bardzo modą metodyką prowadzenia projektów. Ten „fenomen” wyjaśniłem już na blogu w wpisie Dlaczego większość projektów prowadzonych jest Scrum?
Dzisiaj jednak chcę poruszyć ten temat z innej strony. Znam wielu kierowników projektów, którzy decydują się na Agile/Scrum… jednak nie znam żadnego (słownie: zero), ilu by podczas scrum tworzyło dokumentację.
Nie mam czasu na dokumentację
Zacząłem więc drążyć temat w rozmowach pytając: dlaczego?
Najczęstszą z odpowiedzi jaką zazwyczaj słyszę jest ogólnie przyjęty „brak czasu”. Ludzie są zbyt zajęci bieżączką, zbyt dużo „tematów” jest otwartych równolegle.
Tłumaczenie się „brakiem czasu” w tym przypadku trochę przypomina mi bieganie z pustą taczką bo nie ma czasu na jej załadowanie. To właśnie napisanie dokumentacji daje Ci więcej czasu. Trzeba myśleć o jej tworzeniu jak o inwestycji czasowej. Najpierw inwestujesz czas, by odebrać go z nadwyżką.
Nie chcę żebyś zrozumiał mnie źle – nie jestem ortodoksem, jeśli chodzi o dokumentacje. Rozumiem, że są gorące okresy w niektórych branżach, kiedy naprawdę nie ma czasu na nic innego poza „próbą nie utonięcia”.
Jednak nie o takie brak okresy mi chodzi, a o wymówkę, którą stosują ludzie bo tak naprawdę nie wiedzą jak napisać dokumentację sprawnie i zrozumiale.
Wiedza o Dokumentacji IT na twój adres e-mail?
W Agile/Scrum nie tworzy się dokumentacji…
Kolejnym argumentem osób prowadzących projekty w Scrum było powołanie się na manifest Agile. Podejrzewam, że chodzi o zdanie „Working software over comprehensive documentation„.
Jednak w mojej opinii to wcale nie mówi o nietworzeniu dokumentacji 😥
W wolnym tłumaczeniu to znaczy „Działające oprogramowanie ponad obszerną dokumentacją”. Myślę, że każdy się pod tym podpisze.
Sęk w tym, że tu nie chodzi o NIE PISANIE DOKUMENTACJI, a jedynie o kwestie priorytetów. Lepiej mieć działający software bez dokumentacji, niż nie działający z dokumentacją.
Ale prawdziwym sukcesem jest mieć działający z dokumentacją (chociażby taką „z grubsza”).
Mam wrażenie, że często nie zdajemy sobie sprawy z korzyści jakie niesie dokumentacja. Imho (w większości przypadków) w finalnym rozrachunku: CZAS TWORZENIA DOKUMENTACJI vs KORZYŚCI Z JEJ NAPISANIA jest zawsze na korzyść tworzenia.
Dlaczego warto pisać dokumentację?
Musisz pamiętać, że:
🔸 tworząc dokumentację „spuszczasz się” z całym procesem myślowym. Robisz syntezę projektu, który chodzi Ci po głowie. Możesz zauważyć problemy ZANIM OPÓŹNIĄ REALIZACJĘ;
Czy chcesz mieć taką korzyść podczas Scrum? Hell yeah.
Wyobraź sobie, że zwiększasz ilość realizowanych zadań w sprincie i redukujesz ilość błędów.
🔸 pisząc dokumentację RAZ, to jakbyś MÓWIŁ JĄ WIELE RAZY, z tym, że nie tracisz na to czasu. Czyli inwestycja czasowa jest jedna (utworzenie dokumentu). Natomiast zwróć uwagę o ile łatwiej jest się wdrożyć nowym programistom gdy prowadzisz dokumentację (nawet zwykły manual użytkowników).
🔸 Powinieneś też rozważyć jak wpływa NIE TWORZENIE dokumentacji na Twój projekt. Czyli ile czasu tracicie na „głupawe” pomyłki bo na przykład dwie różne rzeczy nazywacie tak samo?
Heh, mógłbym tych przykładów mnożyć i mnożyć, ale mam nadzieję, że wyjąłeś główny sens tego wpisu dla siebie.
Tak naprawdę wdrożenie tworzenia dokumentacji w Scrum nie jest rocket science – nawet jeśli jesteście turbo obłożeni. A wiem, bo zdarzało mi się pracować w Scrum i tworzyć dokumentację (w wymiernej obszerności względem czasu sprintu).
Dokumentacja & Agile/Scrum – jak?
Chodzi o to, że możecie przeznaczyć kilka godzin ze sprintu (fajnie sprawdzają się 10 dniowe), gdzie:
- product owner przygotuje opisy – po co mówić setki razy to samo. Na planowanie sprintu można się przygotować i przynieść ze sobą „tekst” zamiast tłumaczyć i pozwolić każdemu inaczej zrozumieć. Wtedy scrum master ma gotowe narzędzia tekstowe do przydzielenia.
Jeśli w trakcie planowania są pytania do dokumentu to możecie je zawrzeć na dole jako Q&A – wtedy nic nie umknie, będzie można do tego wrócić w każdej chwili.
Taki proces pozwoli Twojemu product ownerowi tworzyć coraz lepsze opisy.
FYI: tutaj nie chodzi mi o „wyrafinowaną dokumentację” – możecie zacząć od bardziej precyzyjnego opisu zadań. - jeśli product owner z różnych powodów nie może przygotować opisu to po rozplanowaniu sprintu takie opisy mogą przygotować programiści do swoich zadań. Tutaj też nie mam na myśli „wyrafinowanej dokumentacji” a bardziej precyzyjnego opisu zadań, który pomoże programistom „ułożyć sobie w głowie” zakres zadania. Wyłapać potencjalne problemy zanim wystąpią (tak właśnie działa pisanie – wylewamy z siebie różne koncepcje).
- lub jeśli programiści nie mogą, to idealnie jeśli dysponujecie analitykiem/kierownikiem projektu, który takie opisy może przygotować. Wtedy prawdopodobnie zrobi to „poza czasem sprintu”. Takie opisy można przekazać swoim QA (quality assurance), testerom – żeby wiedzieli czy dane działanie to błąd czy feature 🙂 Rozstrzygną to odwołując się do dokumentu, tym samym wskazując programistom jak powinno to działać.
Mam nadzieję, że Ci pomogłem, albo chociaż rozjaśniłem pewne kwestie 🙂
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
