Zespół ocenia punkty fabularne, biznes chce rzeczywistego czasu

Jestem pewien, że nie jest to rzadki motyw. Mamy dwa zespoły scrumowe, które dobrze oceniają historie użytkowników przy użyciu punktów fabularnych (obecne konstelacje zespołu mają zaledwie około 8 miesięcy, chociaż członkowie zespołu mają kilkuletnie doświadczenie w scrumie). Ale część biznesowa firmy ma trudności z odniesieniem do historii użytkowników; chcą rzeczywistych jednostek czasu (lub „formuły przeliczającej punkty fabularne na godziny”), aby mogli zaplanować, kiedy wszystko będzie gotowe ( „musimy wiedzieć, kiedy możemy powiedzieć klientom, że funkcja X będzie produkowana „ ).

Ja i moi poprzednicy Scrum Master wyjaśniłem oczywiście, że „nie ma określonej relacji między punktami opowieści a faktycznym czasem” oraz że „punkty opowieści służą do określenia, jak bardzo zespół może zmieścić się w sprincie”, a ja pewnie zgadniesz, jak byli zadowoleni z tej odpowiedzi. Nadal chcą wiedzieć, w czasie kalendarzowym, kiedy przejdziemy do historii 27 użytkowników w zaległościach.

W każdym razie, zostały kompilacji niektórych statystyk, a nasze szacunki SP przekładają się szalenie różne od faktycznego czasu spędzony wyników (mierzone przez naszego oprogramowania pokładzie Scrum, która śledzi, ile czasu bilety spędzają w „pracuje nad” kolumny ). W przypadku opowieści użytkowników 1-SP istnieje oczywiście duże uprzedzenie do bardzo krótkich okresów czasu (z okazjonalnym powiększeniem), ale szczególnie w przypadku opowieści 2-SP, są wszędzie: współczynnik 20 pomiędzy „najszybszymi” a „najwolniejszymi” ukończeniami. W przypadku opowieści 3, 5 i 8-SP spread jest również większy niż współczynnik 2.

Wskazuje to, że (a) zespół musi być znacznie bardziej konsekwentny w szacowaniu historii użytkowników o (co powinno być) podobnej złożoności, oraz (b) zespół musi poprawić swoją dokładność w raportowaniu czasu (tj. Pamiętać o przeniesieniu biletów z „pracuje”, gdy są na spotkaniu, w porze lunchu lub grają w piłkarzyki).

Mam plany ulepszenia zarówno (a) i (b), ale uważam, że to nie wystarczy, że firma oczekuje „większej konkretności” niż to, co przyniosą te inicjatywy.

Jakie są dobre strategie uspokajania strony biznesowej , aby nie ingerowały zbytnio w nasz sposób działania (np. Poprzez narzucenie stosowania oddzielnego śledzenia czasu, co IMHO byłoby głupie, ponieważ w każdym razie byłoby mniej dokładne niż obecne „automatyczne” śledzenie), a jednocześnie pozwalają im uzyskać pewną konkretność, kiedy opowieści zostaną stworzone?

(Historycznie podczas planowania dzieliliśmy historie użytkowników na elementy pracy, które były następnie indywidualnie szacowane w czasie rzeczywistym , ale mówię tutaj o historiach użytkowników w dzienniku wstecznym, które nie będą miały takiego poziomu szczegółowości ani podziału -na dół.)

Aktualizacja: Mój menedżer miał przeczucie, że istnieje rodzaj krzywej dzwonowej godzin spędzonych na punkcie opowieści, ale dane, które zebrałem i wykresy, które stworzył, całkowicie go zniechęciły do ​​tego pojęcia. :-)

Masz rację, nie ma wzoru na konwersję punktów opowieści na godziny. Możesz uzyskać całkiem bezstratną konwersję metrów na stopy i odwrotnie, ale nie możesz powiedzieć, że historia z 3 punktami zajmie X godzin, więc historia z 5 punktami zajmie Y godzin (rozwiąż dla Y).

HorusKol poruszył następną część. Twoja szybkość sprintu jako zespołu może pomóc w osiągnięciu długoterminowych rezultatów. Załóżmy, że twój zespół ma 50 punktów na sprint, a każdy sprint trwa 2 tygodnie. Zatem 50 punktów na sprint pomnożone przez 50 tygodni w roku (zakładając, że ludzie biorą 2 tygodnie urlopu na wakacje), więc twój obecny zespół może uzyskać maksymalnie 2500 punktów w ciągu 12 miesięcy.

Więc biznes przychodzi do ciebie z historiami i eposami wartymi 170 punktów. Podziel to przez historyczną prędkość zespołu wynoszącą 50 punktów (średnio z każdego dotychczasowego sprintu), a otrzymasz 3,4 sprintu. Ponieważ dokonujemy oszacowania, zaokrąglij to do 4 sprintu: 8 tygodni. Zasadniczo dwa miesiące. Lubię też wziąć ostatnie 3-4 sprinty i dokonać innej oceny. Załóżmy, że Twój zespół w ostatnich 3 sprintach zdobył odpowiednio 53, 67 i 55 punktów. Działa to z 58 punktami, które w tym tempie wynoszą 2,9 sprintu - czyli w zasadzie 3 sprinty. Wygląda na to, że twoja oś czasu dla tych 170 punktów wygląda na 6 do 8 tygodni.

Poinformuj biznes 2 miesiące. Nie mów im 6-8 tygodni, ponieważ usłyszą tylko „6 tygodni”. Nie mów im nawet 8 tygodni, ponieważ większość miesięcy ma w nich około 4,5 tygodnia, a kiedy ludzie usłyszą „4 tygodnie”, od razu myślą „1 miesiąc”. Gdy szacunek osiągnie około 4 tygodni, staje się 1 miesiąc. Potem pracuj za kilka miesięcy. Jeśli osiągniesz rok lub więcej, to po prostu nie oceniaj tej pracy. To bezcelowe. Za dużo może się zmienić w ciągu roku.

Przekonałem się, że jest to dość dokładny sposób na przeliczenie punktów historii na godziny ... w każdym razie czas.

Otrzymasz różnicę w ilości czasu potrzebnego na ukończenie poszczególnych historii. Niektórzy programiści pracują szybciej niż inni. Umieszczenie wszystkich punktów historii w misce i włączenie miksera do pracy ze średnimi pomaga złagodzić te niekonsekwencje.

Aha, i nie zapomnij najważniejszej części:

Podsumowanie. Zawsze.

Prawdopodobnie masz już nieodłączną konwersję z punktów historii do oszacowań czasu - jak zdecydujesz, że wybrałeś wystarczająco dużo pracy do sprintu? Prawdopodobnie powiedziałeś coś takiego: „zespół może obsłużyć 20 (lub 40 lub cokolwiek) punktów tygodniowo”. Po kilku sprintach powinieneś być w stanie to zrewidować na podstawie ukończenia - teraz jest to 15 lub 25 (lub 35, 50 lub ...) punktów sprintu - to prędkość twojej drużyny .

W przypadku opowieści użytkowników 1-SP istnieje oczywiście duże uprzedzenie do bardzo krótkich okresów czasu (z okazjonalnym powiększeniem), ale szczególnie w przypadku opowieści 2-SP są one wszędzie: współczynnik 20 pomiędzy „najszybszymi” i „najwolniejszymi” ukończeniami. W przypadku opowieści 3, 5 i 8-SP spread jest również większy niż współczynnik 2.

Pewne różnice w czasie do ukończenia określonych historii są w porządku w wartościach punktowych - prędkość opiekuje się tą niepewnością, będąc średnią w porównaniu z najnowszą historią.

Jednak może być konieczne dokładne przyjrzenie się, w jaki sposób przypisujesz punkty, szczególnie te 2-punktowe, jeśli masz tak duże wahania. Zadania z wyższymi punktami powinny być niepewne (i powinny zostać rozbite) - ale zadania tak małe jak 2-wskaźnik powinny być dość spójne.

Ponieważ wszystkie zadania, którym przypisano tę samą wartość punktową, powinny wymagać podobnego wysiłku, nie ma sensu, aby przedział czasu był taki sam.

Spójrz więc na 2-punktowy wskaźnik, który zajął najdłużej w twojej retrospekcji. Dlaczego coś, co prawdopodobnie powinno być rano, zamieniło się w 10-dniowy slog? Czy pierwszego dnia rano można było oznaczyć coś, co mówi „to musi być epickie i podzielone na mniejsze zadania”? Jak tylko to się stanie, oczywiście dodatkową pracę należy włożyć do zaległości i nie zakłócać reszty sprintu.

Spróbuj także zobaczyć, jak zespół nie docenił tego elementu - czy mógłbyś zrobić to lepiej, oceniając go w przyszłości?

Tak, data dostawy zostanie odpowiednio przesunięta lub lista funkcji aktualizacji może zostać zmieniona, aby dostawa nie uległa zmianie. Ale celem jest poprawa przyszłych oszacowań punktów, a także uzyskanie dokładniejszej osi czasu.

To jest jak prognoza pogody: im dalej, tym mniej wiarygodne. To jest analogia, którą każdy zrozumie. Błędy w oszacowaniach sumują się.

Sprzedaż musi nauczyć się rozmawiać z klientami po Scrumie. Scrum nie ma sensu w izolacji, powinien być stosowany pionowo w całej firmie i najlepiej rozszerza się na obszar klienta.

Jako zespół programistów powinieneś być w tym stanowczy. Możesz dać im oczekiwania i domysły, ale nie pozwól, aby były to zobowiązania przedłużające pojedynczy sprint.

Robię kilka rzeczy, gdy otrzymuję takie pytania.

Po pierwsze odpowiadam na pytania dotyczące przyszłości, opisując przeszłość. Powiedziałbym coś takiego : Przebywamy około dwóch takich opowieści tygodniowo. Jeśli więc nic się nie zmieni, spodziewamy się, że historia 27 zakończy się za około 14 tygodni.

Po drugie, chcę, aby klienci stojący przed klientami wzięli odpowiedzialność za harmonogram handlu kontra ryzyko. Powiedziałbym, że pamiętaj, że zespół inżynierów działa na podstawie szacunków 50/50. Jeśli nic się nie zmieni, istnieje szansa 50/50, że funkcja 27 będzie gotowa w ciągu 14 tygodni. Prawdopodobnie nie chcesz zgłaszać klientowi czegoś z takim poziomem ryzyka. Czy chcesz, żebym opracował szacunek, do którego mamy, powiedzmy, 90% zaufania? Musisz wtedy przejrzeć swoje historyczne dowody i powiedzieć coś w stylu: Istnieje 90% szans, że historia 27 zostanie ukończona w ciągu 25 tygodni .

Na koniec przypomnij swojemu koledze, że kiedy podejmie zewnętrzne zobowiązanie, firma zostaje przypięta. Składanie zewnętrznych obietnic dotyczących historii nr 27 odbiera całą zwinność firmy. Będziesz wtedy zaangażowany w określony sposób działania. Za każdym razem, gdy ktoś przychodzi do Ciebie z prośbą o zmianę, musisz teraz odpowiedzieć. Postanowiliśmy zakończyć historię 27 przed datą x. Mogę wprowadzić tę zmianę tylko wtedy, gdy skontaktujesz się z klientem i powiesz mu, że nasze zobowiązanie nie jest już ważne. Zasadniczo podejmowanie konkretnych zobowiązań do pracy na ponad miesiąc w przyszłości wiąże się z wieloma problemami.

Masz już (bardzo prymitywną) konwersję:
sprinty Scrumowe (zwykle) są dwa tygodnie.
Wiesz, że możesz dokończyć, powiedzmy, około 20 punktów fabularnych funkcji w ciągu tych dwóch tygodni (lub jak inaczej określisz, ile i ile funkcji spakuje się w jednym sprincie?), A twoje poprzednie sprinty potwierdzają tę ocenę (powiedzmy w ostatnich pięciu sprintach ukończyłeś 18, 21, 23, 19 i 20 punktów fabularnych.

Załóżmy, że cecha X (i wszystkie jej zależności) została oszacowana na 47 punktów historii.
Możesz więc oszacować, że jeśli stwierdzisz, że wdrożenie tego ma najwyższy priorytet, powinieneś wziąć około 3 sprinty, tj. 6 tygodni (ale upewnij się, że twoje szacunki biorą pod uwagę, kto może to zrobić - jeśli 35 z tych punktów jest DB, a ty masz tylko w przypadku faceta DB musisz skorygować swoją szacunkową prędkość, aby to uwzględnić).

To powiedziawszy - zdecydowanie informujcie, że są to przybliżone dane szacunkowe - istnieje powód, dla którego sprinty trwają dwa tygodnie, a nie sześć. Im więcej rzeczy ma do powiedzenia zapowiedź, tym więcej niepewności i błędów wnika. Również mocno komunikuj koszty - tj. Że oznaczałoby to nadanie zadania najwyższego priorytetu, co oznacza, że ​​żadne inne zadania nie zostaną wykonane. W przeciwnym razie możesz napotkać scenariusz:

„Kiedy funkcja Y zostanie ukończona?”
„Jeśli skupimy się na tym w ciągu… 12 tygodni”
„ 12 tygodni?!? Powiedziałeś, że zajmie to 4”.
„Tak, ale powiedziałeś nam, abyśmy priorytetowo potraktowali funkcję X , która, jak powiedzieliśmy, będzie wiązać wszystkie nasze zasoby i zajmie 8 tygodni”.
„Czy nie możesz jednocześnie pracować nad funkcją X i Y ?”
„ jęk ”

Sprint jest zdefiniowany czas, powiedzmy 2 tygodnie. Nie możesz przewidzieć, że jakaś historia zostanie ukończona dalej niż 2 sprinty, tak jak masz aktualny i następny. Zakładam, że przygotowałeś historie, które są omawiane z zespołem na kolejny sprint i które były traktowane priorytetowo przez biznes. Najlepiej jest powiedzieć, że na pewno będą następne 4 tygodnie pracy.

Wszystko, co trwa dłużej niż 4 tygodnie, może ulec zmianie, a firma może opracować mapę drogową, która nie zostanie ustalona w godzinach. Powinno to być zaplanowane na sprint, powiedzmy, epic1 (epicki jak w paczce zgrupowanych opowiadań Jira) i epic2 należy wykonać w sprincie 47 i 48, a epic3 należy wykonać w sprincie 49. Epopeje, które oceniam z grubsza w ciągu kilku godzin sprawdzić, czy jeden lub dwa zmieści się w sprincie, oś czasu i tak się przesunie. Jeśli funkcje nie działają, firma musi ograniczyć zakres lub zaakceptować niedoskonałe rozwiązania, które można później ulepszyć w razie potrzeby (które powinny być zwinne, uwzględniać rzeczywistość zamiast realizować plan).

Możesz zrobić fajną tabelę Gantta (tak wygląda biznes) z przyszłymi sprintami i głównymi tematami / epickimi dla nich.

Lubię wydawać każdy sprint, a następnie przygotowuję wydanie z tym, co zostało ukończone w sprincie (lub rzeczami, które zostały podpisane do wydania przez biznes, chociaż nie były idealne), niedokończone rzeczy przechodzą do następnego sprintu. W ten sposób mam przewidywalną dostawę w ciągu około 2-3 tygodni (jeden tydzień na ewentualne poprawki dotyczące kandydata do wydania).

Takie jest moje doświadczenie z małym zespołem, niewielka liczba zewnętrznych zależności i, moim zdaniem, rozsądny interes. Twój przebieg może się różnić.

W przypadku nowych funkcji oszacowanie wymaganego czasu jest prawie niemożliwe.

Doświadczenie w tworzeniu oprogramowania pokazuje, że w większości przypadków są szczegóły, których nie widać przed rozpoczęciem programowania. W najlepszym przypadku te odłamki mogą wymagać trochę więcej czasu, ale w najgorszym przypadku projekt również może się nie powieść. Powodem tego jest złożoność samego tworzenia oprogramowania.

To jest powód, dla którego SCRUM ocenia tylko złożoność problemu (punkty historii), ale nie czas. Jedyną szansą, jaką masz, jest podzielenie obiektów o dużej złożoności na mniejsze. W ten sposób możesz zminimalizować ryzyko.

Ponieważ oszacowanie czasu jest prawie niemożliwe, nie ma formuły przekształcającej punkty fabuły w oszacowania czasu. Prędkość może być jedynie bardzo przybliżonym oszacowaniem, a nie więcej.

W SCRUM właściciel produktu może zmieniać priorytety elementów zaległości przed każdym sprintem. Dlatego mistrz SCRUM nie może podać żadnych szacunków dla więcej niż jednego sprintu. Nie wie, który element zaległości może stać się ważny podczas następnego sprintu.

SCRUM nie jest metodą robienia rzeczy niemożliwych (planowanie nieplanowalnych) lub przyspieszania rozwoju. Jest to system wczesnego ostrzegania, jeśli kończy się rozwój. Pozwala szybko reagować na nowe wymagania.

Do pierwszego postu:

Jesteś już bardzo dobry, jeśli uda ci się podzielić większość zadań na 1 SP na 5 SP. Oszacowania prędkości mogą być lepsze, jeśli zadania są podobne, a zespół staje się bardziej doświadczony. Ale jeśli zawsze pojawiają się nowe, nieznane części w nowych przedmiotach, musisz żyć z niedokładnością.

Ponieważ programiści zwykle spędzają trochę czasu na pracach niezwiązanych z programowaniem (np. Spotkaniach), nie powinieneś planować z 8 godzinami rozwoju na każdy dzień, ale mniej, np. 6 godzin. Następnie otrzymujesz rezerwę na inne zadania lub elementy pracy wymagające więcej czasu.

Jeśli Twoi współpracownicy chcą mieć dokładne szacunki (co jest sprzecznością samą w sobie), wyjaśnij im nieodłączne problemy związane z tworzeniem oprogramowania. Następnie pokaż im zalety zwinnych metod.