Dlaczego i z jakich powodów programiści mogą nie lubić „codziennego scrum”? [Zamknięte]

40

Trzymanie codziennego scrum ma zalety, takie jak:

  1. Zespół koordynuje się ze sobą
  2. Wszyscy wiedzą, ile zadań zostało wykonanych
  3. Wykres wypalenia staje się coraz bardziej kompletny
  4. Tablica zadań została zaktualizowana
  5. Nie trwa to długo, 15 minut nikogo nie zabije

Jednak ostatnio (po 6 miesiącach wdrażania i używania scrum) czuję, że nasi programiści nie lubią scrumu tak bardzo codziennie. Ludzie po prostu aktualizują tablicę zadań, nie wyjaśniając wystarczająco dużo, i wygląda na to, że się nudzą. Widzę, że kiedy z jakiegoś powodu tego nie trzymamy, stają się wyjątkowo szczęśliwi.

Po prostu nie wiem, co może być z tym nie tak. Czy są gdzieś jakieś powody wspomnianych wad dla „codziennego scrum” dla zespołu? Jakie mogą być przyczyny zmęczenia programistów codziennym scrumem?

Saeed Neamati
źródło
14
Mój problem z codziennymi spotkaniami scrumowymi polega na tym, że zaczynają się świeżo i na temat i szybko zamieniają się w 45-minutowy konkurs na temat zarządzania, niejasnych wymagań, barier technicznych i politycznych oraz złej jakości błędów, które piszą QA.
wałek klonowy
2
@Michael, nie mieliśmy mistrza scrum, to był problem. Jedynym powodem, dla którego odbywaliśmy codzienne spotkania Scrum, było to, że ugruntowane zarządzanie wprowadziło projekt w ziemię na mach 10 i musieli wprowadzić powierzchowne bezsensowne zmiany procesu wyłącznie w celu pojawienia się, jakby zajmowali się „nieuchwytnym problemem”. Oczywiście powiedzenie, że musimy robić codzienne spotkania scrumowe, jest o wiele łatwiejsze niż powiedzenie: „może jeśli nie skupię się na mikromanowaniu programistom i codziennym 4 godzinnym lunchem, możemy w końcu wypuścić wysokiej jakości oprogramowanie”
maple_shaft
19
Szczerze mówiąc, naprawdę nie chciałbym być proszony o codzienne chodzenie na spotkania i mówienie wszystkim, co zrobiłem. Próbuję pracować . „Atmosfera” otaczająca spotkanie - zmiana kontekstu, rozmowy na korytarzu, czekanie na pokój - będą jeść czas jak woah. Lepiej - IMO - aby organizować spotkania organiczne w razie potrzeby.
Paul Nathan
6
Codzienny scrum kładzie zbyt duży nacisk na programistę, aby mógł produkować coś codziennie. Potrzebują wolności, aby swobodnie eksperymentować bez konieczności codziennego uzasadniania swoich eksperymentów. Tygodniowy jest lepszy.
Acumenus

Odpowiedzi:

42

Miałem doświadczenie w zespole „SCRUM” z kilkoma pracodawcami. Wydaje mi się, że menedżerowie biorą „codzienne spotkanie scrumowe” jako główny punkt SCRUM i wyznaczają go jako cel, zamiast realizować go tak, jak to jest: środek do osiągnięcia bardziej efektywnego cyklu rozwoju .

Bardzo szybko 15-minutowe spotkania stały się 45-minutowymi spotkaniami, aktualizacje były nieskuteczne, ponieważ ludzie byliby zajęci ziewaniem i myśleniem „kiedy już możemy iść” zamiast słuchać innych, a także łamałoby ludzkie rutyny (ja, na przykład, jestem sowa i codzienne chodzenie do pracy o 9 rano na to głupie spotkanie to wystarczający powód, dla którego muszę rzucić pracę).

Kiedy menedżerowie wpadną na pewien pomysł, który może być dobry, jeśli zastosuje się go poprawnie, i doprowadzą go do skrajności - otrzymają dokładnie odwrotność oczekiwanych rezultatów. Ja osobiście uważam, że im więcej spotkań biorę udział w - tym mniej pracy robię. W kalendarzu mam 2 regularne spotkania tygodniowo i zwykle pomijam jedno z nich. Spotkania są dla menedżerów, zostaw programistom wykonanie ich zadań.

Jestem pewien, że będzie wielu entuzjastów SCRUM, którzy powiedzą „Ale to takie wspaniałe” - no cóż, ocal to, słyszałem to wszystko.

littleadv
źródło
5
Omówienie „poprzedniego dnia” oznacza od ostatniego spotkania i trwa około 24 godzin. Nie ma powodu, aby nie mieć go na początku dnia lub kilka godzin później. Nie wszyscy są zmuszeni do kodowania w tym samym czasie.
JeffO
6
@Jeff - powiedz to menedżerom. W każdym razie SCRUM jest dobry dla rozwoju ad-hoc, ale nie będzie działał dobrze w przypadku długoterminowego, wcześniej zaplanowanego procesu rozwoju. Kiedy mam zadanie trwające tydzień, o czym powinienem rozmawiać na codziennym spotkaniu? „Skończyłem pisać inną funkcję”? Kogo to obchodzi?
littleadv
6
@littleadv: „Kontynuuję pracę nad funkcją X. Nie mam blokad drogi” jest wystarczający do spotkania scrumowego. To ważna informacja dla zespołu. Jeśli Scrum jest dobry tylko dla rozwoju reklamy, będę musiał się z tym nie zgodzić. Widziałem to używane do długich, trwałych, udanych projektów. Zespół musi to zrobić z całego serca, ale to nie jest srebrna kula. Działa dla niektórych zespołów, a nie dla innych.
Bryan Oakley
3
+1 Nigdy nie spotkałem codziennego scrumu, który trwał 15 minut. Większość zajmuje co najmniej pół godziny i dość szybko tracę koncentrację :( Myślę, że krótka aktualizacja statusu ma wartość, ale niestety żaden sklep, w którym pracowałem, nie był w stanie tego zrobić krótko.
Andres F.
5
Innym problemem jest to, że „niech deweloperzy powiedzą nam, co się dzieje”, „spotkanie stanie się”, gdy deweloperzy powiedzą nam wszystko o swoich przemyśleniach na temat tego, dokąd pójdą dalej ”. Zupełnie inaczej i zajmuje znacznie więcej czasu. A potem kierownictwo myśli, och, skoro i tak wszyscy tu jesteśmy, pozwólmy przenieść kolejne spotkanie na to!
Spencer Rathbun
35

Codzienne wstawanie byłoby nudne i bezużyteczne, gdybym poczuł, że nie ma w tym żadnej wartości. Istnieje kilka rzeczy, które mogą zmniejszyć użyteczność codziennego standupu.

  • Udostępniane informacje nigdy mnie nie dotyczą ani w żaden sposób nie wpływają na mnie.
  • Brak własności zespołu i wszyscy zawsze pracują nad własnymi projektami.
  • Brak komunikacji zespołowej poza jednostką.
  • Brak widocznego lub zakomunikowanego postępu.
  • Brak informacji do udostępnienia.

Są tuż nad moją głową, ale zawsze jest więcej możliwych powodów.

Być może powinieneś po prostu zapytać deweloperów, dlaczego nie wydają się zainteresowani? Jeśli chcesz mieć więcej / lepszą komunikację, powinna zacząć od Ciebie.

dietbuddha
źródło
Ale @dietbuddha, jak to jest scrum, jeśli programiści nie udostępniają informacji ani części projektu?
Saeed Neamati,
4
Udostępniane informacje nigdy mnie nie dotyczą ani nie wpływają na mnie w żaden sposób. ” Mój codzienny scrum był nudny.
René Nyffenegger,
2
@Saeed Neamati: A Thing niekoniecznie jest tym, dla którego się nazywa. To nie znaczy, że nie robisz Scruma. Nie pracuję z tobą, więc nie mogę wiedzieć. Może również istnieć różnica między tym, jak rzeczy mają być zrobione, a tym, jak faktycznie są zrobione.
dietbuddha
19

Niektóre problemy napotykane podczas codziennych spotkań SCRUM:

  • te, które trwają zbyt długo. Nie chcesz, aby pojawił się w nich ktoś z kadry kierowniczej, ponieważ są one przyczyną tego rodzaju problemów. Zobacz, jak zwykle używają krzesła (tak, trzeba stawać w ich obronie, aby zachęcić ludzi do szybkości)
  • musi usłyszeć o kimś (lub 2 lub 3 deweloperach) opisujących jakikolwiek odizolowany problem, który ma w zamian zamiast niego, który decyduje się umówić kolejne prawdziwe spotkanie później, aby omówić to z zainteresowanymi
  • głupie godziny. Te spotkania nie muszą odbywać się rano: nie mówisz o tym, co zrobiłeś wczoraj i nie decydujesz, co zrobisz dzisiaj; mówisz o tym, co robiłeś między ostatnim dniem a tym, i decydujesz, co będziesz robić do następnego.
  • brak własności aplikacji dla deweloperów. SCRUM działa, jeśli deweloperzy nie są traktowani jak małpy kodowe. Pierwszą oznaką niepowodzenia procesu jest to, że twórcy nie są tymi, którzy oceniają, ile czasu zajmie zrobienie czegoś.
  • znowu głupie godziny. Jeśli część zespołu zaczęła pracować nad niektórymi rzeczami i znajduje się „w strefie”, gdy zdarza się codzienność, staje się to kłopotliwe. Dobrym momentem na codzienne jest to, że nikt nie powinien pracować (na przykład po obiedzie lub tuż przed rozpoczęciem dyskusji podczas lunchu).
Arkh
źródło
3
@jhocking: W rzeczywistości menedżerowie mogą uczestniczyć w spotkaniach (lub interesariuszach lub po prostu wszystkim, którzy są zainteresowani). Jednak zasada jest taka: rozmawiają tylko programiści. Wszyscy inni mówią tylko wtedy, gdy zostaną o to poproszeni. To takie proste ... (i tak, nasi menadżerowie uczestniczą w codziennych scrumach i przestrzegają tej zasady).
sleske,
2
Jeśli Twoi menedżerowie mogą trzymać się zasad, to świetnie.
jhocking
Ja osobiście spotkałem niedoborem mistrzów Scrum, która nadużywała „elastycznych godzinach” argument dzienników przytrzymać, gdy to było wygodne dla nich , więc to jeden potencjalny minowe. Drugi zaczyna coś „po”. To sprawia, że ​​codzienne wygląda na coś „skupionego”, podczas gdy rozpoczęcie „przed” nie tylko przerywa to postrzeganie, ale także pomaga zachować zwięzłość spotkania. Dlatego często preferowane są poranki - codzienne dzieje się przed rozpoczęciem „właściwej” pracy.
mikołak
+1 za ostatni punkt (planuj, kiedy nie przerywasz pracy, tj. Rzeczy, której nie mogłem do końca sfinalizować poprzedniej nocy lub miałem świetny pomysł na temat domu).
Cees Timmerman
14

Czas jest dla wielu zabójcą. Programiści lubią kodować do późna, spać do późna i przychodzić po porannym pośpiechu. Konieczność bycia w biurze o ustalonej godzinie - o wiele za wcześnie. I za późno dla innych, którzy mogą przyjść wcześniej i już zacząć pracę.

Kolejnym problemem jest przepływ . Programista z pewną funkcją będzie działał do późnej nocy, wróci do domu i wróci naładowany i będzie gotowy do kontynuowania. Konieczność spotkania się z najczęściej niezwiązanymi ze sobą kwestiami może go rozproszyć.

Cata
źródło
+1 Mam ten sam problem z procesami, które nakazują zbyt wiele spotkań. Zobacz także paulgraham.com/head.html , punkty 1 i 2.
Giorgio
11

Moim spostrzeżeniem jest zdecydowanie zbyt często spotkania te są dla menedżerów, aby wyglądać i czuć, że faktycznie coś robią, a nie są przydatne dla zespołu i projektu.

Na przykład zespół ma za zadanie wykonać szereg krótkich poprawek błędów w różnych projektach. Naprawdę nie pracują jako zespół, ale jako jednostki. Ponieważ jednak nakazuje to polityka firmy / działu, kierownik zespołu / menedżer organizuje codzienne spotkanie scrumowe. Wszystko, co zostało osiągnięte, to zabranie 15+ minut na bezużyteczne spotkanie i zajęcie się 15-30 minutami rozproszenia i braku wydajności przed i po spotkaniu.

Teraz widziałem, jak Scrum dobrze sobie radzi w projekcie, który miał napięte terminy i wymagał dużej koordynacji między ludźmi pracującymi nad różnymi utworami. W tym kontekście był to świetny system. Ale w kontekście „Jesteśmy na spotkaniu, ponieważ jesteśmy sklepem typu scrum / agile i właśnie to mamy robić” może naprawdę być do kitu.

jfrankcarr
źródło
10

Upewnij się, że nikt nie monopolizuje spotkania.

Jeśli 4 programistów usunie się z gry w ciągu 5 minut, a kolejne 10 minut zostanie spędzonych na słuchaniu lidera zespołu opisującego wszystkie niesamowite , niesamowite nowe osiągnięcia, których dokonał, z których większość nie jest ani tak niesamowita, ani tak niesamowita jak mu się wydaje, ludzie bardzo szybko się nudzą.


Odsuń się na chwilę i pomyśl o swoim zespole:

  • Czy działają skutecznie?
  • Czy zadania są wykonywane na czas?
  • Czy kod jest solidny i dobrze napisany?
  • Czy zespół zapewnia, że ​​nic nie wpadnie przez pęknięcia?
  • Czy zespół koordynuje się, aby nie powielać pracy ani nie deptać sobie nawzajem?

Jeśli Twoja odpowiedź na wszystkie te pytania brzmi „Tak”, być może powinieneś zastanowić się, dlaczego chcesz zmusić do pracy, jak codzienne spotkania, tabele wypalenia i tablice zadań w swoim zespole. Jaką wartość to dodaje? Czy chcesz generować biurokratyczne dane wyłącznie dla własnej przyjemności, czy starasz się zwiększyć wydajność zespołu?

Czy nastąpił spadek wydajności od czasu zatrzymania się codziennych młynów, czy też wszystko tyka tak samo jak wcześniej? Jeśli nic się nie zmieniło, po co kontynuować spotkania?

Mrówka
źródło
9

15 minut. Czy to 15 minut (plus czas na przygotowanie się) przekazuje wystarczającą ilość nowych i przydatnych informacji między członkami zespołu, aby poprawić wydajność zespołów na nadchodzący dzień o ponad 15 minut? Jeśli każdego dnia nie ma takiej ilości przydatnych treści, członkowie zespołu prawdopodobnie myślą, że zrobiliby znacznie większy postęp w kierunku celów, gdyby jak najszybciej opuścili spotkanie i wrócili do pracy.

Jeśli chcesz tylko często aktualizować planszę i wykres, umieść kopie robocze na wiki.

hotpaw2
źródło
8

Sugerowałbym, aby odbyć spotkanie retrospektywne, aby zobaczyć „Co poszło dobrze” i „Co nie poszło dobrze” i sprawdzić, czy programiści wymieniają codzienne spotkanie Stand-up jako stratę czasu. W takim razie trzeba go trochę przeorganizować.

Moje osobiste doświadczenie:

  • Chodzi o to, aby wiedzieć, co robimy dzisiaj i gdzie byliśmy wczoraj. Zamiast trzymać się agendy, zaczyna się techniczna dyskusja na temat blokerów między 2 osobami, a pozostałymi 15 się nudzi. Zidentyfikuj problem, ale przedyskutuj na zewnątrz
  • Ludzie nie wchodzą na salę konferencyjną na czas, a niektórzy celowo to robią. Dlatego Scrum Master musi odbyć z nimi cichą dyskusję poza spotkaniem, aby upewnić się, że zaczną i kończą się na czas.
  • Aktualizujemy już wykresy wypalenia poza spotkaniem Scruma, aby nie było to głównym celem codziennej walki.
JoseK
źródło
+ 1 + 1 + 1 To jest odpowiedź. Miejsca, w których pracowałem, które nie robiły retrospekcji, miały wszystkie problemy opisane przez wszystkich. Tam, gdzie teraz pracuję, mamy Scrum, Scrum of scrums (interteam), retrospektywy, a nawet retrospektywy. Wszystko po to, aby upewnić się, że rzeczy, które Cię dręczą i nie działają, zatrzymują się lub zmieniają tak bardzo, jak to możliwe, i że wszystko idzie dobrze. Bez tego scrum łatwo staje się nudny i nie na temat. Uważam również, że „spotkania” oczerniane przez tak wielu są świetne, jeśli mają naprawdę dobrą komunikację, są na temat, na czas i krótko.
Michael Durrant
7

Opór pojawia się, gdy: 1) Służą do zmuszenia ludzi do pośpiechu o 9 rano. Jest dodatkowy stres, gdy pociąg się spóźnia. 2) Słabe przywództwo scrum. Lider powinien mówić ludziom, żeby zdjęli rzeczy z linii, a nie zmuszali ludzi do słuchania czegoś, co ich nie dotyczy. 3) Treści bezwartościowe. To znowu kwestia przywództwa scrum. Ma to być forum zajmujące się wąskimi gardłami, problemami trajektorii i potencjalną współpracą. W rzeczywistości każdy mówi po prostu, czego oczekuje od pracy w tym dniu, co nie jest przydatne ani interesujące dla nikogo innego. 4) Stojący. Nie będę stać na stojąco. Logika stojąca za tym była taka, że ​​zachęca ludzi do krótkich wypowiedzi. Ludzie faktycznie po prostu grzechotają.

Ian
źródło
4

Wiele razy zarządzałem zespołami scrum i byłem ich częścią. Kluczowym powodem, dla którego programiści nie lubią scrum, są:

  • Ponieważ są prowadzone przez bardzo słabego mistrza scrum, jeśli zmieni się to w 45 minut, twój scrum master musi poprawić kontrolę nad scrumem.
  • Największym i jak dotąd najbardziej uczciwym powodem, dla którego im się to nie podoba, jest to, że bardzo trudno jest ukryć złą etykę pracy, tj. Bardziej rażąco pokazuje leniwych ludzi. Niektórzy deweloperzy, z którymi pracowałem, są szokujący, wykonują zadania, które powinny zająć 30 minut. Dobry premier powinien usunąć bariery dla deweloperów, co oznacza, że ​​powinni móc wykonywać swoje zadania w sprincie. Twórcom się to nie podoba, ponieważ muszą codziennie wstawać i demonstrować poczynione postępy. Powoduje niepokój, gdy nie mogą wykazać postępu z jakiegokolwiek powodu. Jeśli to z powodu ważnego problemu, dobry mistrz scrum powinien rozwiązać ten problem jak najszybciej.

Problem pojawia się, gdy mistrzowie scrum nie mają uprawnień, umiejętności ani zdolności do rozwiązywania problemów z blokowaniem. W rzeczywistości widziałem kilka problemów z pogrzebaniem w nadziei, że odejdą. To jest katastrofalne.

Shaun
źródło
4

Szczerze mówiąc, w 99% codziennych spotkań, w których uczestniczyłem, prawie wszystkim dyskusjom / pytaniom / odpowiedziom można było zaradzić za pomocą kilku e-maili.

Szczerze uważam, że musimy podać bardziej uzasadnione powody, by NIE organizować spotkań. Buduj środowiska, w których kiedy nadejdzie czas, aby wszystkich osobiście zamknąć w pokoju, że lepiej być dobrym powodem i być zorganizowanym, aby zmaksymalizować wydajność czasu.

Nienawidzę spotkań w ogóle i wolałbym korzystać z wideokonferencji, telefonów, e-maili i wszystkiego, co pozwala mi wejść lub pozostać w pracy bez konieczności wstawania i zakłócania wydajności.

Osobiście uważam, że jeśli masz więcej niż cztery spotkania w ciągu 8 godzin, projekty nie są dobrze zarządzane.

Alex M.
źródło
to nawet nie próbuje odpowiedzieć na zadane pytanie: „Dlaczego i z jakich powodów programiści mogą nie lubić„ codziennego scrum ”?”
komar
1
Właśnie zrobiłem. Nie lubię codziennego scrum, ponieważ nie jest to konieczne. Kilka e-maili z łatwością zaspokoi większość potrzeb.
Alex M
2
Interesująca myśl ... a może to dlatego, że MOJE doświadczenia ze scrumem nie były dobre. Być może „dzienny” powinien być w niektórych przypadkach „tygodniowy”. Wiem, że tydzień byłby skuteczniejszy niż codzienny.
Alex M
4

Istnieje wiele czynników, które przyczyniają się do napięcia wokół spotkań. Weź to pod uwagę jako jeden z ważnych powodów, dla których spotkania mogą cię kosztować więcej niż są warte:

  • Focus - oprogramowanie kontra spotkania
  • Zarządzanie - menedżerowie potrzebują pomiaru
  • Osobowość - introwertycy kontra ekstrawertycy
  • Czas - przerwy, czas Twórcy i Menedżera
  • Cele, priorytety

Każdy z tych czynników wyjaśniono poniżej,

Koncentracja - Lubię tworzyć oprogramowanie, które obejmuje myślenie o wyzwaniach (problemach), tworzenie rozwiązań, tworzenie oprogramowania i spotkania, które odwracają uwagę od zadań związanych z tworzeniem oprogramowania. Istnieje stan o nazwie „ Flow ”, w którym programista jest zanurzony w wyzwaniu (problemie), zbudował mentalny model rozwiązania i całkowicie skupia się na budowaniu rozwiązania. Deweloper może pracować do północy, pozostawiać tylko po to, aby jeść i spać, a następnie powrócić do stanu bliskiego miejsca, w którym wyszedł.

Programiści muszą unikać rozpraszania uwagi, a wielu uważa, że ​​kodowanie do późnych godzin ma zalety (unikają hałasu, rozmów telefonicznych, zajętego biura i współpracowników niebędących programistami przerywających pracę). A kiedy pracowałeś do 10, 11 lub 12, przychodzenie do pracy później (10, 11 w południe?) Jest nieracjonalne. Czy można oczekiwać od programistów pracy od 9 rano do północy?

Spotkania Scrumowe (i wszelkie inne) odwracają uwagę programisty od ich głównego celu, jakim jest budowanie oprogramowania.

Zarządzanie - Menedżerowie muszą mierzyć, aby odnieść sukces, stąd potrzeba harmonogramów, rezultatów, harmonogramów, priorytetów i spotkań w celu pomiaru i zgłaszania postępów oraz ujawniania zależności, opóźnień i obszarów ryzyka. Wyzwanie związane ze Scrumem polega na tym, że menedżer potrzebuje tych rzeczy, ale deweloper musi się skupić. Spotkania służą menedżerowi i zapewniają menedżerowi sposób uzyskiwania, mierzenia i śledzenia statusu i postępów, ale spotkania rzadko zapewniają użyteczność programistom. Weź pod uwagę, że menedżerowie zapewniają większą wartość, gdy radzą sobie z rozrywkami, usuwają bariery i umożliwiają programistom skupienie się na tworzeniu oprogramowania.

Istnieją rozwiązania potrzeby spotkań. Menedżer może odwiedzać swoich programistów, prosić o raporty o stanie, przyjmować protokół, gdy zakłócenia są mniej ingerujące, lub przyjąć zasady informujące programistę o postępach, gdy programista jest przerywany. Zobacz dyskusję czasu, dlaczego jest to ważne.

Osobowość - weź pod uwagę, że niektórzy ludzie są introwertykami, a inni ekstrawertykami. Ekstrawertycy lubią interakcje społeczne i są przez nich ładowani. Menedżerowie są zazwyczaj ekstrawertykami (ponieważ ekstrawertycy są zwykle lepsi w kontaktach społecznych), chociaż introwertycy mogą odnosić sukcesy jako menedżerowie. Introwertycy mogą cieszyć się, a nawet celować w interakcjach społecznych, ale są ładowani przez samotność. Deweloperzy często są introwertykami i odnoszą sukcesy pracując samodzielnie (lub w małych zespołach), ponieważ nie potrzebują „interakcji społecznych”; mogą być szczęśliwi pracując samodzielnie nad problemami (chociaż ekstrawertycy mogą być również programistami). Codzienne spotkania scrumowe mogą stać się spotkaniami towarzyskimi, dobrymi dla ekstrawertyków, ale nie tak dobrymi dla introwertyków.

Czas - programiści nie mogą pisać kodu podczas spotkań. Nie mogą też myśleć o trudnych problemach (chyba, że ​​burza mózgów), podczas gdy są rozproszeni przez spotkania. Programiści potrzebują dużych bloków nieprzerwanego czasu, aby skupić się na tworzeniu oprogramowania. Spotkania są przerwami, które odwracają uwagę od ich wysiłków. Kiedy godzinami zanurzasz się w rozwiązywaniu problemu, prawie już skończyłeś, a ktoś mówi „czas na scrum”, zostajesz przerwany i być może tracisz godziny pracy podczas „zmiany biegów”. Lub pozostałeś w pracy do 23:00, opuściłeś pracę, pojechałeś do domu, spałeś na problemie, obudziłem się, wróciłem do pracy gotowy do rozwiązania problemu, a potem zostałeś przerwany po godzinie pracy nad problemem, ponieważ to „czas na scrum”.

Paul Graham ma doskonały artykuł na temat Maker Time vs. Manager Time, który wyjaśnia ten problem znacznie lepiej niż ja. Wystarczy powiedzieć, że przerwanie spotkania, niezależnie od tego, czy jest planowane, czy nieplanowane, może przerwać przepływ i zmusić programistę z czasu Maker do czasu Menedżera. Uwierz mi, chcesz programistów na czas Maker.

Cele, priorytety - Programiści i menedżerowie mają różne cele i priorytety. Menedżerowie mają obowiązek śledzenia harmonogramów, minimalizacji kosztów, upewnienia się, że ich raporty są odpowiedzialne i że wykonują. Programiści mają na celu zbudowanie oprogramowania, które sprosta wyzwaniom / problemom. Cele te nie są w konflikcie, ale to mechanizm komunikacji powoduje napięcie. Spotkania służą potrzebom menedżera i optymalizują czas menedżerów, ale są sprzeczne z potrzebami programisty. Spotkania Scruma odrzucają pierwszą zasadę spotkań, „mają porządek obrad” i mają tendencję do błąkania się dalej. Spotkania służą do optymalizacji komunikacji (dla menedżera), ale kosztują czas programisty (przerwy, utrata przepływu itp.).

Jaki jest cel Aby szybko i jakościowo tworzyć oprogramowanie, które zaspokaja potrzeby, a ograniczeniami są (jakość, czas, koszt, proces). Scrum i inne zwinne metodologie rozpoznają ograniczenie procesu i próbują zminimalizować ten czynnik, i odniosły sukces, ponieważ minimalizują to ograniczenie. Ale dodawanie spotkań kosztuje czas, a przerwanie kosztuje programistę znacznie więcej niż czas trwania spotkania.

ChuckCottrill
źródło
0

Zmodyfikuj spotkanie, aby upewnić się, że zapewnia ono korzyści:

  1. Zaplanuj to w czasie, który oferuje pewną wygodę. Dlaczego nie może upłynąć 30 minut od rozpoczęcia pracy, aby każdy mógł przejrzeć e-mail i uporządkować swoje przemyślenia na spotkanie. Brevity wymaga planowania. Nieprzygotowani mogą włóczyć się wiecznie.
  2. Zidentyfikuj problemy, których można by uniknąć, gdyby problem został zakomunikowany podczas spotkania. Każdy musi zrozumieć, o co chodzi.
  3. Zrób wszystko, aby ograniczyć wkład wszystkich do minimum. To nie jest miejsce na debatę. Zachęcaj ludzi do prywatnego planowania spotkań poza codziennym spotkaniem poświęconym tematowi, który wymaga dyskusji. Reguła: rozmawia tylko jedna osoba na raz.

Wszyscy skarżący muszą upewnić się, że nie przyczyniają się do powstania problemu. Jeśli możesz osiągnąć swoje cele w codziennym scrumie, nie mając go w mniej bolesny sposób, chcielibyśmy to usłyszeć.

JeffO
źródło