Czy duży wzrost prędkości jest realistyczny w środowisku Scrum?

Mój menedżer ostatnio bardzo dążył do wykorzystania prędkości jako celu i miary wydajności. Obecnie pracujemy ze średnią prędkością 50 punktów fabularnych. Mój menedżer chce, abyśmy zwiększyli go o 40% do 70 punktów historii (bez wzrostu liczby członków zespołu). Jeśli nie osiągniemy tego wzrostu, chce, abyśmy przedstawili pełny podział wyjaśniający dlaczego.

Cały pomysł mierzenia wydajności zespołu według prędkości i używania go jako celu wydaje mi się błędny, ale trudno mi wyjaśnić, dlaczego. Jakaś pomoc? Dlaczego nie jest to właściwy sposób mierzenia i zachęcania do produktywności?

Cóż, zwiększenie prędkości o 40% jest całkowicie proste - wystarczy dodać o 40% więcej punktów do wszystkich swoich oszacowań i wykonać taką samą ilość pracy.

Biorąc pod uwagę, że tak jest, powinno być oczywiste, dlaczego używanie prędkości jako celu jest błędne, po prostu zachęca do zawyżonych szacunków.

Mniej płynną odpowiedzią jest to, że twoje oszacowanie już zakłada, że ​​idziesz tak szybko, jak to możliwe, robiąc wszystko poprawnie. Jedynym sposobem na zwiększenie produktywności o 40% jest albo praca w godzinach nadliczbowych, albo niepoprawne wykonanie wszystkich czynności. Obie te rzeczy przyspieszają w krótkim okresie, ale spowalniają w dłuższej perspektywie. A długoterminowa w tym przypadku nie jest bardzo długa, miesiąc na zewnątrz. Optymalną długoterminową strategią jest nigdy nie iść szybciej niż twoje zrównoważone tempo.

Peopleware wymownie mówi o próbach zmuszenia programistów do zwiększenia wydajności i jest często cytowanym klasykiem. Ale generalnie nie będzie łatwo zmienić zdanie menedżera, który idzie ścieżką, którą jest twój. Twój projekt może mieć kłopoty - z pewnością jest to czerwona flaga.

Jak wskazano w komentarzach, żądanie jest oczywiście błędne w sposobie jego sformułowania. Ale tak naprawdę nie jest w błędzie, jeśli chce ciągle poprawiać wydajność. Z reguły do ​​tego dążą menedżerowie (i są oceniani).

To powiedziawszy, menedżerowie zawsze starają się poprawić wydajność, a Scrum i Agile chcą być elastyczni. Podczas gdy prędkość jest miarą twojego obecnego zrównoważonego tempa, nie powinieneś usiąść na laurach. Scrum ma miejsce do oceny i zmiany tego, co działa, a co nie w twoim procesie: retrospektywa. Jeśli skorzystasz z tego i dostosujesz swój proces, wydajność (i ewentualnie prędkość) powinna wzrosnąć.

Czy więc (w swoich retrospektywach) szukasz sposobów na zwiększenie produktywności jako zespołu? Czy w twoich sprintach jest coś, co regularnie pochłania nieproporcjonalnie dużo wysiłku? Czy można to rozwiązać? Prawdopodobnie nie da ci to 40% wzrostu, ale 5-10% to początek, nie? Podczas każdego sprintu powinieneś szukać wąskich gardeł i zająć się nimi. W końcu możesz zbliżyć się do celu, który dla ciebie wyznaczył.

TL; DR

Prędkość jest bardzo przydatna do szacowania harmonogramów lub generowania wartości planowania, a także może stanowić znaczącą kontrolę detektywną do oceny wąskich gardeł procesu lub zmian w wydajności zespołu. Nie jest to jednak poprawna miara wydajności.

Gdy prędkość jest mylona z celami zarządzania

„Prędkość” to zakres, który wyraża średnią pojemność zespołu w pewnym okresie historycznym. Jest to statystyczna analiza dotychczasowych wyników, która może być następnie wykorzystana do projekcji probabilistycznych szacunków przyszłej wydajności obciążenia lub czasów cyklu. Jest to wyraźny kontrast z „celem planowania”, który jest celem zarządzania, który wyznacza oś czasu lub cel na potrzeby planowania.

Doświadczeni zwinni menedżerowie projektów wiedzą, że właściwe wykorzystanie prędkości polega na ustaleniu, czy zespół ma zrównoważoną zdolność do spełniania zdefiniowanych przez zarząd celów harmonogramu. Czasami odpowiedź brzmi „tak” i wszyscy są szczęśliwi. Czasami odpowiedź brzmi nie, w którym momencie żelazny trójkąt wymusza decyzje biznesowe dotyczące zakresu, kosztów, czasu i jakości.

Oceń swoje opcje polityczne

Mamy średnią prędkość 50 punktów opowieści ... Poproszono mnie o zwiększenie jej o 40% do 70 punktów opowieści (bez wzrostu liczby członków zespołu).

Zakładając, że twoje praktyki szacowania są prawidłowe i że twoja prędkość jest względnie stabilna, twój menedżer nie będzie czerpał radości z dostosowywania skali szacunkowej lub ustalania celów zarządzania nieopartych na wynikach historycznych. Jak słusznie zauważyłeś, jest to zasadniczo problem z pojemnością .

Limit pojemności może być związany z liczbą osób w zespole lub może ograniczać procesy organizacyjne. Oczywiście dodanie większej liczby osób nie zawsze powoduje zwiększenie rzeczywistej wydajności projektu; zobacz Prawo Brooksa, aby uzyskać więcej informacji na temat tego powszechnego nieporozumienia.

Problem , przed którym stoisz, ma charakter polityczny. Z tonu twojego wpisu wygląda na to, że Twój menedżer chce zobaczyć wzrost wydajności bez wprowadzania rzeczywistych zmian w podstawowej zdolności zespołu. Rozwiązania mają zatem również charakter polityczny i mają w dużej mierze charakter edukacyjny.

Jeśli prowadzisz sklep Scrum, poproś Scrum Master o rozwiązanie tego problemu za pośrednictwem odpowiednich kanałów ramowych. Backlog Grooming i retrospekcje Sprint są często idealnymi okazjami do sprawdzenia i dostosowania się do tego konkretnego problemu.

Jeśli nie jesteś sklepem Scrum, musisz zdecydować, jaki jest właściwy sposób rozwiązania problemów w Twojej organizacji. Jeśli jesteś w dobrych stosunkach ze swoim menedżerem, możesz nawet pożyczyć mu kopię Agile Estimating and Planning dla was obojga do omówienia podczas lunchu.

Jeśli wszystko inne zawiedzie, przygotuj się na marsz śmierci, poprawiając swoje CV i starając się, jak najlepiej, dopóki projekt się nie zapadnie. 68% projektów informatycznych kończy się niepowodzeniem ; chyba że cele zarządzania są solidnie ugruntowane w zdolnościach organizacyjnych, Twój prawdopodobnie będzie jednym z nich.

Nie rozumiem, jaką rolę pełni twój menedżer w zespole Scrum? Czy on jest trenerem? Czy on jest właścicielem produktu?

Jeśli jest w zespole jak trener lub taki (pracuje przy zadaniu rozwojowym), możesz zapytać go, dlaczego nie docenia własnej wydajności, ponieważ wydaje się, że nie było tak w przypadku innych członków zespołu. Jeśli wierzy, że może osobiście założyć o 30 punktów więcej za każdą iterację, pozwól mu to pokazać.

Bardziej prawdopodobne: jest poza zespołem, może właścicielem produktu? Jeśli tak, powinien zrozumieć, że składając tak głupią prośbę, po prostu przestał zwinność.

Podstawową zasadą jest to, że właściciel produktu wyznacza cel, a zespół określa, co można zrobić w iteracji. Nieprzestrzeganie tego prowadzi do klasycznego i dobrze znanego żelaznego kręgu: zasobów, prędkości, cech. Wybierz dwa! Nie możesz wybrać trzech z nich jednocześnie (i pamiętaj: jakość nie jest zmienną regulacyjną, próba przecięcia narożników przez niską jakość jeszcze pogorszy sytuację).

Jeśli nie chce zmieniać obecnego celu, może 40% wzrost wydajności można osiągnąć, rekrutując więcej osób do zespołu? Może zainwestujesz w jakieś szkolenie dla niektórych członków zespołu? Zespoły mogą również zwiększać prędkość w czasie poprzez ciągłe doskonalenie, ale na pewno nie przez arbitralną decyzję.

Próba zmiany prędkości drużyny jest jak próba zmiany wielkości pokoju. Można to zrobić, ale w zasadzie musisz zmienić pokój.

Czy nie masz jakiegoś Mistrza Scrum lub innych ludzi z podstawową wiedzą o Scrumie, którzy mogliby mu to wyjaśnić?

W tym przypadku menedżer obrał niewłaściwy kierunek po otrzymaniu rzetelnego i wiernego szacunku od zespołu. Kierownik powinien zwrócić się do interesariusza i poinformować go, że jego wymagań nie można spełnić w wymaganym czasie. Menedżer / analityk powinien następnie ustalić, które funkcje MUSZĄ zostać uwzględnione, a inne, które mogą poczekać (choćby na kilka tygodni). Jeśli interesariusz jest nierozsądny, może wymagać zaangażowania wyższej kadry kierowniczej, co może być trudne i wymagać całego innego zestawu dyskusji.

Gdybym był na twoim miejscu bym wymyślić szczegółowym przypadku, dlaczego projekt JEST potrwa tak długo, jak szacowano. Spróbuj także zidentyfikować produkty o niskim zwrocie. Znajdź przedmioty, które nie wnoszą dużej wartości i wymagają znacznych wysiłków programistycznych, i uzasadnij usunięcie ich ze sprintu. Wymyśl również iteracyjne podejście, które zapewnia „X” w dniu „Y” i upewnij się, że jest to wykonalne, a następnie wymyśl następującą iterację, która zapewni im pozostałe przedmioty.

Zasadniczo ktoś musi powiedzieć interesariuszowi, czego może oczekiwać przed upływem terminu i że obejmuje on większość jego wymagań. i że w następnej wersji będą mieli pozostałe elementy. Jeśli klient jest zbyt nierozsądny, należy zaangażować wyższe kierownictwo, kierownik powinien być w stanie to zrobić.

Jeśli jednak klient był zbyt obiecany i do tej pory nikt się nie odezwał, będzie to bitwa pod górę. Niestety nie jest to rzadka sytuacja.

Wygląda na to, że masz dwa problemy.

Niepokojące dla ciebie jest to, że pomiar prędkości jest kosztem . To, co naprawdę chcesz poprawić, to wartość . Niestety pomiar wartości oprogramowania jest niezwykle trudny i subiektywny. Jednak nawet niedokładny i subiektywny wskaźnik może być przydatny. Możliwe, że prawdziwym problemem nie jest to, że Twój zespół musi napisać więcej kodu, ale że historie powinny być bardziej wartościowe.

Innym problemem jest to, że w oparciu o twoje konto menedżer spodziewał się 40% wzrostu wydajności. W twoim pytaniu nie podano kontekstu tego żądania. Dobrym pomysłem może być życzeniowe pragnienie, aby Twój zespół się poprawił. Lub może to nie być tak subtelne wskazanie, że twój menedżer uważa, że ​​twój zespół ma słabe wyniki.

edycja: Na podstawie Twojego komentarza sytuacja wygląda źle. Wygląda na to, że twoja firma kładzie podwaliny pod ciebie i twój zespół (być może także twojego kierownika). Proponuję poszukać innej pracy.

Zwolnij go. Innymi słowy, przejdź nad głową i wyjaśnij, że stracił zaufanie do swojego zespołu, i wyjaśnij, że nie ma żadnej wartości dla firmy. Wyjaśnij, że menedżerowie z takim poziomem niekompetencji są znacznie łatwiejsi do zastąpienia niż zespół poniżej.

Nie ma dobrego powodu, aby znosić takiego menedżera, ale nie powinno to automatycznie oznaczać rezygnacji programistów. Z tą firmą niekoniecznie musi być coś nie tak. Napraw ten problem.

Aby zapobiec wszelkim uchyleniom od kierownictwa wyższego szczebla, wyjaśnij, że nie jest to błąd do wybaczenia. Sygnalizuje, że odpowiedzialny menedżer nie rozumie zespołu, którym zarządza. To nie nadaje się do naprawy, ani nie ma takiej potrzeby na obecnym rynku pracy. Menedżerowie są wyjątkowo wymienni, podobnie jak trenerzy sportowi. Właściciele nie zwalniają drużyn.

Teraz może to wyglądać na strategię, która może przynieść odwrót. Ale zastanów się: jeśli wyższe kierownictwo popiera swojego przełożonego niezależnie od tego, i tak już i tak byłbyś na straconej pozycji. Tak więc, jeśli weźmiesz pod uwagę tylko sytuacje, w których nie jesteś już w tej pozycji przegrywania, wynik będzie prawdopodobnie znacznie bardziej pozytywny. Prawdziwe ryzyko polega na tym, że kierownictwo po prostu zwalnia cały zespół, w tym kierownika. Tylko Ty możesz oszacować to ryzyko. Najwyraźniej twoja produkcja jest pożądana, inaczej nie poprosiliby o więcej, ale za jaką cenę?

Z mojego doświadczenia wynika, że ​​bardzo, bardzo trudno było zwiększyć rzeczywistą prędkość zespołu, biorąc pod uwagę, że ani zespół, dziedzina problemowa, ani stos technologii nie ulegają zmianie.

Tam, gdzie udało mi się osiągnąć wzrosty, chodziło o:

• oczyszczanie długów technicznych; upewniając się, że wszystko działa poprawnie (niekoniecznie najnowsza!), że kod jest dobrze przemyślany i że nie ma w systemie nadmiarowości (zduplikowany kod, nieużywany kod itp.)

• ulepszanie praktyk; parowanie tam, gdzie to możliwe (tak, zauważyłem, że to zwiększa prędkość), poświęcanie czasu na agresywne refaktoryzowanie (to samo!) i bycie bezwzględnym w kwestii zakresu i skupienia

• znalezienie i / lub zakup najlepszych narzędzi do pracy (np. ReSharper dla .NET jest na wagę złota, Airbrake i Splunk dla rozwoju Ruby itp.)

Zgadzam się z innymi tutaj, którzy twierdzą, że twój menedżer żądający arbitralnego zwiększenia prędkości jest czerwoną flagą. Szukałbym innej pracy o wysokim priorytecie.

Twój kierownik prosi (lub każe) zespołowi, aby przepracował dodatkowe godziny. Podczas gdy usuwanie wąskich gardeł i zwiększanie wydajności może nieco poprawić twoją prędkość, jedynym sposobem na uzyskanie tego wzrostu (40%) jest praca przez dłuższe godziny, ponieważ w tym czasie musisz włożyć więcej jednostek pracy.

Weźmy scenariusz.

Na dwutygodniową interakcję powiedzmy 10 dni. Utopia trwałaby 8 godzin dziennie, a punkt historii zostałby streszczony na dzień pracy. Tak więc, z góry, twoja szybkość wyniosłaby 8. Ale relistycznie ludzie prawdopodobnie dostają 6 dobrych godzin dziennie z e-mailem, spotkaniami, przerwami w łazience itp. Więc teraz masz 6 za każdego programistę. Więc twoja linia bazowa to 6. Powiedzmy, że chcesz, aby ludzie pracowali w godzinach nadliczbowych, teraz o 10 godzinach dziennie. To byłoby 10 punktów prędkości na programistę.

Twoja prędkość zawsze będzie się zmieniać, być może była niska, ponieważ musiałeś poradzić sobie z wieloma błędami podczas tej iteracji, być może brakowało wymagań, może ktoś zachorował na kilka dni. Może była wysoka, ponieważ praca była przeszacowana lub twój zespół spędził dodatkowe godziny.

Ale jeśli masz stabilne 50, naprawdę osiągnięcie 70 będzie wymagało dodatkowych godzin.

Problem z prędkością polega na tym, że jest to zmienna zależna, mierzona moc wyjściowa twojego procesu rozwoju. Wymaganie zwiększenia prędkości o 40% przypomina próbę wcześniejszego rozpoczęcia pracy, krzycząc na samochody, aby jechały szybciej. Prędkość zwiększa się poprzez podawanie większej ilości paliwa i powietrza do silnika lub uzyskanie szybszego samochodu, a także znalezienie trasy o mniejszym natężeniu ruchu.

Więcej godzin pracy nie zwiększa prędkości, jeśli odpowiednio ją zmierzysz, powiedzmy w punktach funkcji na godzinę programisty. Działa tylko wtedy, gdy mierzysz punkty dziennie, a następnie redefiniujesz, co oznacza „dzień” w połowie pomiaru. To tylko złudzenie prędkości.

Wzrost prędkości wymaga poprawy zmiennych niezależnych w procesie tworzenia; szybsze komputery i kompilatory, bardziej wydajny system kompilacji, lepszy proces projektowania, bardziej zdolni programiści, lepszy obszar roboczy, motywacja super duplikatów. 40% poprawa wymagałaby bardzo znaczących zmian.

Zapytaj, czy Twój menedżer rozważyłby ulokowanie zespołu w zamkniętych biurach wokół wspólnego warsztatu, zakup zespołu zupełnie nowego sprzętu deweloperskiego lub zatrudnienie kilku naprawdę starszych deweloperów, aby mentorowali zespół, jeśli to zapewni mu jego 40%. Jeśli nie ma dostępnych zasobów, aby ulepszyć wkład w proces tworzenia oprogramowania, to prawie wyklucza szczere zainteresowanie ulepszeniem. To pozostawia menedżerowi odwrotną inżynierię, aby dowiedzieć się, co go tak naprawdę motywuje, co byłoby przedmiotem całego „innego wątku”.

Cóż, jestem nieco zaskoczony, że inne odpowiedzi traktują poważnie prośbę szefa. Ktoś, kto żąda 40-procentowego wzrostu wydajności, nie wie o rozwoju oprogramowania.

Nadal lubię czytać Phila Factora na ten temat:

Istnieją dwie podstawowe ścieżki zarządzania IT. Możesz uczyć się zawodu poprzez krew, pot i łzy i stopniowo wspinać się po drabinie, w oparciu o wiarygodność, którą zyskałeś dzięki ciężko wypracowanej wiedzy technicznej i udanym projektom. Ewentualnie możesz założyć ostry garnitur i krawat, nauczyć się żargonu i płynnie mówić o swojej drodze na szczyt.

Obie trasy wydają się równie skuteczne. Radzenie sobie z tą ostatnią rasą z pewnością może powodować pewne chwile konsternacji i niedowierzania… nawet rozpaczy… a niektóre z nich są udokumentowane w tych historiach.

Łatwo jest jednak odczuwać smutek i rozgoryczenie, gdy napotyka się techniczną niekompetencję na stanowiskach władzy, i smołować wszystkich menedżerów tym samym pędzlem. Phil odradza to. Większość menedżerów ciężko pracuje i dobrze przyczynia się do rozwoju firmy, a nawet biedni menedżerowie mogą zostać przeszkoleni do wymaganego standardu, jeśli zastosują się do kilku prostych wskazówek. Obowiązkiem zespołu jest pomaganie menedżerowi w funkcjonowaniu w sposób, który przyniesie korzyści wszystkim.

Ostatecznie, jeśli nie możesz ich wyszkolić, awansować lub ich uniknąć, być może możesz nauczyć się ich kochać tylko za ich niezamierzony wkład w bogatą komedię w miejscu pracy.

Rada, aby nie stać się „smutnym i rozgoryczonym” jest najlepszym, co możesz dostać. Nie walcz z technicznie niekompetentnym szefem w sprawach technicznych. Po prostu zobaczy to jako osobisty atak.

Twój menedżer źle zrozumiał użycie prędkości. To nie jest metryka i nie jest celem. Jego celem jest kalibracja obciążenia pracą zespołu na sprint.
Jeśli się nad tym zastanowić, twoja prędkość wyłania się z najlepszego przypuszczenia, które oceniasz po każdym sprincie. Zwykle w miarę upływu czasu powinien on być nieco stabilny. Ale to nie zmienia faktu, że jest to produkt uboczny tego, co faktycznie robi Twój zespół: tworzenie wartości dla klientów.

Powodem, dla którego niewłaściwe jest używanie go jako celu i / lub metryki, jest spowodowane tym, że byłaby to marność. Wyglądałby dobrze na papierze, ale nie zrobiłby absolutnie nic, by odzwierciedlić, czy Twoje produkty są w pełni zaspokojone przez Twoich klientów. I to jest najważniejsze (mam nadzieję).

Odnośnie mojego doświadczenia i od razu do rzeczy.

Po pierwsze, możesz zawyżać szacunki, ale to nie znaczy, że robisz więcej.

Drugi (przesłanka: bez nadmuchiwania, po prostu skupianie się na prędkości drużyny),

Spróbuj znaleźć umiejętności w swoim zespole. Czy pracują nad tym, co są najlepsze? Czy potrzebujesz architekta systemów, aby podejmować trudne decyzje dotyczące budowy aplikacji i skomplikowanych rzeczy? Jak zespół wydaje wysiłki? Spędzają czas na poszukiwaniu rozwiązań swoich problemów, refaktoryzacji, podejmowaniu decyzji biznesowych czy co?

Czy są wygodne, skoncentrowane i oszacowane? Co dalej dla nich?

To nie jest „jestem zepchnięty na granice”… to raczej pytanie dla całego zespołu „Czy jesteśmy na limicie?” i „Jak możemy przekraczać granice?” ...

Mam wiodące zespoły o wysokiej wydajności (do pierwszej budowy i / lub migracji) ... motywacja zespołu jest kluczem do sukcesu ... i planowanie, jak podstawa aplikacji będzie niezbędna. Czasami ja lub zespół otrzymuję rolę architekta systemów i decyduję, w jaki sposób i gdzie „rzecz” powinna iść.

Czasami, gdy widzę, że moi współpracownicy tracą skuteczność, próbuję się przełamać i zaprosić ich na drinka lub coś, co im się podoba. To rozwiązuje wszelkie konflikty i następnego dnia ponownie się koncentrują.

SPRZEDAWANIE...

Jeśli wyjaśnienie powodów, dla których nie można zwiększyć prędkości, jest trudne, użyj ROI.

Scrum koncentruje się na tym, co najważniejsze dla klienta. Teoretycznie najbardziej opłacalne zadania.

Jeśli twoje problemy dotyczą sprzedaży nakładów programistycznych, co według Ciebie sprzedajesz, ile ROI nakładów rozwojowych bezpośrednio zamienia punkty fabularne na „cenę”. Jeśli możesz udowodnić, że Twój zespół pracuje z wysokim zwrotem z inwestycji, to kto cię przesłucha? Ponadto, każdy zespół ma swoje ograniczenia, jeśli zespół znalazł swój „komfortowy rozmiar”, spróbuj z miesiąca na miesiąc nieznacznie zwiększyć, jeśli nie mogą ukończyć wszystkich zadań, jest to (prawdopodobnie) limit.

Pokaż historię zadań, dochód z zysku (jeśli jest dostępny), wykorzystany punkt historii i pokaż, że WYDAJNOŚĆ TO NIE EFEKT ZESPOŁU to obliczenie ustalone przez zespół w celu oceny złożoności i być może czasu na uzyskanie czegoś gotowy