11230 Agile Entwicklung medizinischer Software mit Scrum
|
Mit klassischen Projektmanagement-Methoden ist die Entwicklung von Software meist schlecht steuerbar und schwerfällig. Hier setzen agile Methoden wie Scrum an. Die Software-Entwicklung wird durch sehr kurze Iterationen flexibler. Eine detaillierte Planung erfolgt nur auf Sicht, für die jeweils aktuelle Iteration, eine langfristige Planung wird nur grob erarbeitet. Die kurzen Iterationen haben das Ziel, immer lauffähige Software bereitzustellen. Der Fortschritt kann somit klar bemessen werden und es lassen sich verlässlichere Vorhersagen über die Einhaltung von Budget- und Zeitplanung machen. von: |
1 Einführung
Andere Prinzipien
Software-Entwicklung folgt anderen Prinzipien als die Entwicklung mechanischer oder elektronischer Systeme. Beispielsweise muss nicht auf die Anlieferung von Komponenten gewartet werden. Änderungen können bis kurz vor der Auslieferung durchgeführt werden. Klassische Projektmanagement-Methoden bringen oft lange Wartezeiten mit sich, bis wieder Änderungen an der Software möglich sind. Zudem ist es schwierig, während der Entwicklung den Fortschritt zu messen oder Informationen darüber zu erhalten, ob das Konzept tragfähig ist. Somit ist es schwer vorherzusagen, ob eine Software termin- und budgetgerecht ausgeliefert werden kann. Des Weiteren lässt sich der Entwicklungsaufwand von Software schlecht schätzen, wodurch der Zeitplan oft unzuverlässig ist. Darüber hinaus weist die Food and Drug Administration (FDA) daraufhin, dass gerade Änderungen in einer Software häufig zu kritischen Fehlern führen. Oft verletzen die Entwickler bei späten Änderungen in Systemen implizite Annahmen, sodass Software-Fehler auftreten.
Software-Entwicklung folgt anderen Prinzipien als die Entwicklung mechanischer oder elektronischer Systeme. Beispielsweise muss nicht auf die Anlieferung von Komponenten gewartet werden. Änderungen können bis kurz vor der Auslieferung durchgeführt werden. Klassische Projektmanagement-Methoden bringen oft lange Wartezeiten mit sich, bis wieder Änderungen an der Software möglich sind. Zudem ist es schwierig, während der Entwicklung den Fortschritt zu messen oder Informationen darüber zu erhalten, ob das Konzept tragfähig ist. Somit ist es schwer vorherzusagen, ob eine Software termin- und budgetgerecht ausgeliefert werden kann. Des Weiteren lässt sich der Entwicklungsaufwand von Software schlecht schätzen, wodurch der Zeitplan oft unzuverlässig ist. Darüber hinaus weist die Food and Drug Administration (FDA) daraufhin, dass gerade Änderungen in einer Software häufig zu kritischen Fehlern führen. Oft verletzen die Entwickler bei späten Änderungen in Systemen implizite Annahmen, sodass Software-Fehler auftreten.
„Gedränge”
An all diesen Punkten setzen die Methoden der agilen Software-Entwicklung an. Insbesondere Scrum (engl. für „Gedränge”) wird oft als eine Möglichkeit gesehen, die Entwicklung von Software besser zu steuern. Jedoch scheinen einige der Prinzipien des agilen Manifestes, die bei einer Entwicklung nach Scrum Anwendung finden, gegen die Forderungen der für die CE-Kennzeichnung benötigten Normen zu verstoßen. Eine Reihe erfahrener Software-Entwickler hat das agile Manifest unterzeichnet; sie stellten fest, dass rigides Projekt- und Prozessmanagement nicht unbedingt die Qualität von Software erhöht. Das agile Manifest beschreibt, was in einer Software-Entwicklung wertzuschätzen ist [1]:
An all diesen Punkten setzen die Methoden der agilen Software-Entwicklung an. Insbesondere Scrum (engl. für „Gedränge”) wird oft als eine Möglichkeit gesehen, die Entwicklung von Software besser zu steuern. Jedoch scheinen einige der Prinzipien des agilen Manifestes, die bei einer Entwicklung nach Scrum Anwendung finden, gegen die Forderungen der für die CE-Kennzeichnung benötigten Normen zu verstoßen. Eine Reihe erfahrener Software-Entwickler hat das agile Manifest unterzeichnet; sie stellten fest, dass rigides Projekt- und Prozessmanagement nicht unbedingt die Qualität von Software erhöht. Das agile Manifest beschreibt, was in einer Software-Entwicklung wertzuschätzen ist [1]:
| Agiles Manifest | |
| • | Individuen und Interaktionen mehr als Prozesse und Werkzeuge; |
| • | Funktionierende Software mehr als umfassende Dokumentation; |
| • | Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung; |
| • | Reagieren auf Veränderung mehr als das Befolgen eines Plans. |
Ohne den Zusatz „Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein” wird das agile Manifest oft missverstanden. Einige der Forderungen aus den Normen für die Entwicklung medizinischer Software stehen sicherlich im Widerspruch zu den oben zitierten Aussagen. Im Folgenden wird gezeigt, wie diese scheinbaren Widersprüche sinnvoll zu vereinen sind. Denn auch agile Software-Entwicklung ist kein Freibrief für eine chaotische Entwicklung. Im Gegenteil wird oft durch das Zusammenspiel mehrerer Methoden sehr geschickt das Ziel einer hohen Software-Qualität erreicht und somit die Intention der zur CE-Kennzeichnung geforderten Normen erfüllt. Daher führen agile Projekte oft zu einer hohen Qualität der entwickelten Software, so dass Schäden für Patienten meist ausbleiben.
2 Scrum im Überblick
Agiles Projektmanagement-Framework
Die agile Projektmanagement-Methode Scrum, von manchen auch als agiles Projektmanagement-Framework bezeichnet, enthält folgende Elemente:
Die agile Projektmanagement-Methode Scrum, von manchen auch als agiles Projektmanagement-Framework bezeichnet, enthält folgende Elemente:
| • | Rollen: Product Owner, Scrum Master und Team |
| • | Regelbesprechungen: Sprint Planung, Daily Scrum, Sprint Review und Retrospektive |
| • | Artekfakte: Product Backlog und Sprint Backlog |
Die Sprint Planung dient zur Planung der Aufgaben während einer kurzen Iteration, das Team nutzt das Daily Scrum zur täglichen Koordination der Aufgaben während der Entwicklung. Im Sprint Review werden die Ergebnisse des Sprints abgenommen und in der Retrospektive reflektieren alle Beteiligten den Ablauf des Sprints. Der Product Owner ist der Projektverantwortliche, das Team sind die Software-Entwickler, und der Scrum Master nimmt die Rolle eines Coaches für das Teams ein. Alle drei Rollen zusammen werden auch als Scrum-Team bezeichnet. Das Product Backlog ist eine Liste von priorisierten Anforderungen, und das Sprint Backlog listet Aufgaben, die in einem Sprint abzuarbeiten sind.
2.1 Der Scrum Master
Moderator
Der Scrum Master ist verantwortlich für die Planung, Moderation und Durchführung aller anderen Besprechungen in Scrum, wie Sprint Planung, das Daily Scrum, Sprint Review und die Retrospektiven. Der Scrum Master sorgt als Moderator auch für ausreichende Disziplin. Insbesondere beim Daily Scrum ist Pünktlichkeit essenziell: Wenn die Team-Mitglieder regelmäßig auf eine Person warten müssen, entstehen sonst hohe Kosten. Der Scrum Master ist verantwortlich für den Prozess des Teams. Oft wird der Scrum Master auch als „serveant leader” bezeichnet, da er keine Weisungsbefugnis gegenüber den Mitgliedern des Teams hat. Dementsprechend sollte er auch keine Personalverantwortung gegenüber Mitgliedern des Teams tragen.
Der Scrum Master ist verantwortlich für die Planung, Moderation und Durchführung aller anderen Besprechungen in Scrum, wie Sprint Planung, das Daily Scrum, Sprint Review und die Retrospektiven. Der Scrum Master sorgt als Moderator auch für ausreichende Disziplin. Insbesondere beim Daily Scrum ist Pünktlichkeit essenziell: Wenn die Team-Mitglieder regelmäßig auf eine Person warten müssen, entstehen sonst hohe Kosten. Der Scrum Master ist verantwortlich für den Prozess des Teams. Oft wird der Scrum Master auch als „serveant leader” bezeichnet, da er keine Weisungsbefugnis gegenüber den Mitgliedern des Teams hat. Dementsprechend sollte er auch keine Personalverantwortung gegenüber Mitgliedern des Teams tragen.
2.2 Der Product Owner
Projektmanager
Der Product Owner trägt die Verantwortung für das Projekt. Er ist für den Zeitrahmen, das Budget und den Umfang des Projekts verantwortlich. Dementsprechend sollte das Management dem Product Owner auch die Entscheidungskompetenz für all diese Bereiche übertragen. Die Rolle des Product Owner ähnelt am ehesten der des Projektmanagers in der klassischen Entwicklung. Allerdings hat er keine direkte fachliche Weisungsbefugnis gegenüber dem Team. Er ist nur für die Anforderungen und deren Priorität im Product Backlog sowie für deren Abnahme im Sprint Review verantwortlich. Oft ist der Product Owner allerdings ein „Flaschenhals” in der Entwicklung, da er dem Team während des Sprints für Rückfragen und Detailfragen zu den Anforderungen zur Verfügung stehen muss. Zudem sammelt der Product Owner neue Anforderungen und holt beim Kunden Rückmeldungen über die bereits implementierte Software ein. Auch der Product Owner sollte möglichst keine Personalverantwortung gegenüber anderen Mitgliedern des Scrum-Teams tragen.
Der Product Owner trägt die Verantwortung für das Projekt. Er ist für den Zeitrahmen, das Budget und den Umfang des Projekts verantwortlich. Dementsprechend sollte das Management dem Product Owner auch die Entscheidungskompetenz für all diese Bereiche übertragen. Die Rolle des Product Owner ähnelt am ehesten der des Projektmanagers in der klassischen Entwicklung. Allerdings hat er keine direkte fachliche Weisungsbefugnis gegenüber dem Team. Er ist nur für die Anforderungen und deren Priorität im Product Backlog sowie für deren Abnahme im Sprint Review verantwortlich. Oft ist der Product Owner allerdings ein „Flaschenhals” in der Entwicklung, da er dem Team während des Sprints für Rückfragen und Detailfragen zu den Anforderungen zur Verfügung stehen muss. Zudem sammelt der Product Owner neue Anforderungen und holt beim Kunden Rückmeldungen über die bereits implementierte Software ein. Auch der Product Owner sollte möglichst keine Personalverantwortung gegenüber anderen Mitgliedern des Scrum-Teams tragen.
2.3 Das Team
Das Team sollte aus fünf bis neun Entwicklern bestehen, die Fähigkeiten in den verschiedenen Disziplinen des Software Engineering mitbringen. Mindestens ein erfahrener Entwickler sollte Teil des Teams sein, damit das Team über genügend eigene Erfahrung verfügt und sich so erfolgreich selbst organisieren kann.
2.4 Der Sprint
Potenziell auslieferbare Software
Ein Sprint wird innerhalb einer sogenannten Timebox durchgeführt, das heißt in einer vorher festgelegten Zeitdauer. Die Timebox wird nicht verlängert und hat eine einheitliche Länge von zwei bis vier Wochen. Innerhalb eines Sprints wird eine potenziell auslieferbare Software erstellt. Gemeint ist damit, dass die Software so weit fertig ist, dass eine Auslieferung an den Kunden erfolgen kann. Natürlich ist der Funktionsumfang in den ersten Sprints nicht der Lieferumfang, daher kann die Software sicherlich nicht sofort geliefert werden. Allerdings sollte möglichst immer ein funktionaler Durchstich erreicht werden, das heißt, die Software sollte von der Bedienoberfläche erreichbare nützliche, wenn auch begrenzte Funktionalität aufweisen. In den nachfolgenden Sprints wird die Funktionalität der Software dann Stück für Stück erweitert.
Ein Sprint wird innerhalb einer sogenannten Timebox durchgeführt, das heißt in einer vorher festgelegten Zeitdauer. Die Timebox wird nicht verlängert und hat eine einheitliche Länge von zwei bis vier Wochen. Innerhalb eines Sprints wird eine potenziell auslieferbare Software erstellt. Gemeint ist damit, dass die Software so weit fertig ist, dass eine Auslieferung an den Kunden erfolgen kann. Natürlich ist der Funktionsumfang in den ersten Sprints nicht der Lieferumfang, daher kann die Software sicherlich nicht sofort geliefert werden. Allerdings sollte möglichst immer ein funktionaler Durchstich erreicht werden, das heißt, die Software sollte von der Bedienoberfläche erreichbare nützliche, wenn auch begrenzte Funktionalität aufweisen. In den nachfolgenden Sprints wird die Funktionalität der Software dann Stück für Stück erweitert.
2.5 Die Sprint Planung
Auch Timebox
Welche Funktionalität im nächsten Sprint entwickelt wird, bestimmen der Product Owner und das Team in der Sprint Planung. Auch diese Besprechung hat eine Timebox von vier Stunden bei einem zweiwöchigen Sprint. Als Erstes legt der Product Owner ein Sprint-Ziel fest. Dies beschreibt in ein paar Worten oder einem Satz, was im kommenden Sprint erreicht werden soll. In der Sprint Planung werden dann aus den Anforderungen des Product Backlog konkrete Aufgaben für das Team erstellt. Diese Aufgaben werden dabei in Stunden geschätzt und in das Sprint Backlog übernommen. Eine Aufgabe sollte möglichst innerhalb eines Tages zu erledigen sein. Da der Product Owner das Product Backlog vor der Sprint Planung in einer Rangfolge priorisiert hat, ist für die Sprint Planung klar, welche Anforderungen das Team als Nächstes umsetzt. Während der Sprint Planung ist der Product Owner anwesend, damit er die Anforderungen erklären kann. Dies ist in Scrum ein wichtiges Element: Der Product Owner steht während der Planung und der Entwicklung dem Team für die Beantwortung von Fragen zur Umsetzung von Anforderungen zur Verfügung. Diese mündliche Kommunikation über Anforderungen ist ausdrücklich erwünscht, damit Missverständnisse vermieden und Details sofort geklärt werden können. Während der Sprint Planung klärt das Team zudem selbstständig die Zusammenarbeit: Wer erledigt welche Aufgaben? Welche Aufgaben werden bewusst von bestimmten Personen erledigt, um das Wissen im Team zu verteilen? Das Team organisiert sich selbst. Das Management gibt keine Anweisung dazu, wer welche Aufgabe erledigen soll.
Welche Funktionalität im nächsten Sprint entwickelt wird, bestimmen der Product Owner und das Team in der Sprint Planung. Auch diese Besprechung hat eine Timebox von vier Stunden bei einem zweiwöchigen Sprint. Als Erstes legt der Product Owner ein Sprint-Ziel fest. Dies beschreibt in ein paar Worten oder einem Satz, was im kommenden Sprint erreicht werden soll. In der Sprint Planung werden dann aus den Anforderungen des Product Backlog konkrete Aufgaben für das Team erstellt. Diese Aufgaben werden dabei in Stunden geschätzt und in das Sprint Backlog übernommen. Eine Aufgabe sollte möglichst innerhalb eines Tages zu erledigen sein. Da der Product Owner das Product Backlog vor der Sprint Planung in einer Rangfolge priorisiert hat, ist für die Sprint Planung klar, welche Anforderungen das Team als Nächstes umsetzt. Während der Sprint Planung ist der Product Owner anwesend, damit er die Anforderungen erklären kann. Dies ist in Scrum ein wichtiges Element: Der Product Owner steht während der Planung und der Entwicklung dem Team für die Beantwortung von Fragen zur Umsetzung von Anforderungen zur Verfügung. Diese mündliche Kommunikation über Anforderungen ist ausdrücklich erwünscht, damit Missverständnisse vermieden und Details sofort geklärt werden können. Während der Sprint Planung klärt das Team zudem selbstständig die Zusammenarbeit: Wer erledigt welche Aufgaben? Welche Aufgaben werden bewusst von bestimmten Personen erledigt, um das Wissen im Team zu verteilen? Das Team organisiert sich selbst. Das Management gibt keine Anweisung dazu, wer welche Aufgabe erledigen soll.