Mój kierownik projektu nie akceptuje przeniesienia w Scrumie - czy to normalne?

52

Jestem programistą pracującym nad nową aplikacją mobilną na Androida i iOS z dużym komponentem zaplecza. Byliśmy w trzech sprintach tego projektu i używamy Scruma podczas wszystkich jego ceremonii (udoskonalanie, planowanie, dzienniki, retrospektywy itp.).

Podczas dwóch sprintów zespół musiał pracować (nieodpłatnie) w godzinach nadliczbowych i weekendach, ponieważ kierownictwo było bardzo zaniepokojone, że nie dotrzymamy zobowiązania do sprintu na czas. Wszyscy ciężko pracowali, ale niektóre zewnętrzne zależności i optymistyczne szacunki sprawiły, że mieliśmy trudności z ukończeniem wszystkich historii sprintu.

Z mojego doświadczenia wynika, że ​​niewielki odsetek historii, które nie zostały ukończone podczas niektórych sprintów, jest nieco normalny i można je rozwiązać w następnej. Ale nasz kierownik projektu mówi, że to nasza wina, ponieważ sami dokonaliśmy oceny, więc powinniśmy ukończyć wszystkie elementy w sprincie.

  1. Czy to akceptowalna / powszechna odmiana Scrum, o której nie wiem?

  2. Jak sugerujesz, żebym działał w tej sprawie?

MrAn3
źródło
66
.. ponadto, gdy twoja umowa o pracę zezwala na nieodpłatne nadgodziny i weekendy, a twoi przełożeni mogą ci to zrobić z własnej woli, obawiam się, że najlepszym rozwiązaniem jest albo dodanie marginesu bezpieczeństwa co najmniej jednego czynnika 2 do każdego sprintu eastimation lub znaleźć innego pracodawcę.
Doc Brown
59
Nie, nie jest to dopuszczalna praktyka od czasu zniesienia rzymskiej kuchni. Jest to typowy atak paniki kierownika projektu, którego kompetencje mogłyby się dalej rozwijać. Kopanie ludzi w tyłek przy założeniu, że nie radzą sobie najlepiej bez kwestionowania szacunków i sytuacji, nie pomoże w tym bałaganie. Ale ta kwestia jest zdecydowanie zbyt szeroka, aby ją tutaj omawiać ...
Christophe
27
Zadaj sobie pytanie, jak wyglądałby zarząd, gdybyś wcześniej wypełnił swoje „zobowiązanie” do sprintu. Czy zespół dostanie resztę sprintu (w tym wynagrodzenie)?
Qwerky
13
Project Manager nie jest normalny w Scrumie. Przewodnik Scrumowy jest dość wyraźny w odniesieniu do ról: Scrum Master, Właściciel produktu, Scrum Team. Nie wspomniano o PM. W rzeczywistości wiele osób (w tym większość sygnatariuszy Manifestu Zwinnego) wielokrotnie twierdziło, że projekty szkodzą zwinności. Ponadto jesteś jedynym, który decyduje, że jest to dopuszczalne. Jeśli nie możesz tego zaakceptować, dopracuj swoje CV i poszukaj lepszej firmy.
Blueriver
5
Dwie rzeczy: zobowiązania są podejmowane przez zespół, a nie szefa rządu, więc poświęć mniej na natychmiastową naprawę, jednak większy problem dotyczy tego, co się stanie, jeśli nie dostarczysz? Jaka jest konsekwencja? Zazwyczaj PM, TPM, mistrzowie Scrum, właściciele produktów itp. Są zachęcani do współpracy z zespołem, ponieważ ... nie mają realnego autorytetu nad zespołem w strukturze macierzy, do której Agile / SCRUM się nadaje. Więc może to być tylko @ próbujący rozwinąć karierę kosztem innych.
RandomUs1r

Odpowiedzi:

75

Kilka rzeczy mnie wyróżnia.

Pomysł, jaki ma kierownictwo, że zespół angażuje się w zbiór prac, jest niezgodny z najnowszymi wersjami Przewodnika Scrum. Słowo „zatwierdzenie” lub „zobowiązanie” jest używane tylko dwa razy w najnowszej wersji Przewodnika Scrum (listopad 2017 r.) - raz przy wymienianiu Wartości Scrum i raz, aby wskazać, że „ludzie osobiście zobowiązują się do osiągnięcia celów Zespołu Scrumowego „.

Idea celów jest ważna dla Scruma. Organizacje i zespoły mają nie tylko ogólne cele, ale w Scrumie każdy Sprint ma Cel Sprint zdefiniowany w Sprint Planning jako współpraca między właścicielem produktu a zespołem programistycznym. Cel sprintu jest realizowany poprzez wdrożenie elementów z rejestru produktu, ale nie jest to po prostu „ukończenie tej pracy” i często nie reprezentuje pełnego rejestru sprintu. Oznacza to, że powinieneś być w stanie osiągnąć cel sprintu bez ukończenia każdego elementu Backlogu Produktu wybranego dla Sprinta lub każdego elementu w Backlogu Sprintu. Moje obecne myślenie jest takie, że praca potrzebna do osiągnięcia celu sprintu powinna wynosić około 60-70% pojemności twojego zespołu, jednak to ty bierzesz pod uwagę pojemność. Różne organizacje będą jednak różne, ale to „

Praca w godzinach nadliczbowych i weekendach jest również praktyką przeciwdziałającą zwinnemu programowaniu. Jedną z podstawowych zasad jest to, że wszystkie zainteresowane strony są w stanie pracować w zrównoważonym tempie. Długie dni i weekendy, nawet jeśli zostały opłacone, nie są w stanie utrzymać zespołu.

W tym momencie jest kilka kolejnych kroków. Zespół Scrum Master powinien edukować kierownictwo w zakresie wartości i zasad Scrum i Agile Software Development (takich jak „zaangażowanie” i „zrównoważone tempo”). Zespół powinien pracować nad swoją zdolnością do prognozowania pracy i negocjować zakres z właścicielem produktu. Zespół powinien również zidentyfikować i pracować nad rozwiązaniem lub zapobieganiem przeszkodom, które doprowadziły do ​​tej sytuacji (wyeliminowanie lub ograniczenie wpływu zależności zewnętrznych).

Thomas Owens
źródło
2
Świetna odpowiedź - możesz nawet ją poprawić, podkreślając lub TL; DR, zwracając uwagę na najważniejsze punkty: zaangażowanie może pochodzić wyłącznie od samego dewelopera, a praca musi być zrównoważona
Falco
Ponadto, jeśli masz opóźnienia z powodu zależności od innych zespołów, Twój czas powinien być widoczny dla Twojego zespołu.
luizfzs
2
Wierzę, że zmienili sformułowanie na „prognoza”; podobnie jak prognoza pogody, może się mylić, ma poziomy pewności, a historie ukończone w sprincie pomagają zespołowi lepiej oceniać w przyszłości.
George Stocker,
1
@GeorgeStocker Tak - słowo „prognoza” jest używane zamiast „zatwierdzenia” w odniesieniu do rejestru sprintu i określonych elementów pracy. Jednak „zatwierdzenie” i „zobowiązanie” jest stosowane w odniesieniu do celów zespołu.
Thomas Owens
1
a także tak, 9 kobiet nie może urodzić 1 dziecka w ciągu 1 miesiąca :)
Michael Durrant
33

Opisana przez Ciebie sytuacja, w której kierownictwo wymaga, aby zespół pracował w nadgodzinach, aby ukończyć wszystkie zaplanowane historie, jest jednym z powodów, dla których literatura Scrum przestała używać terminu „zobowiązanie”. Prawdziwe zobowiązanie można dać tylko wtedy, gdy wyeliminowana zostanie wszelka niepewność, w tym niepewność co do zależności osób trzecich, ile pracy zajmuje każdy element, ile czasu każdy będzie dostępny biorąc pod uwagę chorobę itp.

Jedną z podstawowych idei Scrum jest to, że zespół pracuje w zrównoważonym tempie, co zasadniczo oznacza normalne godziny pracy bez nadgodzin (płatne lub nieodpłatne). To bezpośrednio oznacza, że nie występuje akceptowalna odmiana Scruma.

Co możesz z tym zrobić, zależy od twojej roli.

Jeśli jesteś programistą, najlepsze, co możesz zrobić, to

  • (wspólnie jako zespół programistów) odmawiają „angażowania się” w więcej pracy, niż jesteś absolutnie pewien, że możesz wykonać w trakcie sprintu. Prawdopodobnie będzie to znacznie mniej niż to, co kierownictwo chce, abyś zrobił.
  • skupiaj się na zakończeniu pracy, a nie na nowych zadaniach. Jeśli zauważysz, że niektórych prac nie można ukończyć, zaznacz to jak najwcześniej, aby umożliwić dostosowanie planów.

Jeśli jesteś mistrzem Scrum, możesz naprawdę udowodnić swoją wartość, kształcąc kierownictwo na temat Scrum. Niektóre punkty, które mnie wyróżniają:

  • Jak stwierdzono w akapicie pierwszym, zespół nie zobowiązuje się podczas planowania sprintu, ale podaje prognozę prac, których wykonania oczekuje się zakończyć.
  • Chociaż zespół powinien unikać niedokończonej pracy pod koniec sprintu, sytuacja ta jest prawie nieunikniona na początku projektu (lub po zmianie składu zespołu). Ile pracy zespół może realistycznie wykonać podczas sprintu, można ustalić wyłącznie na podstawie historycznych danych z kilku ostatnich sprintów zespołu w tym składzie. Na początku projektu takie historyczne postacie po prostu nie istnieją, więc zespół osiągający w pierwszych 3 sprintach dokładnie to, co zaplanowano dla każdego sprintu, jest bardziej wypadkiem niż dobrym planowaniem. Po około 5 sprintach w zrównoważonym tempie jest wystarczająca ilość danych, aby uzyskać rozsądny pomysł, ile pracy zespół może realistycznie wykonać w ramach sprintu.
Bart van Ingen Schenau
źródło
Tak, niepewność jest usuwana dopiero po zakończeniu projektu :-)
Christophe
3
Większość ludzi jest bardzo dobra w przewidywaniach. Jedyny wyjątek dotyczy przyszłości.
Michael Durrant
21

Twój premier nie ma nic wspólnego z twoim scrumem.

Twój premier nie ma interesu w proszeniu o nieodpłatne nadgodziny.

Oczywistą rzeczą jest oszacowanie wszystkich zadań w taki sposób, aby zagwarantować, że zostaną one wykonane na czas. Następnie powinieneś być w stanie pójść do pubu w drugi sposób, ponieważ oczywiście, jeśli niedocenianie zadania oznacza, że ​​kończysz je za darmo, to przeszacowanie oznacza, że ​​masz czas bez pracy.

gnasher729
źródło
1
„Twój premier nie ma nic wspólnego z twoim scrumem”. W przypadku niektórych metodologii Agile (np. DSDM) robią to. Pure Scrum nie rozpoznaje nawet „Project Managera” jako istniejącej roli.
nick012000,
3
Jeśli z umowy o pracę wynika, że ​​nadgodziny mogą być nieodpłatne, premier z pewnością musi o to poprosić. A jeśli zespół wykona się wcześniej, niż przewidywano, to znowu „błąd” zespołu, więc nie ma powodu, aby się później lenić, lepiej zacznij szacowanie na następny sprint, aby oszacowania nie były tak dalekie ^^ (mówiąc w logice premiera ). Nie zgadzam się ze sposobem, w jaki kierownictwo sobie z tym radzi, ale twoje argumenty też się nie utrzymują (poza tym, że PM jest zaangażowany w scrum, w zależności od pewnych ograniczeń - jako interesariusz może być zaangażowany, ale nie w sposób obecnie jest).
Frank Hopkins,
Inną logiczną odpowiedzią na zmuszanie do dokonywania szacunków jest zaplanowanie czasu na zbadanie wszystkich niewiadomych, zanim możliwe będzie oszacowanie rzeczywistego zadania.
Robin Bennett
Nigdy nie pracowałem nigdzie, gdzie scrum / agile działa w ten sam sposób, ale w szerokich pociągnięciach, podczas gdy PM nie jest uznawany za szczególną rolę, często zarządzają budżetem i ryzykiem. Następstwem tego jest to, że absolutnie zrobić mają żywotny interes w tym, jak dobrze / źle rozwój idzie i może poprosić o niezapłaconej nadgodziny aczkolwiek w układzie dobrej woli. Sposób, w jaki jest to ułatwione w zespole, będzie się znacznie różnić w zależności od sklepu. W niektórych miejscach są one wręcz wolne - podporządkowane mistrzowi scrum, w innych uczestniczą w wstawaniu (wbrew przyjętej praktyce).
Robbie Dee
DSDM nie jest zwinną metodologią, jest parującym stosem **** ****** **** tego *** *** **** *******, który lubią menedżerowie, ponieważ daje im dużo zaangażowanie w proces.
gbjbaanb
12

Jest w tym wiele aspektów, ale na wysokim poziomie tak - premier będzie absolutnie chciał jasno zrozumieć, dlaczego planowane prace nie zostały zakończone. Jednak powinno to zostać poruszone (i rozwiązane) w retrospekcji. Od strony deweloperów istnieje wiele czynników, które mogą przyczynić się do niepowodzenia w sprincie.

Niektóre rzeczy, które warto rozważyć:

Za dużo w sprincie

Jeśli regularnie angażujesz się w zbyt dużo pracy, sprinty się nie powiodą. Prędkość sprintu należy śledzić w czasie, aby dowiedzieć się, jaka jest optymalna liczba punktów (lub dni).

Alokacja zasobów

Upewnij się, że planowanie sprintu odpowiednio uwzględnia działania niezwiązane z rozwojem, takie jak ceremonie, wakacje, szkolenia, administracja, wsparcie i inne projekty itp. Automatyczne zakładanie, że wszyscy rozwijają się z każdą minutą każdej godziny, gdy są fizycznie w biurze, jest po prostu niepraktyczne i natychmiast postaw cię na tylnej stopie od samego początku.

Oszacuj zmienność

Robisz wyrafinowanie, ale czy są jakieś zadania, które zawsze się przekraczają? Często są to spowodowane brakującymi lub niejasnymi wymogami. Jeśli wymagania są wełniste, historia nie powinna nawet przejść do sprintu, chyba że zostanie odpowiednio udoskonalona lub zaplanowano skok.

Prędkość

Jeśli prędkość jest właściwie śledzona, prawdziwa liczba opowieści powinna być wyraźna. Nie oznacza to, że zawsze będą wykonywane na czas, ale powinno to znacznie ułatwić sprawę.

Życzliwość

W każdym projekcie dobra wola jest ograniczona. Jeśli ciągle pracujesz nad godzinami, aby dostarczyć, morale ucierpi, a deweloperzy wypalą się - jest to błąd zarządzania projektem . Jak już wspomniałem, upewnij się, że planowanie sprintu planuje tylko realistyczną liczbę historii przy użyciu prędkości i skoków, które pomogą ci po drodze.

Kolce

Jeśli przedmiot jest źle dopracowany lub po prostu wełniany, nie bój się postawić kolca, aby lepiej oszacować późniejsze sprinty. Tak, niektórzy ludzie są po prostu źle oszacowani, ale przez większość czasu, pełne fakty po prostu nie są w tym czasie znane. Najlepiej byłoby, gdyby to było ujęte w udoskonaleniu lub odebrane wcześnie przez PO, ale czasami mogą prześlizgnąć się do sprintu. Deweloperzy powinni odpierać te trudne kroki, ponieważ mogą łatwo zepsuć sprint, który w przeciwnym razie przebiega dobrze.

Robbie Dee
źródło
2
Nie jestem pewien, czy „odepchnięcie od PM” jest najbardziej użytecznym kadrowaniem. Cały zespół, jako całość, powinien chcieć usprawnić swój proces - po to jest retrospektywa - a wszystkie zidentyfikowane problemy są świetnymi rzeczami do rozważenia w ramach tej dyskusji, ale myślę, że najbardziej użyteczne jest myślenie tego jako „w jaki sposób zespół może zapewnić, że prognozy dostarczone przez cele sprintu będą bardziej przydatne w przyszłości?” zamiast premiera odpychającego zespół za niewykonanie zadań.
Zach Lipton
1
Myślę, że docierasz do sedna problemu. Premier musi poruszyć tę kwestię, aby zrozumieć, dlaczego projekt się spóźnia, ale powodem nr 1 będzie „szacunki były błędne” z jakiegokolwiek powodu. (a powodem tego byłby premier, który nie lubił wysokich szacunków!)
Ewan
Dla mnie jest to zdecydowanie najlepsza jak dotąd odpowiedź. +1
złyITguy
Co powiesz na „wypychanie” (co sugeruje potencjalnie antagonistyczne podejście) jako „pytania”, które wydają mi się bardziej neutralne i skuteczne?
Michael Durrant
1
@MichaelDurrant i in. W porządku - zmodyfikowałem brzmienie pierwszego akapitu.
Robbie Dee
10

Nie, to nie jest rozpoznawalna forma Agile , z jednego bardzo ważnego powodu: jeśli zobowiązujesz się do dostarczania wszystkiego , nie robisz Agile, robisz Wodospad - i jeśli myślisz, że robisz Agile , prawdopodobnie źle sobie radzisz z Wodospadem . Jestem pewien, że słyszałeś starą piłę „dobrze, szybko, tanio, wybierz dowolne dwa”, prawda? Wraz z rozwojem oprogramowania jest to bardziej jak „wszystkie funkcje dostarczone na czas, w ramach budżetu, wybierz pierwszą lub dwie pozostałe”. Waterfall wybiera pierwszą, a Agile drugą.

Jeśli chcesz być zwinny , potrzebujesz elastyczności, aby usuwać Historie z Sprintu, których nie możesz ukończyć na czas. Jednym z możliwych sposobów jest poproszenie właściciela produktu o ocenę historii przy użyciu priorytetów MoSCoW. Oznaczałoby to wybranie nie więcej niż 60% opowieści (według łącznej liczby punktów opowieści) jako Must Haves, które zostaną ukończone, 20% jak Haves, które powinieneś ukończyć w ramach projektu, a minimalny dostępny produkt zostanie wydany, 20% jako Czy Haves może zostać ukończony, jeśli masz czas, i cokolwiek poza zakresem obecnej wersji jako Won't Haves. Ważne jest również, aby pamiętać, że po połączeniu Must Haves powinny mieć wystarczającą ilość mięsa do kości, aby stworzyć minimalny żywotny produkt bez konieczności dołączania żadnych przedmiotów z innych kategorii.

Ustalenie, czy upuścić elementy z rejestru sprintu jest obowiązkiem właściciela produktu, po tym, jak zespół poprosi o to, a wszelkie przedmioty, które zostaną upuszczone z rejestru sprintu, zostaną ocenione przez właściciela produktu, a następnie są albo zostało całkowicie usunięte z projektu lub umieszczone w Backlogu Projektu na odpowiednio uszeregowanej pozycji.

W takim przypadku zgaduję, że Twój Właściciel produktu jest Twoim Project Managerem, prawda? Jego zadaniem będzie ustalenie, które zadania należy porzucić, więc z pewnością nie powinien winić cię za nadmierne zaangażowanie, ponieważ jego zadaniem byłoby porzucenie zadań, aby to zrekompensować, i wygląda na to, że tego nie robi.

nick012000
źródło
wszędzie, gdzie widziałem Scrum, jego wodospad.
gbjbaanb
6

Ma rację, że między sprintami nie powinno być żadnych przeniesień. Zespoły Scrumowe mające przeniesienie między sprintami to anty-wzór, a nie coś, co kanoniczny Scrum akceptuje jako ważny wynik.

Ale jego podejście nie jest dobre.

Podczas sprintu zespół powinien stale monitorować wykonywane prace i czy mogą kontynuować swoje zaangażowanie w planowanie sprintu dotyczące ukończenia wybranych historii. Jeśli drużyna stwierdzi, że nie jest w stanie ukończyć wszystkich historii, powinna spotkać się z PO i wybrać historię do usunięcia ze sprintu. W ten sposób wszyscy ZATRZYMUJĄ SIĘ PRACĄ NA HISTORII i skupiają się na wykonaniu pozostałych historii. Pamiętaj: zawsze lepiej jest ukończyć jedną historię w pełni, niż mieć dwie historie w połowie ukończone.

Problemy zewnętrznych zależności i nieprecyzyjnego oszacowania są dokładnie tym, dlaczego istnieją Retrospektywy. Podczas Retro zespół powinien zastanowić się i zidentyfikować te problemy. Zespół powinien następnie znaleźć i wdrożyć rozwiązania tych problemów. Szacunki mogą być dokładniejsze dzięki lepszej znajomości systemu i prostemu doświadczeniu. Zależności zewnętrzne są trudniejsze, ale nie niemożliwe do naprawienia.

Twój PM ( co w ogóle robi PM w zespole Scrum? ) Nie powinien pozwolić Scrum Master na zmuszanie cię do ukończenia wszystkich historii. Zamiast tego, jeśli narzeka, powinien zatrzymać je na retrospekcję. Co więcej, powinno być częścią rozwiązywania problemów, które uniemożliwiały ukończenie opowieści na czas.

Euforyk
źródło
Nie zgadzam się z komentarzem „nieprawidłowy wynik”. Choć nie jest to pożądany wynik, zespoły scrumowe powinny zdać sobie sprawę, że niekiedy od czasu do czasu niektóre historie są całkowicie rozsądne. Z pewnością nie powinien to być normalny wynik, jeśli nie uda ci się ukończyć więcej niż jednej historii, oznacza to, że robisz coś źle, ale stwierdzenie, że nie jest to prawidłowy wynik, jest moim zdaniem nieco mocny. Wolę zespoły, które wybierają trochę za dużo pracy, niż wybierają za mało.
Bryan Oakley,
5

Czy to akceptowalna / powszechna odmiana Scrum, o której nie wiem?

Nie . To całkowicie źle. Mogłabym być może poprzeć płatne godziny nadliczbowe, jeśli OP popełnił błąd, podając szacunki jako fakty przed końcem sprintu, ale nieopłacone godziny nadliczbowe są całkowicie absurdalne i sprawiłyby, żebym szukał innej pracy jak najszybciej.

Jak sugerujesz, żebym postąpił w tej sprawie?

Z mojego doświadczenia wynika, że ​​ludzie, którzy są aż tak szynowi, nie będą słuchać logicznych argumentów. Jedynym sposobem, aby przekonali się, jak bardzo jest uszkodzony, jest pokaz , a nie opowiedzenie. Więc następnym razem, gdy oszacujesz i zatwierdzisz, dokonaj najmniejszej możliwej kwoty . Zobowiązaj się do ukończenia małego biletu przed końcem sprintu. Można to zrobić w ciągu jednego dnia. Zobacz, jak reaguje Twój PM. Następnie rozpocznij dyskusję od tego, do czego służy system i do czego system powinien być używany.

nvoigt
źródło
pozytywnie rozpatrzona, choć perspektywa nieopłaconego czasu nadliczbowego może być rozsądna, jeśli umowa jest sformułowana w ten sposób (a płaca ogólna uwzględnia to, tj. powyżej średniej - lub istnieją inne korzyści).
Frank Hopkins
4

Ogólnie rzecz biorąc, na początku projektu, kiedy decydujemy o prędkości zespołu, wybieramy konserwatywną (niższą niż zwykle) liczbę, biorąc pod uwagę fakt, że jest to nowy zespół, zajęłoby mu to trochę czasu , rozumiemy się wzajemnie, rozumiemy wymagania funkcjonalne i NFR itp. Zasadniczo po kilku pierwszych sprintach optymalizujemy prędkość zespołu i oczywiście prędkość poprawi się tylko od tego momentu.

Nie ma sensu zwiększanie prędkości na początku i rozciąganie zespołu, aby to osiągnąć.

Jeszcze jedną rzeczą jest to, że w jednorazowym scenariuszu, w którym istnieje zobowiązanie do dostarczenia, którego nie można przeoczyć, menedżerowie projektów mogą wywierać presję na zespół, aby rozciągał się, pracował do późna i pracował w weekendy. Ale to należy uznać za wyjątek, a nie normę działania. Takie działanie może zwiększyć prędkość w krótkim okresie, ale w dłuższej perspektywie przyniesie efekt przeciwny do zamierzonego, ponieważ może to spowodować problemy z jakością kodu, problemy z wypaleniem zespołu, niezadowolony zespół o niskiej motywacji itp.

Rajesh Nair
źródło
1
Miły! +1. Ryzykując rozdwajanie się włosów, nie „decydujesz” o prędkości, jest to po prostu coś, co wychodzi po praniu po wielu sprintach, ale tak, przy sprincie 0 (lub jak go liczysz) - układasz planszę z tyloma historiami, które według ciebie są osiągalne.
Robbie Dee
2

FAQ dotyczące zobowiązań

Czy to zachowanie jest normalne?

Nie jestem pewny.

Czy to zaskakujące

Nie. Niektórzy ludzie zawsze rozumieją „zobowiązanie”, co oznacza, że ​​wszystko w zobowiązaniu musi zostać wypełnione.

Czy to dobry pomysł?

Nie. Zwinne projektowanie ma zrównoważony rozwój jako główny temat: Pracuj tylko tyle / długo / ciężko, ile możesz zrobić w nieskończoność. W większości przypadków jest to rozsądny pomysł. (Jeśli kierownictwo tego nie zaakceptuje, nie powinno nazywać swojej organizacji sprawną).

Co powinniśmy zrobić?

  • Wyjaśnij, że zawartość sprintu jest oparta na oszacowaniu . „Oszacowanie” oznacza, że ​​tylko czasami będzie poprawne - i zwykle błędne. Kiedy jest źle, czasami jest za niska, a czasem za wysoka.
  • Wyjaśnij, że o wiele łatwiej jest zmienić zachowanie szacunkowe niż prędkość pracy.
  • Wyjaśnij, że gdy zespół zostanie ukarany za zbyt wysoką ocenę, po prostu oszacuje niższą wartość, a kierownictwo straci w ten sposób znacznie więcej postępów, niż od czasu do czasu przesuwając część treści z jednego sprintu na drugi.

Zaletą jest: Twój kierownik projektu będzie już wiedział te wszystkie rzeczy i uzna je za słuszne. Tylko w krótkim okresie można je zignorować.

Lutz Prechelt
źródło
2

Nie zgadzam się z twoim zespołem zarządzającym. Nie powinni byli zmuszać cię do nadgodzin do ukończenia sprintu.

Jednak pomysł, że zobowiązania nie są możliwe, wynika z nieporozumienia dotyczącego rozwoju oprogramowania. Widziałem wiele zespołów próbujących przewidzieć historie, które mogą ukończyć w sprincie na podstawie liczby punktów historii, które ukończyły w poprzednich sprintach. Gdyby to było możliwe, oznaczałoby to, że tworzenie oprogramowania jest liniowe, tzn. Jeśli pracuję dwie godziny, robię dwa razy więcej niż w ciągu godziny.

Tworzenie oprogramowania jest kreatywne, a zatem nie liniowe. Lepiej jest, aby zespół powiedział zarządowi, co może zrobić w sprincie, a następnie opowiedział te historie. Jeśli konsekwentnie nie wywiązujesz się ze swoich zobowiązań, albo nie masz pojęcia o zakresie historii na początku, albo jesteś zmuszony przez właściciela produktu, by przejął więcej.

W pierwszym przypadku musisz upewnić się, że rozumiesz zakres historii, zanim zgodzisz się na jej wzięcie. Jeśli tak jest, masz problem kulturowy i niewiele można zrobić.

John Douma
źródło