Agile Softwareentwicklung

Agil ist ein Mode-Wort. Viele Firmen schreiben sich gross 'agil' auf die Flagge um modern zu wirken, sind es aber nicht wirklich. Um etwas Klarheit zu schaffen, holten wir einen Profi zu uns und führten einen Workshop durch. Hier sind die wichtigsten Infos und Highlights dazu:

Über den Referenten

Aus der Nachrichtentechnik stammend hat Michael Palotas bei mehreren Telekomunternehmen gearbeitet, unter anderem auch bei eBay.
Mittlerweile ist er CEO der Firma "Element34" und gibt viele Kurse rund ums Thema agile Softwareentwicklung.

Um was geht es bei der agilen Softwareentwicklung?

Wikipedia beschreibt die agile SW-Entwicklung folgendermassen: Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. 

Das klingt gut, aber wie können diese Punkte nun konkret von einem SW-Entwicklungsteam umgesetzt werden? Hier einige Beispiele:

• Kurzfristige definitive Entscheidung, welche Arbeitstasks in der nächsten Zeit durchgeführt werden
• Iterativer Prozess - ständiges Testen
• Ständiges Feedback über den aktuellen Stand durch den Kunden und das Team
• Transparentes Arbeiten - Das Team wird kontinuierlich über den eigenen Stand aufgeklärt

Häufige falsche Umsetzungen:

• Requirements werden nur ungenügend spezifiziert. z.B. wird nicht festgelegt, wann die Requirements als erfüllt angeschaut werden können - schliesslich ist man ja agil und macht sonst einfach einen neuen Task...
• Der Product Owner hat das Gefühl er müsse seine Ideen nicht komplett durchdenken - wegen ständigen Änderungen ist man ja schliesslich agil und kann diese jederzeit anpassen...
• Keine oder nur ungenügende Dokumentationen - in der agilen SW-Entwicklung muss man ja schliesslich nicht mehr dokumentieren...

Testpyramide

Insbesondere bei schnellen, häufigen oder sogar kontinuierlichen Veröffentlichungen (Continuous Delivery) ist umfassendes und schnelles Feedback unerlässlich. Hier können automatisierte Test einen grossen Teil der Arbeit übernehmen. Die Erstellung von solchen Tests ist jedoch nicht immer einfach. Insbesondere bei UI-Tests kann es vorkommen, dass eine kleinere Änderung an der Benutzeroberfläche eine ganze Reihe von Tests fehlschlagen lässt. Dies lässt die Frage aufkommen, ob der Programmierer tatsächlich einen Fehler eingebaut hat oder ob einfach die Tests überarbeitet werden müssen, was mit viel Arbeit verbunden sein kann. Dies kann soweit führen, dass UI-Änderungen nur widerwillig akzeptiert werden.
Mike Cohn hat ein Bild der Testpyramide entwickelt. Die Tests in der Spitze zeigen welche Tests lange zur Entwicklung und Ausführung brauchen und oft wenig Aufschluss über Programmfehler geben. Im Gegensatz dazu sind Unit-Tests zuunterst angeordnet. Sie sind schnell erstellt und geben sehr genaues Feedback zu funktional falschem Code.
Entsprechend sollte die unterste Ebene besonders stark ausgeprägt sein und die oberen Ebenen stellen nur noch die Interaktion der verschiedenen Komponenten sicher.

Continuous Integration

Continuous Integration (CI) bedeutet, dass alle Teammitglieder ihre Arbeit mindestens täglich in ein zentrales System einchecken. Dieses System bildet und testet die eingecheckte Software. CI behebt keine Fehler, macht es aber sehr viel einfacher sie zu finden. Nachdem die CI-Tasks durchgelaufen sind, folgen Continuous Delivery bzw. Continuous Deployment.

Continuous Delivery und Continuous Deployment

Continuous Delivery testet das Produkt vollständig, liefert es jedoch noch nicht auf die Produktivumgebung aus. Dieser Schritt passiert manuell.
Continuous Deployment liefert das vollständig getestete Produkt auch automatisch aus.

Graphic showing the difference between continuous delivery and continuous deployment
Source: https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff

Demo

Damit wir eine Vorstellung gewinnen können, wie das Ganze mit Continuous Delivery funktionieren kann, gibt es am Schluss noch eine Demo. Es handelt sich dabei um eine einfache Web-Anwendung, welche in Java geschrieben ist und mit git verwaltet wird. Als erster Schritt wird nun die aktuellste Version der Applikation aus git geladen und mittels Jenkins gebaut. Anschliessend werden die Unit-Tests angestossen.

In einem zweiten Schritt haben wir dann sehen können, wie die erfolgreich getesteten Artefakte aus dem ersten Prozess (in diesem Fall die JAR-Datei) gepackt und anschliessend auf einen Test-Server verschoben und dort installiert werden. Danach findet ein System-Test (hier mittels Test-Framework Selenium) auf dem Test-Server statt. Solche System-Tests beinhalten in vielen Fällen häufig genutzte Anwendungsfälle der Endkunden.
Nach erfolgreichem Abschluss der System-Tests auf dem Test-Server werden die Artefakte aus dem vorhergehenden Prozess schliesslich auf einen produktiv genutzten Server geladen. Auch hier laufen nochmals automatisch die System-Tests durch. Falls zu diesem Zeitpunkt ein Test fehlschlagen sollte, kann automatisch ein Rollback auf die vorherige Version stattfinden.

So zeigt uns diese Demo eindrücklich, dass man basierend auf eine solche Infrastruktur ziemlich schnell und sehr agil Software entwickeln und bis zum Endkunden ausrollen kann.

Links

Testpyramide: https://blog.namics.com/2012/06/tour-durch-die-testpyramide.html