Estymowanie czasochłonności prac w projektach IT

Na kiedy to będzie i dlaczego tak późno? Takie pytanie znają ludzie z IT aż za dobrze. Jak znaleźć odpowiedź? Z tego artykułu dowiesz się, jakie są tradycyjne, sprawdzone techniki estymacji (niektóre mają ponad 40 lat!), oraz co na ten temat przyniesie przyszłość.

Techniki estymacji w bazujące na danych historycznych

Podejście bazujące na danych z przeszłości jest bardzo dokładne, ale tylko pod pewnymi warunkami. Jeżeli realizujesz powtarzające się projekty i zadania, to warto skorzystać z tej techniki. Skoro w ostatnich kilku projektach zespół dostarczył typowego CRUD-a w 2 dni, to prawdopodobnie ten czas realizacji powtórzy się w kolejnych, podobnych zadaniach.

Żeby zacząć, potrzebujesz wiarygodnych danych. Najlepiej z więcej niż jednego projektu. Do tego projekt, który wyceniasz, musi być podobny do poprzednich pod względem:

• Zakresu do zrealizowania,
• Technologii,
• Złożoności dziedziny,
• Umiejętności zespołu.

Jeżeli któryś z tych parametrów się zasadniczo różni, to dane historyczne nie będą pomocne i mogą doprowadzić do sporych błędów w oszacowaniach.

Szacowanie w oparciu o poprzednie projekty możesz przeprowadzić na różnym poziomie szczegółowości. Na przykład:

• Oceniasz, że nowy projekt stanowi mniej-więcej połowę poprzedniego. Szacujesz więc jego czas trwania i budżet na 50% tego, co było poprzednio.
• Analizujesz szczegółowo dane historyczne, z których wynika, że zbudowanie jednego ekranu wyświetlającego dane zajmuje X czasu, jeden raport to Y godzin itd. Mając takie dane, wystarczy, że oszacujesz liczbę podobnych elementów w nowym systemie i wykonasz proste mnożenie. Wynik będzie dużo dokładniejszy niż przy poprzednim podejściu.

Techniki wykorzystujące algorytmy

Jeżeli brakuje danych historycznych, to rozwiązaniem może być podejście wykorzystujące sprawdzone algorytmy. I to sprawdzone przez lata, bo jedna z takich technik - punkty funkcyjne (Functional Points) została opracowana już w roku 1979 przez Allana Albrecha[1].

Szacowanie z wykorzystaniem punktów funkcyjnych

Określanie złożoności projektu z na podstawie punktów funkcyjnych wymaga przeprowadzenie kilkuetapowych obliczeń.

W pierwszej kolejności specjalista szacuje liczbę elementów systemu przyporządkowanych do pięciu kategorii, do których należą: zewnętrzne wejścia i wyjścia, interfejsy, zewnętrzne zapytania i wewnętrzne typy plików.

Następnie dla każdego elementu określa złożoność - niską, średnią lub wysoką, po czym przypisuje wartość punktową wynikającą z kategorii elementu i jego złożoności (według predefiniowanych tabel).

Kolejnym krokiem jest oszacowanie wpływu czternastu czynników projektowych, których wartość jest określana od 0 (brak wpływu) do 5 (krytyczny wpływ). Sumę tak zebranych punktów podstawia się do odpowiednich wzorów, aby uzyskać końcowy wynik.

AFP, czyli Adjusted Function Points to końcowa wartość złożoności projektu uwzględniająca zarówno jego spodziewaną techniczną implementację, jak i czynniki ogólno-projektowe jak na przykład łatwość instalacji czy intensywność wykonywanych operacji w ramach systemu.

Szczegóły wyliczania wartości punktów funkcyjnych znajdziesz na przykład w badaniu: “Function Point Based Estimation of Effort and Cost in Agile Software Development.”[2] lub w tym artykule[14].

Z wartości AFP nie wynikają wprost godziny pracy czy złotówki potrzebne na sfinansowanie projektu. Konieczne jest określenie przelicznika, który jest inny dla różnych technologii czy metodyk pracy. Taki przelicznik może powstać w oparciu o poprzednio realizowane projekty. Możesz również wykorzystać wartości dostępne publicznie, bazujące na projektach z różnych branż i firm.

Na przykład w artykule: “What Is the Cost of One IFPUG Method Function Point? – Case Study”[13] znajdziesz informację, że jeden punkt funkcyjny to 128 linii kodu w C, ale tylko 53 linie w Javie.

Wyliczanie punktów funkcyjnych opisuje też szczegółowo standard ISO/IEC 20926:2009 przygotowany przez organizację IFPUG[15].

Szacowanie czasu i kosztów z wykorzystaniem COCOMO II

Model COCOMO powstał w roku 1981. Jego najnowsza wersja - COCOMO II powstała w oparciu o dane ze 161 projektów[3].

Standardowym punktem wejścia do estymacji przy pomocy COCOMO II są spodziewane pojedyncze linie kodu, ale można też stosować opisane wyżej punkty funkcyjne (FP).

Szacując liczbę linii kodu, należy[4]:

1. Uwzględniać tylko kod związany z budowanym produktem. Narzędzia testujące czy wspierające w jakiś inny sposób nie są uwzględniane.
2. Liczyć tylko kod pisany przez zespół pracujący nad projektem. Kod generowany przez narzędzia nie jest brany pod uwagę.
3. Pomijać komentarze.

Następnym krokiem w wycenie wg COCOMO II jest zdefiniowanie poziomów dla czynników określających skalę projektu, takich jak:

1. Doświadczenie w budowaniu podobnych rozwiązań (Precedentedness).
2. Elastyczność, czyli na ile sztywno zostały zdefiniowane wymagania i efekt końcowy (Development Flexibility).
3. Ryzyko związane z architekturą, czyli na ile przeanalizowano zastosowane rozwiązanie techniczne (Architecture / Risk Resolution).
4. Spójność zespołu - na ile zespół jest zgrany i skutecznie zarządzany (Team Cohesion).
5. Dojrzałość procesu (Process Maturity).

W kolejnym kroku należy określić wartość każdego z siedemnastu czynników wpływających na koszty projektu. Dotyczą one:

1. Zespołu (doświadczenie, umiejętności analityczne, umiejętności programistyczne itp.)
2. Produktu (złożoność, oczekiwana niezawodność, dokumentacja do przygotowania itp.)
3. Środowiska (ograniczenia przestrzeni dyskowej, czasów odpowiedzi itp.)
4. Projektu (np. używania odpowiednich narzędzi).

Podstawiając te wartości do odpowiednich wzorów, otrzymujesz na końcu czas trwania projektu oraz pracę, jaką należy wykonać (czyli liczbę godzin, co przekłada się na koszt projektu).

Dokładne wartości i wzory byłyby niemożliwe do opisania w krótkim artykule. Jeżeli chcesz poznać sposób szacowania z wykorzystaniem COCOMO II to:

• Poszukaj w Internecie opracowań “COCOMO II Model Definition Manual”4 (około 100 stron opisu).
• Skorzystaj z gotowych kalkulatorów, które po podstawieniu danych wykonają obliczenia za Ciebie (na przykład http://softwarecost.org/tools/COCOMO/).

Inne metody wykorzystujące algorytmy

Inne techniki wykorzystujące algorytmy do szacowania czasochłonności projektu, to:

• Puntam Model[5],
• Object Points[6],
• Use Case Points[7].

Techniki estymacji wykorzystujące wiedzę ekspercką

Kolejną grupę technik estymacji, stanowią oszacowania eksperckie. W tej sytuacji specjalista lub grupa specjalistów ocenia, jak długo potrwają prace i jak duży zespół będzie potrzebny do ich zrealizowania.

Można wyróżnić kilka podejść do takich estymacji.

Szacowanie przez eksperta

W tym przypadku pojedynczy ekspert zapoznaje się z wymaganiami i ograniczeniami projektu, po czym na podstawie swojego doświadczenia określa szacowany czas trwania i koszt projektu.

Poprawność tych estymacji zależy więc bardzo mocno od doświadczenia osoby przygotowującej wyliczenia. Szacunki są też podatne na zwykłe ludzkie pomyłki.

Co jeszcze istotne, efektywność pracy eksperta jest całkowicie różna od początkującego programisty. Dlatego do tak przygotowanych obliczeń należy wprowadzić korekty na podstawie średnich prędkości pracy zespołu.

Metoda delficka

Początki tej techniki sięgają lat 50. poprzedniego stulecia, kiedy to zauważono, że oceny opracowywane przez pojedynczego eksperta są często błędne. Zaczęto więc zapraszać do wspólnego estymowania grupy eksperckie. Istotnym elementem metody delfickiej jest anonimowość głosowania, tak aby wyniki podane przez menedżerów wysokiego szczebla czy osoby o wysokim autorytecie nie wpływały na resztę grupy.

Przed głosowaniem wszyscy zapoznają się z tematem przedstawionym na przykład w formie dokumentacji wymagań. Następnie przeprowadzane jest anonimowe głosowanie. Po jego zakończeniu każdy uczestnik otrzymuje informację o pozostałych wynikach, ale bez informacji kto jest autorem której oceny.

Jeżeli wyniki są takie zbliżone w całej grupie, to można przejść do kolejnego zagadnienia. W przypadku większych rozbieżności następuje dyskusja na dany temat. Następnie moderator przeprowadza kolejną rundę głosowania. Proces powtarzany jest tak długo, aż nie zostanie uzyskana zgodność co do wartości oszacowania.

Plannig poker

Tradycyjna metoda delficka była czasochłonna i wymagała intensywnego zaangażowania moderatora. James Grenning opracował w 2002 roku technikę planning pokera[8] na potrzeby szacowania czasochłonności projektów IT. Coś, co jest często standardowym narzędziem współczesnych zespołów.

W procesie tym powinien brać udział cały zespół zaangażowany w projekt. Głosowanie odbywa się przy pomocy kart. Mogą to być specjalne karty do plannig pokera, tradycyjne karty do gry lub dedykowane narzędzia wirtualne. Jedna osoba przedstawia temat, który będzie estymowany. Następnie każdy z graczy przypisuje ocenę do danego zagadnienia, ale nie ujawnia jej pozostałym graczom. Dopiero kiedy wszyscy są gotowi, wtedy następuje porównanie wyników.

Jeżeli wyniki są zbieżne, to ustalany jest końcowy wynik. Zwykle, jako wartość najpopularniejsza (aby uniknąć ułamków). W przypadku istotnej rozbieżności w pierwszej kolejności swoje argumenty przedstawiają osoby, które przyznały najwyższą i najniższą ocenę. Po zakończeniu dyskusji uczestnicy mogą zmienić ocenę lub powtórzyć cały proces głosowania. Jeżeli uzyskano zgodność wyników, to analizowane jest kolejne zadanie.

Zasadniczą zaletą takiego podejścia jest zebranie informacji od szerokiej grupy osób. Dzięki temu eliminowane są indywidualne pomyłki, a średnia wartość szacunków jest często zbliżona do rzeczywistej. Według jednego z badań przeciętny błąd oszacowania przy wykorzystaniu planning pokera był dwa razy mniejszy, niż gdy oceny dokonywał pojedynczy ekspert (7,1% względem 14,8%).

Szacowanie relatywne

Techniki takie jak COCOMO II podają szacunki w godzinach i dniach pracy. Korzystając z planning pokera możesz oszacować zarówno czasochłonność w godzinach/dniach, jak i relatywne zależności między zadaniami. To drugie podejście jest dużo bardziej powszechne.

W szacowaniu relatywnym określane są wyłącznie relacje pomiędzy poszczególnymi zadaniami. Czyli zespół wykorzystujący na przykład technikę planning pokera określa, że zadanie 1 jest dwa razy bardziej złożone od zadania 2, a zadanie 3 jest pięć razy bardziej złożone od zadania 1 itd.

Relacje można zapisać w punktach (tzw. Story Points) lub korzystając z popularnych rozmiarów koszulek (T-Shirt size), czyli: S, M, L, XL itd. Żeby następnie uzyskać czas trwania zadań, należy:

• Dla estymacji w Story Points określić prędkość zespołu w dostarczaniu Story Points per sprint. Możesz to zrobić, na przykład planując dokładnie pierwszy sprint, a na koniec podliczając ile Story Point „weszło" do tak zaplanowanego sprintu.
• Dla estymacji w T-Shirt size zespół powinien określić ile czasu średnio zajmie dostarczenie jednej S-ki, M-ki itd. Następnie z przemnożenia i zsumowania wyjdzie całkowity spodziewany czas trwania projektu.

Co ważne, estymacje relatywne przed przeliczeniem ich na jednostki czasu są niezależne od zespołu i technologii. Relacja złożoności zadań jest faktem, a nie oceną. Dlatego to rozwiązanie sprawdza się dobrze, jeżeli ostateczny kształt zespołu nie jest znany, lub często się zmienia.

Szacowanie z wykorzystaniem uczenia maszynowego

Przetwarzanie naturalnego języka przez mechanizmy uczenia maszynowego jest wykorzystywane do wielu celów. W tym także do estymowania czasochłonności. W opracowaniu przygotowanym przez badaczy z Australii i Stanów Zjednoczonych przedstawione zostały efekty zastosowania różnych algorytmów uczenia maszynowego do przygotowania relatywnych estymacji w szesnastu projektach[10]. Dla trzech projektów średni błąd oszacowania wynosił poniżej jedności (0,64; 0,68; 0,74). To znaczy, że oszacowanie przygotowane przez automat różniło się średnio nie więcej niż 1 SP względem oszacowań przygotowanych przez człowieka.

Uzyskany wynik jest naprawdę obiecujący, gdyż estymacje relatywne z definicji charakteryzują się pewnym błędem. I nawet ten sam zespół szacujący liczbę Story Pointów po kilku miesiącach uzyskałby większy od zera błąd pomiaru.

W Internecie znajdziesz wiele opracowań na temat zastosowania uczenia maszynowego do szacowania czasochłonności projektów informatycznych. Lista różnych technik i artykułów na ich temat jest na przykład w pracy “Software Effort Estimation Accuracy Prediction of Machine Learning Techniques: A Systematic Performance Evaluation”[11].

W naszym kraju wiele prac na temat szacowania czasochłonności projektów informatycznych przy użyciu uczenia maszynowego opublikował dr Przemysław Pospieszny, jak choćby w tym opracowaniu już z roku 2015: “Zastosowanie technik eksploracji danych do estymacji pracochłonności projektów informatycznych”[12].

Niewątpliwie przyszłość w obszarze estymacji projektowych będzie należała do narzędzi, które na podstawie ogromnych zbiorów danych w połączeniu ze wsparciem eksperckim będą w stanie przewidywać termin zakończenia i budżet projektów z dużą dokładnością.

Podsumowanie różnych technik szacowania czasochłonności projektu

Jeżeli posiadasz dane historyczne z poprzednich projektów i Twoje środowisko jest dość stabilne (podobne projekty, mała rotacja w zespole), to najlepszym wyjściem będzie estymowanie na podstawie informacji z poprzednich projektów. Możesz to robić mniej lub bardziej formalnie. A jeżeli wykorzystasz do tego narzędzia wykorzystujące Machine Learning, to wyceny będą bardzo precyzyjne.

Gdy brakuje danych z przeszłości, a konieczne jest opracowanie dokładnej wyceny, to z pomocą mogą przyjść techniki bazujące na algorytmach, jak COCOMO II. Jako miarę złożoności możesz zastosować punkty funkcyjne lub szacowaną liczbę linii kodu. Przygotowanie takich estymacji zajmuje sporo czasu i jest mało odporne na zmiany. Czyli po większych zmianach zakresu należy powtórzyć obliczenia.

W sytuacji, gdy potrzebujesz zgrubnej oceny i spodziewasz się w trakcie projektu wielu zmian, wtedy dobrze sprawdzą się estymacje relatywne. Narzędziem, które pomoże Ci w szybkim i precyzyjnym zebraniu tych wycen jest planning poker.

Źródła:

1. ttps://en.wikipedia.org/wiki/Function_point
2. “Function Point Based Estimation of Effort and Cost in Agile Software Development.”, Anupam Yadava, Ashish Sharma.
3. https://en.wikipedia.org/wiki/COCOMO
4. COCOMO II Model Definition Manual, Version 2.1
5. [https://en.wikipedia.org/wiki/Putnam_model]
6. [https://en.wikipedia.org/wiki/Object_point]
7. [https://en.wikipedia.org/wiki/Use_case_points]
8. [https://en.wikipedia.org/wiki/Planning_poker]
9. “A Review on Software Cost and Effort Estimation Techniques for Agile Development Process”, Manju Vyas et al. International Journal of Recent Research Aspects ISSN: 2349-7688, Vol. 5, Issue 1, March 2018.
10. “A deep learning model for estimating story points”, Morakot Choetkiertikul, Hoa Khanh Dam, Truyen Tran, Trang Pham, Aditya Ghose, Tim Menzies.
11. “Software Effort Estimation Accuracy Prediction of Machine Learning Techniques: A Systematic Performance Evaluation”, Yasir Mahmood, Nazri Kamaa, Azri Azmia, Ahmad Salman Khanb, Mazlan Alic.
12. “Zastosowanie technik eksploracji danych do estymacji pracochłonności projektów informatycznych”, Andrzej Kobyliński, Przemysław Pospieszny.
13. “What Is the Cost of One IFPUG Method Function Point? – Case Study”, Beata Czarnacka-Chrobot
14. https://projectmakers.pl/jak-obliczyc-zlozonosc-projektu-punkty-funkcyjne-w-praktyce/
15. https://ifpug.org/