Agile Development – czyli dlaczego Test może być 5 krotnie dłuższy (droższy) niż implementacja

Dlaczego test może być 5 krotnie dłuższy (droższy) niż implementacja?

szczerze mówiąc nie mam zielonego pojęcia :)
Trochę przewrotnie. Niestety jeden z naszych klientów ocenił swój czas na testy takim właśnie faktorem: RAZY 5
Możesz pomyśleć sobie, że pracuję małej firmie gdzie zwykle projekty są niedoszacowane, źle zaplanowane, nie testujemy lub robimy work-for-food. BŁĄD
Nasza praca jest pokryta testami, gdyż kochamy TDD. Dobrze planujemy jak mniemam bo rzadko mijamy się z ocenami pracy: zarówno w dół (niedoszacowanie) jak i w górę (duży margines).
Gdzie leży więc problem … naszego klienta ???
Odpowiedź : w strukturze i ZARZĄDZANIU
Dlaczego?

Niestety (dla naszego klienta) problemów jest kilka.
Jednym z nich, PODSTAWOWYM, jest metoda zarządzania projektami. Klasyk: V-Model. Może równie źle to być prince(2), waterfall lub inny archaik. Co w nich takiego złego zapytasz? A to mój przyjacielu, że w projektach tego typu ramy określa 1 Super Człowiek, zwykle Projekt Manager. Ten nadczłowiek, lepiej powiedziawszy jasnowidz, musi zaplanować na długi czas zakres prac i budżet. Oczywiście zakłada margines ryzyka, powiedzmy standardowe 20%, pyta przerażonych deweloperów „ile czasu potrzebujecie” … czasami nasz śmiałęk nawet ocenia, że chłopaki chcą się poobijać więc robi presję na mniej, a oni się zgadzają.
Na tym kończy się fajna część projektu. Potem jest już tylko stres, nieaktualna dokumentacja no i balansowanie na linie :)
Błąd polega na tym, że nasz Super Manager nie rozumie jedynej stałej, a mianowicie: że jedyne co pewne w projekcie IT to ZMIANA. Nasz jasnowidz jednak miał doświadczenie i dołożył kilkaset procent do ram projektu…

Problem kolejny to struktura firmy. Kilka oddziałów, z czego każdy ma swojego Nadczłowieka. Generalnie nie przepadają za sobą, a z pewnością nie lubią świecić n zebraniu oczami, że ich część projektu jest poza ramą. Oni jednak tworzą kolejny problem: KOMUNIKACJI. Jeśli oddział A potrzebuje coś od oddziału B to musi to być pięknie opisane, najlepiej jakąś specyfikacją. Dalej, piszą to zwykle CI co nie do końca rozumieją problem. Dają to biednym technikom i … katastrofa. Specyfikacja ma błędy, więc „jakoś się dogadajcie”. Dogadanie nie jest jednak proste, ani łatwe, zaczynają się problemy. Może więc marginesik na problemy? W sumie czemu nie … następne procenty.

Projekt na „szczęście” trafia do managera wykonawczego. Ten dumnie prezentuje plan wykonawcy, wykonawca też przedstawia mu swój plan i … BUUUUUMMMMM.
Jak to możliwe, że TEST + trochę konfiguracji jest droższy od implementacji ? Jak nie wiesz to przeczytaj jeszcze raz od początku. Albo nie! BĄDŹ AGILE. Używaj SCRUM albo KANBAN albo XP i twórz projekty w zadowolonym zespole.

Informacje o @albgorski

Od 1999 roku profesjonalnie zajmuję się rozwijaniem oprogramowania. Głównie Java, ale także Groovy, PHP, HTML, JavaScript oraz Adobe Flex. Fascynują mnie metody wymiany danych, ich przechowywania oraz dostępowania. Jestem WIELKIM zwolennikiem Clean Code, TDD oraz agilistą (może lepiej lean-istą). Ekosystem Java dostarcza WIELE świetnych frawework-ów i bibliotek, a społeczność miłośników języka Java jest najlepsza pod słońcem :)
Ten wpis został opublikowany w kategorii agile, inżynieria opogramowania, java, pm, scrum i oznaczony tagami , , , , , , , . Dodaj zakładkę do bezpośredniego odnośnika.

Możliwość komentowania jest wyłączona.