Share ZU:
15 April 2014 @ Andreas Becker

Der NORMator – Maschine oder Erlöser im agil regulierten Umfeld?

Agile Entwicklungsmethoden gewinnen stark an Bedeutung und lösen zunehmend phasen- und dokumentengetriebene Vorgehensweisen ab. Bei einer erfolgreichen Einführung überwiegen die Vorteile durch direkte Kommunikation und durch das Integrieren des Experimentierens und des unmittelbaren Feedbacks aus gemachten Erfahrungen sowie das Aufteilen von komplexen Problemstellungen in kleine, gut handhabbare Schritte, um das Risiko einer Fehlentwicklung zu minimieren. Aber wie können in einem regulierten Entwicklungsumfeld diese Vorteile genutzt werden, da eine agile Entwicklung mit diversen Normen und Regularien nicht vereinbar zu sein scheint?

Dies kann ein Fall für den NORMator sein.

Der NORMator ist weder eine Maschine noch ein Erlöser, sondern lediglich jemand, der das Know-how mitbringt, um im agil regulierten Umfeld die notwendigen Aufgaben zu übernehmen oder bei deren Durchführung zu unterstützen.

Reguliertes Umfeld
Von den Vorteilen der agilen Entwicklung möchten auch Unternehmen aus regulierten Umfeldern profitieren. Hier herrscht aber in vielen Fällen noch große Verunsicherung und die Vorstellung, dass agile Entwicklungsframeworks (z.B. Scrum) und die Randbedingungen des regulierten Umfelds nicht miteinander vereinbar sind. Zum einen geht man davon aus, dass die Anwendung des V-Modells verbindlich vorgeschrieben sei und eine vollständige Spezifikation und Dokumentation, wie sie in dokumentengetriebenen Vorgehensweisen vorkommen, einen agilen Ansatz unmöglich machen – beides sind Fehlinterpretationen, die mit den nachfolgenden Aspekten anhand einiger Beispiele belegt werden:

Dokumentation und Spezifikation
In der Definition of Done muss festgehalten werden, wann eine User Story beendet ist – dies sieht Scrum auch im nicht-regulierten Umfeld vor – und regelt die Abnahme und den notwendigen Umfang an Dokumentation. Im Unterschied zur Spezifikation wird bei der Dokumentation die im Sprint tatsächlich implementierten Funktionalitäten nachhaltig beschrieben. Dies kann in Form von Szenarien, Testfällen und Anwenderdokumentation erfolgen. Eine Spezifikation beschreibt eine geplante Umsetzung vor der Implementierung und wird häufig in Form von Lasten- und Pflichtenheften durchgeführt. Diese Art der Spezifikation entfällt und wird durch Backlog-Items erfüllt, die in einem regulierten Umfeld neben dem Ziel die Kommunikation zu verbessern, auch durch beschriebene Akzeptanzkriterien – in Form von Anforderungssätzen, Tabellen, Screens oder Beispieldaten – den Spezifikationsbedarf abdecken.

Entwicklungsprozess
Am Beispiel des Leitfaden GAMP5 (Good Automated Manufacturing Practice), der sich als Standard für die Computervalidierung in der pharmazeutischen Industrie durchgesetzt hat, wird deutlich, dass das ursprünglich verwendete V-Modell nicht mehr zwingend vorgeschrieben ist. Entscheidend ist, dass das Prozessvorgehen und dass Backlog-Items als Spezifikationsmittel beschrieben werden, die vollständige Implementierung im Rahmen der Definition of Done erfolgt und ein umfassend dokumentierter Test durchgeführt wird. Diese Forderungen können von einem agilen Team erfüllt werden und der NORMator kann bei der Prozessdokumentation und z.B. im Rahmen von zusätzlichen manuellen Tests und deren Dokumentation unterstützen. Einige Normen verlangen darüber hinaus, dass z.B. der gesamte Softwareentwicklungsprozess ausführlich beschrieben wird. Dies könnte der NORMator übernehmen und z.B. die Events, Artefakte und Rollenaufgaben von Scrum beschreiben, die verwendeten Methoden und Tools sowie die beteiligten Personen und deren ausgeführte Aufgaben.

Nachverfolgbarkeit
Backlog Items (Epics, User Stories, Refactorings usw.) können von ihrer Quelle (Kunden, Team, weitere Stakeholder, Regularien) über Planungsaspekte einer Release-Zusammenstellung und über die Umsetzung im Sprint Backlog (Tasks) bis zu den entsprechenden Tests (z.B. Unit-, Integration-, Abnahme- und Regressionstests) nachverfolgt werden. Hier bietet sich an, dass ein ausführendes Teammitglied den Link zu seinem zu erstellenden Artefakt herstellt. Der NORMator kann bei weiteren Nachverfolgungen z.B. zwischen Risiken und System- oder Softwarekomponenten unterstützen, wenn dies erforderlich ist.

Risiko-Management
Am Beispiel der Entwicklung von Medizinprodukten und der gültigen Norm EN ISO 14971 müssen Methoden des Risikomanagements eingesetzt werden. Hierbei kann der NORMator bei der Identifizierung, Analyse von geeigneten Maßnehmen und Überwachung sowie der Dokumentation von Risiken entsprechende Aufgaben übernehmen. Dies gilt sowohl für Risiken im Rahmen des Entwicklungsprojekts als auch für mögliche Produktrisiken über alle Phasen von der Entwicklung bis zur Entsorgung.

Nachweis der Gebrauchstauglichkeit
Einer der Hauptbetätigungsfelder für den NORMator kann der Nachweis der Gebrauchstauglichkeit gemäß EN 62366 / EN ISO 9241 sein. Im Rahmen dieser Validierung kann der NORMator  Gebrauchsszenarien für unterschiedliche Benutzerrollen beschreiben und mögliche Benutzerfehler definieren, aus denen geeignete Maßnahmen abgeleitet werden. Die Benutzerszenarien müssen zur Ausführung gebracht und protokolliert werden. Zudem verlangt die Norm die Erstellung einer sog. Gebrauchstauglichkeitsakte, die aus hinzugefügten Dokumenten besteht und zur sicheren Nutzung durch die Anwender beitragen soll.

Integration ins Team
Wenn eine Norm die Aufgabendurchführung nicht durch spezielle Rollen vorschreibt, können die notwendigen Aufgaben des regulierten Umfeldes innerhalb der Definition of Done festgehalten und durch das Entwicklerteam ausgeführt werden. Es stellt sich an dieser Stelle aber die Frage, ob  Softwareentwickler tatsächlich mit Aufgaben vertraut werden sollten, die keinen Mehrwert im Rahmen der Produktentwicklung darstellen, sondern nur der regulativen Befriedigung dienen. Unternehmen, die in diesem Umfeld Produkte entwickeln, haben in der Regel ihre Produkte bereits in der vor-agilen Zeit implementiert und verfügen über das notwendige regulative Know-how in ihren Reihen, z.B. als Quality Engineers. Genau diese Mitarbeiter können in einem Scrum-Team integriert werden und mit oder ohne der Bezeichnung des NORMators die notwendigen Aufgaben durchführen oder andere dabei unterstützen.

Fazit:
Ein reguliertes Umfeld und agile Entwicklungsansätze lassen sich hervorragend kombinieren und es besteht die Möglichkeit durch die Einführung des NORMators die notwendigen Aufgaben des regulierten Umfeldes durchführen zu lassen oder bei deren Ausführung zu unterstützen.

Andreas Becker

Kontaktieren Sie Andreas Becker

Andreas Becker ist Agile Transition Coach, Senior Consultant und Trainer bei HOOD GmbH / Agile-by-HOOD. Er begleitet Unternehmen bei der Transition zu agilen Organisationen und unterstützt bei der Implementierung von „Lean Thinking“. Im Fokus seiner Arbeit stehen agile Teams und Business Analysten in agil skalierten Umfeldern. Er ist in der Lean, Agile und Scrum Community aktiv und veröffentlicht Artikel, hält Vorträge und führt Workshops auf internationalen Konferenzen durch und ist zudem Lehrbeauftragter an der Hochschule Rosenheim für "Agile Produktentwicklung". Herr Becker ist zertifizierter Scaled Agile Framework - Program Consultant (SAFe), ScrumMaster und Product Owner. Neben seiner langjährigen Erfahrung im agilen Umfeld hat er in den Bereichen Requirements Engineering, Softwaretest- und Qualitätsmanagement in unterschiedlichen Branchen gearbeitet.