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

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ś?

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.

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.

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.

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!

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.

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!