Czy sprinty Scrumowe działają w najszybszym możliwym tempie?

21

Niedawno przeprowadziłem wywiad z niektórymi firmami, które używają Agile, a dokładniej Scrum, a są pewne rzeczy, które nie do końca wydają mi się Agile. Wezmę teraz jeden przypadek, który szczególnie mnie interesuje, dotyczący sprintu Scrum.

Jeden konkretny kierownik projektu, z którym rozmawiałem (tak, powiedziałem kierownik projektu) z dumą stwierdził, że ludzie w jej zespole rozumieją („powiedziano mi”, to, co wybrałem z kontekstu), że nie wracasz do domu po upływie godzin pracy , wracasz do domu po zakończeniu pracy, bez względu na to, ile to zajmie. Przeczytałem między wierszami, że w sprincie pakujemy jak najwięcej funkcji i pracujemy w nadgodzinach, aby tak się stało.

Teraz do tej pory nie robiłem Agile (współpracowałem z instytucjami finansowymi i rządowymi, które nadal preferują wodospad), ale rozumiem, że:

  • sprint w Scrum to nazwa ogólnej iteracji w Agile;
  • zespół powinien pracować w zrównoważonym tempie i starać się unikać długoterminowych nadgodzin, ponieważ ma to wpływ tylko na krótki czas, a efekty są przyćmione przez problemy, które napotykają przez długi czas.

Czy moje wypowiedzi są prawidłowe? I czy powinienem traktować prezentację kierownika jako czerwoną flagę?

JohnDoDo
źródło
Nie ma też prawdziwego doświadczenia z Agile, ale z tego, co zrozumiałem, obciążenie sprintu powinno być zrównoważone z czasem trwania sprintu, więc albo programiści nie doceniają swojego obciążenia, albo menedżer po prostu daje im pracę bez pytania o opinie na temat obciążenia . W tym przypadku prawdopodobnie ten drugi. - Popraw mnie, jeśli się mylę
Andreas
4
@gnat Myślę, że pytania są zbyt różne
Andreas
27
„... nie wracasz do domu po upływie godzin pracy, wracasz do domu po zakończeniu pracy, bez względu na to, ile to zajmie ...”. Biec jak wiatr. Ona jest idiotką.
JᴀʏMᴇᴇ
Głosowałem za ponownym otwarciem tego pytania. Pytanie o proponowany duplikat „ zwinność-nowa-mikrozarządzanie” ma wspólne znaczenie z tym pytaniem, że menedżer nazywa coś „scrum”, a pytający chce wiedzieć, czy to naprawdę jest scrum. To pytanie dotyczy „nadgodzin”, proponowanych „nie wolno rozmawiać z innymi programistami”.
k3b
„... że nie wracasz do domu po upływie godzin pracy, wracasz do domu po zakończeniu pracy, bez względu na to, ile to zajmie” wydaje się być bezpośrednim konfliktem z kluczową koncepcją zrównoważonego tempa - pracuj tam, gdybym musiał położyć jedzenie na stole. HST, jeśli zdarza się to od czasu do czasu, nie mam z tym problemu. Czasami, pomimo wszelkich wysiłków, dochodzi do kryzysu, a klient jest na pierwszym miejscu. Ale sprawia, że ​​brzmi to tak, jakby to było normalne zjawisko i że jest to godne podziwu. Oznacza to, że nie robią głównej przyczyny, aby zrozumieć, dlaczego się pojawia, i naprawić podstawowy problem.
Don Branson

Odpowiedzi:

27

Nie musisz szukać daleko, aby zobaczyć, że praktyki te są sprzeczne z zasadami Agile. Jedna z zasad Manifestu Zwinnego mówi:

Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność.

Kilka lat temu Scrum dokonał subtelnej, ale ważnej zmiany . Zamiast zespołów zaangażowanych w pracę, którą można wykonać, prognozują, co według nich można zrobić.

Zmiana następuje z powodu nadużyć, które brzmią bardzo podobnie do opisywanej przez ciebie postawy „nie wracaj do domu, aż do końca”. W fazie rozwoju zespołów jest wiele czynników, na które zespoły nie mogą się zgodzić - aby użyć analogii pogody, nie można „potwierdzić”, że jutro będzie padać.

Aby bezpośrednio odpowiedzieć na pytania:

  • tak, Sprint to nazwa iteracji w Scrumie. Zobacz tę odpowiedź dla różnicy
  • tak, zespoły powinny pracować w zrównoważonym tempie. Pewność tylko nadgodzin jest to, że będzie zmniejszenie produktywności zespołów długoterminowej.
  • tak, to czerwona flaga!
Dave Hillier
źródło
23

Tak, masz rację, a gdybym usłyszał, co ci mówiono, uciekłbym stamtąd tak szybko, jak to możliwe. Po prostu używają zwinności jako wymówki. Brzmi jak klasyczny marsz śmierci.

Miki Watts
źródło
3
Czy marsz śmierci zazwyczaj nie miałby końca? Ten projekt brzmi jak wieczne piekło, jeśli tak działa sprint po sprincie.
DXM
5
Nie, w marszu śmierci zawsze jest „musimy po prostu przejść do następnej wersji, a następnie możemy przefakturować i naprawić błędy! Ups, obiecaliśmy klientowi następną następną wersję za dwa miesiące, po prostu musimy przejść do następnej następnej wersja!" i tak dalej, masz pomysł.
Miki Watts
2
@DXM kończy się, gdy wszyscy rezygnują lub zostają zwolnieni. Projekty Marszu Śmierci mogą trwać lata.
Dogweather
3
@DXM marsze śmierci kończą się, gdy umrzesz.
Dave Hillier
hmm, myślę, że wyświetlałem tam swoje własne doświadczenia. W moim przekonaniu źle zarządzane projekty to połączenie marszu śmierci, po którym następują miesiące niezdecydowania, gdzie pójść dalej. Najdłużej nasz zespół siedział na kciukach z pustymi zaległościami przez prawie 8 miesięcy. Następnie otrzymalibyśmy 4-6 miesięcy na wydanie z oświadczeniem „jesteśmy w rocznym cyklu wydawniczym”
DXM
11

Jest jedna kluczowa rzecz, która może uczynić to akceptowalnym: zespół akceptuje zakres sprintu.

W Scrum zespoły nie tylko otrzymują przydzieloną pracę. Właściciel produktu negocjuje z zespołem w celu ustalenia priorytetów pracy produktu i pracy technicznej (dłużnej). Kierownik projektu, właściciel produktu i zespół negocjują następnie, co zostanie wciągnięte w sprint i jaki jest zakres tej pracy.

W tym świecie zespół zasadniczo mówi „możemy wykonać pracę X, przetestować i wysłać tę iterację”. Oczekiwałbym więc, że zespół od czasu do czasu będzie pracował w nadgodzinach, aby wypełnić te zobowiązania.

To powiedziawszy, tak wiele miejsc drań zwinnie - i tak mało kierowników zespołów może skutecznie negocjować z ludźmi, którzy zwykle są ich szefami ... Uznałbym to za wielką czerwoną flagę.

Telastyn
źródło
8
„okazjonalnie pracuj w nadgodzinach, aby wypełnić te ( błędnie oszacowane ) zobowiązania” => przekształcanie złych szacunków w nawyk
zgrab
1
@gnat - pssh. Szacunki są czasem wysokie. Szacunki są czasem niskie. Jeśli niedoszacowanie staje się trendem, z pewnością stanowi problem. Ale w dużej mierze z tego powodu istnieją iteracje: aby pomóc w udoskonaleniu szacowania.
Telastyn
8
Sweatshopy programistyczne na ogół nie akceptują negocjacji pracowników.
wałek klonowy
1
@gnat: Jeśli stwierdzisz, jako zespół, że zwykle nie doceniasz pracy, powinieneś poświęcić mniej pracy w następnym sprincie.
Bart van Ingen Schenau
Gdy cele zarządzania mają na celu wykonanie jak największej ilości pracy, niezależnie od ograniczeń godzin pracy (a doświadczenie wskazuje, że jest to prawdą w zdecydowanej większości przypadków), a cele pracowników to wykonanie jak największej ilości pracy bez przekraczania płatnej pracy godziny (przyznaję, że niektórzy menedżerowie mogą twierdzić, że jest to optymistyczne), a następnie niezależnie od nieodłącznego błędu w szacowaniu, harmonogram zawsze będzie miał tendencję do> = godzin pracy. Logicznym rozszerzeniem jest to, że cele pracowników muszą przejść w niedoszacowanie. @BartvanIngenSchenau tak właśnie rozwija się ten nawyk.
Steven Evers
1

Scrum jest rozbity na sprinty, w których oceniasz zestaw zadań do wykonania w czasie tego sprintu (zwykle 2 tygodnie, ale widziałem gdzieś od 1 dnia do 4 tygodni). Myślę, że to stwarza zachętę do niedoszacowania zadań. OP (właściciel produktu) będą chcieli, aby niskie szacunki wiązały się z dużym zaangażowaniem na sprint. Zespół dokona dużych szacunków, aby wygenerować ładne wykresy wypalenia dla PM. Są to oczywiście oznaki kiepskiej organizacji. Naprawdę chcesz uzyskać dokładne prognozy i nie obawiać się, że nie uda ci się zabraknąć i przenieść opowieści do następnego sprintu lub zakończyć wcześnie i usunąć dodatkowe zadania z zaległości. Myślę, że termin „sprint” tworzy obraz osób pracujących szybciej.

nerwowy
źródło
1
z wyjątkiem tego, że organizacja producentów nie powinna brać udziału w procesie szacowania. Gdyby mieli być zwinni, zespoły byłyby wyłącznie odpowiedzialne za przedstawianie szacunków i na podstawie tego, co zespół szacuje, PO może zmienić jedynie zaległości.
DXM
2
„Zespół dokona dużych szacunków, aby wygenerować ładne wykresy wypalenia, które zobaczą premierzy.”: To jeden z powodów, dla których uważam, że cały ten mechanizm jest wadliwy. Myślę, że menedżer może uzyskać znacznie lepszą wydajność od zespołu, któremu ufają, niż zmuszając zespół do przedstawienia oszacowań, które zostaną wprowadzone do wykresów.
Giorgio
Zespół powinien, ale jak powiedziałem, mieć motywację do szacowania. Jeśli OP płaci, mogą wywierać presję, aby oszacować bardziej agresywnie. W tle pracuję jako konsultant, więc zespół scrumowy jest moim współpracownikiem, podczas gdy PO jest zwykle zewnętrzny i płaci nam zawyżoną stawkę rachunku :)
jiggy
@Giorgio niewiarygodny zespół zawsze może uzupełnić szacunki i pogorszyć sytuację. Jednak godny zaufania zespół, nawet ekspertów, może nauczyć się szacować lepiej. Właśnie dlatego dokonuje się szacunków, a następnie porównuje z rzeczywistą pracą, aby poprawić ich zdolność do oszacowania. Mechanizm nie jest wadliwy, problemem jest zespół, który korzysta z systemu, i będzie problemem niezależnie od systemu zarządzania.
Chris
1

Nie: sprinty Scrum to timebox, nic więcej, nic więcej. Na początku sprintu / iteracji zespół podaje szacunkową liczbę punktów historii, które według nich mogą osiągnąć, w oparciu o takie rzeczy, jak poprzednia wydajność, dostępność, nadchodzące wydarzenia, otwarte przeszkody itp. Następnie negocjują z właścicielem produktu o tym, które historie użytkowników zostaną wprowadzone do sprintu. To jest (lub było? Patrz inna odpowiedź) zobowiązanie, które zespół daje właścicielowi produktu.

Jeśli podczas programowania okaże się, że rzeczy nie są tak, jak się spodziewano (w końcu chodzi o rozwój oprogramowania) i istnieje ryzyko, że zespół nie spełni zobowiązania, informują właściciela produktu, że istnieje ryzyko, że jedna lub więcej historii nie do ukończenia.

I w porządku. Jasne, to źle się czuje, gdy muszę przyznać, że pod koniec sprintu się nie udało, ale to nie porażka, to szansa na poprawę. Ponieważ pod koniec sprintu / początku nowego można zrobić retrospekcję sprintu, a pierwszą rzeczą, którą ktoś zapyta, jest: „Dlaczego nie udało nam się tego sprintu i co musimy zrobić, aby go nie powtórzyć ? ” Jedną z opcji byłoby oddanie mniejszego zaangażowania (= zajęcie mniej punktów fabularnych).

tl; dr: Sustainable Pace. W Scrumie chodzi o kadencję, coś, co zespół może nadążać w nieskończoność na zasadzie sprintu do sprintu. Praca w godzinach nadliczbowych nie jest; zespół zostanie przepracowany, praca stanie się niechlujna, członkowie będą wzywać chorych lub całkowicie rezygnować, a wtedy masz o wiele większy problem niż nieudany sprint.

Cthulhu
źródło
0

Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność.

Z Manifestu Agile

Praca w nadgodzinach przez cały czas nie wydaje mi się zrównoważona.

To powiedziawszy, nie widzę problemu z tym, że wiosenne zobowiązanie jest silne (jeśli tak chce zespół), a konieczność pracy w godzinach nadliczbowych, gdy przesadzasz lub przekręcasz szacunki, jest dobrą zachętą do lepszego szacowania lub komunikowania się oczekiwania wobec PO.

ptyx
źródło
0

Jeden konkretny kierownik projektu, z którym rozmawiałem (tak, powiedziałem kierownik projektu) z dumą stwierdził, że ludzie w jej zespole rozumieją („powiedziano mi”, to, co wybrałem z kontekstu), że nie wracasz do domu po upływie godzin pracy , wracasz do domu po zakończeniu pracy, bez względu na to, ile to zajmie. Przeczytałem między wierszami, że w sprincie pakujemy jak najwięcej funkcji i pracujemy w nadgodzinach, aby tak się stało.

To nie jest Scrum. Proponowane obciążenie pracą timeboxu opiera się na szybkości zespołu , a nie na liście życzeń menedżera. Oni po prostu próbują oszukać cię, abyś uwierzył, że niekończąca się praca w nadgodzinach jest „zwinna”, a tak nie jest. Zespół stanie się bardziej wydajny, pracując bez zakłóceń i skupienia, ale Scrum nie jest magiczną różdżką zapewniającą niekończące się przyrosty wydajności.

Albo menedżer ma niewielkie nieporozumienie z Agile, albo (co bardziej prawdopodobne) uważa, że ​​programiści są tacy głupi. Z drugiej strony, kiedy zespół raz po raz akceptuje sprint, wiedząc, że będą musieli wykonywać pracę w godzinach nadliczbowych, może rzeczywiście są głupi i nie zasługują na to lepiej?

Chyba znasz odpowiedź ... ;-)

JensG
źródło