Zwinne metody programowania oraz metodyka SCRUM stosowane są w większości firm wytwarzających oprogramowanie na świecie. W rękach sprawnego, dobrze zorientowanego w temacie zespołu SCRUM stanowi doskonałe narzędzie do organizacji i rozwoju projektu. Pomimo, że metodyka ta ma pomagać w tworzeniu oprogramowania, często przeszkadza – szczególnie w małych firmach, które nie opanowały zasad tej metodologii do końca lub nie rozumieją sposobu kontroli utylizacji zadań przez programistę. Oto najczęstsze spotykane błędy, które miałem okazję podziwiać w trakcie pracy w środowiskach SCRUMowych.

1. Jestem szefem, więc decyduję, kto ma jak pracować!

Źle: Przydział tasków dla poszczególnych programistów często stosowany jest w małych firmach, w których kierownictwo stara się utrzymywać w ryzach „obijających się programistów”. To niestety prawda, iż pion decyzyjny często nie rozumie, czym tak do końca jest SCRUM. Przydzielanie zadań „na siłę” często kończy się przekroczeniem estymowanego czasu, na wykonanie zadania a tym samym powoduje znaczne przekroczenie terminu realizacji zlecenia. Managerów tego typu nazwał bym mianem kaskaderów i nie traktował poważnie!

Dobrze: Programista sam wybiera taski z określonego sprintu, wg swoich umiejętności. User story separowany na trzy logiczne części – frontend, backend i organizację – doskonale uproszcza proces podejmowania zadań przez odpowiednich specjalistów. Frontend to nie tylko HTML i CSS tak jak backend to nie tylko JAVA, PHP lub .NET. Programiści powinni być tutaj świadomymi swoich umiejętności i to oni powinni realizować zadania, starając się przy tym nie przekroczyć ich estymacji czasowej.

2. Szybko, szybciej…

Źle: Zbyt skrupulatna estymacja poszczególnych tasków – niedoszacowanie – może powodować, że projekt nie zostanie ukończony na czas. W SCRUM stosujemy estymację – przybliżone oszacowanie – czasu wykonania zadania. Powinno być ono realne do wykonania i zaproponowane przez programistę a nie pion kierowniczy. Niestety spotkałem się wielokrotnie z sytuacją, w której za oszacowanie czasu, koniecznego na wykonanie zadania, zabierał się kierownik, dyrektor lub ktoś, kto zupełnie nie miał pojęcia o tym, jak wydajny zespół programistów posiada. Efekty tych „niedoszacowań” bywały często tragiczne.

Dobrze: Estymacja zadań powinna odbywać się poprzez głosowanie. Polega ono na tym, iż zespół spotyka się na początku każdego ze sprintów i określa czas, konieczny na wykonanie każdego tasku przydzielonego do sprintu. Głosowanie polega na określeniu odpowiedniej ilości punktów scenariusza (story point). Przykładowym podziałem story points może być następujący zestaw punktów zależnych od czasu:

Story points Nakład czasu
1 1-3 godzin
2 4-6 godzin
3 7-9 godzin
5 10-13 godzin
8 14-16 godzin
10 17-19 godzin
13 ponad 20 godzin

4. Wyjdzie w praniu…

Źle: Niedookreślone zadania sprawiają, że estymacja również bywa bardzo niedookreslona. Brak dokładnego opisu, wizualizacji, dokumentacji sprawia, że task – często wyglądający niepozornie – może przy głębszej analizie stać się ogromnym przedsięwzięciem. Brak ustalonych szczegółów wpływa negatywnie na proces estymacji oraz określenia statusu tasków – np. blokerów (blokujących dalszą pracę. Od nich zależą kolejne taski) bądź tasków krytycznych (niezwykle istotnych dla dalszej pracy – np. zmiana implementacji interfejsu API, na którym bazować będzie aplikacja).

Dobrze: Dobrze określone zadania oraz scenariusze użytkowników sprawiają, że estymacja przeprowadzana jest w bardziej świadomy sposób. Nie wahaj się więc wykorzystać pól „description” w aplikacjach do zarządzania SCRUM-em. Określ kryteria akceptacji wykonania zadania (Acceptance Criteria), w których opiszesz, jakie założenia musi spełnić rozwiązanie, aby mogło być rozważone, jako zakończone. Jako załączniki stosuj dokumentację, wizualizacje, wymagania klienta, notatki. Podziel user story na części logiczne – frontend, backend i organizacja – zgodnie z zasadą „dziel i rządź”.

5. Skończyłem pracę! Mam luz…

Źle: Niedopełniony sprint sprawia, że pod jego koniec programiści nie mają nic więcej do roboty. Odwrotnie natomiast przedstawia się sytuacja odnośnie pozostałego backloga i jego utylizacji. Ilość scenariuszy użytkowników pozostałych w backlogu sprawia, że koniec projektu bywa bardzo ciężkim o ile nie niemożliwym do wykonania w realnym czasie.

Dobrze: Jeśli sprint jest niedopełniony, pozwól programistom na dobieranie zadań z backloga. Pozwoli to na lepsze wykorzystanie czasu, który pozostał w danym sprincie i odciąży ostatnią fazę projektu.

6. Na pewno się nie wyrobię!

Źle: Odwrotnie do poprzedniego punktu, sprint może zostać przeładowany. Jest to bardzo częsty przypadek, występujący u młodych, ambitnych project managerów, którzy za wszelką cenę chcą zakończyć projekt przed czasem „na wszelki wypadek”. Niestety, jak doświadczenie niejednokrotnie mi pokazało, tego typu podejście kończy się przeciążeniem zespołu, licznymi nadgodzinami i końcowym zawaleniem terminu. Zmęczony pracownik to żaden pracownik! Co z tego, że dziś napisze pierdyliard linii kodu by spełnić oczekiwanie PM’a, jeśli jutro będzie musiał je poprawić, lub co gorsza usunąć. Ani nie przysparza to rozpędu dla projektu, ani nie gwarantuje, że taski wykonywane są odpowiedzialnie, z zachowaniem wszelkich zasad dobrej jakości kodu.

Dobrze: Staraj się, aby nie przeładowywać sprintu. W najgorszym przypadku pozwolisz programistom na pobranie dodatkowych zadań z backloga ale nie wyjdziesz na idiotę przed klientem, któremu naobiecywałeś złote góry. Przelicz story points na realne godziny pracy. Zestaw to z ilością odpowiednich specjalistów w zespole. Z mojej praktyki zauważam, że najlepszym stosunkiem story points do dostępnych zasobów jest stosunek 0.75. Oznacza to w praktyce, że ilość godzin pracy programisty wynikająca ze sprintu powinna wynosić 0.75 (75%) jego dostępnego czasu całkowitej pracy. Pozostałe 25% pozostawiam na ewentualne „zdobycie koniecznych informacji”, doprecyzowanie i przerwy na regenerację w trakcie pracy. W niektórych przypadkach parametr ten warto obniżyć nawet do 65%.

7. Po co komu Code Review! To strata czasu…

Źle: Właściwie to stosuję to jako dodatek – ponieważ ten topic powinien wylądować w poście nt. dobrych praktyk i jakości kodu. W małych firmach, które często obłożone są projektami, często spotyka się zjawisko pominięcia praktyk związanych z dbaniem o dobrą jakość kodu. Najczęstszym błędem jest tutaj pominięcie fazy Code Review tuż po umieszczeniu kodu aplikacji w repozytorium rozwojowym. Małe firmy nie wykorzystują tego doskonałego narzędzia, które weryfikuje pracę każdego programisty. Krzyżowe code review sprawia, że częste trywialne błedy wyłapywane są jeszcze przed merge requestem z główną gałęzią deweloperską repozytorium kodu.

Dobrze: Code Review doskonale podnosi jakość aplikacji ale także… umiejętności programistyczne samych developerów. Mająca swoje korzenie w programowaniu w parach (hot seat, pair programming, shadow programming) metodyka sprawia, że programiści na wzajem starają się wyłapać błędy kolegów, co znacząco poprawia efekt końcowy w formie czytelnego, zrozumiałego i dobrze zaprojektowanego kodu. To podejście nie kosztuje zbyt wiele czasu czy pieniędzy a w efekcie samo może przynieść znaczący zysk – nie tylko finansowy!

Przedstawiłem Wam przykłady błędów SCRUMowych, z którymi najczęściej się spotkałem. Jakie są natomiast wasze doświadczenia? Zapraszam do dyskusji.