Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Słowa duże i Agile nie są często używane w tym samym zdaniu. Duże organizacje zyskały reputację powolnego działania. 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 funkcjonalności, które wydają do produkcji co trzy tygodnie.
Każdy zespół w usłudze Azure DevOps jest odpowiedzialny za funkcje od początku do końca i w dalszej perspektywie. Są właścicielami relacji z klientami. Zarządzają własną listą zadań produktu. Piszą i sprawdzają kod w gałęzi produkcyjnej. Co trzy tygodnie wdrażana jest gałąź produkcyjna, a wydanie zostaje upublicznione. Następnie zespoły monitorują kondycję systemu i naprawiają problemy z działaniem systemu na żywo.
Zgodnie z zasadami Agile zespoły autonomiczne są bardziej produktywne. Organizacja zwinna chce, aby ich zespoły miały kontrolę nad przebiegiem ich codziennej pracy. 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. Zgodność daje zespołom wspólny cel i zapewnia, że spełniają cele organizacyjne. Bez odpowiedniego zgrania, nawet najlepiej działające zespoły poniosłyby porażkę.
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 a autonomią, liderzy DevOps muszą określić taksonomię, opracować proces planowania i korzystać ze spotkań dotyczących 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ą angażować kilka zespołów i kilka sprintów, ale zawsze mają swój koniec. Epiki mają jasno zdefiniowany cel. Po osiągnięciu epika jest zamknięta. Liczba epik w toku powinna być łatwa do zarządzania, aby utrzymać koncentrację organizacji. Epiki są podzielone na cechy.
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ą wymagać wielu sprintów do ukończenia, ale powinny być tak rozmiarowane, aby zapewnić stały przepływ wartości do klienta. Funkcje są podzielone na historie.
Historie
Scenariusze definiują wartość przyrostową, która zespół musi dostarczyć, aby utworzyć funkcję. Zespół dzieli tę funkcję na mniejsze, stopniowe części. Pojedynczy ukończony scenariusz może nie zapewniać znaczącej wartości klientowi. Jednak ukończona historia reprezentuje oprogramowanie gotowe do produkcji. Historie to jednostka robocza zespołu. Zespół definiuje historie wymagane do ukończenia funkcji. Scenariusze opcjonalnie dzielą się na zadania.
Tasks
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 odpowiedzialność za poziom przechodzi od zarządu do zespołu. Zarządzanie nie ingeruje w poziomy zależne od zespołu.
W poniższym przykładzie pokazano linię autonomii wyznaczoną poniżej cech. Zarząd posiada epiki i funkcje, które zapewniają spójność. Zespoły posiadają historie i zadania oraz mają autonomię nad sposobem ich wykonywania.
W tym przykładzie zarządzanie nie mówi zespołowi, jak rozkładać historie, planować sprinty ani wykonywać pracy.
Zespół musi jednak zapewnić, że ich wykonywanie jest zgodne z celami zarządzania. Podczas gdy zespół jest właścicielem swojego backlogu zadań, musi dopasować backlog do przypisanych im cech.
Planning
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 falowym.
Plan wyznacza kierunek na ustalony okres czasu z planowaną 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: epicki zarys, cechy, historyjki, zadania.
Wizja
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 całego zespołu. Ponieważ wizja ma być ambitna i wiele może się zmienić w tym okresie, spodziewaj się osiągnąć 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 uwidocznić dla swoich klientów. Kierownictwo jest właścicielem planu sezonowego i przedstawia wizję oraz plan sezonowy na spotkaniu wszystkich pracowników. Wszystkie plany zespołu muszą być zgodne z planem sezonowym zarządzania. Spodziewaj się osiągnąć około 80% planu sezonowego.
Plan trzech sprintów
Plan 3 sprintów definiuje historie i funkcje, które zespół zakończy w ciągu następnych trzech sprintów. Zespół jest właścicielem planu i dostosowuje go w każdym sprincie. Każdy zespół przedstawia swój plan kierownictwu za pośrednictwem czatu funkcji (patrz poniżej). Plan określa, w jaki sposób realizacja zespołu jest zgodna z 6-miesięcznym planem sezonowym. Powinieneś oczekiwać osiągnięcia około 90% planu trzech sprintów.
Plan przebiegu
Plan sprintu definiuje historie i cechy, które zespół zakończy w następnym sprincie. Zespół odpowiada za plan sprintu i wysyła go e-mailem do całej organizacji, aby zapewnić pełną przejrzystość. Plan obejmuje to, co zespół wykonał w ostatnim sprintcie oraz na czym skupi się w następnym sprintcie. Spodziewaj się osiągnąć około 95% planu sprintu.
Linia autonomii
W tym przykładzie charakterystyczna linia autonomii zostaje narysowana, co pokazuje, gdzie zespoły mają autonomię planowania.
Jak wspomniano powyżej, zarządzanie nie rozszerza własności poniżej linii autonomii. Zarząd zapewnia wskazówki, korzystając z planów wizji i sezonowych, a następnie daje zespołom autonomię do tworzenia planów trzech sprintów i planów sprintów.
Czaty funkcjonalności: gdzie autonomia spotyka harmonizację
Spotkanie dotyczące funkcji to nieformalne zebranie, podczas którego każdy zespół przedstawia swój plan na 3 sprinty kierownictwu. To spotkanie zapewnia, że plany zespołu są zgodne z celami organizacji. Zarządowi pomaga również być na bieżąco z tym, co robi zespół. Podczas gdy plan 3-sprintowy jest kalibrowany co sprint, spotkania dotyczące funkcji odbywają się zgodnie z potrzebami, zwykle co jeden do trzech sprintów.
Spotkanie dotyczące omówienia funkcji przeznacza 15 minut na każdy zespół. Mając 12 zespołów funkcjonalnych, te spotkania mogą być zaplanowane na około trzy godziny. Każdy zespół przygotowuje 3-slajdową prezentację z następującymi slajdami:
Funkcje
Pierwszy slajd przedstawia funkcje, które zespół wdroży w ciągu następnych trzech sprintów.
Dług
Na następnym slajdzie opisano, jak zespół zarządza długiem technicznym. Dług to wszystko, co nie spełnia standardów jakościowych zarządzania. Dyrektor inżynierii ustala standardy jakości, które są takie same dla wszystkich zespołów (spójność). Przykładowe wskaźniki jakości obejmują liczbę usterek na inżyniera, procent testów jednostkowych zakończonych sukcesem oraz cele wydajnościowe.
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 swoje slajdy bezpośrednio dla kierownictwa. Zespół prezentuje, jak ich plan obejmujący trzy sprinty jest zgodny z sześciomiesięcznym planem sezonowym. Kierownictwo zadaje pytania wyjaśniające i sugeruje zmiany 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ół przemyśli i zaplanuje drugą rozmowę o funkcji, aby ją przeanalizować.
Zaufanie: Spójne złącze, które łączy spójność i autonomię.
Podczas stosowania metodyki Agile na dużą skalę zaufanie jest obustronnym procesem.
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ąd musi zapewnić jasne plany, z którymi zespoły mogą się zgodnie kierować, a następnie ufać swoim zespołom, by je realizowały. 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.
Dalsze kroki
Istnieje wiele sposobów, aby zespół o dowolnym rozmiarze zaczął widzieć korzyści dzisiaj. Zapoznaj się z niektórymi z tych praktyk, które się skalują.
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.