Plan zarządzania projektami, część 2: Kompleksowe porównanie Waterfall, DAD, SAFe, LeSS i Scrum@Scale

Przegląd

W części 1 planu zarządzania projektami omówiliśmy metodologie tworzenia oprogramowania Lean Software Development, Agile, Scrum i Kanban oraz sposób, w jaki wszystkie one wywodzą się z Lean Manufacturing. Te metodologie są zwykle wdrażane na poziomie jednego zespołu. Jednak złożoność rośnie, gdy projekty i zespoły projektowe stają się większe, a nowe podejścia są potrzebne, aby działać sprawnie na dużą skalę.

W części 2 najpierw zagłębimy się w to, w jaki sposób kierownicy projektów wykorzystują metodologię kaskadową, która jest najpopularniejszym frameworkiem do tworzenia oprogramowania w tradycyjnych firmach. W zestawieniu z tym omówimy najpopularniejsze frameworki, które starają się uwzględniać zasady Agile na dużą skalę – Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) i Scrum@Scale.

Wodospad

Metodologia kaskadowa (znana również jako model cyklu życia oprogramowania (SDLC)) jest bardziej tradycyjną metodologią, w której tworzenie oprogramowania przechodzi kaskadowo z jednej fazy do drugiej jak wodospad. Fazy ​​nie nakładają się i mają określone kryteria wejścia i wyjścia dla przejścia z jednej fazy do drugiej.

Sześć etapów cyklu życia oryginalnego modelu wodospadu to:

1. Wymagania: Na tym etapie definiowane są oczekiwania i cele projektu, a wymagania są szeroko analizowane i dokumentowane, zwykle przez analityka biznesowego. Wymagania są sprawdzane i zatwierdzane przed wyjściem z tej fazy.
2. Projekt: Po zatwierdzeniu wymagań rozpoczyna się praca nad architekturą i zaprojektowaniem produktu w celu spełnienia zatwierdzonych wymagań. Architektura fizyczna, architektura komponentów, projekt bazy danych, szczegółowy komponent, projekt modułu i inne aspekty projektu są dokumentowane przez architekta oprogramowania lub projektanta. Następnie jest sprawdzany i zatwierdzany przed rozpoczęciem wdrażania.
3. Wdrożenie: Po zatwierdzeniu projektu, wdrożenie lub kodowanie oprogramowania zgodnie z wymaganiami i projektem jest wykonywane przez programistów.
4. Weryfikacja: Po zakończeniu wdrożenia oprogramowanie jest testowane przez zespół testowy lub zespół QA w celu upewnienia się, że wymagania i projekt są spełnione oraz że osiągnięto pożądany poziom jakości. Defekty są znajdywane, rejestrowane, selekcjonowane iw wielu przypadkach naprawiane.
5. Wydanie i konserwacja: Po zakończeniu testowania i debugowania produkt jest udostępniany klientowi i instalowany. Często zdarza się runda testów, aby upewnić się, że instalacja się powiodła. Po dostarczeniu produktu ma miejsce ciągła konserwacja i wsparcie, aby zapewnić, że produkt nadal działa zgodnie z przeznaczeniem.

Zalety wodospadu

Wodospad ma pewne zalety i nadaje się do niektórych typów projektów, ale ma też poważne wady. Waterfall najlepiej nadaje się do krótszych projektów, w których wymagania, technologia są dobrze zrozumiane i prawdopodobnie nie ulegną znaczącym zmianom.

W przypadku zastosowania do odpowiedniego typu projektu, niektóre z zalet modelu wodospadu:

• Prostota: Waterfall jest łatwy do wdrożenia dzięki identyfikacji zakresu z góry oraz sztywnym fazom i wyraźnemu przejściu z jednej fazy do drugiej.
• Widoczność: Postęp jest łatwiej mierzony i postrzegany przez interesariuszy, ponieważ pełny zakres pracy jest znany z góry, a projekt przechodzi z jednego etapu do drugiego.
• Dokumentacja: Zakres, wymagania i plany mogą być dokładnie przemyślane i dobrze udokumentowane, co ułatwia mniej doświadczonym zespołom pracę nad projektem.
• Praca etapowa: ze względu na sztywne role i przejście między fazami, zasoby projektu mogą pracować nad innymi projektami, gdy ich faza podstawowa nie jest w toku.

Wady wodospadu

Wodospad nie nadaje się do dłuższych projektów, w których wymagania nie są dobrze zrozumiane i/lub mogą ulec zmianie i/lub gdzie występuje znaczne ryzyko techniczne. W dzisiejszych czasach, w których warunki rynkowe stale się zmieniają, a czas wprowadzania produktów na rynek ma kluczowe znaczenie, dotyczy to większości projektów oprogramowania.

Wady modelu wodospadu, które w większości koncentrują się wokół jego niezdolności do przystosowania się do zmian, obejmują:

• Zakres monolityczny: Wynagradza interesariuszy za myślenie o WSZYSTKIM podczas definiowania zakresu projektu, co prowadzi do zakresu monolitycznego.
• Późne informacje zwrotne od klientów: interesariuszom, a zwłaszcza klientom, trudno jest wyobrazić sobie pełny, szczegółowy zakres projektu. Ponieważ wodospad udostępnia klientom wyniki projektu głównie na jego ostatnich etapach, nieuchronnie trudno jest uwzględnić opinie klientów w projekcie
• Zmiana wymagań: W dłuższych projektach warunki rynkowe, a co za tym idzie cele i wymagania projektu, są obarczone bardzo dużym ryzykiem zmiany w trakcie realizacji projektu.
• Wartość tworzona na końcu: Wodospad wymaga dużo pracy na początku, co oznacza, że ​​wartość powstaje dopiero pod koniec projektu.
• Współzależność faz: wprowadzanie zmian często skutkuje wymaganiami i/lub przeróbkami projektu, które mogą mieć wpływ na inne obszary projektu. Zależność późniejszych etapów od wcześniejszych etapów może sprawić, że drobne zmiany w projekcie będą nieproporcjonalnie trudne.

Zdyscyplinowane zwinne dostarczanie (DAD)

Zdyscyplinowane dostarczanie agile (DAD) zostało sformalizowane przez Scotta Amblera w IBM i Mark Lines i rozwija się na frameworkach agile i scrum, uznając, że niezwinne części organizacji są zwykle zaangażowane w pewne zdolności w dostarczaniu projektu oprogramowania. Ramy te wyraźnie obejmują działania od operacji IT, architektury korporacyjnej, zarządzania portfelem, finansów i zaopatrzenia do pełnego cyklu życia dostawy. DAD ma na celu zwiększenie ogólnej sprawności biznesowej w sposób pragmatyczny.

Główne zasady i komponenty

Role

DAD ma znacznie więcej ról niż scrum i jest podzielony na dwie kategorie ról zespołowych. Pierwotne role pełnią osoby, które stale pracują nad projektem. Role drugorzędne są zwykle wprowadzane tymczasowo, aby pomóc zespołowi w skalowaniu lub innych problemach. DAD pełni te dodatkowe role, ponieważ zajmuje się całym cyklem dostarczania rozwiązania i rozpoznaje różne rodzaje potrzebnych ról tymczasowych i pomocniczych występujących w świecie rzeczywistym

Główne role:

1. Interesariusz: Ktoś, kto jest zależny od Twojego zespołu kończącego projekt: klient, użytkownik końcowy lub kolega wewnętrzny.
2. Członek zespołu: Osoby w zespole, które faktycznie wykonują zaplanowaną pracę: programiści, projektanci, testerzy itp.
3. Lider zespołu: Analogicznie do mistrza scrum, lider zespołu działa jako sługa-lider zespołu, usuwając przeszkody, ułatwiając spójność zespołu i rozpowszechniając zwinne wartości.
4. Właściciel produktu: czasami określany jako „głos klienta”. Właściciel produktu reprezentuje interesariuszy i utrzymuje listę prac do wykonania według priorytetów.
5. Właściciel architektury: Odpowiedzialny za ograniczanie ryzyka związanego z architekturą na dużą skalę. Ta rola jest zwykle wypełniana przez starszego programistę w zespole, ponieważ wymaga głębokiego przygotowania technicznego i solidnej znajomości domeny biznesowej.

Role drugorzędne:

1. Specjalista: Osoby, które tymczasowo dołączają do zespołu, aby pomóc w wyspecjalizowanej roli. Na przykład analityk danych może dołączyć, aby zapewnić możliwości badawcze na wczesnych etapach projektu.
2. Ekspert dziedzinowy: doradcy podatkowi, radcowie prawni i inne osoby, które posiadają specjalistyczną wiedzę dziedzinową i pomagają zespołowi w rozwiązywaniu powiązanych problemów.
3. Ekspert techniczny: administrator baz danych, ekspert ds. bezpieczeństwa kompilacji itp. Ci ludzie pomagają bardziej uogólnionym członkom zespołu w kluczowych momentach cyklu życia.
4. Niezależny tester: Podczas gdy testerzy są zwykle częścią głównego zespołu, w niektórych przypadkach wymagania regulacyjne dotyczące życia lub bardzo złożone systemy, niezależni testerzy pracują równolegle nad walidacją dostarczonych prac.
5. Integrator: Na dużą skalę różne zespoły pracują nad różnymi częściami całego systemu. Integrator pomaga zespołowi zintegrować jego część z całym systemem oraz zarządza zależnościami.

Wsparcie cyklu życia

DAD promuje pełny cykl życia dostawy, nie tylko część programowania i wydania objętą agile/scrum, ale także fazę inicjacji, w której wizja projektu jest definiowana i zatwierdzana oraz fazy wsparcia i wycofania po wydaniu. Obecnie DAD obsługuje 6 różnych cykli życia:

• Zwinny cykl życia: cykl życia projektu oparty na Scrumie
• Cykl życia Lean: cykl życia projektu oparty na Kanbanie
• Ciągłe dostarczanie: zwinny cykl życia
• Ciągłe dostarczanie: szczupły cykl życia
• Cykl eksploracyjny (startup szczupły)
• Cykl życia programu dla zespołu zespołów

Te cykle życia uwzględniają różne style pracy, poziomy sprawności firmy i inne sytuacje, w których mogą się znaleźć zespoły. Najważniejsze jest to, że te cykle życia działają jako sugestie. DAD przedkłada pragmatyzm nad puryzm, ponieważ każda sytuacja jest wyjątkowa, a zdyscyplinowani praktycy Agile powinni dostosować proces Agile do swoich potrzeb.

Cele procesu

DAD stosuje podejście ukierunkowane na cele do tworzenia i dostosowywania zwinnych procesów. Autorzy tej metodologii nakreślają 21 najważniejszych i najczęstszych procesów, z którymi zmierzy się większość zespołów w swoim cyklu życia.

Wszystkie te procesy mają udokumentowane punkty decyzyjne, które będą wymagały od zespołu podjęcia decyzji, jak ustrukturyzować ten proces. Każdy punkt decyzyjny zawiera sugerowane techniki lub praktyki, które można wykorzystać do wdrożenia decyzji. Przykład tego można zobaczyć na poniższym obrazku. Proces „Rozwiń wspólną wizję” obejmuje 6 decyzji, które należy podjąć. Każda z tych decyzji zawiera od 2 do 5 sugerowanych praktyk. Strzałki wskazują, że autorzy DAD uporządkowali listę, przy czym górna pozycja to najlepsza praktyka, a dolna pozycja to najgorsza praktyka na tej liście. Tekst _ pogrubiony kursywa_ oznacza dobre punkty wyjścia dla nowych zespołów, które dopiero zaczynają z DAD.

Skalowanie DAD

Zdyscyplinowane Agile Delivery podchodzi do skalowania z dwóch różnych punktów widzenia:

• Taktyczna zwinność na dużą skalę

• Zwinność strategiczna na dużą skalę

Zwinność taktyczna stara się uwzględnić indywidualne czynniki skalowania zespołu, takie jak wielkość, rozkład geograficzny, złożoność projektu itp., poprzez sytuacyjne zastosowanie celów procesu i sugerowanych praktyk.

Zwinność strategiczna stara się rozwiązać problem skalowania poprzez zastosowanie strategii zwinnych i szczupłych w całej organizacji, rozszerzając ramy tak, aby obejmowały różne obszary organizacji:

• Zdyscyplinowany DevOps: obejmuje korzystanie z metodyki DevOps w celu zapewnienia organizacji bardziej efektywnych wyników.

• Zdyscyplinowane Agile IT (DAIT): obejmuje sposoby zastosowania strategii Agile i Lean we wszystkich aspektach IT.

• Zdyscyplinowane przedsiębiorstwo zwinne:. opisuje, jak zastosować Lean i Agile w całym przedsiębiorstwie.

Bezpieczny

Scaled Agile Framework (SAFe) to obecnie najpopularniejszy, a także najbardziej złożony i wszechstronny skalowany framework Agile. 29% respondentów w Annual State of Agile Report twierdzi, że korzysta z tych ram w swoich organizacjach. Z kolei na rynku jest wielu kierowników projektów SAFe.

Początkiem SAFe była książka Deana Leffingwella „Scaling Software Agility: Best Practices for Large Enterprises”, opublikowana w 2007 roku. Leffingwell jest obecnie głównym metodologiem SAFe, ale wiele innych osób również ma swój wkład w tę strukturę. Obecnie, w wersji 4.6, ten framework przypomina oprogramowanie z obsługą wersji, kompatybilnością wsteczną i różnymi komponentami.

Główne zasady i komponenty

Głównym celem SAFe jest ułatwienie tworzenia i rozwoju szczupłego przedsiębiorstwa, ponieważ uznaje, że wiele różnych rodzajów firm to po części firmy programistyczne, które muszą stale dostarczać wartość w jak najkrótszym, zrównoważonym czasie.

SAFe for Lean Enterprises stara się stworzyć Lean Enterprise, dostarczając bazę wiedzy zawierającą sprawdzone zasady, kompetencje i najlepsze praktyki.

SAFe 4.6 definiuje Pięć Kluczowych Kompetencji Lean Enterprise. Każda kompetencja to zestaw powiązanej wiedzy, umiejętności i zachowań, które razem umożliwiają organizacjom osiągnięcie doskonałości:

1. Przywództwo Lean-Agile : opisuje, w jaki sposób liderzy prowadzą i utrzymują zmiany organizacyjne poprzez uczenie się, nauczanie i wdrażanie sposobu myślenia SAFe Lean-Agile.

2. Zwinność zespołowa i techniczna : opisuje umiejętności, zasady i praktyki potrzebne do tworzenia wydajnych zespołów Agile.

3. DevOps i uwalnianie na żądanie : opisuje, w jaki sposób wdrażanie DevOps i ciągły potok dostarczania zapewnia organizacjom możliwość zwalniania przyrostów produktu w dowolnym momencie niezbędnym do zaspokojenia popytu.

4. Rozwiązania biznesowe i inżynieria systemów lean : opisuje, jak zastosować zasady i praktyki lean-agile do specyfikacji, rozwoju, wdrażania i ewolucji dużych, złożonych aplikacji

5. Zarządzanie portfelem Lean : dostosowuje strategię i realizację, stosując podejścia lean i myślenie systemowe do strategii i finansowania inwestycji, zwinnych operacji portfelowych i zarządzania.

Każda z kluczowych kompetencji jest bezpośrednio odwzorowywana na odpowiedni poziom na diagramie procesu SAFe, z wyjątkiem Lean-Agile Leadership, który obejmuje cały proces.

Kompetencje przywódcze Lean-Agile

Podstawowym celem kompetencji przywódczej Lean-Agile jest pomoc w przekształceniu organizacji w przedsiębiorstwo działające w oparciu o metodykę Lean-Agile. Odbywa się to poprzez uczenie się, ćwiczenie i nauczanie sposobu myślenia SAFe, wartości, zasad i praktyk Lean-Agile.

Podstawowe wartości SAFe kierują transformacją do szczupłego przedsiębiorstwa. Przy każdej okazji zachowanie lidera odgrywa kluczową rolę w ich promowaniu. Podstawowe wartości to:

1. Dostosowanie : komunikuj misję, strategię portfolio i wizję rozwiązania. Przeprowadzaj odpowiednie odprawy i uczestnicz w planowaniu przyrostu programu (PI) i utrzymywaniu zaległości.

2. Przejrzystość : Wizualizuj wszystkie istotne prace.

3. Wbudowana jakość : angażuj się w praktyki, aby zapewnić jakość przez cały cykl życia. Odmów przyjęcia pracy o niskiej jakości. Wspieraj inwestycje w utrzymanie i redukcję zadłużenia technicznego.

4. Realizacja programu : Uczestnicz jako właściciele firm w realizacji PI i ustal wartość biznesową. Upewnij się, że zakres jest dostosowany do popytu i pojemności. Agresywnie usuwaj przeszkody i demotywatory.

Podstawowe wartości SAFe są wspierane przez przyjęcie podejścia Lean-Agile i stosowanie zasad SAFe:

1. Spójrz na ekonomię

2. Zastosuj myślenie systemowe

3. Załóż zmienność; zachowaj opcje

4. Buduj przyrostowo dzięki szybkim, zintegrowanym cyklom uczenia

5. Oprzyj kamienie milowe na obiektywnej ocenie działających systemów

6. Wizualizuj i ograniczaj WIP, zmniejsz rozmiary partii i zarządzaj długościami kolejek

7. Zastosuj rytm, zsynchronizuj z planowaniem międzydomenowym

8. Odblokuj wewnętrzną motywację pracowników wiedzy

9. Zdecentralizuj podejmowanie decyzji

   

Zasady te są podobne do zasad Lean i Agile. Wreszcie, transformacja organizacji jest realizowana zgodnie z Mapą Drogową Wdrażania SAFe.

Kompetencje zespołu i sprawności technicznej/poziom zespołu

Kompetencja Team and Technical Agility opisuje umiejętności, zasady i praktyki potrzebne do tworzenia wydajnych zespołów zwinnych, które tworzą wysokiej jakości rozwiązania. Kluczowe są dwie kluczowe cechy:

• Zwinność zespołu : zespoły przyjmują praktyki i zasady Agile, które umożliwiają im pracę, naukę i dostosowywanie się w niezawodnym rytmie

• Zwinność techniczna : zespoły stosują praktyki techniczne Agile, które zapewniają jakość kodu i komponentów oraz łatwość utrzymania tworzonego kodu\ Jakość jest głównym elementem kompetencji zespołu i sprawności technicznej. Aby to osiągnąć, stosuje się zwinne techniki inżynieryjne, takie jak Behavior Driven Development (BDD) i Test-driven development (TDD), aby zwiększyć jakość i przepływ. Szybki przepływ zależy od jakości budynku w całym systemie, ponieważ błędy mogą poważnie wpłynąć na przepływ i opóźnić zwolnienia.

Poziom zespołu na diagramie SAFe opisuje sposób działania poszczególnych zespołów Agile. Wszystkie zespoły są częścią Agile Release Train, która pracuje nad dostarczeniem Przyrostu Produktu. Ma zastosowanie większość tradycyjnego przepływu Agile/Scrum, w którym zespoły pracują w iteracjach, aby dostarczyć działające systemy. W SAFe wykorzystywane są role Scrum Master, Product Owner i Team, podobnie jak większość działań i artefaktów scrum. Zespoły są również obsługiwane przez role na poziomie programu, takie jak zarządzanie produktem, architekt systemu i inne usługi współdzielone. Kanban służy do wizualizacji przepływu funkcji w cyklu życia dostawy oraz interakcji i przekazywania między zespołami.

DevOps i poziom kompetencji/programu Release on Demand

Kompetencja DevOps i Release on Demand opisuje, w jaki sposób „wdrożenie DevOps i ciągły potok dostaw zapewnia przedsiębiorstwu możliwość uwolnienia wartości, w całości lub w części, w dowolnym momencie niezbędnym do zaspokojenia zapotrzebowania rynku i klientów”.

DevOps pracuje nad dostosowaniem rozwoju, operacji, działalności i innych obszarów do współpracy w celu uzyskania wyników biznesowych. Chociaż nie każda organizacja musi wydawać tak często, jak niektórzy liderzy branży ruchu DevOps (Amazon wydaje co kilka sekund), wszystkie organizacje muszą być w stanie wydać na żądanie.

• DevOps zapewnia podejście do kultury, automatyzacji, lean-flow, pomiaru i odzyskiwania (CALMR), które umożliwia ciągłe dostarczanie i uwalnianie na żądanie

• Agile Release Trains (ART) to zespoły zwinnych zespołów, które są zorganizowane w celu dostarczania wartości na żądanie za pośrednictwem ciągłego potoku dostaw

Poziom programu diagramu opisuje role i czynności potrzebne do ciągłego dostarczania poprzez Agile Release Train (ART) . Ten poziom działa w podobny sposób iteracyjny jak poziom zespołu, ale integruje wiele zespołów zwinnych i obejmuje więcej cykli. ART to zwinny zespół zespołów składający się z 5 do 12 zespołów (50 do 125 osób), w tym tradycyjne role zwinne, a także krytyczne role programowe, takie jak Release Train Engineer (RTE) i Product Management. ART dostarcza 8-12 tygodniowe Przyrosty Programu (PI) , które są planowane przez Planowanie PI i prowadzone przez Kierownika Produktu .

Postęp funkcji PI, eposów itp. jest śledzony i zarządzany za pomocą tablicy Program Kanban. RTE działa jako Scrum Master na ART. Codzienne spotkania synchronizacyjne obejmują zespołowe Daily Standups, Scrum-of-Scrums (RTE i Scrum Masters), PO Sync (Product Management & Product Owner) oraz ART Sync (Scrum-of-Scrums i PO Sync razem). Każdy PI ma Demo Systemu i Retrospektywę.

Kompetencje w zakresie rozwiązań biznesowych i inżynierii systemów Lean/duży poziom rozwiązań

Kompetencja Business Solutions and Lean Systems Engineering opisuje „jak zastosować zasady i praktyki Lean-Agile do specyfikacji, rozwoju, wdrażania i ewolucji dużych, złożonych aplikacji i systemów cyber-fizycznych”.

Oprócz zasad SAFe, kluczem do tej kompetencji jest stosowanie następujących 8 zasad podczas pracy nad dużymi rozwiązaniami:

Poziom dużego rozwiązania zawiera role, artefakty i procesy potrzebne do tworzenia dużych i złożonych rozwiązań. Wiele ART współpracuje w ramach pociągów rozwiązań, aby dostarczać rozwiązania . Główne cele to:

• Zarządzaj częstą integracją

• Nieustannie rozwiązuj problemy dotyczące zgodności

• Architekt pod kątem skali, modułowości, dostępności i serwisowania

Zarządzanie rozwiązaniem kontroluje zawartość rozwiązania, a inżynier szkolenia rozwiązań (STE) kieruje pracą. Solution Architect jest odpowiedzialny za utrzymanie dobrej architektury dla wszystkich ART w Solution. Planowanie przed i po PI służy do planowania rozwiązań dostarczanych za pośrednictwem wielu Przyrostów Programu. Backlog rozwiązania zawiera możliwości i epickie rozwiązania i jest śledzony za pomocą tablicy Kanban rozwiązania

Kompetencja zarządzania portfelem na poziomie portfela/szczupłego portfela

Kompetencja Lean Portfolio Management „dopasowuje strategię i realizację, stosując podejście Lean i myślenie systemowe do strategii i finansowania inwestycji, zwinnych operacji portfelowych i zarządzania”.

Lean Portfolio Management koncentruje się na następujących obszarach:

1. Strategia i finansowanie inwestycji: łączy portfel ze strategią przedsiębiorstwa, finansuje strumienie wartości i ustanawia przepływ portfela

2. Zwinne operacje portfelowe: koordynuje strumienie wartości, realizację programu wsparcia i doskonałość operacyjną

3. Lean governance: prognozuje budżety, mierzy wydajność portfela i egzekwuje zgodność

Poziom portfela zawiera zasady, praktyki i role potrzebne do inicjowania i zarządzania zestawem rozwojowych strumieni wartości. Backlog portfela zawiera epopeje biznesowe i epopeje aktywizujące i jest śledzony za pomocą tablicy Kanban* portfela. **Lean Portfolio Management (LPM) decyduje o tym, jakie strumienie wartości znajdują się w portfelu i obejmuje najwyższych decydentów w przedsiębiorstwie. Architekt korporacyjny kieruje pracą i koordynuje wszystkie strumienie wartości.

Mniej

Rama scrum na dużą skalę (LeSS) została stworzona przez Craiga Larmana i Basa Vodde, którzy oparli go na swoim doświadczeniu w branży finansowej i telekomunikacyjnej. Jak sama nazwa wskazuje, LeSS promuje posiadanie jak najmniejszej liczby procesów i procedur, aby wiele zespołów Scrum współpracowało ze sobą. Skalowanie jest trudne, ponieważ ludzie czynią je złożonymi, więc celem jest uczynienie go tak prostym, jak to tylko możliwe.

Główne zasady i komponenty

„LeSS to Scrum, stosowany w wielu zespołach pracujących razem nad jednym produktem”. LeSS opiera się na dziesięciu zasadach, które wydadzą się znajome każdemu, kto zna zasady Lean-Agile:

1. Scrum na dużą skalę to Scrum

2. Empiryczna kontrola procesu

3. Przezroczystość

4. Więcej za mniej

5. Koncentracja na całym produkcie

6. Skoncentrowany na kliencie

7. Ciągłe doskonalenie w kierunku perfekcji

8. Systemy myślenia

9. Elastyczne myślenie

10. Teoria kolejkowania

LeSS ma tylko dwie główne role, obie zapożyczone ze Scrum:

1. Właściciel produktu: Współpracuje z 2-8 zespołami.
2. Scrum master: Współpracuje z 1-3 zespołami.

Wszystkie zespoły pracują z tym samym rejestrem produktów w sprintach trwających od 1 do 4 tygodni. Zespoły pracują równolegle, co oznacza, że ​​jednocześnie rozpoczynają i kończą sprinty. Pod koniec sprintu zespoły wspólnie dostarczają przyrost produktu . Dla jednego właściciela produktu praca z ośmioma zespołami może wydawać się prawie niemożliwa. LeSS promuje przeniesienie odpowiedzialności za wyjaśnianie pozycji zaległości produktu na zespoły. Z kolei zespoły muszą być wielofunkcyjne i zawierać nie tylko kompetencje w zakresie kodowania, projektowania i testowania, ale także wiedzę z dziedziny biznesu. Co ważniejsze, zespoły muszą mieć możliwość dotarcia do klientów.

Planowanie sprintu

Planowanie podzielone jest na dwie części:

1. Planowanie sprintu 1: Miejsce, w którym przedstawiciele zespołów spotykają się z właścicielem produktu i decydują, które elementy zaległości podejmą i omówią ewentualną współpracę, która może być potrzebna między zespołami podczas sprintu.
2. Planowanie sprintu 2: Tak samo jak w tradycyjnym scrum, każdy zespół zbiera się osobno, aby stworzyć plan, w jaki sposób zostaną wykonane pozycje zaległości.

Udoskonalenie Backlogu Produktu

Udoskonalenie rejestru produktu (PBR) odbywa się podczas sprintu w celu przygotowania pozycji rejestru produktu do planowania sprintu. LeSS nie oferuje zasad przeprowadzania PBR i pozostawia firmom samodzielne ustalenie najbardziej efektywnego procesu. PBR obejmuje trzy kluczowe działania:

1. Dzielenie dużych przedmiotów.
2. Wyszczególniaj elementy, aż będą gotowe.
3. Doceniający.

Koniec sprintu

Pod koniec każdego sprintu dzieją się trzy rzeczy:

1. Przegląd Sprintu: Wspólne demo Sprintu, w którym zespoły i klienci badają, co zostało zrobione podczas Sprintu i co należy zrobić dalej.
2. Retrospektywa: Każdy zespół przeprowadza własną retrospektywę, aby ulepszyć swój proces.
3. Ogólna retrospektywa: Zespoły, właściciele produktów i mistrzowie scrum spotykają się, aby sprawdzać i dostosowywać praktyki organizacyjne, aby były bardziej efektywne.

Scrum@Skala

Scrum at Scale i Scrum@Scale są używane zamiennie. Metodologia ta została wprowadzona przez Jeffa Sutherlanda w 2014 roku, który stworzył metodologię Scrum i był jednym z sygnatariuszy Manifestu Agile.

Scrum@Scale traktuje Scrum jako punkt wyjścia i oferuje proste, lekkie ramy do skalowania Scrum z „minimalną realną biurokracją”. Jest mniej nakazowy niż inne skalowane metodologie Agile i może być uważany za meta-ramę. Podkreśla problemy i obszary związane ze skalowaniem oraz oferuje mentalne ramy, w jaki sposób można je rozwiązać.

Główne zasady i komponenty

Scrum@Scale to framework, który radykalnie upraszcza skalowanie, używając Scruma do skalowania Scruma. W Scrumie „co” (właściciel produktu) jest wyraźnie oddzielone od „jak” (scrum master). Ta sama strategia jest stosowana w Scrum@Scale, aby jurysdykcja i odpowiedzialność były dobrze zrozumiane, eliminując marnotrawstwo i konflikty.

Scrum@Scale zawiera dwa cykle wyraźnie oddzielające jurysdykcje: cykl Scrum Master i cykl Właściciela Produktu z dwoma punktami styku: Proces na poziomie zespołu i Informacja zwrotna o wydaniu produktu.

Cykl Mistrzowski Scrum

Cykl scrum master odpowiada za to, jak będą budowane rzeczy, które zidentyfikowano w cyklu właściciela produktu. W Scrum@Scale poszczególne zespoły Scrumowe pełnią te same role, artefakty, czynności i ceremonie, co tradycyjny Scrum.

Zespoły Scrumowe są pogrupowane w Scrum of Scrums (SoS) , które wspólnie odpowiadają za tworzenie wspólnego przyrostu produktu. Uczestniczą we wspólnym opracowywaniu i ustalaniu priorytetów zaległości, przeprowadzają retrospektywy, utrzymują zaległości związane z utrudnieniami i przeprowadzają SDS (Scaled Daily Scrum) (podobny w formacie do codziennego scrum), aby koordynować zespoły i usuwać blokady. W SDS uczestniczy co najmniej jeden przedstawiciel (zwykle scrum master zespołu) każdego z uczestniczących zespołów i jest prowadzony przez mistrza Scrum of Scrums (SoSM) , który jest odpowiedzialny za koordynację z zespołami scrumowymi i właścicielami produktów.

Jeśli potrzebne jest dalsze skalowanie, istnieje scrum scrumów (SoSoS) utworzony z wielu SoS, które również spotykałyby się codziennie i tak dalej. Ogólnym liderem jest Zespół Działań Wykonawczych (EAT) , który jest odpowiedzialny za promowanie Agile w organizacji, koordynację zespołów Scrum w razie potrzeby oraz za bycie ostatnim przystankiem w usuwaniu przeszkód.

Cykl właściciela produktu

Cykl Właściciela Produktu jest odpowiedzialny za to, jaki produkt lub usługa zostanie stworzona i wszystkie działania niezbędne do tego. Właściciele Produktu są przypisani do zespołów Scrumowych i wykonują wszystkie czynności związane z ich rolą określoną w Scrumie. Właściciele produktów są pogrupowani w zespoły właścicieli produktów , które są mapowane na zespoły SoS. Zespoły Właścicieli Produktu spotykają się codziennie na Meta Scrumie , aby omówić strategię wysokiego poziomu dla zespołów i koordynować w razie potrzeby z odpowiednim SoSM oraz innymi właścicielami produktów i interesariuszami. Meta Scrumy są prowadzone przez Głównego Właściciela Produktu (CPO) .

Product Ownerzy skalują się w podobny sposób do cyklu scrum master, w zależności od wielkości organizacji, i osiągają kulminację w Executive Meta Scrum (EMT) , który jest odpowiedzialny za ustalanie priorytetów w całej firmie.

Implementacja Scrum@Scale

Wdrożenie Scrum@Scale rozpoczyna się od stworzenia skalowalnego modelu referencyjnego, czyli małego zestawu zespołów wykorzystujących scrum na małą skalę. Odbywa się to w celu rozwiązania wszelkich zasad organizacyjnych i praktyk rozwojowych, które utrudniają zwinność. Scrum@Scale sugeruje rozwiązanie tych problemów wcześnie, ponieważ wszystkie zespoły prawdopodobnie zmierzą się z problemami ogólnoorganizacyjnymi, a wynikające z tego frustracje mogą utrudnić przyjęcie metodyki Agile. Model referencyjny jest następnie wykorzystywany jako wzorzec do skalowania scrum do innych zespołów i działów.

W celu wdrożenia modelu referencyjnego należy najpierw utworzyć zespół wykonawczy (EAT). EAT składa się z osób, które są politycznie i finansowo upoważnione w organizacji, ponieważ będą w stanie wdrożyć zmiany w polityce organizacyjnej.

Wniosek

W tej drugiej części planu zarządzania projektami omówiliśmy niektóre z najpopularniejszych frameworków używanych w większych projektach lub programach. Waterfall jest nadal szeroko stosowany w wielu organizacjach i chociaż ma wiele wad ze względu na nieelastyczne procesy, czasami warto korzystać z tych ram, gdy projekty są małe, a ich zakres jest dobrze zdefiniowany i mało prawdopodobne, aby się zmienił.

Ponieważ firmy napotykają większe, bardziej złożone projekty o stale zmieniających się wymaganiach lub celach, zwracają uwagę na bardziej zwinne podejścia. Ponieważ Agile był pierwotnie przeznaczony dla małych zespołów składających się z 5-9 osób, różni praktycy Agile mają wiele sposobów na skalowanie Agile od pojedynczych zespołów, przez wiele zespołów, aż po całe przedsiębiorstwo. W tym artykule omówiliśmy Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) i Scrum@Scale.

W końcowej części planu zarządzania projektami omówimy kilka frameworków specyficznych dla zarządzania projektami, takich jak PMP (PMBOK) i PRINCE2. Omówimy również niektóre procesy i ramy innowacji, takie jak „zadania do wykonania” (JTBD) i „myślenie projektowe”.