Prędkość z czasem nie osiąga plateau, dlaczego?

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?

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.

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ą?

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?