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.

Agile Toolbox
Scrum
User Story
bgloger-redakteur
October 27, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein
BG

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?
BG

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion
BG

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht
BG

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht

DeepWork für Autoren – Wie du dein Buch effizient schreibst
BG

DeepWork für Autoren – Wie du dein Buch effizient schreibst

Scrum ist tot, es lebe Scrum!
BG

Scrum ist tot, es lebe Scrum!

Agile Leadership ist nicht gleich agile Leadership
BG

Agile Leadership ist nicht gleich agile Leadership

Seth Godin über Strategie als Denkweise
BG

Seth Godin über Strategie als Denkweise

Die Essenz einer Erfolgreichen Geschäftsstrategie – Einsichten von Seth Godin 
BG

Die Essenz einer Erfolgreichen Geschäftsstrategie – Einsichten von Seth Godin 

Agiles Management – Warum es zur wichtigsten Errungenschaft der Moderne wurde
BG

Agiles Management – Warum es zur wichtigsten Errungenschaft der Moderne wurde

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion
BG

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion

Scrum Master und Agile Coaches – Ersetzt KI unsere Rolle oder eröffnet sie neue Chancen?
BG

Scrum Master und Agile Coaches – Ersetzt KI unsere Rolle oder eröffnet sie neue Chancen?