Scrum to iteracyjny i przyrostowy model oparty na zwinnych wartościach . Oznacza to, że nie masz oddzielnej fazy projektowania. Chodzi o to, że powinieneś stale zajmować się projektowaniem, tak jak stale zajmujesz się analizą, wdrażaniem, testowaniem i integracją w całym projekcie.
Potrzebujesz trochę planowania, aby to zadziałało. Weź udział w spotkaniu dotyczącym planowania sprintu , podczas którego zespół szacuje zadania na nadchodzący sprint. Większość ludzi nie zdaje sobie sprawy, że jest to nie tylko spotkanie szacunkowe, ale także wysiłek projektowy. Na przykład zadaniem może być „Dodaj kod dla nowego modelu samochodu”. Nie możesz jeszcze tego oszacować, musisz dowiedzieć się więcej. Zespół omawia więc projekt i proponuje szerokie rozwiązanie („podklasa Samochód?”) I dodaje to jako przypomnienie zadania. Rzadko potrzebujesz więcej formalności niż to. Masz teraz pomysł, jak rozwiązać problem. Nie masz jeszcze wszystkich szczegółów i to dobrze, znasz wystarczająco dużo projektu, aby móc wygodnie oszacować. Bez konieczności tworzenia jakichkolwiek diagramów (w tym momencie).
Aby uzyskać rzeczywistą dokumentację fizyczną , zalecam utworzenie na ścianie schematu przeglądowego systemu, aby wszyscy mogli go zobaczyć. Przegląd musi zawierać tylko najważniejsze klasy i moduły i rzadko powinien być aktualizowany. Bardzo pomocne jest także utworzenie kilku diagramów stanów dla najważniejszych klas w systemie. Posyp kilkoma wybranymi schematami sekwencji typowych przypadków użycia, aby ułatwić ludziom szybkie sprawdzenie, jak rzeczy się łączą. Zakładam, że możesz generować diagramy hierarchii klas na podstawie kodu, dzięki czemu problem można łatwo rozwiązać.
Zauważ, że wszystkie diagramy są tworzone po faktycznej implementacji. Jest to zgodne z „działającym oprogramowaniem nad obszerną dokumentacją” i projektem „just-in-time”.
I tak, czytelny kod jest zdecydowanie dokumentacją.