Czego się wystrzegać podczas Estymowania?

Wiadomo, że estymowanie to temat kontrowersyjny. W branży są zwolennicy, jak i przeciwnicy szacowania czasu.

Czego się wystrzegać podczas Estymowania?

Wydawałoby się, że skoro praca programisty opiera się jedynie na klepaniu w klawiaturę, to wszystko powinno iść zgodnie z planem i każde ustalenie czasowe powinno być spełnione. Skoro tak, to czemu estymowanie ile czasu zajmie praca nad nową funkcją jest tak trudne i często wszystko trwa dłużej niż było ustalone na początku?

Moje doświadczenie z tworzeniem oprogramowania jest dosyć bogate. W końcu już ponad 9 lat pracy jako programista to nie w kij dmuchał. Temat estymat ciągnie się za mną już od początku kariery. Zawsze było to ogromne wyzwanie.

Z czego wynikało to wyzwanie?

Najczęściej z tego, że przedstawiane przeze mnie estymaty nie do końca sprawdzały się w rzeczywistości. I tu nawet nie chodzi o rodzaj estymat, czy to man-daye, czy też punkty lub egzotyczne zwierzęta. Po prostu okazywało się często, że moje przewidywania były zbyt optymistyczne.

Postanowiłem zastanowić się nieco z czego wynika problem i jakie elementy warto wziąć pod uwagę, żeby w przyszłości takich błędów nie popełniać. Udało mi się dzięki temu zidentyfikować 5 potencjalnych problemów z życia codziennego, które miały bezpośredni wpływ na jakość estymat w projekcie.

1. Niewystarczająca biegłość w projekcie

To jest jeden z typowych problemów. Programista/programiści są na tyle świeży w projekcie, że nie znają jeszcze wszystkich zależności i nie są w stanie określić złożoności projektu. Byłem w tym miejscu wielokrotnie podczas dołączania do nowych projektów i z tym aspektem jest sobie cieżko poradzić. Zdecydowanie nie można ulegać presji managementu i podawać przez jakiś czas bardziej pesymistyczne estymaty aż zdobędziemy biegłość w projekcie, do którego dołączyliśmy

2. Presja ze strony PO/Managera

Presja narzucana odgórnie jest również bardzo często występującym elementem, który negatywnie wpływa na jakość estymat. Byłem w tym miejscu wielokrotnie. Osoba zarządzająca projektem wymagała, żeby nowa funkcja była jak najszybciej, więc pod wpływem presji podawałem bardzo optymistyczne estymaty. Prowadziło to do dużej presji, która koniec końców wcale nie przyspieszała mojej pracy, a wręcz przeciwnie - powodowała zwiększoną ilość błędów i wydłużenie czasu wdrożenia

3. Nieodpowiednie przygotowanie specyfikacji

Ten problem jest chyba najczęściej występującym problemem. Nie pracowałem w ani jednym projekcie, gdzie praca zawsze była odpowiednio przemyślana. Częściej lub rzadziej zdarzało się, że w trakcie developmentu odnajdowałem dodatkowe elementy, które powodowały potrzebę pogłębienia analizy problemu do rozwiązania, przez co automatycznie praca wydłużała się. Ogólnie zbyt wczesne zaczynanie prac, bo "coś musi być szybko dowiezione" i "jest to taka malutka rzecz, która skończymy w kilka dni" niemal zawsze kończy się przestrzelonymi estymatami.

4. Niewystarczające zrozumienie problemu do rozwiązania przez programistę

Rozpoczynanie prac, kiedy programiści nie rozumieją jeszcze całkowicie konceptu, może być nie najlepsze w skutkach. Zdarzało mi się pracować nad funkcjami, których nie rozumiałem, a co za tym idzie odkrywałem o co chodzi dopiero w trakcie prac. Kończyło się to zawsze tym, że byłem w stanie zaproponować/dodać jakieś swoje sugestie dopiero w trakcie prac, przez co końcowy development musiał trwać dłużej, bo pojawiały się nowe możliwości, które trzeba przegadać i ewentualnie wprowadzić.

Wiadomo, że estymowanie to temat kontrowersyjny. W branży są zwolennicy, jak i przeciwnicy szacowania czasu. Jednak jakby na to nie patrzeć, programista, jako profesjonalista w swoim fachu powinien być wstanie z jak największą dokładnością określić, ile zajmie mu praca nad zadaniem, które robi. Jest to bardzo ważne dla biznesu! Dlatego z mojej perspektywy, powinniśmy estymaty robić i wystrzegać się przedstawiony przeze mnie błędów, tak aby było one jak najprecyzyjniejsze!