Skalowanie metody Agile do dużych zespołów
Słowa duże i Agile nie są często używane w tym samym zdaniu. Duże organizacje zyskały reputację powolnych ruchów. Jednak to się zmienia. Wiele dużych organizacji oprogramowania pomyślnie wprowadza transformację do metody Agile. Uczą się skalować zasady Agile z popularnymi strukturami, takimi jak SAFe, LeSS lub Nexus, lub bez nich.
W firmie Microsoft jedna z takich organizacji używa metody Agile do tworzenia produktów i usług dostarczanych pod marką Azure DevOps. Ta grupa ma 35 zespołów funkcji, które zwalniają do produkcji co trzy tygodnie.
Każdy zespół w usłudze Azure DevOps jest właścicielem funkcji od początku do końca i nie tylko. Są właścicielami relacji z klientami. Zarządzają własną listą prac produktu. Piszą i sprawdzają kod w gałęzi produkcyjnej. Co trzy tygodnie wdrażana jest gałąź produkcyjna, a wydanie staje się publiczne. Następnie zespoły monitorują kondycję systemu i naprawiają problemy z witryną na żywo.
Zgodnie z zasadami Agile zespoły autonomiczne są bardziej produktywne. Organizacja Agile chce, aby ich zespoły miały kontrolę nad codziennym wykonywaniem. Ale autonomia bez wyrównania doprowadziłaby do chaosu. Dziesiątki zespołów pracujących niezależnie nie produkowałoby ujednoliconego, wysokiej jakości produktu. Dopasowanie daje zespołom swój cel i gwarantuje, że spełniają cele organizacji. Bez wyrównania, nawet najlepsze wyniki zespołów zakończy się niepowodzeniem.
Aby skalować metodę Agile, musisz włączyć autonomię dla zespołu przy jednoczesnym zapewnieniu zgodności z organizacją.
Aby zarządzać delikatną równowagą między wyrównaniem i autonomią, liderzy metodyki DevOps muszą zdefiniować taksonomię, zdefiniować proces planowania i używać czatów funkcji.
Definiowanie taksonomii
Zespół Agile i większa organizacja Agile, do którego należy, potrzebują jasno zdefiniowanej listy prac, aby odnieść sukces. Zespoły będą miały trudności z sukcesem, jeśli cele organizacyjne są niejasne.
Aby określić jasne cele i określić, w jaki sposób każdy zespół je współtworzy, organizacja musi zdefiniować taksonomię. Jasno zdefiniowana taksonomia tworzy nomenklaturę dla organizacji.
Powszechną taksonomią są epiki, funkcje, historie i zadania.
Epiki
Epiki opisują inicjatywy ważne dla sukcesu organizacji. Epiki mogą wykonywać kilka zespołów i kilka przebiegów, ale nie są one bez końca. Epiki mają jasno zdefiniowany cel. Po osiągnięciu epika jest zamknięta. Liczba epików w toku powinna być zarządzalna w celu zapewnienia koncentracji organizacji. Epiki są podzielone na funkcje.
Funkcje
Funkcje definiują nowe funkcje wymagane do realizacji celu epika. Funkcje są jednostką wydania; reprezentują one to, co zostało wydane klientowi. Opublikowane informacje o wersji można tworzyć na podstawie listy ostatnio ukończonych funkcji. Funkcje mogą wykonać wiele przebiegów, ale powinny mieć rozmiar, aby zapewnić spójny przepływ wartości klientowi. Funkcje są podzielone na historie.
Wątki
Scenariusze definiują wartość przyrostową, która zespół musi dostarczyć, aby utworzyć funkcję. Zespół dzieli tę funkcję na fragmenty przyrostowe. Pojedynczy ukończony scenariusz może nie zapewniać znaczącej wartości klientowi. Jednak ukończona historia reprezentuje oprogramowanie jakości produkcyjnej. Historie to jednostka robocza zespołu. Zespół definiuje historie wymagane do ukończenia funkcji. Scenariusze opcjonalnie dzielą się na zadania.
Zadania
Zadania definiują pracę wymaganą do ukończenia artykułu.
Inicjatywy
Ta taksonomia nie jest jednowymiarowym systemem. Wiele organizacji wprowadza poziom powyżej epików nazywanych inicjatywami.
Nazwy poszczególnych poziomów można dostosować do organizacji. Jednak nazwy zdefiniowane powyżej (epiki, funkcje, historie) są powszechnie używane w branży.
Linia autonomii
Po ustawieniu taksonomii organizacja musi narysować linię autonomii. Linia autonomii jest punktem, w którym własność poziomu przechodzi od zarządzania do zespołu. Zarządzanie nie zakłóca poziomów należących do zespołu.
W poniższym przykładzie przedstawiono linię autonomii rysowaną poniżej. Zarządzanie jest właścicielem epików i funkcji, które zapewniają wyrównanie. Zespoły posiadają historie i zadania oraz mają autonomię nad sposobem ich wykonywania.
W tym przykładzie zarządzanie nie informuje zespołu o tym, jak rozkładać scenariusze, planować przebiegi ani wykonywać pracy.
Zespół musi jednak zapewnić, że ich wykonywanie jest zgodne z celami zarządzania. Podczas gdy zespół jest właścicielem listy prac historii, musi dopasować listę prac z przypisanymi do nich funkcjami.
Planowanie
Aby skalować planowanie Agile, zespół potrzebuje planu dla każdego poziomu taksonomii. Ważne jest jednak, aby iterować i aktualizować plan. Ten proces jest nazywany planowaniem fal kroczenia.
Plan zapewnia kierunek dla stałego okresu z oczekiwaną kalibracją w regularnych odstępach czasu. Na przykład plan 18 miesięcy można skalibrować co sześć miesięcy.
Oto przykład metod planowania dla każdego poziomu taksonomii: epiki, funkcje, historie, zadania.
Obraz
Wizja jest wyrażana za pośrednictwem epików i określa długoterminowy kierunek organizacji. Epiki definiują, co organizacja chce ukończyć w ciągu najbliższych 18 miesięcy. Kierownictwo jest właścicielem planu i kalibruje go co sześć miesięcy.
Wizja jest przedstawiana na spotkaniu z całą ręką. Ponieważ wizja ma być ambitna i wiele może się zmienić w tym okresie, spodziewaj się, że osiągnie około 60% wizji.
Pora roku
Sezon jest opisywany za pośrednictwem funkcji i określa strategię na następne sześć miesięcy. Funkcje określają, co organizacja chce rozświetlić dla swoich klientów. Kierownictwo jest właścicielem planu sezonowego i przedstawia wizję i plany sezonowe na spotkaniu z każdą ręką. Wszystkie plany zespołu muszą być zgodne z planem sezonowym zarządzania. Spodziewaj się osiągnąć około 80% planu sezonowego.
Plan 3-sprint
Plan 3-sprint definiuje historie i funkcje, które zespół zakończy w ciągu następnych trzech przebiegów. Zespół jest właścicielem planu i kalibruje go w każdym przebiegu. Każdy zespół przedstawia swój plan zarządzania za pośrednictwem czatu funkcji (patrz poniżej). Plan określa, w jaki sposób wykonanie zespołu jest zgodne z 6-miesięcznym planem sezonowym. Spodziewaj się, że osiągnie około 90% planu 3-sprintu.
Plan przebiegu
Plan przebiegu definiuje historie i funkcje, które zespół zakończy w następnym przebiegu. Zespół jest właścicielem planu przebiegu i e-mailem do całej organizacji w celu zapewnienia pełnej przejrzystości. Plan obejmuje to, co zespół wykonał w przeszłości sprint i skupił się na następnym przebiegu. Spodziewaj się osiągnąć około 95% planu przebiegu.
Linia autonomii
W tym przykładzie linia autonomii jest przyciągana, aby pokazać, gdzie zespoły mają autonomię planowania.
Jak wspomniano powyżej, zarządzanie nie rozszerza własności poniżej linii autonomii. Zarządzanie zawiera wskazówki dotyczące planowania wizji i sezonu, a następnie zapewnia zespołom autonomię w celu tworzenia planów 3-sprintu i przebiegu.
Czaty funkcji: gdzie autonomia spełnia wyrównanie
Czat funkcji to spotkanie z małą ceremonią, w którym każdy zespół przedstawia swój 3-sprint plan zarządzania. To spotkanie zapewnia, że plany zespołu są zgodne z celami organizacji. Pomaga również zarządzać na bieżąco z tym, co robi zespół. Podczas gdy plan 3-sprint jest kalibrowany co sprint, czaty funkcji są przechowywane zgodnie z potrzebami, zwykle każdy jeden do trzech przebiegów.
Spotkanie czatu funkcji przydziela 15 minut każdemu zespołowi. Dzięki 12 zespołom funkcji te spotkania mogą trwać około trzech godzin. Każdy zespół przygotowuje 3-slajdowy pokład z następującymi slajdami:
Funkcje
Pierwszy slajd przedstawia funkcje, które zespół będzie rozświetlać w kolejnych trzech sprintach.
Zadłużenia
Na następnym slajdzie opisano, jak zespół zarządza długiem technicznym. Dług to wszystko, co nie spełnia pasków jakości zarządzania. Dyrektor inżynierów ustawia paski jakości, które są takie same dla wszystkich zespołów (wyrównanie). Przykładowe paski jakości obejmują liczbę usterek na inżyniera, procent testów jednostkowych i cele wydajności.
Problemy i zależności
Problemy i zależności wymienione na ostatnim slajdzie obejmują wszystkie elementy wpływające na postęp zespołu, takie jak problemy, których zespół nie może rozwiązać lub zależności od innych zespołów, które wymagają eskalacji.
Każdy zespół przedstawia slajdy bezpośrednio do zarządzania. Zespół prezentuje, jak ich plan 3-sprintu jest zgodny z 6-miesięcznym planem sezonowym. Kierownictwo zadaje wyjaśnienie pytań i sugeruje zmiany w kierunku. Mogą również poprosić o kolejne spotkania, aby rozwiązać głębsze problemy.
Jeśli plan zespołu nie jest zgodny z oczekiwaniami zarządzania, zarządzanie może zażądać ponownego planu. W tym rzadkim przypadku zespół ponownie zaplanuje i zaplanuje drugi czat funkcji, aby go przejrzeć.
Zaufanie: Klej, który posiada wyrównanie i autonomię razem
Podczas ćwiczeń Agile na dużą skalę zaufanie jest dwukierunkową ulicą:
Zarządzanie musi ufać zespołom, aby robić to, co właściwe. Jeśli zarządzanie nie ufa zespołom, nie dadzą one autonomii zespołom.
Zespół zdobywa zaufanie dzięki spójnemu dostarczaniu kodu wysokiej jakości. Jeśli zespoły nie są godne zaufania, zarządzanie nie da im autonomii.
Zarządzanie musi zapewnić jasne plany, aby zespoły były zgodne z zespołami, a następnie ufać ich zespołom w celu ich wykonania. Zespoły muszą dostosować swoje plany do organizacji i wykonać je w wiarygodny sposób.
W miarę jak organizacje chcą skalować agile do większych scenariuszy, kluczem jest zapewnienie autonomii zespołów przy jednoczesnym zapewnieniu, że są one zgodne z celami organizacji. Krytyczne bloki konstrukcyjne są jasno zdefiniowaną własnością i kulturą zaufania. Gdy organizacja ma tę podstawę, przekona się, że agile może być bardzo dobrze skalowana.
Następne kroki
Istnieje wiele sposobów, aby zespół o dowolnym rozmiarze zaczął widzieć korzyści dzisiaj. Zapoznaj się z niektórymi z tych rozwiązań, które skaluje.
Dowiedz się więcej o funkcjach usługi Azure DevOps na potrzeby zarządzania portfolio i widoczności w różnych zespołach.
Firma Microsoft jest jedną z największych firm Agile na świecie. Dowiedz się więcej o sposobie skalowania planowania metodyki DevOps przez firmę Microsoft.