Umstellung auf agile Software-Entwicklung

Erfahrungen eines Medizinprodukte-Herstellers

Nach 25 Jahren Entwicklung von medizinischen Geräten und Software für die kardiologische Diagnostik und die ambulante Überwachung von Vitaldaten bei Risikopatienten, haben wir uns ein konsequentes und vollständiges Qualitätsmanagement für unser Unternehmen erarbeitet. Dieses beinhaltet einen strukturierten und dokumentierten Entwicklungsprozess für unsere Hard- und Software, der den regulatorischen Anforderungen wie DIN EN ISO 13485 oder DIN EN IEC 62304 gerecht wird. Mit dem stetigen Wachstum der Organisation und dem Bereich Forschung und Entwicklung, stieß dieser implementierte Prozess an seine Grenzen. So musste der Entwicklungsprozess verbessert werden, um Projekte effizienter durchführen zu können und die Entwicklungszyklen zu verkürzen. Inspiriert von Best Practices aus der Industrie, Erfahrungen, Konferenzen und Literatur entschieden wir uns, agile Entwicklungsprozesse zu untersuchen und zu bewerten.

Auswahl eines agilen Entwicklungsprozesses

Die Hauptprobleme bei der Wahl eines agilen Entwicklungsprozesses sind die regulatorischen Anforderungen einzuhalten und die notwendige technische Dokumentation. Klassische Entwicklungsprozesse wurden oft mit regulatorischen Anforderungen verknüpft und referenziert. Die meisten agilen Entwicklungsprozesse beziehen sich nicht auf regulatorische Anforderungen, insbesondere nicht auf regulatorische Anforderungen für Medizinproduktehersteller. Daher war es nicht möglich, eine strikte Implementierung eines agilen Entwicklungsprozesses zu wählen und es wurde die Entscheidung getroffen, die Methoden, Ideen und Ansätze aus verschiedenen agilen Prozessen an den Entwicklungsprozess der Organisation unter Berücksichtigung der regulatorischen Anforderungen anzupassen. Wir wählten also agile Prinzipien aus und passten sie an unseren Entwicklungsprozess an, mit der Auflage, sich an die relevanten Standards zu halten. Der neue Prozess wurde nicht auf die gesamte Organisation ausgerollt, sondern in unserer täglichen Arbeit in einem Pilotprojekt implementiert, das alle relevanten Aspekte eines typischen Entwicklungsprojekts in unserer Organisation abdeckt:

• Entwicklung von Hard-, Soft- und Firmware
• Mittlere Komplexität
• Breites Spektrum an beteiligten Abteilungen und Rollen

Quellen für die von uns gewählten agilen Ideen, Methoden und Ansätze waren hauptsächlich:

• Manifest für agile Softwareentwicklung
• Kanban – Evolutionäres Change Management für IT-Organisationen 
• Agile Testing – A Practical Guide for Testers and Agile Teams
• Implementing Lean Software Development – From Concept to Cash
• Basiswissen Medizinische Software – Aus und Weiterbildung zum Certified Professional for Medical Software
• The Scrum Guide

Bewährte Praktiken und Beschränkungen

Agile Entwicklungsprozesse haben zahlreiche Methoden und Best Practices, die genutzt werden können. Während der Implementierung und Verbesserung unseres neuen Prozesses haben wir einige dieser Praktiken identifiziert, die seit unserer Prozessumstellung den größten Nutzen für uns haben. Auf der anderen Seite gibt es einige Einschränkungen, vor allem durch die regulatorischen Anforderungen, die zu jeder Zeit berücksichtigt werden müssen.

Planung von kleinen Iterationen

Die größte Auswirkung auf unser Projektmanagement in Bezug auf die Steuerung des Projekts und auf die Effizienz des Entwicklungsteams, war die Aufteilung des Projekts in kleine Iterationen. Für das große Ganze und die Planung wurde ein klassischer Projektplan aufgesetzt. Für die operative Arbeit im Entwicklungsteam wird dieser Plan jedoch in kleine Iterationen (Sprints) aufgeteilt. Ein Sprint hat eine Dauer von 2 bis 4 Wochen und die geplanten Arbeiten müssen innerhalb dieses Sprints abgeschlossen werden.

Jede Iteration wird in einem separaten Planungsmeeting zu Beginn eines Sprints geplant, in dem der Product Owner (Produktmanager) seine hoch priorisierten Anforderungen erläutert und diese mit dem Entwicklungsteam (bestehend aus Entwickler und Tester) bespricht. So haben alle relevanten Rollen – der Product Owner, der Entwickler und der Tester – das gleiche Verständnis von den Anforderungen. Auf Basis dieser gleichen Sicht entscheidet das Entwicklungsteam, was es in diesem Sprint liefern kann. Einen Teil des Produkts abzuliefern bedeutet aber nicht nur, die Entwicklung abzuschließen. Es bedeutet auch, dass die folgenden Aufgaben in diesem Sprint erledigt werden:

• Entwurfsspezifikation und Überprüfung
• Unit– und Komponententests
• Refactoring von bestehenden Teilen
• Überprüfung der Quellen, Schaltpläne, etc.
• Integrations– und Systemtest
• Regressionstest der vorhandenen Teile

Dadurch wird sichergestellt, dass das Entwicklungsartefakt am Ende des Sprints nicht quick & dirty umgesetzt wird, sondern eine gesicherte Qualität und eine konsistente Dokumentation hat. Am Ende des Sprints werden die Ergebnisse vom Entwicklungsteam präsentiert und vom Product Owner überprüft, der sein Feedback direkt an das Team gibt. Es gibt viele Best Practices, wie man Planungsmeetings und Sprints organisiert und wie man die Arbeit für den kommenden Sprint schätzt. Die Erfahrung zeigt jedoch, dass es wichtiger ist, das Projekt so zu verändern, dass es mit diesen kleinen Iterationen arbeitet, als die Details der Planung und Schätzung. Die Methoden und Ansätze zur Organisation und Verwaltung der Iterationen können sich während des Projekts ändern und sollten an die Bedürfnisse des Entwicklungsteams angepasst werden. Der große Vorteil der Aufteilung der Arbeit in solche Iterationen ist die Möglichkeit, den Fortschritt öfter zu kontrollieren, die Entwicklungsergebnisse während des Projekts zu überprüfen und eine einheitliche Sichtweise auf die Anforderungen zwischen dem Entwicklungsteam und dem Product Owner zu erhalten.

Kommunikation und Zusammenarbeit

In den letzten Jahren der Entwicklung haben sich die Teammitglieder immer mehr auf “ihre” Arbeit fokussiert, was bei der Organisation zu zwei großen Problemen führt:

• Einige Codes, Schaltpläne usw. wurden nur von einem oder zwei Entwicklern verstanden und konnten nicht gewartet werden. Bei Problemen während Krankheit oder Urlaub war eine Analyse des Problems sehr schwierig.
• Die Entwickler verlieren sich manchmal in der Lösung ihrer Probleme, die vielleicht von anderen Entwicklern des Teams in kürzerer Zeit gelöst werden können. Dies verursacht einen großen Verlust an Effizienz.

Um diese Probleme zu vermeiden, wurden zwei Ansätze gewählt: das tägliche Meeting und kontinuierliche Reviews.

Daily meeting

In einem täglichen Meeting, zeitlich begrenzt z.B. auf 15 Minuten, erzählt jedes Teammitglied den anderen, was es seit dem letzten täglichen Meeting getan hat, was es bis zum nächsten Meeting tun wird und ob es irgendwelche Probleme gibt, die seine Arbeit blockieren. Mit dieser kurzen Besprechung, die vielleicht als Stand-up-Meeting am Morgen durchgeführt wird, weiß jedes Teammitglied, was im Projekt vor sich geht. Das reduziert das Risiko, dass ein Teammitglied sich in einem Problem verliert und Zeit mit dessen Lösung verschwendet, wo ein anderes Teammitglied es sehr schnell lösen kann. Es ist wichtig, dass dieses Meeting nicht als “Bericht an den Projektleiter” verstanden wird, sondern als Know-How-Transfer an die anderen Teammitglieder.

Kontinuierliche Überprüfungen

Ein Teil der für einen Sprint definierten “Definition of done” ist, dass alle Artefakte (Designdokumente, Source, Schemata, …) innerhalb des Sprints von mindestens einem weiteren Teammitglied überprüft werden. Je nach Komplexität und Risiko werden einige Dokumente formal, andere informell geprüft. Dies führt zu einer kontinuierlichen Qualitätsprüfung der Artefakte und zu einem breiten Wissen über die Artefakte im Team. Die Qualität der Artefakte unserer Entwicklungsteams steigt durch die Implementierung von kontinuierlichen Reviews deutlich an. Einige Entwickler sind auch einen Schritt weiter gegangen und haben mit Pair Programming begonnen, bei dem zwei Entwickler an einem Arbeitsplatz an einem Problem arbeiten.

Werkzeuge

Im Rahmen der Implementierung des neuen Prozesses evaluierten wir unsere bestehenden Tools zur Unterstützung unseres neuen Prozesses. Unsere Hauptregel war, dass wir zuerst einen Teil unseres Prozesses definieren wollen, wie er zu unseren Bedürfnissen passt, und dann entscheiden, welches Werkzeug uns unterstützen kann. Die Werkzeuge für die Entwicklung bleiben im Wesentlichen so, wie sie waren. Als Werkzeug für die Verwaltung unseres gesamten Entwicklungsprozesses haben wir uns für ein Application Lifecycle Management Tool entschieden: Polarion ALM. Polarion ist ein sehr generisches Tool mit der Möglichkeit, fast das gesamte Produkt anzupassen. Es basiert auf dem Versionskontrollsystem Subversion und arbeitet mit Work Items (z.B. Anforderung, Design, Testfall, Anomalie, etc.), die miteinander und mit anderen Artefakten wie Quellcode, etc. verknüpft werden können. Die wichtigsten Vorteile für uns waren:

• Nachvollziehbarkeit über Elemente: Wir sind in der Lage, den Implementierungspfad z.B. von einer Anforderung über das Design bis hin zu den Testfällen, den gefundenen Fehlern und dem entsprechenden Quellcode aufzuzeigen. So ist es möglich, eine einfache Auswirkungsanalyse durchzuführen, wenn sich ein Element ändert. Darüber hinaus ist diese Rückverfolgbarkeit ein wesentlicher Bestandteil der regulatorischen Anforderungen für Medizinproduktehersteller.
• Rückverfolgbarkeit über die Zeit: Da Polarion auf Subversion basiert, ist es möglich, zu einem Satz von Workitems zu einem bestimmten Zeitpunkt in der Vergangenheit zurückzukehren. So können Sie z.B. die Anforderungen so betrachten, wie sie in einem alten Release waren und die Änderungen vom alten Release zum aktuellen Stand der Entwicklung aufzeigen.
• Anpassung: Polarion gibt uns die Möglichkeit, das Tool an unsere Prozessanforderungen anzupassen. Es gibt eine Vielzahl von Vorlagen, APIs und Konfigurationen, die genutzt werden können, um einen Workflow zu entwerfen, der den Anforderungen entspricht.

Ein weiteres großes Problem war die Aufgabenverwaltung der Entwicklungsteams. Es wurden verschiedene Tools für die Aufgaben verwendet, z.B. Microsoft Outlook und Polarion, aber beide waren nicht für die schnelle Verfolgung, Änderung und Bearbeitung der Aufgaben geeignet. Dies führte dazu, dass die Entwickler die Tools nicht nutzten. Nach einigen Iterationen wurde ein wirklich leichtgewichtiges Tool gefunden, um die Aufgaben zu verwalten: ein einfaches Whiteboard mit Post-it-Notizen. Jede Notiz ist eine Aufgabe, die den Status offen, in Bearbeitung oder erledigt haben kann. Auf den Notizen werden auch die relevanten Elemente in Polarion (z.B. Defekte oder Anforderungen) referenziert. Das Whiteboard ist auch ideal für das tägliche Meeting, da es den aktuellen Stand der Iteration zeigt.

Motivation und Einstellung des Teams

Mehr als in klassischen Entwicklungsprojekten sind die Soft Skills der Teammitglieder und die Teammotivation entscheidend für den Erfolg des Projekts. Alle Teammitglieder müssen sich auf die neuen Methoden und Ansätze einlassen, um die Prozessverbesserung erfolgreich umsetzen zu können. Die Erfahrung unseres Entwicklungsteams zeigt, dass skeptische Teammitglieder meist den Nutzen z.B. der kleinen Iterationen nicht verstanden hatten. Das beste Argument ist die Präsentation im Review-Meeting, Iteration für Iteration. Die agilen Methoden enthalten oft ein lustiges Element, das die Teammitglieder motiviert. Einige Ideen, die uns inspiriert haben:

• Tägliches Stand-Up-Meeting außerhalb des Bürogebäudes
• Motivationskarten für Teammitglieder
• Bug-Hunting-Sitzungen
• Planungs- und Schätzungspoker
• Kleine Herausforderungen

Aber der ganze Wandel ist nicht nur ein Prozesswandel. Auch das Mindset und die Kultur der Organisation sind betroffen. Für ein Entwicklungsteam, das in einem klassischen Entwicklungsprozess arbeitet, ist das manchmal nicht einfach und kann nicht von einem Tag auf den anderen geschehen. Vor allem, wenn die Entwickler nur in ihrer Domäne arbeiten und die Interaktion mit dem Team gering ist. Es muss also jedem bewusst sein, dass die Umstellung Zeit braucht und die Effizienz anfangs sinken kann. In unseren Projekten waren 5 bis 7 Iterationen nötig, um produktiver und effizienter zu werden als vorher.

Regelung und Dokumentation

Eine Besonderheit bei der Entwicklung von Medizinprodukten ist die große Anzahl von Vorschriften, die erfüllt werden müssen. Möchte der Medizinproduktehersteller am weltweiten Markt teilnehmen, gibt es auch viele regionale Standards, die erfüllt werden müssen, um in diesen Ländern akkreditiert zu werden. Neben den Produktnormen gibt es Prozessnormen, die eine nachvollziehbare und lückenlose Dokumentation vom ersten bis zum letzten Schritt des Projektes erfordern. Ein weiterer Aspekt ist die Qualitäts- und Risikokontrolle. Ein medizinisches Gerät stellt hohe Anforderungen an die Sicherheit und Zuverlässigkeit, was ein breites Spektrum an Qualitätssicherung über das gesamte Projekt hinweg erfordert, von Reviews über statische Analysen bis hin zu dynamischen Tests.

Diese Anforderungen an Dokumentation, Qualitätssicherung und Risikokontrolle müssen bei jeder Iteration des Projekts Teil Ihres Prozesses sein. Als wir mit der Definition unseres neuen Entwicklungsprozesses begannen, sah es nach einem No-Go für diesen Übergang zu einem agilen Prozess aus. Aber unsere Erfahrung zeigt, dass diese regulatorischen Anforderungen auch in einem agilen Prozess erfüllt werden können. Für uns hat der agile Prozess in zwei Bereichen sogar Vorteile gegenüber dem klassischen Entwicklungsprozess:

• Dokumentation: Nach unserer Definition von “done” muss am Ende jeder Iteration auch die Dokumentation erledigt sein. Das bedeutet, dass die Dokumentation (z.B. Anforderungen, Designspezifikation, Testfälle, etc.) konsistent zu den Entwicklungsartefakten sein muss und innerhalb eines Sprints überprüft werden muss. Dies führt zu einer durchgängigen, konsistenten und qualitätsgeprüften Dokumentation am Ende einer jeden Iteration.
• Testautomatisierung: Genau wie die Dokumentation wächst auch die Testautomatisierung mit jeder Iteration. Sie wird laufend angepasst.

In beiden Fällen zeigt unsere Erfahrung, dass innerhalb weniger Iterationen nicht nur der Tester das Ziel verfolgt, die Dokumentations- und Testaufgaben in einer Iteration abzuschließen, sondern das gesamte Team beginnt, intensiv an der Dokumentation und Testautomatisierung zu arbeiten. Zusätzlich kommt ein Mitarbeiter aus dem Qualitätsmanagement in das agile Entwicklungsteam, um diese Aktivitäten zu unterstützen.

Fazit

Zusammenfassend hat der Übergang zu einem agilen Entwicklungsprozess für uns als Medizinproduktehersteller funktioniert. Die regulatorischen Anforderungen erfordern es, bei der Umstellung des Prozesses über jeden Schritt nachzudenken, vor allem weil die agilen Methoden und Ansätze nicht den Fokus auf Dokumentation und Regulierung legen, wie es im medizinischen Bereich notwendig ist. Es muss also ein angepasster agiler Prozess eingesetzt werden. Die Methoden, Ideen und Ansätze, die in der agilen Entwicklung etabliert sind, können genutzt werden, um den bestehenden Entwicklungsprozess zu verbessern. Dies führt zu einem standardkonformen und effizienteren Entwicklungsprozess, der nun in zwei großen Projekten zur Entwicklung medizinischer Hard- und Software angewendet wird.