Jak firma Microsoft planuje korzystanie z metodyki DevOps

Firma Microsoft jest jedną z największych firm na świecie do korzystania z metodologii Agile. Przez lata Microsoft opracował proces planowania DevOps, który jest skalowalny od najmniejszych projektów aż po ogromne przedsięwzięcia, takie jak Windows. W tym artykule opisano wiele lekcji poznanych i praktyk, które firma Microsoft implementuje podczas planowania projektów oprogramowania w całej firmie.

Zmiany instrumentalne

Następujące kluczowe zmiany pomagają uczynić cykle rozwoju i dystrybucji zdrowszymi i bardziej wydajnymi.

• Promowanie dostosowania kulturowego i autonomii.
• Zmiana koncentracji uwagi od osób fizycznych na zespoły.
• Tworzenie nowych strategii planowania i uczenia się.
• Zaimplementuj model z wieloma załogami.
• Poprawa praktyk zdrowego kodu.
• Wspieranie przejrzystości i odpowiedzialności.

Promowanie dostosowania kultury i autonomii

Peter Drucker powiedział: "Kultura zjada strategię na śniadanie." Autonomia, opanowanie i cel są kluczowymi motywacjami człowieka. Firma Microsoft stara się dostarczać te motywatory menedżerom projektów, programistom i projektantom, aby mieli poczucie mocy sprawczej do tworzenia udanych produktów.

Dwoma ważnymi elementami tego podejścia są dostosowanie i autonomia.

• Dopasowanie pochodzi od góry w dół, aby zapewnić, że osoby i zespoły rozumieją, jak ich obowiązki są zgodne z szerszymi celami biznesowymi.
• Autonomia dzieje się od dołu, aby zapewnić, że osoby i zespoły mają wpływ na codzienne działania i decyzje.

Istnieje delikatna równowaga między wyrównaniem a autonomią. Zbyt wiele wyrównania może stworzyć negatywną kulturę, w której ludzie wykonują tylko wtedy, gdy powiedziano im. Zbyt duża autonomia może spowodować brak struktury lub kierunku, nieefektywne podejmowanie decyzji i złe planowanie.

Zmiana fokusu od osób do zespołów

Firma Microsoft organizuje osoby i zespoły w trzy grupy: PM, design i engineering.

• Pm definiuje, co firma Microsoft tworzy i dlaczego.
• Projektowanie odpowiada za projektowanie tego, co firma Microsoft buduje.
• Inżynieria tworzy produkty i zapewnia ich jakość.

Zespoły firmy Microsoft mają następujące kluczowe cechy:

• Międzydyscyplinarny
• 10-12 osób
• Samodzielne zarządzanie
• Jasny plan i cele na 12-18 miesięcy
• Fizyczne pokoje zespołu
• Wdrożenie funkcji własnych
• Własne funkcje w środowisku produkcyjnym

Dążyć do budowania zespołów pionowych

Zespoły w firmie Microsoft miały poziome struktury, które obejmowały wszystkie interfejsy użytkownika, wszystkie dane oraz wszystkie interfejsy API. Teraz firma Microsoft dąży do zespołów pionowych. Zespoły mają pełną odpowiedzialność za swoje obszary produktu od początku do końca. Ścisłe wytyczne w niektórych warstwach zapewniają jednolitość między zespołami w całym produkcie.

Poniższy diagram przedstawia różnicę między zespołami poziomymi i pionowymi:

Zezwalaj na samodzielne wybieranie zespołów

Co 18 miesięcy firma Microsoft uruchamia "ćwiczenie z żółtymi karteczkami", w którym deweloperzy mogą wybrać obszary produktu, nad którymi chcą pracować na najbliższe kilka okresów planowania. To ćwiczenie zapewnia autonomię, ponieważ zespoły mogą wybrać, nad czym pracować, i wyrównać organizację, ponieważ promuje równowagę między zespołami. Około 80% osób w tym ćwiczeniu pozostaje w swoich obecnych zespołach, ale czują się wzmocnieni, ponieważ mieli wybór.

Tworzenie nowych strategii planowania i uczenia się

Dwight Eisenhower powiedział: "Plany są bezwartościowe, ale planowanie jest wszystkim." Planowanie w firmie Microsoft dzieli się na następującą strukturę:

• Przebiegi (3 tygodnie)
• Plany (3 przebiegi)
• Sezony (6 miesięcy)
• Strategie (12 miesięcy)

Inżynierowie i zespoły są głównie odpowiedzialne za sprinty i plany. Kierownictwo jest przede wszystkim odpowiedzialne za sezony i strategie.

Na poniższym diagramie przedstawiono strategię planowania firmy Microsoft:

Ta struktura planowania pomaga również zmaksymalizować naukę podczas planowania. Zespoły mogą uzyskać opinie, dowiedzieć się, czego chcą klienci, i szybko i wydajnie implementować żądania klientów.

Implementowanie modelu z wieloma załogami

Poprzednie metody sprzyjały "kulturze przerywania" usterek i zdarzeń w witrynie na żywo. Zespoły firmy Microsoft wymyśliły własny sposób, aby zapewnić koncentrację uwagi i uniknąć rozproszenia uwagi. Zespoły organizują się samodzielnie dla każdego sprintu w dwie odrębne załogi: Funkcjonalności (F-crew) i Klient (C-crew).

Załoga F pracuje nad zaplanowanymi funkcjami, a załoga C zajmuje się problemami i zakłóceniami na działającej stronie. Zespół ustanawia cykl obrotowy, który umożliwia członkom łatwiejsze planowanie działań. Aby uzyskać więcej informacji na temat modelu wieloosobowego, zobacz Budowanie wydajnych zespołów skoncentrowanych na kliencie.

Ulepszanie praktyk dotyczących kondycji kodu

Przed wdrożeniem metodologii Agile zespoły zwykle pozwalały na gromadzenie się błędów w kodzie aż do ukończenia kodu pod koniec fazy rozwoju. Następnie zespoły odkryły usterki i pracowały nad ich naprawianiem. Ta praktyka stworzyła huśtawkę błędów, które negatywnie wpływały na morale i produktywność zespołu, kiedy zespoły musiały pracować nad naprawą błędów zamiast implementować nowe funkcje.

Zespoły implementują teraz limit błędów obliczany przez formułę # of engineers x 5 = bug cap. Jeśli liczba błędów zespołu przekracza limit błędów na końcu sprintu, musi przestać pracować nad nowymi funkcjami i naprawiać błędy, dopóki nie będą poniżej limitu. Zespoły spłacają teraz dług techniczny związany z błędami na bieżąco.

Wspieranie przejrzystości i odpowiedzialności

Na końcu każdego przebiegu każdy zespół wysyła wiadomość e-mail z raportem, co osiągnęli w poprzednim przebiegu i co planuje zrobić w następnym przebiegu.

Cele i kluczowe wyniki (OKR)

Zespoły są najbardziej skuteczne, gdy są jasne na temat celów, które organizacja próbuje osiągnąć. Firma Microsoft zapewnia czytelność dla zespołów za pomocą celów i kluczowych wyników (OKR).

• Cele definiują cele do osiągnięcia. Cele są znaczące, konkretne, zorientowane na działania i idealnie inspirujące wyrażenia intencji. Cele reprezentują duże pomysły, a nie rzeczywiste liczby.
• Kluczowe wyniki definiują kroki umożliwiające osiągnięcie celów. Kluczowe wyniki to kwantyfikowalne wyniki, które oceniają postęp i wskazują powodzenie względem celów w określonym przedziale czasu.

OKR odzwierciedlają najlepsze możliwe wyniki, a nie tylko najbardziej prawdopodobne wyniki. Przywódcy starają się być ambitni i nie ostrożni. Zachęcanie zespołów do realizacji trudnych kluczowych wyników przyspiesza realizację celów i priorytetyzuje pracę, która prowadzi do większych zamierzeń.

Przyjęcie struktury OKR może pomóc zespołom w lepszej wydajności z następujących powodów:

• Każdy zespół jest dopasowany do planu.
• Zespoły koncentrują się na osiąganiu wyników , a nie na wykonywaniu działań.
• Każdy zespół jest odpowiedzialny za regularne wysiłki.

Elementy OKR mogą istnieć na różnych poziomach produktu. Na przykład mogą istnieć elementy OKR produktów najwyższego poziomu, elementy OKR na poziomie składników i elementy OKR na poziomie zespołu. Utrzymywanie wyrównanych wartości OKR jest stosunkowo łatwe, zwłaszcza jeśli cele są ustawione od góry do dołu. Wszelkie konflikty, które pojawiają się, są cennymi wczesnymi wskaźnikami niezgodności organizacyjnej.

Przykład OKR

Cel: Rozwijaj silną i szczęśliwą bazę klientów.

Kluczowe wyniki:

• Zwiększ zewnętrzny wynik promotora netto (NPS) z 21 do 35.
• Zwiększ zadowolenie z dokumentacji z 55 do 65.
• Nowy przepływ rurociągu ma ocenę Apdex 0,9.
• Czas kolejki dla zadań wynosi 5 sekund lub mniej.

Aby uzyskać więcej informacji na temat okr, zobacz Mierzenie wyników biznesowych przy użyciu celów i kluczowych wyników.

Wybieranie odpowiednich metryk

Kluczowe wyniki są tak przydatne, jak metryki, na których są oparte. Firma Microsoft używa wiodących wskaźników, które koncentrują się na zmianach. Z czasem te metryki tworzą obraz roboczy przyspieszania lub zwalniania produktu. Firma Microsoft często używa następujących metryk:

• Zmiana miesięcznego tempa wzrostu wdrożenia
• Zmiana wydajności
• Zmiana czasu na naukę
• Zmiana częstotliwości zdarzeń

Zespoły unikają metryk, które nie przynoszą wartości w osiąganiu celów. Chociaż mogą one mieć pewne zastosowania, następujące metryki nie są przydatne do śledzenia postępów w kierunku celów:

• Dokładność oryginalnych szacunków
• Ukończone godziny
• Wiersze kodu
• Pojemność zespołu
• Burndown zespołu
• Szybkość zespołu
• Liczba znalezionych usterek
• Stopień pokrycia kodu

Przed agile i po agile

W poniższej tabeli przedstawiono podsumowanie zmian wprowadzonych przez zespoły programistyczne firmy Microsoft w miarę wdrażania praktyk Agile.

Kluczowe wnioski

• Weź pod uwagę naukę Agile poważnie, ale nie bądź nadmiernie nakazowy. Agile może stać się zbyt rygorystyczne. Pozwól, aby sposób myślenia Agile i kultura rosły.
• Świętuj wyniki, a nie aktywność. Wdrażanie funkcji przewyższa wiersze kodu.
• Wysyłka na każdym sprincie, aby ustalić rytm i tempo oraz zidentyfikować wszystkie zadania, które należy wykonać.
• Buduj kulturę, której pragniesz, aby osiągnąć pożądane zachowanie.