Wie verkauft man eine technische Schuld aus DevOps-Sicht?

Oft wird dramatisch und pathetisch argumentiert, dass es besser sei, keine technischen Schulden zu machen. Ja, ohne geht es natürlich besser. Aber die Folgen können noch beseitigt werden.

Als technische Schulden bezeichne ich alle Änderungen und Verbesserungen, infrastrukturelle Modifikationen und Prozessänderungen, Änderungen in Teamstrukturen, die darauf abzielen, Lücken zu schließen (bewusst oder unbewusst im Rahmen der Produkteinführung vorgenommen) und Funktionen, die sich im Laufe der Zeit stark auswirken.

Und da solche Probleme ohne ein festes und souveränes Zusammenspiel der Produktions- und Betriebsabteilungen nicht gelöst werden können, geht es in dieser Geschichte direkt um DevOps.

Technische Schulden – wem gehört das?

Aber zuerst zur Wurzel des Problems: Warum spreche ich überhaupt von technischen Schulden? Weil ich sehr beleidigt bin, dass das Unternehmen dafür keine Zeit einplant. Dieser rote Faden zieht sich durch alle Berichte, Treffen und die Kommunikation zwischen Entwicklern und Betrieben.

Ein böses, schlechtes, schreckliches Geschäft nimmt sich keine Zeit, um mit technischen Schulden zu arbeiten. Es stellt sich sogar die berechtigte Frage: „Brauchen sie überhaupt keine Qualität?“ Mit Blick auf die Zukunft sage ich: „Niemand braucht Qualität.“ Aber diesen Gedanken werde ich etwas später verraten.

Um diese Situation zu analysieren, betrachten wir, warum Unternehmen uns das antun. Und um eine Antwort zu erhalten, müssen wir darüber nachdenken, wessen technische Schulden es sind. Wer ist dafür verantwortlich?

Nach Jahren des Engagements wurde mir klar, dass wir wie Frodo waren, der jedem einen Ring anbot. Es ist wie: „Hilf mir, diese Last zu tragen!“ Wir warten darauf, dass die Unternehmen wollen (genau wollen), dass wir uns um die technischen Schulden kümmern. Die Hauptursache für unser gegenseitiges Missverständnis mit der Wirtschaft liegt jedoch darin, dass sie dies niemals wollen wird.

Für uns ist es eine technische Herausforderung, eine Möglichkeit zur Verbesserung der Produktqualität oder sogar ein Mechanismus, um den Stolz auf unser Produkt zu steigern. Aber für das Geschäft ist es immer ein Ärgernis, ein notwendiges Übel (oder eine Notwendigkeit), dem Sie Zeit widmen müssen.

Stellen Sie sich vor, Sie steigen in ein Taxi und der Fahrer fragt: „Darf ich an der Autowaschanlage anhalten?“

Das Unternehmen ist in dieser Situation der Kunde und der Entwickler der Taxifahrer.

• Das Unternehmen ist empört: „Wieso?! Ich bezahle die Reisezeit und du gehst zur Autowaschanlage!“

• Worauf der Taxifahrer vernünftigerweise antwortet: „Wollen Sie nicht in einem sauberen Auto fahren, das gut riecht?“

• Das Unternehmen antwortet: „Mann, natürlich tue ich das! Aber ich erwarte es standardmäßig, und ich bin nicht bereit, jetzt dafür in die Autowaschanlage zu gehen!“

So gehen Unternehmen mit technischen Schulden um. Es ist wie ein Vorschlag, bei einer Autowaschanlage vorbeizuschauen. Ich wähle die entsprechende Kategorie aus, wenn ich ein Taxi bestelle, um einen sauberen oder luxuriösen Salon zu haben. Bei der Bestellung bin ich bereit, dafür zu investieren, bei der Autowaschanlage vorbeizuschauen jedoch nicht.

Denn wie ich bereits sagte: Niemand will Qualität. Aber es wird standardmäßig erwartet.

Es ist ein Muss. Unternehmen können sich nicht damit abfinden, nicht zur Autowaschanlage zu gehen, und Unternehmen können nicht auf Kosten ihrer Freizeit dorthin gehen. Also, was machen wir? Ein Unternehmen ist eine Lokomotive. Es braucht Funktionen, Verkäufe und Kunden. Es ist unmöglich, die technischen Schulden durch unser „Ich will“ und „Ich wünsche“ an ein Unternehmen zu verkaufen. Es ist jedoch möglich, Unternehmen auf andere Weise zu motivieren.

Im Laufe meiner Reise habe ich drei Kategorien geschäftlicher Motivation für den „Kauf“ technischer Schulden gebildet:

• „Fette“ Gleichgültigkeit. Wenn es einen reichen Investor gibt, kann sich der CEO ein Entwicklungsteam aus seltsamen Geeks leisten. Es ist wie: „Lasst sie es machen! Die Hauptsache ist, das Produkt fertigzustellen, und der Teamgeist ist großartig, alles ist cool und wir wären das beste Büro der Welt.“

  
  

  Meiner Meinung nach ist es eine coole Kür, die oft ins Desaster führt, weil technische Schulden Pragmatismus erfordern. Wenn wir es nicht pragmatisch machen, erschaffen wir einen Leviathan pseudocooler Architektur.

• Furcht. Dies ist eines der effektivsten, am weitesten verbreiteten und effizientesten Modelle für technische Schulden. Über was für ein „Wollen“ können wir hier sprechen, wenn es beängstigend ist? Es geht darum, wenn etwas passiert, wie zum Beispiel, dass ein Kunde aufgrund eines Fehlers oder eines Hacks das Unternehmen verlässt. Und das liegt alles an schlechter Qualität, Bremsen oder etwas anderem. Aber aus Angst unverblümt zu verkaufen ist auch schlecht. Spekulationen mit Angst wirken dem Vertrauen zuwider. Sie müssen sorgfältig und so ehrlich wie möglich verkaufen.

• Vertrauen. Dies ist der Fall, wenn Ihnen ein Unternehmen so viel Zeit gibt, wie Sie für die Bearbeitung technischer Schulden benötigen. Vertrauen funktioniert und bleibt nur erhalten, wenn man den Gesamtanteil sorgfältig kleinschätzt und sich diese Zeit möglichst pragmatisch nimmt. Andernfalls wird das Vertrauen zerstört. Außerdem sammelt es sich nicht an. Ein ständiger Prozess verläuft in Wellen: Vertrauen wächst und schwindet dann.

Als Nächstes bespreche ich meine Erfahrungen und was für mich und mein großartiges Team funktioniert.

Wie tief ist das Kaninchenloch mit technischen Schulden?

Als ich vor drei Jahren dem neuen Unternehmen beitrat, musste ich verstehen, wie hoch diese technischen Schulden waren. Dass es existierte, wusste ich aus der Statistik der Anfragen, auch von Unternehmen und Partnern. Ich musste herausfinden, womit ich es im Allgemeinen zu tun hatte.

Dies ist ein normaler und obligatorischer erster Schritt bei der Arbeit mit technischen Schulden. Sie sollten sich nicht beeilen, das Erste zu tun, was Sie finden. Sie sollten die Situation als Ganzes analysieren.

Basierend auf dem, was ich damals sah, ging ich davon aus, dass eines der Grundprobleme eine große Codekopplung ist. Jetzt beziehe ich jeden weniger in diesen Prozess ein, aber damals habe ich das gesamte Produktionsteam versammelt, um festzulegen, welche Ebenen wir in unserer Anwendungssuite hervorheben wollten.

Unsere Anwendung hatte mindestens 80 verschiedene Komponenten (Distributionen, keine Installationen). Nachdem man die Situation erkannt hatte, musste man sich damit befassen.

Phase 1. Virtuelle Teams

Da ich so schlau war, kam ich auf die Idee, so zu tun, als ob jeder Zeit hätte, und um jede Komponente herum ein virtuelles Team zu bilden. Es sah so aus: „Leute, wer übernimmt welche Komponente? Formuliert eure Vorschläge, wie man sie verbessern kann.“ Um aber konzentriert zu bleiben, haben wir gemeinsam die Kriterien für die Optimierung der ersten Phase formuliert:

• Lose Kopplung
• Kostengünstige Skalierbarkeit
• Einfache Anbindung neuer Entwickler (einfache und klare Prinzipien: Was genau kann in dieser Komponente gemacht werden und was nicht, plus Isolierung von Code, der nicht von jedem „angefasst“ werden kann)
• Möglichkeit, eine externe API dort zu verwenden, wo sie benötigt wird
• Zugänglichkeit des vorgeschlagenen Technologie-Stacks
• QuickWin-Optimierungen in aktuellen Lösungen
• Einfache Überwachung und Fehlerbehebung
• Audit- und Lizenzreinheitsprinzipien
• Versionierungs- und Obsoleszenzprinzipien

Dabei handelte es sich natürlich nicht um einen Schwerpunkt, sondern um eine Reihe von Kriterien für nahezu alle Aspekte der Softwareentwicklung. Die gesamte Liste kann durch einen Satz ersetzt werden: „Repariere alles.“

Diese Phase endete in einem Fiasko, in dem Sinne, dass einfach nichts passierte. Wir haben bei der Umsetzung einiger Dinge kaum Fortschritte gemacht, weil ich versucht habe, sie anhand eines gemeinsamen Rückstands zu planen. Die Aufgaben waren unverständlich. Sie wurden manuell in Betrieb genommen. Mir wurde schnell klar, dass es sowohl für mich als auch für das Team hart war und die Konflikte und Auseinandersetzungen immer größer wurden.

Also ging ich zu Phase 2 über.

Phase 2. Die technischen Schulden liegen bei mir

In Phase 1 habe ich mit dem CEO unseres Unternehmens vereinbart, dass wir eine Rückstandsquote einführen. Wir würden 70 % für geschäftliche Angelegenheiten, 15 % für die Beseitigung von Mängeln und 15 % für die technischen Schulden ausgeben.

Zweitens wurde mir in der vorherigen Phase klar, dass, wenn jeder für ein Problem verantwortlich ist, niemand für dieses Problem verantwortlich ist. Das ist überhaupt keine türkisfarbene Aussage. Mir selbst gefällt es nicht. Aber das Gegenteil erfordert ein sehr hohes Maß an Reife und Teamarbeit. Deshalb habe ich beschlossen, ein System technischer Führungskräfte aufzubauen.

Aber ich habe nicht einfach eine Person zum technischen Leiter einer Komponente ernannt. Ich habe meine Erwartungen so weit wie möglich dargelegt, ihren Entwicklungspfad definiert und sie für die Situation in der Produktion verantwortlich gemacht. Die OPS-Experten sind nicht wach, wenn Ihr Bauteil in der Produktion durcheinander gerät. Sie sind es, die versuchen, die Situation zu lösen.

Und so machten wir uns auf den Weg. Es gibt technische Leiter (die Verantwortlichen) und eine Quote von 15 % für technische Schulden (es gibt Zeit). Doch wie sah die Realität am Ende aus?

Das erste, was uns auffiel, war, dass wir FinTech, Compliance und Aufgabentrennung haben, das heißt, ich und die Entwicklung haben keinen Zugang zur Produktion und können ihn per Definition auch nicht haben. Und doch sage ich: „Leute, ihr seid für die Situation in der Produktion verantwortlich!“

Geben Sie den Leuten die Protokolle!

Wenn Sie Menschen Verantwortung übertragen, geben Sie ihnen bitte ein Werkzeug in die Hand. Und das ist das Erste, was wir mit den OPS-Experten gemacht haben, indem wir den Technikern Protokolle zur Verfügung gestellt haben, damit sie die Protokolle ihrer Komponenten einsehen konnten.

Und wir hatten eine wirklich gemeinsame Anstrengung – unseren ersten Schritt in Richtung DevOps, wo Betrieb und Entwicklung zusammenarbeiten. Die Ausbeutung richtete die Protokollübertragung ein (Kibana usw.), während die Entwicklung sicherstellen musste, dass die Protokolle keine sensiblen Informationen (personenbezogene Daten usw.) enthielten.

5 % gelten als Glücksbringer ...

Die Realität ist, dass es trotz der 15-Prozent-Quote in jedem Sprint einige Unternehmenskrisen und dringende Injektionen gibt, denn „Der Partner braucht es jetzt, sonst geht er!“ Diese technischen Schulden werden natürlich erst einmal aus dem Sprint herausgeschoben – in der Folge hatten wir Sprints mit 0 %.

Es gab auch Sprints mit 15 %, aber wir hatten im Schnitt nur 5-8 % technische Verschuldung. Dies ist ein großes Problem, da ein Programmierer nicht wissen kann, wie viel Zeit ihm für die Implementierung zur Verfügung steht.

Ich für meinen Teil habe versucht, dieser Situation zu helfen, indem ich unermüdlich einen Drachen über alle Teams steigen ließ. Wir haben gelernt, detaillierte Kennzahlen für jeden Sprint zu sammeln, und ich habe mir den Sprint am Ende angesehen.

Beim Sprint-Hacking handelt es sich um eine systematische Verletzung der technischen Schuldenquote. Wenn die Quote in einem Sprint nicht erreicht wird, heißt das nicht, dass alles schlecht ist. Tatsächlich gibt es unterschiedliche Situationen und Sie müssen flexibel sein.

Aber als es systematisch wiederholt wurde, versammelte ich die Produktionsexperten, argumentierte und erklärte, wie wichtig und inakzeptabel es sei, weil die Quote vereinbart worden sei. Es war meine tägliche Arbeit, den Prozess in diesem Modell voranzutreiben.

Und es hat sich bewegt, aber jetzt glaube ich, dass dieser Ansatz seine eigenen erheblichen Mängel hat.

Einschränkungen des Ansatzes

Product Owner sind daran gewöhnt, dass der Backlog ganz ihnen gehört und alle Aufgaben von ihnen koordiniert werden: „Quota ist gut, aber nur wir entscheiden, was das Team in dieser Quote an technischen Schulden macht!“

Und als Entwickler Aufgaben (denken Sie an die starke Konnektivität) wie Refactoring, Eliminierung von Boilerplates usw. aufkamen, bekamen sie eine logische Reaktion: „Was?! Welche Boilerplate? Worüber reden wir?!“

Infolgedessen wurden Aufgaben durch Aufgaben ersetzt, die als technische Schulden bezeichnet werden könnten, aber für den Anbieter bedingt von Vorteil waren. Deshalb musste ich eine harte Haltung einnehmen und sagen: „Die technischen Schulden gehören mir! Und ich behaupte, dass sie in die technischen Schulden jedes Produktteams in der Quote der technischen Schulden für jeden Sprint einfließen.“

So haben wir gelebt. Obwohl wir normal lebten und arbeiteten, wuchs das Misstrauen. Wenn wir etwas tun und niemandem erzählen, was es ist, und die Zeit nicht für geschäftliche Aufgaben aufwenden, ist für alle unklar, welches Ergebnis wir bringen.

Da die Statistiken über die Auslastung der technischen Schuldenquoten in die Höhe schnellten, sahen wir uns mit der Tatsache konfrontiert, dass wir keine großen Projekte durchführen konnten. Darüber hinaus erfordern große Projekte oft mehrere Teams. Dies war auch deshalb unmöglich, weil sich jedes Produktteam auf sein Produkt konzentriert und in dessen Realität lebt. Es ist unmöglich, sie an ein komplexes Thema anzudocken.

Außerdem hat niemand Operationen in die Sprints einbezogen. Sie haben keine Sprints und Backlogs wie in der Produktion. Sie sind mit Aufgaben in der Produktion überhäuft, aber das war nicht in den Gesamtplänen enthalten. Und wenn die Entwicklung mit etwas einhergeht, das innerhalb dieser kleinen technischen Schulden erledigt ist, um es in die Produktion zu bringen, könnte es ziemlich lange in den Anfragen von OPS bleiben.

Denn sie hatten wirklich keine Zeit, waren mit zusätzlichen Aufgaben überlastet und an der Arbeit gehindert.

Aber trotz der negativen Aspekte dieses Ansatzes haben wir einiges erreicht.

Was haben wir mit diesem Ansatz erreicht?

Zunächst haben wir die Muskelmasse der Autotests aufgebaut. Durch die grundlegende Neugestaltung des gesamten CI-Prozesses haben wir ihn zu einem zivilisierten Prozess gemacht, für den wir uns nicht schämen müssen.

Zweitens haben wir den Kampf gegen Spaghetti-Code in vielen Komponenten erfolgreich umgesetzt.

Wir haben eine Modularisierung vorgenommen und die Boilerplates reduziert. Diese Aufgaben können dem Unternehmen auch aus Angst nicht verkauft werden. Wenn die Technologielücken in Ihrem Produkt diese Probleme enthalten und Sie sie beheben müssen (wenn sie vorhanden sind, müssen sie zuerst behoben werden), müssen Sie nicht einmal versuchen, sie zu verkaufen. Das geht nur über das Modell „Technische Schulden – das gehört mir“, nur über Quoten.

Ich habe viele Versuche gesehen und in der ersten Phase selbst versucht, es anders zu machen. Es hat nicht geklappt.

Tatsächlich kann die Arbeit in diesem Modus nicht lange dauern. Es handelt sich um einen begrenzten Freibrief, den das Management Ihnen als CTO und Teamleiter anvertraut.

Phase 3. Legitimes Projekt

Dann haben wir Phase 3 initiiert – ein „legitimes“ Projekt zur Bearbeitung technischer Schulden. Die Annahme war, dass wir von einem geschlossenen Kontingent weggingen, die Planung anhand eines gemeinsamen Produkt-Backlogs (dh die Produktbesitzer akzeptieren, dass diese Projekte durchgeführt werden müssen) und zu einem sauberen Verkauf übergingen. Um dies zu erreichen, haben wir zwei Dinge getan:

• Ich habe den Arbeitsumfang, mit dem wir im Rahmen dieses Projekts begonnen haben, so weit wie möglich eingegrenzt.

• Ich habe konkrete Erwartungen darüber gebildet, wofür wir in der Produktion kämpfen werden. Es war eine völlige Ablehnung des Idealismus, denn unsere Aufgaben sollten möglichst pragmatisch, verständlich und aus geschäftlicher Sicht für den Dienst nützlich sein.

Ein wichtiger Punkt ist, dass wir eine gewisse Illusion haben, dass wir versuchen, den Geschäftswert technischer Schulden zu berechnen, obwohl dies selten möglich ist. Und wenn es noch berechenbar ist, dann haben wir eine technische Albtraumverschuldung!

Ein positiver Wert wirkt sich besser auf das Unternehmen aus als ein negativer Wert. Wenn Sie sagen: „Dieser Kunde wird gehen. Er bringt so viel Geld ein“, dann wird es nicht funktionieren, bis er geht. Es handelt sich nicht um einen geschäftlichen Wert. Darüber hinaus ist die Kultur des Umgangs mit Risiken noch nicht sehr hoch, daher lautet der Modus: „Kein Verlust, bis sie gehen.“

Es ist auch nicht notwendig, den Geschäftswert darzustellen. Wo man es zeigen kann, aber man kann den technologischen Wert zeigen, nur muss er berechnet werden.

Leitfaden zum Verkauf technischer Schulden

Hier ist der gesamte Arbeitsablauf dieser Phase für den Verkauf technischer Schulden.

Wählen Sie einen Schwerpunktbereich (nur einen)

Da es sich hierbei um einen Verkauf aus Angst handelt, wählen Sie einen Bereich, der Ihr Unternehmen wirklich beeinflusst. Die Bereiche können unterschiedlich sein: Verfügbarkeit, Geschwindigkeit der Nacharbeit, Sicherheit von A/B-Tests und Experimenten und Kosten der Nacharbeit. Es gibt eine Vielzahl an Bereichen und Themen.

In meinem Fall habe ich mich für Barrierefreiheit entschieden, weil sie im Fokus des Unternehmens stand und einen gewissen Einfluss auf unseren Service hatte. Es ist wichtig, sich nicht zu verzetteln und nur ein Thema auszuwählen.

Führen Sie eine Integralanalyse durch

Ich habe die Verfügbarkeits- und Vorfallstatistiken für das Jahr analysiert und alle Obduktionen für alle Situationen, die im Laufe des Jahres aufgetreten sind, detailliert analysiert. Danach entwickelte ich ein umfassendes Verständnis davon, woran wir so viel wie technisch möglich, aber auch inhaltlich, arbeiten müssen.

Die erste Regel der Verfügbarkeit besteht nicht darin, ein System aufzubauen, das immer verfügbar ist, sondern darin, bereit zu sein, wenn ein Vorfall eintritt. Dafür müssen wir sorgen.

Das zweite Problem und die Grundregel der Verfügbarkeit ist die Degradationsvereinbarung: Irgendwann muss etwas passieren, und Sie müssen bereit sein, Ihren Dienst aufrechtzuerhalten, möglicherweise um den Preis, dass Sie auf einige von Ihnen bereitgestellte Funktionen verzichten müssen. Diese Vereinbarung muss eingehalten werden, auch auf Programmebene.

Das dritte Thema betrifft Überwachung und Beobachtbarkeit. Dies ist die schnelle Lokalisierung von Vorfallquellen und die Reaktionserkennungszeit. Wenn Sie viele unzuverlässige Tests haben, müssen Sie aufhören, Ihrer Überwachung zu vertrauen. Wenn Ihre Produktionstests Anweisungen für Service-Desk-Reaktionen enthalten, wie zum Beispiel „Wenn es nicht innerhalb von 5 Minuten ausgegangen ist, rufen Sie mich an“ – überwachen Sie die Produktionssituation nicht. Der Test sollte möglichst eindeutig sein: „Es zeigt – es bedeutet, dass es irgendwo Ärger gibt, los geht’s!“

Führen Sie eine komponentenweise Analyse durch

Zu diesem Zweck haben wir festgelegt, was wir für jede Richtung und Komponente genau tun werden. Wir meinen, wo wir das Service-Mesh einbinden werden, wie wir die Überwachung verändern werden und auf welcher Grundlage. Hier haben wir etwa 15 % aufgelistet, aber tatsächlich gibt es viele Programmverbesserungen.

Wir haben alles geplant, aber es ist noch nicht marktfähig. Um es jetzt offen zu zeigen, haben wir für jedes Projekt dieser Phase Folgendes getan.

Formulieren Sie substanzielle, quantitative Indikatoren

Wir haben große Angst vor quantitativen Indikatoren: Wie können wir die Qualität der Entwicklerarbeit anhand quantitativer Indikatoren messen? Wir haben viele Argumente gegen quantitative Indikatoren, aber wir sollten sie nicht direkt angehen.

Wert sollte nicht nur als Geschäftswert verstanden werden. Sie können beispielsweise so formuliert werden: „nicht mehr als X Fehlalarme.“

Sie können einen bestimmten Satz von Komponenten auflisten, für die es wichtig ist, Canary-Releases bereitzustellen oder ein garantiertes Patch-Rollback sicherzustellen. Die Gesamtverfügbarkeit sollte natürlich ein quantitativer Indikator sein. Es ist ein Muss.

Verteidigung der Projekte

Mit dieser Reihe pragmatischer Projekte, möglichst klaren Kennzahlen und den Ergebnissen, die wir erreichen müssen, sagte ich: „Leute, ich brauche eine Quote an technischen Schulden. Ich möchte, dass Sie diese Projekte in Ihren Pool aufnehmen, um sie zu beschleunigen, damit sie funktionieren.“ gehen zusammen mit den Unternehmenszielen auf vollrechtlicher Grundlage in die Gesamtplanung ein.“

Es wurde gehört, wir haben es getan und es hat funktioniert. Ich denke, es ähnelt dem Video zum Zeichnen einer Eule: „Zeichne ein Oval und zwei Striche.“ Am Ende – magisch – erhalten Sie eine Eule! Aber die ganze Magie besteht darin, dass man das ganze Projekt auf den Punkt bringen und zu Ende bringen muss.

Nicht nur, um einige Dinge in diese Richtung zu tun, sondern um es zum Ergebnis zu bringen. Das heißt, die angegebenen quantitativen Indikatoren zu erreichen und anzuzeigen. Dieser Abgrund kann in 95 % der Fälle nicht übersprungen werden. Es muss komplett gesprungen werden.

Vorteile des Ansatzes

Also fingen wir an zu springen (über den Abgrund). Wir machen es erfolgreich. Jetzt befinden wir uns in der zweiten Runde dieses Projekts. Das heißt, wir haben den ersten Projektpool verschoben und uns auf den zweiten Projektpool geeinigt. Was hat sich verändert?

Vertrauen stärken

Vertrauen wird durch Offenheit deutlich gesteigert, wenn wir echte, quantifizierbare Kennzahlen aufzeigen. Aber die Wahrheit ist, dass der technische Schuldenverkauf aus Angst zustande kommt. Dieser Schritt lässt sich nicht vermeiden. Aber Sie müssen auch keine Angst davor haben oder sich dafür schämen. Die Hauptsache ist nicht, über die Angst zu spekulieren, sondern sie wirklich zu analysieren, wie ich in verschiedenen Phasen gezeigt habe (Integralanalyse, Komponenten-für-Komponenten-Analyse).

Große Projekte durchführen

Da es sich nun um legitimierte Projekte handelt, können wir uns teamübergreifend synchronisieren und wirklich große Projekte durchführen. Einige Projekte wurden nacheinander von Sprint zu Sprint durchgeführt. Wir werden innerhalb dieses Projekts regelmäßig (einmal pro Woche) durch die Zusammensetzung des Technologieteams verfolgt und verstehen, wer wo (in welcher Phase) ist.

Diese Informationen sind so offen und transparent wie möglich. Der Fortschritt von Projekten und aktuelle Status werden veröffentlicht und stehen den Produktbesitzern (und allen anderen, die es sehen möchten) zur Verfügung.

OPS-Mitarbeiter im Projekt

Vor allem wurde uns klar, dass wir in der Infrastruktur und im Rollout-Prozess viele Dinge neu gestalten mussten. OPS-Mitarbeiter wurden ausdrücklich in dieses Projekt einbezogen.

Meiner Meinung nach handelt es sich hierbei eher um DevOps als um Kubernetes und Docker, wenn OPS-Mitarbeiter mit Entwicklern diskutieren, wie die Architektur einer Komponente geändert werden kann, und Entwickler mit OPS-Mitarbeitern diskutieren, wie die Infrastruktur am besten geändert werden kann.

Warum habe ich es nicht sofort getan?

Da kommen wir wieder auf das zurück, worüber ich am Ende von Phase 2 gesprochen habe: Früher hätte es nicht funktioniert. Denn was wir in Phase 2 gemacht haben (Spaghetti-Code, den wir neu gestaltet haben, der Muskelaufbau bei Tests und die Neugestaltung von CI-Prozessen), wäre dem Unternehmen im Hinblick auf messbare Metriken unmöglich zu verkaufen gewesen.

Diese Situation war nicht auf eine bestimmte Angst zurückzuführen, und unser Standardargument „Wir brauchen viel Zeit zum Codieren, weil Spaghetti-Code“ – niemand in der Branche hört zu. Wir hätten diesen Ansatz also nicht durchziehen können.

Aus meiner Sicht kommt man bei einer Technologieplattform, die eine so tiefgreifende infrastrukturelle Überarbeitung erfordert, nicht um Phase 2 herum.

Sie müssen es wagen, aber Sie müssen nicht nur bereit sein, ständig wie ein Drachen herumzuflattern, sondern auch diesen Laden schnell genug zu schließen, um das Vertrauen Ihres Unternehmens nicht zu verlieren.