Den Anfang wagen

Ende der 1990er herrschten in der Softwareentwicklung Vorgehensmodelle wie das Wasserfallmodell vor. Als Gegenbewegung zu diesen als zu schwergewichtig, bürokratisch und ineffizient angesehenen Vorgehensmodellen entstand die agile Softwareentwicklung. Die darunter gefassten Entwicklungsprozesse gehen mehr auf die sozialen Probleme bei der Softwareentwicklung ein, sind leichter umzusetzen und flexibel anzupassen, und sie stellen den Wert des Produktes für den Kunden in den Vordergrund. Das „Agile Manifest“ formalisiert diese Vorstellungen und stellt bis heute den gemeinsamen Nenner für die verschiedenen agilen Vorgehensmodelle dar.

Nach einer Studie von Forrester Research aus 2010 gelten agile Methoden in der Softwareentwicklung mittlerweile als „Mainstream“. Für 35 % der befragten Teilnehmer sind sie ein wesentlicher Teil des Entwicklungsprozesses. Weitere 20 % setzen iterative Vorgehensweisen ein.

Allerdings ist die Bandbreite dessen, was Hersteller unter „agil“ verstehen, erschreckend groß, wie eine weitere Studie von Forrester Research aus 2011 belegt. Legt man strenge Kriterien an, herrschen nicht agile, sondern hybride Entwicklungsprozesse vor, in denen Vorgehensweisen aus beiden Welten kombiniert werden.

Die Anzahl der Hersteller, deren Entwicklungsprozess wirklich dem agilen Manifest genügt, scheint eher gering. Sie versuchen, durch agile Vorgehensweise nur konkrete Probleme im Projektmanagement, im Anforderungsmanagement, bei der Verzahnung von Entwicklung und Testen sowie beim Messen des Entwicklungsfortschritts zu lösen. Hybride Entwicklungsprozesse lösen die genannten Probleme zwar nicht grundsätzlich, aber sie lindern die Symptome.

Im regulierten Umfeld herrschen zusätzlich häufig Mißverständnisse darüber, ob und wie agile Vorgehensweisen umsetzen sind. Dabei finden sich weder in der IEC 62304 noch bei der FDA Vorgaben, die ein bestimmtes Vorgehensmodell fordern. Es wird lediglich eine Umsetzung der beschriebenen Aktivitäten und eine Erstellung der zugehörigen Ergebnisse gefordert. Für Hersteller scheinen auch diese Vorgaben in einem wasserfallartigen Vorgehen einfacher umsetzbar zu sein als in einem reinen agilen Prozess. Wenn ein agiler Entwicklungsprozess eingeführt werden soll, empfiehlt es sich daher, RA-Abteilungen und Benannte Stellen frühzeitig einzubeziehen, um deren Ängste auszuräumen. Der Mehraufwand rechnet sich allemal.

Wie sieht ein typischer hybrider Entwicklungsprozess nun aus, den Forrester als Water-Scrum-Fall bezeichnet? Die Entwicklung beginnt in diesem Fall mit der Erstellung von Nutzungsanforderungen, Systemanforderungen und einer Architektur, die erhoben, dokumentiert und freigegeben wird. In der Praxis sind der Wert und die Qualität dieser so erstellten Dokumente aber häufig gering, denn Nutzungsanforderungen werden nicht systematisch erhoben. Umfangreiche Änderungen bei den Anforderungen sind daher im Verlauf des Projektes zu erwarten. Weiterhin ist eine detaillierte funktionale Beschreibung des fertigen Produktes oder eine umfangreiche Architektur zu diesem Zeitpunkt nicht nützlich. Technische Entscheidungen sollen nicht möglichst früh, sondern so spät wie möglich erfolgen, damit die bis zu diesem Zeitraum erlangten Kenntnisse berücksichtigt werden können.

Anschließend beginnt die iterative Phase. Dadurch entstehen frühzeitig Teilergebnisse. Anforderungen und Architektur der Software lassen sich früher als bei einem reinen Wasserfallmodell beurteilen. Entwurfsfehler werden daher früher entdeckt, so dass eine Korrektur weniger Kosten verursacht. Die inkrementelle Entwicklung kann zudem für das Projektmanagement genutzt werden. Allerdings zeigen sich bei der Umsetzung dieser Strategie häufig Probleme, wenn das Entwicklungsteam nicht funktionsübergreifend besetzt ist und insbesondere die wichtigen Tester nicht im Team vertreten sind. Häufig arbeiten die Entwickler auch nicht als Team. Dem Management ist nach Einführung agiler Methoden oft nicht klar, dass das Entwicklungsteam selbstorganisiert arbeiten muss, um die Vorteile agiler Entwicklung zu nutzen.

Agile Entwicklung verlangt zudem nach neuen Rollen, die es vorher im Unternehmen nicht gegeben hat. Scrum, ein besonders populäres agiles Vorgehensmodell, fordert die Besetzung der Rollen „Scrum Master“ und „Product Owner“ und die Zuweisung spezifischer Rechte und Verantwortlichkeiten. Diese Rollen sind aber in einer Organisation, die diese Arbeitsweise gerade einführt, häufig nicht gelebt.

Sobald alle Anforderungen durch das Entwicklungsteam umgesetzt sind, wird der „agile“ Teil des Projektes beendet. Das Produkt ist an dieser Stelle typischerweise bereits zu einem gewissen Umfang getestet. Der Systemtest und der Abnahmetest erfolgen nun wieder innerhalb des Wasserfallmodells.

Für viele Hersteller von Medizinprodukten, die eigene Software entwickeln, erscheint solch ein hybrider Entwicklungsprozess geeignet. Er lässt sich mit vertretbarem Aufwand in eine klassische Projektorganisation einführen, und er löst die dringendsten Probleme in der Softwareentwicklung. Darüber hinaus lässt er sich auch gut mit den regulatorischen Vorgaben vereinbaren. Mit diesem ersten Einsatz agiler Praktiken ist ein Anfang gemacht, der erste Schritt zum agilen Unternehmen vollzogen. Dass er in den meisten Fällen den Vorgaben für eine „agile“ Entwicklung noch gar nicht entspricht, ergibt sich aus dem bisher Gesagten. Dennoch ist dieses Vorgehen nicht zwangsläufig schlecht. Wer Water-Scrum-Fall als Einstieg in eine agile Organisation nutzt, profitiert immerhin von einigen Vorteilen. Die Vorteile des iterativen und inkrementellen Vorgehens können konkret an dem Erfolg von eigenen Projekten belegt werden. Das zeigt, wie vorteilhaft diese Herangehensweise ist und dass sie im Unternehmen funktioniert. Damit ist nachgewiesen, dass der Fokus auf lauffähige Software nicht durch Nachteile, wie etwa fehlende oder unvollständige Dokumentation, erkauft werden muss. Auch die erfolgreiche Integration von Entwicklungs- und Testaktivitäten konnte nachwiesen werden.

Nach Abschluss eines solchen Entwicklungsprozesses ist klar, dass es sinnvoll ist, die Verantwortung für die Fertigstellung eines Produktinkrements in die Hände eines entsprechend besetzten Entwicklungsteams zu legen. Mit diesem Vorgehen kann also gezeigt werden, dass es möglich ist, agile Methoden bei der Entwicklung medizinischer Software einsetzen, wenn auch zunächst in eingeschränktem Umfang.

Bernhard Fischer Fischer Consulting, Bochum

Weitere Informationen Auf der jährlich stattfindenden Konferenz ScrumMed treffen sich Experten für agile Softwareentwicklung in der Medizintechnik, Anwender und andere Interessierte, um Erfahrungen auszutauschen. Die nächste Veranstaltung ist am 18. und 19.02.2013 in München geplant. Hier geht es um die Einführung agiler Methoden in der Medizintechnik, die Einhaltung gesetzlicher Richtlinien sowie um Qualitäts- und Risikomanagement. www.scrummed.de Über das Agile Manifest: www.agilemanifesto.org

Entwurfsfehler werden früher entdeckt