Die Anforderungen in den Bereichen Safety und Medical sind hoch. Lassen sich die Entwicklungsmethoden V-Modell und SCRUM zusammenführen?
Andreas Schlaffer, Head of R&D Kontron Austria erläutert die Vor- und Nachteile beider Methoden. Darüber hinaus zeigt er auf, wie durch eine Kombination von beiden ein Projekt erfolgreich umgesetzt werden kann.
Das V-Modell stammt ursprünglich aus dem militärischen Entwicklungsbereich. Es wurde in der ersten Version bereits 1988 veröffentlicht und dann stetig weiterentwickelt. Seit Jahrzehnten ist dieses bewährte Modell Stand der Technik, obwohl es ein sehr starres Vorgehen, Planen, Entwickeln und Testen verlangt. Nach wie vor ist es die Basis und das empfohlene Vorgehensmodell bei beispielsweise folgenden Normen:
· IEC 60601-1 Allgemeine Anforderungen an die Sicherheit von medizinischen Geräten
· IEC 62301 Medizingeräte-Software
· IEC 61508 Funktionale Sicherheit
· IEC 13849 Sicherheit von Maschinen
· VDI 2206 Richtlinie
Charakteristisch für dieses Modell ist, dass der Ablauf des Projekts in einzelne, detaillierte Phasen gegliedert wird. Zu Beginn werden die allgemeinen System-Anforderungen analysiert und im Anschluss die funktionalen und nicht funktionalen Anforderungen an die Systemarchitektur definiert. Die Komponenten und Schnittstellen werden im Systementwurf geplant, im Anschluss folgt die Entwicklung und Implementierung. Zur Qualitätssicherung stehen Unit Tests, Integration Tests, die Systemintegration sowie die Abnahme und Validierung auf dem Programm. Hier sollte bedacht werden, was passiert, wenn ein Team stur nach Plan arbeitet? Das Team wird im Ergebnis immer nur das erreichen, was geplant wurde und nicht unbedingt das, was unter Umständen auch gebraucht wird.
Das agile Entwicklungsmodell SCRUM wurde im Februar 2001 in vier Leitsätzen als agiles Manifest formuliert. In den nachstehenden vier Bullet Points werden die erstgenannten Werte höher als die klassischen Werte gewichtet. (Quellenangabe: Manifesto for Agile Software Development agilemanifesto.org)
· Individuen und Interaktionen sind mehr als Prozesse und Werkzeuge
· Funktionierende Software ist mehr als nur eine umfassende Dokumentation
· Zusammenarbeit mit dem Kunden ist mehr als eine Vertragsverhandlung
· Reagieren auf Veränderung ist mehr als das Befolgen eines Plans
Der Ansatz beim SCRUM-Modell ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsmodelle zu komplex sind, um sie in einen vollumfänglichen Plan zu fassen. Der Lösungsansatz ist zu Beginn unklar und man vertraut auf Zwischenergebnisse, um die Unklarheiten zu beseitigen. Anhand dieser Ergebnisse erschließen sich fehlende Anforderungen und Lösungstechniken effizienter als in einer abstrakten Klärungsphase. Es wird eine Vision und kein detailliertes Lasten- und Pflichtenheft formuliert. Das Ziel ist, ein hochwertiges Produkt schnell und kostengünstig zu entwickeln. Dieses Modell zeichnet sich nur durch wenige Regeln aus: kurze Kommunikationswege, eine hohe Flexibilität durch adaptives Planen, Transparenz durch regelmäßige Meetings sowie eine zeitnahe Realisation neuer Produkteigenschaften beziehungsweise Inkremente. Als ein Nachteil kann der fehlende Überblick über die gesamte Projektstrecke sowie wenig konkrete Handlungsempfehlungen gesehen werden.
Wie sehen die Anforderungen an die Prozesse in den Bereichen Safety und Medical aus?
Vor der Durchführung des Projekts erfolgt die Planung der Aktivitäten. Der Detaillierungsgrad hängt vom Safety Anteil ab, Design Input vor Design Output. Ein stringentes Änderungs- und Change-Management steht bei Safety und Medical im Vordergrund, das heißt, der Zwang zur Dokumentation ist gegeben. Auf Grund der Normen sind immer wieder die Empfehlungen des V-Modells anzuwenden.
V-Modell und SCRUM in der Umsetzung
Wie lassen sich nun die Vorteile beider Entwicklungsmethoden vereinen? Das V-Modell XT erlaubt per Definition eine Anpassung (XT = extreme Tailoring), dieses Modell dient als Basis.
Nun wird SCRUM als spezielle Projektmanagement Methode innerhalb des V-Modells XT eingeführt. Die Anforderungen des Lastenhefts entsprechen dem SCRUM Produkt Backlog, dieser enthält nach und nach immer detailliertere Informationen.
Die Anwendung der SCRUM-Methode auf den unterschiedlichen Ebenen der Systementwicklung des V-Modells ist in den meisten Fällen kein Widerspruch. So lassen sich kurze Iterationen mit gleicher Länge umsetzen. Der agile Ansatz kann in jeder Phase des V-Modells angewendet werden, beispielsweise in der Systemarchitektur, der Validierung, den Integrationstests, den Hardwaredesigns etc. Kritisch zu betrachten sind die Iterationen bei der Hardware- und Mechanik- Entwicklung, da diese oft etwas längere Sprints erfordern. Hier ist speziell darauf zu achten, dass diese Sprints nicht zu lang werden. Die Aufgabenbeschreibung wie Dokumentation, Review, Testreport sowie weitere Kriterien fließen in die SCRUM-Definition für den Status „Done“ als Entscheidungskriterien ein.
Welche Erfahrungen ergeben sich aus dem Zusammenspiel beider Modelle?
Die Integration der SCRUM-Methode in das V-Modell ist in der Umsetzung nicht einfach, aber möglich. Es ist ein Lernprozess und bedarf mehrerer Iterationen. Insbesondere sind die folgenden Punkte wie zum Beispiel der Mind Change, die neue Art der Planung und die Disziplin bei der „Definition of Done“ sowie die Akzeptanz der Vorgehensweise als Herausforderungen zu sehen. Um ein Projekt mithilfe beider Modelle erfolgreich umzusetzen, sind Collaboration Tools sehr hilfreich. Wir haben gute Erfahrungen mit den Tools JIRA und Confluence gemacht.
Zusammenfassend sind nach unserem Erachten folgende Aspekte in der Phase der Umsetzung besonders wichtig:
· Das Team in der Umsetzungsphase mitnehmen und begleiten
· Disziplin bei der „Definition of Done“
· Kontrolle bei der „Definition of Done“
· Unterstützung bei der Umsetzung und Dokumentation mit den entsprechenden Tools
· Das Projekt des Umstieges zur SCRUM-Methode bereits agil zu gestalten
Fazit: Aus unserer Sicht lohnt sich die Verknüpfung der beiden Modelle. Es ist jedoch zu beachten, auch diese kombinierte Methode ist agil und muss immer wieder auf mögliche Anpassungen beziehungsweise Optimierungen überprüft werden.
{{comment.comment}}