w ramach naszej serii szacowania oprogramowania zbadaliśmy znaczenie zarządzania oczekiwaniami w ramach każdego projektu programistycznego. W tym artykule skupimy się na stożku niepewności, potężnym narzędziu do ograniczania ryzyka związanego z procesem ustalania zakresu i szacowania. W swej istocie jest to obraz niepewności co do czasu potrzebnego do ukończenia projektu, w oparciu o ilość wiedzy (lub jej brak) na początku projektu. Ostatecznie odpowiada to za ryzyko wybuchu projektu z powodu niewiadomych, a także faktu, że im dalej w przyszłość próbujesz oszacować, tym bardziej prawdopodobne jest, że się mylisz. Jest to interesujący paradoks, w którym chcemy dokładnie przewidzieć przyszłość, jednak nie możemy być naprawdę dokładni, ponieważ jest to tylko oszacowanie.

w przypadku, gdy jeszcze tego nie zrobiłeś, polecam zapoznanie się z poprzednim eksperymentem, który przeprowadziliśmy tutaj w Codebots, aby dowiedzieć się, w jaki sposób możemy najlepiej zarządzać ryzykiem w oprogramowaniu. Motywacją do tego ćwiczenia był częsty nadoptymizm naszych zespołów programistycznych, jeśli chodzi o przeprowadzanie szacunków.

wyposażywszy się w najlepszą procedurę zaproponowania eksperymentu, zidentyfikowaliśmy problem w naszych stałych szacunkach zakresu. Każdy cytat zawierał minimum 80% zmian w wykonanej pracy, bez względu na długość projektu. Ponieważ nie zastosowaliśmy stożka niepewności, nasza zdolność do dostarczania naszym klientom realistycznych oszacowań i zarządzania ich oczekiwaniami była znacznie utrudniona.

Krok 1: Zrozum problem

jak wspomniano powyżej, napotkaliśmy problem w naszych szacunkach, występujący, gdy zapewniamy stałą cenę zakresu na etapie wyceny. (Stały zakres oznacza spełnienie dokładnych wymagań, ale przez elastyczny czas). Bez względu na długość projektu, zawsze szliśmy z powodu dużej różnorodności.

przyczyna-nie mieliśmy stożka niepewności. Nie wzięliśmy pod uwagę faktu, że im dalej w przyszłość próbujesz przewidzieć, tym większy wzrost wariancji w czasie. Wynika to z obecności szeregu konkretnych zagrożeń, z których najpoważniejsze to niedokładne szacunki, zmiany zakresu i zaangażowanie użytkowników końcowych. Ponieważ wszystko oszacowano na początku, nie było możliwości zmiany szacunków w celu uwzględnienia tych odkrytych zagrożeń. Zamiast tego, wpływ tych zagrożeń są spotęgowane przez cały okres trwania projektu, co oznacza, że im dłuższy projekt, tym więcej starasz się przewidzieć, tym bardziej prawdopodobne jest, że się mylisz.

Krok 2: Opracowanie hipotezy

Po przetrawieniu problemu, następnie pracowaliśmy nad opracowaniem hipotezy, aby sprawdzić, w jaki sposób stożek niepewności może być dokładnie zastosowany do naszych stałych szacunków zakresu.

na tej podstawie postawiono hipotezę, że można użyć Wzoru do obliczenia wielkości stożka niepewności, biorąc pod uwagę długość projektu.

Krok 3: Zaplanuj eksperyment

wyposażeni w naszą hipotezę, przystąpiliśmy do zaplanowania eksperymentu, aby przetestować naszą propozycję stożka niepewności. Aby to zrobić, wygenerowaliśmy funkcję kwadratową symulującą nasz stożek, z parametrem reprezentującym liczbę przewidywanych tygodni rozwoju. Następnie możemy zastosować ten mnożnik do naszych szacunków, aby uwzględnić wariancję czasu, w oparciu o to, jak daleko w przyszłość staraliśmy się przewidzieć.

Jeśli zastosujemy to do danych szacunkowych z poprzednich projektów, możemy wtedy określić, czy stała cena zakresu ze zmiennością byłaby dokładniejsza.

Krok 4: Zbieraj dane

zebraliśmy dane z różnych projektów, w tym informacje o czasie przydzielonym i zajętym, historie zakończone, czas do zakończenia, w tym dodatkowe uwagi na temat projektu i napotkanych zagrożeń.

biorąc estymacje, obliczyliśmy hipotetyczną stałą wartość zakresu dla każdego projektu, używając stożka niepewności. Korzystając z tych informacji, byliśmy w stanie zbadać, czy czas, który rzeczywiście zabraliśmy na opracowanie, kończąc zarówno wstępną pracę, jak i dodatkowe zmiany, był porównywalny z nowymi wartościami estymacji generowanymi za pomocą stożka niepewności. Okazuje się, że poprawione oszacowanie i faktycznie wzięty czas były bardzo podobne!

Krok 5: Podejmij decyzję

w końcu dane wykazały, że gdybyśmy zastosowali Stożek niepewności do ustalonego zakresu, używając wzoru, który uwzględnia długość projektu, skończylibyśmy z oszacowaniem, które uwzględniałoby wariancję, która występuje w trakcie rozwoju projektu.

ostatecznie zalecamy, aby zamiast próbować oszacować cały projekt, zespół programistów skupił się tylko na i szacuje niewielką ilość pracy. Pomoże to zmniejszyć wpływ niewiadomych, a tym samym Rozmiar stożka niepewności. Oznacza to również, że gdy zespół pracuje nad projektem, dowiaduje się o nim więcej, a jeśli chodzi o szacowanie kolejnego kawałka pracy, może zmniejszyć niepewność i dokonać dokładniejszych szacunków.