Nexus: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
Linia 26: | Linia 26: | ||
==Bibliografia== | ==Bibliografia== | ||
* Schwaber K., Sutherland J., (2020), ''The | * Schwaber K., Sutherland J., (2020), ''The scrum guide the definitive guide to scrum: the rules of the game'', Scrum.org | ||
* Schwaber K., (2021), ''Nexus | * Schwaber K., (2021), ''Nexus guide: the definitive guide to Nexus: The exoskeleton of scaled scrum development'', Scrum.org | ||
{{a|Sylwia Firszt}} | {{a|Sylwia Firszt}} | ||
[[Kategoria:Zarządzanie projektami]] | [[Kategoria:Zarządzanie projektami]] |
Wersja z 18:22, 24 kwi 2021
Zarządzanie projektami w sposób zwinny zyskało na popularności w ostatnich latach, a zainteresowaniem cieszyły się nawet w coraz większych organizacjach. Jednak skorzystanie z tej metodyki wymaga doprecyzowania w przypadku projektów, gdzie zaangażowanych osób jest kilkanaście czy nawet kilkadziesiąt. Naprzeciw wyszły skalowalne metodologie, takie jak SAFe, LeSS, Nexus, Scrum at Scale czy model Spotify. Zatem w sytuacji, gdy przewidujemy, że nasz projekt będzie przynosił lepsze rezultaty korzystając ze zwinnych metodyk zarządzania w tym momencie mamy szereg opcji do wyboru, z których możemy skorzystać, gdy po uważnej analizie uznamy, że w naszej organizacji jest to opłacalne i ma sens. [1]
Nexus jest propozycją, która została przygotowana przez organizację scrum.org w 2015 roku. Jego twórcą jest Ken Schwaber, który znany jest również wraz z Jeffem Sutherlandem z opracowania ram postępowania scrum. Podstawą metodyki podobnie jak w przypadku scuma jest przewodnik Nexusa. Książka autorstwa Kena Schwabera opublikowana pod przewodnictwem organizacji scrum.org nosi tytuł – „Nexus Guide: The Definitive Guide to Nexus: The exoskeleton of scaled Scrum development”. Przewodnik powstał w 2015 roku i od tego czasu zyskała już dwie aktualizację, pierwszą w 2018, druga miała miejsce w 2021. [2]. Nexus jest rozwinięciem ram postępowania scrum i bezpośrednio z niego korzysta, tylko rozszerzając jego bazowe elementy. Jest propozycją, która daje możliwość na zaimplementowanie rozwiązania dla projektów rozbudowanych, wielkoskalowych. Celem całej metodyki jest zorganizowanie pracy dla wielu zespołów scumowych, których praca oparta jest na tym samym backlogu produktu. [3]. Sam autor tej metodyki opisuje ją jako „model postępowania pomocny w wytwarzaniu i utrzymywaniu produktów oraz w prowadzeniu inicjatyw związanych z produkcją oprogramowania dużej skali”. Tak więc możemy go rozumieć jako dodatkową warstwę, która ma zastosowanie przy rozwijaniu jednego backlogu produktu przez wiele zespołów korzystających z ram postępowania scrum. Nexus pozwala na rozszerzenie tego co proponuje scrum, a poprzez rozbudowanie jego narzędzi daje możliwość na zbudowanie współpracy pomiędzy wieloma zespołami scrumowymi, które współpracują nad iteracyjnym rozwojem tego samego backlogu produktowego [4].
Metodyka Nexus jak już zostało wspomniane swoje podstawy znajduje w scrumie, jej celem jest rozbudowanie celów i założeń tych ram postępowania na większą skalę. Oznacza to nic innego niż wdrożenie tych samych podstaw dla całej grupy zespołów, skalując wartości jakie mógłby dostarczyć jeden zespół na wiele zespołów, które wspólnie pracują nad tym samym backlogiem produktowym. Jest to osiągalne poprzez zminimalizowanie złożoności współpracy przez wielozespołowe środowisko pracujące w tym samym czasie nad dostarczaniem wspólnie zintegrowanego przyrostu produktowego, który jest celem każdego sprintu. Nexus wspomaga zespoły w organizowaniu im pracy w takim środowisku, które są charakterystyczne dla skalowania rozwiązań, czyli między innymi redukowania zależności między zespołowych, braku przejrzystości czy utrzymaniu zaangażowania na odpowiednim poziomie. Nexus pomaga w zorganizowaniu przejrzystych zależności, które często są zaburzone z powodu niedopasowaniami w obrębie struktury produktu i komunikacji. Metodyka w tej kwestii proponuje sposób w jaki można zorganizować proces, strukturę produktu czy też komunikacji w organizacji, aby ograniczyć lub całkowitej zredukować zaistniałe zależności (K. Schwaber 2021, s. 4).
Jak już zostało zaznaczone Nexus, jest rozszerzeniem scruma, wspomniane rozbudowanie pojawia się w trzech obszarach. Warto więc tutaj przypomnieć, że scrum są to proste ramy postępowania, którego podstawą są trzy role – właściciel produktu, scrum master oraz zespołu deweloperów. Posiada on cztery charakterystyczne zdarzenia, którymi są planowanie, przegląd i retrospektywa sprintu oraz codzienny sprint. Scrum również posiada trzy artefakty, którymi są przyrost, backlog produktu oraz sprintu (K. Schwaber, J. Sutherland, 2020, s. 5-11).
Pierwszym poszerzonym elementem w obrębie metodyki Nexus są odpowiedzialności między zespołowe, a dokładniej pojawia się w strukturze nowy zespół, tak zwany zespół integracyjny nexus. Rolą tego dodanego zespołu jest zapewnienie, aby współpracujące zespoły wspólnie stworzyły zintegrowany i wartościowy przyrost na koniec każdej iteracji, czyli sprintu. W skład wspomnianego zespołu wchodzi właściciela produktu, scrum master oraz dodatkowe osoby będące jego członkami. W obrębie wydarzeń nie pojawiają się diametralne zmiany w porównaniu do podstawowej wersji ram postępowania scrum. Zdarzenia są rozszerzane na potrzeby skalowalnych praktyk lub zastępują te już zdefiniowane w podstawowych założeniach scruma. W przypadku zdarzenia, którym jest sprint nie pojawiają się żadne zmiany, definicja jest niezmienna w porównaniu do podstawowych ram postepowania. Opisywany on jest jako okres czasu, podczas którego następuje wytwarzanie przyrostu produktowego. Planowanie sprintu nexus jest zdarzeniem, które pozwana na koordynację planu pracy wszystkich zespołów współpracujących ze sobą. Stworzony podczas wydarzenia plan dotyczy pojedynczej iteracji oraz powinien posiadać jednoznaczny cel (jeden bądź wiele). W celu codziennej koordynacji pracy wszystkich zaangażowanych zespołów pojawia się tak znany Codzienny Scrum nexus. Spotkanie pozwala zespołom na zintegrowanie ich pracy oraz regularnego upewniania się, czy cele całej iteracji są osiągalne oraz rozwiązywaniu pojawiających się problemów, które mogłyby uniemożliwić ich osiągnięcie. Na koniec każdej iteracji pojawia się wydarzenie – przegląd sprintu nexus. Jest to moment, w którym zaangażowane zespoły prezentują przyrost pracy nad produktem przygotowany w czasie trwania pojedynczej sprintu. Na końcu każdej iteracji zespoły spotykają się w celu przeanalizowania pracy wykonanej w czasie sprintu. Zdarzenie to nosi nazwę retrospektywy sprintu nexus. Na podstawie wysnutych wniosków zespoły wspólnie planują zmiany w procesie, które powinny skutkować zwiększeniem efektywności ich pracy. Przewodnik po nexusie definiuje również jedno dodatkowe zdarzenie, którym jest zespołowe doskonalenie backlogu produktu. Zdarzenie pozwala na zredukowanie zależności między zespołowych i pozwana na zrozumienie elementów przez wszystkich członków poszczególnych zespołów. Wydarzenie pozwana na ustalenie który zespół będzie odpowiedzialny za jakie zadanie czy też pozwala na identyfikację występujących zależności pomiędzy współpracującymi zespołami. Tylko odpowiednio przygotowany backlog, który jest jednoznaczny i przejrzysty dla wszystkich członków zespołów pozwala na optymalną pracę podczas planowania sprintu nexus. Artefakty w obrębie metodyki Nexus są tylko rozszerzone w porównaniu do podstawy, którą jest scrum. Reprezentują one pracę i wartości generowane przez zespoły oraz pomagają w zmaksymalizowaniu przejrzystości pracy między zespołowej. Jak już zostało wspomniane wszystkie zespoły pracuje nad jednym, tym samym backlogiem produktu. Zawiera on listę zadań, które mają na celu udoskonalenie produktu, a elementy są ułożone w odpowiedniej kolejności. Zarówno za treści jak i kolejność fragmentów backlogu jest odpowiedzialny właściciel produktu. Podstawą backlogu jest cel produktu, który jest długoterminowym zobowiązaniem dla wszystkich zespołów, które powinno zosrać osiągnięte w ramach przygotowania poszczególnych elementów backlogu. Drugim artefaktem pojawiającym się w metodyce jest backlog sprintu nexus, który składa się z elementów backlogu produktu wyszczególnionego na podstawie backlogów sprintów wszystkich zaangażowanych zespołów scrumowch oraz celu sprintu nexus. Wspomniany cel nie jest niczym innych zobowiązaniem zatwierdzonym przez poszczególne zespoły na temat przyrostu pracy jaki powinien zostać dokonany w konkretnej iteracji. Ostatnim artefaktem wymienionym w przewodniku po metodyce Nexus jest zintegrowany przyrost, który reprezentuje całość pracy wykonanej przez wszystkie współpracujące zespoły, aby osiągnąć cel produktu. Wspomniany przyrost produktowy jest dostarczany przez zespoły na koniec każdego sprintu do interesariuszy (K. Schwaber 2021, s. 5-10).
Podsumowując Nexus to metodyka, która rozszerza ramy postępowania Scrum, poprzez rozbudowanie jest ról, wydarzeń i artefaktów w celu ich dostosowania do projektów na dużą skalę. Dzięki temu możliwa jest integracja wielu zespołów zwinnych wspólnie rozwijających jeden backlog produktowy [5].
Przypisy
- ↑ Kaczor K. (2019) Skalowanie Scrum — jak zacząć?
- ↑ Scaling Scrum with Nexus (2021)
- ↑ Nexus Framework (2021)
- ↑ Ochmańska H. (2019) Na czym polega Nexus?
- ↑ Scaling Scrum with Nexus (2021)
Bibliografia
- Schwaber K., Sutherland J., (2020), The scrum guide the definitive guide to scrum: the rules of the game, Scrum.org
- Schwaber K., (2021), Nexus guide: the definitive guide to Nexus: The exoskeleton of scaled scrum development, Scrum.org
Autor: Sylwia Firszt