Agile Softwareentwicklung

« | 31 Jan 2019 | »

Nachdem ich neulich einem schönen Gespräch beiwohnen und es auch mitgestalten durfte, wo auch der Begriff SCRUM fiel, ist es an der Zeit das Gebiet der Agilen Softwareentwicklung mal aufzuschnüren.

Da mehr und mehr Softwareprojekte sich “SCRUM” auf die Brust schreiben, um sich vor der “klassischen Softwareentwicklung” abzuheben, stelle ich mir offen die Frage, wie viel nun an Konzepten im “neuen” Ansatz steckt, und was davon letztlich nur Buzzwords sind.

---

Offen gesagt frage ich mich nun, was eigentlich “klassische Softwareentwicklung” im Gegensatz zur “agilen Softwareentwicklung” eigentlich sein soll.
Denn vom Beginn meiner Karriere als freiberuflicher PHP -Entwickler ab dem Jahr 2000 bis zur heutigen C++ Systemprogrammierung kann ich mich an kein Projekt erinnern, bei welchem die “Agilen Leitsätze” verletzt worden wären.

Vielleicht gab es mal eine sprichwörtliche Softwareindustrie, wo Programme wie Kleidungsstücke bestellt, gefertigt und geliefert wurden, doch ich habe in solche Bereiche nie Einblick erhalten.

Bei der Umsetzung der agilen Prinzipien und Methoden hingegen erkenne ich eine Diskrepanz zwischen Theorie und Praxis.
Denn wie so oft in unserem Leben, hängt die Interpretation eines Grundsatzes häufig an der Auffassung und den Skills der Anwender.

Ich verfolgte etwa vor 10 Jahren das Thema “Extrem Programming” in einer aufgezeichnete Diskussion im Chaos Radio Express und empfand die Fokussierung auf die eigentliche Softwareentwicklung als hervorragend, kann aber mangels direkter praktischer Umsetzung die Praxistauglichkeit nicht belegen.

Zu SCRUM hatte ich bisher einen eher negativen Bezug, was aber vermutlich mit einer sehr unausgereiften Implementierung dieses Schemas in Verbindung steht, woran letztendlich alle dieses Projekte gescheitert sind bzw. abgebrochen wurden.

Und weitere agile Entwicklungsformen habe ich bisher weder in der Theorie noch in der Praxis ins Auge gefasst.

Doch meiner Erfahrung nach steckt hinter all dem ein zentraler Ansatz:

Das Ziel der agilen Entwicklung ist ein einzelnes Produkt, welches der Endkunde vorgibt.

Diese Idee “verkauft” sich perfekt an Entscheidungsträger, die am besten gleich morgen ein Produkt haben wollen, das es bereits gibt, und wo keine Neuentwicklung stattfinden soll.

Beispiel:

1. Anforderung Kunde: Erstellen Sie eine Taschenrechner-App
2. Entwicklung berät über die Technologie
3. Erstellung einer Sprint-basierter Roadmap
4. Stückweise Ausprogrammierung der Software
5. Rückkommunikation mit dem Kunden
6. Tests und Bugfixes
7. Finalisierung

Gerne wird auf das KISS- Prinzip verwiesen (Keep it simple, stupid).
Und das funktioniert bei der oben erwähnten Taschenrechner-App hervorragend.
Aber mal ehrlich … wozu sollte eine solche App heute noch entwickelt werden?

Interessant wird es also, wenn ein Projekt in die Länge geht, und neue Funktionen entwickelt und bestehende Codemodule erweitert werden müssen.

Hier bietet agile Entwicklung durchaus die Chance, unterstützend einzugreifen. Für mich persönlich war es nie notwendig einen formalen Termin zum Informationsaustausch festzusetzen, schließlich diskutiere ich gerne mit Kollegen und auch Endkunden über erreichte Ziele und Vorgehensweisen, doch für alle jene, die einen täglichen oder wöchentlichen Kommunikationstermin einplanen möchten (bzw. diesen nicht “automatisch” einplanen), bietet diese Vorgabe zusätzliche Sicherheit.

Allerdings bedarf es hier einer Grundvoraussetzung:
Das Entwickler-Team muss hierfür geschlossen auf einem adäquatem Level sein.

Ist dies nicht erfüllt, bewirkt der Formalismus der agilen Entwicklung entscheidende Rückschritte für das gesamte Projekt. Denn da es kein fixes Entwicklungsziel für Abschnitte hinweg gibt, korrigieren sich einzelne Sprints automatisch selbst immer weiter nach unten, der Feature Umfang wird stetig reduziert und der Arbeitsdurchsatz sinkt.

Es kommt das Prinzip “des schwächsten Glieds der Kette” zum Einsatz, und da Sprints immer ein (Kleinst-)Ergebnis haben, kann schnell und vor allem unbewusst der Fokus zum Projektabschlusses verloren gehen.

Das Projekt bleibt dann “verbal” und formal weiter “agil”, wird dann aber nach Monaten oder Jahren als immer noch nicht beendet angesehen und letztendlich abgedreht.
Parallel dazu wirken solche in die Länge gezogenen Prozesse bei progressiven Entwicklern kontraproduktiv auf die Motivation.

Ein solches beschriebenes negatives Szenario konnte ich leider mitverfolgen und habe daraus folgenden Schluss gezogen:

Agile Softwareentwicklung stellt Ideen und Ansätze bereit, die die Entwicklung, wenn sie bereits verkrustet ist, entrosten und optimieren können.
Doch es ist ein Fehler, ein SCRUM oder XP Buch zu kaufen und nach dem ersten Kapitel zu sagen: “Genau das machen wir.”

In fast allen Projekten, an denen ich in den letzten 15 Jahren beteiligt war, lag das größte Problem- und Konfliktfeld in der “freien Interpretation” der Ziele durch die Teammitglieder und weniger an falsch durchgeführten Methoden.
Weder SCRUM noch XP lösen dies sondern schwenken dann in den Modus: “Wir wissen nicht wo wir hinwollen, aber wir laufen einfach mal los.”

Von daher plädiere ich für eine ausgereifte Grundsatzplanung in einem Projekt, die Aufgabenteilung und Wissensvermittlung in den Mittelpunkt stellt und dessen Stabilität auf Erfahrung im jeweiligen Fachbereich basiert, und nicht nur auf verallgemeinerte agile Ratschläge vertraut.

Man kann nicht die Entwicklung der oben exemplarisch genannten Taschenrechner-App mit z.B der der Treiber Entwicklung in Betriebssystemen gleichsetzen und die gleichen “agilen” Prozesse daraus ableiten, wie auch die Apfelernte nicht mit jener von Getreide gleichgesetzt werden kann.

Dass “Refactoring”, “Kundeneinbeziehung”, “Iteration” und “Tests” zur Entwicklung gehören, ist für mich absolut keine Eigenschaft der “agilen Entwicklung”, die aktiv vorangetrieben und täglich angesprochen werden muss.
Im Gegenteil, es ist eine zwingende Voraussetzung für die Zusammenarbeit in einem Team und stellt eigentlich die “Aufnahmeprüfung” in ein solches dar.

Laufen solche Prozesse erst durch ein Abarbeiten einer SCRUM-Liste an, so möchte ich offen an der Qualität der Resultate zweifeln. … denn wie gesagt, dies ist eine Grundvoraussetzung für ein Expertenteam und alle müssen dies “im Blut” haben, genau so wie das “Vergessen des kleinen Einmaleins” zum automatischen Rücktritt eines Mathematikers führen sollte.

Fazit

Wenn ich vereinfachend SCRUM und XP vergleiche, so ist meiner Meinung nach:

• SCRUM für Projekt- und Zeitmanagement optimiert
• und XP etwas näher am Coding- und Entwicklungsprozess orientiert

Und deshalb gefällt mir XP natürlich besser. Und da ich wie erwähnt SCRUM-Projekte sterben sah, bin ich in diese Richtung heute skeptisch.

Ich hoffe, dass einige Ziele der “agile Entwicklung” sich vom aktuellen Buzzword-Status zu einer Selbstverständlichkeit entwickeln und nicht ständig eingemahnt werden müssen und somit Prozesse unnötig verzögern.

Wäre nämlich KISS als Grundsatz der agilen Entwicklung auf die Mathematik, die Medizin oder die Physik angewendet worden, hätte es seit 3000 Jahren keinen Fortschritt mehr gegeben.

Doch gerade als Entwickler von Bibliotheken möchte ich schon auch noch anmerken, dass es keine “einfachen Apps” und coole UIs gäbe, hätten sich die Macher von Betriebssystemen und Bibliotheken nicht dem höheren Ziel verschrieben, allgemeine Lösungen zu entwickeln, die langjährig und mit ausgereiften Konzepten arbeiten.

Betriebssysteme wie Kompressions- und Verschlüsselungsverfahren und viele OpenSource-Projekte wären durch das stumpfe Befolgen der Richtlinien von “agiler Entwicklung” entweder abgebrochen worden, oder hätten heute den Status von vor 10-15 Jahren.

Und als C++ Entwickler möchte ich hierbei an die Worte unseres großen Meisters erinnern, die er in einem Interview voller Stolz sagte:

C++ is also a library language!