Jak działa Scrum, gdy masz wiele projektów? [Zamknięte]

91

Dość dobrze znam zalety i procesy Scruma. Dostaję pomysły dotyczące zaległości, wykresów wypalania, iteracji, wykorzystując historie użytkowników i inne różne koncepcje "frameworka" Scruma.

Mając to na uwadze ... Pracuję dla firmy zajmującej się tworzeniem stron internetowych, która zarządza wieloma projektami jednocześnie, z sześcioma członkami zespołu, którzy tworzą „zespół produkcyjny”.

Jak Scrum działa z wieloma projektami? Czy nadal po prostu planujesz iterację dla pojedynczego projektu w określonym czasie i cały zespół pracuje nad tym, a następnie przechodzisz do następnego projektu z nową iteracją, gdy ta iteracja zostanie zakończona? A może istnieje „zwinny” sposób zarządzania wieloma projektami z ich własnymi iteracjami z tylko jednym zespołem w tym samym czasie?

Tim Knight
źródło
9
Chciałbym wiedzieć, pracuję nad 3+ projektami i muszę robić 3+ SCRUMY dziennie. : płacz:
Chad Grant
To pytanie jest niezwiązane z tematem, ponieważ nie wchodzi w zakres tej witryny, zgodnie z definicją w sekcji Jakie tematy mogę tutaj zadawać? Zobacz także: Jakiego rodzaju pytań powinienem unikać? Możesz zapytać w innej witrynie Stack Exchange , na przykład w zakresie zarządzania projektami lub inżynierii oprogramowania . Przeczytaj stronę na temat w centrum pomocy dla każdej witryny, w której zamierzasz zadać pytanie.
Makyen
3
@Makyen Jedną rzeczą do rozważenia jest to, że to pytanie ma z powodzeniem 8,5 roku i pojawiło się na długo przed istnieniem większości giełd podrzędnych. Tak więc, chociaż temat może być teraz najlepiej obsługiwany przez coś w rodzaju wymiany stosów zarządzania projektami, w tamtym czasie pytanie o praktyki Scruma było niezwykle istotne dla programistów i ich metodologii, jak najlepiej wykonać pracę.
Tim Knight
Zgadzam się, było to rozsądne w czasie, gdy o to pytano. Nie ma nic złego w pytaniu jako pytaniu. W tej chwili to nie jest na temat SO. To, co dotyczy sprawy SO, zmieniło się z biegiem czasu. Chociaż to pytanie jest interesujące dla programistów, nie chodzi głównie o programowanie. Chodzi o proces Scrum, czyli metodę zarządzania projektami, a nie konkretnie programowania. Chodzi o „zarządzanie wieloma projektami… tylko z jednym zespołem…”, którym może być wiele różnych typów projektów. Dlatego należy go zamknąć. Nie głosowałbym za jego usunięciem, ponieważ są tutaj przydatne informacje.
Makyen
2
Głosuję za zamknięciem tego pytania jako niezwiązanego z tematem, ponieważ dotyczy ono praktyk organizacyjnych, a nie programowania.
Kristján

Odpowiedzi:

61

Scrum tak naprawdę nie narzuca, że ​​musisz pracować nad jednym samodzielnym produktem. Po prostu stwierdza, że ​​jest kilka rzeczy do zrobienia (backlog produktu), jest pewien czas rozwoju dostępny w następnej iteracji (obliczony na podstawie prędkości projektu) i są elementy wybrane przez klienta / biznes jako mający największy priorytet z tej puli problemów / zadań, które zostaną wykonane w następnej iteracji (rejestr sprintu).

Nie ma powodu, aby backlog produktu i backlog sprintu musiały pochodzić z jednego projektu - nawet w jednym projekcie będą istnieć odrębne jednostki pracy, które są jak oddzielne projekty - interfejs użytkownika, warstwa biznesowa, schemat bazy danych itp. W szczególności tworzenie oprogramowania dla przedsiębiorstw jest takie, w którym istnieje wiele baz kodu, które muszą być rozwijane. Proces Scrum - spotkania, pytania, wykres spalania itp. - wszystko działa bez względu na to, czy jest to jeden projekt, czy wiele.

To powiedziawszy, w praktyce często dobrze jest mieć główny temat dla każdej iteracji - „zrób moduł raportowania” lub „interfejs z API systemu XYZ” - tak, aby wiele problemów pochodziło z jednego projektu lub obszaru i koniec iteracji, możesz wskazać dużą część pracy i zaznaczyć ją.

Chris Latta
źródło
4
+1: Istotą Scruma jest codzienne stojące spotkanie w celu koordynacji działań. Działa na jednym lub wielu projektach.
S.Lott,
4
Nie zgadzam się z S. Lottem, myślę, że istotą jest sprint, a spotkanie na stojąco to narzędzie do zarządzania sprintem. Uruchomiłbym 6 sprintów lub 1 na projekt.
kenny,
@Kenny: Gdyby to nie było konieczne, czy zrezygnowałbyś z codziennej stand-upu dla każdego oddzielnego projektu? Jeśli tak, co robisz, aby utrzymać przebieg każdego projektu?
S.Lott,
1
@ S.Lott, spotkanie dotyczy problemów, jeśli się pojawiają. Miałbym jednego przeciwnika dla całego zespołu. Nie zaszkodzi informować, a różne / nowe punkty widzenia często mogą być cenne.
kenny
A co z 3 projektami, 3 członkami zespołu, z których każdy opracowuje własną bazę kodu dla różnych właścicieli produktów? Czy w takim razie są 3 zespoły?
jolySoft
25

Myślę, że odpowiedź zależy od „ kto będzie nadawał priorytety elementom zaległości ” (tj. Decyduje, co należy zrobić najpierw). Jeśli jest to jedna osoba, to ta osoba jest właścicielem produktu dla twoich projektów i możesz mieć jeden zaległości dla wszystkich pozycji dla wszystkich projektów - lub zaległości dla każdego projektu - i wybierasz pozycje zaległości ze wszystkich projektów podczas planowania Sprint. W tym przypadku Scrum „działa” dobrze.

Jeśli każdy projekt jest odpowiedzialny, prawdopodobnie napotkasz pewne problemy, w wyniku których każdy z nich - mniej lub bardziej świadomie - będzie próbował faworyzować swój projekt (y). IMHO, musisz mieć tylko jednego właściciela produktu z uprawnieniami do ustalania priorytetów w drodze arbitrażu.

Jedną z zasad, których należy przestrzegać w takim kontekście jest, aby nigdy nie zmieniać treści Sprintu w trakcie Sprintu . W razie potrzeby możesz skrócić iterację do dwóch lub trzech tygodni, aby zmniejszyć ryzyko konieczności dodania pilnej pozycji w bieżącym Sprincie.

filant
źródło
16

Muszę się nie zgodzić. Myślę, że kluczem do tego procesu jest skupienie się zespołu na jednym projekcie podczas sprintu. Jeśli masz specjalistów, którzy nie mogą wnieść wkładu w cały proces rozwoju (autorzy treści, graficy, analitycy procesów biznesowych itp.), Wyrzucałbym ich z zespołu, gdy już nie mogą wnieść wkładu. Albo jeszcze lepiej, przeszkol ich w różnych zadaniach, aby mogli przyczynić się do takich rzeczy, jak testowanie.

Inną rzeczą, o której należy pamiętać, jest to, że równoległe prowadzenie projektów niszczy harmonogram. Rozważ to: dla uproszczenia załóżmy, że mamy 5 projektów wykorzystujących ten sam zespół i rozpoczynających się tego samego dnia. Każdy projekt wymaga 3 miesięcy wysiłku, w najlepszym przypadku równolegle wykonasz je wszystkie na raz i zajmie to 15 miesięcy. Twoja prędkość spadnie, ponieważ w jednym sprincie możesz zmieścić tylko 1/5 miesiąca wysiłku. Będziesz także robić 5 spotkań demonstracyjnych w tym samym czasie. W najlepszym przypadku zrealizujesz 5 projektów w 15 miesięcy, a konkurencja będzie twierdzić, że mogą wykonać tę samą pracę w 3. Twoje zespoły szacujące dojrzałość ucierpią, ponieważ będą w stanie wziąć pod uwagę tylko 20% dostępnej siły roboczej. Może się okazać, że w rzeczywistości nie jesteś w stanie wykonać niektórych zadań w jednym sprincie. Jeśli będziesz musiał zmienić liczbę realizowanych projektów z 5, Twój zespół będzie musiał dostosować swoje nawyki szacowania, co zaszkodzi wydajności zespołów. Dodatkowo, Twój zespół będzie miał trudności z samoorganizacją, gdy proste ponowne przypisanie zadania może wymagać uruchomienia nowego środowiska deweloperskiego, zanim będzie można rozpocząć pracę.

Gdybyś miał uruchomić te same 5 projektów seryjnie, dostarczyłbyś piąty projekt w ciągu tych samych 15 miesięcy, ale uświadomiłbyś klientowi, że Twój zespół jest tak poszukiwany, że masz 12-miesięczne zaległości i możesz z niego korzystać czas na doprecyzowanie celów projektu. Lub jeśli masz ciągłe zaległości, wiesz, że czas zacząć zatrudniać inny zespół. Twój najlepszy projekt kończy się jednak za 3 miesiące z klientem, który zauważył szybką poprawę w aktywnym okresie. Możesz zakończyć ten projekt rok wcześniej i umieścić go w swoim CV. Twoja prędkość sprintu ustabilizuje się w tym okresie i może się okazać, że osiągniesz swój krok po jednym lub dwóch projektach i będziesz w stanie osiągnąć więcej w danym sprincie.

Myślę, że seryjne prowadzenie projektów jest jedną z największych przeszkód dla organizacji próbujących przyjąć twarze scrumów. To poważna zmiana kulturowa związana z dekonstrukcją roli kierownika projektu, ale korzyści płynące z procesu scrum są ogromne.

Pamiętaj, że WSZYSCY nie muszą być pełnoprawnymi członkami zespołu. Mogą angażować klienta w poczekalni, przygotowując się do procesu rozwoju. Moich analityków biznesowych, architektów sieci i grafików pozostaję ekspertami dziedzinowymi i dołączam ich do zespołu tylko w razie potrzeby. Pozwól im działać ze sprintem 0. Zdziwiłbyś się, jak angażująca jest praca nad wyglądem i sposobem działania oraz przepływem pracy. Dobrze jest również przygotować klienta ze zrozumieniem, że kiedy rozwój zaczyna się na dobre, jego poziom uczestnictwa może faktycznie wzrosnąć i ważne jest, aby był dostępny. Poinformuj ich o harmonogramie, aby mieli dużo czasu na zajęcie się takimi rzeczami, jak wakacje i święta z dużym wyprzedzeniem.

anopres
źródło
Działa to tylko wtedy, gdy MOŻESZ ponownie przypisać członków zespołu. Jeśli nie ma dokąd pójść, nie możesz zostawić ich bezczynnych.
BlueChippy
8

Byłem w tej właśnie sytuacji.

Jeśli masz jednego właściciela produktu we wszystkich projektach, Phillipe ma absolutną rację; Jeden sprint z jedną drużyną powinien działać dobrze.

Jeśli masz więcej niż jednego właściciela produktu, najlepiej byłoby, gdyby strona biznesowa wybrała jednego „priorytetyzatora”, któremu powierzono odpowiedzialność za planowanie prac. To zdecydowanie najlepsze rozwiązanie.

Jeśli (jak to prawdopodobnie ma miejsce) firma nie chce zmieniać sposobu ustalania priorytetów (byłoby to zbyt wygodne), możesz podzielić zespół i uruchomić dwa równoległe sprinty. Jednak w przypadku zespołu składającego się z sześciu osób nie podzieliłbym go na więcej niż 3 zespoły (w ogóle nie chciałbym go dzielić, ale myślę, że 2-3 zespoły byłyby sprawne). Dalszy podział, jak sugeruje Kenny, i posiadanie zespołów składających się z jednej osoby wydaje mi się nieco bezcelowe, ponieważ wtedy nie masz już zespołu, tylko indywidualnych programistów.

Jeśli dzielisz zespół, nie znalazłem zbytniej wartości w łączeniu stand-upów, chyba że masz oddzielne sprinty pracujące w większości z tego samego kodu, ale wtedy może to być argument do połączenia tych zespołów w celu sprint.

DanSingerman
źródło
5

Jest jeszcze jedna opinia, o której ostatnio czytałem, a mianowicie, że w środowisku Agile koncepcja projektu może przynosić skutki odwrotne do zamierzonych i można ją wyeliminować. Zgodnie z tym sposobem myślenia, organizacja powinna zamiast tego skupić się na wydaniach . Dzieje się tak, ponieważ Projekty to sztuczne pudełka pracy, które nie mają żadnej wartości, dopóki nie zostaną ukończone. Są sprzeczne z celem Agile, jakim jest częste dostarczanie wartości do wysyłki. Release jest bardziej zgodne z Agile, ponieważ jest zorientowany dostarczanie wartości i dlatego jego zakres może zostać zmniejszona lub rozszerzony na podstawie tego, co zespoły mogą dostarczyć przed kolejnym wydaniu .

Istnieje potencjalny środek, w którym to, co wcześniej nazywano projektem w Twojej firmie, jest teraz przepakowywane jako wspólny motyw lub funkcja zwinna . Zaletą tego podejścia jest to, że motyw lub funkcja można teraz zaimplementować w wartościowych elementach, zgodnie z uznaniem właściciela produktu.

Nadal istnieje kwestia jednego zespołu pracującego nad wieloma Produktami i jest to kwestia uzasadniona obawami o znajomość domeny i możliwe umiejętności techniczne. Ale produkty zbudowane z zwinny, nawet wielokrotne Produkty zbudowane przez jeden zespół, nieustannie gromadząc wydania wartość -able. W przeciwieństwie do tego projekty są nic nie warte, dopóki nie zostaną ukończone (a wiele z nich nie).

Coś do przemyślenia...

Bob Lieberman
źródło
1
Zgoda, powinniśmy minimalizować „zasoby oprogramowania”, które stanowią skumulowaną wartość biznesową, która jeszcze nie została wprowadzona w życie.
AndyM
4

Myślę, że Anopres miał rację: najlepszym sposobem jest unikanie wielu projektów w tym samym czasie ze scrumem. Zrób wszystko, aby przekonać się, że zbyt częste bieganie równolegle nie jest wydajne.

Przyjmijmy 5 projektów po około 3 miesiące dla 5-osobowego zespołu.

Podejście 1: każda osoba pracuje nad jednym projektem w zespole

  • 1/5 szybkości dostawy na projekt daje 15 miesięcy dostawy dla wszystkich projektów
  • Każda osoba jest ekspertem, ale tylko w swoim projekcie
  • Brak ducha zespołowego

Podejście 2: 1 sprint na projekt, przełączanie projektów

  • Co szósty sprint pracuje nad projektem
  • Zbyt długi czas między pracą nad projektem - nie jest to zwykła przyrostowa wartość projektu (w przypadku backlogu produktu tak), łatwo o niej zapomnieć, wysiłek potrzebny do przywrócenia kontekstu,
  • Pierwszy projekt zrealizowany po około 12-13 miesiącach (przy założeniu 2 tygodniowego sprintu)

Podejście 3: 5 projektów w jednym sprincie

  • Wymaga zbyt szczegółowego podziału zadań, aby zmieścić się w sprincie
  • Bardzo mała kompilacja przyrostowa na projekt
  • Dostawa pierwszego projektu po około 12-15 miesiącach

Podejście 4: zalecane - praca seryjna

  • Zespół pracuje nad jednym projektem po projekcie
  • Pierwszy projekt rozpoczął się i został dostarczony po 3 miesiącach
  • Drugi projekt rozpoczął się po 3 miesiącu, dostarczony po 6 miesiącu
  • ...
  • Piąty projekt ruszył po 12 miesiącu, dostarczony po 15 miesiącu
  • Zespół mocno skoncentrowany na projekcie, intensywnych badaniach i współpracy z klientem
  • Cały zespół ma ogólnie dobrą wiedzę na temat wszystkich projektów
  • Nie trać czasu na przełączanie kontekstów
  • Wymagają dobrej współpracy zespołowej (konflikty mogą spowolnić dostarczanie).

Jak widać, rozwiązanie 4 jest generalnie lepsze, ponieważ projekty są dostarczane znacznie szybciej, zespół pracuje razem i wydajnie. Inne podejścia obejmują marnowanie czasu na zmianę kontekstu, brak pełnej współpracy zespołowej, bardzo długi całkowity czas dostawy wszystkich projektów itp.

A co z pielęgnacją zaległości? Jeśli zespół od razu pracuje nad jednym projektem, to jest proste - dołączą wszyscy. Jeśli jest wiele projektów, może być konieczne oddelegowanie pojedynczych osób do oddzielnych sesji pielęgnacyjnych (nie jest zaangażowany cały zespół).

Ważne jest, aby przekonać klientów, że rozpoczęcie drugiego projektu po 3 miesiącach nadal będzie skutkować szybszą dostawą (po 6 miesiącu), a nie wtedy, gdy zaczniemy go od razu ze wszystkimi innymi. Menedżerowie widzą to złudzenie - rozpoczynamy 5 projektów naraz, ciężko pracujemy i sukcesywnie dostarczamy. Ostatecznie nie jest to jednak skuteczne.

Dlatego nie wierzę, że scrum jest skuteczny dla wielu projektów równolegle, bardzo trudno jest dopasować go do frameworka i pracować zgodnie z zasadami scrum. Czasami może być dobrze mieć 2 projekty, aby wszyscy byli zajęci, ale im więcej projektów dodamy, tym mniej efektywny będzie scrum. Może kanban jest alternatywą tylko po to, aby zobaczyć postęp i pracę zespołową (nie tak silną jak w zespole Scrum)?

Pozdrawiam, Adam

Adam Krawczyk
źródło
3

Jak powiedział @Chris, normalny projekt zawiera projekty podrzędne. Masz jednak tylko jeden zaległości.

Pomyśl o zaległościach we wszystkich swoich projektach. Pierwszy problem: czy przypisujesz priorytety zadaniom lub projektom? Wolę zaległości na projekt. Przynajmniej jasne priorytety, które ma właściciel produktu.

Posiadanie różnych właścicieli produktów oraz fakt, że ci właściciele produktów nie zamierzają uzgodnić, ile czasu powinni poświęcić na każdy projekt. „Ktoś” będzie musiał wchłonąć decyzję, jak zarządzać priorytetami międzyprojektowymi. Uwaga: programiści nie powinni tego robić.

Oto nasz kierownik projektu „S”, który zrównoważy zasoby, których potrzebują właściciele produktów, i czas, jaki członkowie zespołu mogą poświęcić. Właściciel produktu A zapłacił za jeden miesiąc pracy, ale właściciel produktu B zawsze aktualizuje swój projekt (i również dobrze płaci). Oto sposób, w jaki zrównoważysz swój zespół, aby A miał jeden miesiąc (czas programisty) i nie powstrzymaj B przed zapełnieniem kieszeni.

W przypadku oprogramowania wewnętrznego (jedna firma, tysiąc projektów). Właściciele różnych produktów powinni uzgodnić przydzielony im czas. Nie mieszkają w odosobnieniu, ale na tej samej łodzi co Ty (kierownik projektu „S”). Ułatwią Ci życie, odkładając niektóre zadania, ale jednocześnie nigdy nie zapominaj o ich potrzebach.

Cóż, wciąż próbuję znaleźć najlepszy sposób, aby to zrobić. Ale to jest to, co teraz naciskamy. Mam nadzieję, że to pomoże.

graffic
źródło
3

Członkowie zespołu mogą dzielić swój czas między projekty scrumowe, ale o wiele bardziej produktywne jest posiadanie członków zespołu w pełni oddanych. Członkowie zespołu mogą również przechodzić z jednego sprintu do drugiego, ale to również zmniejsza produktywność zespołu. Projekty z większymi zespołami są organizowane jako wiele scrumów, z których każdy koncentruje się na innym aspekcie rozwoju produktu, przy ścisłej koordynacji ich wysiłków.

Bharath Krishnamurthy
źródło
0

Sugerowałbym prowadzenie jednego Sprintu dla każdego projektu i organizowanie 1 codziennego spotkania w celu obsługi wszystkich aktywnych źródeł / projektów.

Kenny
źródło
Kenny, więc jeden sprint dla każdego projektu na raz? A może mówisz o prowadzeniu wielu sprintów na raz i dzieleniu zespołu tak, jak sugerują inni?
Tim Knight
Hej Tim, wyobrażałem sobie, że nie zmieniam struktury twojego zespołu, dzieląc zespoły na sprinty, ale po prostu uruchamiaj oddzielne sprinty / zaległości / etc ... dla każdego projektu. Niech każda osoba wypowie się na każdym spotkaniu, o czym się martwi. Dla mnie byłoby miło nadążać za wszystkimi / wszystkim lub być świadomym.
kenny
0

Chciałbym wnieść swój wkład. Oto jak to robię:

  • Na zespół przypada jeden właściciel produktu i jeden rejestr produktu. Właściciel produktu nie musi być jedną osobą, ale ten „podmiot” właściciela produktu jest odpowiedzialny za zaległości w produkcie.
  • Backlog produktu zawiera historie użytkowników każdego projektu (wszystkie projekty tutaj). Każda historia użytkownika ma swój wysiłek / punkty historii (odpowiedzialność zespołu) i wartość biznesową (odpowiedzialność właściciela produktu).
  • Mamy „uwodzenie backlogu produktu” na każdy sprint. Przed tym spotkaniem właściciel produktu zaktualizował wartości biznesowe opowieści (jeśli potrzebują jakiejś zmiany z jakiegokolwiek powodu biznesowego - czego nie mamy i nie powinniśmy się tym przejmować -) i dołączył kilka nowych historii. Podczas tego spotkania nowe historie są wyjaśniane, a wysiłki są również aktualizowane. To spotkanie trwa około godziny (poza pierwszym razem około 4 godzin).
  • Kiedy mamy zamiar zaplanować nowy sprint, otwieramy backlog produktu, porządkujemy historie według zwrotu z inwestycji (to jest wartość biznesowa / wysiłek) i planujemy historie do upływu czasu.

I to wszystko. Mogę powiedzieć, że to działa całkiem nieźle. Używamy do tego kilku arkuszy kalkulacyjnych Google (backlog produktu i sprintu, zarówno z wykresami, jak i innymi rzeczami), a redmine (z określoną semantyczną) dla organizacji online każdego dnia: czas, postęp zadań itp.

Problem z tym podejściem polega na tym, że zduplikowałem zadania w arkuszu kalkulacyjnym backlog sprintu i redmine. Ale nie znajduję żadnego narzędzia online do robienia tego całkowicie online. Brakuje mi zaległości produktowych w Redmine (żadna inna semantyczna dla mnie nie działa), pojedynczej planszy w Jira, więcej historii w tajdze itp.

hosseio
źródło
Jak możesz skupić się na każdym produkcie w zaległości? Tagi, konwencja nazewnictwa itp.? Zaimplementowałem podobne podejście, ale staram się zachować wszystko w TFS i nie znalazłem jeszcze dobrego rozwiązania, które pozwoliłoby na wyświetlanie zaległości i produktów w funkcjach / historiach.
BlueChippy