Ich frage mich manchmal, warum Agile Softwareentwicklung so selten “wirklich erfolgreich” praktiziert wird. Kann es sein, dass einfach unterschätzt wird, wieviel Fähigkeiten und Disziplin auf Seiten der Entwickler nötig ist? Gerade kam eine Erinnerung daran von Ron Jeffries, einem der Erstunterzeichner des Agilen Manifests:

The thing is this: programmers almost never learn in school the skills needed to build an Increment and keep it viable. The skills are not obvious. In fact they often seem to be quite wrong, given what we do learn in school. So it is critical – literally critical – to successful Agile, for developers to have these skills, which mostly they do not have.

They need time to learn and practice them. Those skills are not obvious, even to rather skilled programmers. Those skills are, I believe, literally unimaginable to non-programmers. (@RonJeffries auf Twitter am 12.4.2019)

“Build an Increment” ist das Entscheidende am agilen Entwicklungsprozess: Alle zwei Wochen (oder wie lang der Iterationszyklus auch ist) sollen die Entwickler eine etwas bessere Version der Software bauen (“an Increment”). Eine neue Version, die

• den Anwendern mehr Nutzen bringt als die vorige Version
• potenziell ausgeliefert werden kann. Das bedeutet natürlich auch, dass man ein Demo machen kann, dass Stakeholder über etwas Konkretes, Sichtbares diskutieren können usw.
• hohe innere Qualität hat, d.h. der Code ist gut strukturiert, die Architektur unterstützt die aktuell gelieferten Anforderungen, es gibt möglichst wenig bis gar keine technischen Schulden (technical debt)
• hohe äußere Qualität hat, d.h. möglichst keine bekannten Bugs.

Alle diese Bedingungen sind am Ende eines jeden Zyklus zu erfüllen. Also nicht: “Hier sind 5 neue Features, aber wir müssten irgendwann nochmal ein Refactoring machen.” Oder: “In dieser Iteration haben wir nur das Datenbankschema umgestellt, für etwas anderes war keine Zeit mehr.” Oder: “Drei von den neuen Features sind so fehlerbehaftet, dass wir sie nicht wirklich ausliefern können, aber schaut sie Euch schon mal an.”

Ahnen Sie, dass das ganz schön hohe Ansprüche sind?

Ich habe eine Theorie dazu, warum die technischen Fähigkeiten vernachlässigt werden, wenn man über Agilität redet. Die Verantwortlichen sehen nur den Vordergrund - funktionierende Software soll regelmäßig geliefert werden. Klingt gut, wer könnte was dagegen sagen? Dann sehen sie sich Scrum an, die Rollen (Product Owner, Scrum Master usw.) und die Zeremonien – was ist daran schwer? Was sie übersehen, und ohne technischen Hintergrund auch nicht einschätzen können, sind die technischen Praktiken, die die inkrementelle Lieferung von Software erst möglich machen.

Diese Praktiken werden bei Scrum bewusst ausgeklammert. Das sollte man dem Framework auch nicht vorwerfen, denn sinnvolle Vorschriften machen für die Prozesse um die Entwicklung herum ist schon schwer genug. Man kann auch argumentieren, dass es Organisationen leichter fällt, Scrum anzunehmen – eben weil es nicht vorschreibt, wie die eigentliche Programmierarbeit zu erledigen ist.

Wo steckt also die harte Arbeit bei der agilen Softwareenwicklung? Welche technischen Fähigkeiten braucht man, um erfolgreich zu werden? Was ist hier “leichter gesagt als getan”?

Ich greife mal eine Fähigkeit heraus: Unit Testing.

Unit tests (auch Microtests genannt) werden vom Programmierer für seinen eigenen Code geschrieben. Sie sichern, dass der Code das tut, was der Programmierer im Sinn hatte. Ein Beispiel: “Teste, dass Abhebungen von einem Konto das Überziehungslimit nicht überschreiten können.” Die Unit Tests werden sehr häufig ausgeführt, und zwar

1. Vom Programmierer nach jeder kleineren Änderung, um zu sehen ob das Ziel der Änderung erreicht wurde, und ob irgendwo anders etwas kaputt gegangen ist.
2. Ebenso vom Build-System (Continuous Integration), nachdem eine Änderung der gemeinsamen Code-Basis hinzugefügt wurde.

Im Beispiel der Abhebungen von einem Konto wäre ein Unit Test ein kleines Programm mit diesen Schritten:

1. Richte ein Konto ein mit einem Guthaben von 1000 Euro und einem Überziehungslimit von 2000 Euro.
2. Versuche, 4000 Euro abzuheben.
3. Prüfe, dass eine Fehlermeldung kommt “Überziehungslimit erreicht, sie können maximal 3000 Euro abheben.”
4. Prüfe, dass immer noch 1000 Euro auf dem Konto sind.

Sieht einfach aus – wer die Verwaltung eines Kontos programmieren kann, sollte auch so etwas zustande bringen, oder? Was an Unit Tests dennoch schwer ist, will ich morgen näher erläutern.

Matthias Berth