Wer ist in agiler Verantwortung für die Qualität der Entwicklung komplexer Projekte oder die Methodik von Quality Gates

    Heute erleben wir, wie das Wasserfallmodell der Entwicklung allmählich auf der ganzen Welt stirbt. Sie mag nicht für schweres Gewicht und schlechte Reaktion auf Veränderungen. Dies wirkt sich direkt auf die Relevanz des Produkts aus und erhöht die TTM (Time-to-Market), wodurch zusätzliche Kosten entstehen. Entwickler werden auf agilen Schienen umgebaut, und wir machen da keine Ausnahme.

    Die agile Methodik wurde ursprünglich für kleine Teams entwickelt, die ein schlüsselfertiges Produkt im End-to-End-Modus herstellen und für die Qualität verantwortlich sind. Was aber, wenn Sie äußerst kritische Banksysteme entwickeln, in denen Dutzende agiler Teams arbeiten? Wie kann das Vertrauen in das Produkt erreicht werden, das eine lange und umfassende Prüfung des Wasserfalls ermöglicht? In diesem Beitrag werden wir unsere Lösung für dieses Problem mitteilen.



    Jeder löst das Problem auf andere Weise, aber in der Regel kommt es auf die Testautomatisierung an. Tests an Stubs werden entwickelt, allgemeine Regeln für die Bildung von Rückständen benachbarter Befehle sind Rahmen für die Interaktion zwischen Teams des SAFe-Typs. Dank der Synchronisierung von Backlogs können Teams zusammengehöriger Produkte zusammen schreiben und Tests durchführen, einschließlich Integrationstests. Wir haben auch solche Rahmenbedingungen.

    Jetzt werden wir uns an die Stelle des Inhabers eines komplexen und äußerst kritischen Bankensystems setzen. Wer ist noch für die Qualität dieses gesamten Produkts verantwortlich, wenn ein Dutzend verantwortungsbewusst agiler Teams gleichzeitig damit beschäftigt sind? Wir brauchen das Vertrauen, dass in der Produktion nichts rollen wird. Zusätzliche Tests einführen Hallo, Wasserfall und auf Wiedersehen, TTM.

    Es gibt keine perfekte Lösung. In dieser Situation haben wir immer einen Konflikt zwischen den Prinzipien der Methodik und der garantierten Zuverlässigkeit des Ergebnisses. Hier haben wir einen Kompromiss gefunden.

    Qualitätstore


    Wenn die Besonderheiten Ihres Produkts davon ausgehen, dass es nicht vollständig von anderen isoliert ist, sollten Sie an den Berührungspunkten nach einer Regel spielen - beachten Sie dabei ein Mindestmaß an Qualität. Der Code sollte durch Komponententests abgedeckt werden, sollte keine kritischen Defekte in der Informationssicherheit enthalten. Distributionen sollten Smook-Tests bestehen, wenn sie ausgeliefert werden. Keine Dose, aber die Anforderungen sind für alle verbindlich. Ihre Ausführung ist ein Pass zu allgemeinen Tests.

    Im Allgemeinen sieht die Praxis von Quality Gates also so aus : eine Reihe automatisierter Prüfungen, die in die Devops-Pipeline jedes Systems integriert sind. Tatsächlich spiegelt es die Tendenz zu Schichttests wider, von denen heute oft als Teil der Devops gesprochen wird.



    Wir haben mit allen Teams eine Reihe von Überprüfungen vereinbart, Qualitätsgatter, die sie während des Durchlaufs der Phasen des Lebenszyklus durchlaufen müssen.

    Codierung


    Vor dem Zusammenstellen des Codes ist eine obligatorische statische Analyse erforderlich, die den Code auf Übereinstimmung mit den Standards einer bestimmten Programmiersprache überprüft. Und auch zur Vollständigkeit der Beschichtungstests. Dafür gibt es verschiedene Werkzeuge. Wir lieben zum Beispiel den SonarQube. Nach diesem Qualitätszugang können Teams sicher sein, dass sie nicht frühzeitig gegen einige grundlegende Regeln verstoßen haben. Sie haben beispielsweise erhebliche Duplizierungen vermieden, was die Komplexität des Codes und die Wahrscheinlichkeit von Problemen erhöht.

    Die zweite Prüfung vor dem Zusammenbau ist eine IB-Prüfung. Es gibt allgemein anerkannte Vorgehensweisen zum Erkennen von IS-Problemen im Code und Tools, mit denen der Code gescannt und gefährliche Stellen identifiziert werden können. Beispielsweise kann eine falsch deklarierte Variable zu Produktionsproblemen führen. Hier haben wir uns darauf geeinigt, nicht alles, was sich beim Schreiben des Codes offenbart, Pententests und komplexeren Prüfungen zu erlauben.

    Distributiv aufbauen


    Wenn Sie ein Verteilungskit zusammenbauen, werden wir auf jeden Fall das Ergebnis überprüfen: Die Baugruppe wurde ordnungsgemäß durchlaufen, alle Dienste wurden gestartet und funktionieren wie vorgesehen, das Verteilungskit kann in der gewünschten Umgebung installiert werden und funktioniert. Durch einen solchen Prüfungstest werden mögliche Missverständnisse zwischen Tester und Entwickler vermieden. In der Wasserfallpraxis kam es vor, dass der Entwickler die Arbeit beendete, das Verteilerset an die Tester weitergab, und als er auf einem Ständer installiert wurde, stellte sich heraus, dass die Montage nicht einmal gestartet wurde. Dann wurde der gesamte Zyklus unterbrochen, die Entwicklung gedehnt und nichts Gutes geschah.

    Wir haben eine Integrationsinteraktion aufgebaut, die sehr schwierig ist. Es ist wichtig, den Stand nicht zu brechen, was auch von anderen Teams überprüft werden kann. Wir können es wegen einer schlechten Verteilung tun, und die Nachbarn auf dem Stand werden es vor uns erfahren - wir brechen einfach den gesamten Arbeitsprozess damit auf. Darüber hinaus können Sie die Testdaten beschädigen. Und ihre Herstellung kostet auch Geld und kostet viel Zeit. Vor allem wenn es um unpersönliche Nutzerdaten geht.

    Rauch-Tests


    Da das Verteilungskit auf jedem Prüfstand installiert ist, besteht eine Reihe einfacher Rauchprüfungen. Die Funktionalität des Verteilungskits wird auf dem Systemprüfstand getestet. Dann wird das Verteilungskit auf die Integrationstestbank gestellt, auf der die Interaktionen der Integration getestet werden. Es führt auch eine Reihe von Rauchprüfungen durch. Wenn die Verteilung sie nicht besteht, kann sie nicht zur nächsten Stufe übergehen.

    Mit Hilfe dieser Qualitätstore bekommen wir die primäre Vorstellung von der Qualität der Distribution. Wenn die Smoke-Tests erfolgreich bestanden wurden, fährt das Team mit den Tests fort. Wenn die Verteilung zu diesem Zeitpunkt keinen Rauchtest besteht, besteht höchstwahrscheinlich keine manuelle Prüfung. Hier weisen wir es nur zu, wenn die Baugruppe möglicherweise bereit ist, in die Industrie zu gehen.

    Qualitätstore als Rahmen


    Wir sind bestrebt, sicherzustellen, dass Quality Gates zu einem vollwertigen Rahmen für das Management der Qualität der Entwicklung einer großen Anzahl von Produkten in agiler Form werden. Wenn ein Team ständig ausfällt, signalisieren selbst die erforderlichen Quality Gates, dass es Probleme gibt, die besprochen und gelöst werden müssen. Auf der anderen Seite kann ein Team, wenn es die grundlegenden Quality Gates bereits beherrscht und in interne Abläufe eingebettet hat, weiter gehen und zusätzliche Quality Gates hinzufügen.

    In Zukunft planen wir, neue Sätze von obligatorischen Qualitätstoren einzuführen. Und optional, dass jedes Team mit ausreichendem Reifegrad wählen kann, was es braucht. Wenn es sich beispielsweise lohnt, die Stabilität der Verteilung auf den Integrationsstandorten zu ermitteln, muss das Team ein einziges Qualitätsgatter einnehmen. Wenn Sie sicherstellen müssen, dass eine komplexe und aus mehreren Komponenten bestehende Baugruppe die Bereitstellung nicht erschwert, sind andere Aufgaben erforderlich. Jemand hat eine Vorurteile in Bezug auf die Sicherheit an der Front, jemanden, der Lasttests, Zugänglichkeit der Stände, Reaktion, jemanden im Vorfeld der Integration testet oder nach Daten sucht. Jedes Team kann für seinen Fall Qualitätstore finden.

    Es ist wichtig zu wissen, dass Quality Gates kein Ersatz für Tests sind, sondern ein primäres Steuerungswerkzeug.. Testen niemand storniert. Die Hauptaufgabe besteht hier darin, den Schaden anderer Teams durch die schlechte Produktqualität so früh wie möglich zu minimieren.


    Beispiel einer Drittanbieter-Pipeline mit Qualitätsgattern

    Ergebnisse der Implementierung von Quality Gates


    Zunächst haben wir die Stabilität des Produktionszyklus erhöht. Links in Aktion können wir kritische Funktionsfehler sofort erkennen. Es wird weniger Zeit für verschiedene Test-Iterationen aufgewendet, Fehler werden früher erkannt, so dass ihre Beseitigung kostengünstiger ist.

    Die Vorlaufzeit hat sich verringert - die Zeit vom Start der Codierungsfunktionen bis zur Implementierung in der Produktion. Die Stabilität der Entwicklungsphase von TTM ist gestiegen, da wir die Ausfallzeiten bei der Bereitstellung der Verteilung an die industrielle Umgebung reduziert haben. Wir verbringen die gleiche Zeit zum Testen, gleichzeitig haben wir jedoch keine Ausfallzeiten, da der Stand zusammengebrochen ist und wir warten müssen, bis das Distributions-Kit neu aufgebaut wird.

    Die Verfügbarkeit von Medien zum Testen ist gewachsen. Zuvor konnte man eine Versammlung darauf legen und eine Woche lang vergessen. In der Zwischenzeit konnten benachbarte Teams in dieser Umgebung nicht getestet werden, da Ihr Build fehlerhaft ist und Sie dies nur in einer Woche erfahren. Wenn Sie nun die Baugruppe auf die Deponie legen, testen Sie sie selbst auf die häufigsten Probleme: Zurückrollen, Fertigstellen, Zurückkehren, falls erforderlich. Und die Chance, niemanden daran zu hindern, viel höher zu werden. Die Einführung von Quality Gates wird auch zu einer Verringerung der Kostendeckung für die Stände und zur Umschulung von Daten für Tests führen.

    Deine meinung


    Wie bereits gesagt, kann der Widerspruch zwischen den Prinzipien der agilen und komplexen Entwicklung nicht wie ein Gordischer Knoten geschnitten werden. Man kann nur danach streben, dass es so wenig Probleme wie möglich bringt. In unserem Fall hilft das Üben von Qualitätstoren, aber wir halten es natürlich nicht für ideal. Wie lösen Sie dieses Problem? Wir würden uns sehr freuen, dieses Thema zu diskutieren.

    Nikolay Vorobiev-Sarmatov, Sberbank-Technologies, Sberworks
    Vielen Dank an Mikhail Bizhan für die Hilfe bei der Vorbereitung des Artikels!

    Jetzt auch beliebt: