Stożek Niepewności

Stożek Niepewności, opisany przez Steve’a McConnela, pokazuje to, co wie każdy doświadczony profesjonalista oprogramowania. Na początku każdego projektu nie wiemy dokładnie, jak długo będzie on trwał.

Przyczyn tego jest wiele. Żadne dwa projekty nie mają:

  1. takich samych wymagań.
  2. takich samych ludzi.
  3. takiego samego kontekstu biznesowego.
  4. takiej samej technologii.
  5. takich samych priorytetów &ograniczeń.

Każdy jest unikalny. Każda linia kodu jest tworzona ręcznie. A praca nad wiedzą, w którą zaangażowani są inteligentni i kreatywni ludzie, nie wymaga precyzji tak, jak kopanie rowów.

Ale precyzja jest tym, o co się prosi. Sponsorzy chcą wiedzieć dokładnie, kiedy projekt zostanie ukończony i ile będzie kosztował.

Radzenie sobie z tym problemem jest prawie tak stare jak sam czas. Oto kilka sposobów, w jaki zespoły i firmy radzą sobie z tą niepewnością.

Radzenie sobie ze stożkiem

Podwyższ szacunki

Po odczuciu ukłucia niedoszacowania, jedną z powszechnych reakcji jest podwojenie lub potrojenie szacunków w następnej rundzie. To zdecydowanie obniża ryzyko początkowe, ale podbijanie liczb jest trudniejsze niż się wydaje.

Podanie zbyt dużej liczby spowoduje, że sponsorzy będą się wahać i nie zatwierdzą Twojego projektu. Podaj zbyt niską liczbę, a ryzykujesz, że zabraknie ci pieniędzy. To staje się podwójnie ryzykowne, kiedy licytujesz na kontraktach o stałej ofercie, gdzie jest jeszcze większa presja, aby utrzymać liczby na niskim poziomie.

Większość projektów dodaje jakiś rodzaj wypełnienia do ostatecznych liczb, aby dać sobie wystarczającą swobodę działania. Inną rzeczą, którą zespoły mogą zrobić, jest porównanie tego projektu z innymi.

Wybierz projekt względnie

Ludzie są naprawdę dobrzy w określaniu względnej wielkości rzeczy. Nie możemy powiedzieć dokładnie, jak duży jest kamień. Ale możemy powiedzieć, jak duży jest w porównaniu z czymś innym. Możemy to wykorzystać również podczas wymiarowania projektów.

Be upfront and honest

Domyślnym trybem działania Agile jest przejrzystość i widoczność. Nie powinno więc dziwić, że sposobem Agile na radzenie sobie ze stożkiem jest bycie otwartym i szczerym.

Patrz. Nie wiemy, jak długo to potrwa. To jest nasze najlepsze przypuszczenie. Ale jeśli dasz nam kilka iteracji, możemy coś zbudować, zmierzyć, jak długo to potrwa, a następnie powiedzieć ci o wiele lepsze poczucie, jak duża jest ta rzecz.

Innym podejściem, które niektóre zespoły Agile podejmą, aby pomóc w komunikowaniu niepewności, jest przedstawienie szacunków jako zakresu.

Ma to tę zaletę, że w widoczny sposób pokazuje sponsorom niepewność związaną z projektem, a następnie pozwala im zdecydować, na jak duże ryzyko mogą sobie pozwolić.

Fundowanie przyrostowe

Innym podejściem, które ma wiele sensu, ale niestety nie widzę, aby było stosowane wystarczająco często, jest finansowanie przyrostowe.

Przy finansowaniu przyrostowym nie prosisz o cały worek pieniędzy z góry. Tylko tyle, żeby przepchnąć się przez wystarczającą ilość pracy, żeby zgłosić z powrotem lepszy numer na to, jak długo to potrwa.

To nie jest niezawodne. Wciąż możesz wpaść w kłopoty później. Ale dając zespołom $30-50K, pozwalając im coś zbudować i widząc, jak długo to trwa, można przejść długą drogę do zmniejszenia wariancji w tej liczbie z góry.

Możesz przeczytać więcej o tym sposobie planowania i korzyściach, jakie przynosi w Beyond Budgeting Jeremy’ego Hope.

The Root Cause

Żyjemy w świecie rocznych budżetów. I niestety to napędza wiele napięć i dramatów w naszym miejscu pracy. Pod pewnymi względami roczne budżety są naturalne (żyjemy i śledzimy czas w cyklach rocznych), ale pod innymi są one okropne dla planowania, ponieważ rok to długi okres na rynku.

Jeśli znajdziesz się potknięty przez stożek niepewności, po prostu pamiętaj, że cały punkt szacowania oprogramowania polega na określeniu, czy projekt jest w ogóle możliwy.

Albo jak mówi Steve McConnell:

Podstawowym celem estymacji oprogramowania nie jest przewidywanie wyniku projektu; jest nim określenie, czy cele projektu są wystarczająco realistyczne, aby umożliwić sterowanie projektem w celu ich spełnienia.

-Steve McConnell, Software Estimation: Demystifying the Black Art

.

Dodaj komentarz