Na czym polega Nexus?

Przedstawiam Ci Nexusa: Nexus (pol. ogniwo) jest jak mityczny Herkules: duży, silny i wymagający. Pomaga porządkować chaos w złożonych procesach wytwarzania, dysponuje silnymi regułami. Daje mocne role, wspierające zdarzenia i niezbędne artefakty.

Żeby z sukcesem wdrożyć Nexusa i z zyskiem z niego korzystać, trzeba najpierw dobrze osadzić się w Scrumie, tak, żeby stał się nie tylko obowiązującym zestawem ról, artefaktów, wydarzeń i reguł. Trzeba, żeby Scrum stał się naturalnym stylem życia projektowego. 

Nexus potrzebuje otwartych i cierpliwych umysłów, które przyjmą go z całym dobrodziejstwem inwentarza: z wartością, która pozwala dostarczyć klientowi gotowy produkt, ale też wymaganiami, jakie stawia. 

Nexus wysoko stawia poprzeczkę i tego samego oczekuje w zamian. Posługuje się mocnymi narzędziami i tego oczekuje od tych, którzy zdecydują się z nimi współpracować. Jest w pełni profesjonalny.

A można by tak konkretniej?

ogniwo (tłum. nexus)
«to, co jednoczy kogoś lub coś»
«składowa część jakiejś struktury organizacyjnej»
«źródło stałego prądu elektrycznego»

Cytując za twórcami frameworku:

Nexus to model postępowania pomocny w wytwarzaniu i utrzymaniu produktów oraz w prowadzeniu inicjatyw związanych z produkcją oprogramowania dużej skali.”

- Ken Schwaber

Nexus, bazując na frameworku Scrum, rozszerza narzędzia Scruma, aby poprowadzić wiele Zespołów Scrumowych w zakresie współpracy w dostarczaniu działającego oprogramowania w każdym Sprint. 

Scrum jest prostym frameworkiem do dostarczania oprogramowania przy użyciu podejścia empirycznego. Zespoły dostarczają wartość w małych krokach, sprawdzają wyniki i w razie potrzeby dostosowują swoje podejście na podstawie informacji zwrotnych. W swojej strukturze ról, wydarzeń, artefaktów, wartości i reguł je łączących, jest również prosty.

Nexus również pozostaje w strukturze prosty, rozszerza jednak i uzupełnia scrumowy zestaw narzędzi. Pokazuje jak podzielić się pracą między wieloma zespołami oraz jak zarządzać procesem wytwórczym i minimalizować zależności. Pozwala zachować samoorganizację i przejrzystość.

Skalowanie Nexus w Scrumie pomaga zespołom dostarczać złożony, wieloplatformowy, oparty na oprogramowaniu produkt w krótkich, częstych cyklach, bez poświęcania spójności lub jakości oraz bez dodawania niepotrzebnej złożoności lub odejścia od głównych zasad Scruma. 

Pokazuje, jak wyznaczać cele i planować pracę, jak korzystać z doświadczeń w złożonych strukturach produktowych i organizacyjnych. Stawia wiele wyzwań związanych z dostarczeniem działających, zintegrowanych przyrostów produktu w wielu zespołach oraz pokazuje, jak je rozwiązywać.

Środowiska pracy Nexus

Zróbmy krok wstecz, aby lepiej zrozumieć Nexusa i poznać jego rolę. Przeanalizujmy obszary złożoności i zobaczmy, w których z nich wytwarzane są najczęściej rozległe produkty IT.

Z czym mierzymy się wytwarzając złożone produkty IT, tłumaczy model Cynefin. Wyróżnia on 5 obszarów złożoności i podpowiada, jakiego typu podejścia do problemu zastosować w zależności od kontekstu. 

Model Cynefin (model uproszczony; pełen opis: Model Cynefin ), źródło

Proste (ang. simple)

To obszary, systemy, procesy, w których wyraźna jest relacja skutek – przyczyna. Problemy nie wymagają więc złożonej interpretacji czy doświadczenia. Proces jest dokładnie określony, są sztywno ustalone kolejne kroki wytwórcze i nie ma miejsca na niewiadome. Przykładem może być przygotowanie leku wg. określonej receptury.

Skomplikowane (ang. complicated)

Tutaj istnieje powiązanie między przyczyną i skutkiem, ale nie jest ono oczywiste. Znalezienie rozwiązania problemu wymaga wiedzy eksperckiej, dużego doświadczenia oraz złożonej analizy. Przykład: budowa domu.

Złożone (ang. complex)

Tu nie ma jednoznacznych powiązań między przyczyną, a skutkiem ze względu na ich zmienność, więc można je wykryć poprzez eksperymenty i ciągłą analizę bieżącej sytuacji.

Choatyczne (ang. chaotic)

Środowiska, w których brakuje powiązań między przyczyną i skutkiem. Wszelkie sytuacje alarmowe, pożary i katastrofy są przykładami takich systemów.

Nieporządek (ang. disorder)

To sytuacja, w której nie jesteśmy w stanie określić, z jakiego typu systemem mamy do czynienia.

źródło

Domeną projektów IT w większości jest środowisko complex. Niewiele jest tu prostych rozwiązań. Wytwarzanie oprogramowania jest czynnością złożoną, a proces integracji prowadzący do uzyskania działającego, gotowego oprogramowania, wiąże się z koordynowaniem wielu działań i wykorzystaniem wielu narzędzi i reguł. Powinny być one odpowiednio ze sobą zorganizowane i zestrojone, zależności między nimi rozwiązane, a ich wyniki odpowiednio ze sobą połączone. 

Zwinny Scrum dysponuje określonymi ramami postępowania, które umożliwiają tę skuteczność pod jednym warunkiem: projekt skupia nie więcej niż 3-4 zespoły wytwórcze.

źródło

Co jednak dzieje się, jeśli projekt swoim zakresem, złożonością, liczbą i wielkością niewiadomych przekracza możliwości Scruma? Jak poruszać się po gęstym i ciemnym lesie, żeby dotrzeć do klienta na czas, z produktem dokładnie takim, jakiego potrzebuje? 

W rozległych projektach informatycznych, wymagających zaangażowania większej liczby zespołów scrumowych, system próbuje spychać ze szczególnym natężeniem w chaos i mnoży zależności w tempie znanego wszystkim pracującym scrumowo ciągu Fibonacciego (Ciekawostka: ciąg został przedstawiony przez Fibonacciego w 1202 r. jako rozwiązanie zadania o rozmnażaniu się królików ☺).

źródło

I tu dochodzimy do Nexusa.

Jak działa Nexus? Jakie są konkretne powiązania i różnice między Scrumem i Nexusem?

Nexus to model postępowania składający się z ról, zdarzeń, artefaktów i reguł, które łączą i splatają pracę około 3-9 Zespołów Scrumowych (ang. Scrum Teams). Pracują one nad jednym Rejestrem Produktu (ang. Product Backlog) i wspólnie wytwarzają Zintegrowany Przyrost (ang. Integrated Increment) spełniający założony cel. 

Ról, zdarzeń, artefaktów i reguł, które uwydatniają zależności między pracą zespołów i złożonymi komponentami produktu i wspierają zarządzanie nimi. Opiera się na teorii, wartościach i definicji „Ukończenia” Scruma.

Bazując na Scrumie pomaga dotrzeć do sedna problemu skalowania - ciągłego identyfikowania i usuwania zależności tworzonych przez zwiększoną złożoność. Wykorzystuje do tego role, artefakty, wydarzenia i reguły - niektóre z nich pozostawiając niezmienne, inne dodając, a jeszcze inne redefiniując. 

Niezmienna pozostaje zasadnicza rola Właściciela Produktu (ang. Product Owner). Nexus pracuje w oparciu o pojedynczy Backlog Produktu i ma jednego Właściciela Produktu. 

Pojawia się nowa rola: Zespół Integracyjny Nexus (ang. Nexus Integration Team). Koordynuje on, uczy i nadzoruje stosowanie Nexusa i Scruma w celu dostarczenia zintegrowanego, gotowego przyrostu na koniec sprintu. Zespół Integracyjny Nexusa składa się z Właściciela Produktu, Scrum Mastera i członków Zespołu Integracyjnego Nexusa – doświadczonych specjalistów.

Nowy artefakt: Backlog Sprintu Nexusa (ang. Nexus Sprint Backlog), który ułatwia zachowanie przejrzystości podczas Sprintu. Niezależnie od istnienia Backlogu Sprintu Nexusa, wszystkie Zespoły Scrumowe utrzymują swoje własne Backlogi Sprintu (ang. Sprint Backlog);

I nowe zdarzenie: Codzienny Scrum Nexusa (ang. Nexus Daily Scrum). Oprócz Codziennego Scruma poszczególnych zespołów, ich przedstawiciele spotykają się na Nexus Daily Scrum, aby identyfikować wszelkie problemy związane z integracją. Zespoły Scrumowe wykorzystują Codzienny Scrum, aby utworzyć plan dnia i upewnić się, że w pierwszej kolejności rozwiązane zostaną problemy zidentyfikowane podczas Codziennego Scruma Nexusa.

Nexus przedefiniowuje i rozbudowuje role, artefakty i zdarzenia

Jeden Cel Nexusa (ang. Nexus Goal) i jeden Zintegrowany Przyrost (ang. Integrated Increament).

Zgodny z definicją „Ukończenia” na koniec Sprintu: wszystkie zespoły wytwarzają oprogramowanie często integrując swoją pracę we wspólnym (międzyzespołowym) środowisku, w którym może ono być testowane w celu zapewnienia jego pełnej integracji. Cel Nexusa jest więc sumą pracy i Celów Sprintu wszystkich Zespołów Scrumowych.

Planowanie Sprintu Nexusa (ang. Nexus Sprint Planning)

Wyznaczeni przedstawiciele każdego zespołu scrumowego spotykają się, aby przejrzeć i omówić przygotowany Backlog Produktu. 

Każdy zespół scrumowy wybiera elementy Backlogu Produktu, a następnie planuje swój własny Sprint, współdziałając z innymi zespołami, jeśli zachodzi taka konieczność. Wynikiem jest zestaw Celów Sprintu, zgodnych z nadrzędnym Celem Nexusa z Backlogami Sprintu wszystkich Zespołów Scrumowych oraz z Backlogiem Sprintu Nexusa. 

Backlog Sprintu Nexusa

Powoduje, że wybrane przez Zespół Scrumowy elementy Backlogu Produktu i wszystkie zależności stają się widoczne.

Przegląd Sprintu Nexusa (ang. Nexus Sprint Review)

Wszystkie zespoły spotykają się z Właścicielem Produktu, aby przejrzeć Zintegrowany Przyrost. 

Retrospektywa Sprintu Nexusa (ang. Nexus Sprint Retrospective)

Pomaga przedstawicielom Zespołów Scrumowych w zidentyfikowaniu wspólnego wyzwania. Dalsza jej struktura daje przestrzeń zespołom na własną Retrospektywę Sprintu, po której zespoły spotykają się ponownie, żeby omówić działania, których realizacja jest niezbędna w obliczu wspólnych wyzwań.

Doskonalenie Backlogu

Szczególny nacisk w Nexusie jest położony na Doskonalenie Backlogu (ang. Refinement), który pozwala zdekomponować Backlog Produktu w taki sposób, aby można było łatwo zidentyfikować, a następnie usunąć lub ograniczyć zależności.

Scrum vs. Nexus, źródło 1, źródło 2

Wszystkie te „nadbudowane” na Scruma i dodane elementy pełnią rolę analogiczną do egzoszkieletu podtrzymującego ciało człowieka o zmniejszonej sprawności - narzędzia, które pionizuje i ma znaczny wpływ na sprawną pracę układu kostnego, mięśniowego, naczyniowego, oddechowego, trawiennego. 

Dlatego do opisania Nexusa używa się czasem określenia „egzoszkielet”. Koncentruje on bowiem zespoły developerskie na jednym, wspólnym celu. Wychwytuje zależności, przeciwdziała powielaniu pracy w poszczególnych zespołach developerskich i wytwarzaniu niekompatybilnych komponentów systemu. Zapobiega pułapkom, na które mogłyby natrafić zespoły. Swoją strukturą daje możliwość świadomego zapanowania nad skomplikowanym, rozległym projektem wytwórczym, na którego końcu są zadowoleni klienci.

Życzę Ci, żebyś chociaż raz w życiu spotkał/a swojego Herkulesa!