Specyfikacja w Scrumie

Cześć, od kilka dni nurtowało mnie pytanie, jak powinna wyglądać specyfikacja projektowa. Chciałem stworzyć prosty projekt, ale nie widziałem zbytnio jak ma on wyglądać. Zacząłem od projektowania i pisania dokumentacji. Szybko zorientowałem się, że marnuje na to tylko czas i zacząłem się zastanawiać jak to się robi w Scrumie, gdzie teoretycznie nie marnuje się czasu na zbędne rzeczy.

Nie robi się specyfikacji

Po dłuższym czytaniu o Scrumie, zrozumiałem, że nie mówi on nic o dokumentacji projektowej. Nie ma czegoś takiego jak projekt systemu oraz opis implementacji poszczególnych technologii. W trakcie pisania właśnie takiego projektu, też doszedłem do wniosku, że łatwiej byłoby to opisać w kodzie. Skupić się na dobrych praktykach programowania i utworzyć kod, który sam się opisuje. Taka dokumentacja jest zbędna, a najczęściej bardzo nieaktualna. Dodatkowo, jeżeli coś poprawiamy w kodzie, powinniśmy też w dokumentacji i vice versa. Marnujemy przez to dużo czasu i nie zachowujemy zasady DRY.

Skąd, więc wiedzieć co mamy napisać?

Programista powinien mieć wolną rękę na styl programowania zleconego zadania. Owszem zespół może przyjąć jakieś praktyki, wzorce, założenia. Nie powinien jednak mieć ich sztywno narzuconych od osób trzecich.

Wiedzę o systemie dostajemy od Product Ownera. To on przedstawia zespołowi, czego oczekuje. Przekazać to może za pomocą User Story, User Case, opisu jak sobie to wyobraża lub jakichkolwiek obrazków. Ciągły kontakt z klientem powinien rozwiewać wątpliwości co do szczegółów zasad działania systemu. Sposób implementacji tego, akurat powinniśmy wyznaczyć sobie sami.

Dokumentacja jednak jest ważna dla użytkownika

Ustaliliśmy, że przekazane dane od użytkownika powinien jednak być jakoś udokumentowany. Do tego najczęściej używa się dodając link'i do różnych źródeł dla naszych zadań.

Dokumentację instalacji systemu, obsługi programu, opisu API systemu itp. musimy tworzyć. Nie opisujemy jedynie szczegółowo kodu oraz projektu. Piszemy dokumenty ważne dla użytkownika. Owszem, czasami wymaga też szczegółowego opisu algorytmu (skoro jest to w kodzie, można zautomatyzować generowanie takiego opisu), tego nie obejdziemy. Jednakże, to już jest wymaganie użytkownika i nie możemy uważać wtedy za stratę czasu.

Podsumowując

Nie marnujmy czasu na specyfikację projektową oraz implementacji. Zbierzmy wymagania i zacznijmy od razu się za implementację kodu (tutaj w dużym skrócie, czasami ważne są inne kroki). A jakie są Wasze spostrzeżenia o dokumentacji? Uważacie ją za ważną? Zostawcie komentarze, na pewno będą inspiracją do kolejnych wpisów.