Agil, aber trotzdem nicht wirklich agil? Was Pipeline Automation für Sie tun kann. Teil 1.

Unternehmen, die Agile einführen, und Teams, die Feature für Feature liefern und am Ende eines jeden Sprints einen geschäftlichen Wert schaffen. Wahrscheinlich ist das auch in Ihrem Unternehmen der Fall. Aber erreichen diese Funktionen Ihre Kunden tatsächlich im gleichen Tempo und generieren sie sofort geschäftlichen Nutzen? Und wenn wir schon dabei sind: Sind Sie in der Lage, das Feedback Ihrer Kunden tatsächlich zu nutzen und es im nächsten Sprint zu verwenden? Möglicherweise lautet Ihre Antwort "Nein", was ich sehr oft sehe. Viele Unternehmen haben die agile Arbeitsweise in ihren Geschäftsbereichen eingeführt, aber aus irgendeinem Grund scheinen die "alten Probleme" einfach nicht zu verschwinden... Daher die Frage:

"Schöpfen Sie die Vorteile der agilen Arbeitsweise voll aus?"

Eine unkomplizierte Software Delivery Pipeline Automation könnte Ihnen dabei helfen.

In diesem ersten von drei Beiträgen möchte ich Sie dazu anregen, darüber nachzudenken, wie die Automatisierung der Software Development Pipeline Ihrem Unternehmen helfen kann, voranzukommen und die nächsten Schritte auf dem Weg zu einem wirklich agilen Unternehmen zu gehen. Nicht nur ein Unternehmen, das agile Prinzipien anwendet, sondern ein Unternehmen, das wirklich in der Lage ist, auf das sich ständig verändernde Umfeld zu reagieren, das unser heutiger Markt darstellt. Um dies zu erklären, nehme ich das Agile Manifest als Ausgangspunkt und arbeite von dort aus.

Agiles Prinzip 1: Unsere oberste Priorität ist die Zufriedenheit des Kunden durch die frühzeitige und kontinuierliche Bereitstellung wertvoller Software. Dies ist das Hauptziel, das agile Teams anstreben. Am Ende eines jeden Sprints ein voll funktionsfähigesales Produkt zu liefern. Aber viel zu oft bleibt dieses Produkt irgendwo zwischen der Entwicklungsumgebung und den anschließenden Test-, Abnahme- und Produktionsumgebungen "stecken", so dass Sie Ihrem Product Owner und anderen Stakeholdern im Grunde nichts Neues vorführen können. Zu einem großen Teil, wenn nicht sogar zum größten Teil, geht es um die Kultur: streben (produktbasierte) Teams buchstäblich danach, qualitativ hochwertige funktionale Komponenten in einem möglichst kurzen Zeitrahmen zu produzieren? Wenn die Einstellung stimmt, haben Sie bereits einen weiten Weg zurückgelegt, aber oft arbeiten die Teams mit Werkzeugen, die nun ja, ähm ... etwas eigenwillig sind. Builds müssen manuell gestartet werden, Unit-Tests werden nur in einigen wenigen Bereichen durchgeführt und die Abdeckung bei funktionalen Tests ist wirklich gering. In vielen Fällen sehe ich, dass die Bereitstellung manuell von den leitenden technischen Entwicklern oder der Operations-Abteilung durchgeführt wird. Die Automatisierung jedes manuellen Schritts in der Pipeline, der automatisiert werden kann, ist hier der Schlüssel. Sei es die Automatisierung der Paketierung, die Automatisierung von Tests, die Automatisierung von Bereitstellungen oder die automatische Instanziierung neuer Infrastruktur. Wenn Sie Ihr Unternehmen zu einer produktzentrierten Umgebung umgestalten, Ihre Entwicklungsteams aufeinander abstimmen und jeden manuellen Schritt in Ihrem Softwareentwicklungsprozess, der automatisiert werden kann, automatisieren, werden Sie das erste Ziel des Agilen Manifests erreichen.

Agiles Prinzip 2: Begrüßen Sie geänderte Anforderungen, auch in der späten Entwicklungsphase. Agile Prozesse nutzen den Wandel für den Wettbewerbsvorteil des Kunden. Agile Teams sind bestrebt, so transparent wie möglich zu sein. Dies entspricht auch der Notwendigkeit, am Ende eines jeden Sprints ein voll funktionsfähiges Produkt zu liefern. Da die Software regelmäßig geliefert wird, können auch die Anforderungen jederzeit aktualisiert werden. Das beste Feedback, das sich ein Team wünschen kann, ist das Feedback der Kunden und nichts ist dynamischer als die Stimme des Kunden. Die Fähigkeit, mit dem sich ständig verändernden Umfeld umzugehen, erfordert eine andere Denkweise als die, die für die Arbeit mit starren Prozessen verwendet wird, mit denen einige Unternehmen heute noch arbeiten. Es erfordert eine Kultur des Vertrauens, der kontinuierlichen Verbesserung auf Organisations-, Produkt- und persönlicher Ebene und fördert das Experimentieren. Ein Unternehmen, das Konzepte der kontinuierlichen Lieferung einsetzt, konzentriert sich darauf, die Produkte gemeinsam mit dem Kunden zu gestalten, so dass ein Produkt entsteht, das den Kundenbedürfnissen optimal entspricht. Dies kann z.B. durch die Entwicklung eines Minimal Viable Product geschehen, das dem Kunden zugänglich gemacht wird, während das Benutzer- und Systemverhalten überwacht wird und das Feedback in das Endprodukt einfließt. Diese rückmeldungsgesteuerte Veränderung ist von Natur aus kontinuierlich und erfordert einen Grad an rigoroser Automatisierung, bei dem manuelle Eingriffe zur Bereitstellung eines neuen Produkts nicht mehr erwünscht sind.Um die sich ständig ändernden Anforderungen zu fördern, sollten Sie sicherstellen, dass Ihre Softwareentwicklungspipeline das richtige Maß an Flexibilität bietet, damit Ihr Team damit umgehen kann. Es ist von größter Wichtigkeit, dass Sie sofort reagieren können, und genau hier kommt die Automatisierung ins Spiel.

Agiles Prinzip 3: Liefern Sie häufig funktionierende Software aus, von ein paar Wochen bis zu ein paar Monaten, wobei der kürzere Zeitrahmen bevorzugt wird. Das Ziel eines agilen Teams ist es, häufig funktionierende Software zu liefern, um so einen sofortigen ROI auf Sprint-Basis zu erzielen. Agile Teams liefern am Ende eines jeden Sprints voll funktionsfähige Software, aber manchmal bleibt diese Software in den nachfolgenden Teilen des Softwareentwicklungsprozesses stecken. Solange die Software in der Pipeline feststeckt, in einer anderen Umgebung als der Produktionsumgebung, generiert sie keinen Wert. Wenn Sie einen möglichst kurzen Release-Zyklus anstreben, z.B. indem Sie Software mehrmals am Tag bereitstellen, können Sie dies nur erreichen, wenn Sie rigorose Automatisierung anwenden. Diese Themen werden in Bereichen wie Build-Automatisierung, Test-Automatisierung, Release-Automatisierung, Bereitstellungsautomatisierung und Automatisierung der Bereitstellung Ihrer Infrastruktur behandelt. Die Automatisierung jedes manuellen Schritts in Ihrem Softwarebereitstellungsprozess, der automatisiert werden kann, wird Ihnen helfen, das dritte Ziel des Agilen Manifests zu erreichen. Agiles Prinzip 4: Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten. Die Arbeit in durchgängig verantwortlichen multidisziplinären Teams ist ein wichtiger Aspekt von Agile. Menschen mit allen Arten von Wissen im Zusammenhang mit dem Endprodukt müssen in ein und demselben Team zusammenarbeiten. "You build it you run it" hören wir oft, und deshalb müssen wir sicherstellen, dass wir in Teams arbeiten, deren Ziel nicht nur die Bereitstellung neuer Funktionen ist, sondern auch der Betrieb des Produktsal aspects. Ein wichtiger, wenn nicht sogar der wichtigste Aspekt im Zusammenhang mit Continuous Delivery ist die Kultur. Wenn das Ziel darin besteht, die Zykluszeiten für die Produktlieferung auf ein absolutes Minimum zu reduzieren, ist es wahrscheinlich, dass Ihre Belegschaft anders organisiert werden muss als bisher. Das können Sie erreichen, indem Sie die Mitarbeiter zentral um (einen Teil) Ihres Produkts herum organisieren, d.h., indem Sie Vertreter des Geschäftsbereichs, der Entwickler und des operativen Bereichs in ein Team einbinden, in dem jedes Teammitglied explizit Fähigkeiten einbringen soll, die dem Produkt zugute kommen. Die Automatisierung kann zwar nicht viel zur Teambildung beitragen, aber sie kann Ihnen dabei helfen, Produktinformationen auf eine abstrakte Ebene zu bringen, die jeder versteht. Ein fehlgeschlagener Build (roter Bildschirm), ein fehlgeschlagener Test (roter Bildschirm mit eindeutigem Testnamen), eine fehlgeschlagene Bereitstellung (roter Bildschirm mit fehlgeschlagenem Komponentennamen), ein statistischer Bericht (6 / 10 erfolgreiche Bereitstellungen oder 'Spikes nach Bereitstellung von Version n des Produkts) können dem gesamten Team helfen, den Produktstatus zu verstehen. Und genau darum geht es bei der Teamarbeit: dass jede Disziplin innerhalb des Teams versteht, dass es nicht nur um ihren isolierten Teil geht, sondern um das gesamte Produkt des Teams.

Bleiben Sie dran für den nächsten Beitrag, in dem ich mich mit den agilen Prinzipien 5 bis 8 befassen werde.

Michiel Sens.