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

89

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?

P2l
źródło
19
łał. menedżer albo nie rozumie, co to jest prędkość, albo myśli, że zespół zwleka. lub obydwa. Na następnym spotkaniu planistycznym przydziel do 70 punktów i pozwól zespołowi powiedzieć mu o ryzyku niepowodzenia, które spowoduje
Steven A. Lowe
25
Wydaje się, że jest to tak szalona prośba, że ​​chciałbym zapytać go, dlaczego uważa, że ​​jest to możliwe - jeśli już dajesz 100%, czy on oczekuje, że dasz 140%? Co jeśli po prostu wykonasz sprinty o 40% dłużej?
Jonathan Rich
20
Prędkość ma być miarą szybkości wykonywania zadań. Jeśli twoja prędkość i punkty fabularne są w ogóle dokładne, oznacza to, że nie możesz ukończyć całego zaległości przed upływem terminu. Racjonalną rzeczą jest zaakceptowanie rzeczywistości i albo wycięcie rzeczy z zaległości, albo ustalenie priorytetów tego, co tam jest, aby to, co robisz, było ważniejsze. Lub możesz zmienić termin na coś realistycznego.
Michael Shaw,
45
Poproś go o 40% wzrost wynagrodzenia, jeśli osiągniesz te cele, a następnie zwiększ swoje prognozy, aby uzyskać wzrost o 40%.
mattnz
18
Czy to nie jest tak, jakby poprosić biegacza maratonu, aby nagle przebiegł maraton w 1h25m zamiast 2h?
Scroog1 17.09.13

Odpowiedzi:

158

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.

psr
źródło
28
Mocno wierzę, że nie ma „szybkiego i brudnego”. „Brudny” zawsze spowalnia mnie - nawet w krótkim okresie.
Doc Brown
1
@Paul - Myślałem, że to dobrze. Ale porady w nim zawarte mogą przeważnie kierować się wyłącznie menedżerami, a ci, którzy mogliby z nich skorzystać, prawdopodobnie nie przeczytają go. Przeczytanie go niekoniecznie zmieni zachowanie.
psr
2
A jeśli się zgodzisz i naprawdę zwiększysz prędkość o 40%, będzie to wyglądało tak, jak inni, że ty i twój zespół nie pracowaliście najlepiej. Profesjonalnym sposobem radzenia sobie z tym jest udzielenie prostej odpowiedzi: „Nie, nie da się”. Kolejne odniesienie do książki na ten temat: „The Clean Coder” Roberta C. Martina.
pablosaraiva
1
„Twój szacunek już zakłada, że ​​idziesz tak szybko, jak to możliwe, robiąc wszystko poprawnie” To prawdopodobnie błędne założenie. Zawsze możemy nadal ulepszać i optymalizować. Zespoły nigdy nie powinny zakładać, że ich stabilna prędkość wskazuje, że nie mogą się polepszyć. Ale muszą systematycznie patrzeć na cały proces i szukać drobnych usprawnień procesu.
Curtis Reed,
53

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ł.

Matthew Flynn
źródło
7
+1: To dobry sposób na opisanie tego menedżerowi. Nie możesz sztucznie zwiększać prędkości, ale możesz spojrzeć wstecz po każdym sprincie i dowiedzieć się, co możesz zrobić, aby być bardziej wydajnym podczas następnego sprintu.
Kevin
3
Szanse są takie, że usunięcie narzutu menedżera (wymuszone spotkania, wypełnianie formularzy itp.) Prawdopodobnie dałoby ci to 5-10%, łatwo. Ale jak go przekonać?
AviD
2
Myślę, że twoja odpowiedź stanowi nieporozumienie dotyczące prędkości. Nie jest to miara bezwzględna, jest to średnia mierzona przez cały czas trwania projektu. Co więcej, same punkty prędkości nie reprezentują wykonanej pracy, ale przybliżone miary złożoności. Są one również wartościami średnimi, a zadanie z niskim punktem może wymagać więcej czasu niż zadanie z wyższym punktem. Proszenie o „więcej” wydaje się trochę pozbawione sensu i stanowi fundamentalne nieporozumienie. Menedżer zasadniczo prosi o ustalony termin.
Ricardo Gladwell,
3
@RicardoGladwell - Kiedy powiedziałem „prośba jest oczywiście błędna”, przyznałem, że błędnie rozumiem, jak działają punkty fabularne. Sugerowałem jedynie, że menedżer naprawdę chce, aby zespół poprawił wydajność, a Scrum zapewnia na to sposób. Istnieją również różne podejścia do tego, co reprezentują punkty historii - złożoność jest jedną z najczęstszych. Większość zespołów, z którymi pracowałem, w pewnym stopniu koresponduje z poziomem wysiłku. Proste zadanie z dużą ilością nie jest już uważane za proste.
Matthew Flynn
1
Wspominacie, że wzrost prędkości o „5-10% to początek”, ale wydaje się, że podziela to nieporozumienie kierownika co do tego, co „wzrost prędkości” oznacza, co zarysowałem.
Ricardo Gladwell
26

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.

CodeGnome
źródło
jakość nie jest zmienną regulacyjną: dlatego mówimy o żelaznym trójkącie, a nie o żelaznym kwadracie. Innymi słowy, gdy ktoś próbuje obniżyć „jakość”, powoduje spustoszenie w opóźnieniach (dłuższe dostawy), zasięgu (funkcje nie działają, a tym samym nie są sprzedawane) ... i zasobach (programiści są sfrustrowani i odchodzą). Dobra odpowiedź obok tego momentu.
kriss
1
@ Kriss Jakość może rzeczywiście być częścią trójkąta. Czasami jest uważany za część „zasięgu” lub w niektórych trójkątach jest to faktyczny wierzchołek wskazujący, że jest to podstawowe ograniczenie. Zobacz konkretny przykład niebieski trójkąt w gwieździe PMBOK lub Ewolucja modelu ograniczenia projektu, aby uzyskać szczegółowe informacje na ten temat. Proszę o więcej informacji na PMSE .
CodeGnome
to jest dyskusja, którą przeprowadziłem już z innymi agilistami. Podsumowując, nie zgadzamy się co do tego, że PMBOK jest ważnym zasobem Agile. Pochodzi z modelu wodospadu i jest ortogonalny do zwinnego. Jest w większości kompatybilny, ale wciąż istnieją pewne problemy. Uwzględnienie jakości jako zmiennej dostosowującej jest jednym. Jak widzę (i nie jestem sam) używanie (próba użycia) Jakości jako zmiennej dostosowującej przerywa cały proces Agile. Ale powinno to być samo z siebie.
kriss
Pytanie zamieszczone tutaj pm.stackexchange.com/questions/11489/…
kriss
21

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

Kriss
źródło
15

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.

hanzolo
źródło
1
problemem mogą być „uczciwe i wierne szacunki”.
JeffO
@JeffO - Być może dlatego zaleciłem uzasadnienie szacunków .. kiedy spróbują to zrobić, albo zdadzą sobie sprawę, że zawyżili swoje szacunki lub że naprawdę nie mają zdolności
hanzolo
9

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.

Aaron Kurtzhals
źródło
3
Niestety była to poważna prośba, sformułowana w stylu: „Nie widzę powodu, dla którego nie możesz tego osiągnąć (ale nie powiem ci, jak!”). Oznacza to, że nie wierzy, że pracują wystarczająco ciężko lub nie są tak kompetentni, jak powinni. Sytuacja pogorszyła się, kiedy nie było mnie na wakacjach, a Właściciel Produktu powiedział zespołowi, że jeśli nie uda się tego osiągnąć, będą miały poważne konsekwencje. Więc teraz mam również bardzo zaniepokojony zespół (który naprawdę uważam za świetny zespół), o który też muszę się martwić.
P2l
4
+1 za „wyjdź z Dodge”. Czasami jest to jedyny sposób (choć im rzadziej, tym lepiej).
Michael
9

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

MSalters
źródło
5
Innymi słowy, podnieście ręce w powietrze, zawodząc i rzuć się napad. Takie podejście nigdy nie rozwiązuje problemów. Istnieją znacznie lepsze sposoby radzenia sobie z sytuacją.
MrFox
Nie. Zawodzenie lub atakowanie to dramatyczne działania. Można to zignorować. To, co proponuję, to ultimatum. Albo ten menedżer idzie, albo zespół idzie. Bez dramatu, tylko zimna logika biznesowa. Nie nadaje się do pracy, a zadaniem kierownictwa jest podjęcie działań. Ale ich preferowaną opcją może być zignorowanie sytuacji, jeśli na to pozwolisz. Dlatego musisz zabrać ten wybór.
MSalters
@nathanhayfield Typowy? Myślę, że zespół składałby się z wielu osobowości i ludzi. Leniwi powinni się zwracać do zespołu indywidualnie, a nie do ogólnej prośby zespołu.
James Khoury
1
@MSalters Istnieje wiele osób w różnych warstwach biznesowych, które nie zrozumieją pewnych rzeczy. Prawidłowe podejście polega na łagodzeniu konfliktów i edukacji wszystkich zaangażowanych osób. Może ten menedżer nie rozumie Agile, ale mogą mieć inne cechy odkupienia (co może być o wiele ważniejsze). Jako profesjonalista powinieneś najlepiej wykorzystywać każdą sytuację i pracować z każdym typem osobowości - ponieważ jest to w rzeczywistości konstruktywne i pomocne w dłuższej perspektywie. Robienie tego, co sugerujesz, nie jest skalowane.
MrFox,
3
@MrFox: Bezpośredni menedżerowie powinni rozumieć harmonogram; w rzeczywistości są warstwą najbardziej bezpośrednio za to odpowiedzialną. Członkowie zespołu powinni być ekspertami merytorycznymi, a kierownictwo wyższego szczebla jest bardziej oddalone od akcji. Więc to menedżer, w miejscu gdzie jest żądających o harmonogramach, dowodzi, że nie rozumie, co jest chyba jego najważniejszym zadaniem. Jeśli rynek pracy był napięty, znalezienie lepszego menedżera może być kłopotliwe. Ale dziś możesz znaleźć kogoś lepszego.
MSalters,
6

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.

Duncan Bayne
źródło
3

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.

Jon Raynor
źródło
2

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”.

SeattleCplusplus
źródło
1

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.

Andomar
źródło
Myślę, że ten rodzaj zależy od subskrybowanego modelu zarządzania. Lider trenera: uznany ekspert, który brudzi sobie ręce i uczy innych, jak być dobrym, ale ogólnie pozostaje „Guru”. Dyrektor ds. Przywództwa: „ekspert”, który wie wszystko (lub myśli, że wie), po prostu wydaje rozkazy i mówi ludziom, co należy zrobić. Przywództwo delegowane: może nie być ekspertem, ufa swojej wiedzy specjalistycznej i ułatwia. Wspierające przywództwo: cheerleaderka grupy pomaga je budować, motywuje, przekonuje zespół, że mogą to zrobić i pomaga im to osiągnąć.
Curtis Reed,
0

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ę).

Stefan Billiet
źródło
o ile wiem, jest to już wyjaśnione w innej odpowiedzi : „zakres, który wyraża średnią wydajność zespołu w pewnym okresie historycznym. Jest to analiza statystyczna wcześniejszych wyników, którą można następnie wykorzystać do prognozowania prawdopodobieństwa przyszłych obciążeń pojemność lub czasy cyklu ... ”
komnata
@gnat częściowo, tak, choć ta odpowiedź nie mówi nic o używaniu prędkości jako miernika próżności, co jest nadal ważne, ponieważ dla wielu menedżerów robi się głupie rzeczy w oparciu o liczby proxy. OP powiedział, że czuł, że to źle, ale nie potrafił tego wyjaśnić. Czułem, że metryka próżności (od The Lean Startup) daje dobre wyjaśnienie.
Stefan Billiet
-1

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

Marcos Lima
źródło