Agil entwickelte Produkte in einem regulierten Umfeld

Fixe Idee oder erfüllbarer Kundenwunsch?

Von Softwareprodukten mancher Unternehmen geht bei einer Fehlfunktion ein gesundheitsgefährdendes oder gar lebensbedrohliches Risiko für Menschen aus. Da die Gesellschaft die Abwägung solcher Risiken nicht dem freien Markt überlassen möchte, müssen manche Branchen – allen voran Luft- und Raumfahrt oder auch Automobilentwicklung und Medizintechnik – behördliche Auflagen erfüllen. Auf den ersten Blick erscheint es unmöglich, ein Softwareprodukt für ein reguliertes Umfeld mit agilen Methoden zu entwickeln. Lohnt sich dennoch der Versuch?

Die Vorzüge agiler Entwicklung haben sich herumgesprochen. Viele Konzerne, in denen mit großer Personalstärke Softwareentwicklung betrieben wird, sind dabei, zumindest teilweise auf ein agiles Entwicklungsmodell – etwa Scrum und SAFe® – umzustellen.

Um die Hoffnungen nicht zu groß werden zu lassen, gleich vorab: Am oberen Ende der Risikoskala ist wenig Raum für agile Experimente – FAA und EASA fordern etwa die Einhaltung strenger Softwareentwicklungsprozessnormen. Und für Automotive-Branchenkenner ist auch nicht vorstellbar, dass beispielsweise bei der Entwicklung eines Notbremsassistenten auf die umfangreichen Dokumentations- und Review-Pflichten verzichtet wird, die den gesamten Entwicklungsprozess von der ersten Zeichnung bis zur Serienreife flankieren. Nicht ohne Grund halten agile Softwareentwicklungsmethoden in regulierten Branchen nur sehr gemächlich Einzug.

Das bedeutet, dass für die Übernahme eines agil entwickelten Produktes, welches gepflegt werden und unerwartet den höchsten regulatorischen Ansprüchen genügen muss, vielleicht nur die Neuentwicklung bleibt.

Allerdings führt auch nicht jedes Stück Software bei einer Fehlfunktion direkt zu einer lebensbedrohlichen Situation. Deshalb werden Produkte hinsichtlich ihres Risikos eingeordnet und die Auflagen zur Erreichung und Erhalt einer angemessenen Betriebssicherheit anhand der Klassifizierung bestimmt. Nur: Auch wenn die Auflagen bei geringerem Risiko entsprechend weniger fordernd ausfallen, scheinen sie mit einem typischen Inkrement – also dem Produkt einer agilen Entwicklung nach Scrum-Methoden – zunächst unvereinbar. So wird in klassischen Modellen der messbare, von einzelnen Mitarbeiter:innen unabhängige und in hoher Güte wiederholbare Projekterfolg maßgeblich durch Prozesse und Referenzmodelle erreicht – in GxP-regulierten Bereichen der Medizintechnik beispielsweise werden alle Arbeitsschritte durch Standard Operating Procedures (SOPs) vorgegeben. Das Agile Manifest hingegen gewichtet entgegengesetzt und priorisiert Individuen über Prozesse und lässt auf dem Weg zur Zielerreichung viele Freiheiten – eine Förderung des Projekt-Heldentums.

Auf den Dienstleister ausgelagert

Durch die auferlegten Einschränkungen neigen davon betroffene Unternehmen eher dazu, im eigenen Haus weiter klassisch zu entwickeln. Produkte, die für eine wirtschaftliche Entwicklung in klassischen Prozessen zu komplex sind und dennoch mit angemessenem Aufwand umgesetzt werden sollen, werden als Gewerk an einen bereits auditierten Zulieferer vergeben: Die Produktverantwortung ist damit abgegeben. Schon in erster Näherung wird jedoch nichts gewonnen, da der Lieferant prinzipiell ähnlichen Auflagen unterliegt, die für Gewerke typische Arbeitsweise gerade nicht agil ist, und Änderungsanforderungen entsprechend bestenfalls vierteljährlich umgesetzt werden.

Während auf dem Markt etablierte Standardware (commercial-off-the-shelf, COTS) auch im regulierten Umfeld relativ einfach eingeführt werden kann, ist die Verwendung von Softwareprodukten unbekannter Herkunft (software of unknown provenance, SOUP) mit sehr umfangreichen Prüfpflichten und Absicherungen verbunden.

Es gilt als Dienstleister also, dem Kunden durch kluges Vorgehen einen Projektrahmen anzubieten, der die Übernahme eines agil entwickelten Produkts in das regulierte Umfeld zumindest erleichtert und diese Übernahme mit überschaubarem Aufwand wiederholbar gestaltet – damit dem Kunden so ermöglicht wird, trotz des behördlichen Korsetts die wichtigsten Vorteile der Agilität für sich nutzbar zu machen: Die Prüfpflichten müssen vom Projekt so weit wie möglich übernommen oder erheblich begünstigt werden.

Schlüsselfaktor Nachvollziehbarkeit

Ein wesentlicher Aspekt klassischer Softwareentwicklung im regulierten Umfeld ist die bilateral traceability, also die eineindeutige Nachvollziehbarkeit aller Implementierungen und Änderungen, so dass Fragen nach Zusammenhängen („Welche Anforderungen liegen dieser Klasse und diesen Tests zugrunde?“, „Welche Testfälle wurden aufgrund dieser Anforderung geändert oder neu erzeugt?“, „Welches Risiko geht von dieser Funktion aus?“) jederzeit beantwortet werden können.

Agile Entwicklung an sich legt keinen großen Schwerpunkt auf detaillierte Nachvollziehbarkeit, aber mit einigen Maßnahmen lässt sich diese erreichen – und für viele Entwicklerteams gehören sie teilweise ohnehin zum guten Ton.

1. User Stories und „Definition of Ready“: die Latte höher legen

Nachverfolgbarkeit beginnt bei den Anforderungen. Mit Scrum treten User Stories an die Stelle einer Anforderungsspezifikation – mit dem Unterschied, dass sie zu Projektbeginn nicht vollständig vorliegen und im weiteren Projektverlauf durch andere User Stories angepasst oder außer Kraft gesetzt werden können. Und sie sind lediglich ein Gedankenanker: zwei Zeilen Text, deren Zweck es ist, dem Scrum-Team die Diskussion und Absprachen zu dieser User Story ins Gedächtnis zu rufen.

Die Lücke lässt sich mit einer Anpassung der Definition of Ready schließen. Die Definition of Ready (DoR) legt für ein Scrum-Team fest, welche Eigenschaften eine User Story haben muss, um umgesetzt werden zu können – hier gehört am Ende auch eine ungefähre (relative) Aufwandsabschätzung seitens des Entwicklerteams dazu. Dieser Abschätzung geht notwendigerweise eine Diskussion mit dem Product Owner und ggf. eine Designentscheidung voraus. Da diese Festlegungen (das „Wie“ der Umsetzung) für gewöhnlich nicht dokumentiert werden, bedarf es zweier Anpassungen:

• Die DoR muss festlegen, dass die besprochenen Designentscheidungen und Risikobewertungen zur User Story dokumentiert bzw. mit ihr verknüpft werden.
• Die DoR muss festlegen, dass die Akzeptanzkriterien so detailliert sind, dass sie an die Stelle einer Spezifikation treten können.

Beide Punkte sind zeitaufwändig und werden von Scrum-Teams folgerichtig nicht ohne zwingende Notwendigkeit etabliert und eingepreist. Da das Produkt ohne Dokumentation der Anforderungen und Entscheidungsprozesse aber weitgehend intransparent bleibt und später entsprechend wesentlich umfangreichere Prüfungen notwendig werden, kann die Notwendigkeit über die kommerziellen Rahmenbedingungen hergeleitet werden.

2. Werkzeugunterstützung: die Punkte verbinden

In stark regulierten Branchen ist es seit vielen Jahren üblich, dass Änderungen an Quelldateien Anforderungen zugeordnet sein müssen. Schon Subversion-Repositories konnten automatisiert sicherstellen, dass nur Beiträge übernommen wurden, wenn in deren Kommentar ein Ticket erwähnt wurde; dieses musste zudem zur Bearbeitung offen und dem beitragenden Teammitglied zugeordnet sein. Das lässt sich selbstverständlich auch mit Git-Repositories und ihren Verwandten umsetzen und ist auch in agilen Projekten verbreitet, denn die Vorgabe, dass zu jeglicher Änderung am Quelltext (genau) ein Ticket existieren muss, vereinfacht die Fehlersuche und wird oft auch von Entwicklungsteams gefordert.

Die Rückverfolgbarkeit muss aber auch zwingend alle qualitätssichernden Maßnahmen – also vorrangig Testfälle – mit einbeziehen:

• Testfälle müssen im gleichen Repository verwaltet werden wie alle Quelldateien. Dies betrifft ausdrücklich nicht nur vom implementierenden Teammitglied selbst geschriebene Unit-Tests, sondern auch die fachlich getriebenen Tests. Die Auswahl möglicher Testwerkzeuge wird damit eingeschränkt. Insbesondere fachlich getriebene Tests sollten zusätzlich auf Dateiebene möglichst granular vorliegen, wobei das Ideal – jeder Testfall wird in einer eigenen Datei gepflegt – kaum erreicht werden kann.
• Jegliche Änderungen zu einem Ticket – sei dieses User Story, Bugfix oder Technologieverbesserung – finden in einem genau diesem Ticket zugeordneten Feature-Branch statt. Dort werden auch alle Testfallanpassungen vorgenommen und erst dann integriert, wenn die Bearbeitung vollständig ist, d.h. auch alle Tests ergänzt oder angepasst wurden. Auch hier ist eine kluge Werkzeugwahl unerlässlich: Der Einsatz von Multibranch-Pipelines, mit deren Hilfe jeder Feature-Branch „on push“ einem Testzyklus unterworfen werden kann, trägt maßgeblich zum Erfolg dieser Strategie bei.

Dieses Vorgehen ermöglicht nicht nur eine gelingende Integration des Repositories mit digitalen Scrum Boards, sondern erlaubt auch das automatisierte Erstellen von Abhängigkeitsmatrizen, die z. B. darstellen, welche Testfälle von welcher Fehlerbehebung oder welcher User Story betroffen waren – insbesondere dem Umstand, dass User Stories durch andere User Stories veralten können, kann durch eine Darstellung von Abhängigkeiten Rechnung getragen werden.

Und das genügt?

Die Berücksichtigung dieser Punkte ist kein Garant dafür, dass Inkremente vom Auftraggeber in eine regulierte Umgebung überführt werden können, denn die behördlichen Auflagen sind international sehr verschieden und, wie eingangs erwähnt, je nach Klassifizierung überaus herausfordernd – und einige Methoden gilt es auch unter weniger fordernden Rahmenbedingungen zu etablieren: Hierzu gehört Grundsätzliches, wie das sorgfältige Beachten des Vier-Augen-Prinzips für alle relevanten Artefakte ebenso wie die Würdigung ungewöhnlicher Anpassungen der agilen Methode. Das Sprint Review beispielsweise, das bei einem Kunden/Lieferanten-Verhältnis zwischen Product Owner und den anderen Mitgliedern des Scrum-Teams ohnehin allzu leicht einer Abnahme gleicht, verändert sich in diesem Kontext noch deutlicher. Ein Kunde in dieser Rolle muss jetzt Sprints abnehmen und sein Team auch hinsichtlich der Einhaltung aller Festlegungen wie Mindesttestabdeckung und des Aufrechterhaltens der Nachvollziehbarkeit entlasten. Eine Überprüfbarkeit dieser Eigenschaften muss also gegeben sein.

Und selbstverständlich müssen deshalb nicht nur die Testfälle und Testdurchführungsprotokolle, sondern auch der Inhalt des digitalen Scrum-Boards (mit allen Anmerkungen und Verknüpfungen) archivierbar und Teil des Liefergegenstands sein, wenn das Board nicht ohnehin beim Kunden betrieben wird.

Diese Erörterung ist bei weitem nicht vollständig, und spätestens in konkreten Fällen werden wichtige Fragen noch individuellen Antworten harren. Der Weg zur Übernahme agil entwickelter Softwareprodukte in ein reguliertes Umfeld wird noch eine Weile einer Hindernisbahn gleichen – über den einen oder anderen Wassergraben führt jetzt aber immerhin eine stabile Brücke.