Eksplorowanie kultury metodyki DevOps

  • 7 min

Kultura jest podstawą metodyki DevOps, ponieważ wymaga ona rozwoju i ciągłego uczenia się, aby odnieść sukces. Wsparcie przywództwa jest jednym z kluczowych elementów sukcesu.

Zanim omówimy, jak wygląda kultura metodyki DevOps, rozważmy rolę kultury w możliwości wdrożenia metodyki DevOps w organizacji. Według Gartnera:

Odporność kulturowa i niski poziom dyscypliny procesów spowodują znaczne wskaźniki niepowodzeń dla inicjatyw DevOps.

Gene Kim, autor podręcznika Phoenix Project i DevOps, mówi:

Metodyka DevOps to podróż pełna wyzwań i rzadko są to te wyzwania po prostu ze względu na niewłaściwą technologię lub niewłaściwe procesy. W rzeczywistości największe i najtrudniejsze przeszkody wydają się być kulturowe. A jeśli dostaniesz kulturę źle, nawet jeśli dostaniesz wszystko inne dobrze, jesteś kierowany do frustracji, dodatkowych kosztów i prawdopodobnie porażki.

Co to jest kultura?

Dla naszych celów kultura jest dziedzictwem społecznym grupy. Jest to wzorzec odpowiedzi odnalezionych, opracowanych lub wynalezionych w historii grupy problemów, które wynikają z interakcji między jej członkami i między nimi a ich środowiskiem.

Kultura określa:

  • To, co jest dopuszczalne lub niedopuszczalne.
  • Co jest ważne lub nieistotne.
  • Co jest właściwe lub złe.
  • To, co jest możliwe do pracy lub nie do wykonania.
  • KtoTo zatrudniasz, zwalniasz i promujesz.

Dlaczego inicjatywy metodyki DevOps kończą się niepowodzeniem?

Badania firmy Gartner pokazują, że do 2023 r. 90% inicjatyw DevOps zakończy się niepowodzeniem z powodu ograniczeń podejść do zarządzania używanych przez kierownictwo.

Ważne

Główną obowiązkiem kierownictwa jest utworzenie środowiska, które umożliwia pomyślną kulturę DevOps.

Osoby, którzy pracują w kreatywnych przedsięwzięciach, nie potrzebują "piwa w break roomie", aby je zmotywować. Twórcy zamiast tego potrzebują opanowania, autonomii i celu.

Kiedy ludzie zapytali, jaka jest najważniejsza część sukcesu firmy Microsoft — czy jest to wizja, strategia czy wykonanie? – Dyrektor generalny Firmy Microsoft Satya Nadella powiedział, że są one ważne, ale w końcu było to ich cel i nastawienie na rozwój.

12 przykładów myślenia metodyki DevOps

Oto 12 przykładów podejścia DevOps: nastawienie na przywództwo, skoncentrowanie się na klientach, myślenie oparte na chudym myśleniu, myślenie systemowe, usuwanie odpadów, teoria ograniczeń, wyrównanie i autonomia, testowanie zmian w lewo, nastawienie na zabezpieczenia, rozwój oparty na hipotezach, rozwój na żywo i wyniki pomiaru, a nie nastawienie na działania.

Nastawienie na przywództwo

Firma Gartner udostępnia następujące zalecenia:

  • Zidentyfikuj liderów transformacji, ustalając priorytety określonych cech behawioralnych niezbędnych do prowadzenia inicjatywy DevOps, kładąc mniejszy nacisk na zestawy umiejętności technicznych.
  • Rozwijaj liderów transformacji, przyjmując porażkę jako szansę na naukę.
  • Zarządzanie liderami transformacji przez umożliwienie im podejmowania decyzji wolnych od zgadywania i dostarczania jasnych celów i kluczowych metryk.

Ponieważ metodyka DevOps jest transformacyjna, liderzy infrastruktury i operacji (I&O) muszą identyfikować kandydatów, którzy są wizjonerami, adaptacyjnymi, motywacyjnymi, wzmacnianymi i odpowiedzialnymi.

Ukierunkowany na klienta sposób myślenia

Co to znaczy być skoncentrowanym na klientach?

  • Nasłuchiwanie i komunikowanie się z naszymi klientami
  • Mierzenie, co jest ważne
  • Objąć kolor czerwony w środowisku produkcyjnym
  • Tworzenie, mierzenie i nauka
  • Użyj przełączania funkcji na potrzeby bezproblemowego wdrażania
  • Zbieranie danych w szerokim zakresie, ale starannie

Myślenia o chudym myśleniu

Wartość: nastawienie oparte na chudym myśleniu zaczyna się od szczegółowego zrozumienia, jaką wartość klient przypisuje do produktu i usług. Organizacja koncentruje się na eliminowaniu odpadów, dzięki czemu mogą dostarczyć wartość oczekiwaną przez klienta na najwyższym poziomie rentowności.

Strumień wartości obejmuje cały cykl życia produktu, od surowców przez użycie klienta i ostateczną likwidację produktu. Aby wyeliminować odpady, ostatecznym celem Lean musi być dokładne i pełne zrozumienie strumienia wartości.

Przepływ: Zrozumienie przepływu jest niezbędne do wyeliminowania odpadów. Jeśli strumień wartości przestanie iść do przodu w dowolnym momencie, odpady są nieuniknione według produktu. Zasada oszczędnego wytwarzania przepływu polega na tworzeniu łańcucha wartości bez przerw w procesie produkcyjnym i o tym, gdzie każda działalność jest w krokach ze sobą.

Ściąganie: chude zasada ściągania pomaga zapewnić przepływ, upewniając się, że nic nie zostało wykonane przed upływem czasu, co tworzy spis prac w procesie i zatrzymuje zsynchronizowany przepływ. Zamiast używać tradycyjnego amerykańskiego podejścia produkcyjnego do wypychania pracy na podstawie prognozy i harmonogramu, podejście ściągania dyktuje, że nic nie jest dokonywane, dopóki klient go nie zamówi.

Doskonałość: Lean praktycy starają się osiągnąć doskonałość. Marsz w kierunku idealnego procesu ma miejsce, gdy ciągłe ulepszenia dotyczą głównych przyczyn problemów z jakością i odpadów produkcyjnych. Nieustanne dążenie do doskonałości jest tym, co napędza użytkowników podejścia do kopania głębiej, mierzenia więcej i zmieniania się częściej niż ich konkurenci.

Sposób myślenia systemowego

Sposób myślenia systemowego podkreśla wydajność całego systemu, a nie wydajność konkretnego silosu pracy lub działu.

Skoncentruj się na wszystkich strumieniach wartości biznesowych, które są włączone przez it. Innymi słowy, zaczyna się, gdy wymagania są identyfikowane przez firmę lub dział IT, wbudowane w programowanie, a następnie przenoszone do operacji IT, gdzie wartość jest następnie dostarczana klientowi jako usługa.

Usuwanie myślenia o odpadach

Chudy sposób myślenia koncentruje się na identyfikowaniu i usuwaniu siedmiu śmiertelnych odpadów, które nie są wartością dla klienta:

  • Częściowo zakończona praca
  • Dodatkowy proces
  • Dodatkowe funkcje
  • Przełączanie zadań
  • Oczekuje
  • Ruchu
  • Wady

Teoria myślenia ograniczeń

Teoria ograniczeń to metodologia identyfikowania i usuwania ograniczeń (nazywanych również wąskimi gardłami), które ograniczają przepływność. W praktyce zacznij od zidentyfikowania najważniejszego czynnika, który stoi w drodze osiągnięcia celu. Pracuj, aby zminimalizować ten czynnik, dopóki nie jest już ograniczeniem.

Diagram depicts the Theory of constraints: identify the constraint, exploit it, subordinate & synchronize to it, elevate the performance of the constraint, repeat the process

Równoważenie zestawów umysłów wyrównania i autonomii

Konieczne jest osiągnięcie równowagi między wyrównaniem a autonomią. Zbyt duża spójność prowadzi do mniejszej liczby innowacji, mniejszej motywacji i mniejszej współpracy. Zbyt duża autonomia prowadzi do większego chaosu, zamieszania i konfliktu, a jednocześnie prowadzi do mniejszej spójności.

Diagram explains aligned autonomy: if you get the organization, roles, teams, cadence, and architecture in alignment, then the plans and practices can function autonomously.

Sposób myślenia na potrzeby testowania w lewo

Testowanie po lewej stronie jest podejściem służącym do przyspieszania testowania oprogramowania i ułatwiania programowania przez przeniesienie procesu testowania do wcześniejszego punktu w cyklu programowania. Przesunięcie w lewo to odwołanie do przenoszenia testów po lewej stronie na osi czasu. Ułatwia tworzenie jakości i identyfikowanie problemów wcześniej w celu zmniejszenia strat pracy.

Testowanie w lewo z przesunięciem zostało zaprojektowane tak, aby był lepszym modelem na potrzeby tworzenia szybkiego pasa ruchu, ponieważ tradycyjne modele testowania, które czekają do późniejszego momentu w cyklu programowania, mogą być wąskim gardłem.

Sposób myślenia o zabezpieczeniach

Aby osiągnąć sposób myślenia o bezpieczeństwie, zespoły muszą:

  • Promowanie świadomości.
  • Zdefiniuj swoje zasady.
  • Żyją zgodnie z ich zasadami.

Nastawienie na rozwój oparty na hipotezach

Użycie podejścia Lean Product do opracowywania w krótszych cyklach i opracowywania opartego na hipotezach pomaga tworzyć małe eksperymenty w celu uzyskania opinii od naszych klientów i decyzji opartych na danych.

Podejście do rozwoju opartego na hipotezach:

  • Zaczyna się od założenia — coś akceptowanego jako prawdziwego bez dowodu
  • Artykułuje założenie, które ma zostać przetestowane
  • Przeprowadza eksperymentowanie i testowanie
  • Sprawdza dowody — wskaźnik wyniku

Sposób myślenia na żywo witryny

W przypadku zespołu DevOps nie ma miejsca takiego jak produkcja. Wszystko, co robią, polega na ulepszaniu środowiska klientów.

Aby utworzyć stabilną witrynę o wysokiej wydajności, zastosuj najlepsze rozwiązania dotyczące operacji ciągłych w sposób zdyscyplinowany i ciągły, aby zachować kondycję lokacji.

Kluczowe czynniki naszej kultury na żywo to:

  • Wykrywanie, zanim klienci odczuwają ból
  • Dysk z danymi
  • Główną przyczyną jest klucz
  • Konfigurowanie jako kodu
  • Automatyzowanie do przetrwania
  • Bądź otwarty i naucz się

Mierzenie wyniku, a nie myślenia o aktywności

Sposób mierzenia ludzi doprowadzi do tego, jak zachowują się ludzie. Należy zmierzyć użycie, szybkość i kondycję witryny na żywo, a nie wiersze kodu, burndown zespołu i liczbę znalezionych usterek.

Napiwek

Zachowaj ostrożność z pomiarem, aby doprowadzić do optymalnego wyniku!