Większość z Nas szczególnie, ta mniej doświadczona zwykle bardzo nie lubi dokonywać oszacowania. Nic dziwnego skoro często zadania to przypomina chodzenie po omacku.  Dlatego postaram się tutaj jak najszerzej omówić dostępne metody i narzędzia.

Zacznę od kwestii o których powinniśmy pamiętać wykonując wszelkie oszacowania, później przejdę do sposobów na szacowanie całych projektów, w części trzeciej opiszę metody szacowania czasu trwania poszczególnych zadań, a na koniec wspomnę trochę o dostępnych narzędziach.

Zaczynamy – czyli jak zabierać się do szacowania czasu?

Oszacowanie czasu trwania całego projektu, to zadanie naprawdę trudne. Szczególnie na początku projektu w fazie przygotowawczej, kiedy tak na prawdę nie do końca wiemy jeszcze co trzeba w projekcie zrobić. Ale za nim powiem, jak można sobie pomóc, to ustalmy z czego powinno się składać takie formalne oszacowanie.

1. Założenia

Każde oszacowanie projektu powinno mieć pokrótce opisane założenia, dla których zostało dokonane. Czyli jakie rzeczy zostały uwzględnione, a co nawet ważniejsze, czego ewentualnie nie uwzględniono. Jakie było zakładane rozwiązanie i jakie zaplanowano zasoby. Generalnie wszystkie czynniki, które mogą znacząco wpłynąć na czas trwania projektu.

2.  Odchylenie , czyli dokładność oszacowania.

Powinniśmy sobie zdawać sprawę w jakim stopniu dokładny jest prognozowany czas. Czasem mamy naprawdę dużą pewność (np. robiliśmy już podobne projekty) i możemy sobie założyć, że oszacowanie może mieć odchylenie rzędu 10 – 20%.  Czasem jednak trafiamy do dzikiej nieznanej krainy i nasze szacunki mogą być naprawdę bardzo orientacyjne. W takim przypadku odchylenie, może sięgać do np. 100% czasu trwania. Jeśli chodzi o wyznaczanie wielkości odchylenia to osobiście przyjmuje pięciostopniową skalę (jak w większości ciężko mierzalnych metryk, taka ilość daje sporą elastyczność, a nie powoduje jeszcze bałaganu).

• Bardzo Niskie 0 – 10%
• Niskie  10 – 20%
• Średnie 20-40%
• Wysokie 40 – 70%
• Bardzo Wysokie 70%+

Warto zwrócić uwagę, że w tym przypadku im większy poziom odchylenia, tym szerszy jego przedział.

3.  Czas ważności Oszacowania

Zaleca się też, choć wszystko zależy od przeznaczenia oszacowania, aby określić jego czas ważności. Tzn na przykład, że oszacowanie aktualne jest do końca Marca. (bo wtedy będziemy mieli więcej szczegółów) Zabezpiecza Nas to na wypadek, gdyby ktoś później wyciągał nam takie archiwalne oszacowanie i dochodził jego wyegzekwowania.

Osobiście, niestety raczej rzadko zdarza mi się określać czas ważności oszacowania. Wykonywane oszacowania zwykle są po prostu aktualizowane w ramach napływających danych, czy wykonywania prac, występowania problemów itd.

4. Nakład pracy, a czas trwania

Bardzo ważna rzecz, której trzeba mieć świadomość, jak również zaznaczyć w opisie oszacowania. Pojęcia ‘nakładu pracy’ i ‘czasu trwania’ są często stosowane zamiennie, co jest wielkim nieporozumieniem i trzeba je twardo rozgraniczyć.

Nakład pracy, opisuje szacunek ile godzin roboczych należy poświęcić na zrealizowanie projektu/zadania. Zaś Czas trwania, musi do nakładu pracy doliczyć takie kwestie jak dostępność zasobów, dni wolne, realizację innych projektów i zobowiązań itp.

Koniecznie należy zaznaczyć w oszacowaniu, którą z tych wartości prognozujemy. Inaczej nieraz spotkałem się z nieporozumieniami. Programista mówi, że wykonanie jakieś funkcjonalności to 3 dni roboty, a klient rozumie,  że za 3 dni otrzyma gotowe rozwiązanie.

Podsumowanie

Stosowanie wszystkich tutaj wymienionych elementów oczywiście nie jest konieczne. Ale często zabezpiecza nad przed mogącymi wystąpić problemami. W kolejnej części opiszę zasady szacowania całych projektów, a później przejdę do szacowania zadań.

Co to są User Stories?

User stories to sposób opisu wymagań projektowanej aplikacji. Opisujący krótko pojedynczą funkcjonalność lub zestaw funkcjonalności, który bez siebie nawzajem nie miałby sensu. Np:

Użytkownik może wysłać powiadomienie email o nowo stworzonym spotkaniu.

Project Manager może przydzielić zadanie do wybranego pracownika lub ich grupy.

Koniecznie należy zwrócić uwagę, że każde zdanie historii użytkownika zaczyna się od osoby której tyczy się ta historia. Osoby te nazywamy ‘Rolami’ i są one w zasadzie analogiczne do aktorów w przypadkach użycia (Use Cases).

Zwyczajowo User Stories zapisywane były na małych karteczkach, jak widać na pierwszej ilustracji tego posta. Dzięki temu zapewniona była ich zwięzła forma, a także łatwość zarządzania, poprzez możliwość dowolnego układania. Dziś popularnym w wielu firmach narzędziem pozostaje po prostu arkusz kalkulacyjny.

Zalety User Stories

1. 1.Największą zaletą przynajmniej z mojego punktu widzenia jest fakt, że dzięki User Stories patrzymy na projektowaną aplikację z punktu widzenia przyszłego użytkownika. Co bardzo często chroni nas przed absurdalnymi błędami, a z całą pewności pozwala dostarczyć wygodny i funkcjonalny produkt.
2. 2.Kolejną zaletą jest na pewno zwięzła forma dzięki której zebranie takich wymagań nie zabiera wiele czasu, ale mimo wszystko dają one bardzo dobry pogląd na wygląd przyszłego systemu.
3. 3.Z punktu widzenia metodyki Scrum, user stories pozwalają na bezpośrednie wpisywanie ich z Zaległości Produktowe (Backlog).

Więcej o User Stories:

• http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements
• http://www.agilers.com/teamblog/zwinne-dzialania-zaczepne/