Agiles Systems Engineering ist unmöglich. Oder?
Wer regelmäßig SE-Trends liest, der weiß, dass ich agiles Systems Engineering für machbar und sinnvoll halte. Aber in der Praxis ist agiles SE noch nicht sehr weit verbreitet, und ich zitiere immer wieder die selben Case Studies, wie SpaceX und WikiSpeed. Da stellt sich die Frage: Sind das die Ausnahmen, die die Regel bestätigen, oder Trendsetter?
Um ein besseres Verständnis zu bekommen, stelle ich in diesem Artikel die Ergebnisse von Ronald Carson vor (Boing), der agiles SE nicht für möglich hält. Dieses Paper wurde 2014 verfasst (laut Wiley). Allerdings steht auf dem Paper selbst „2011-2013.“ Dies als Kontext, um den Stand von agilem SE einzustufen, als das Paper verfasst wurde.
Ich würde mich sehr über eine Pro- und Contra-Diskussion im Kommentarbereich freuen.
Agilität nur für Software
Das Paper von Carson wurde vor sieben Jahren (2011) geschrieben. Zu dem Zeitpunkt waren agile Methoden in der Softwareentwicklung etabliert, und die ersten Versuche für den Einsatz im Systems Engineering waren unterwegs.
Um es vorweg zu nehmen: Eine zentrale These von Carson ist, dass Agilität nur in der Softwareentwicklung funktioniert. Dabei hat er einen wichtigen Unterschied zwischen Hardware und Software erkannt: Hardware wird klassisch iterativ gebaut und integriert. In der Softwareentwicklung finden diese Tätigkeiten kontinuierlich statt. Das Bauen passiert in Sekunden oder Minuten und wird in der Regel viele Male pro Tag durchgeführt.
Agilität hat seinen Platz – aber welchen?
Carson bestätigt, dass agile Entwicklung durchaus effektiv sein kann. Eines der Hauptergebnisse des Papers ist dementsprechend, zu klassifizieren, wann welcher Ansatz empfehlenswert ist.
Dazu zitiert er die folgende Tabelle aus der Wikipedia (für das Paper leicht abgewandelt):
| Suitability Factors | Agile | Plan-driven (Traditional SE) | Formal methods |
|---|---|---|---|
| Criticality | Low criticality | High criticality | Extreme criticality |
| Personell | Senior developers | Junior developers | Senior developers |
| Dynamism | Requirements change often | Requirements do not change often | Limited requirements, limited features see |
| Size | Small number of developers | Large number of developers | Requirements that can be modeled |
| Culture | Culture that thrives on chaos (In Wikipedia: „responds to change“) | Culture that demands order | Extreme quality |
Carlson entwickelt acht weitere Kriterien:
Sustainability Factors | Agile | Plan-driven (Traditional SE) | Formal Methods |
Program application | Internal or exploratory development | Contracted development | Contracted development |
Contracting approach | Time and materials | Fixed price or cost plus | Fixed price or cost plus |
Role of stakeholders | Full time on-site customer/user (Beckley and Mroczek 2003) | Up-front SE by customer/user; periodic validation; operational evaluation | Up-front SE by all stakeholders; periodic validation |
User need statements | Capabilities, user stories; may be incomplete | Conops, Requirements | Requirements |
Planning and analysis | Some planning, limited analysis | Extensive planning; some analysis | Extensive planning; model-based analysis |
Domain | Software | Systems, software, hardware, services, processes | Software and hardware |
Key managed risks | Time to market, user satisfaction; focus on deliverable software | Contract breach | Unexpected behavior |
Fabricator | Same as designer | Independent of designer | Code generation from formal language |
Gated development
Carson sieht das Konzept von „Gated Development“ als einen wichtigen Aspekt, den er in der agilen Entwicklung vermisst. Er gibt frei zu, dass dieses serielle Vorgehen zum Umsetzen von veralteten Anforderungen führen kann. Carson akzeptiert dies als notwendiges Übel, da er als praktizierte Alternativen entweder (a) Keine Anforderungen oder (b) schwammige Anforderungen sieht. Beide sind zu recht als schlechtere Alternativen einzustufen. An dieser Stelle ist es schade, dass Carson keine weiteren Alternativen untersucht, denn diese gibt es selbstverständlich!
Mangelnde Pflege von Anforderungen
Ein weiterer Kritikpunkt ist die mangelnde Pflege von Anforderungen beim agilen Vorgehen. Auch hier sieht er wieder Gating als Ansatz, dies zu verhindern. Im klassischen SE sieht Carson Prototyping, welches dann beim nächsten Gate sauber umgesetzt und dokumentiert wird. Carson argumentiert, dass in der agilen Entwicklung die Mechanismen fehlen, die für eine konsistente Systembeschreibung sorgen. Carson kritisiert hier zu Recht eine Reihe von Praktiken, die zu Problemen führen, zum Beispiel fehlende Verifikation, weil objektive Erfolgskriterien fehlen. Allerdings argumentiert er nicht überzeugend, warum diese Probleme in der agilen Entwicklung vermehrt auftreten, oder in der traditionellen Entwicklung abwesend sind.
Weitere Kritikpunkte
Carson kritisiert, dass „User Stories“ keine richtigen Anforderungen sind, dass die Eindeutigkeit fehlt. Aber auch hier gesteht Carson ein, dass es Techniken gibt, die hier für Präzision sorgen können, wie Test-Driven Development.
Weiterhin sieht er einen Interessenkonflikt darin, dass Designer und Coder in der agilen Entwicklung die selbe Person sind. Dieses Statement ist etwas überraschend: Das wir zwar oft so praktiziert, ist jedoch nirgendwo festgelegt.
Zuletzt kritisiert er das Fehlen eines „Dämpfers“ in der agilen Entwicklung, der dafür sorgt, dass in der Entwicklung eine klare Richtung eingeschlagen und beibehalten wird. Darin sieht er insbesondere einen Risikofaktor für Festpreisprojekte.
Meine Meinung: Agiles Systems Engineering ist die Zukunft
Ich hatte es ja bereits vorweggenommen: Ich teile nicht Carson’s Meinung und halte agiles SE sogar für zukunftsweisend. Doch wie erkläre ich mir dann die Einwände von Carson? Ich halte die Einwände von Carson für valide – aber die Einwände sind allgemein und haben wenig mit Agilität zu tun. Die angesprochenen Probleme sind real, tauchen aber auch mit anderen Entwicklungsmethoden auf. Und sie können auch leicht bei agilen Vorgehen unterbunden werden.
Die von Carson angesprochenen Probleme sind real, haben aber wenig mit Agilität zu tun
Twittern
Das klassische Beispiel ist Dokumentation. In der Vergangenheit bestand das Klischee, dass viele Entwicker „agil“ als Entschuldigung benutzten, um gar nicht zu dokumentieren. Das stimmt natürlich nicht: Das Agile Manifest sagt: „Funktionierende Software mehr als umfassende Dokumentation.“ Es sagt nicht aus, dass Dokumentation komplett weggelassen werden kann.
Ich würde sogar argumentieren, dass agiles Arbeiten das Risiko der angesprochenen Probleme häufig reduziert: Denn agiles Arbeiten ermöglicht es uns, frühzeitig Rückmeldung über den aktuelle Entwicklungsstand zu bekommen und frühzeitig einzugreifen, wenn die ersten Warnzeichen erscheinen. Das erfordert natürlich kompetentes Management, was aber ebenfalls nicht mit Agilität zu tun hat.
Fazit: Das Paper hätte besser „Fallen in der Systementwicklung“ heißen sollen. Die Problempunkte existieren. Wir haben aber inzwischen gelernt, mit diesen Problempunkten umzugehen: Und zwar sowohl in der klassischen Entwicklung, als auch im Agile Systems Engineering.
Photo by Vincent van Zalinge on Unsplash
