Eksplorowanie ciągłego ulepszania

  • 5 min

Ciągłe ulepszanie to jedna z ośmiu funkcji taksonomii DevOps.

Dowiedz się, dlaczego ciągłe ulepszanie jest niezbędne

Ciągłe ulepszanie obejmuje i wymaga pomiaru. Jak zidentyfikować ulepszenia, jeśli nie mierzysz?

Raport Forrester Faster Software Delivery Przyspieszy transformację cyfrową, opublikowany w 2017 r., pokazuje znaczne straty między czasem realizacji a czasem procesu. Przypomina nam to, że jeśli nie mierzysz, nie możesz znać różnicy ani ilości odpadów tworzonych przez organizację.

Po zmierzeniu wpływu, jaki mają określone odpady na ten proces, łatwo jest ustalić priorytety pracy w celu wprowadzenia ulepszeń.

Diagram przedstawia znaczne straty między czasem realizacji 123 dni a czasem procesu 39 dni. Oznacza to czas oczekiwania wynoszący 84 dni.

Źródło: Forrester, Szybsze dostarczanie oprogramowania przyspieszy transformację cyfrową, 9 marca 2017 r. przez Diego Lo Giudice, Christopher Condo z Christopher Mines, Luis Deya

Ale jak poprawić jakość obsługi klienta, jeśli nie mierzysz? Badania forrester wykazały, że "Małe nakładanie się między przetestowanymi i używanymi funkcjami oznacza, że deweloperzy potrzebują lepszych szczegółowych informacji o klientach". Nakładanie się między przetestowanymi funkcjami aplikacji a używanymi funkcjami aplikacji wynosi około 35%.

Diagram pokazuje, że między testami i używanymi funkcjami nakłada się tylko 35%.

Jak utworzyć odpowiednie oprogramowanie, jeśli nie mierzysz użycia i wpływu nowych funkcji? Z 65% szans na błędne, wiedząc, że różnica jest niezbędna.

Co to jest ciągłe ulepszanie?

Ciągłe i szczere obserwowanie procesu DevOps umożliwia zespołom identyfikowanie możliwych punktów poprawy.

Cała poprawa wymaga zmiany, ale nie wszystkie zmiany są ulepszeniem. Dlatego pomiar jest krytycznym czynnikiem sukcesu dla organizacji korzystających z metodyki DevOps. Jak mówi Peter Drucker: "Jeśli nie możesz go zmierzyć, nie możesz go poprawić."

Brak skutecznego mechanizmu przesyłania opinii utrudnia poprawę wpływu aplikacji na działalność biznesową. Dlatego ważne jest utworzenie środowiska, które wspiera podejście skoncentrowane na uczeniu się na potrzeby poprawy metodyki DevOps, koncentrując się na tworzeniu korekt opartych na danych. Diagram pokazuje, że powinniśmy użyć miary i wpływu na generowanie ulepszeń. Pomiar powinien prowadzić do pozytywnej zmiany zachowania. Organizacje powinny rozwijać się w praktyce ciągłego uczenia się i opinii w celu utworzenia ciągłego ulepszania wydajności dostarczania oprogramowania.

Pomiary i metryki

Najpierw rozważmy pomiar. Według książki Accelerate by Nicole Forsgren, Jez Humble i Gene Kim, cztery najważniejsze środki wydajności dostarczania oprogramowania to:

  • Czas realizacji zmian: miara tempa wydajności dostarczania oprogramowania. Czas potrzebny na przejście z kodu zatwierdzonego do kodu pomyślnie uruchomionego w środowisku produkcyjnym
  • Częstotliwość wdrażania: bezpośrednia lub pośrednia miara czasu odpowiedzi, spójność zespołu, możliwości deweloperów, efektywność narzędzi programistycznych i ogólna wydajność zespołu DevOps.
  • Średni czas przywracania: jak długo zwykle trwa przywracanie podstawowej aplikacji lub usługi w przypadku wystąpienia zdarzenia usługi.
  • Procent zmian niepomyślnie: procent zmian w środowisku produkcyjnym (w tym na przykład zmiany wersji oprogramowania i konfiguracji infrastruktury), które kończą się niepowodzeniem.

Jest to odpowiedzialność kierownictwa devOps za mierzenie elementów, takich jak metryki kondycji operacyjnej, użycie, szybkość i kondycja lokacji na żywo. Innymi słowy, miara IMPACT, a nie ACTIVITY. Metryka jest przydatna tylko wtedy, gdy można ją podjąć działania.

Mimo że zespoły scrum mierzą pojemność zespołu, szybkość zespołu, burndown i liczbę usterek, te metryki są istotne tylko w kontekście zespołu. Ważne jest jednak, aby kierownictwo metodyki DevOps koncentrowało się na wpływie.

Ważne

Mierzenie wpływu, a nie działania!

Rzeczy, które mierzymy:

Użycie

Prędkość

Kondycja witryny na żywo

  • Nabycie
  • Zaangażowanie
  • Stopień zadowolenia
  • Zajętość
  • Użycie funkcji
  • Czas kompilacji
  • Czas na samodzielne testowanie
  • Czas wdrożenia
  • Czas na naukę
  • Czas wykrywania
  • Czas komunikacji
  • Czas, aby rozwiązać problem
  • Wpływ na klienta
  • Elementy zapobiegania zdarzeniu
  • Starzenie się problemów z witryną na żywo
  • Umowa SLA na klienta
  • Metryki pomocy technicznej klienta

Rzeczy, których nie oglądamy:

  • Oryginalne oszacowanie
  • Ukończone godziny
  • Wiersze kodu
  • Pojemność zespołu
  • Burndown zespołu
  • Szybkość zespołu
  • Liczba znalezionych usterek

Ważne

Metryki wpływają na wyniki biznesowe.

Dostosowanie wskaźników KPI do nawyków jest ważne. Pomaga to osiągnąć pozytywne wyniki biznesowe.

Ważne nawyki mające na celu wzmocnienie wskaźników KPI i skonfigurowanie zespołów na potrzeby sukcesu powinny obejmować:

  • Autonomia zespołu i dopasowanie organizacji: co, jak i dlaczego tworzymy. Potrzebujesz wspólnego rytmu lub pulsu w całej organizacji, aby umożliwić wszystkim zespołom kierowniczym i zespołom funkcji współpracę w sposób przejrzysty i skuteczny.
  • Skupienie się na kliencie: Wszystkie wysiłki muszą mieć bezpośredni lub pośredni wpływ na wartość klienta.
  • Pierwszy sposób myślenia w środowisku produkcyjnym: sposób myślenia, który nie rozróżnia sposobu obsługi funkcji i usterek podczas opracowywania, testowania i obsługi operacyjnej. Wszystko powinno być zautomatyzowane, wersjonowane i dostosowane do środowiska produkcyjnego.
  • Zmiana jakości w lewo i niepowodzenie: zachęcaj przeglądy, walidacje i zatwierdzenia zarówno do testowania, jak i zabezpieczeń tak wcześnie, jak to możliwe w cyklu dostarczania funkcji, aby zwiększyć jakość i szybki sposób myślenia.

Diagram przedstawia relację między metrykami, wskaźnikami KPI, nawykami i wynikami biznesowymi. Metryki obsługują kluczowe wskaźniki wydajności, które powinny być zgodne z nawykami w celu osiągnięcia wyników biznesowych. Przykłady wskaźników KPI obejmują czas realizacji, częstotliwość wdrażania, średni czas przywracania i zmianę współczynnika awarii. Te kluczowe wskaźniki wydajności powinny być dostosowane do nawyków, takich jak: autonomia zespołu i dopasowanie organizacji, skupienie się na klientach, sposób myślenia pierwszego w środowisku produkcyjnym i zmiana jakości w lewo i szybko. Takie dostosowanie pomaga osiągnąć wyniki biznesowe, takie jak krótszy czas obrotu, wyższa jakość, mniej odpadów i kompleksowe zabezpieczenia.

Ciągła opinia

Następnie zastanówmy się, jak używać ciągłej opinii na potrzeby współpracy.

Najczęściej mówi się o nowoczesnych deweloperach aplikacji pochodzi od startupów. Dlaczego są one tak skuteczne? Ponieważ ich praktyki chude są niewykonane przez lata wyrafinowanych procesów.

Lean startupy ustanowiły optymalną ścieżkę do opracowywania, dostarczania i udoskonalania pomysłów — tworząc niesamowitą pozytywną kulturę ciągłej opinii:

  • Wersja wczesna, wersja często
  • Rozpocznij od minimalnej opłacalnej wersji produktu
  • Korzystanie z rozwoju opartego na hipotezach
  • Ciągłe ulepszanie dzięki opinii klientów

Diagram przedstawia cykl ciągłej opinii. Zaczynamy od pomysłów, kompilowania kodu i mierzenia wyników w celu zbierania danych. Data pomoże nam nauczyć się i wygenerować nowe pomysły. Ciągła opinia minimalizuje całkowity czas przez pętlę.

Ciągłe ulepszanie za pomocą mapowania strumienia wartości

Gdy mamy pomiar i opinie, poprawa staje się ćwiczeniem opartym na danych.

Jednym z skutecznych sposobów obsługi ciągłego ulepszania jest mapowanie strumienia wartości. Strumień wartości to sekwencja działań, które organizacja podejmuje w celu dostarczenia żądania klienta.

Mapowanie strumienia wartości to bardzo skuteczny sposób na poznanie i rozwiązywanie problemów z rozłączeniami, nadmiarowością i lukami w sposobie wykonywania pracy. Nie jest to tylko narzędzie, ale metodologia oparta na zespole, która naszym zdaniem jest podstawą sprawdzonej praktyki zarządzania.

Analiza strumienia wartości pozwala podzielić proces dostarczania i zmierzyć czas realizacji, czas cyklu i czas bezczynności, co pomaga zespołom wprowadzać korekty oparte na danych w przepływie pracy.

Te miary pomagają zespołom planować, wykrywać różnice w wydajności i identyfikować potencjalne problemy z procesem.

Diagram przedstawia etapy procesu dostarczania. Czas realizacji to całkowity czas na wszystkich etapach. Czas bezczynności to czas między dwoma etapami. Czas procesu lub cyklu mierzy czas trwania etapu.

Napiwek

Im niższa liczba potencjalnych klientów i czasów cyklu, tym szybciej przepływność ma twój zespół.

Musimy być w stanie zidentyfikować różnicę między niepotrzebną pracą nienależącą do dodania wartości i niezbędną pracą nienależącą do wartości, aby ułatwić identyfikowanie przyszłych zmian w celu poprawy procesu.

Niepotrzebna praca nienależącą do wartości jest prawdziwą stratą: klient go nie ceni, a organizacja nie musi tego robić, aby pozostać realnym przedsiębiorstwem. Zużywa zasoby bez dodawania żadnej wartości do produktu.

Diagram pokazuje, że czas realizacji obejmuje niepotrzebny i niezbędny czas procesu bez dodawania wartości, a także czas procesu dodawania wartości.

Metodyka DevOps oparta na danych: metryki ułatwiają podróż

Transformacja metodyki DevOps to podróż, a najlepszym i najbardziej efektywnym sposobem, aby poprowadzić się przez proces DevOps, jest proces DevOps oparty na danych.

Diagram przedstawia przepływ podróży metodyki DevOps. Zespoły rozpoczynają transformację i identyfikują szybkie zwycięstwa. Automatyzacja pomaga w postępach o niskich wykonawcach do średnich wykonawców. Automatyzacja zwiększa wymagania dotyczące testów, które są traktowane ręcznie. Góra długu technicznego blokuje postęp. Dług techniczny i zwiększona złożoność powodują dodatkowe ręczne kontrole i warstwy procesu wokół zmian, spowalniając pracę. Nieustanna poprawa pracy prowadzi do doskonałości i wysokiej wydajności! Wysokiej i elitarnej wykonawców wykorzystują wiedzę i uczą się od swoich środowisk, aby zobaczyć skoki wydajności.

Sugerujemy utworzenie całościowego podejścia do mierzenia skuteczności metodyki DevOps i zapewnienia przejrzystości inicjatyw związanych z transformacją metodyki DevOps. Utwórz kulturę, która promuje uczenie się i eksperymentowanie wymagane przez metodykę DevOps, koncentrując się na metrykach, które podkreślają sukces. Przyznaj te sukcesy, świętując właściwe zachowanie, a nie karając niewłaściwego.