Agiles Engineering

Sowohl durch die Globalisierung als auch durch die Digitalisierung haben sich die Entwicklungs- und Angebotszyklen auf nahezu allen Märkten beschleunigt. Wie wettbewerbsfähig ein Unternehmen ist, entscheidet sich daher immer häufiger daran, wie rasch es sich auf die wechselnden Bedürfnisse von Kunden einstellen kann. Möglich wird das nur mit einer agilen Unternehmenskultur, die an die Stelle starrer Pläne und Strukturen tritt. Agilität ist dabei mehr als ein Modewort. Der Begriff stammt aus dem Lateinischen und bedeutet dort so viel wie "Beweglichkeit", "Schnelligkeit" beziehungsweise eine "Biegsamkeit des Charakters". Mittlerweile zieht sich der Begriff durch nahezu alle Unternehmensbereiche und reicht vom Management über die Entwicklung bis hin zu Produktion, Vertrieb und Service.

Agilität ist dabei nicht nur eine Methode, mit der Prozesse angegangen werden, sondern vielmehr ein Mindset. Der "Leitfaden zu agiler Arbeitsgestaltung" des Mittelstand 4.0 Kompetenzzentrums Usability definiert Agilität entsprechend als eine Medaille mit zwei Seiten "Agilität als Methode ('etwas agil machen') und Agilität als Mindset ('agil sein')." Ihren Ursprung findet die Agilität als Methode in der Softwareentwicklung. Dort wurden bereits in den 1990er Jahren agile Methoden angewandt. Seit der Jahrtausendwende erobert die Vorgehensweise mehr und mehr Bereiche und wird mittlerweile auch im Engineering angewandt.

Schrittweises Vorgehen statt Planwirtschaft

Agile Methoden zeichnen sich vor allem durch ihr iteratives, also schrittweises Vorgehen aus. Der Entwicklungsfortschritt wird dabei stetig an den Bedarf des Kunden angepasst. Statt auf ein Lastenheft und einen starren Plan zu setzen, wie es der traditionellen Herangehensweise an Projekte entspricht, begnügen sich agile Methoden erst einmal auf das Vereinbaren von Zielen. Wie diese Ziele zu erreichen sind, bleibt dabei bewusst offen. Die reine Entwurfsphase wird dadurch auf ein Mindestmaß reduziert. Das bedeutet in der Folge zugleich, dass der Kunde in den gesamten Entwicklungsprozess viel stärker involviert werden muss.

Während der Kunde in der traditionellen Vorgehensweise nach der Vereinbarung über ein Lastenheft erst einmal aus der Entwicklung herausgenommen ist, spielt er bei agilen Methoden eine wichtige und zumeist auch aktive Rolle. Häufig erhält der Kunde zu einem frühen Zeitpunkt der Entwicklung ein bereits zu nutzendes Produkt. Dieses sogenannte "minimum viable product" hat die Vollausbaustufe noch nicht erreicht, sondern stellt lediglich eine Produktvorstufe dar. Die noch enthaltenen Fehler sollen sich in der Praxis zeigen und fließen dann in die weitere Entwicklung des Produkts mit ein. Notwendige Veränderungen (in der Softwarebranche "patches" genannt) werden nach und nach durchgeführt, bis das Produkt fehlerfrei und nach den Wünschen der Kunden läuft. Dieser Prozess wird auch als "Patchen" bezeichnet.

Grenzen agiler Methoden im Engineering

Auch im industriellen Umfeld wird ein "Patchen" von Maschinen durchgeführt, übersteigt dort aber üblicherweise nicht ein begrenztes Maß an Erweiterung oder Änderung. Die Spanne reicht von der Re-Konfiguration einer Maschine, dem Bereitstellen neuer Funktionalitäten bei unveränderter Maschine bis hin zum "Retrofit" mit dem Ersatz von Teilkomponenten durch optimierte Austauschteile. Auch der Einsatz neuer Werkzeuge an den bestehenden standardisierten Schnittstellen ist üblich. Gängig sind zudem Aktualisierungen von Steuerungssoftware oder auch Änderungen der Firmware der Maschine, um neue Funktionen zur Verfügung zu stellen. In der Regel finden dabei vor allem Fehlerkorrekturen und eher geringfügige Anpassungen von Funktionen und Services statt. Die Anzahl der Retrofits von Maschinen, inklusive der Aktualisierung der Software, ist üblicherweise deutlich geringer als bei den "reinen" Softwaresystemen auf Unternehmens-, Betriebs- und Prozessleitebene.

Umgang mit Haftungsrisiken

Der wichtigste Grund dafür ist, dass das "Patchen" für viele Industrie- und Geschäftsanwendungen hohe Risiken birgt, die nicht toleriert werden können − zumal bei agilen Methoden auch das Lastenheft aufgegeben werden muss, das bisher im Geschäftskundengeschäft die verbindliche Vertragsbasis darstellt. Wie Haftungsfragen bei agilen Methoden im Engineering zu klären sind, wenn keine Abnahme wie bislang üblich erfolgt, wird gegenwärtig noch diskutiert.

Mit der Abnahme wird schließlich nicht nur bestätigt, dass das Produkt den vereinbarten Anforderungen entspricht, sondern beispielsweise auch wie lange das Produkt funktionieren soll, wann und in welchem Maß bei Ausfall Ersatz gestellt werden muss und vieles mehr. Die Abnahme ist damit letztlich die juristische Erklärung, dass eine Sache oder ein Zustand den im Lasten- beziehungsweise Pflichtenheft bestimmten Kriterien entspricht (§ 640 BGB). Beim agilen Engineering muss die Abnahme auf die iterative (schrittweise) Methodik angepasst werden. Das gelingt am besten durch eine Modularisierung: Die Abnahme des Produkts erfolgt dann jeweils entlang vorab festgelegter Module beziehungsweise Entwicklungsstufen.

Solange der Engineering-Prozess im Virtuellen verbleibt, sind die Unterschiede zwischen dem Engineering physischer Produkte und der Softwareentwicklung dagegen eher gering, sodass die meisten Prinzipien agilen Arbeitens angewendet werden können. Auch für die Software-Anteile eines physischen Produkts ist eine agile Entwicklung prinzipiell möglich. Ein gutes Beispiel sind die sogenannten digitalen Zwillinge, bei denen eine physische Anlage virtuell im digitalen Raum nachgebildet wird, um am Modell beispielsweise Planungen oder auch Überwachungen vornehmen zu können.

Besondere Anforderungen entstehen allerdings bei zulassungspflichtigen oder sicherheitskritischen Produkten – das gilt für die Software eines Flugzeuges genauso wie für sicherheitskritische physische Bauteile. Hier ist die geschlossene Beweisführung der Erfüllung der Funktion durch das Gesamtsystem aus Hardware und Software essenziell, nicht zuletzt vor dem Hintergrund der Haftung.

Ökonomische Hürden für agiles Engineering

Signifikante Unterschiede zwischen produktbezogenen und Software-Prozessen treten mit dem Beginn der physischen Realisierung des Entwurfs ein. Agile Methoden setzen auf die frühe und kontinuierliche Auslieferung von notfalls auch noch unfertiger Software. Für physische Produkte, insbesondere für Investitionsgüter und langlebige Konsumgüter, kann das frühe Angebot eines "minimum viable product" meist schon aus rein ökonomischen Gründen nicht unverändert übernommen werden.

Viele Produkte rechnen sich erst durch eine Groß- beziehungsweise Serienfertigung, für die das Produkt allerdings bereits voll ausgereift sein muss. Die Möglichkeiten der additiven Fertigung dürften dieses Problem zwar künftig deutlich entspannen. Dennoch bleibt es eine Herausforderung, eine fundierte Methodik für agiles Engineering zu erarbeiten.