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.
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:
Quellen für die von uns gewählten agilen Ideen, Methoden und Ansätze waren hauptsächlich:
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.
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:
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.
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:
Um diese Probleme zu vermeiden, wurden zwei Ansätze gewählt: das tägliche Meeting und kontinuierliche Reviews.
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.
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.
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:
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.
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:
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.
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:
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.
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.