Estymacja okiem programisty

  • Home
  • /
  • Blog
  • /
  • Estymacja okiem programisty

Estymacja okiem programisty

13 listopada 2018

Teoria projektów definiuje projekt jako byt, który posiada datę zakończenia. Tym samym najmniejsze zadanie lub cel jaki sobie stawiamy możemy określić mianem projektu, o ile ustalimy datę zakończenia.

Najlepsza estymacja to taka, która określa czas potrzebny na zakończenie zadania. Precyzyjna estymacja jest w większości przypadków niezwykle trudnym zadaniem. W sytuacji kiedy estymujemy po raz pierwszy zadanie, z którym nigdy wcześniej się nie spotkaliśmy, istnieje szansa, że nie uda się nam poprawnie określić czasu jaki spędzimy nad zadaniem.

Co wpływa na estymację? Istnieje wiele czynników mających bezpośredni wpływ na estymację zadania. Pierwszym etapem jest przeprowadzenie wywiadu z klientem na temat jego oczekiwań względem projektu. Jest to kluczowa kwestia, ponieważ niedokładne zebranie informacji czy powierzchowne omówienie kluczowych elementów może mieć wpływ na późniejsze poprawki albo konieczność ponownych konsultacji.

Kolejnym czynnikiem jest złożoność projektu, czyli to jak bardzo kod projektu jest skomplikowany i jak mocno chcemy ingerować w jego funkcjonalności. Zmiany dotyczące powierzchownych modyfikacji aplikacji są mniej kosztowne od modyfikacji ingerujących w fundamenty aplikacji. Tutaj znaczenie ma to jak aplikacja została zaprojektowana, czy ma dług techniczny, czy zadania które mamy zrealizować będzie wpływało na zachowania innych modułów aplikacji. Bez analizy trudno jest oszacować czas realizacji jakiegokolwiek zadania w kontekście złożoności aplikacji. Niektóre firmy IT stosują zwinne metodyki pracy, które w swoich założeniach posiadają mechanizmy wspierające estymację zadania. Omówmy krótko estymację w Scrumie. Rozpoczęcie pracy nad zadaniem zaczyna się od jego omówienia, a następnie wyceny w często abstrakcyjnych punktach, które opisują poziom trudności wykonania danego zadania, a tym samym czas jaki zajmie jego realizacja. Estymuje każdy programista w zespole. Podczas niezgodności co do wyceny punktowej dochodzi do konfrontacji opinii programistów o najbardziej skrajnych ocenach. Wtedy można usłyszeć uwagi i opinie dotyczące danego zadania, które w znaczący sposób mogą wpłynąć na czas jego realizacji. W metodyce tej panuje zasada, że w zespole każdy jest deweloperem na tym samym poziomie. Innymi słowy, jak kolega realizujący zadanie dla klienta X zachoruje, to zadania nie będzie opóźnione, ponieważ reszta zespołu może przejąć obowiązki chorego programisty. Tym samym muszę wspomnieć o transparentności w zespole. Element ten pozwala zespołowi być świadomym statusu każdego zadania jakie jest realizowane. Transparentność jest wspierana przez kolejny element Scruma – daily – czyli codzienne 15 minutowe spotkania zespołu, podczas, których w kilku słowach jest prezentowany status pracy każdego z programistów. Podsumowując, chociaż Scrum początkowo może okazać się opornym i ciężkim narzędziem, to w dłuższej perspektywie oferuje dokładniejszą analizę zadania oraz lepszą estymację. Zapewnia również wsparcie szeregu zasad i mechanizmów, aby zadanie zostało ukończone w ramach początkowej estymacji.

Ostatnim, elementem są pakiety usług dodatkowych, bez których zadanie może zostać z sukcesem zakończone, ale ich ignorowanie może w przyszłości odbić się czkawką. Do takich elementów można zaliczyć test aplikacji. Testy mogą znacznie wpłynąć na czas realizacji projektu, jednak korzyści które niosą w dłuższej perspektywie są znacznie wyższe od początkowych kosztów jakie generują. Aplikacja przetestowana to znaczy: aplikacja bezpieczna, aplikacja odporna na przyszłe błędy programistów (nie wiadomo kto w przyszłości będzie ją rozwijał), aplikacja dobrze udokumentowana, aplikacja łatwa do debuggowania, aplikacja otwarta na rozwój.

Elementy analizy Estymacja zadania z perspektywy programisty składać się powinna z kilku elementów. Niektóre z nich mogą być określane w czasie, inne jako procentowy udział w realizacji zadania. 1. Analiza zadania – bez tego estymację możemy określać z dokładnością od 1 do 50 godzin. Warto pamiętać o tym, że im więcej czasu poświęcimy na analizę, tym estymacja będzie być dokładniejsza. 2. Prace programistyczne – ten element powinien być szacowany jako konkretna ilość godzin. 3. Testy programisty – programista jest również testerem. Determinuje to, że powinien przetestować dokładnie swoją pracę i naprawić ewentualne niedoskonałości. Testy te stanowią procentowy udział od wielkości zadania. 4. Zakończone i przetestowane zdanie powinno trafić na Code Review. Często z innej perspektywy doskonale widać błędy, nietrzymanie się standardów programowania lub logiczne pułapki. Nikt nie ma lepszej perspektywy do wyłapywania takich błędów i nikt nie ma lepszych kompetencji do zwrócenia uwagi na popełnione błędy niż inni programiści siedzący obok :) Code review nie powinien być długi - z reguły nie powinien trwać dłużej niż 5-20 min. Jeżeli jest sporo plików do sprawdzenia to zadanie powinno być w miarę możliwości podzielone wcześniej na mniejsze części. 5. Po ukończeniu 4 pierwszych etapów demolkę zaczynają testerzy. Tutaj również zachodzi procentowy udział czasowy w zależności od wielkości zadania. Jednak wraz z niskim warsztatem programisty i wysokim warsztatem testera czas wykonania zadania może znacząco się wydłużyć. Do powyższych punktów należy dodać czas jaki planujemy poświęcić na komunikację z Project Managerem lub Product Ownerem. Oczywiście każda estymacja powinna zawierać bezpieczny margines błędu.

Podsumowując, estymacja projektu jest niezwykle trudnym zadaniem. Im więcej czasu zostanie poświęcone na analizę tym dokładniejszą estymację można stworzyć. W Mindcode staramy się podchodzi do estymacji w jak najbardziej pragmatyczny sposób. Dzięki doświadczeniu oraz zastosowaniu wewnętrznego narzędzia do estymacji zazwyczaj udaje się nam przedstawić klientowi realne terminy ukończenia projektów.