Wer jemals in den Alpen war, kennt das vermutlich: Gondelbahnen. Da gibt es die großen Kabinenbahnen, bei denen zwei große Gondeln jeweils parallel hoch und runter fahren und dabei oft 50 oder mehr Fahrgäste gleichzeitig auf den Berg transportieren. Oft sind es jedoch viele kleinere Gondeln, die dicht hintereinander weg fahren und jeweils 4-6 Fahrgäste nach oben oder unten chauffieren. Doch während der normale Skifahrer oder Wanderer darin einfach ein Transportmittel sieht, entdecken wir mehr: Eine wunderbare Veranschaulichung der Vorzüge von Continuous Delivery.
„Hä? Was bitte haben denn Seilbahnen mit agiler Softwareentwicklung zu tun?“ Natürlich benötigen auch Seilbahnen eine digitale Steuerungssoftware, aber das meinen wir hier nicht. Vielmehr zeigen Seilbahnen wunderbar den Prozessfluss auf, je nach Frequenz und Größe der ausgelieferten Pakete.
Nehmen wir zum Beispiel mal eine der großen Kabinenbahnen: Eine Gondel lädt im Tal die Fahrtgäste ein, zeitgleich wartet die zweite am Berg. Abfahrt ist vielleicht nur alle dreißig Minuten. Im besten Fall kommt man gerade rechtzeitig vor der nächsten Abfahrt, erwischt noch einen Platz in der Gondel und es kann los gehen – in den typischeren Fällen aber kommt man irgendwann dazwischen und wartet erst einmal, selbst wenn wenig Betrieb ist. Hat man dazu noch das Pech, dass direkt vor einem eine ganze Reisegruppe mit ihrem Bus angekommen ist, ist die nächste Gondel schon voll, bevor sie überhaupt angekommen ist, und man kann direkt eine weitere halbe Stunde Wartezeit drauf packen. Unschön, wenn oben der Schnee und die Sonne locken!
Hinzu kommt, dass es natürlich immer seine Zeit braucht, bis 50 Leute in eine Gondel ein- und wieder ausgestiegen sind. Bestimmt 5 Minuten vergehen also, in der die Gondel gar keine Passagiere transportiert – sondern einfach nur wartet. Verschenkte Zeit!
Und dann ist da noch der Pulk, in dem man sich unweigerlich befindet, wenn man denn endlich einmal an seinem Ziel angekommen ist. Anstatt sich entspannt auf die Piste zu schwingen, tummelt man sich zunächst einmal mit 49 anderen Menschen auf den Quadratmetern vor der Bergstation, bis man, schnell genug oder mit viel Geduld, ein wenig Platz für sich erobert.
Alles nicht so richtig geschmeidig. Aber genau so laufen klassische Releases ab, in denen gesammelt und gewartet wird, bis viele Features gemeinsam live gestellt werden.
Da haben die kleinen Gondeln, die viel kontinuierlicher liefern, klare Vorteile. Selbst wenn, wie oben, direkt vor mir die Busladung angerollt ist: Zwar sind, wenn die Bahn mit den kleinen Gondeln die gleiche Kapazität hätte wie die große, die nächste halbe Stunde alle Kleingondeln voll. Aber danach muss ich nur wenige Sekunden oder Minuten warten, bis ich einsteigen kann, und nicht eine halbe Stunde bis zur nächsten Abfahrt!
Zudem läuft das Ein- und Aussteigen quasi nebenbei: Die kleinen Gondeln verlangsamen ein wenig, man steigt hinein, und los geht’s – keine Wartezeit. Und am Zielort angekommen verteilt sich die Masse, wie sie sich auch über die Gondeln verteilt hat.
Und falls einmal irgendwo die Tür einer Gondel klemmt, muss nur diese eine kleine Kabine aus dem Verkehr gezogen werden, und nicht gleich die ganze Bahn!
Alles in allem also angenehmer, das ganze Szenario, flexibler und effizienter.
Nun ist Continuous Delivery* in der Software natürlich mehr als die Unterteilung in kleine Portionen und hat auch mehr Vorteile als nur den Abbau von Wartezeiten. Dennoch nennt eine aktuelle Studie der Software-Firma Perforce, „Continuous Delivery: The New Normal for Software Development“, die schnellere Lieferzeit als größten Vorteil: Wer kleinere Pakete schnürt, bringt viel früher die ersten Dinge auf die Straße. Oder im Business-Sprech: Minimierung der Time to Market-Zyklen.
Hinzu kommt eine bessere Qualität des Produktes. Der Grund dafür liegt, neben der notwendigen Automatisierung von Test- und Releaseschritten, vor allem in der besseren Überschaubarkeit der einzelnen Pakete. Oder ganz praktisch: Wenn es einen Bug gibt, kann man viel leichter nachvollziehen, wo dieser entstanden ist.
So wird im Continuous Delivery auch ein echter Marktvorteil gegenüber dem Wettbewerb gesehen: Höhere Qualität, schnellere Lieferung und vor allem die Möglichkeit, schnell auf neue Anforderungen (oder das neueste Killerfeature des Konkurrenten) zu reagieren.
So fasst ein Studienteilnehmer es wie folgt zusammen: „Releasing early and often so that the act of learning is accelerated, risk is identified, and you can react quicker.“ Klingt doch nach einem plausiblen und lohnenswerten Vorgehen!
Wer nun nach dem Lesen über Bergseilbahnen Lust auf’s Skifahren bekommen hat (wie zum Beispiel die Autorin selbst), dem können wir an dieser Stelle leider nicht weiterhelfen. Wer sich dagegen für Continuous Delivery, Testautomatisierung und Continuous Integration interessiert, der hat in Leanovate genau den richtigen Ansprechpartner - quasi den Gondelbauer der Softwareprozesse.
*Continuous Delivery bedeutet, sich von festen Release-Zeitpunkten zu lösen und zu beliebigen Zeiten – sobald etwas fertig ist – ausliefern zu können. Voraussetzung dafür ist eine weitgehende Automatisierung der Build-, Release- und Deployment-Prozesse, da manuelle Arbeit hohen Zeitaufwand und große Kosten verursacht, bei häufigen Releases eine noch so zeitaufwändige Automatisierung also auch finanziell lohnend ist.
Die Frequenz manueller Releases hat eine natürliche Grenze - nämlich genau die Zeit, die man für die manuellen Prozesse plus Kommunikation, Overhead und Wartezeiten benötigt. Durch Automatisierung steigt nicht nur die Geschwindigkeit, auch die Zuverlässigkeit erhöht sich drastisch und die Fehlerrate sinkt.
Wer mehr wissen will liest:
Jez Humble / David Farley: Continuous Delivery:
Reliable Software Releases Through Build, Test, and Deployment Automation
Rufen Sie uns an: 030 – 555 74 70 0
