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

Dieser Artikel erschien zuerst bei se-trends.de.