W jaki sposób SCRUM zarządza środowiskiem, w którym członkowie zespołu są współdzieleni?

13

Cóż, pytania brzmiały same. W moim miejscu pracy takie przypadki się zdarzają, ale także wiele książek Agile promuje pracę w tym samym miejscu pracy i koncentrację na bieżącym projekcie, aby przyspieszyć tempo pracy.

Może nie jestem tak dobrze poinformowany na ten temat, może nie jest tak rygorystyczny, ale dlatego chciałem wiedzieć, co proponuje Agile w takich przypadkach.

Ktoś?

Xanathos
źródło
1
Co rozumiesz przez „dzielony”? Czy masz na myśli, że ktoś może przenosić się z jednego zespołu do drugiego lub że ktoś może pracować w wielu zespołach jednocześnie? To wpłynęłoby na moją odpowiedź.
pdr

Odpowiedzi:

6

W metodologii Scrum wpływa jedynie na oszacowanie.

Przydzielisz współczynnik koncentracji tej osobie na podstawie alokacji czasu dla każdego projektu.

Tak więc, jeśli równo pracuję nad Projektem A i Projektem B , Projekt A obliczy zasoby w następujący sposób:

Projekt A - Współczynnik koncentracji zespołu 70%
Sam - 10 dni, 100% alokacji (7 po współczynniku fokusu)
Joe - 10 dni, 100% alokacji (7 po współczynniku fokusu)
Me - 10 dni, 50% alokacji (3,5 po współczynniku fokusu) )
Łącznie: 25 dni * 70% współczynnik ostrości = 17,5 prognozowanej prędkości

Możesz również obliczyć współczynnik koncentracji osobno dla członków zespołu zatrudnionych w pełnym wymiarze godzin i członków zespołu zatrudnionych w niepełnym wymiarze godzin zamiast jednego dla całego zespołu, ze względu na zmniejszoną wydajność podziału projektów. W takim przypadku użyjesz mojego współczynnika koncentracji projektu na poziomie 50% i pomnożysz go przez osobisty przydział 50% dla 25% lub 2,5-dniowej przewidywanej prędkości .

To, jak dobrze to działa w praktyce, będzie miało wpływ na to, jak dobrze wiesz z góry, ile czasu wspólne zasoby przeznaczą na każdy projekt i jak dobrze Scrum działa dla Ciebie na inne sposoby.

Nicole
źródło
2
Mój problem z robieniem tego w ten sposób polega na tym, że nie uwzględnia to zbyt dobrze przełączania zadań. Na przykład rozważ 2-tygodniowy (10-dniowy) sprint. Posiadanie programisty z 50% współczynnikiem skupienia, w którym dostajesz go przez 5 dni z rzędu, znacznie różni się od posiadania programisty co drugą godzinę przez 10 dni. Ten pierwszy jest znacznie bardziej produktywny. Ekstremalny przykład, ale rozumiesz.
Brook
@ Brook Mówisz tylko o współczynniku skupienia (1 pomiar na osobę), który różni się od alokacji projektu (w tym przypadku podzielony 50/50). Współczynnik skupienia to% idealnego dnia, na który jest wart faktyczny dzień . Zwykle jest to około 70-80%, ale dla kogoś, kto dzieli projekty, prawdopodobnie byłby mniejszy (na co odpowiedziałem w odpowiedzi). Z czasem opiera się na pewnej spójności. Jeśli nie możesz mieć konsekwencji, naprawdę nie powinieneś nawet robić Scruma.
Nicole,
część dotycząca spójności była naprawdę moim celem. Jeśli masz zespół, w którym ludzie są ciągnięci w 10 różnych kierunkach i nie możesz tego zmienić, Scrum ci nie pomoże.
Brook
@Brook - to dobra uwaga i pomogłeś mi o tym pomyśleć w sposób, w jaki pierwotnie tego nie robiłem. Wygląda na to, że się zgadzamy.
Nicole,
1
@NickC Wydaje się to prawdopodobne. Przynajmniej jestem świadomy, że członkowie zespołu mogą być zmieniani za każdym razem, na szczęście to się nie zdarza tak często. Miejsce pracy pozostaje zawsze takie samo, tyle że czas poświęcony na projekt czasami stanowi połowę pojemności członka zespołu (ponieważ członek zespołu wykonuje taksówki z 2 różnych projektów). Ale wydaje się to odpowiednie do obliczania prędkości przynajmniej dla różnych projektów. Dzięki za referencje.
Xanathos,
10

Z mojego doświadczenia w Scrumie, prędkość można przewidzieć tylko wtedy, gdy projekt i zespół pozostaną takie same i oddane. Jeśli którakolwiek z tych rzeczy ulegnie zmianie, nie można tak naprawdę użyć obliczeń prędkości z poprzednich sprintu do oszacowania. Możesz spróbować, ale będziesz o wiele więcej niż zwykle.

Ogólnie rzecz biorąc, zdecydowanie powinieneś spróbować utrzymać ten sam zespół i poświęcić się co najmniej podczas sprintu, więcej, jeśli możesz.

Potok
źródło
2
W rzeczy samej! Próba dzielenia członków między projektami powoduje jedynie opóźnienie wszystkich zaangażowanych projektów. Nie ma sensu dzielić takich ludzi i myśleć, że rzeczy zostaną ukończone szybciej.
Martin Wickman,
+1 za zdrowy rozsądek, po prostu nie możesz przypisać trzech kobiet do ciąży, aby zrobić to w ciągu trzech miesięcy. Bardziej sensowne jest poświęcanie ludzi konkretnemu zadaniu.
wałek klonowy
Uważam, że tak naprawdę jest to „główny filar” Scruma. Plakat wydaje się mieszać kontekst, gdy pyta „co mówi Agile w tej sytuacji” (w porównaniu ze Scrumem) Czy istnieje odpowiedź Agile (nie-
Scrumowa
1

Moim zdaniem wpłynie to bardzo niekorzystnie na wszystkie projekty. To nie tylko kwestia oszacowania lub planowania. Tak, możesz powiedzieć, że jeśli członkowie zespołu są przydzieleni do trzech projektów i mają 33% alokacji do każdego projektu, wiesz wszystko, czego potrzebujesz i jesteś gotowy, ale to nieprawda.

Przełączanie kontekstu jest bardzo drogie. Utrzymanie pełnego zaangażowania w wiele równoległych projektów jest niemożliwe, więc te 33% procent czasu programisty jest dalekie od 33%, gdy programista jest przypisany tylko do jednego projektu.

Innym miejscem, w którym to całkowicie zawodzi, jest komunikacja. Co się stanie, jeśli członek zespołu pracujący obecnie nad projektem A musi coś komunikować z członkiem zespołu pracującym nad projektem A wczoraj, ale obecnie pracującym nad projektem B? Jest to przeszkodą dla obu z nich, ponieważ pierwsza potrzebuje informacji, ale druga koncentruje się na zupełnie innym projekcie, a każde pytanie do projektu A tylko mu przeszkadza. Scrum master z projektu A chce, aby jego programista uzyskał informacje tak szybko, jak to możliwe, a Scrum master z projektu B nie chce, aby członkom jego zespołu przeszkadzało coś niezwiązanego z projektem B. Jeśli chcesz tego uniknąć, musisz wszystko zaplanować programiści z zespołu, którzy pracują nad tym samym projektem w ciągu tych samych dni - to duża komplikacja dla całego procesu planowania i coś, czego należy całkowicie unikać.

Musisz także zaplanować wszystkie spotkania, aby się nie kolidowały. Musisz także zrozumieć, że spotkanie jest faktycznie marnotrawstwem, dlatego też powinna istnieć minimalna wymagana liczba spotkań możliwie krótka, aby zachować kontrolę nad procesem. Ale jeśli masz członka zespołu pracującego nad trzema projektami, musi on uczestniczyć we wszystkich spotkaniach dla tych trzech projektów => trzy razy więcej spotkań, na których programista nie wytwarza żadnej wartości biznesowej.

Podsumowując, zwinność polega również na zmniejszaniu ilości odpadów (tak jest z podejścia Lean), a dzielenie członków zespołu między zespołami jest jedną z najgorszych porażek pod względem wprowadzania odpadów i zmniejszania wydajności. Wydaje mi się, że dostarczona wartość biznesowa dla 33% alokacji dla jednego projektu będzie równa wartości biznesowej dostarczonej z 10-16% alokacji pełnego czasu. Oznacza to, że programista będzie nie tylko uczestniczył 1/3 czasu w projekcie, ale w tym czasie jego wydajność wyniesie od 1/3 do 1/2.

Ladislav Mrnka
źródło
1

SCRUM opiera się na zaangażowanym zespole bez wspólnych członków, dlatego równie dobrze możesz zapytać:

Ponieważ powiedziano nam, że musimy zrobić true == false, jak to zrobić x

Jeśli to nie jest SCRUM, nie nazywaj go SCRUM!

Ian
źródło
0

Kluczowe pytanie dotyczy zaangażowania członka zespołu w projekt. Idealnie, członek zespołu powinien być całkowicie zaangażowany w sukces projektu. Nie oznacza to, że jego czas jest całkowicie poświęcony projektowi, ale że jest on w stanie wykonać wszystkie zadania wymagane dla projektu, gdy pracuje nad projektem.

Często pracownicy zatrudnieni w projekcie tylko w niepełnym wymiarze godzin są zaangażowani tylko w ograniczonym zakresie zobowiązań. Na przykład możesz mieć osobę, która zajmuje się tylko optymalizacją bazy danych.

W takim przypadku często najlepiej jest traktować tę osobę jako „zasób”, a nie jako członka zespołu. Zespół decyduje, ile zasobów będzie potrzebować w danym Sprincie, i daje im bardzo konkretny zestaw zadań do wykonania dla Sprintu. Czasami najlepiej jest, jeśli Zespół ma konkretnego członka zespołu odpowiedzialnego za ten zasób, i będzie aktualizował status i raportował przeszkody dla tego zasobu w codziennym Scrumie.

Dave
źródło
0

Uważam, że jednym z kluczowych aspektów Scrum jest skupienie zespołu na jednej rzeczy na raz (jeden projekt, jedna historia, jedno zadanie ...)

Zapytałeś „co proponuje Agile” w sytuacji, gdy nie możesz przydzielić zasobów do jednego projektu ... Możesz rozważyć wypróbowanie jednego z poniższych:

  • Zachowaj dużą tablicę Kanban, która obejmuje wiele projektów. Ponieważ projekt ma taką potrzebę, jest dodawany do tablicy, ponieważ ludzie mają potencjał, wyciągają kluczowe historie. Problem polega na tym, że wszystkie projekty są zarządzane razem, co zmniejsza ogólną przewidywalność dla jednego projektu. To powiedziawszy, indywidualne elementy / elementy Kanban zostaną wyciągnięte i opracowane przez skoncentrowaną osobę lub zespół. (Możesz spróbować utworzyć mniejsze 4-5 osobowe zespoły, aby wyciągnąć je z planszy Kanban
  • Przydzielaj tylko zatwierdzone zasoby. Zachowaj pulę dedykowanych zasobów dla projektu. Są one chronione jako zespół, a przerwy są utrzymywane w pobliżu zera. Utrzymaj także „zespół szybkiego reagowania”, który nie ma zaległości i nie koncentruje się na projekcie / produkcie. Gdy pojawiają się przerwy, zespół szybkiego reagowania radzi sobie z nimi. Gdy nie mają przerw, mogą skupić się na ulepszeniu systemu kompilacji, dodaniu do frameworku testów automatyzacji itp. Ponadto mogą pomóc w recenzowaniu kodu / recenzowaniu projektów i rozwiązywaniu trudnych / nieprzyjemnych błędów, które się pojawiają. Zarządzaj rozwojem, jakby ten zespół nie istniał. Wszystko, co mogą zrobić, to wciągnąć dostawę. Obracaj ludzi przez ten zespół, aby „zachować świeżość” (ludzie lubią / nienawidzą być w zespole szybkiego reagowania ...)

mam nadzieję że to pomoże!

Al Biglan
źródło