Doc Sprint

Jak myślisz, kiedy należy pisać dokumentację do projektu?


Wiesz jak to jest, zespół nie ma czasu na pisanie dokumentacji do istniejącego projektu, bo PM zawsze mówi, że brakuje jakieś bardzo ważnej funkcjonalności bez której to projekt nie ma sensu i dopiero jak skończy się tą jedną funkcjonalności to będzie czas na zrobienie dokumentacji. Ale później będzie błąd krytyczny lub inna bardzo ważna i potrzebna funkcjonalność i nadal nie będzie czasu na pisanie dokumentacji.

W metodyce scrum, sprint (przebieg) to przedział czasowy dostarczający klientowi działający produkt. Ale co z dokumentacją? Kiedy należy pisać dokumentację? Na końcu bieżącego sprintu czy na początku następnego sprintu? Czy lepiej jest na bieżąco pisać, czy jednak zmiany są zbyt często i lepiej jest pisać dokumentacje co kilka sprintów. Może jednak należy wyznaczyć osobny sprint do pisania dokumentacji?

Nie znam odpowiedzi na te pytania, ale podoba mi się koncepcja krótkiego sprintu poświęconego tylko na dokumentacje. Ten sprint nazywa się Doc Sprint. Doc Sprint może trwać od 2 do 3 dni. Jeżeli ten sprint potrzebowałby trwać dłużej niż 3 dni to oznacza, że dokumentacja jest źle zarządzana, za bardzo było się skoncentrowany na samej funkcjonalności projektu, albo mamy problem ze zbieraniem danych potrzebnych do dokumentacji (problem z knowledge sharingiem).

Wiem, że sprint bardziej jest dla klienta produktu niż dla zespołu, gdyż zasadą jest, że zmiany wprowadzone w sprincie musza być namacalne dla użytkowników (musza mieć nową widoczną funkcjonalność). Ale w trakcie sprintu można wprowadzić wewnętrzny, mniejszy sprint poświęcony tylko dokumentacji.