DoD, czyli semantyka w służbie programowania

Minęło już trochę czasu od kiedy napisałem poprzedni wpis. Emocje już opadły, mój zapał do pisania na temat niezwiązane wprost z IT podobnie. Czas więc zacząć pisać o czymś, co wiąże się z tą działką nieco bardziej. Tym razem coś krótszego i lekko strawnego, ale wkrótce cykl o Sharepoint, czyli dlaczego IE jest lepsze od Firefox, Opery i Chrome razem wziętych. No dobrze, tylko o Sharepoint.

Definition of Done

Miesięcy kilka wstecz pisałem o programowaniu zwinnym. Właśnie w związku z tym sposobem tworzenia aplikacji najczęściej spotkać się można z pojęciem "definicji gotowe". Pozornie wydaje się, że odpowiedź na pytanie czy zadanie jest gotowe, jest błaha. Gotowe oznacza, że coś jest gotowe i tyle. Tymczasem programowanie wprowadzana konieczność weryfikacji znaczenia tego słowa. Czy bowiem gotowe jest wtedy, gdy kompiluje się bez błędów? A może wtedy, gdy przechodzi przez unit testy bez problemów? A może dopiero po utworzeniu dokumentacji (w projektach niezwinnych)?

A.C.R.T.D

Dla każdego projektu ten element może wyglądać inaczej. DoD może być inne dla różnych projektów

Zadanie sprintowe powinno zawsze mieć jasno określony i znany zespołowi cel. Najczęściej jest to nowa funkcjonalność, którą otrzymuje aplikacja. Trzeba jednak pamiętać, że zawsze lepsze jest wrogiem dobrego, ergo - wprowadzanie udogodnień do aplikacji może tę aplikacje w drobny mak roz... roz... wybić ze stanu stabilności. Dlatego wszelkie modyfikacje powinny zaczynać się od Analizy. Analiza może być przeprowadzona przez specjalnego człowieka w zespole, jednak nic nie stoi na przeszkodzie, by analizą pojedynczych zadań zajmowali się programiści. W końcu nikt nie zna aplikacji jak oni sami. To także dobry moment, żeby stworzyć podstawy do testów jednostkowych (mam na mysli określenie jakie testy ma przejść kod) lub wręcz je napisać. Ten etap powinien być jak najszybszy. Nie ma czasu bowiem na niekodowanie.

Po wykonaniu analizy przychodzi czas na Codowanie. Ten etap nie wymaga zdaje się tłumaczeń, poza tym, że jeśli do tej pory nie mieliśmy działających unit testów, to właśnie teraz trzeba je napisać. Z najnowszej gałęzi tworzymy więc trunka i zaczynamy.

Proces kodowania powinien trwać około 2/5 długości sprinta, po nim zaś następuje Review kodu, czyli proces, w którym inny członek zespołu weryfikuje poprawność kodu pod względem formalnym (zachowanie przyjętych standardów programowania, jak utrzymywanie nazw zmiennych, klas itd. w tym samym języku, poprawne formatowanie, komentarze) oraz pod względem poprawności "programistycznej" (odpowiednia wydajność kodu, odpowiednia obsługa wyjątków itd). Proces ten kończy się akceptacją kodu do testów przedprodukcyjnych.

Testowanie kodu to bardzo często niedoceniany element całego procesu, a może bardzo widowiskowo położyć całego sprinta. Testerzy weryfikują odporność kodu (bezpieczeństwo), wydajność, zgodność z celem sprintu, ale także integralność z istniejącymi gałęziami projektu, a więc wspomnianą stabilność całości.

Dopiero po tym etapie, gdy testerzy nie zgłoszą błędów nastąpić może status "gotowe". Ale, o czym już pisałem, w każdym projekcie może wyglądać to nieco inaczej. No i to by było na tyle w tym temacie ode mnie. Mam nadzieję, że komuś być może się przyda. Mnie się miło pisało, życzę więc miłego czytania.

PS.

Dla wszystkich, którzy jeszcze nie czują czym jest scrum, jakie ma zalety, jak się w nim pracuje oraz co znaczy done, krótki film