Szacowanie kosztów oprogramowania w zwinnym zarządzaniu projektami

Wstęp

Jedną z najtrudniejszych rzeczy do zrobienia w tworzeniu oprogramowania jest określenie, jak długo i ile zajmie dostarczenie nowego oprogramowania. Czy to powinno być takie trudne? Odpowiedź nie jest prosta.

Szacowanie kosztów oprogramowania jest z natury trudne, a ludzie są strasznie źli w przewidywaniu bezwzględnych wyników. Nie ma dwóch takich samych projektów; każdy jest wyjątkowy w tym, co zamierza osiągnąć, i wyjątkowy w niezliczonych parametrach, które tworzą jego istnienie. Często to, co na pierwszy rzut oka wydaje się prostym problemem, jest znacznie trudniejsze lub technicznie trudne do wdrożenia w rzeczywistości. I bez wątpienia w projekcie pojawią się „niewiadome”, które można zidentyfikować tylko wtedy, gdy się pojawią.

Ponadto nie ma dwóch takich samych osób, niezależnie od tego, czy jesteś klientem, programistą czy użytkownikiem. Przychodzimy z własnym zestawem wiedzy, doświadczeń, wartości, oczekiwań, stosunku do ryzyka i zdolności do adaptacji.

Pisanie dobrej jakości oprogramowania to chleb powszedni dla starszych inżynierów; tworzenie niesamowitego oprogramowania może być znacznie trudniejszym przedsięwzięciem dla wszystkich zaangażowanych osób.

Ale jeśli chodzi o oprogramowanie, zrozumienie czasu trwania i kosztów ma kluczowe znaczenie w podejmowaniu strategicznych decyzji biznesowych, niezależnie od tego, czy tworzysz startup, zdajesz sobie sprawę z nowej możliwości biznesowej, czy też umożliwiasz swojej firmie lepsze wyniki. Czas, zwrot z inwestycji i dostarczane korzyści mogą wpłynąć na, wstrząsnąć lub zepsuć Twój biznes. Zadajesz sobie pytanie: co otrzymujemy za nasze pieniądze? Czy możemy przewidzieć nasze koszty? Ile będzie kosztowało stworzenie produktu, który chcemy? Kiedy możemy wystartować? Czy do naszej inwestycji otrzymamy produkt wysokiej jakości? Czy będzie rosła wraz z naszą firmą? Czy przyniesie wartość biznesową?

Jak więc oszacować rozmiar, czas trwania i koszt projektu? Przyjrzyjmy się szacowaniu projektów Agile i kosztów rozwoju oprogramowania oraz jak to robimy w Toptal.

Tradycyjna wycena kontraktowa i estymacja

Tradycyjnie, używając praktyk niezwiązanych z Agile, projekty oprogramowania miały na celu naprawienie funkcjonalności lub zakresu oraz pozostawienie zmiennych czasu i kosztów. Powoduje to problemy:

1. Skąd wiesz, że funkcjonalność, którą naprawiasz na początku projektu, naprawdę jest funkcjonalnością, która najlepiej służy Twojej firmie lub klientom? Częściej niż nie, funkcjonalność lub zakres ulegną zmianie, dlatego słyszymy o „pełzaniu zakresu”, wyniku pożądanych potrzeb identyfikowanych w cyklu życia projektu i określanych jako konieczne lub obowiązkowe

2. Kiedy koszt staje się zmienną, tracimy kontrolę nad zwrotem z inwestycji (ROI), który staramy się osiągnąć. Zwiększony koszt jest często wynikiem niezidentyfikowanego ryzyka lub zmieniających się wymagań, co oznacza, że ​​musimy dodać członków zespołu, aby wykonać więcej pracy w tym samym czasie lub zatrzymać członków zespołu na dłużej. Żadne nie jest pożądane

3. Gdy czas jest zmienny, tracimy kontrolę nad pozycją na naszym rynku. Być może przegapiamy ważną dla branży datę lub nasi konkurenci prezentują swój produkt przed nami, tracąc w ten sposób jakąkolwiek przewagę konkurencyjną, jaką mógł mieć nasz projekt.

Istnieje wiele innych skutków o zmiennym czasie i koszcie, które często są negatywne i niepożądane.

Oczywiście wielu klientów i organizacji stara się naprawić wszystkie trzy elementy tego „magicznego trójkąta”. Niestety, jest to prawie niemożliwe do osiągnięcia. Jest zbyt wiele elementów, które skłaniają do zachwiania tego ideału, co ostatecznie prowadzi do powstania produktów, które nie spełniają potrzeb, zbyt długo przynoszą korzyści klientom lub zbyt dużo kosztują, aby zrealizować wartość biznesową.

Zwinne kontrakty na projekty oprogramowania

Koszt jest iloczynem czasu i ludzi (członków zespołu). Dodaj więcej czasu, a doliczysz koszty dłuższego zatrudniania ludzi. Dodaj więcej członków zespołu, a zwiększysz koszty, aby zapewnić tę samą wartość biznesową. Rzeczy, których naprawdę chcemy uniknąć. Właśnie dlatego zasady Agile wierzą w ustalanie czasu i członków zespołu oraz pozwalanie, aby zakres był elementem zmiennym.

Co brzmi lepiej i zwiększa zaufanie interesariuszy, koszt stały czy koszt zmienny?

Oczywiście ważne jest, aby produkt spełniał obietnice i potrzeby klientów. Nie ma sensu spędzać dokładnej ilości czasu i dokładnej kwoty pieniędzy, jeśli w końcu masz produkt, którego nikt nie chce lub nie może skutecznie używać.

Tak więc kontrakty Agile skupiają się na następujących kwestiach:

• Pakiety robocze o stałej cenie — cały projekt jest podzielony na logiczne „mini” wydania, które przyczyniają się do pełnego wyniku produktu. Każde wydanie jest pakietem roboczym o odpowiedniej cenie. Po ukończeniu pakietu roboczego przyszłe pakiety robocze są ponownie szacowane w oparciu o to, czego nauczyliśmy się z poprzedniego. Pozwala to uniknąć niepotrzebnych nieprzewidzianych sytuacji i umożliwia zdefiniowanie przez klienta poziomu zmiany priorytetów oraz nowych/zmienionych funkcji.

• Wcześniejsze zakończenie — umożliwia to klientowi wcześniejsze zakończenie projektu, jeśli dostarczono wystarczającą ilość produktu i nie można osiągnąć dalszego zwrotu z inwestycji poprzez zatrzymanie zespołu projektowego, który będzie nadal zapewniał jedynie marginalne korzyści. Klauzula ta jest zazwyczaj dozwolona w dowolnym momencie i obowiązuje tak długo, jak zespół projektowy i klient utrzymują silną, pełną zaufania i bliską współpracę. Korzyścią dla klienta jest to, że projekt zakończy się wcześnie, dostarczając wszystkie cenne funkcje niezbędne do tego, aby produkt był opłacalny. W zamian dostawca otrzymuje 20 procent pozostałej wartości umowy i kompensuje ryzyko zatrzymania personelu.

• Elastyczne zmiany — Zmiana to motyw, który działa w żyłach dostarczania oprogramowania Agile. Spodziewamy się, że nie będziemy wiedzieć wszystkiego, czego potrzebujemy, aby produkt od samego początku odnosił sukcesy. Dlatego promujemy zmiany, opierając się na odpowiednich danych i informacjach zwrotnych, aby zapewnić dostarczenie właściwego produktu. Pod koniec iteracji zmiany można zamienić na stare funkcje, które nie są już uważane za konieczne lub priorytetowe. Dopóki zmiana ma taką samą wartość, nie ma dalszych kosztów. Jeśli zmiana ma niższą wartość, można zidentyfikować dodatkowe prace lub wyciągnąć je z pozostałego zaległości. Klauzula ta obowiązuje tak długo, jak zespół projektowy i klient utrzymują silną, pełną zaufania i bliską współpracę w trakcie całego projektu.

• Dodatkowa praca - W trakcie trwania projektu można zidentyfikować więcej funkcji, które nie byłyby osiągalne w ramach istniejącej umowy o stałej cenie. W tym scenariuszu na końcu projektu można dodać dodatkowe pakiety robocze o nowo wycenionej cenie lub przywrócić czas i materiały.

• Oszacowania w zakresie — istnieją dwa sposoby, w których oszacowania można określić w umowie dotyczącej projektu Agile: zakres czasu trwania lub zakres funkcji. Zakres czasu trwania pozwala na szacunkowe stwierdzenie, że projekt lub pakiet roboczy zajmie od 12 do 16 tygodni dla danego zakresu. Jednak dodanie czasu trwania zwiększa koszty, ponieważ dłużej utrzymujesz członków zespołu projektowego lub oznacza to, że nie można ich zwolnić do pracy nad innymi projektami deweloperskimi. W Toptal wolimy rozróżniać funkcje w różnych punktach fabularnych, zachowując zakres jako zmienny, ale obiecując dostarczać klientowi minimalny poziom wartości w ustalonych ramach czasowych pakietu roboczego lub całego projektu.

Warto pamiętać, że później zawsze możesz dodać większy zakres. Być może zacząłeś zarabiać, zwiększyłeś liczbę użytkowników lub zmniejszyłeś koszty. Tak czy inaczej, znacznie łatwiej jest poprosić o więcej pieniędzy i czasu, jeśli już wykazałeś zwrot lub poprawę i zapewniasz wartość biznesową.

Nasze podejście do kosztów i wyceny oprogramowania

W Toptal ściśle współpracujemy z naszymi klientami i inżynierami, aby stosować techniki, które zwiększają zaufanie interesariuszy do czasu trwania i kosztów projektu. Pracujemy nad ciągłym opracowywaniem i dostosowywaniem planowania od początkowego wysokiego poziomu do bardziej szczegółowych, gdy jest to właściwe i konieczne, aby uniknąć marnotrawstwa i umożliwić zarządzaną zmianę.

Przy opracowywaniu projektu kosztorysu i ceny stałej podejmowane są następujące kroki:

1. Początkowy zakres wysokiego poziomu

Na początku projektu najmniej wiemy o jego ostatecznym wyniku. To szaleństwo wyobrażać sobie, że od samego początku można dokładnie wiedzieć, jakich funkcji potrzebują nasi klienci i użytkownicy.

Tak więc zaczynamy od karty projektu i wysokiego zestawu „epickich” funkcji, które wyznaczają kierunek projektu, w oparciu o solidną wizję i cele

a. Wyznaczanie wizji i celów Co musimy zbudować? Co musisz osiągnąć i jakie są Twoje cele biznesowe? Zrozumienie tych pytań pozwala nam ustalić skalę projektu. Potrzebujesz prototypu do przetestowania wstępnego pomysłu, koncepcji lub technologii? Czy zidentyfikowałeś jasną propozycję, która została przetestowana na Twoim rynku i czy jesteś gotowy do zbudowania swojego pierwszego produktu o minimalnej opłacalności (MVP)? A może skalujesz istniejący biznes lub produkt, aby przenieść go na wyższy poziom?

b. „Epickie” funkcje wysokiego poziomu Bez wchodzenia w szczegóły, będziesz chciał zdefiniować funkcje, które posiada Twój produkt, aby spełnić potrzeby klienta. Jest to ustrukturyzowana „lista zakupów”, która opisuje podstawowe elementy Twojego produktu; często są one określane jako „historie użytkowników” lub epopeje

C. Analiza MoSCoW Analiza MoSCoW to technika, która w uproszczeniu pomaga określić, co jest naprawdę konieczne, aby produkt był opłacalny, a co warto mieć. Te, które są określone jako „obowiązkowe”, zaspokoją to, co zachęci użytkowników do zaangażowania i przyjęcia Twojego produktu. Te cechy określone jako „powinny” zaskoczą i zachwycą Twoich klientów, ale mogą zostać zbudowane później. Pozycje „mogą” często nie dodają znaczącej wartości biznesowej, mogą nie zwiększać zwrotu i są najniższym z twoich priorytetów. Funkcje „Nie” mogą być kiedyś ważne, ale są poza zakresem tej iteracji projektu. Jednak identyfikacja ich teraz może pomóc w ustaleniu potencjalnej skali i rozmiaru produktu w przyszłości.

2. Propozycja

Aby podjąć decyzję, czy kontynuować projekt, konieczne jest oparcie tej decyzji na dobrze poinformowanych danych: kosztach i czasie trwania. Oto minimum, które musisz sobie zadać: czego potrzeba, aby stworzyć produkt, którego pragniemy? Kiedy możemy wystartować? Czy jest to zgodne z naszą strategią biznesową i finansami?

Biorąc pod uwagę powyższe szczegóły, jesteśmy w stanie przedstawić propozycję. Nasi inżynierowie są starannie dobierani pod kątem konkretnych wymagań projektowych i współpracują z kierownikiem projektu, aby opracować co najmniej jedno rozwiązanie techniczne, szacowany czas trwania, który zapewnia znany zakres i szacowany koszt ukończenia projektu.

Jak wspomnieliśmy wcześniej, na początku projektu wiemy najmniej o tym, co zostanie dostarczone. Celowo utrzymujemy niejasne funkcje i zakres, ponieważ postępowanie w inny sposób sugeruje, że dokładnie wiemy, co jest wymagane. Szacunek na tym etapie byłby najmniej dokładny, ale zawiera wskazówki, czy warto kontynuować projekt.

Propozycja jest pierwszym narzędziem w opracowaniu czasu trwania i kosztów projektu. Gdy oferta zostanie zaakceptowana, możemy przejść dalej, aby przedstawić stałą wycenę.

3. Planowanie wydania

Następnym poziomem opracowania szacunkowego jest stworzenie planu wydania, który zapewni szereg funkcji w określonym przedziale czasowym. Wywodzimy to z listy cech, wielkości projektu, tego, jak szybko nasz zespół może opracować wysokiej jakości oprogramowanie, które spełnia oczekiwania klienta oraz techniki zarządzania ryzykiem niepewności.

a. Rejestr produktu Rejestr produktu to po prostu uporządkowana lista „Epics” lub „Historii użytkowników”, która reprezentuje funkcje wymagane dla produktu. Ta lista zaczyna się jako eposy omówione wcześniej, ale między wyznaczonym zespołem projektowym, kierownikiem projektu i klientem dzielimy je teraz na bardziej znaczące elementy. Każda z pozycji reprezentuje część wartości biznesowej dla klienta. Na tym etapie nie wchodzimy w szczegóły, nie musimy znać kryteriów akceptacji, nie musimy wiedzieć, czy przycisk jest niebieski czy zielony, musimy tylko wiedzieć, że istnieje przycisk, który umożliwia wykonanie jakiegoś zadania do wykonania.

b. Szacowanie Teraz, gdy mamy naszą listę funkcji opisanych jako historyjki użytkowników, zespół szacuje te dyskretne elementy funkcji za pomocą techniki zwanej „Planning Poker”. Jest to przydatna technika, która zapewnia szybkie, wiarygodne wyniki oparte na opinii ekspertów i analogicznej wielkości. Planning Poker przypisuje każdemu przedmiotowi ustaloną liczbę reprezentującą jego rozmiar i złożoność. Nazywa się to punktem fabularnym. Dostępne są inne techniki i rozmiary szacowania Agile, takie jak „dni idealne”.

Koniec tego procesu określi rozmiar projektu i zależności między funkcjami. Rozmiar jest określany przez zsumowanie wszystkich punktów historii z pozycji w rejestrze produktu. Jeśli ta liczba wynosi 120, to rozmiar naszego projektu wynosi 120 punktów historii.

C. Ustalanie priorytetów Teraz, gdy mamy zaległości i rozmiar projektu, jesteśmy w stanie ustalić priorytety z klientem. Tak naprawdę chodzi o zidentyfikowanie tego, co jest najcenniejsze dla klienta, aby osiągnąć pożądane rezultaty. Pozycja na górze listy jest uważana za najważniejszą, druga pozycja jest mniej ważna niż pierwsza i tak dalej na liście. Żadne dwa elementy nie mogą być tak ważne jak inne, priorytet każdego elementu ma względną wagę lub wartość w stosunku do pozostałych elementów.

Takie podejście do ustalania priorytetów jest ważnym kamieniem milowym w planowaniu projektu oprogramowania. Teraz wiemy, co jest ważne dla klienta iw jakiej kolejności wykonać pracę, dbając o zależności, aby dostarczyć produkt spełniający oczekiwania.

D. Planowanie wydania Do tej pory ustaliliśmy, za jaki produkt uważamy i jak duży jest.

Teraz określamy, ile czasu zajmie dostarczenie produktu nadającego się do wydania. Klient i zespół, w tym projektanci, inżynierowie, testerzy, scrum master i kierownik projektu, współpracują ze sobą, aby określić, co można osiągnąć i jak szybko można wykonać pracę, aby stworzyć plan wydania.

Plan wydania daje również wgląd w to, jak projekt będzie zgodny z planami strategicznymi klienta.

I wreszcie, plan ten zapewnia zespołowi projektowemu przewodnictwo, które wyznacza kierunek i określa logiczny punkt końcowy rozwoju.

Zanim zaczniemy, upewniamy się, że rozumiemy uzgodnioną definicję „zrobione”. Jest to określony zestaw kryteriów, które klient zaakceptuje jako kompletne, a także spełnia wszystkie wymagania inżynieryjne, które należy uznać za możliwe do wydania.

Aby wziąć pod uwagę podstawowy scenariusz, bierzemy całkowitą liczbę punktów fabularnych, które uzyskaliśmy z ustalenia naszych zaległości i dzielimy je przez przewidywaną prędkość naszych zespołów. (Prędkość NB jest zwykle wyrażana jako zakres, ale dla uproszczenia użyjemy tutaj pojedynczej liczby.) Pracujemy w dwutygodniowych iteracjach, więc nasza prędkość będzie odzwierciedlona przez to, ile możemy ukończyć w dwutygodniowym cyklu z dostępnymi pojemność zespołu. Jeśli nasze punkty fabularne wyniosłyby 120 i przewidujemy, że ukończymy 20 punktów na iterację, całkowity czas rozwoju wyniesie 12 tygodni lub 6 iteracji. Dodajemy do tego sprint 0 trwający 2 tygodnie i sprint przygotowania do wydania trwający 2 tygodnie. Łącznie nasz projekt trwa 16 tygodni. Istnieją techniki, których możemy użyć, które pomogłyby zbudować odpowiedni bufor ryzyka w naszym planowaniu, co omówimy później. Krótko mówiąc, używamy bufora do zarządzania ryzykiem niepewności i do osiągnięcia minimalnego porozumienia w zakresie oczekiwanych punktów fabularnych, które mają zostać dostarczone. Wynikiem może być zakres od 90 do 150 dostarczonych punktów historii, przy czym 90 to minimum, które byłoby dopuszczalne do stworzenia opłacalnego produktu.

Ewentualnie, jeśli projekt musi zostać ukończony w określonym terminie, powiedzmy 10 tygodni, zespół określi, jaka część zaległości może zostać ukończona w tym czasie. Jeśli przewidujemy 20 punktów fabularnych na sprint, plus Sprint 0 i sprint do wydania, celujemy w 60 punktów ukończonych do końca projektu. Ponownie chcielibyśmy zarządzać ryzykiem, dodając odpowiedni bufor, co może skutkować ukończeniem od 45 do 75 punktów fabularnych i gotowością do wydania. 45 punktów fabularnych byłoby zgodnych z minimalnym dopuszczalnym, aby dostarczyć opłacalny i wartościowy produkt. To jeden ze scenariuszy, w którym możesz spodziewać się dodania członka zespołu, aby zwiększyć prędkość, jeśli to konieczne.

Oczywiście wszystko to jest wspierane przez dobrej jakości komunikację i współpracę między wszystkimi stronami, aby opracować plan wydania, który jest osiągalny, realistyczny i akceptowalny dla klienta.

4. Umowa o ustalonej cenie

Po uzgodnieniu planu wydania jesteśmy w stanie stworzyć wycenę dla umowy projektowej o stałej cenie. Jak wspomniano wcześniej, wskazane jest, aby czas trwania projektu i zespół były stałe oraz zmienny zakres.

Wycena umowy z ceną stałą dostarczana jest wraz z zestawieniem prac i uzgodnionym harmonogramem płatności.

Dopóki istnieje zaufanie, komunikacja, współpraca i gotowość do wejścia w ducha projektu oprogramowania Agile, wszystkie powyższe kroki pozwalają nam dostarczyć wycenę z realistycznym stopniem pewności, że projekt zostanie dostarczony na czas i w budżecie. Oczywiście będą sytuacje, w których projekt zostanie dostarczony wcześnie lub późno, a my radzimy sobie z tymi odmianami z najwyższą przejrzystością.

Techniki szacowania

Zwinne planowanie i szacowanie są wspierane przez szereg technik, które zespół programistów może wykorzystać, aby uzyskać pewność co do wielkości, nakładu pracy, czasu trwania i kosztów. Oto niektóre z tych, których nasze zespoły używają do oszacowania rozmiaru i kosztu projektu oprogramowania.

Szacowanie rozmiaru

Rozmiar projektu jest tak naprawdę uznaniem jego zakresu, złożoności, wymiarów, ryzyka i wielkości. Używając analogii, chodzi o zrozumienie, czy budujemy Wieżę Eiffla, czy Wielki Mur Chiński. Wieża Eiffla to wysoka, ciężka, złożona konstrukcja zbudowana w ciasnym środowisku miejskim. Wielki Mur Chiński to stosunkowo prosta, ale długa i solidna konstrukcja obejmująca wiele mil pofałdowanego terenu.

Chociaż oba byłyby dużymi projektami do realizacji, ich zakres, złożoność, wymiary, wielkość, a tym samym wielkość, są różne.

Ważne jest, aby zarządzać oczekiwaniami za pomocą szacunków. Nigdy nie są przewidywaniami, zobowiązaniami ani gwarancjami. Omawiając całkowity rozmiar, całkowity czas trwania i całkowity koszt, zawsze pracujemy w granicach, aby zmniejszyć ryzyko, niepewność i niewiadome.

Historie przedstawiające cechy Twojego produktu są indywidualnie dobierane i szacowane na podstawie punktów historii lub idealnych dni. Całkowita liczba tych jednostek określa całkowity rozmiar projektu.

Punkty fabularne

Punkty historyjki to jednostka miary wyrażająca całkowity rozmiar historyjki użytkownika. Szacowany rozmiar historii obejmuje wszystkie aspekty projektowania, inżynierii, testowania, przeglądu kodu, integracji itp.

Każdy rozmiar historii jest powiązany z inną historią. Na przykład, kondygnacja A może mieć jeden punkt, kondygnacja B dwa punkty, a kondygnacja C trzy punkty. W tym przypadku historia C jest co najmniej trzy razy większa od historii A i co najmniej o połowę mniejsza od historii B.

Jeśli poniższe historie w naszym rejestrze produktów mają powiązane rozmiary:

Całkowity rozmiar projektu to 12 punktów fabularnych.

Idealne dni

Jest to miara wielkości wyrażona w dniach. Usuwa pojęcie kosztów ogólnych, takich jak przerwy, działania związane z planowaniem zwinnym, czytanie e-maili i inne czynności niezwiązane z projektem. Koncentruje się tylko na tym, ile czasu zajęłoby, gdybyś pracował nad czymś nieprzerwanie, bez przerwy, a nie na czasie, który upłynął od początku do końca.

Zazwyczaj podczas szacowania na wysokim poziomie, gdy wiemy najmniej o projekcie, szacowalibyśmy w idealne dni, ponieważ jest to łatwiejsza koncepcja do skorelowania z przeszłą historią i doświadczeniem niż abstrakcyjna liczba, taka jak punkt fabularny. Zwłaszcza, gdy historie na wysokim poziomie mają charakter bardziej epicki, z niewielką ilością szczegółów i prawdopodobnie zawierają dodatkowe elementy, gdy zostaną podzielone w późniejszym terminie.

Podczas szacowania na bardziej szczegółowym poziomie, powiedzmy historię w ustalonym rejestrze produktów, można zastosować dowolne podejście, o którym decyduje zespół inżynierów. Oba podejścia mają swoje zalety i każdy zespół będzie miał swoje preferencje.

Techniki szacowania

Wspólne szacunki Szacunki nie są przeprowadzane w oderwaniu. Są one wykonywane wspólnie przez cały zespół inżynierów i obejmują projektowanie, bazę danych, serwer, interfejs użytkownika, kontrolę jakości i innych ekspertów wielofunkcyjnych. Pozwala to uniknąć problemów związanych z nieuwzględnianiem wszystkich aspektów pracy związanej z ukończeniem funkcji i zapewnia, że ​​żadna osoba nie ma ciężaru ani nieszczęścia z powodu przeszacowania lub niedoszacowania rozmiaru funkcji. Połączony zespół będzie miał pogląd, który można omówić i uzgodnić.

Szacunki analogiczne W tym miejscu rozważamy dwie odrębne cechy i decydujemy, że jedna jest stosunkowo mniejsza lub większa od drugiej. Możemy spojrzeć na daną historię i zgodzić się, że ma ona niewielki rozmiar, a jeśli użyjemy punktów fabularnych, możemy nadać jej rozmiar dwa. Kolejną historię można by uznać za dużą w porównaniu z pierwszą, a my dalibyśmy jej rozmiar pięć. Sugeruje to, że duża jest co najmniej dwa razy większa od małej.

Kontynuowalibyśmy to ćwiczenie ze wszystkimi historiami. Po zakończeniu możemy następnie ułożyć wszystkie małe, średnie, duże i bardzo duże kondygnacje obok siebie i sprawdzić nasze rozmiary, aby upewnić się, że w naszych szacunkach występuje poziom jednolitości.

Planning Poker Wiele napisano o Planning Poker; Wspomniałem o tym również na moim poprzednim blogu. Jedno z najlepszych źródeł do zrozumienia tego jest tutaj.

W istocie łączy ekspertyzy, analogie i współpracę zespołową w jeden łatwy, szybki i niezawodny proces.

Skupia wielu ekspertów, którzy najlepiej nadają się do opracowania wyceny w oparciu o doświadczenie techniczne i dziedzinowe, żywy dialog i solidne uzasadnienie.

Prędkość

Prędkość jest miarą zdolności zespołu do wykonania pracy w danej iteracji (lub sprincie).

Wyraża się to jako zakres, na przykład od 23 do 32 punktów fabularnych na sprint, szczególnie na wczesnym etapie projektu. Generalnie dzieje się tak dlatego, że o ile ten sam zespół nie pracował wcześniej nad tym samym problemem, trudno jest dokładnie określić, jaka będzie prędkość zespołu. Zauważ, że odnosimy się do prędkości zespołu, a nie indywidualnej!

Wykorzystujemy prędkość do planowania naszych wydań i dostosowywania naszych planów i pakietów roboczych w miarę postępów w projekcie, co umożliwia nam regularne i dokładne dostosowywanie naszej prognozy do ukończenia poprzez wykonanie.

Kiedy zaczynamy, jesteśmy zmuszeni określić zakres prędkości przy bardzo małej ilości danych. Możemy użyć wartości historycznych, jeśli zespół i przestrzeń problemu są takie same, co często jest najmniej prawdopodobne. Możemy uruchomić iterację, aby uzyskać wyobrażenie o szybkości od zespołu faktycznie pracującego nad projektem, ale jest to kosztowne i nie działa, jeśli nadal trzeba podjąć decyzje o zgodzie na rozpoczęcie projektu. Albo możemy sporządzić prognozę.

Prognozowanie prędkości obejmuje zebranie historii ze sprintu i podzielenie ich na zadania, które są wykonywane w celu ukończenia historii. Oszacowalibyśmy liczbę godzin, które zajmie każde zadanie, co obejmuje projektowanie, rozwój, testowanie itd., oraz ocenilibyśmy, ile możliwości miałby zespół w danym sprincie. Wydajność 70 procent dla nieobciążonego zespołu to dobra podstawa. Tak więc w prostej sytuacji, jeśli całkowita liczba godzin dostępnych dla zespołu wynosi:

• 4 członków zespołu * dwa tygodnie * 40 godzin tygodniowo = 320 godzin
• pomnożone przez nasze 70 procent pojemności = 224 godziny
• Dodaj wszystkie zadania fabularne i przestań liczyć na 224
• Weź wszystkie ukończone funkcje, zsumuj ich punkty fabularne i uzyskaj prędkość, powiedzmy 36
• Zastosuj 20 procent z każdej strony, aby uzyskać zakres od najniższego do najwyższego, aby uzyskać szacowaną prędkość od 29 do 43 punktów fabularnych.

Prędkość zwykle zmienia się w pierwszych dwóch do czterech iteracjach, a następnie stabilizuje się w niewielkim zakresie punktów. Tak więc, gdy nasz początkowy zakres przed pierwszym sprintem wynosił od 29 do 43, do czwartego sprintu może on ustabilizować się od 34 do 38. Daje nam to wtedy większą pewność w prognozowaniu ostatecznej daty ukończenia.

Plany buforowania ryzyka i niepewności

Wszystkie projekty oprogramowania wiążą się z pewnym poziomem niepewności. Ta niepewność zmniejsza się w miarę postępów w projekcie, a coraz więcej wiemy o naszej technologii, środowisku, wydajności oraz potrzebach klientów i użytkowników.

Tę niepewność lub ryzyko łagodzimy buforem w harmonogramie, który stanowi margines błędu w naszych szacunkach i niewiadome, których nie możemy określić przed rozpoczęciem prac rozwojowych.

Zazwyczaj istnieją dwa typy buforów: funkcja i harmonogram. Ponieważ często określamy stałą cenę za stałą datę dostawy, lepiej jest użyć bufora funkcji.

Takie podejście daje nam wiarygodną strategię ograniczania ryzyka i daje klientom pewność co do tego, czego powinni się spodziewać po zakończeniu projektu.

Bufory funkcji

Dzięki buforowi funkcji prognozujemy, że dostarczymy dany zestaw funkcji, ale idealnie uzupełnimy kolejny zestaw funkcji. Powinno to odzwierciedlać przynajmniej minimalny zestaw funkcji, który klient uważa za niezbędny do wprowadzenia opłacalnego produktu, ale więcej może zostać dostarczonych w ramach czasowych, jeśli pozwalają na to wszystkie różne czynniki wewnętrzne i zewnętrzne.

Klient może więc uznać, że najważniejsze są cechy o najwyższym priorytecie z rejestru produktu, sumujące do 100 punktów historii. Następnie mogą rozważyć dodatkowe funkcje, które sumują się do kolejnych 30 punktów historii. Zespół zaplanuje zatem w oparciu o dostarczenie 130 punktów fabularnych, przy czym minimum 100 zostanie ukończonych do końca zaplanowanego terminu realizacji dla danej umowy o stałej cenie.

Kilka myśli zamykających

Agile może być bardzo trudną do zrozumienia i zaadaptowania koncepcją. Nie mniej dotyczy to zarządzania wrażliwymi tematami, takimi jak cena, zakres i czas trwania. Niestety, wiem z pierwszej ręki, że wymagający klienci chcą wszystko naprawić z góry i chętnie obwiniają dostawcę, gdy wszystko zaczyna się psuć. Równie dobrze zdaję sobie sprawę z dostawców, którzy walczą, przestają odpowiadać i nie odpowiadają na potrzeby klientów. Podążanie ścieżką Agile opiera się zasadniczo na zaufaniu, dobrych relacjach i doskonałej komunikacji. Muszą to być wartości wyznawane przez obie strony, aby utrzymać zdrowy projekt z równymi korzyściami, satysfakcją i sukcesem dla wszystkich zaangażowanych. Utrzymywanie otwartego umysłu i konstruktywne podejście do współpracy i negocjacji to najlepszy sposób na uniknięcie zepsucia relacji.

Pracowałem z klientami, którym trudno było przyjąć adaptacyjną naturę Agile i zrezygnować z nastawienia dowodzenia i kontroli. Ciężko jest odpuścić i całą swoją wiarę i zaufanie złożyć w zespole, którego nie znasz. Często klienci mogą chcieć stworzyć wszystkie wymagania z góry jako specyfikację tego, co zostanie dostarczone. Daje im to poczucie pewności, że zakres projektu jest dobrze zdefiniowany. Ale ostatecznie nie jest to skuteczne podejście. Jeśli jesteśmy ograniczeni do zakresu i nierealistycznych wymagań w kontrakcie, problemy pojawiają się bardzo szybko.

Wiemy, że stosując takie podejście w tradycyjnych metodach, zmienia się zakres, niewiadome są odkrywane lub to, co naszym zdaniem klientowi oczekiwało, jest już nieprawdziwe lub chybione. Przyjęcie adaptacyjnego podejścia do ustalania cen, planowania i zakresu pozwala klientom naprawdę zidentyfikować swój produkt, aby był dokładnie tym, czego potrzebuje ich rynek. Umożliwia to dostawcy również responsywność, wyobraźnię i wydajność. Kluczowe znaczenie ma wykorzystanie współpracy między klientem a dostawcą w ramach negocjacji umowy.

Sprzedawcy muszą być uczciwi, a klienci realistycznie podchodzić do tego, co można osiągnąć od samego początku. Sprzedawca, który obiecuje nierealistyczne cele, a następnie podnosi koszty, może wygrać wstępny kontrakt, ale wkrótce straci przychylność niezadowolonego klienta. Zbyt często relacje rozpadają się z powodu braku zaufania między stronami. Zaufanie należy budować od samego początku i utrzymywać przez cały czas trwania projektu. Sprzedawca musi być elastyczny i współpracować ze zmieniającymi się potrzebami. Klienci zawsze chcą więcej; to naturalna konsekwencja prowadzenia biznesu. Musi istnieć równa i korzystna wymiana wartości między obiema stronami. Klienci chcą tworzyć wartość dla swojej firmy. Sprzedawcy powinni dążyć do tworzenia wartości poprzez tworzenie długotrwałych relacji z klientami. Przestrzeganie wartości i zasad przewodnich Manifestu Agile jest solidną podstawą do tworzenia silnych, zrównoważonych i długich relacji.

Streszczenie

Mam nadzieję, że to dało ci pewien wgląd w planowanie, szacowanie i określanie ceny za projekt oprogramowania Agile. Wszystkie powyższe podejścia i techniki mają na celu budowanie zaufania w zespole i budowanie zaufania w umysłach klientów, jeśli chodzi o to, jak długo i ile zajmie zbudowanie oprogramowania. I ostatecznie, aby zbudować pewność siebie przy podejmowaniu decyzji o kontynuacji.

Postępuj zgodnie z tymi wskazówkami, a na pewno znajdziesz satysfakcjonującą drogę do ożywienia swojego oprogramowania.