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?
źródło
Odpowiedzi:
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ą.
źródło
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.
źródło
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.
źródło
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.
źródło
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...
źródło
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
Podejście 2: 1 sprint na projekt, przełączanie projektów
Podejście 3: 5 projektów w jednym sprincie
Podejście 4: zalecane - praca seryjna
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
źródło
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.
źródło
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.
źródło
Sugerowałbym prowadzenie jednego Sprintu dla każdego projektu i organizowanie 1 codziennego spotkania w celu obsługi wszystkich aktywnych źródeł / projektów.
źródło
Chciałbym wnieść swój wkład. Oto jak to robię:
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.
źródło