Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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

 

programowanie

Komentarze

0 nowych
Druedain   14 #1 07.03.2012 18:07

W ten weekend byłem na wykładzie, gdzie jeden koleś opowiadał o ciągłej integracji, zaletach oraz rozszerzeniu idei na inne obszary związane z rozwojem projektu jak http://pl.wikipedia.org/wiki/Ci%C4%85g%C5%82a_integracja co powinno uzupełniać stosowanie powyższego patentu. Sam nie jestem praktykiem, żeby móc fajnie o tym opowiedzieć, ale wiem, że wszystkie wykłady były nagrywane, więc jeśli się pojawi to gdzieś w sieci, to tu wrzucę (chyba, że to będzie kiedyś tam i wcześniej wszyscy o tym zapomną).

Swoją drogą mam coraz większy problem z praktycznym podejściem. Od dłuższego czasu nie miałem niczego większego do napisania (jako student, nie pracuję), a samemu też jakoś nie mogłem pozbierać się do kupy. Od niedawna interesuję się Qt, więc może dla samego ćwiczenia coś tam pogrzebię, jeśli tylko zapału starczy… Bo zamiast tego interesuję się ostatnio dość mocno bardziej teoretycznymi rzeczami, jak np. technikami rozwijania programów, które wymagają pewnego dodatkowego narzutu pracy na początku, ale z czasem pozwalają bardzo łatwo dany program rozwijać. Problem polega na tym, że czasem bardzo fajne pomysły się rodzą z doświadczenia specjalistów, ale jak się jest laikiem to często rodzą one więcej pytań niż odpowiedzi. Nie chcę tutaj się rozpisywać, bo nurtujące mnie pytania bardziej nadają się na forum.

Ciekawy materiał i świetny film. Pozdrawiam! :)