Czy targowanie się i podważanie prób oszacowania Scruma jest uzasadnioną częścią tego procesu?

Zauważyłem na spotkaniach scrum, że programiści często podają realistyczne oceny historii. Jednak nawet dość proste historie wymagają wiele wysiłku w zakresie konfiguracji, konfiguracji komponentów stron trzecich, testowania i ostatecznej kompilacji, a system ma dość techniczny dług, więc szacunki często wydają się zbyt wysokie dla właściciela produktu lub kierownictwa.

Organizacja producentów często próbuje obalić takie szacunki, takie jak: „Co, chcesz 13 punktów historii [4 dni] dla tej historii, to nie może być! Nie mogę tego wytłumaczyć kierownictwu, ktoś powinien być w stanie to zakodować z 3 SP [w ciągu 4 godzin]! ”. W rezultacie programiści przekręcają ramiona, aby dokonać oceny 5 lub 8 punktów historii [1,5 do 2 dni] (szacunki Scrum są nadal traktowane jako zobowiązania, a nie tylko prognozy).

Oczywiście, bez żadnego planu ograniczenia oczekiwań (głównie w zakresie testowania i jakości), te sprinty często zawodzą. Szacunek twórców jest szczery, realistyczny, a pokonanie szacunku nie przebije faktycznej pracy do wykonania.

Można powiedzieć: „Nie powinieneś podejmować niemożliwego zobowiązania, tylko dlatego, że ktoś cię do tego zmusza!” Ale moim zdaniem zadaniem programisty jest projektowanie i kodowanie oprogramowania, a nie targowanie się i przeciwstawianie się presji! Mogą istnieć gniazda wszystkich transakcji, zazwyczaj tych, które mają bezpośredni kontakt z klientami zewnętrznymi, ale nie jest to większość programistów biurowych!

Dla mnie ta praktyka sprawia, że ​​programiści wyglądają jak szarpnięcia, powodują ciągłe niepowodzenia sprintu i uniemożliwiają realistyczne oszacowania, a także szukają faktycznych ulepszeń.

Co mówią wytyczne Scrum na ten temat lub czy coś na ten temat mówią?

EDYCJA: czasy zastąpione punktami opowieści. Miałem na myśli wstępną fazę oceny z Planning Poker i punktami fabularnymi, a nie szczegółowe planowanie zadania. Po prostu wprowadzam tam dni / godziny, ponieważ czasami był to typowy dialog, także z czasem zamiast punktów. Przepraszam za zamieszanie! Przykłady punktów fabularnych reprezentują dłuższe okresy niż przykłady czasowe.

EDYCJA 2 Obecnie nie ma dedykowanego mistrza scrum, a organizacja producentów przyjmuje tę rolę, jeśli chodzi o spotkania szacunkowe. Prawdopodobnie jest to konflikt ról, który pogarsza te nieodpowiednie negocjacje, ponieważ pojawia się jako autorytet, zamiast neutralnego mistrza scrumowego. Być może można to naprawić, biorąc go za stronniczego uczestnika zamiast „mistrza”, o ile żaden nie jest dostępny.

Sytuacja, którą opisujesz, jest toksyczna. Tego rodzaju negocjacje ignorują rzeczywistość i wiedzę zespołu, umyślnie ukrywają informacje przed zespołem i organizacją, a także powstrzymują zespół przed poprawą w czasie.

Jeśli chcesz miasta http://www.scrumguides.org/scrum-guide.html jako organ chciałbym podkreślić:

Tylko zespół programistów może ocenić, co może osiągnąć w nadchodzącym sprincie.

i

Scrum opiera się na przejrzystości. Decyzje dotyczące optymalizacji wartości i kontroli ryzyka podejmowane są na podstawie postrzeganego stanu artefaktów. W zakresie, w jakim przejrzystość jest pełna, decyzje te mają solidne podstawy. W zakresie, w jakim artefakty nie są całkowicie przejrzyste, decyzje te mogą być błędne, wartość może się zmniejszyć, a ryzyko może wzrosnąć.

Właściciel produktu może chcieć, aby zadanie było możliwe w ciągu zaledwie 4 godzin. To może być nawet rozsądny cel. Zdrową reakcją może być zaakceptowanie oszacowania zespołu, zmierzenie go, jeśli jest dokładne, i spytanie „co musielibyśmy zmienić, aby móc szybciej wykonać tego rodzaju zadanie?” Negocjowanie zakresu prac związanych z zadaniem może być również uzasadnione i uwypuklić ważną różnicę w sposobie, w jaki programiści i właściciel produktu rozumieją tę pracę. Żądanie od zespołu zmiany szacunków bez nowych informacji zapewnia jedynie niedokładne szacunki.

Zespół programistów może zastosować wiele strategii, aby spróbować zmienić ten wzorzec, ale kiedy podasz przykładową odpowiedź „Nie mogę wyjaśnić zarządzania”, bardzo się denerwuję. Wygląda na to, że właściciel produktu nie ma zaufania do kierownictwa (niedokładne szacunki, które produkują, prawdopodobnie nie pomagają) i może nie być chętny do zachowania przejrzystości w odniesieniu do bieżących błędów procesu.

Moim zdaniem jednym z największych osiągnięć SCRUM jest rozwój punktów fabularnych, z wyraźnym wyraźnym zamiarem uniknięcia omawianych tu kwestii negocjacyjnych. Chodzi przede wszystkim o to, aby unikać bezpośredniego związku między zadaniem a liczbą dni. Zamiast tego te dwie koncepcje łączy idea prędkości.

Gdybym był programistą, a ja byłem nakręcony na rękę, by nazwać historię 13 punktów historią 8 punktów, chętnie bym się zobowiązał. Wpływają na ich możliwości szacunkowe. Po prostu wyskaluję wszystkie moje trudności, aby dopasować. Ostatecznie prędkość zespołu zmniejszy się pod względem liczby opowieści na tydzień, aby dopasować gotowość kierownictwa do „rozdrabniania” punktów opowieści. Liczby dostarczone do kierownictwa powinny się zgadzać: „Z powodzeniem zmniejszyliśmy liczbę historycznych punktów pracy potrzebnych do osiągnięcia kamienia milowego o 50%. Widzieliśmy jednak odpowiedni spadek prędkości o 50%, więc efekt netto to zamierzamy osiągnąć dokładnie to, co zamierzaliśmy osiągnąć w dokładnie takim czasie, jaki to zajmie ”. Pojęcie prędkości istnieje w celu zwalczania pobożnego życzenia wyższego kierownictwa.

Teraz są dwie skrajności, które moim zdaniem warte są przyjrzenia się. Jedna z nich jest całkowitym niepowodzeniem zarządzania, a druga jest tak naprawdę bardzo istotną kwestią, na którą należy dbać. Pierwszy przypadek to wyrok śmierci dla SCRUM, kiedy programiści są informowani: „nie jesteś wystarczająco produktywny. Musisz stworzyć więcej punktów wartych pracy”. Jeśli tak się stanie, nie używasz SCRUM, jesteś Cookoo, który wyrzucił SCRUM z gniazda i próbuje być karmiony przez matkę, która wraca do następnej.

Teraz jest jeden przypadek, w którym myślę, że zarząd powinienbyć w stanie zaangażować się w takie skręcanie ramion. Klient powinien rozsądnie powiedzieć: „Nie stać mnie na 50 punktów za wykonanie tego zadania, jeśli twoja prędkość wynosi 20 punktów na tydzień. Potrzebuję, abyś wykonał to w 30 punktach”, jeśli ten klient jest skłonny renegocjować treść tych opowiadań, aby zmniejszyć ich zakres o 40%. SCRUM nie jest darmowym biletem na posiłek dla programistów, aby robić, co chcą, jest to narzędzie komunikacyjne, które pomaga im i zarządowi otwarcie rozmawiać o tym, co należy zrobić. Ważne jest również, aby klient naciskał na programistę i powiedział „wykonaj zadanie w 30 punktach”, jeśli jest gotów zaakceptować nieodłączne ryzyko, że praca po prostu nie zostanie ukończona na czas. Gdy termin zostanie przekroczony, jeśli programiści mogą powiedzieć „ a następnie zaakceptuj wszystko, co faktycznie zostało zrobione. Myślę, że istnieją lepsze sposoby pomiaru produktywności zespołu, ale muszę przyznać, że to proces, który działa. a następnie zaakceptuj wszystko, co faktycznie zostało zrobione. Myślę, że istnieją lepsze sposoby pomiaru produktywności zespołu, ale muszę przyznać, że to proces, który działa.

Po pierwsze, organizacja producentów nie powinna przekazywać zarządowi informacji o zadaniu. Szacunki zadań są wyłącznie na korzyść zespołu. Jedyne, co każdy poza zespołem musi wiedzieć, nad którymi historiami pracuje, jakie są ich wartości punktowe i jaka jest średnia prędkość zespołu. T.

Po drugie, chyba że organizacja producentów jest programistą wyższego szczebla z głęboką znajomością oprogramowania, ich opinia na temat szacunków zadań nie powinna mieć dużego znaczenia. Programiści są tymi, którzy znają system i wykonują pracę. O ile wszyscy nie są świeżo po szkole z zerowymi umiejętnościami szacowania, ich oszacowania należy wykluczyć.

Nie oznacza to, że czasami nie można kwestionować szacunków. Jeśli tak, musi to nastąpić w pozytywny sposób. Na przykład „czy zastanawiałeś się, czy wykonaliśmy już połowę pracy dla„ x ””, czy „czy pamiętasz, aby uwzględnić czas na wykonanie Y?”.

Podsumowując: programiści powinni czuć się bezpiecznie, dokonując wszelkich szacunków, o ile chcą, pod warunkiem, że podejmą w dobrej wierze próbę zachowania dokładności. Jeśli powiedzą, że coś zajmuje cztery godziny, musisz to zaakceptować.

Co mówią wytyczne Scrum na ten temat lub czy coś na ten temat mówią?

Nic nie mówią. Szacowanie zadań nie jest częścią scrum. W przypadku scrum ocena kończy się w punktach opowieści. Szacowanie zadań jest jedynie narzędziem pomagającym zespołom w lepszym oszacowaniu punktów historii, upewniając się, że przemyśleli całą pracę niezbędną do ukończenia historii.

Zadaniem Scum Master jest upewnienie się, że śledzony jest proces scrum. Obejmuje to upewnienie się, że zespół nie (konsekwentnie) nadmiernie angażuje się w ilość pracy, jaką mogą wykonać w sprincie.
Z jednej strony oznacza to rządzenie zbyt entuzjastycznym zespołem, ale z drugiej strony także odsuwanie się do Właściciela produktu, jeśli wywiera on presję na zespół.

Jednym dobrym sposobem na utrzymanie realistycznego zaangażowania / prognozy jest spojrzenie na historie, które zostały zrealizowane w ostatnich kilku sprintach. Zespół udowodnił, że jest w stanie to zrobić, więc nie ma sensu ciągnąć znacznie więcej pracy w sprincie, ponieważ nie zostanie on ukończony.

Jak wskazują również inne odpowiedzi, negocjacje w sprawie szacunków podanych przez zespół nie są częścią procesu Scrum. Zespół jest najbardziej zaznajomiony z oprogramowaniem, więc powinni wiedzieć, ile pracy w ogóle ma.

Co może być targował o to zakres od historii. Jeśli właściciel produktu uważa, że ​​historia jest oceniana jako znacznie większa lub mniejsza niż można się spodziewać, może poprosić zespół o wyjaśnienie, aby zobaczyć, czy widok pracy, którą należy wykonać, pasuje do stron.
Jeśli historia jest naprawdę tak duża, Właściciel produktu może zdecydować o podzieleniu jej na kilka mniejszych historii i rozdzielenie funkcji na te mniejsze.

Zespół jest odpowiedzialny za dostarczanie wysokiej jakości i to nigdy nie powinno być otwarte na negocjacje.

Tak i nie.

Tak, zespół sprintu powinien negocjować z właścicielem produktu o czym dostanie się do sprintu.

Nie, właściciel produktu nie dostaje na to, ile czasu to zajmie. Jesteście ekspertami, a nie nimi.

Słuchaj, nie powinieneś mieć do czynienia z tego rodzaju śmieciami - twój menedżer lub kierownik zespołu są po to, aby przygotować cię do sukcesu. Oznacza to radzenie sobie z premierem (lub jego szefem), abyś odniósł sukces. To powiedziawszy, to nie jest takie trudne.

"Nie."

Co oni zamierzają zrobić? Napisz sam kod?

Dopuszczenie tego zachowania jest niepowodzeniem Scrum Master. Jej zadaniem jest przede wszystkim ochrona zespołu. Organizacja producentów, z powodów opisanych powyżej, jest krótkowzroczna. Scrum Master powinien wkroczyć i pozytywnie przeformułować kontekst dyskusji.

Taki nacisk oczywiście doprowadzi do zmniejszenia prędkości w dół, o czym już wspominał PO. Jeśli zespoły konsekwentnie nie kończą sprintu, Scrum Master powinien ponownie wkroczyć i zapytać, dlaczego tak się dzieje. W naprawdę toksycznych środowiskach członkowie zespołu mogą nie czuć się swobodnie będąc szczerymi w retrospektywach. Ale w tej sytuacji Scrum Master ma obowiązek wezwać złe zachowanie i chronić zespół.

Jeśli znajdziesz się w sytuacji, w której Twój Scrum Master nie może lub nie będzie robił tych rzeczy, prawdopodobnie potrzebujesz innego Scrum Master. Organizacja producentów reaguje na typowe naciski. Zespół w jaskiniach reaguje również tak, jak często robią to ludzie. Zadaniem Scrum Mastera jest zobaczyć to, co to jest i położyć temu kres. Odpowiedzialność OP polega na przedstawieniu tego w Retrospektywie oraz, w razie potrzeby, liderów i menedżerów. Jeśli to nadal nie rozwiąże problemu, zaktualizuj swój profil LinkedIn i znajdź lepszych ludzi do pracy.

Zespół ds. Rozwoju produktu (tj. Każdy od właściciela produktu, przez programistów, testerów) może śledzić sprawny proces i uzyskiwać dobre wyniki, biorąc pod uwagę rozsądnie kompetentnych ludzi i realistyczne oczekiwania.

Lub mogą postępować zgodnie z procesem, który powierzchownie przypomina proces zwinny.

Ten PO prawdopodobnie myśli, że uzyska lepsze wyniki, starając się uzyskać niższe prognozy czasu dla zadań. Oczywiście, że to nie działa. Jeśli coś potrwa trzy dni, dajesz mi dużo gotówki, a ja oszacuję, że dam radę za godzinę. Nadal zajmie to trzy dni. Jeśli przyjdziesz i krzykniesz na mnie, bo nie skończy się to tak, jak obiecano, zajmie to pięć dni.

Wszystko, co osiąga, to przerywanie zwinnego procesu i rezygnacja ze wszystkich pozytywnych rezultatów, jakie może osiągnąć. Mistrz Scrum powinien mieć doświadczenie, moc i odwagę, aby temu zapobiec. Jeśli zarządzanie sprawi, że ktoś scrum master, który nie ma doświadczenia lub nie da scrum master mocy, aby temu zapobiec, to ich wina, że ​​zwinny się psuje. Jeśli mistrz scrum nie ma odwagi, dzieli się winą z premierem.

Powiedziałbym, że zależy to od motywacji. Nadrzędnym celem oszacowania jest uzyskanie wiedzy o tym, ile zespół może osiągnąć podczas każdego sprintu, co następnie pozwala prognozować przyszłe prace na podstawie tej prędkości. Na przykład, jeśli zespół zbiera 30 punktów opowieści w każdym sprincie, a zaległe pozycje są o 60 punktów opowieści, właściciel produktu może rozsądnie powiedzieć, że przedmiot X zostanie ukończony za około 6 tygodni (na podstawie standardowy dwutygodniowy sprint).

Aby oszacowanie było jak najdokładniejsze, nie jest niespotykane, że nie ma zgody co do tego, ile punktów opowieści jest dany przedmiot. Scrum naprawdę to zachęca. Nieporozumienie może czasem nawet zostać podgrzane. Jednak ostatecznym celem końcowym powinno być dokładne oszacowanie złożoności PBI, a nie sztuczne zmniejszanie wysiłku, abyś mógł spróbować wcisnąć więcej PBI do danej prędkości.

Zasadniczo tak właśnie działa planowanie pokera. Wszyscy przedstawiają swoje szacunki. Scrum Master dokonuje następnie oceny szacunkowej wysokiej i niskiej i pyta, dlaczego członek zespołu uważa, że ​​powinna być tak wysoka / niska. Daje to zespołowi szansę usłyszenia alternatywnych perspektyw pracy i lepszego zrozumienia stopnia złożoności zadania. Po dyskusji wszyscy ponownie rzucają swoje prognozy. Proces ten jest płukany i powtarzany, aż do osiągnięcia ogólnego konsensusu co do złożoności.

Innymi słowy, nie jest źle kwestionować twoje oszacowanie, biorąc pod uwagę, że pretendent ma uzasadnienie, dlaczego się nie zgadza, poza tym, że po prostu chce, aby było niższe. Twoim obowiązkiem jest zatem przekonanie swojego zespołu, że twoje szacunki są prawidłowe, jeśli uważasz, że nadal tak jest.