Continuous Feedback

Wer sich mit Continuous Delivery beschäftigt und die Einführung plant, wird schnell feststellen, dass es sich um ein Ziel handelt, dem teils kulturelle Veränderungen vorausgehen müssen. Wer dennoch schnell von Vorteilen profitieren möchte, muss CD anders angehen.

Das funktioniert auch bei uns

beladenEin wesentliches Wert agiler Softwareentwicklung ist die kompromisslose Fähigkeit, ständig an den Kunden zu liefern – oder zumindest potentiell liefern zu können. Continuous Delivery (CD) ist hierfür das Leitbild, das in den Unternehmen Einzug hält.

Wer sich intensiv mit Continuous Delivery auseinandersetzt wird schnell feststellen, dass es sich dabei um einen Arbeitstitel handelt. Eine klare vorgegebene Prozessanweisung, wie CD im konkreten Projekt für das konkrete Produkt umzusetzen sei, wird man vergeblich suchen müssen. Dafür sind Organisationen und Produkte – und vor allem deren Code-Basis – zu verschieden.

Doch so verschieden wie Menschen, Teams, Organisationen und Produkte sind, so unterschiedlich sind auch die Kunden der jeweiligen Produkte und Branchen. Viel zu oft stehen technische Machbarkeit und organisationsinterne Hürdenbewältigung im Zentrum aller Aufmerksamkeit.

Kunden und deren Erwartungen spielen für mich eine zentrale Rolle, wenn von CD die Rede ist. Bevor also Antworten zu Infrastruktur- und Prozessanpassung gesucht werden, müssen folgende drei Fragen beantwortet sein:

  • Wer sind unsere Kunden und wie profitieren sie von CD?
  • Wie nutzen unsere Kunden unser Produkt?
  • Wie tolerant sind sie gegenüber Mängel und Fehlfunktion?

Wer sind unsere Kunden?

kundenAuch wenn von Continuous Delivery die Organisation profitiert, Prozesse dadurch schlanker und Qualitätssicherung und Deployment auf ein Höchstmaß automatisiert werden, profitiert in erster Linie der Kunde davon. So soll es zumindest nach meinem Verständnis sein.

Wenn diese Aussage nicht getroffen werden kann, spreche ich höchstens von etwas, das ich als Automated Deployment bezeichnen möchte.

Der Kunde, zum einen der Auftraggeber, erhält schnelles Feedback über neue Anforderungen und Ideen – und das in der realen Produktionsumgebung. Der Kunde, zum anderen auch der Anwender, kann neue Funktionen in der alltäglichen Arbeit verwenden und wertvolles Feedback an die Hersteller zurückgeben.

Wer sind die Anwender? Endverbraucher, Ingenieure, eine Fachabteilung in einem Konzern, oder Jugendliche mit Smartphones? Wie es auch konkret aussieht, es muss bekannt sein, wer der Kunde ist und wie er von CD profitiert.

Wie nutzen Kunden unser Produkt?

nutzenWenn nun klar ist, wer das Produkt nutzt, kann die Frage nach dem Wie gestellt werden: wie wird es genutzt?

Handelt es sich konkret um eine Web-Anwendung, eine mobile App, eine vom Kunden manuell oder eine ab Werk installierte, native Software? Verwenden Anwender das Produkt bewusst, oder ist es eine Teilkomponente einer größeren Orchestration?

Wird die Software jeden Tag verwendet? 24/7 oder nine-to-five? Wird der Dienst on-demand genutzt? Hoch- oder nieder-frequentiert? Oder ist der Dienst ständig unter Last?

Antworten auf diese Fragen geben eine Idee, wie genau die Update-Strategie aussehen muss – und vor allem, welche Strategie dem Kunden zumutbar ist.

Toleranz gegenüber Mängel und Fehler?

erwartungContinuous Delivery geht so weit, dass nach jedem Push eines Entwicklers eine neue, auslieferbare Version des vollständigen Produkts gebaut wird – voll automatisiert. Dies suggeriert eine flächendeckende, vollumfängliche und automatisierte Qualitätssicherung. Um es mit anderen Worten zu sagen: automatisierte Tests.

In der Betrachtung eines Bestandsprodukts, dessen Code schon in die Jahre gekommen ist, ist eine hinreichende Testabdeckung schlicht nicht gegeben. Eine Nachrüstung lässt sich aber auch nicht von heute auf morgen bewerkstelligen.

Möchte man dennoch seine Kunden von CD profitieren lassen und, wie in diesem Fall, wissentlich ungetestete Versionen herausgeben, muss ein Verständnis über die Erwartungshaltung der Kunden vorhanden sein.

So unterscheidet sich die Erwartungshaltung eines Verbrauchers, der auf einem Web-Shop einkaufen geht, gänzlich von der eines Facharbeiters, der eine hoch sensible Industrieanlage betreut. Oder ein Endverbraucher, der sich eine App auf sein Smartphone lädt, 5 Sekunden ausprobiert und dann wieder löscht im Kontrast zu einem jahrelang treuem Bestandskunden, der viele Jahre das Produkt verwendet und eine gewisse Toleranz für Mängel entwickelt hat.

Die Kunden, deren Verhalten, Erwartungen und, vor allem, deren Akzeptanz gegenüber Mängel sind zentrale Komponenten in der Frage, wie konkret Continuous Delivery im Unternehmen aussehen muss.

Darauf kommt es an

ankommenZugegeben, die soeben getroffene Aussage von mir ist befremdlich, man solle wissentlich ungetestete Versionen herausgeben.

Es geht nicht darum, die bekannte Bananensoftware auszuliefern, die erst beim Kunden reift. Zum Ersten geht es darum, dass die Tatsache der fehlenden Testautomatisierung nicht zum Hindernis für CD wird. Zum Zweiten spreche ich über den Wert der Zusammenarbeit mit dem Kunden.

Durch die heutigen technischen Möglichkeiten und die Akzeptanz von Kunden, die Entwicklung zu unterstützen, bieten sich neue Modelle für verschiedene Produkttypen an. Intelligent umgesetzt ebnen sie den Weg zu Continuous Delivery, da die Hürde der vollkommenen Testautomatisierung (vorerst) in den Hintergrund gerät.

Continuous Feedback

feedbackWird die nicht vorhandene (oder teilweise vorhandene) Testautomatisierung zunächst als gegeben akzeptiert, geraten die ursprünglichen Vorteile von Continuous Delivery, für Hersteller und Kunde, zurück in den Fokus:

  • der Veredelungs-Prozess zum Release und das Deployment werden geübt und automatisiert
  • Kunden können sofort neue Features und Änderungen ausprobieren und Feedback geben

An dieser entscheidenen Stelle müssen nun Antworten auf die eingangs erwähnten drei Fragen vorliegen. Mit ihnen lassen sich Szenarien bauen, die dem Produkt und seinem Kundenstamm gerecht werden.

Im Folgenden möchte ich drei beispielhafte Überlegungen anführen. Diese Überlegungen sollen Anregungen geben, wie konkret CD aussehen kann:

  • Load-Balancing
  • Show-Rooms
  • Crowd- und Beta-Testing

Load-Balancing

balancingLoad-Balancing ist ein Mittel für hoch-frequentierte Websites. Anfragen von Kunden werden auf verschiedene, redundante Server verteilt, um Engpässe auf einzelnen Maschienen zu vermeiden. Im Umfeld einer Webanwendung, eines Online-Services, oder eines vom Endverbraucher tag-täglich genutzten Online-Shops kann sich CD die vorhandene Infrastruktur zu Nutze machen.

Das neu erzeugte Inkrement muss nicht sofort auf allen Serverinstanzen veröffentlicht werden. Wird es auf nur einem Server veröffentlicht, gelangt z.B. nur jeder 50. Besucher auf dem neuen (ungetesteten) Produkt.

Handelt es sich konkret um eine anspruchsvolle und flüchtige Kundschaft, leitet eine Fallback-Strategie den Kunden im Falle eines technischen (Programmier-) Fehlers auf einen anderen Server mit bewährter Version. Sauber protokolliert geben solche Umleitungen Aufschluss über die Qualität der neuen Version.

Ist Ihr Kundenstamm auf Ihr Produkt angewiesen und akzeptiert Abbrüche in der Konversation, ist die Auswertung der Conversion-Rate eine Möglichkeit. Sie besagt, wie viele Besucher zu einem Abschluss gekommen sind, also z.B. das Produkt im Shop gekauft haben. Eine auffällig niedrige Rate lässt vermuten, dass die Besucher das Geschäft nicht abwickeln konnten und es nicht gut im die Qualität des neuen Inkrements steht.

Show-Room

showroomNicht alle Produkte werden zentralisiert betrieben und erlauben ein kontrolliertes Update. Betrachten wir einen Industrie-Konzern, der Software auf Anlagen beim Kunden installiert. Das System ist darauf ausgelegt, die nächsten 5 bis 10 Jahre auf dieser Anlage zu verweilen.

Zum einen ist der externe Zugriff auf die Anlage nicht möglich: Updates können so nicht eingespielt werden. Zum anderen wäre die Erprobung eines neuen Features auf einer u.U. sensiblen Anlage auch mehr als riskant.

Ein Show-Room beim Hersteller ist eine geeignete Produktivumgebung und Ziel der Continuous Delivery. Der Show-Room ist nicht nur ein Marketing-Mittel um Kunden zu beeindrucken. Intelligent platziert bietet er spielerisch die Plattform neue Features zu erkunden. Product-Owner, Team-Mitglieder und Stakeholder anderer Abteilungen finden stets den Zugang zur aktuellen Version in einem realistisch nachempfundenen Einsatzszenario.

Sprint-Reviews finden im Show-Room statt. Die Spannung im Team vor dem Review wird gesenkt, könne es faktisch an jedem beliebigen Tag das Review durchführen. Und genau so soll es sein. Änderungen und neue Features können sofort mit dem Product-Owner abgesprochen werden – nicht am Rechner des Entwicklers, sondern am echten System.

Crowd- und Beta-Testing

crowdIm Segment der mobilen Apps gelten andere Herausforderungen. Nicht nur die verschiedenen Hardware-Ausführungen (CPU, Rechenleistung, Bildschirmauflösung), auch Parameter wie Internetfähigkeit, Bandbreite, Speicherplatz, GPS an/aus, etc. und deren Kombinationsmöglichkeiten bieten ein weites Spektrum an Fehlerquellen.

Zudem ist der App-Kunde sehr sensibel. Der Erstkäufer widmet sich nur wenigen Sekunden der neuen App. Versteht er sie nicht, oder kann er einen Fehler provozieren, ist die App schnell wieder gelöscht.

Meiner Erfahrung nach hat das Einbinden von Kunden in die Entwicklung sehr gut funktioniert. Durch die Nutzung von Beta-Testing-Diensten können User, dort registriert, aktualisierte Versionen der App beziehen und durch bekannte Kommentarfunktionen Feedback geben.

Änderungen und neue Features werden so nicht nur auf einer heterogenen Gerätelandschaft auf ihre Korrektheit hin überprüft. Kunden geben schnelles und ehrliches Feedback und Ideen für die Weiterentwicklung.

Entsprechend koordiniert kann dies die Qualitssicherung und auch die Innovationsfähigkeit stärken.

Continuous Improvement

imrpovementZum Schluss möchte ich betonen, dass es nicht das Ziel von Continuous Delivery ist, ungetestet Software in Produktion zu bringen. Die hier aufgeführten Ideen geben einen Anstoß, um die skizzierte Blockade zu lösen, man könne nur mit ausreichender Testautomatisierung kontinuierlich liefern.

Selbst bei einem noch so lückenlosen Testplan beweist Testen nur die Anwesenheit von Fehlern, jedoch nicht die vollständige Abwesenheit. In Produktivumgebungen und unter Verwendung nicht geschulter Anwender zeigt Software Fehler auf, an die unter Laborbedingungen niemand gedacht hat.

Einen auf Produktion gefunden Fehler gilt es mit einem automatisierten Test zu reproduzieren und dann zu beheben. Zum einen ist sichergestellt, dass der selbe Fehler nicht erneut auftreten kann. Zum anderen ist dies ein Schritt in die Richtung zu hinreichenden Testautomatisierung.

Continuous Delivery kann also schnell erreicht werden. Dennoch ist es als größeres Ziel zu verstehen, Schritt für Schritt und über die Zeit, Software bestmöglichst automatisiert auf die Produktionsumgebung zu bekommen, ohne dabei ein unsicheres Gefühl zu haben. Und auch hier bewährt sich, beim Kunden zu beginnen.

Quellenangaben
Sopon Phutthima/shutterstock.com
SUWIT NGAOKAEW/shutterstock.com
Jackiso/shutterstock.com
CedarchisCociredeF/shutterstock.com
Chantal de Bruijne/shutterstock.com
LoloStock/shutterstock.com
Anna Grigorjeva/shutterstock.com
Elena Efimova/shutterstock.com
CedarchisCociredeF/shutterstock.com
nanD_Phanuwat/shutterstock.com