Skip to main content

Nexus to prosty i minimalistyczny framework (w bardzo pozytywnym znaczeniu tych słów), który skaluje Scrum na wiele zespołów w celu dostarczenia jednego zintegrowanego produktu. Według autorów, można go zastosować dla 3–9 zespołów Scrumowych, które pracują we wspólnym środowisku programistycznym i skupiają się na tworzeniu łącznego przyrostu w każdym Sprincie przy minimalnych zależnościach.

Artefakty w Nexus Framework:

  • Jeden Product Backlog produktów Nexusa dla wszystkich zespołów Scrumowych
  • Indywidualny Sprint Backlog dla każdego Scrum Team
  • Nexus Sprint Backlog to zbiór pojedynczych Sprint Backlogów per Scrum Team. Pełni rolę planu Sprintu NEXUSa, który jest pomocny w identyfikowaniu. przeglądaniu i podkreślaniu zależności między zespołami Scrumowymi.

Zespoły i Role w Nexus Framework

  • Klasycznie mamy role Product Owner, Scrum Master oraz samo-zarządzalne i wielofunkcyjne zespoły Scrumowe. Istnieje jeden Product Owner, który prowadzi cały produkt. Mogą być wspierani przez analityków biznesowych lub inżynierów systemowych. Scrum Mastarzy są odpowiedzialni za usprawnianie swoich zespołów. Klasycznie, każdy zespół Scrumowy jest cross-funkcjonalny.
  • Rdzeniem frameworka Nexus jest Zespół ds. Integracji Nexus (NEXUS Integration Team), który składa się z Product Ownera, Scrum Mastera i jednego lub większej liczby członków z każdego zespołu. Dodatkowo członkowie zespołu mogą obejmować coachów i trenerów, którzy zapewniają płynną integrację i śledzenie pracy wykonanej przez zespoły Scrumowe. Celem zespołu integracyjnego jest koordynacja pracy wszystkich zespołów Scrum, aby mieć pewność, że ich ukończone prace będą ze sobą współgrać i będą w harmonii, a nie konflikcie (ale nie wykonuje integracji za zespoły Scrumowe). Potrzeba zespołu integracyjnego staje się tym bardziej niezbędna, im większa jest liczba zespołów Scrum pracujących nad tym samym projektem przy użyciu tego samego portfela produktów. Jeśli pojawią się jakiekolwiek problemy z integracją, jeden lub dwóch członków zespołu każdego zespołu Scrumowego spotyka się z zespołem integracyjnym w celu znalezienia rozwiązania.

Planowanie w Nexusie

Zespoły wybierają PBIe z Nexus Product Backlog. Klasycznie, backlog może zawierać historie, zadania, inicjatywy biznesowe, epiki lub dowolne elementy dowolnej wielkości, które odpowiadają zespołom.

Pozycje w rejestrze produktów są stale udoskonalane, aby zminimalizować lub usunąć zależności. Można również dodać nowe wymagania. Obejmuje to również dokonanie odpowiednich oszacowań punktów historii.

Product Owner odpowiada za Nexus Product Backlog, ale jeśli wielkość zespołów przekroczy możliwości Product Ownera, może on/ona przekazać niektóre ze swoich zadań (ale nie odpowiedzialności) zespołom Scrum, analitykom biznesowym, kierownikom projektów lub innym rolom.

Planowanie Sprintu składa się z dwóch części:

  • W pierwszej części Zespół Nexus przeprowadza sesję planowania Sprintu, w której planuje większy obraz / horyzont projektu. Informacje i podejmowane decyzje są przekazywane zespołom Scrumowym. Zależności są wyszukiwane i identyfikowane. Zespół Nexus i zespoły Scrumowe pracują zsynchornizowane.
  • Zespoły Scrumowe mają swoje indywidualne sesje planowanie / Sprint Planningi. Podczas Planowania Sprintu zespoły współdziałają i współpracują ze sobą, aby zwiększyć prawdopodobieństwa osiągnięcia Celu Sprintu NEXUSA i swoich indywidualnych Celów Sprintu. Po zakończeniu planowania PBIe w Sprincie są gotowe dla wszystkich zespołów Scrumowych w Nexus Sprint Backlog.

Rozwój w Nexusie

Wiele zespołów Scrumowych pracuje w zbiorowym środowisku pracy, aby stworzyć zintegrowany produkt. Zespoły konsekwentnie (dzień w dzień) integrują swoją pracę. Zespół ds. Integracji Nexus odgrywa bardzo zdrową rolę, zapewniając, że zespoły pozostają w harmonii ze sobą, ale nie wykonuje integracji za zespoły.

Codzienny Scrum Nexusa ma miejsce, gdy Zespół Nexusa i odpowiedni zespół 1–2 członków Scrum mają sesję scrum. Celem tego spotkania jest koordynacja wszelkich wyzwań i zależności dnia, o których powinny wiedzieć wszystkie zespoły. Następnie codziennie odbywają się Codzienne Scrumy dla każdego zespołu Scrumowego.

Przegląd Sprintu Nexusa odbywa się naturalnie na końcu Sprintu, podczas którego wszystkie zespoły Scrumowe spotykają się z Product Ownerem i przeglądają zintegrowany Przyrost Produktu. Zespoły Scrumowe nie mają Review Sprintu. Istnieje tylko jedno zbiorowe Sprint Review, w której przedmiotem jest zintegrowany przyrost.

Wreszcie jest Retrospektywa Nexus Sprint. Istotą każdej Retrospektywy jest identyfikacja wspólnych wyzwań i przeszkód oraz obszarów do usprawnień. Rozwiązania omawia się, dzieląc się pomysłami i sposobami ich ulepszenia. Następnie Nexus Team i zespoły Scrumowe mają swoje indywidualne Retrospektywy. NA koniec jest zbiorowa Retrospektywa, w której rozwiązania są dzielone z całym Nexusem i zespołami Scrumowymi.

Nexus w pigułce

Nexus promuje minimalizm zamiast rozłożystość i wielkość. Jest to struktura skalowania, która niewiele mówi się o interesariuszach. Podobnie NEXUS nie wspomina o transformacji całej organizacji na dużą skalę.

Jeden wielofunkcyjny zespół Scrumowy jest warunkiem wstępnym Nexusa. Posiadanie wiedzy i doświadczenia w środowisku Scrum daje przewagę w pracy z Nexusem. Promuje i zapewnia przejrzystość, ciągłą integrację i ciągłe doskonalenie.

Posiadanie jednego Nexus Product Backlogu i Nexus Sprintu zapewnia przejrzystość, ponieważ wszystkie informacje ze Sprintu zespołów można łatwo wizualizować zapewniając transparencję. A codzienne Scrumy jak w klasycznym Scrumie, poprawiają komunikację i pomagają usuwać zależności.

Praca we wspólnym środowisku, w którym praca jest stale, codziennei integrowana w jeden produkt końcowy, gwarantuje ciągłą integrację. Zespoły używają automatyzacji do zarządzania wszelkimi złożonościami. Zespoły ds. Integracji Nexus zapewniają zespołom niezbędne wsparcie, mentoring i coaching, aby utrzymać je w synchronizacji. Możne pokusić się o stwierdzenie, że eliminuje to w ten sposób potrzebę spotkania Scrum of Scrums, które są istotną częścią innych struktur skalowania.

W przypadku architektury Nexus nie zaprzecza stosowania architekta korporacyjnego, ale milczy na temat pełnienia takiej roli w zespole integracyjnym. Kładzie również nacisk na dostosowanie się do zmieniających się wymagań za pomocą zespołów wielofunkcyjnych i wyeliminowanie marnotrawstwa dzięki Lean-Thinking. Zespoły potwierdzają nieustanne doskonalenie za pomocą działań, takich jak Product Backlog Refinement, Sprint Review i Sprint Retrospective.

Miroslaw Dabrowski

Enterprise-Lean Agile Coach

Subscribe To Our Newsletter

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

GDPR EN

You have Successfully Subscribed!