07.04.2025 Axel
DevOps - agile Transformation
Was ist DevOps?
DevOps ist eine enge Zusammenarbeit der Bereiche Development (Entwicklung) und Operations (IT Betrieb) mit dem Ziel, die Wertschöpfungskette zu optimieren. Gemeinsame Prozesse ermöglichen dieser Zusammenarbeit, Lead Times (Lieferzeiten) und Feedback Loops (Rückkopplungsschleifen) zu verkürzen, und damit den Arbeitsdurchsatz zu erhöhen. Um diese Prozesse bestmöglich verwalten zu können, werden vielfach verschiedene Methoden aus dem [lean.management] eingesetzt. Darunter fallen beispeilsweise folgende wesentliche Bestandteile:
- Visualisierung von Aufgaben/Prozessen
- Begrenzung der Anzahl der aktuell aktiven Aufgaben (WIP: Work In Progress)
- Begrenzung der Größe der jeweiligen Aufgaben
- Reduzierung der Anzahl von Übergabepunkte
Visualisierung von Aufgaben/Prozessen
Im Gegensatz zur Fertigung ist der Wertstrom in der Informationstechnologie oftmals nicht sichtbar. Dadurch ist es in der Folge auch nicht möglich, Engpässe innerhalb des Wertstromes zu erkennen. Um diesem Problem entgegen treten zu können, ist es wichtig, Aufgaben/Prozesse zu visualisieren. Dazu wird oft die bewährte Methode Kanban herangezogen.
Die Visualisierung von Aufgaben/Prozessen ermöglicht es, Engpässe innerhalb eines Wertstromes zu erkennen und zu beseitigen. Dazu kann nach Eliyahu M. Goldratt aus The Goal: A Process of Ongoing Improvement [goal] wie folgt vorgegangen werden:
- Identify the system’s constraint
- Decide how to exploit the system’s constraint
- Subordinate everything else to the above decisions
- Elevate the system’s constraint
- If a constraint has been broken in the previous steps, go back to step one but don’t allow inertia to cause a system constraint
Begrenzung der Anzahl der aktuell aktiven Aufgaben
Kognitive Kontextwechsel sind teuer. Daher versucht DevOps solche kognitiven Kontextwechsel (aka. Multi-tasking) zu begrenzen. Es ist besser, eine Aufgabe vollständig in einem Durchgang zu bearbeiten und zu beenden, denn viele Aufgaben gleichzeitig zu bearbeiten und keine zu beenden. (“Stop starting. Start finishing”). Ein Beispiel dazu wird im nächsten Abschnitt beschrieben.
Kanban hilft hier, die Anzahl der aktuell aktiven Aufgaben (Work in Progress) zu visualisieren und zu begrenzen.
Begrenzung der Größe der jeweiligen Aufgaben
Kleingeschnittene Aufgaben können schneller bearbeitet werden, womit sich die Qualität verbessert und die Lieferzeiten verringern.
Ein einfaches Beispiel dafür wird in Lean Thinking: Banish Waste And Create Wealth In Your Corporation [lean.thinking] beschrieben. Es zeigt den Unterschied auf zwischen groß- und kleingeschnittenen Aufgaben. Im Beispiel werden dafür zehn Prospekte versendet. Und jeder Versandvorgang erfordert wiederum vier Schritte: (F) Prospekt falten, (I) Prospekt in den Umschlag stecken, (Se) den Umschlag verschließen, (St) den Umschlag frankieren.
Bei großgeschnittenen Aufgaben wird für jeden Prospekt ein Schritt ausgeführt. Es werden also erstmal alle Prospekte gefaltet. Danach in einen Umschlag gesteckt. Dieser Umschlag wird dann verschlossen und zuletzt frankiert.
Dagegen wird bei kleingeschnittenen Aufgaben erst jeder Prospekt fertiggestellt, bevor es an den nächsten Prospekt geht. Den Unterschied kann man im nachfolgenden Bild erkennen:[1]
Silos
Die Idee hinter DevOps ist, sog. Silos, d.i. autonome Bereiche, Abteilungen und/oder Teams in einem Unternehmen, aufzulösen und den Wertstrom bzw. die Wertschöpfungskette zu optimieren. Bekannte Beispiele solcher Silos sind Development und Operations. Indem beide Silos aufgehoben und miteinander verschmolzen werden, reduzieren sich die Anzahl der Übergabepunkte. Ebenso verkürzen sich die Feedback Loops.
Eine Feedback Loop in pre-DevOps Zeiten ist etwa die Rückmeldung von Operations an Entwicklung, wenn während eines Deployments Probleme (aka. Bugs) aufgetreten sind, die ein erfolgreiches Deployment verhindert haben und von der Entwicklung nachgearbeitet und behoben werden müssen. Diese Rückkopplungsschleife kann sooft und solange bedient werden, bis ein Deployment fehlerfrei erfolgt ist.
Fazit
DevOps muss mehr als eine Kultur, denn als Disziplin, verstanden werden. In vielen Unternehmen gibt es “DevOps”-Teams, die im Bereich IT Operations verortet sind und überwiegend Aufgaben automatisieren. Automatisierung ist als eine der technischen Methoden zwar ein wesentlicher Bestandteil der DevOps Kultur, aber dafür nicht kennzeichnend.
Die DevOps Transformation ist eine kulturelle Entscheidung des Unternehmens. Sie ist umso erfolgreicher, je höher sie in der Unternehmenshierarchie angestoßen und gelebt wird. Wir können Sie bei dieser agilen Transformation kompetent unterstützen und begleiten.
Referenzen
- [lean.management] Anja Zalik. Lean Management. FHC+P Blog. Abgerufen 01. April 2025
- [goal] Eliyahu M. Goldratt. North River Press, 2012. The Goal: A Process of Ongoing Improvement, 4th rev. Edition
- [theory.of.constraints] Eliyahu M. Goldratt. North River Press Publishing, 1990. Theory of Constraints
- [phoenix.project] Gene Kim, Kevin Behr, George Spafford. IT Revolution Press, 2018. The Phoenix Project
- [devops.handbook] Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren PhD. IT Revolution Press, 2021. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, 2nd Edition
- [making.work.visible] Dominica DeGrandis. IT Revolution, 2022. Making Work Visible: Exposing Time Theft to Optimize Work & Flow, 2nd Edition
- [lean.thinking] James P. Womack, Daniel T. Jones. Simon & Schuster UK, 2003. Lean Thinking: Banish Waste And Create Wealth In Your Corporation