Transparenz in Softwareentwicklungs-Projekten ist nicht nur für Projektmanager, Product Owner oder die Entwickler selbst wichtig, sondern für alle Stakeholder, die sicher sein wollen, dass ein Vorhaben in die richtige Richtung läuft. Für agiles Arbeiten mit Backlogs und Task-Boards stehen digitale Lösungen bereit, die auch das Zusammenarbeiten über große Distanzen unterstützen. Zu nennen sind hier beispielsweise Jira von Atlassian, Azure Devops Services von Microsoft oder Trello. Am Ende sind es aber nur am Rande die Tools für Kommunikation und Collaboration, die zum gewünschten Ergebnis führen.

Wichtiger sind die agilen Methoden und Frameworks wie Scrum beziehungsweise SAFe, die es ermöglichen, anhand von Sprints kurze Feedbackzyklen zu erreichen. Mit regelmäßig stattfindenden Events wie Sprint Review, Sprint Planning, Daily Sprint und Retrospektiven steht ein Werkzeugkasten für solche Feedbackzyklen bereit. Mit ihnen lässt sich das Ergebnis der geleisteten Arbeit kontinuierlich inspizieren und steuern.

Transparente Entwicklung: Voraussetzungen schaffen

Regelmäßige Reviews der Arbeitsfortschritte bieten die Voraussetzung, das Produkt inkrementell und iterativ entlang der Anforderungen von Stakeholdern zu entwickeln, Fehlentwicklungen frühzeitig zu erkennen, kontinuierlich zu lernen und sich zu verbessern. Damit möglichst schnell Feedback von späteren Nutzern und Kunden kommen kann, ist es empfehlenswert, Produktversionen frühzeitig auszuliefern, die einen Teilnutzen für das spätere Produkt liefern. Mindestens sollten aber die interessierten Parteien früh zur Nutzung und zur Feedback-Abgabe eingeladen werden. Die Idee solcher Minimal Viable Products (MVP) stammt aus dem Lean-Startup-Ansatz.

Agile Methoden wie Scrum und Extreme Programming liefern die Prozesse, um inkrementelle Entwicklung und kontinuierliche Verbesserung zu realisieren. Wie lässt sich nun ein Stand der Arbeiten erstellen, der von Stakeholdern inspiziert werden und so jederzeit für Transparenz in der Produktentwicklung sorgen kann? Tools und Verfahren dafür sollen im Folgenden beschrieben werden.

Um zu sehen, was Entwickler gerade schaffen, lohnt ein Blick dahin, wo die Developers das Ergebnis ihrer Arbeit - den Quellcode und andere Datei-Artefakte - speichern. Das wird eine Versionsverwaltung sein, in den meisten Fällen Git. Neben dem bloßen Speichern bieten dieses und andere Tools weitere wichtige Funktionen:

• Konfliktbehebung (Merging) für den Fall, dass mehrere Personen gleichzeitig Änderungen an Dateien speichern wollen;

• ein Protokoll, in dem gespeichert ist, wer wann was geändert hat. Damit lassen sich auch Änderungen wieder zurücknehmen, um ältere, aber funktionsfähige Stände wiederherzustellen;

• Code Reviews zur Sicherung der Codequalität;

• den Stand im zentralen Repository mit den Rechnern der Entwickler synchronisieren. Das bietet die Möglichkeit auch offline und an jedem beliebigen Ort zu arbeiten. Nach getaner Arbeit lassen sich die lokalen Änderungen in das zentrale Repository überführen.

Wichtig ist, dass die Entwickler regelmäßig ihre Arbeit mit dem zentralen Repository synchronisieren und mit den Änderungen der Kollegen zusammenführen. Regelmäßig soll heißen, mindestens einmal täglich. Das ist nicht nur nötig, um den Fortschritt und aktuellen Stand zu sehen, sondern auch um die Arbeiten der beteiligten Entwickler nicht zu weit auseinanderlaufen zu lassen. Die Folge wären langwierige Integrationsaufwände, die viel Zeit kosten und sich negativ auf Stabilität und Qualität der Software auswirken.

Damit wäre der erste Schritt geschafft: Es gibt einen zentralen Speicher, in dem alle Beteiligten, egal wo sie gerade arbeiten, ihre Ergebnisse regelmäßig ablegen. Hier kann auch überprüft werden, wer wann woran gearbeitet hat. Muss jetzt der Quellcode durchforstet werden, um zu sehen, ob sich die Arbeit in die richtige Richtung bewegt? Nein, zum Glück nicht. Das wäre auch wenig praktikabel. Besser ist es, den aktuellen Stand der Arbeit in Form funktionsfähiger Software zu überprüfen.

Softwareentwicklung: Continuous Delivery Pipeline und Tools

Dies wird mit dem Konzept einer Continuous Delivery Pipeline erreicht. Mit ihr lässt sich aus dem aktuellen Stand des Codes in der Versionsverwaltung der korrespondierende Stand der Software bauen und in der Zielumgebung installieren. Eine Zielumgebung kann je nach Art der Software ein Webserver oder ein App Store sein, von dem die App auf einem Smartphone installiert werden kann.

Mit der Continuos Delivery Pipeline wird im Idealfall auch die benötigte Infrastruktur an Servern, Netzwerkdiensten, Datenbank- und Webservern mitinstalliert. Dies geschieht mittels Skripten und Konfigurationsdateien. Infrastructure as code wird dieser Ansatz genannt. Skripte und Konfigurationsdateien dienen gleichzeitig als Dokumentation, weshalb Dokumentation und die daraus erstellten Systeme synchron sind. Eines der Werkzeuge, um Infrastrukturen in ihren Umgebungen zu installieren und zu konfigurieren, ist das quelloffene Infrastructure-as-Code-Tool Terraform. Es wird auch von den wichtigen Cloud-Providern unterstützt.

Dieses Vorgehen funktioniert am besten mit Cloud-basierter Infrastruktur (IaaS = Infrastructure as a Service), wie sie die großen Cloud-Provider zur Verfügung stellen. Aber auch für Infrastrukturen in klassischen Rechenzentren stehen diese Lösungen zu Verfügung. Eine besonders flexible und aktuell beliebte Lösung stellen Infrastrukturen auf Basis von Software-Containern dar. Wichtig ist, Installationsskripte und Konfigurationsdateien zusammen mit dem Quellcode in der Versionsverwaltung zu speichern. Dann sind Software und die zugrundeliegende Infrastruktur synchron.

Weil Continuous Delivery Pipelines für moderne und agile Softwareentwicklung eine so wichtige Rolle spielen, gibt es eine große Auswahl an Tools und Plattformen. GitHub, GitLab, Altassian BitBucket, Jenkins und Azure DevOps sind nur einige der bekannten. Installationen per Continuous Delivery Pipeline lassen sich manuell oder durch Ereignisse ausgelöst ausführen. Im Idealfall läuft der Installationsvorgang ohne weiteren menschlichen Eingriff ab. Zu Beginn muss die Pipeline einmalig aufgesetzt und danach an die laufende Entwicklung angepasst werden. In größeren, langlaufenden Produktentwicklungen lohnt sich dieser Aufwand.

Ideal ist es, wenn die Pipeline von Beginn der Entwicklung an implementiert wird. Überspitzt gesagt: Die erste Zeile Code, die entwickelt wird, sollte durch eine funktionierende Pipeline laufen. Dann ist man nicht nur tatsächlich von Beginn an über den Stand des Produkts informiert, es ist auch leichter und risikoärmer, diese Pipeline aufzubauen, weiterzuentwickeln und zu betreiben.

Softwareprodukte lassen sich meistens so entwickeln, dass schon früh funktionsfähige Produktversionen zu Verfügung stehen. Inkrementell und iterativ wird die Software Sprint für Sprint anhand von Anwender- und Kunden-Feedback weiterentwickelt. Wenn ein Entwicklerteam mitteilt, dass erst gegen Ende des Projekts etwas Sichtbares präsentiert werden kann, sollte das als Alarmsignal gewertet werden.

Softwareentwicklung: Wann ist das Projekt "fertig"?

Darüber, wann eine Software "fertig" ist, sollte zwischen Auftraggeber und den Entwicklern ein gemeinsames Verständnis bestehen. Was alles zu diesem Fertig gehört, wird in einer Definition of Done niedergelegt. Darin wird festgeschrieben, welche funktionalen, nichtfunktionalen und qualitativen Eigenschaften eine Funktion, ein Produktinkrement oder ein Release aufweisen muss, damit es als fertig und auslieferbar gilt. Wenn hier kein gemeinsames Verständnis besteht, kann das im Laufe des Projekts zu bösen Überraschungen führen. Hier hilft agiles Vorgehen mit kurzen Feedbackzyklen. Wenn früh und regelmäßig Produktstände ausgeliefert werden, lässt sich schnell erkennen, ob es noch Unstimmigkeiten gibt.

Muss die so gelieferte Software nun von Hand durchgetestet werden? Das wäre sicher zu aufwändig und ist auch nicht die lustvollste Beschäftigung. Es gibt eine Vielzahl von Lösungen, um das Testen der Anforderungen zu automatisieren. Das geschieht, indem die Tests programmiert oder so beschrieben werden, dass sie automatisiert ausgeführt werden können. Da dies eine wichtige Funktion ist, existieren hierzu unzählige Framework und Tools. Auf allen Ebenen und aus allen Perspektiven, lässt sich so das Testen automatisieren

Entsprechend werden die Tests in unterschiedliche Testarten und Typen für unterschiedliche Einsatzbereiche und Zielgruppen definiert. Zu den verschiedenen Testarten zählen funktionale Tests beziehungsweise Akzeptanztests. Sie sind interessant für Personen, die Software aus Benutzer- oder Kundensicht prüfen wollen sind. Möglich sind auch End-to-End-Tests, allerdings sind sie meist aufwändiger zu automatisieren.

Einen interessanten Ansatz liefert das Konzept des Behavior Driven Design (BDD). Mittels einer Beschreibersprache, zum Beispiel Gherkin für Cucumber, werden Anforderungen in einer für alle beteiligten verständlichen Sprache beschrieben und später als codierte Tests umgesetzt und ausgeführt.

Das erleichtert die gemeinsame Anforderungserstellung und Verifizierung der gewünschten Funktionalität durch Stakeholder oder Product Owner. Die Dokumentation der Anforderungen testet in diesem Fall die Anforderungen an die Software selbst. Anforderungsdokumentation und Tests sind synchron.

Softwareprüfung: Integrationstests, Dashboards und Reports

Ebenso gibt es Unit und Integrationstests: Sie prüfen die technische Funktionsfähigkeit von Software. Unit Tests konzentrieren sich auf die Funktionsfähigkeit des Codes ohne Berücksichtigung der abhängigen Systeme wie Datenbanken. Integrationstests testen die Software zusammen mit den umliegenden Systemen, mit denen sie später betrieben werden. Tests in diesem Bereich sagen eine Menge über die innere Qualität der Software aus. Interessant ist in diesem Zusammenhang der Wert der "Code Coverage". Er beschreibt, zu welchem Prozentsatz der Code durch Tests abgedeckt ist. Schließlich sind auch funktionale und Akzeptanztests wichtig, auch wenn sie nur die Spitze des Eisbergs im Blick haben.

Hinzu kommen nicht-funktionale Anforderungen wie Sicherheit, Performance und Skalierung. Hier werden die Qualitätsanforderungen an die Software geprüft. Auch für diese Testarten existieren Frameworks und Lösungen, wie zum Beispiel Apache JMeter. Diese Tests werden sinnvollerweise in die Continuous Delivery Pipeline integriert.

Die installierte Software wird so auch gleich automatisch getestet. So steht am Ende nicht nur der aktuelle Stand der Software zu Verfügung, sondern es wird auch die Frage beantwortet, ob die gewünschten funktionalen und nichtfunktionalen Merkmale erfüllt sind. Auf dieser Basis kann entschieden werden, ob die Software auf dem nächsten Staging Level, zum Beispiel User Acceptance Test (UAT), installiert wird. Dies lässt sich automatisiert sogar bis auf das Produktionslevel fortführen. Der Stand der Software wird automatisch bis auf die Produktion gebracht, wenn auf dem Weg dorthin die Qualitäts- und Funktionsanforderungen auf allen Staging-Umgebungen (Test, UAT, …) erfüllt werden.

Dieses Verfahren funktioniert auch in großen Umgebungen. Amazon zum Beispiel deployt alle paar Sekunden auf seine Produktivsysteme. Damit bei dieser Menge von Tests vor lauter Bäumen auch der Wald sichtbar bleibt, sollte das Ergebnis in benutzerfreundlicher und übersichtlicher Weise dargestellt werden.

Plattformen für Software Lifecycle Management und Continuous Delivery bieten Möglichkeiten, Ergebnisse und Status von Installation, Tests und anderen Aktivitäten in benutzerfreundlicher Weise darzustellen. So lässt sich auf einen Blick sehen, ob der aktuelle Arbeitsstand zu einem funktionierenden Produkt führt und funktionale wie nichtfunktionale Anforderungen erfüllt sind. Dabei bietet es sich an, einen Top-down-Ansatz zu wählen. Eine Übersicht dient dazu, schnell zu sehen wo ein Produkt steht. Aus dieser Übersicht kann in Detailansichten navigiert werden, bis hinunter zu einzelnen Tests und Codeänderungen. Entwickler und Systemadministratoren können so schnell Probleme und deren Ursachen finden.

Die Delivery Pipeline kann den aktuellen Stand der Software auch Nutzern und Kunden zur Verfügung stellen. Diese müssen nicht alles durchklicken; Tests werden automatisch ausgeführt und die Ergebnisse stehen übersichtlich zu Verfügung. Auf einen Blick sieht man wo das Produkt aktuell steht.

Es empfiehlt sich, noch ein weiteres Thema im Auge zu behalten, besonders wenn es sich um eine wichtige und kritische Anwendung handelt, die auch in Zukunft eine wichtige Rolle spielen soll: die innere Codequalität. Hier geht es um Themen wie Komplexität, Kopplung und Codezeilen pro Methode. Dieses Thema ist dann relevant, wenn der Programmcode auch in Zukunft wartbar, erweiterbar und modernisierbar bleiben soll - und das ohne unangemessenen Aufwand und Fehlerrisiken.

Auch hierfür gibt es Lösungen, wie zum Beispiel SonarQube, die den Code auf Qualitätsmerkmale testen, sich in die Delivery Pipeline einbinden lassen und im Extremfall verhindern, dass Code ausgeliefert wird, der nicht vorgegebenen Standards entspricht. Auch diese Tools bieten übersichtliche grafische Reports, die einen Überblick über Qualität und kritische Bereiche bieten.

Bei all den tollen Dashboards und Reports über Tests und Codequalität, die hoffentlich immer alles in Grün anzeigen, ist am Ende aber immer noch die produzierte Software selbst am wichtigsten. "Funktionierende Software vor Dokumentation" lautet einer der zentralen agilen Werte. Der Kunde zahlt nicht für eine Continuous Delivery Pipeline oder für Dashboards, die gute Testergebnisse anzeigen, sondern für ein Produkt, das seine Bedürfnisse erfüllt, sich gut bedienen lässt und ansprechend aussieht. Der Fokus sollte also immer auf der produzierten Software liegen. Es ist entscheidend, dass man dem Anwender, dem Kunden und sich selbst Software schnell und regelmäßig zu Verfügung stellt, kontinuierlich testet und Feedback gibt.

Transparentes Development: Worauf es ankommt

Wird das Richtige in der geforderten Qualität entwickelt? Dies früh festzustellen, spart viel Geld und hilft Termine einzuhalten. Dieser Beitrag soll nur einen Überblick geben. Vor allem für größere, langlaufende und wichtige Produktentwicklungen lohnt es sich, diesen zweifellos hohen Aufwand zu betreiben. Darauf kommt es dabei an:

• Ein Quellcodeverwaltungssystem wie Git, in das alle Beteiligten in kurzer Frequenz ihre Arbeit einchecken können und so auftretende Konflikte lösen (mergen). Automatisierte Codeanalysen und manuelle Code Reviews sorgen dafür, dass nur Code in das Produkt einfließt, der geforderten Qualitätskriterien entspricht.

• Eine Continuous Delivery Pipeline erstellt automatisch aus dem aktuellen Stand des Codes die aktuelle Produktversion. Diese wird den am Produkt interessierten Personen zu Verfügung gestellt. In der Pipeline werden auch Tests und Checks auf die Codequalität automatisch durchgeführt. Erfolg oder Misserfolg der Tests und der Codequalitätsprüfung können als Quality Gates dienen, ob diese Version der nächsten Staging Stufe zu Verfügung gestellt wird.

• Dashboards und Reports, die die Ergebnisse von Installation, Tests, Qualitätsmetriken und Bugs in übersichtlicher Weise darstellen, so dass man schnell über den Zustand der Software und dem Stand der Arbeit im Bilde ist.

• Working Software sorgt früh für ein auch subjektives, "Gefühl", ob die Entwicklung in die richtige Richtung geht. Minimal Viable Products (MVP) liefern früh Feedback von Kunden und Anwendern. Agile Praktiken sorgen für Feedback in kurzen Abständen. So lässt sich zukünftige Arbeit neu priorisieren und alle Aspekte des Projekts kontinuierlich verbessern. (hv/fm)