Agilität in Großunternehmen, Teil 2

Agilität in Großunternehmen: Die Quadratur des Kreises?
Keine Kommentare

Um Software nicht nur schnell zu entwickeln, sondern auch schnell in Betrieb nehmen zu können, muss das agile Mindset in allen Unternehmensbereichen ankommen. Die Rahmenbedingungen müssen angepasst werden. Continuous Integration und Continuous Delivery sind hier gefragt.

Dies ist der zweite Teil des Artikels „Der Widerspenstigen Zähmung: Agilität in Großunternehmen“ von Volker Gruhn. Teil 1 finden Sie hier.


Damit Unternehmen agil entwickelte Software überhaupt in der Frequenz in Betrieb nehmen können, in der die Entwicklung sie veröffentlicht, müssen die Verantwortlichen nicht nur die Organisation, sondern auch die Systeme anpassen. Ziel ist es, sowohl die Software als auch die Entwicklungs-, Test- und Produktivumgebungen automatisiert zu produzieren und bereitzustellen. Ein solch hohes Maß an Automatisierung war bisher in vielen Organisationen nicht notwendig. Für Unternehmen, die nur wenige Releases pro Jahr veröffentlichen, hat sich der damit verbundene Aufwand nicht gerechnet. Ein weiteres Argument, das gegen einen höheren Automatisierungsgrad sprach: Wenn zwischen zwei Softwareupdates mehrere Monate liegen, verändert sich mit hoher Wahrscheinlichkeit die Struktur der Zielumgebung. Die Experten müssten den automatisierten Prozess also erneut überarbeitet, damit er zu den neuen Strukturen passt.

Continuous Integration und Continuous Delivery: Agilität ein System geben

Eher statische Rahmenbedingungen in der IT fördern also die „Handarbeit“. Diese personalintensiven Prozesse bringen einige Nachteile mit sich. Insbesondere sind sie stark von einzelnen Mitarbeitern abhängig. Unvorhergesehene Abwesenheiten, der Verlust von Kompetenzträgern oder unterschiedlich qualifizierte Fachleute sorgen für Probleme oder sogar für Prozessstillstand.

Wenn zwischen zwei Updates aber nicht mehrere Monate, sondern nur ein paar Tage oder sogar nur Stunden liegen, müssen die Verantwortlichen die IT-Betriebsprozesse grundlegend überdenken. Jetzt sind Installationsroutinen gefragt, die permanent prüfen, ob veränderte Software in Betrieb genommen werden kann. Diese Idee liegt Continuous Integration und Continuous Delivery zugrunde. Im Gegensatz zu den ersten Ansätzen der Automatisierung mit ihrem begrenzten Funktionsumfang bieten die aktuellen Lösungen inzwischen sehr vielfältige Möglichkeiten: von der Adressierung heterogener Infrastrukturen bis hin zum automatisierten Bereitstellen von Umgebungen und deren Integration in die vorhandene IT-Infrastruktur (Softwarelösungen wie Puppet oder Chef). Dazu gehören auch Tools für die Umsetzung von Monitoring- und Logging-Mechanismen, für das automatisierte Testen, für die Verwaltung von Softwarekomponenten (zum Beispiel mit der Lösung Nexus) und für das Orchestrieren des gesamten Prozesses (beispielsweise das Softwaresystem Jenkins).

Automatisierung beschleunigt die Prozesse in der IT nicht nur, sie erleichtert auch die Fehlersuche. Sie vermeidet die Probleme, die durch das unterschiedliche Konfigurieren von Entwicklungs-, Test- und Produktivumgebungen entstehen können. Diese Fehlerquelle kann das Team also ausschließen. Das Bereitstellen von Infrastruktur wird zu einem Prozess, der mit den gleichen Methoden und zum Teil sogar mit den gleichen Werkzeugen wie die Softwareentwicklung unterstützt werden kann. Beispiele dafür sind die Versionierung von Code für die Infrastruktur oder das Entwickeln von Design Patterns für bestimmte Infrastrukturaufgaben, wie das Aufsetzen eines Webservers.

Mit den bisher geschilderten Konzepten und Werkzeugen gelingt es Unternehmensentscheidern, in der eigenen Organisation den richtigen Ausgleich zwischen agilen und traditionellen Entwicklungskonzepten zu finden. Aber häufig stehen sie auch vor der Aufgabe, Dienstleister in agile Projekte einzubinden. Der nächste Abschnitt zeigt, wie das gelingen kann.

Budgets in agilen Projekten: die Quadratur des Kreises?

Agiles Denken reicht nicht nur über Abteilungs-, sondern auch über Unternehmensgrenzen hinaus. Denn setzen Unternehmen bei der Softwareentwicklung auf externe Kapazitäten, ist es unabdingbar, dass diese in gleicher Weise an der agilen Entwicklung schlanker Software interessiert sind. Agile Entwicklungsverfahren reduzieren zugunsten einer rasch einsetzbaren Software die Spezifikationen auf ein Minimum und passen sich flexibel an neue Erkenntnisse, neue Prioritäten und neue Anforderungen an. Damit bieten sie zwar die Chance auf besonders effiziente Projekte, bereiten aber den Einkaufs- und Controlling-Abteilungen Kopfzerbrechen: Wie sollen sie etwas budgetieren, das gar nicht genau spezifiziert ist? Wie sollen sie auf dieser Grundlage die Kosten für ein ganzes Softwareprojekt planen? Eine Berechnung nach Aufwand ist für die Auftraggeber äußerst problematisch, da die Kosten dabei theoretisch ins Unendliche steigen können. Auf einen Festpreis wiederum wird sich kaum ein Lieferant einlassen, denn dieses Modell funktioniert für ihn nur, wenn während des Projekts keine oder zumindest nur sehr wenige Änderungen erforderlich sind. Dieses Dilemma ist der Grund dafür, dass es in der Praxis de facto nur sehr selten zu echten agilen Softwareprojekten kommt. Diese gibt es fast nur bei internen Projekten, die ganz anderen Regeln unterliegen. Beauftragen die Verantwortlichen dagegen einen Dienstleister mit der Softwareentwicklung, sind Planungs- und Sicherheitsbedürfnisse der involvierten Parteien meist stärker als alle guten agilen Absichten.

Das Thema Budgetierung steht also der agilen Idee im Weg. Erst wenn es zur Zufriedenheit aller Beteiligten gelöst ist, kann sich die agile Idee weiter ausbreiten. Es klingt ein bisschen wie die Quadratur des Kreises. Gefragt sind intelligente Konzepte, die die unterschiedlichen Interessenlagen von Fach- und IT-Abteilungen des Auftraggebers und seines Lieferanten ausbalancieren. Einen Ansatz dafür bieten die so genannten „Shared pain/Shared gain“-Modelle. Die zentrale Idee dahinter ist, dass sich Auftraggeber und Dienstleister als Projektpartner die budgetären Risiken und Chancen der Agilität teilen.

BASTA! 2018

Elegante und performante WebAPIs und Webanwendungen (MVC & Razor Pages) mit ASP.NET Core 2.1?

mit Dr. Holger Schwichtenberg (IT-Visions.de / 5Minds IT-Solutions.de)

Machine Learning mit TensorFlow

mit Max Kleiner (kleiner kommunikation)

Ein Beispiel dafür ist das Vorgehensmodell „adVANTAGE“, das es erlaubt, komplette agile Projekte zu budgetieren und die Budgets zu kontrollieren. Dazu skizziert der Auftraggeber zunächst seine Erwartungen an die Software, indem er unter anderem ihren Zweck, ihr Einsatzgebiet und ihre Anwender beschreibt. Daraus abgeleitet werden dann in so genannten User Stories die zu entwickelnden Features definiert – unscharf, aber ausreichend, um den Aufwand und die Dauer ihrer Entwicklung schätzen zu können. Die Zusammenfassung aller Schätzungen ergibt ein vorläufiges grobes Gesamtbudget und umreißt einen Zeitrahmen. Sind alle Anforderungen geschätzt, muss der Auftraggeber sie priorisieren: Welche Stories sind unbedingt nötig, um live gehen zu können? Und welche lassen sich zur Laufzeit nachreichen?

Die so priorisierte Anforderungsliste bearbeitet der Dienstleister anschließend in Iterationen, den Sprints. Vor dem zweiten und jedem weiteren Sprint treffen sich Auftraggeber und Dienstleister und nehmen den letzten Sprint ab. Sie legen fest, welche User Stories in der nächsten Iteration umgesetzt werden sollen. Bringt der Auftraggeber dabei neue User Stories ein, so schätzt das Planungsteam den Aufwand dafür gemeinsam ein. Soll das Projektbudget dafür nicht erhöht werden, ersetzt die neue Story eine niedriger priorisierte mit gleichem Umfang. Den Streichkandidaten bestimmt dabei der Auftraggeber. Die Rahmenbedingungen wie Zielbudget, Zieltermin und Schätzung einzelner Features sind während des gesamten Projektverlaufs für alle Beteiligten transparent und dienen ihnen als Leitfaden. Kommt es zu Änderungen durch die Hinzunahme oder das Weglassen eines Features, werden diese Daten entsprechend angepasst.

Wie aber sollen die Partner mit Abweichungen vom ursprünglich geschätzten Budgetrahmen umgehen? Hierfür bauen sie in das Projekt einen „Unwissenheitskorridor“ ein; ein spezieller Mechanismus, mit dem sich Auftraggeber und Auftragnehmer das Risiko teilen, das mit den groben Schätzungen einhergeht. Wird die angesetzte Zeit überschritten, schlagen für die zusätzlich nötigen Tage deutlich geringere Sätze zu Buche. Diese sind für den Dienstleister gerade noch kostendeckend, lohnen sich aber nicht mehr wirklich. Mit diesem Konstrukt ist sichergestellt, dass Auftraggeber und Auftragnehmer gemeinsam gewinnen, wenn sie möglichst nahe am Budgetrahmen bleiben, und gemeinsam verlieren, wenn sie ihn überschreiten.

IT sitzt jetzt mit am Tisch

Die Ausführungen zeigen: Die Art und Weise, wie Unternehmen Software entwickeln, betreiben und nutzen, verändert sich im Augenblick grundlegend. Ideen, die noch vor wenigen Jahren hippen Start-ups vorbehalten waren, halten Einzug in etablierte Großunternehmen. Damit ändert sich nicht nur die Arbeitsweise von IT-Abteilungen, sondern auch die Bedeutung, die IT-Themen und damit der CIO innerhalb eines Unternehmens einnehmen.

Für junge Firmen mit vergleichsweise neuen Geschäftsmodellen ist IT häufig das zentrale Produktionsmittel. Im Gegensatz dazu wird in alteingesessenen und etablierten Unternehmen IT oft noch auf die Rolle des reinen Serviceerbringers beschränkt. Hier wissen die einzelnen Fachbereiche genau, was sie wollen. Sie sind es, die die Merkmale der Lösung festlegen. Die EDV-Experten müssen dann nur noch bauen oder beschaffen.

Dieses Serviceerbringermodell funktionierte auch mehr oder weniger gut. Zumindest solange es nicht erforderlich war, disruptive Innovationen auf der Basis von IT umzusetzen. Aber neue digitale Produkte, neue Vertriebswege, neu fragmentierte Geschäftsprozesse, neue Anforderungen der Kunden an das Tempo, in dem das Unternehmen Innovationen umsetzt, oder neue Formen der Kooperation mit Partnern erfordern genau das: IT-gestützte Innovationen, die etablierte Geschäftsmodelle ablösen oder zumindest ergänzen. Dann wird IT zum Business Enabler. Das bedeutet, dass IT-Abteilungen noch enger mit Fachbereichen zusammenarbeiten müssen, um das Potenzial von Technologien auszuschöpfen. Sie müssen sich in Märkte einarbeiten, um essenzielle Anforderungen zu verstehen und zu bewerten. Auf der anderen Seite sind Fachbereiche dazu aufgefordert, die Chancen neuer Technologien zu beurteilen.

Das gemütliche Modell der langsamen und kontinuierlichen Verbesserung von Produkten und Prozessen kommt immer mehr an seine Grenzen. Die Bereitstellung von IT muss flexibler und dynamischer werden. Damit wird der Einfluss des CIO und seines Teams immer weniger an der Tür zur IT-Abteilung aufhören. Denn die Technologien und die Infrastruktur, die die Experten bereitstellen, werden immer entscheidenderen Einfluss über Erfolg oder Misserfolg haben. Entsprechend wird sich die Rolle des CIO weiter ändern: vom reinen Erbringer zum Gestalter von Geschäftsprozessen.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -