Narysowałem wykres spalania mojego zespołu i jego prędkość na iterację. Dla mnie wygląda to naprawdę źle (prędkość bardzo się zmienia). Czego powinienem szukać, aby zdiagnozować podstawową przyczynę tego zachowania?
Dlaczego źle to wygląda? Większość projektów zaczyna się od szeregu łatwych do rozwiązania problemów, a następnie grzęźnie później, ponieważ niektóre początkowe założenia okazują się błędne i muszą zostać poprawione, aby rozwiązać późniejsze problemy.
Blrfl
1
Twój zespół ma 1000 punktów za sprint?
Bryan Oakley
@BryanOakley Wygląda bardziej jak 100 punktów / sprint. Najwyższy wiersz to „skumulowana wartość”.
Caleb
„Punkty” są celowo arbitralne - nawet jeśli jest to 1000 punktów na sprint, może to po prostu oznaczać, że jeden punkt może wynosić dziesięć osobo-minut lub coś w tym rodzaju.
tdammers
1
@KirkBroadhurst Patrz uważnie. Linia oznaczona „Velocity” w kluczu jest jednolicie czarna i odpowiada dolnej linii na wykresie. Linia oznaczona „Acc. Wartość ”w kluczu jest szara, podobnie jak górna linia na wykresie. Można również stwierdzić przez kontrolę, że górna linia jest prawdopodobnie bieżącą sumą dolnych punktów danych: linia jest płaska w tygodniach, gdy dolna linia jest bliska zeru (sprinty 6, 9, 15 ...), ma stałe nachylenie, gdy dolna linia jest płaska (sprinty 3-6, 10-13) i nigdy się nie zmniejsza.
Caleb
Odpowiedzi:
20
To zupełnie normalne, że wahania zachodzą podczas pierwszych dziesięciu sprintów, podczas gdy zespół znajduje swój rytm. Potem jest zupełnie normalne, że prędkość oscyluje wokół średniej. Spróbuj wykreślić średnią bieżącą z ostatnich pięciu sprintów i powinieneś ją wyrównać. Jeśli nie, przyczyną mogą być niektóre z poniższych:
Zespół próbuje skorygować swoje oszacowania punktów opowieści w oparciu o ich ostatnią prędkość, zamiast utrzymywać stałe punkty opowieści i dostosowywać liczbę opowieści, które podejmują.
Nie dzielisz historii na wystarczająco małe.
Zbyt wiele twoich opowieści jest w wyższych szczegółach. Na przykład masz dużo 20 wskaźników, których nie chcesz zmienić na 13 lub 40.
Masz wiele historii o kacu, które nie do końca kończą się jednym sprintem.
Co do opowieści o kacu? Zwłaszcza jeśli sprint zostanie „ukończony” przez co najmniej część zespołu, a następnie będą musieli przeciągnąć historię z sprintu na kilka dni przed końcem sprintu. Z tego, co mi powiedziano, „to się uśrednia”. Czy to nie jest właściwy sposób myślenia?
Earlz
Osobiście „uśrednianie” jest dla mnie w porządku, a mój zespół scrumowy się z tym zgadza. Inne zespoły robią takie rzeczy, jak podwójne sprawdzanie gotowych opowieści, dodawanie dodatkowych testów, dzielenie opowieści na mniejsze kawałki lub dogryzanie opowieści, aby uniknąć kaca, a to jest bardziej zgodne z „czystym scrumem”.
Karl Bielefeldt
Czy jest to jednak coś złego? Na przykład wielokrotnie podejmujemy zobowiązanie wyłącznie na podstawie prędkości. Zatwierdzenie obejmie wiele trwających historii, a następnie w razie potrzeby przeciągniemy historie do sprintu (i jest to zaplanowane i oczekiwane).
Earlz
Jest źle, jeśli Twój kod nie jest w stanie możliwym do wysyłki na końcu sprintu. Puryści Scrumowi uważają, że planowanie wciągnięcia historii do sprintu jest z zasady złe, nawet jeśli kod można wysłać na koniec sprintu. Osobiście uważam, że dostosowanie procesu do twojego zespołu nie jest złe.
Karl Bielefeldt
4
Nadużywasz prędkości jako wskaźnika wydajności, tak jakby pewna liczba zaakceptowanych punktów historii była „dobrym” sprintem, a cokolwiek mniejszego niż „zły” sprint.
Prędkość (która jest strasznie źle nazwaną koncepcją) powinna być wykorzystywana jako narzędzie wybiegające w przyszłość do oszacowania, ile funkcji zespół może zatwierdzić podczas następnego sprintu, tj. Prędkość należy wykorzystać do planowania przepustowości.
Oto istotny cytat z artykułu: „Problemem jest waga przypisywana prędkości i przekształcanie jej w miarę produktywności”.
Może występować problem z tym, co wygląda na znaczną zmienność prędkości. Nie oznacza to, że zespół robi coś złego, ale efektem jest to, że nie można bardzo dobrze przewidzieć zdolności zespołu do przyszłych sprintów. Niestety, nie jest to pytanie, na które każdy z nas może odpowiedzieć za ciebie. Musisz zagłębić się w temat z perspektywy czasu. Co się naprawdę dzieje
W każdym razie na wykresie brakuje najbardziej krytycznej miary. Jak dobrze zespół radził sobie z dostarczaniem wartości, do której się zobowiązał? Czy prędkość zmienia się, ponieważ przekracza swoje zaangażowanie w niektórych sprintach, ale nie w innych, czy zmienia się, ponieważ nie kończą opowiadań, czy też zmienia się, ponieważ zobowiązania również się zmieniają?
Dodatkowa potencjalna przyczyna: podczas późniejszych sprintów spłacasz dług techniczny z wcześniejszych sprintów.
Np. Masz demo zarządzania po sprincie 3 i musisz pokazać scenariusz z okazji dnia szczęśliwego. Aby to zrobić, wykonujesz kodowanie bez obsługi błędów, bez obsługi tłumaczenia, bez testowania jednostkowego. To ważna decyzja, musisz tylko mieć świadomość konsekwencji.
Później dodajesz wszystkie fajne rzeczy, takie jak frameworki obsługi ekscytujące, obsługa tłumaczeń, framework testów jednostkowych i tak dalej. Twoje obecne kodowanie z pierwszych 3 sprintów jeszcze tego nie wykorzystuje, więc musisz je zaktualizować. Wysiłek ten spowalnia tworzenie wartości podczas późniejszych sprintów.
W przypadku twojego pytania trudno jest stwierdzić, dlaczego ma on wahania, ponieważ może to wynikać z karty opowieści, ludzi w zespole lub możliwości właściciela produktu. Z mojego doświadczenia wynika, że prędkość będzie się zmieniać, ponieważ na przykład:
Twój członek zespołu może nie być oddanymi członkami zespołu. Aby pracować i rozumieć się nawzajem, muszą współpracować wystarczająco długo. Jeśli twoja drużyna często zamienia ludzi w drużynie, to dynamizuje ją i wpływa również na szybkość.
Karty opowieści są za duże. Tak więc zespół nie może szczegółowo omawiać planów / oszacowań. Podczas sprintu przekonają się, że coś jest trudniejsze niż im się wydaje.
Chyba robisz scrum. W scrumie musimy wykonać część 1 planowania sprintu (właściciel produktu decyduje, co robić) i część 2 planowania sprintu (zespół decyduje, ile mogą zrobić). Może się tak zdarzyć, że po tym, jak właściciel produktu wybierze karty do sprintu, zespół nie zagłębia się wystarczająco szczegółowo w część 2 planowania sprintu, aby nie mogli znaleźć ukrytego problemu, o którym muszą powiadomić właściciela produktu. Jeśli na początku znajdą problemy, złamią je LUB pomyślą, jak pozbyć się ryzyka. To sprawia, że oszacowanie jest wystarczająco poprawne przed rozpoczęciem pracy nad sprintem.
Jeśli karty opowieści nie są szczegółowo opisane, oszacowanie nie będzie dokładne. Ocena na początku może być trudna, ale przed rozpoczęciem sprintu lub zanim karty opowieści trafią do sprintu, należy je podzielić i wyjaśnić na tyle, aby uzyskać prawie prawidłowe oszacowanie. Pomaga to w większej stabilności zespołu.
Właściciel produktu może nie być w stanie wyjaśnić wystarczająco kart historii przed rozpoczęciem sprintu. Jest to również bardzo ważna rzecz, ponieważ jest to celem zespołu do pracy w ciągu tych 2 tygodni. Jeśli właściciel produktu po prostu wybierze kartę do sprintu, a zespół jeszcze jej nie rozumie, i tak muszą ją zrozumieć podczas sprintu, a odpowiedź może się okazać, że ma więcej niż dyskutowano, a ocena jest błędna. To wyraźnie wpływa na prędkość.
itp...
W każdym razie moim zdaniem fluktuacja prędkości nie jest ważna, o ile wiemy, jaka jest sytuacja na każdym sprincie. Velocity to po prostu informacja, jak stabilny może pracować Twój zespół. Jeśli nie jest stabilny, musimy szczegółowo dowiedzieć się o każdym sprincie o tym, co się stało. To tylko sposób na wyjaśnienie / sprawienie, aby problem się pojawił, dzięki czemu jesteśmy w stanie go naprawić. Prędkość powiedz nam, co się działo w tym sprincie, abyśmy mogli cofnąć myśl i poprawić ją, aby była stabilna. Prędkość jest projekcją projektu. A fluktuacja prędkości nie oznacza, że zespół nie może dostarczyć produktu, po prostu pomaga myśleć o projekcji w przyszłości i o problemach, które należy rozwiązać, aby wszystko było płynne.
Twoja prędkość ma hałas (fluktuacje). Możliwe przyczyny:
Historie są zbyt duże i dość często historia w połowie ukończona jest przenoszona do następnego sprintu.
Historie nie zostały dokładnie oszacowane. Przyczyną może być niedoświadczony zespół lub zbyt duże historie.
Ten hałas niekoniecznie jest sam w sobie problemem: hałaśliwa prędkość, która oscyluje wokół stałej średniej, wciąż pozwala na dokładne planowanie uwolnienia.
Jeśli jednak odfiltrujesz hałas (średnia krocząca z 5 kolejnych sprintu), twoja prędkość nadal spada po 20 sprintach. Utrudnia to planowanie wersji i warto zbadać:
Czy „definicja ukończenia” jest zbyt słaba, a zespół gromadzi resztki pracy z poprzednich sprintów?
Czy organizacja lepiej radzi sobie z przekierowywaniem scrum i narzucaniem zespołowi zaległych prac?
Duże historie (epopeje) na dole dziennika zostały ocenione bardziej optymistycznie niż bardziej szczegółowe historie na górze?
Odpowiedzi:
To zupełnie normalne, że wahania zachodzą podczas pierwszych dziesięciu sprintów, podczas gdy zespół znajduje swój rytm. Potem jest zupełnie normalne, że prędkość oscyluje wokół średniej. Spróbuj wykreślić średnią bieżącą z ostatnich pięciu sprintów i powinieneś ją wyrównać. Jeśli nie, przyczyną mogą być niektóre z poniższych:
źródło
Nadużywasz prędkości jako wskaźnika wydajności, tak jakby pewna liczba zaakceptowanych punktów historii była „dobrym” sprintem, a cokolwiek mniejszego niż „zły” sprint.
Prędkość (która jest strasznie źle nazwaną koncepcją) powinna być wykorzystywana jako narzędzie wybiegające w przyszłość do oszacowania, ile funkcji zespół może zatwierdzić podczas następnego sprintu, tj. Prędkość należy wykorzystać do planowania przepustowości.
http://jimhighsmith.com/velocity-is-killing-agility/
Oto istotny cytat z artykułu: „Problemem jest waga przypisywana prędkości i przekształcanie jej w miarę produktywności”.
Może występować problem z tym, co wygląda na znaczną zmienność prędkości. Nie oznacza to, że zespół robi coś złego, ale efektem jest to, że nie można bardzo dobrze przewidzieć zdolności zespołu do przyszłych sprintów. Niestety, nie jest to pytanie, na które każdy z nas może odpowiedzieć za ciebie. Musisz zagłębić się w temat z perspektywy czasu. Co się naprawdę dzieje
W każdym razie na wykresie brakuje najbardziej krytycznej miary. Jak dobrze zespół radził sobie z dostarczaniem wartości, do której się zobowiązał? Czy prędkość zmienia się, ponieważ przekracza swoje zaangażowanie w niektórych sprintach, ale nie w innych, czy zmienia się, ponieważ nie kończą opowiadań, czy też zmienia się, ponieważ zobowiązania również się zmieniają?
źródło
Dodatkowa potencjalna przyczyna: podczas późniejszych sprintów spłacasz dług techniczny z wcześniejszych sprintów.
Np. Masz demo zarządzania po sprincie 3 i musisz pokazać scenariusz z okazji dnia szczęśliwego. Aby to zrobić, wykonujesz kodowanie bez obsługi błędów, bez obsługi tłumaczenia, bez testowania jednostkowego. To ważna decyzja, musisz tylko mieć świadomość konsekwencji.
Później dodajesz wszystkie fajne rzeczy, takie jak frameworki obsługi ekscytujące, obsługa tłumaczeń, framework testów jednostkowych i tak dalej. Twoje obecne kodowanie z pierwszych 3 sprintów jeszcze tego nie wykorzystuje, więc musisz je zaktualizować. Wysiłek ten spowalnia tworzenie wartości podczas późniejszych sprintów.
źródło
W przypadku twojego pytania trudno jest stwierdzić, dlaczego ma on wahania, ponieważ może to wynikać z karty opowieści, ludzi w zespole lub możliwości właściciela produktu. Z mojego doświadczenia wynika, że prędkość będzie się zmieniać, ponieważ na przykład:
W każdym razie moim zdaniem fluktuacja prędkości nie jest ważna, o ile wiemy, jaka jest sytuacja na każdym sprincie. Velocity to po prostu informacja, jak stabilny może pracować Twój zespół. Jeśli nie jest stabilny, musimy szczegółowo dowiedzieć się o każdym sprincie o tym, co się stało. To tylko sposób na wyjaśnienie / sprawienie, aby problem się pojawił, dzięki czemu jesteśmy w stanie go naprawić. Prędkość powiedz nam, co się działo w tym sprincie, abyśmy mogli cofnąć myśl i poprawić ją, aby była stabilna. Prędkość jest projekcją projektu. A fluktuacja prędkości nie oznacza, że zespół nie może dostarczyć produktu, po prostu pomaga myśleć o projekcji w przyszłości i o problemach, które należy rozwiązać, aby wszystko było płynne.
źródło
Twoja prędkość ma hałas (fluktuacje). Możliwe przyczyny:
Ten hałas niekoniecznie jest sam w sobie problemem: hałaśliwa prędkość, która oscyluje wokół stałej średniej, wciąż pozwala na dokładne planowanie uwolnienia.
Jeśli jednak odfiltrujesz hałas (średnia krocząca z 5 kolejnych sprintu), twoja prędkość nadal spada po 20 sprintach. Utrudnia to planowanie wersji i warto zbadać:
źródło