Estymacje podczas wytwarzania oprogramowania są trochę jak zajęcia WF na studiach informatycznych – nie lubimy tego robić, często nie wiemy po co to robimy, a jak już to robimy, to zazwyczaj rezultaty są mocno rozczarowujące…
Lubimy czy nie lubimy – czasami trzeba to robić. Czasami trzeba odpowiedzieć na pytanie „kiedy będziemy mogli pokazać nasz system klientom?” albo „kiedy ta funkcjonalność będzie dostępna na produkcji?”
W artykule tym zebrałem cztery metody estymowania, z którymi zetknąłem się podczas pracy przy wytwarzaniu oprogramowania.
Metoda na eksperta
Mamy w zespole pewną szczególną osobę, nazwijmy go Zenkiem. Zenek jest w firmie od zawsze. Napisał połowę systemu własnymi rękami. Zna tajne zakamarki kodu, w które nikt inny nie ma odwagi się zapuszczać.
Mając jakiś temat do estymacji, możemy przyjść do Zenka i powiedzieć mu: „Słuchaj, potrzebujemy zaimplementować obsługę płatności przez PayPal. Ile to może zająć?”. Zenek wtedy myśli chwilę, drapie się po brodzie i mówi tak: „Robiliśmy taką integrację jakiś czas temu z PayU, tutaj API wygląda podobnie, trzeba będzie dołożyć nowe parametry w back-endzie, zrobimy reuse klas do rozliczania, myślę że jakieś 3 miesiące razem z testami”.
Jeżeli tylko mamy taką osobę i jeżeli jej przewidywania się sprawdzają – jesteśmy w bardzo dobrej sytuacji!
Natomiast bardzo często nie mamy takiego eksperta w zespole. Ta metoda ma jeszcze jedną wadę – kiepsko się skaluje. Im większy system, tym mniejsza szansa że znajdziemy osobę, która będzie w stanie ogarnąć wszystkie jego zakamarki.
Metoda „musi być gotowe do…”
W tej metodzie nikogo o nic nie pytamy. Tutaj Ktoś Ważny przychodzi do zespołu i mówi „Integracja z PayPalem musi być gotowa do pierwszego lipca”. Po tym stwierdzeniu zwykle padają jakieś motywatory, a zespół już wie, że nie ma co dyskutować, trzeba zewrzeć szyki, spiąć określone części ciała i zabrać się roboty.
Czy ta metoda jest skuteczna? Różnie z tym bywa. Czasami się udaje uratować świat, czasami nie. Czasami nie zdążenie na deadline ma bardzo przykre skutki, czasami okazuje się, że jak spóźnimy się o dwa miesiące, to nic złego się nie stało.
Natomiast ta metoda ma niepożądane skutki uboczne.
Po pierwsze, bardzo często metoda ta powoduje spadek motywacji zespołu – zwłaszcza wtedy, gdy osoba przynosząca termin nie jest zainteresowana poznaniem perspektywy zespołu. Zespół wtedy nie czuje się partnerem i nie ma poczucia wpływu.
A drugim skutkiem ubocznym jest wzrost długu technicznego. Jeżeli spieszymy się i musimy ścinać zakręty – najczęściej tniemy po jakości. W rezultacie powstaje system, który ma duży dług techniczny i którego utrzymanie staje się coraz bardziej kosztowne.
Byłem tam, nie polecam. Jedna gwiazdka na pięć.
Metoda pobożnych życzeń
Metoda trochę podobna do powyższej, ale jest jedna istotna różnica.
Musimy zrobić integrację z PayPalem, ale nikt nie wie kiedy ona będzie gotowa. Ktoś za pomocą rzutu kością o północy na rozstajnych drogach ustala datę wdrożenia i mówi „integracja z PayPalem powinna być gotowa do pierwszego lipca”. Ten termin nie ma żadnego uzasadnienia, został podany tylko dlatego, że trzeba było coś podać.
Nastaje wyznaczona data – i tu są dwie możliwości. Albo udało się i wtedy cieszymy się, że nasza metoda i pobożnych życzeń sprawdza się tak dobrze. Albo nie udało się i wtedy znowu mamy dwie możliwości. Albo wymyślamy nowy termin, albo ograniczamy zakres naszego projektu – czyli mówimy, że dostarczymy MVP (Minimal Viable Product), albo „MVP light”, albo „mini MVP albo zrobimy „technical go-live” czy „soft release”. Najczęściej taki „technical go-live” oznacza, że teoretycznie nasza funkcjonalność działa, ale w praktyce lepiej tego nie sprawdzać…
Metoda na dekompozycję
Jeżeli mamy na pokładzie jakiegoś menedżera projektu, to jest duża szansa na to, że będziemy dekomponować nasz projekt na pojedyncze zadania, szacować te zadania, a potem składać je razem w jakiś plan. Często ten plan jest prezentowany w postaci diagramu Gantta.
Czy to działa? To działa bardzo dobrze! W budownictwie. W przemyśle. We wszystkich przedsięwzięciach, w których jest duża szansa na to, że zaplanowane rzeczy uda się wykonać zgodnie z planem.
Ale przy wytwarzaniu oprogramowania ta metoda działa słabo.
Pierwszym powodem są trudności w dekompozycji i w szacowaniu zadań. Często na etapie planowania po prostu nie wiemy, jak będzie wyglądało nasze docelowe rozwiązanie i nie jesteśmy w stanie oszacować kosztów powstania tego rozwiązania.
Drugim powodem jest to, że czas realizacja zadania mocno zależy od zespołu lub od osoby, która je dostanie do wykonania.
A trzeci powód to rzeczy nieprzewidziane. Tutaj pozwolę sobie wkleić obrazek od Scotta Adamsa:
Metody widmo
Czy są inne sposoby estymacji? Są. Możemy przeczytać o metodzie punktów funkcyjnych, o estymacji parametrycznej, o technice PERT, o estymacji 3-punktowej… Te różne techniki łączy jedna rzecz: nigdy nie widziałem dużego projektu IT, który z sukcesem wykorzystywałyby jedną z tych metod.
Jeżeli ktoś z was ma pozytywne doświadczenia związane z wykorzystaniem PERT-a czy punktów funkcyjnych – dajcie znać!
Podsumowując…
Podsumowanie tego artykułu będzie smutne – żadnej z tych metod nie polecam.
Metoda na eksperta działa tylko w małej skali. Metoda na deadline („to musi być gotowe za miesiąc!”) ma destrukcyjne skutki uboczne. Pobożne życzenia to tylko pobożne życzenia. A dekompozycja na zadania składowe nie działa dobrze przy wytwarzaniu oprogramowania.
A czy jest jakaś metoda estymacji, która działa dobrze przy wytwarzaniu oprogramowania? Jest. Opiszę ją w następnym artykule.