Korzystanie z arkuszy kalkulacyjnych Agile do szacowania wykrywania

Ten artykuł zawiera wstępnie sformatowany arkusz kalkulacyjny, który pomoże Ci w opracowaniu szacunków odnajdywania Agile. Zawiera również informacje, które pomogą Ci śledzić wraz z opisywanym przykładem. Możesz utworzyć edytowalną kopię (Plik>Utwórz kopię lub Plik>Pobierz) z szablonu tutaj.

Klienci często proszą mnie o przedstawienie szacunków Agile, zanim stworzę zespół lub poznam wymagania MVP. Na tym wczesnym etapie nie mam dostępu do tradycyjnych wskaźników, takich jak prędkość, liczba sprintów lub koszt zespołu, aby obliczyć te szacunki. Ale klienci chcą odpowiedzi. Czy mogą wprowadzić hipotetyczny produkt za dwa lub sześć miesięcy? Czy będzie to wykonalne przy ich (zwykle niskim) budżecie?

Wejdź do arkusza kalkulacyjnego Agile.

Arkusze kalkulacyjne to odpowiedni – ale często pomijany – wybór dla podejścia Agile. Są to proste, zaawansowane technologicznie narzędzia, które zachęcają do współpracy. To powiedziawszy, Twojego klienta prawdopodobnie nie obchodzi, czy Twoje narzędzia są „zatwierdzone Agile”, o ile cena i jakość produktu spełniają jego wymagania. Prawdziwa wartość arkuszy kalkulacyjnych polega na ich dostępności dla kierowników projektów i interesariuszy na wszystkich poziomach doświadczenia.

Wiele specjalistycznych narzędzi do zarządzania projektami ma krzywe uczenia się, które są zbyt strome dla niedoświadczonych użytkowników w szybko zmieniających się projektach. Im łatwiej więc klientom, właścicielom produktów i programistom aktualizować wymagania i koszty pracy, tym szybciej otrzymasz realistyczne oszacowanie. Dzięki wstępnie sformatowanemu arkuszowi kalkulacyjnemu kierownicy projektów mogą dostosowywać wartości i parametry, aby zademonstrować skutki każdego zmiennego zasobu lub przesuwającej się osi czasu.

Arkusze kalkulacyjne to także świetny sposób na dzielenie się wiedzą z kolegami. Arkusz kalkulacyjny, którego używam, pochodzi od kolegi z Toptal i od tego czasu wykonałem kopię i zmodyfikowałem ją do swoich potrzeb. Zachęcam do tego również.

W tym artykule pokazuję, jak zapewnić pomyślne oszacowania odkryć, które umożliwiają klientom i interesariuszom dostosowanie się do celów projektu i kontynuowanie rozwoju. Oto, jak wypełnić puste pola i przedstawić oszacowanie na wczesnym etapie, za którym możesz się oprzeć.

Najpierw zajmij się wizją produktu i planem działania

Załóżmy, że Twój klient chce stworzyć serwis randkowy przy ustalonym budżecie, ale szczegóły produktu są niejasne. Bez znajomości kosztów i szybkości pracy zespołu najlepszym punktem wyjścia jest wizja produktu, ponieważ wymaga od interesariuszy uzgodnienia celu projektowego i promuje przejrzystość w całym zespole.

Podoba mi się format wizji produktu Scrum.org ze względu na jego intuicyjny styl narracyjny. Oto jak to wygląda:

Po ustaleniu wizji produktu możesz dodać Mapę drogową produktu w nowej karcie arkusza kalkulacyjnego, aby dać klientowi poczucie długoterminowego harmonogramu projektu. Mapa drogowa powinna zawierać listę celów, kluczowych funkcji i terminów dla każdej wersji mapy drogowej produktu.

Wersje mapy drogowej to planowane edycje produktu przeznaczone dla konsumentów lub klientów, które wyznaczają jego trajektorię rynkową. Pierwsza wersja mapy drogowej to produkt, który możesz zadebiutować na rynku. Kolejne wersje map drogowych reprezentują wydania rynkowe z atrakcyjnymi nowymi funkcjami, które są zgodne z wizją produktu.

Aby użyć Microsoftu jako przykładu: Windows 8 był prawdopodobnie wersją mapy drogowej. Windows 10 był kolejną wersją mapy drogowej, która zawierała wiele nowych i pożądanych funkcji.

Gdy wizja produktu i mapa drogowa są gotowe, nadszedł czas, aby poprosić klienta o zaangażowanie się w MVP.

Negocjuj funkcje MVP za pomocą tabeli z trzema ograniczeniami

To jest moment na kształtowanie oczekiwań klienta w zakresie czasu i kosztów za pomocą wykresu Potrójnych Ograniczeń:

W podejściu kaskadowym stałe funkcje dyktują czas i koszty, a rozwój przebiega zgodnie ze szczegółowym planem projektu. I odwrotnie, stałe koszty i harmonogram Agile określają cechy produktu, a te cechy są stale zmieniane priorytetowo w oparciu o bardziej elastyczną wizję projektu.

Wykres potrójnego ograniczenia pokazuje klientowi, że uwzględnienie wszystkich pożądanych funkcji w pierwszym wydaniu zwiększy czas opracowywania i koszty balonu. Zamiast tego współpracuj z klientem, aby wybrać tylko „niezbędne” funkcje dla MVP i przedstaw wszystkie pozostałe funkcje dla przyszłych wydań.

Arkusze kalkulacyjne ułatwiają grupowanie i ponowne przypisywanie funkcji do różnych wersji, wydań i priorytetów w oparciu o zmieniające się potrzeby klienta, a także natychmiast wyświetlają koszty tych zmian.

Podczas identyfikowania funkcji MVP poproś ekspertów z danej dziedziny (MŚP) o pomoc w wymienieniu etapów projektu na podstawie podobnych projektów, nad którymi pracowali. Użyjesz tych kroków do późniejszego tworzenia eposów. Po przygotowaniu tych danych wejściowych możesz rozpocząć tworzenie oszacowania.

Zacznij od rozmiaru koszulki

Aby rozpocząć pierwsze zaległości, poproś właściciela produktu o szczegółowy opis funkcji produktu, a następnie przypisz rozmiar koszulki do każdej funkcji w oparciu o jej poziom trudności.

Rozmiary koszulek pokażą względną złożoność i czas trwania każdego zadania programistycznego, zanim uzyskasz jakiekolwiek wartości bezwzględne. W miarę zagłębiania się w planowanie projektu przekonwertujemy te względne rozmiary na punkty fabularne i godziny pracy.

Na przykład, jeśli Twój klient chce, abyś stworzył serię wyskakujących okienek w serwisie randkowym, byłoby to czasochłonne, ale proste. Możesz scharakteryzować tę złożoność zadania jako „Małą”, ale wysiłek byłby „Średni”. Możesz to skrócić jako „SM”. Z drugiej strony opracowanie połączenia back-end dla nowego API byłoby bardziej złożonym zadaniem ze względu na całą wymaganą dokumentację i testy. Potrzebne do tego umiejętności i uwaga mogą sprawić, że będzie to „duży” zarówno pod względem wysiłku, jak i poziomu umiejętności: „LL”.

Gdy skończysz rozmiar koszulki, będziesz mieć poczucie względnego obciążenia pracą i wymagań dotyczących umiejętności każdego przyszłego członka zespołu. Ekspert techniczny z zespołu programistów może następnie pomóc Ci skorelować rozmiar T-shirtu z zakresami godzin i punktów historii.

Ustaw swoje parametry

Teraz możesz przystąpić do pracy z arkuszem kalkulacyjnym i obliczyć szacunkowe dane. Zacznij od utworzenia zakładki Parametry. Będzie to klucz do Twoich obliczeń, a wartości, które tutaj wprowadzisz, zostaną wprowadzone do formuł używanych na kartach Backlog/User Stories i Estimate Summary by Release.

Oto wszystko, czego potrzebujesz na karcie Parametry:

Waluta. Tutaj wprowadzasz przeliczanie walut. Na przykład, jeśli budżet klienta jest w realach brazylijskich, możesz wprowadzić aktualny kurs wymiany dolarów lub euro.

Data rozpoczęcia. Oczekiwana data rozpoczęcia rozwoju zostanie wykorzystana do utworzenia osi czasu projektu. W każdym przykładzie nasza data rozpoczęcia to 25 października.

Budżet początkowy. Budżet zapewnia ograniczenia, które pokazują, czy wszystkie funkcje MVP będą się w nim mieścić.

Rozmiar koszulki. Wprowadź rozmiary swoich T-shirtów w formie tabeli i przypisz punkty historii oraz zakres godzin do każdej kombinacji rozmiarów. W tym przykładzie używamy od jednej do dwóch godzin dla SS i od 33 do 48 godzin dla LL.

Pamiętaj, że czas trwania sprintu ogranicza maksymalny rozmiar koszulki. Jeśli sprint trwa tylko tydzień, największy rozmiar nie może przekroczyć 40 godzin. Dlatego tak ważne jest konsultowanie się z MŚP przy przypisywaniu rozmiarów koszulek do zadań .

Stawki za godzinę. Użyj tej tabeli, aby udokumentować stawki płac dla każdej roli. Jeśli twoi programiści back-end mają różne stawki, użyj średniej z dwóch.

Nad głową. Przydziel procent całkowitego nakładu pracy nad projektem na zadania administracyjne, takie jak spotkania dotyczące statusu, sesje opinii i poprawki projektu. Dziesięć procent (lub cztery godziny tygodnia pracy każdego uczestnika) to dobry początek, ale koszty ogólne mogą być wyższe w przypadku bardziej złożonych projektów.

Przypadkowość. Wskazuje to potencjalną różnicę w oszacowaniu. Rozpoczęcie od rezerwy 0% pokaże najlepszy (tj. mało prawdopodobny) budżet i harmonogram, biorąc pod uwagę wartości wprowadzone w arkuszu kalkulacyjnym. W dalszej części naszego przykładu zwiększymy nieprzewidzianość do zgrubnego rzędu wielkości (ROM) wariancji 50%, aby pokazać potencjalny wysoki koniec kosztów i czas trwania projektu. Przygodność będzie się zmniejszać w miarę uzyskiwania dokładniejszych liczb.

Rozmiar każdego wydania z epikami

Zaczynamy od przybliżonego rozmiaru całego produktu, aby upewnić się, że nie marnujemy czasu ani pieniędzy klienta. W zależności od tego, jak bardzo przybliża się do proponowanego budżetu i terminu, klient może zrezygnować z projektu lub zainwestować w bardziej szczegółowe kosztorysy. Ponieważ w tym momencie nie mamy zbyt wielu szczegółów, główne funkcje wprowadzamy jako epiki w zakładce Backlog/User Stories. Następnie dla każdej epopei wprowadzamy liczbę godzin, jaką MŚP i liderzy rozwoju zasugerowali dla każdego stosu rozwoju na podstawie tabeli rozmiarów koszulek w zakładce Parametry.

Najpierw wybierz kolumnę „EPIC?” i upewnij się, że wybrano tylko „Epic”.

Następnie napisz epicki opis i wprowadź liczbę godzin dla każdej kolumny stosu rozwoju. Na przykład epickie „Bezpieczne połączenie i logowanie” zajmie około ośmiu godzin opracowywania interfejsu użytkownika, 40 na zapleczu i tak dalej.

Zauważ, że w większości przypadków komórki w kolumnie „Punkt” wyświetlają „34*”. Jeśli wrócisz do zakładki Parametry, zobaczysz, że 34 punkty odpowiadają przedziałowi godzinowemu od 33 do 48 godzin. Ta liczba godzin jest zbyt duża, jeśli nasz sprint trwa tylko tydzień.

Gdy zdobędziemy więcej szczegółów, trzeba będzie skrócić te godziny lub podzielić eposy na łatwiejsze do opanowania historie. Jednak ze względu na czas zignorujemy kolumnę Punkty i przejdziemy do przybliżonego oszacowania.

Teraz przejdź do zakładki Podsumowanie szacunków według wydania. U góry arkusza kalkulacyjnego zobaczysz wartości „Ogólne” i „Awaryjne” zdefiniowane na karcie Parametry. Dostępny jest również przycisk, który możesz wybrać, aby wyświetlić szacunki według eposów lub historyjek użytkowników.

Ponieważ nie mamy jeszcze historii użytkownika do wyświetlenia, sprawdź przycisk „Tryb epicki”.

Możesz teraz zobaczyć przybliżony koszt i harmonogram MVP oraz mniej pilne funkcje i aktualizacje w przyszłych wydaniach (R3 i R4). W tym przykładzie druga wersja (R2) jest pusta, ponieważ klient zażądał, aby wszystkie epopeje MVP zostały uruchomione w pierwszej wersji.

Możesz teraz zobaczyć najbardziej optymistyczny łączny koszt: 28 810 USD. Ta liczba to suma kosztu każdego wydania od MVP do R4.

Mamy również oszacowany najkrótszy termin dostarczenia produktu, który odpowiada najpóźniejszej dacie ukończenia w stosie rozwoju R4. Menedżerowie projektów nazywają te wolniejsze stosy programistyczne „ścieżkami krytycznymi”, ponieważ dyktują one szybkość całego wydania.

W tym przypadku ścieżką krytyczną jest rozwój front-end z datą zakończenia 31 stycznia.

Teraz nadszedł czas na dostosowanie parametrów, aby zasymulować najgorszy budżet i najdłuższy harmonogram.

Ustaw awaryjność na 50%

Nadal stosunkowo niewiele wiemy o wymaganiach dotyczących nakładu pracy i wiedzy fachowej dla produktu, więc dodamy awaryjność pamięci ROM w wysokości 50% w zakładce Parametry. Nieprzewidziane sytuacje zmniejszą się, gdy dowiemy się więcej szczegółów na temat projektu.

Ponownie, tutaj jest całkowite oszacowanie projektu na 0% awaryjności.

I tutaj jest na 50% awaryjność.

Oznacza to, że szacunek ROM dla całego projektu wynosi od 28 810 do 41 860 USD. W najlepszym i najgorszym przypadku budżet klienta w wysokości 20 000 USD nie wystarczy, aby uwzględnić wszystkie funkcje na jego liście życzeń.

Pełna data ukończenia projektu przy 50% awaryjności przypada teraz na 14 marca, sześć tygodni później niż data ukończenia na 0% awaryjnych warunków.

Tymczasem MVP będzie gotowy 10 stycznia.

Zamiast rezygnować z projektu, klient prosi o bardziej szczegółowe oszacowanie, aby sprawdzić, czy może on wylądować bliżej jego docelowego budżetu w krótszym czasie.

Zmień priorytety, aby dotrzymać terminów

Załóżmy, że klient ustalił docelową datę 25 grudnia dla MVP, dwa miesiące od rozpoczęcia 25 października.

Aby przesunąć obecną datę ukończenia MVP 10 stycznia, klient zgodził się opóźnić dwie epopeje MVP do następnej wersji (R2).

Arkusz kalkulacyjny oblicza efekt kaskadowy tego dostosowania. W tym przypadku oś czasu MVP skraca się do 27 grudnia. Rozwój frontonu i back-endu to ścieżki krytyczne w tej symulacji, ponieważ ich ukończenie zajmie najwięcej czasu.

Na podstawie tych informacji możesz zdecydować się na dodanie kolejnych dwóch programistów, aby dopasować daty ukończenia frontonu i zaplecza do innych stosów programistycznych. Aby to zrobić, zwiększ godziny z 40 do 80 w rzędzie MVP „Godziny w tygodniu”.

Zarówno front-end, jak i back-end development stacks kończą się teraz w listopadzie, a kontrola jakości staje się nową ścieżką krytyczną (z datą zakończenia 20 grudnia). Pamiętaj, że koszt się nie zmienia. Dzieje się tak, ponieważ łączna liczba godzin pracy w każdym stosie pozostaje taka sama. Zamiast jednego programisty pracującego przez dwa tygodnie (80 godzin), dwóch programistów pracuje przez tydzień (80 godzin).

Arkusz kalkulacyjny uwzględnia również różnice między pracą w pełnym i niepełnym wymiarze godzin. Załóżmy, że programista interfejsu użytkownika będzie pracował w niepełnym wymiarze godzin. Możemy zmienić UI „Godziny projektowania tygodniowo” na 20, aby zasymulować opóźnienie w dostawie.

Zgodnie z harmonogramem na pełny etat, UX/UI zostaną ukończone 29 listopada.

W ramach harmonogramu w niepełnym wymiarze godzin UX/UI zostaną ukończone 27 grudnia.

Po raz kolejny koszt się nie zmienia, ale UX/UI staje się nową ścieżką krytyczną, wydłużając harmonogram MVP do 27 grudnia.

Możesz kontynuować to podejście oparte na próbach i błędach, aż osiągniesz akceptowalną ścieżkę krytyczną, biorąc pod uwagę zasoby i termin klienta. Po wyznaczeniu odpowiedniego terminu nadszedł czas, aby rozpocząć dopracowywanie szacunków.

Doprecyzuj swoje oszacowanie za pomocą historii użytkowników

Ponieważ 50% oszacowanie awaryjności nie mieściło się w budżecie klienta, warto dopracować zmienne, aby obniżyć awaryjność i uzyskać bardziej realistyczne oszacowanie.

Aby to zrobić, współpracuj z programistami i MŚP, aby podzielić swoje eposy na szczegółowe historie użytkowników. Historie są lepiej zdefiniowane niż eposy, dzięki czemu możemy je dokładniej określić.

Następnie dostosuj wartości na karcie Parametry na podstawie nowych informacji. Na przykład Twoje MŚP i zespół programistów mogą mieć dokładniejszy zestaw stawek dla każdej roli i mogą również chcieć dostosować rozmiary koszulek i przydział punktów. Dzięki tym nowym parametrom możesz mieć większą pewność swoich obliczeń i obniżyć awaryjność do 25%.

Spójrzmy, jak podzieliliśmy eposy na mniejsze i bardziej szczegółowe historie użytkowników:

W przeciwieństwie do epickiego oszacowania, które wymagało ręcznego wprowadzenia szacowanych godzin dla każdego stosu, oszacowanie historii wykorzystuje rozmiar koszulki jako skrót. Tutaj przydają się rozmiary koszulek, które wpisałeś w zakładce Parametry.

W sekcji „Rozmiar koszulki” na karcie Backlog/Historie użytkowników wprowadź kombinację rozmiarów, które Twoi programiści i MŚP przypisali do ich stosów dla każdej historii. Stamtąd formuła arkusza kalkulacyjnego automatycznie wypełni odpowiednie godziny z karty Parametry. Pamiętaj, że największy rozmiar, LL, musi pozostać poniżej 34 punktów, aby zapewnić, że można go ukończyć w uzgodnionym czasie sprintu. Wszelkie historie, które nadal mają 34 punkty lub więcej, będą musiały zostać podzielone.

Po upewnieniu się, że do wszystkich historii przypisano mniej niż 34 punkty, usuń zaznaczenie przycisku „Tryb epicki” w zakładce Podsumowanie szacunków do wydania, aby wyświetlić tylko „Historia”.

Teraz zobaczysz nowy zestaw liczb:

Po wyszczególnieniu wszystkich zadań i trzymaniu się tylko funkcji MVP, harmonogram i koszt są teraz zgodne z wymaganiami klienta. Ponieważ równowaga mieści się w ich budżecie, klient decyduje się na kontynuację MVP i przetestowanie go przed podjęciem decyzji o kolejnych wydaniach.

Uczyń to swoim

Arkusze kalkulacyjne są proste w użyciu, a dzięki podstawowej znajomości formuł (bez makr) można je dostosować do niemal wszystkich potrzeb. Jeśli Twoja wiedza dotycząca Excela jest zardzewiała, kursy online dotyczące Udemy i edX pomogą Ci odświeżyć te umiejętności.

W tym artykule omówiono szacowanie odkrycia, ale można użyć tego samego arkusza kalkulacyjnego do tworzenia wykresów wypalania/wypalania, dostosowywania osi czasu i obliczania szacunków na podstawie prędkości i sprintów na późniejszych etapach. Używam swoich niestandardowych arkuszy kalkulacyjnych do uzupełniania aplikacji, takich jak Jira, Asana i Trello, i uważam, że są one potężnym narzędziem w moim zestawie do zarządzania projektami. Mam nadzieję, że okażą się dla Ciebie równie przydatne i wszechstronne.

Wolisz niestandardowe arkusze kalkulacyjne od gotowych narzędzi do zarządzania projektami? Powiedz nam, dlaczego lub dlaczego nie w komentarzach.