Jak firma Microsoft planuje korzystanie z metodyki DevOps

Firma Microsoft jest jedną z największych firm na świecie do korzystania z metodologii Agile. Od lat firma Microsoft opracowała proces planowania Metodyki DevOps, który jest skalowany z najmniejszych projektów w górę dzięki ogromnym wysiłkom, takim jak System 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ą w cyklu rozwoju i wysyłki zdrowsze i bardziej wydajne:

• 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.
• Ulepszanie praktyk dotyczących kondycji 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ę dostarczyć tych motywatorów do PMs, deweloperów i projektantów, aby czuli się upoważnieni 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.
• Projekt jest odpowiedzialny za projektowanie kompilacji firmy Microsoft.
• Inżynieria tworzy produkty i zapewnia ich jakość.

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

• Dyscyplinarny
• 10-12 osób
• Samodzielne zarządzanie
• Jasne karty i cele przez 12-18 miesięcy
• Fizyczne pokoje zespołu
• Wdrożenie funkcji własnych
• Własne funkcje w środowisku produkcyjnym

Dążenie do zespołów pionowych

Zespoły firmy Microsoft były poziome, obejmujące wszystkie interfejsy użytkownika, wszystkie dane lub wszystkie interfejsy API. Teraz firma Microsoft dąży do zespołów pionowych. Zespoły posiadają swoje obszary kompleksowego produktu. Ś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 "żółte lepkie ćwiczenie", w którym deweloperzy mogą wybrać obszary produktu, nad którymi chcą pracować w ciągu najbliższych kilku 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 na swoich obecnych zespołach, ale czują się upoważnieni, ponieważ mieli wybór.

Tworzenie nowych strategii planowania i uczenia się

Dwight Eisenhower powiedział: "Plany są bezwartość, ale planowanie jest wszystko." Planowanie firmy 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 odpowiedzialni za przebiegi 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 przebiegu w dwie odrębne załogi: funkcje (F-crew) i klient (C-crew).

Załoga F pracuje nad zaangażowanymi funkcjami, a załoga C zajmuje się problemami i przerwami na żywo. Zespół ustanawia cykl obrotowy, który umożliwia członkom łatwiejsze planowanie działań. Aby uzyskać więcej informacji na temat modelu wielołotowego, zobacz Tworzenie wydajnych, skoncentrowanych na klientach zespołów.

Ulepszanie praktyk dotyczących kondycji kodu

Przed przejściem do metodologii Agile zespoły mogły umożliwić tworzenie usterek kodu do momentu ukończenia kodu na końcu fazy programowania. Następnie zespoły odkryły usterki i pracowały nad ich naprawianiem. Ta praktyka stworzyła roller coaster błędów, które miały wpływ na morale i produktywność zespołu, gdy zespoły musiały pracować nad poprawkami 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 usterek zespołu przekracza limit błędów na końcu przebiegu, musi przestać pracować nad nowymi funkcjami i naprawiać błędy, dopóki nie zostaną objęte limitem. Zespoły płacą teraz dług błędów, gdy idą.

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 wypowiedzi 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.

Wartości OKR odzwierciedlają najlepsze możliwe wyniki, a nie tylko najbardziej prawdopodobne wyniki. Przywódcy starają się być ambitni i nie ostrożni. Wypychanie zespołów do realizacji trudnych kluczowych wyników napędza przyspieszenie w stosunku do celów i określa priorytety pracy, która zmierza do większych celów.

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 dokumentów z zakresu od 55 do 65.
• Nowy przepływ potoku ma wynik 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 są naliczane w kierunku 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
• Pokrycie 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.

Przed	Po
4–6 miesięcy kamieni milowych	3-tygodniowe przebiegi
Zespoły poziome	Zespoły pionowe
Biura osobiste	Pokoje zespołowe i praca zdalna
Długie cykle planowania	Ciągłe planowanie i uczenie się
PM, Tworzenie i testowanie	PM, Projektowanie i inżynieria
Roczne zaangażowanie klientów	Ciągłe zaangażowanie klientów
Gałęzie funkcji	Wszyscy pracują w gałęzi głównej
Zespoły 20 osób i 20 osób	Zespoły 8-12 osób
Plan wpisu tajnego	Plan publicznie udostępniony
Dług usterki	Zerowy dług
100-stronicowe dokumenty specyfikacji	Specyfikacje programu PowerPoint
Repozytoria prywatne	Open source lub InnerSource
Głęboka hierarchia organizacji	Spłaszczona hierarchia organizacji
Numery instalacji definiują powodzenie	Zadowolenie użytkowników definiuje sukces
Funkcje są dostarczane raz w roku	Funkcje dostarczają każdy przebieg

Podjąć klucza

• 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 przebiegu, aby ustalić rytm i tempo i znaleźć wszystkie prace, które należy wykonać.
• Skompiluj kulturę, której chcesz użyć, aby uzyskać szukane zachowanie.