Die generell zunehmende Digitalisierung erfordert von Unternehmen eine hohe Flexibilität und eine schnelle Reaktion auf neue Anforderungen. Nur so kann die Wettbewerbsfähigkeit sichergestellt werden. Entscheidende Hilfsmittel sind dabei eine moderne, agile Softwareentwicklung und DevOps.
Bei einer klassischen Aufgabenaufteilung zwischen Entwicklung und Betrieb steht für die Entwickler die Software im Mittelpunkt. Zu den Zielen der Entwickler gehören Innovationen, neue Features, eine hohe Agilität und eine kurze Time-to-Market. Der Fokus des Betriebs hingegen liegt auf der Infrastruktur. Seine Ziele sind eine hohe Stabilität, Verfügbarkeit und Performance sowie eine maximale Standardisierung.
Die Intention von DevOps ist die Auflösung dieses traditionellen Zielkonflikts zwischen Entwicklung und Betrieb, das heißt die Überwindung der „Wall of Confusion“. Sie entsteht bei der funktionalen Trennung beim Verantwortungsübergang zwischen den beiden Geschäftseinheiten, also an dem Punkt, an dem die Verantwortung für eine Software von der Entwicklung in den Betrieb übergeben wird. Diese Trennung kann durch die Bildung von gemeinsamen, cross-funktionalen Teams aufgehoben werden.
Die agile Softwareentwicklung lebt von kleinen, handhabbaren Änderungen, die mit der Zeit zu einer großen Veränderung führen. Im agilen Ansatz ist die Veränderung der Normalfall. Das agile Team überprüft regelmäßig seine Praktiken und passt sie an, um effektiver zu werden, gemäß dem Prinzip „Inspect and Adapt“. Ein wichtiges agiles Instrument sind dabei Experimente. Bei der agilen Softwareentwicklung und DevOps haben sich im Laufe der Zeit in den Bereichen Product Owner, Story Parents, Feedbackschleifen und Kanban einige Best Practices herauskristallisiert.
Die Rolle des Product-Owners
Der Product Owner muss die Aufgaben im Product Backlog priorisieren. Das Product Backlog beschreibt in Form von Aufgaben und User Stories üblicherweise nicht nur die fachlichen und funktionalen Anforderungen, sondern auch die nicht-funktionalen Anforderungen, wie etwa die Qualitätsanforderungen.
Bei einem konsequenten Einsatz von DevOps kommen zu den Qualitätsanforderungen noch die operativen Anforderungen beziehungsweise Betriebsanforderungen in Form von meist technischen Aufgaben zur Verbesserung der Wartbarkeit und Betreibbarkeit der Software hinzu. Bei DevOps enthält das Product Backlog also somit einen größeren Anteil an technischen Aufgaben.
Product Owner haben jedoch einen natürlichen Hang zu neuen Features, das heißt zu den funktionalen Anforderungen. Dadurch besteht die Gefahr, dass die qualitativen und operativen Anforderungen zu wenig Beachtung finden. Außerdem fällt es Product-Ownern oft schwer, Kosten und Nutzen von technischen Themen wie Verfügbarkeit, Performanz oder Sicherheit abzuwägen – insbesondere dann, wenn sie selbst technisch weniger versiert sind. Deshalb ist für erfolgreiches DevOps die Unterstützung und Beratung des Product-Owners zu diesen Themen essenziell.
Erfahrungswerte zeigen, dass es sinnvoll ist, einen geringen Anteil des Budgets – etwa 15 Prozent – für kleine technische Verbesserungen zu reservieren. Für diese „Quick Wins“ ist dann keine Rücksprache mit dem Product Owner nötig, sofern ihre Umsetzung weniger als drei Arbeitstage in Anspruch nimmt. Mit diesem Vorgehen wird der Product Owner entlastet. Zudem wird damit dem Team ermöglicht, kontinuierlich an der Verbesserung der Qualität, der Betreibbarkeit und der Wartbarkeit der Software zu arbeiten.
Story Parents
„Story Parents“ beschreibt die Idee, jeder User Story einen „Parent“ zu geben. Dieser Story Parent übernimmt die inhaltliche Verantwortung für die User Story – von der Geburt der User Story im Product Backlog Refinement bis zur Volljährigkeit der User Story mit der Installation des Features in der Produktion. Der Story Parent hat die Aufgabe, Experte für das Thema seiner User Story zu werden.
Dies bedeutet jedoch nicht, dass der Story Parent die tatsächliche Implementierung der einzelnen Entwicklungsaufgaben der User Story übernehmen muss. Aber der Story Parent steht seinen Kollegen des Entwicklungsteams als Ansprechpartner für die User Story zur Verfügung. Dadurch wird auch der Product Owner entlastet.
Darüber hinaus stellt der Story Parent sicher, dass die User Story sinnvoll im Rahmen der Absicherung auf der Ende-zu-Ende-Umgebung getestet wird. Und er überprüft, dass das Feature in Produktion korrekt funktioniert. Das Konzept von Story Parents unterstützt somit das Denken in Vertikalen. Nicht zuletzt verstärkt es den DevOps-Gedanken, indem es den Story Parent in die Verantwortung nimmt, bis das Feature erfolgreich in Produktion ist.
Insbesondere für große Scrum-Teams – etwa ab sieben Personen – und große, komplexe Systemlandschaften, die von einem Scrum-Team betreut werden, hat sich das Konzept der Story Parents als echtes Erfolgsmodell bewährt. Es ermöglicht einen guten Trade-off zwischen der Vermeidung von Wissensinseln und der Team-Effektivität.
Feedback-Schleifen
Für erfolgreiches DevOps ist die Feedbackschleife aus dem produktiven Betrieb der Software von zentraler Bedeutung. Einerseits muss der Entwickler der User Story lernen, welche Konsequenzen die Entscheidungen haben, die er im Rahmen der Entwicklung trifft. Zudem muss er wissen, welche Herausforderungen im Betrieb auftreten und wie sie gelöst werden. Andererseits sollte er sein Verständnis über die innere Funktionsweise des Systems in die Fehlersuche und Fehlerbehebung mit einbringen.
Dadurch gewinnt der Entwickler ein besseres Verständnis über betreibbare und wartbare Software. Die Ergebnisse sind unter anderem ein zielgerichteteres Logging mit aufschlussreicheren Log-Nachrichten, ein besseres Monitoring, aussagekräftigere Health-Checks und sinnvolle Smoke-Tests. Bei erfolgreichem DevOps wird also die Wartbarkeit und die Betreibbarkeit eines Features bereits bei der Entwicklung der User Story berücksichtigt.
Kanban für Operations
Zum Aufgabengebiet von Operations gehören planbare Arbeiten. Beispiele sind ein anstehendes, großes Release, geplante Anpassungen der IT-Infrastruktur oder Systemaktualisierungen. Jedoch fallen im Operations-Bereich auch viele Tätigkeiten an, die inhärent ungeplant sind. Dazu gehören ein plötzlicher Lastanstieg, ein Systemausfall oder eine erkannte Sicherheitslücke, die ein sofortiges Handeln erfordern. Es bleibt dabei keine Zeit, diese Aufgaben in einem Product Backlog zu priorisieren oder erst im nächsten Sprint Planning einzuplanen. Aus diesem Grund wird für die Planung solcher Aufgaben vielfach nicht Scrum, sondern Kanban verwendet. Bei Kanban liegt der Fokus auf der Durchlaufzeit von Aufgaben und der Team-Produktivität.
Kanban macht Engpässe sichtbar. Ein solcher Engpass liegt etwa vor, wenn für einen bestimmten Prozessabschnitt aktuell nicht genug Ressourcen zur Verfügung stehen beziehungsweise die verfügbaren Ressourcen an zu vielen Dingen gleichzeitig arbeiten, also wenn das Work-In-Progress-Limit (WIP-Limit) überschritten wird. Kanban liefert eine hohe Transparenz über den Status des Projekts.
Zusätzlich ermöglicht Kanban eine sehr effiziente Zusammenarbeit im Team, insbesondere in Fällen, in denen Teammitglieder von unterschiedlichen Orten aus zusammenarbeiten. Oft wird Kanban zudem um ein Backlog mit den planbaren Aufgaben ergänzt; dieses „Kanban mit Backlog“ wird auch „Scrumban“ bezeichnet.
Insgesamt ist festzuhalten: DevOps hat die agile Softwareentwicklung grundlegend und bleibend verändert. Und der Siegeszug von DevOps hat Folgen: Der Product Owner muss sich nun auch mehr mit operativen Anforderungen auseinandersetzen. Dafür benötigt er Unterstützung und Beratung. Konzepte wie Story Parents können den Product Owner entlasten und den DevOps-Gedanken stärken.
Die Feedback-Schleife aus dem produktiven Betrieb und die Berücksichtigung gewonnener Erkenntnisse bei der Umsetzung der User Stories führen zu einer Software, die wartbarer, betreibbarer und letztlich besser ist. Mithilfe von Kanban können auch klassische Betriebsaufgaben agil organisiert werden.
Klar sollte sein, dass Agilität und DevOps keine Feinde sind, sondern gute Freunde. Beide haben das Ziel, durch eine Verbesserung der Kommunikation und schnelle Feedbackzyklen einen Mehrwert für das Business zu schaffen.
Dr. Christoph Ehlers ist Principal Software Engineer bei Consol.
