Nexus: Różnice pomiędzy wersjami
mNie podano opisu zmian |
Nie podano opisu zmian |
||
| Linia 1: | Linia 1: | ||
'''Nexus''' jest metodyką, która swoje podstawy znajduje w ramach postępowania Scrum. 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). | '''Nexus''' jest metodyką, która swoje podstawy znajduje w ramach postępowania [[Scrum]]. 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). | ||
==Geneza skalowalności metodyk zwinnych== | ==Geneza skalowalności metodyk zwinnych== | ||
Zarządzanie projektami w sposób zwinny zyskało na popularności w ostatnich latach, a zainteresowaniem cieszyły się 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 [[Scaled agile framework|SAFe]], [[Large-scale scrum|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 (M. Alqudah, R. Razali 2016, s. 828). | [[Zarządzanie]] projektami w sposób zwinny zyskało na popularności w ostatnich latach, a zainteresowaniem cieszyły się 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 [[Scaled agile framework|SAFe]], [[Large-scale scrum|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 (M. Alqudah, R. Razali 2016, s. 828). | ||
<google>t</google> | <google>t</google> | ||
'''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 [[Metodyka SCRUM|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 <ref> ''[https://www.scrum.org/resources/scaling-scrum Scaling Scrum with Nexus]'' (2021) </ref>. 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 <ref> ''[https://www.agilest.org/scaled-agile/nexus-framework/ Nexus Framework]'' (2021) </ref>. 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 <ref> Ochmańska H. (2019) ''[https://bulldogjob.pl/articles/1120-na-czym-polega-nexus Na czym polega Nexus?]'' </ref>. | '''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 [[Metodyka SCRUM|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 <ref> ''[https://www.scrum.org/resources/scaling-scrum Scaling Scrum with Nexus]'' (2021) </ref>. 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 <ref> ''[https://www.agilest.org/scaled-agile/nexus-framework/ Nexus Framework]'' (2021) </ref>. 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 <ref> Ochmańska H. (2019) ''[https://bulldogjob.pl/articles/1120-na-czym-polega-nexus Na czym polega Nexus?]'' </ref>. | ||
==Role, wydarzenia i artefakty== | ==Role, wydarzenia i artefakty== | ||
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ą: | 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ą: | ||
* '''Role''' – właściciel produktu, scrum master oraz zespołu deweloperów. | * '''Role''' – [[właściciel]] produktu, [[scrum master]] oraz zespołu deweloperów. | ||
* '''Wydarzenia''', którymi są planowanie, przegląd i retrospektywa sprintu oraz codzienny sprint | * '''Wydarzenia''', którymi są [[planowanie]], [[przegląd]] i [[retrospektywa]] sprintu oraz codzienny [[sprint]] | ||
* '''Artefakty''', którymi są przyrost backlog produktu oraz sprintu (K. Schwaber, J. Sutherland, 2020, s. 5-11). | * '''Artefakty''', którymi są [[przyrost]] [[backlog]] produktu oraz sprintu (K. Schwaber, J. Sutherland, 2020, s. 5-11). | ||
==Rozszerzenia w zakresie ról== | ==Rozszerzenia w zakresie ról== | ||
| Linia 16: | Linia 16: | ||
==Rozszerzenia w zakresie wydarzeń== | ==Rozszerzenia w zakresie wydarzeń== | ||
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 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 postępowania. Opisywany on jest jako okres czasu, podczas którego następuje wytwarzanie przyrostu produktowego. | W przypadku zdarzenia, którym jest '''sprint''' nie pojawiają się żadne zmiany, [[definicja]] jest niezmienna w porównaniu do podstawowych ram postępowania. 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). | '''[[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. | 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 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. | ||
Podsumowaniem iteracji jest '''retrospektywa sprintu nexus''', czyli moment w którym zespoły spotykają się w celu przeanalizowania pracy wykonanej w czasie sprintu. Na podstawie wysnutych wniosków wspólnie planują zmiany w procesie, które powinny skutkować zwiększeniem efektywności ich pracy. | Podsumowaniem iteracji jest '''retrospektywa sprintu nexus''', czyli moment w którym zespoły spotykają się w celu przeanalizowania pracy wykonanej w czasie sprintu. Na podstawie wysnutych wniosków 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 (K. Schwaber 2021, s. 6-8). | 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 (K. Schwaber 2021, s. 6-8). | ||
==Rozszerzenia w zakresie artefaktów== | ==Rozszerzenia w zakresie artefaktów== | ||
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. | 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''', który jest jednym z artefaktów metodyki Nexus. 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 zostać osiągnięte w ramach przygotowania poszczególnych elementów backlogu. | Jak już zostało wspomniane wszystkie zespoły pracuje nad jednym, tym samym '''backlogiem produktu''', który jest jednym z artefaktów metodyki Nexus. 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 zostać 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. | 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. 8-10). | 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. 8-10). | ||
Wersja z 07:56, 25 lut 2022
Nexus jest metodyką, która swoje podstawy znajduje w ramach postępowania Scrum. 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).
Geneza skalowalności metodyk zwinnych
Zarządzanie projektami w sposób zwinny zyskało na popularności w ostatnich latach, a zainteresowaniem cieszyły się 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 (M. Alqudah, R. Razali 2016, s. 828). 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 [1]. 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 [2]. 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 [3].
Role, wydarzenia i artefakty
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ą:
- Role – właściciel produktu, scrum master oraz zespołu deweloperów.
- Wydarzenia, którymi są planowanie, przegląd i retrospektywa sprintu oraz codzienny sprint
- Artefakty, którymi są przyrost backlog produktu oraz sprintu (K. Schwaber, J. Sutherland, 2020, s. 5-11).
Rozszerzenia w zakresie ról
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 (K. Schwaber 2021, s. 5-6).
Rozszerzenia w zakresie wydarzeń
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 postępowania. 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. Podsumowaniem iteracji jest retrospektywa sprintu nexus, czyli moment w którym zespoły spotykają się w celu przeanalizowania pracy wykonanej w czasie sprintu. Na podstawie wysnutych wniosków 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 (K. Schwaber 2021, s. 6-8).
Rozszerzenia w zakresie artefaktów
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, który jest jednym z artefaktów metodyki Nexus. 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 zostać 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. 8-10).
Przypisy
- ↑ Scaling Scrum with Nexus (2021)
- ↑ Nexus Framework (2021)
- ↑ Ochmańska H. (2019) Na czym polega Nexus?
Bibliografia
- Alqudah M., Razali R., (2016), A Review of Scaling Agile Methods in Large Software Development, International Journal on Advanced Science Engineering and Information Technology, nr. 6, s. 828-837
- Bittner K., Kong P., West D., (2017), The Nexus Framework for Scaling Scrum: continuously delivering an integrated product with multiple scrum seams, Scrum.org
- Schwaber K., (2021), Nexus guide: The definitive guide to Nexus: The exoskeleton of scaled Scrum development, Scrum.org
- Schwaber K., Sutherland J., (2020), The Scrum guide the definitive guide to Scrum: The rules of the game, Scrum.org
Autor: Sylwia Firszt
