Niektórzy członkowie zespołu nie biorą czynnego udziału w planowaniu sprintu

15

Niektórzy członkowie zespołu tylko czekają, aż opowieści, nad którymi najprawdopodobniej będą pracować, zostaną omówione i dopiero wtedy wezmą udział. W przeciwnym razie po prostu bawią się telefonem i nie słuchają.

W pewien sposób rozumiem to stanowisko. Po co wysłuchać dyskusji na temat funkcji, w której prawdopodobnie nie pomożesz rozwijać się w Sprint lub nigdy?

Jak myślisz, co powinniśmy zrobić?

agile scrum

— Eugene
źródło

9

Jak duży jest ten zespół?

— JeffO

8

@JeffO trafił w sedno - to klasyczny problem nadwymiarowego zespołu. Ponadwymiarowy zespół = niewymiarowe indywidualne uprawnienia / obowiązki = niewymiarowe indywidualne zaangażowanie. Odpowiednio dobrany zespół oznacza, że wszystko, co mówicie o efektach, wpływa na każdego w pokoju. Ewentualnie za bardzo spoczywasz na obowiązkach związanych z silosem - po co wysłuchać dyskusji na temat funkcji, w której prawdopodobnie nie pomożesz? Odpowiednio dobrany zespół, który nie odpowiada za zadania w silosie, powinien umożliwić wszystkim pracę nad każdą funkcją.

— Jimmy Hoffa

7

Telefony wyłączone, bez wyjątków. Proste spotkanie zdrowego rozsądku.

— user1019696

5

@ user1019696, żeby być uczciwym, mogę dostać telefon od mojej żony, że moje dziecko złamało nogę w dowolnym momencie. Istnieje duża różnica między „wyłączonymi telefonami” a „nie zadzieraj z telefonem w trakcie spotkania, ponieważ jest to po prostu brak szacunku”.

— Jimmy Hoffa

4

@Jeśli nie wspominasz o epoce, w której istnieli sekretarze firmy, nie było takiej osoby w firmie, w której pracowałem od lat - nie mieliby nic do roboty. I nie, nie może się doczekać. Zwłaszcza nie do pracy, przepraszam, ale praca rodzinna. To powiedziawszy, może dostaję telefon w środku 1 na 30 lub 40 spotkań (może ??), z których prawdopodobnie odbieram 1 na 30 lub 40 ... Nie jest trudno nie być palantem z telefonem. Jeśli ludzie potrzebują ich niepełnosprawnych lub usuniętych ze swoich osób, aby uniknąć szarpnięcia, być może ta osoba to tylko palant.

— Jimmy Hoffa

32

Zatrzymaj własność kodu. Równie prawdopodobne jest, aby każdy w zespole pracował nad danym zadaniem.

Prawie na pewno nastąpi pewne odreagowanie, ponieważ programiści czują się dobrze z określonym obszarem kodu, a inni ludzie nie spoglądają za siebie. Ponadto zarząd zobaczy problem z pracą trwającą dłużej niż zwykle, ponieważ zawsze istnieje krzywa uczenia się.

Ale tak naprawdę leży to w najlepszym interesie wszystkich. Niezbędny jest miecz obosieczny. Coraz trudniej jest dostać się na urlop, wieczorem, w weekendy lub na wakacje. Własność kodu jest niekorzystna dla firmy, ponieważ kiedy ktoś odchodzi, kosztuje więcej czasu niż kiedykolwiek zaoszczędziłeś na drobnych transferach wiedzy.

— pdr
źródło

4

+1 Absolutnie. Jest fałszywe wrażenie wydajności, gdy myślisz, że kodery to tylko kolejna część linii montażowej, a potem zastanawiasz się, dlaczego projekt zostaje cofnięty, ponieważ jeden z trybów wymaga wymiany.

— JeffO

3

@JeffO, co jest moim zdaniem standardem wśród firm zarządzających programistami, biorąc pod uwagę, że programiści są identycznymi częściami w maszynie, którą można natychmiast zamienić na inną jednostkę węglową ...

— jwenting

3

@jwenting, dzięki czemu idealnie nadają się również do outsourcingu. Nie rozumiem, dlaczego programiści pomagają w takim podejściu.

— GrandmasterB

1

@jwenting To jest punkt zwinny. Aby zmienić tego rodzaju pogląd na rzeczy.

— Euforyczny

1

@Eforyzacja z mojego doświadczenia wynika, że efekt końcowy jest odwrotny, menedżerowie postrzegają ludzi jeszcze bardziej jako aktywa, które można po prostu wymieniać w locie, jak wymagania ...

— jwenting

15

Czy zapraszasz odpowiednie osoby na spotkania? Jeśli podzieliłeś system na obszary odpowiedzialności za podelementy, po co zapraszać wszystkie podelementy na każde spotkanie?
Na przykład, jeśli masz zespół frontendowy i zespół backendowy, zachowaj sesje planowania dla pracy frontendowej dla członków zespołu frontendowego. Może zaproś kogoś z zespołu zaplecza jako łącznika na wypadek, gdyby zadanie przekroczyło granice zespołu (ale jeśli zdarza się to często, możesz zrewidować podział obowiązków między swoimi zespołami).
Idealnie wszyscy powinni pracować nad wszystkim, ale w rzeczywistości często nie jest to praktyczne, chyba że twój system jest naprawdę mały i prosty, dzięki czemu wszyscy dokładnie znają każdą jego część. W praktyce oczywiście wiele systemów jest wystarczająco dużych, aby oczekiwać, że każdy członek Twojej organizacji będzie miał wystarczającą wiedzę na temat zaplanowanego zadania, aby móc udzielać prawidłowych informacji podczas sesji planowania (nie mówiąc już o równie produktywnej pracy nad każdą częścią systemu). po prostu nierealne.

— jwenting
źródło

12

Ich brak zainteresowania jest tylko symptomem. Problem polega na tym, że nie rozprowadzasz pracy równomiernie wśród wszystkich członków zespołu. Idealnie każdy członek zespołu powinien odbierać każdy nowy bilet, który nie jest ograniczony do niektórych obszarów projektu.

— Tom Squires
źródło

3

To miło z teorii. W praktyce, szczególnie w przypadku dużych projektów, system może być na tyle duży, że niepraktyczne jest, aby każdy członek zespołu miał wystarczającą wiedzę na temat każdej jego części, aby był produktywny podczas pracy nad nim.

— jwenting

@jwenting - wygląda na to, że ten zespół jest bardzo pewien, że nigdy nie będzie musiał pracować nad innymi częściami. Chociaż jedna osoba nie może wiedzieć wszystkiego, nie oznacza to, że powinna się uczyć jak najmniej.

— JeffO

@JeffO to prawda, ale nie można oczekiwać, że będą w stanie aktywnie uczestniczyć w planowaniu rzeczy w obszarach, o których nie wiedzą. Słuchaj i ucz się, ale miej usta zamknięte. I może użyj telefonu komórkowego, aby zrobić zdjęcia tablicy planszowej :)

— jwenting

1

@jwenting w praktyce przy dużych projektach, musisz bardziej rozpowszechniać pracę! Nie każdy ma taką samą wiedzę, ale równie prawdopodobne jest, że będą pracować w danym obszarze. Dopuszczenie wymówek zwiększa prawdopodobieństwo, że członkowie zespołu nie przyjmą nowych obszarów.

— Dave Hillier

5

Brzmi jak problem motywacyjny - dlaczego niektórym ludziom nie zależy na projekcie, nad którym pracują? Może dlatego, że zespół jest podzielony na „organizatorów” i „pominiętych”.

Zaangażuj więc wszystkich, zamiast 1 lub 2 osób odpowiedzialnych za sesje planowania, angażujesz wszystkich - każesz różnym osobom przejąć kontrolę nad każdą sesją, najlepiej niech różne osoby przejmą kontrolę podczas sesji. Obróć to wszystko dookoła. Wiem, że to może wydawać się trudne, ponieważ zawsze jest ktoś, kto chce się tym niepokoić i organizować wszystkich, ale oni są tutaj problemem.

Oto pomysł: planując, wybierz losowo osobę, która zajmie się każdą historią. Losowo. Zapisz, kto był również odpowiedzialny za jego planowanie, więc podczas następnego sprintu możesz stwierdzić, czy wykonali dobrą robotę, uzyskując dobry konsensus w zakresie szacunków i podziału zadań. To sprawi, że zwrócą uwagę, a także da im powód do zaangażowania się w projekt.

Pamiętaj, że problemem nie są one, to Ty i sposób wykonania sesji planowania. Kiedy więc ktoś przejmie plan opowieści, może zdecydować, jak sobie z tym poradzić, powinien to być oficjalny sposób postępowania. (tzn. nie siedź i nadal narzucaj im swoją organizację przez proxy)

— gbjbaanb
źródło

Dobre pomysły. Mam nadzieję, że ludzie nie uznają tego za stratę czasu.

— Eugene

1

Jaki jest twój czas trwania sprintu?

Dłuższe czasy sprintu prowadzą do

Więcej pracy do zaplanowania w sprincie, co prowadzi do
Dłuższe spotkania planistyczne, które prowadzą do
Większe trudności dla członków zespołu, aby pozostać skupionym, ...
Członkowie zespołu się nudzą

Jeśli więc twój czas trwania sprintu jest dłuższy niż dwa tygodnie, spróbuj pracować w krótszych.

Jeśli trudno jest skłonić interesariuszy do zaangażowania się w krótsze sprinty, możesz pominąć niektóre formalne spotkania, np. Przegląd sprintu następuje tylko co 2 sprinty, a nie po każdym sprincie.

— Pete
źródło