User Storys in der Entwicklung medizintechnischer Produkte

Karl Bredemeyer hat in seinem Artikel "Scrum in der Medizintechnik" die allgemeinen Vorteile agiler Methoden für die Entwicklung medizintechnischer Produkte beschrieben. Durch einen iterativen und inkrementellen Ansatz sind Verifikation und Validierung durch die gesamte Entwicklung hindurch möglich. In diesem und den nächsten beiden Beiträgen zeigen wir anhand von konkreten Beispielen aus unseren Projekten, wie das geht.Anders als bei reinen Softwarelösungen sind bei medizintechnischen Produkten in der Regel verschiedene Komponenten - Mechanik, Eletronik, Software - miteinander zu integrieren, um ein Produktinkrement zu erreichen. Nehmen wir ein Beispiel:Bei einem Gerät zur Laborautomatisierung soll ein Schließmechanismus für Röhrchen gebaut werden - dies ist unser Produkinkrement. Die Mechanik wird sich um Greifarme und Achsen kümmern müssen, die Elektronik um Motorsteuerung und Fahrmethode, und die Software um die Koordination der Arbeitsabläufe. Die Integration aller Komponenten zu einem funktionierenden Mechanismus mit wirtschaftlichem Wert kann nur dann gelingen, wenn zu jedem Zeitpunkt spezifiziert ist, wie sich das Gesamtsystem zu verhalten hat. Ausgangslage dafür sind in Scrum so genannte Epics. Sie postulieren, welche Funktionalität ein Benutzer des Systems braucht, und welchen Nutzen er davon hat.Beispiel: Als Medizinisch Technische Assistentin (MTA) brauche ich einen automatischen Schließmechanismus für Röhrchen, damit ich die Laborproben nicht mehr von Hand verschließen muss.In der Regel gibt es mehr als eine Epic pro Produkt. Neben dem Schließmechanismus könnten beispielsweise Öffnungsmechanismus, Transportmodul, Aliquotierfunktion sowie Ein- und Aussortierer dazukommen. Die Auflistung aller Epics in einer nach wirtschaftlichem Wert priorisierten Liste bildet das Product Backlog.Im nächsten Schritt werden die Epics in Anforderungen, Akzeptanzkriterien und -tests sowie in Rahmenbedingungen analysiert. Das kann dann für die Epic aus unserem Beispiel folgendermaßen aussehen:Anforderungen: Die Röhrchen sollen durch automatisches Aufdrücken einer Kappe verschlossen werden.Akzeptanzkriterium:Der MTA muss keine zugelassenen Röhrchen mehr von Hand verschließen.Akzeptanztest:600 Röhrchen mit zugelassenen Maßen werden innerhalb von 30 Minuten auslaufdicht verschlossen.Rahmenbedingungen:

• Muss mit Röhrchen von 13-16 mm Durchmesser und 65-100 Millimeter Höhe funktionieren.
• Verschluss muss dicht sein.
• Kappe muss aus Polyethylen sein.
• Farbe der Kappe muss blau sein.

Ist eine Epic so heruntergebrochen, lässt sich bestimmen, welche Komponenten welchen Entwicklungsstand haben müssen, und welche Tests auf Komponenten- und Systemeben laufen müssen, um die Epic laut Akzeptanzkriterium zu erfüllen. Im hier genanten Beispiel werden Software, Elektronik und Mechanik so zusammenspielen müssen, dass Röhrchen zuverlässig versiegelt werden können. Ist dieses funktionale Zusammenspiel erreicht, ist das Produktinkrement erbracht.Die Entwicklung orientiert sich an der sequenziellen Fertigstellung von Epics, die nach ihrer Priorität fertig gestellt werden. Somit ist zu jedem Zeitpunkt ein Produkt vorhanden, das potenziell (natürlich begrenzt auf die aktuell vorhandenen Funktionen) verwendbar ist. Weitere, nicht notwendige Funktionen (z.B. Zentrifugierung) können dann mit einem späteren Release ausgeliefert werden.Im nächsten Beitrag erfahren Sie, wie Sie ein Entwicklungsteam zusammenstellen, das in der Lage ist, Produktinkremente zu liefern.