Der Trugschluss der Linksverschiebung

Ich bin fertig mit der ganzen Linksverschiebungs-Geschichte.

Als ich 1999 mit Informatik anfing, sagten die Professoren, dass man sich mit einem guten Design viel Geld und Fehlschläge erspart. Im Jahr 2000 sagten uns die Professoren, dass ein frühes Beginnen mit der Anforderungserhebung die Kosten senken würde. Früh wurde als der Moment definiert, der dem Softwaredesignprozess vorausgeht, im Gegensatz dazu, dass er Teil des Softwaredesignprozesses ist.

Auf die Geschichte mit dem frühen Sammeln von Anforderungen folgte ein Jahr später die Lehre von der iterativen Softwareentwicklung. Iterative Entwicklung würde im Gegensatz zu einem singulären sequenziellen Prozess (Wasserfall) Kosten und Entwicklungszeit reduzieren.

Die iterative Entwicklung würde den gesamten Softwareentwicklungszyklus weiter nach links verschieben. Die Aktivitäten zum Entwerfen, Erstellen, Testen und Ausführen würden alle zu einem früheren Zeitpunkt ausgeführt, wodurch große Fehler vermieden und somit Zeit und Geld gespart würden.

Die Argumentation war immer dieselbe:
Denken Sie nach, bevor Sie bauen, fragen Sie, bevor Sie bauen, liefern Sie schnell und holen Sie sich das Feedback Ihrer Stakeholder ein, um Geld und Zeit zu sparen.

Diese Argumentation ist sehr vernünftig.

Defekte entstehen während der Erstellung (Codierung) und werden während der verschiedenen Test-/Validierungsaktivitäten festgestellt. Die Behebung dieser Fehler ist kostspieliger, wenn sie Teil Ihres Produkts sind, als in der Entwurfsphase.

Ein Fehler ist nicht "nur" ein Fehler des Programmierers, ein Fehler kann in diesem Zusammenhang auch ein Endbenutzer/Stakeholder sein, der sagt: "Das habe ich nicht gemeint.". Ein Fehler ist die Diskrepanz zwischen dem, was in der Realität geschaffen wurde, und dem, was im Kopf erwartet wird. Die Kosten dieser Lücke sind der Grund für alle Shift Left Stories.

In der Abbildung von Stickyminds (I) finden Sie einen Hinweis auf die Kosteneinsparungen, die durch das frühzeitige Erkennen von Fehlern im Softwareentwicklungsprozess entstehen.

[I] Linksverschiebung beim Testen von Software

Linksverschiebungstäuschung in meinem Leben als Berater

Als ich 2006 als Analyst in der Beratung anfing, sagten mir meine Vorgesetzten, dass die Anforderungserhebung so früh wie möglich beginnen sollte. Sie als Anforderungsanalytiker sollten vor der Genehmigung des Business Case beginnen. Die Anforderungen waren bereits auf der Warum-Ebene vorhanden, als Geschäftsanforderungen. Daher waren die geschäftlichen Anforderungen bereits in der Analyse der geschäftlichen Auswirkungen und sogar in der Ideenfindungsphase relevant. Damals nannten wir die Ideenfindung die Phase der Problemerkennung.

In den folgenden Jahren habe ich die Erfahrung gemacht, dass Analysten, Tester, Architekten, Servicemanager und Projektmanager ihre Kollegen unterrichten;
"Je früher Sie sich einbringen und eine Rolle spielen,
desto höher die Qualität und desto niedriger die Kosten des Projekts/der Veränderung."

In einer früheren Phase des Veränderungsprozesses beteiligt zu sein, nennt man "Shift left".

In der Zeit von 2006 bis 2014 (agil) war der Grund dafür, dass die Wasserfall- und Prince2/PMP-Arbeitsweise besagt, dass jeder Schritt einen klaren Anfang und ein klares Ende haben muss. Außerdem sind die Aktivitäten in einer klaren Abfolge organisiert. Der Vorteil war, dass klar war, wer in einem bestimmten Stadium des Prozesses verantwortlich war. Der Nachteil ist, dass dies auch zu einer Art "Ich bin fertig, jetzt ist es Ihr Problem"-Mentalität führte (siehe Abbildung [II] dzone).

[II] Links schieben, rechts schieben, was schieben wir?

RNP identifiziert Zusammenarbeit

Eine meiner Lieblingsdefinitionen für Veränderungsprozesse ist der "Rational Unified Process" aus dem Jahr 1999. RUP stellte fest, dass Softwareentwicklung kein sequentieller Prozess ist und dass die Einbeziehung verschiedener Disziplinen in allen Phasen der iterativen Entwicklung von Bedeutung ist (siehe III).

Diese "altmodische" Methode der iterativen, multidisziplinären Entwicklung ist auch heute noch gültig.

[III] RUP_Erweiterung_für_Die_Entwicklung_von_verteilten_Systemen

RUP identifizierte 1999, was wir als Gemeinschaft in der agilen Arbeitsweise wiederentdeckt haben:
Produktentwicklung ist vor allem eine kollaborative Übung.

[IV] links-schieben-rechts-schieben-was-schieben-wir-und-wh

DevOps gewinnt durch Ideation

RUP besagt, dass Softwareprodukte vier Phasen mit mehreren Iterationen haben. Wir haben versucht, bei der Produktentwicklung die drei Teilbereiche zu berücksichtigen: Ideation, Validate, Produce [V].

[V] devops-mar-2019/

Es hat den Anschein, als würden wir uns jetzt auf das Entdecken und Liefern konzentrieren [VI].

[VI] Linksverschiebung Rechtsverschiebung Was verschieben wir und warum?

BuzDevOps gewinnt durch DevOps

Heute, im Jahr 2021, wird die Linksverschiebungslogik für die Themen BizDevOps [III] und Sicherheit verwendet. Der berühmte Devops-Zyklus Discover/Deliver wird um den Input aus dem Unternehmen erweitert.

Damit wird die iterative Art der Produktentwicklung berücksichtigt und anerkannt, dass Produkte heutzutage meist Softwareprodukte sind. Das ist eine sehr gute Entwicklung, wenn das Ziel kunden- und geschäftsorientierte Softwarelösungen sind, die in einem iterativen Prozess der kontinuierlichen Verbesserung bereitgestellt werden.

[VII] bizdevops überbrückt die vorherrschende Kluft zwischen Unternehmen und IT c1194297a706

Drei sind einer zu viel

Und hier ist der Haken. All diese erhöhte Effektivität wird unter der Flagge der Effizienzsteigerung angenommen.

Erinnern Sie sich daran, dass mehr "Design" im Vorfeld die Gesamtkosten und die Zeit reduzieren würde. Dies führt zu einer kürzeren Markteinführungszeit (IX, X), aber auch dazu, dass mehr "Akteure" und "Berufe" zur gleichen Zeit aktiv sind, was eine ausgefeiltere Koordination erfordert.

Wir alle wissen, dass drei Personen eine Menge sind und mehr als sieben Personen in einer Gruppe zu einer Gruppendynamik führen, die viel Zeit und Mühe kostet. Wenn Entwickler, Service Management und Operations, Tester, Sicherheitsexperten, Geschäftsleute, User Experience-Experten, Anforderungs-/Business-Analysten, Lösungsarchitekten, Unternehmensarchitekten, Systemarchitekten usw. mit am Tisch sitzen, wird es ein bisschen eng.

[VIII] Versteckte Kosten der Linksverschiebung
[IX] Qualität sichern durch Linksverschiebung

Krieg gegen Talente

Die großen Herausforderungen hierbei sind (A) wann verdient eine Veränderung die Kosten und den Fokus eines Teams, (B) welche Expertise suchen wir in einer Person, um die Größe eines multidisziplinären Teams unter Kontrolle zu halten?

Auf diese beiden großen Herausforderungen gibt es keine einfache Antwort. Ich wage sogar zu behaupten, dass es keine Antwort gibt.

Die Menschen bilden sich immer mehr in einer bestimmten Nische aus. Wenn Sie studieren, wählen Sie eine bestimmte Ausbildung, wenn Sie sich weiterbilden wollen, entscheiden Sie sich für bestimmte Fähigkeiten, die auf dem Markt sehr gefragt sind.

Leute, die über ein breites Spektrum an Fachwissen verfügen, sind sehr rar. Der Krieg um Talente im Bereich der Softwaretechnik ist seit Jahren Realität. Ganz zu schweigen von jemandem, der eine geschäftliche Sichtweise, ein Gespür für Benutzererfahrungen, die Fähigkeit, alle verschiedenen (Software-)Produktkomponenten zu überblicken und gleichzeitig ein hervorragender Softwareentwickler ist.

Wenn Sie alles nach links verschieben, malen Sie eine große Gruppe von Menschen in die Ecke des Raums.

[X] malen_sich_in_eine_Ecke

Die Sicherheit nimmt den Linksruck an

Bei der Sicherheit sehe ich die gleiche "Linksverschiebung". Am Anfang (1994 ~ 2016) war Sicherheit das Metier einiger weniger Spezialisten, heute wird Sicherheit als eine organisatorische Fähigkeit gesehen.

Die treibenden Kräfte dahinter sind (A) die komplexe IT-Landschaft mit komplexen Integrationen, (B) die ständige Gefährdung durch Cyber-Bedrohungen und (C) die GDPR, die Sicherheit und Datenschutz durch Design fordert, sowie (D) die Zero-Trust-Richtlinie der US-Regierung.

Das bedeutet, dass jeder IT-Experte lernen und verstehen muss, wie er Sicherheit in seine tägliche Arbeit und in seine spezifischen Fähigkeiten integrieren kann.

Auch bei den Nicht-IT-Mitarbeitern steigt die Nachfrage weiter an. Die Nicht-IT-Mitarbeiter eines Unternehmens verfügen über immer mehr IT-Kenntnisse, wodurch sich die Kluft zwischen Unternehmen und IT schließt. Auch die Nicht-IT-Mitarbeiter werden immer besser über den Mehrwert von Enterprise Design aufgeklärt. Jetzt müssen sie auch verstehen, was Sicherheit und Risiko für die Gestaltung ihrer Geschäftsorganisation und Produkte bedeuten.

Effizienz vs. Effektivität und Burnout

Das ist eine gewaltige Arbeitsbelastung für die gesamte Organisation.

Wie sollten wir dies auf geplante und koordinierte Weise tun? Ich weiß es nicht.
Ist es realistisch, dies von jedem Unternehmen zu erwarten? Ich glaube nicht.
Was bedeutet das dann? Ich weiß es nicht.

Während ich diesen Blog schreibe, veröffentlicht David das Neves seinen Blog mit dem Titel "Das DevSecOps-Paradox". David nähert sich der Linksverschiebung aus der Sicht der Entwickler. Er stellt fest, dass es nicht realistisch ist, von Entwicklern zu verlangen, dass sie Sicherheitsspezialisten werden.

[XI] DevSecOps paradoxon david das neves

Er rät zu einer Zentralisierung, indem er "Ihr komplettes Governance-Lebenszyklusmodell nach links verlagert" und "hochspezialisierte Enablement- und Plattform-Teams schafft", um dem Mangel an Experten zu begegnen.

Ich halte viel von diesem Ansatz, aber er steht im Widerspruch zu der Bewegung für Dezentralisierung, Beherrschung und Autonomie. Wir müssen als Organisation widerstandsfähig sein und deshalb dezentralisieren wir, aber wir müssen eine bestimmte Qualität erreichen und das Problem der Größenordnung durch Zentralisierung abmildern. Dies ist ein Pendel. Ich freue mich auf weitere Beiträge zu diesem Thema von David und Ihnen als Leser.

Kontinuierliche Verbesserung Sie

Was ich weiß, ist, dass der Beruf des Personalleiters immer wichtiger wird, um die Menschen dabei zu unterstützen, sich ständig weiterzuentwickeln, ohne in ein Burn-out zu geraten.

Ich weiß auch, dass die Fähigkeit des Geschichtenerzählens für Fachleute immer wichtiger wird, damit sie mit Leuten kommunizieren können, die Experten in einem anderen Bereich sind, da es unmöglich ist, dass sich alle auf der gleichen Ebene verstehen.

Unsere Herausforderung besteht darin, die Qualität unserer Produkte zu verbessern, als Unternehmen widerstandsfähig zu bleiben, für unsere Stakeholder relevant zu bleiben und nicht alle auszubrennen.

Resilienz und Menschenzentrierung sind die Hauptthemen für die nächsten Jahre.

Ich möchte alle, die diesen letzten Satz lesen, ermutigen, mir eine Nachricht zur Zusammenarbeit zu schicken und/oder auf Davids Blog zu antworten.

Gemeinsam werden wir einen Weg finden, uns mit DevOps weiterzuentwickeln und die Qualität unserer Produkte weiter zu verbessern.

Einen schönen Tag noch, Edzo
ebotjes@xebia.com; linkedin.com/in/edzob

---

Die Kernwerte von Xebia sind: Menschen zuerst, Wissen teilen, Qualität ohne Kompromisse und Kundennähe. Aus diesem Grund wird dieser Blogeintrag unter der Lizenz Creative Commons Attribution-ShareAlike 4.0 veröffentlicht.