Eksplorowanie ciągłej jakości

Ukończone

Ciągła jakość to jedna z ośmiu funkcji taksonomii DevOps.

Dowiedz się, dlaczego wymagana jest ciągła jakość

Rozważmy przykład, dlaczego jakość i ciągła jakość są tak ważne.

Japonia przyjęła rygorystyczny program zapewniania jakości, który dotyczył ich producentów samochodów. Ze względu na program uzyskali reputację produkcji wysoce wydajnych i niezawodnych samochodów, które odróżniały je od konkurencji.

Różnicując się produktami o wyższej jakości, japońscy producenci samochodów byli w stanie opracować innowacje w zakresie efektywności paliwowej, bezpieczeństwa i procesów produkcyjnych. Koszty spadły również z powodu niższych stawek awarii, które wynikały ze wzrostu jakości. Ich konkurenci nie mieli wyboru, ale grać nadrobić zaległości.

Dlaczego więc potrzebujesz jakości?

• Aby produkty można było uratować.
• Aby zmniejszyć koszty.
• Aby odróżnić cię od konkurencji.

Najważniejsze zalety jakości ciągłej obejmują:

• "Jakościowy" sposób myślenia, który promuje wspólną odpowiedzialność za jakość.
• Zmniejszenie odpadów ze względu na częste przeróbki spowodowane wadami.
• Mniej długu technicznego ze względu na brakujące wymagania dotyczące jakości gromadzące się w czasie.
• Większa zadowolenie klientów.
• Mniej zdarzeń, które zakłócają działalność firmy.

Skupienie się na jakości tak szybko, jak to możliwe w cyklu rozwoju, powoduje znaczne oszczędności czasu i nakładu pracy.

Tym dłużej trwa scalanie kodu, a później występują problemy, tym bardziej kosztowne jest rozwiązanie tego problemu. Przyjrzyjmy się zwrotowi z inwestycji:

• Kosztuje 5X, jeśli usterka zostanie znaleziona w fazie opracowywania.
• Kosztuje 10X, jeśli usterka zostanie znaleziona w testach integracji.
• Kosztuje 15X, jeśli usterka zostanie znaleziona w testach akceptujących użytkowników.
• Kosztuje 30X, jeśli w wydaniu produktu znaleziono wadę.

Moralna historia jest inwestowanie w jakość wcześniej!

Wspieranie kultury jakości z ciągłą jakością

Ciągła jakość polega na wspieraniu kultury jakości, dzięki czemu zespoły mogą:

• Tworzenie doskonałych środowisk użytkownika
• Tworzenie funkcji pasujących do czasu rynku
• Włącz charakterystykę aplikacji, która dostarcza wartość szybciej niż tworzą dług techniczny

Ważne jest również, aby uważać na fałszywe założenie, że tym więcej usterek znajdziemy i naprawimy, tym lepiej będzie jakość.

Jeśli nie utworzyliśmy usterek na początku, nie będzie żadnych usterek do znalezienia. Ale jesteśmy ludźmi i popełnimy błędy i stworzymy błędy. Powinniśmy uciec od myślenia, że znalezienie usterek, które sami stworzyliśmy, sprawia, że jakość jest lepsza.

Zadaj sobie pytanie: Kto tworzy usterki? To właściciel produktu, scenarzysta, projektant, architekt, koder, tester... każdy, naprawdę.

Oprócz wspierania kultury jakości, Continuous Quality jest również o mentalności – pasji do nauki i wprowadzania naszych najlepszych na co dzień, aby zrobić większą różnicę na świecie.

Sposób myślenia o ciągłej jakości:

• Zachęca do wzrostu i innowacji oraz tworzy kulturę, która umożliwia i pielęgnowanie zachowań opartych na jakości.
• Wie, że jakość jest wbudowana, że nie można jej przetestować.
• Priorytetyzuje jakość nad nowymi funkcjami.
• Opowiada się za zespołem.
• Ponosi odpowiedzialność za odpowiedzialność za celach dostarczanych.
• Przenosi testy w bok.

Przejście od zapewnienia jakości do ciągłej jakości

Jest to znacząca zmiana paradygmatu z tradycyjnej kontroli jakości na ciągłą jakość. W poniższej tabeli przedstawiono różnice między nimi:

	Tradycyjna kontrola jakości	Ciągła jakość
Dlaczego	Przerywanie systemu	Ulepszanie systemu
Co	Sprawdzanie funkcjonalności	Informacje o systemie
Kto	Odpowiedzialność testera	Cały zespół jest właścicielem jakości
Kiedy	Testowanie na końcu	Testowanie w całym
Gdzie	Etap kontroli jakości	Wszędzie
Jak	Znajdowanie problemów	Zapobieganie problemom
Wynik	Minimalna jakość	Zwiększenie jakości

Należy pamiętać o wyzwaniach i zagrożeniach związanych z ciągłą jakością

Ciągła jakość	Wyzwania i zagrożenia
	Silosy organizacyjne i tradycyjne struktury zarządzania najwyższego poziomu mogą utrudniać tempo wdrażania. Te wyzwania zostaną pokonane tylko wtedy, gdy dojrzała dojrzałość organizacyjna i niezbędna zmiana kultury w całej organizacji oraz w miarę dojrzewania praktyk i projektów DevOps.
	Ciągła jakość wymaga zaangażowania wszystkich uczestników projektu i umożliwienia im odepchnięcia. Brak wyraźnie określonych celów i obawy przed nieznanymi może również spowodować odepchnięcie. Wsparcie wyższego szczebla kadry kierowniczej ma kluczowe znaczenie dla sukcesu podczas wspierania myślenia o ciągłej jakości w całej organizacji.
	Korzystanie z ciągłej jakości w tworzeniu oprogramowania wymaga zmian w zakresie obowiązków związanych z rolą i zmianą kultury organizacyjnej. Te zmiany wymagają znacznych inwestycji i czasu, co wpłynie na osie czasu i spowoduje spadek wydajności przed osiągnięciem poziomu ekspertów. Zwiększy również jakość systemów cyfrowych.
	Narzędzia i technologia są elementami ciągłej jakości, ale nie można po prostu rzucać technologią w postrzegany problem i mieć nadzieję, że go rozwiąże. Mimo że narzędzia automatyzują i ułatwiają procesy, ciągła jakość wymaga zmiany kultury organizacyjnej. Jeśli nie masz procesu, lepiej masz nadzieję, że proces dostawcy działa dla Ciebie.
	Ciągła jakość może stać się dźwignią dla szerokiej zmiany organizacyjnej przy użyciu nowych modeli współpracy i komunikacji oraz poprzez promowanie wspólnej odpowiedzialności za jakość. Jeśli jednak pozostaje on tylko technicznie skoncentrowany na ciągłej integracji i testowaniu, organizacja nie zda sobie sprawy z korzyści, jakie ma na to nadzieję.
	Pomiar jest niezbędny, ale wąski nacisk na pojedynczą metrykę jakości może zwiększyć pracowników, aby poprawić metrykę kosztem innych celów firmy, a nawet zadowolenia klientów. Jeśli organizacja nie wie, co oznacza ciągła jakość, może doświadczyć wielu fałszywych startów podczas jego ustalenia. A brak wczesnego sukcesu może zniechęcać organizacje do realizacji korzystnych zmian kulturowych i współpracy, które mogą zapewnić ciągła jakość.