Agile Software-Entwicklung: Wie wir die Radiologie entwickeln

Welche agilen Methoden und Software Tools wir nutzen

Mit unserer Software möchten wir flexibel auf Kundenbedürfnisse eingehen. Das geht am besten mit einem agilen Entwicklungsprozess. In der Software-Entwicklung  werden häufig die agilen Methoden Kanban und Scrum eingesetzt. Wir nutzen die Vorteile beider Methoden und schaffen so transparente Arbeitsabläufe, eigenverantwortliche Teammitglieder und eine effiziente Durchführung. Unsere Erfolge dokumentieren und tracken wir mithilfe von Jira und Confluence.

Wie wir Software entwickeln

Der Product Owner entscheidet sich gemeinsam mit der Geschäftsführung für ein neues Projekt – z.B. eine neue Funktion. Daraufhin entwirft er mit dem Entwicklungsteam zusammen passende User Stories. Anschließend legen die Entwickler fest, welche einzelnen Aufgaben es zu erledigen gilt, wer diese übernimmt und sie schätzen, wie lange diese Aufgaben voraussichtlich dauern werden. Jetzt werden diese Aufgaben und Zeitschätzungen in einzelne Sprints eingeteilt und auf das Kanban-Board geheftet. Der Release Master stellt sicher, dass alle Sprints vom Kanban-Board in den vorgegebenen Zeiträumen erledigt werden.

Kanban

Kanban kommt aus Japan und bedeutet Karte, Etikett oder Aufkleber. Die Idee hinter dieser Entwicklungsmethode ist, die Arbeit auf einem Board mit den Spalten „to do“, „work in progress“ und „done“ zu visualisieren. So sollen die Anzahl der Aufgaben, die von den einzelnen Teammitgliedern selbständig bearbeitet werden, begrenzt werden. Auf diese Weise sollen die Durchlaufzeiten verkürzt und sichtbar werden, an welcher Stelle eventuell zusätzliche Ressourcen nötig sind.

Scrum

Scrum ist ein iteratives Vorgehensmodell aus der agilen Software-Entwicklung, bei dem Projekte im Voraus nicht komplett und detailliert geplant, sondern schrittweise verfeinert werden. Statt in wöchentlichen Meetings mehrere Stunden zusammenzusitzen und eine Vielzahl von Informationen auszutauschen, setzt Scrum mit sogenannten Daily Standups auf einen fokussierten, täglichen Informationsaustausch. Im Stehen berichten die Teammitglieder – ohne Unterbrechung – der Reihe nach, wobei jedem Teilnehmer nur ca. 1 Minute Sprechzeit zusteht. Somit dauert ein Daily Standup Meeting meist nicht länger als 10 Minuten.

Sprint

Das Team verpflichtet sich innerhalb einer gewissen Zeit, die meist 2 bis 3 Wochen beträgt, eine gewisse Anzahl von Aufgaben umzusetzen. Dieser fester Zeitraum wird als Sprint bezeichnet.

User Story

User Stories beschreiben Anforderungen in wenigen einfachen Sätzen nach einer vorgegebenen Struktur: „Als [Rolle] möchte ich [Ziel / Wunsch], um [Nutzen]“ Diese Struktur lenkt die Aufmerksamkeit auf das Wesentliche. User Stories entstehen in der Diskussion zwischen Product Owner, dem Kunden und den Entwicklern. Komplexe Anforderungen werden so nicht in vollem Umfang abgebildet, dafür werden häufig „Akzeptanzkriterien“ zu einer User Story aufgenommen. Diese beschreiben das Verhalten des zukünftigen Systems unter verschiedenen Bedingungen. Im Laufe eines Projekts entsteht eine Vielzahl von User Stories, die vom Product Owner im Product Backlog verwaltet und fortlaufend priorisiert werden.

Epic

Grundannahme der agilen Software-Entwicklung ist, dass nicht alle Anforderungen zu Beginn eines Projekts vollständig durchdrungen werden, sondern erst zu einem späteren Zeitpunkt. Epics greifen diesen Faktor auf und beschreiben Anforderungen bewusst grob. Aus Epics sollen zu gegebenem Zeitpunkt beherrschbare Anforderungen abgeleitet werden. Dazu werden aus der Epic nach und nach neue User Stories generiert. Wichtig dabei ist, dass die Verfeinerung möglichst spät erfolgt. Ansonsten besteht die Gefahr, dass sich die Anforderungen bis zur Umsetzung ändern. Epics dienen bei uns als Container für User Stories und vereinen alle User Stories zu einer bestimmten Produktfunktion.

Was macht ein Product Owner?

Der Product Owner (PO) ist für den Erfolg des Produkts verantwortlich, definiert das erwünschte Produkt und kommuniziert seine Wünsche an das Team. Er nimmt Sprint-Ergebnisse ab und ist für die Rentabilität des gesamtes Projekts verantwortlich. Der PO ist jedoch kein klassischer Projektleiter, seine Entscheidungsbefugnis bezieht sich nur auf Anforderungen, nicht aber z.B. auf die Detailplanung des Einsatzes der Entwickler. Außerdem muss der PO die Kundenbedürfnisse verstehen, eine Vision für das Produkt entwickeln und sowohl das Team als auch auch die Kunden für diese Vision begeistern. Ein PO muss die Einträge im Product Backlog (z.B. User Stories) zwar nicht selbst schreiben, jedoch muss er sicherstellen, dass das Backlog gepflegt ist (priorisiert, hinreichend detailliert, transparent). Er sorgt auch dafür, dass die Anforderungen umgesetzt werden und die Verfeinerung der Epics rechtzeitig beginnt. Der Product Owner übernimmt bei uns auch einige Aufgaben des Scrum Master. Unter anderem sorgt er für optimale Arbeitsbedingungen und räumt Hindernisse aus dem Weg. Darüber hinaus erarbeitet er z.B. in der Retrospektive zusammen mit dem Team Maßnahmen für kontinuierliche Verbesserungen und für die Zusammenarbeit mit dem Kunden.

Was macht ein Release Master?

Die Rolle des Release Master haben wir selbst eingeführt und nutzen sie anstelle eines Scrum Master. Die Aufgaben des Scrum Master verteilen sich bei uns daher auf den Release Master und den Product Owner.  Der Release Master sorgt über den Zeitraum einer bestimmten Produkt-Freigabe hinweg für optimale Arbeitsabläufe, berichtet über die Arbeitsfortschritte an den Product Owner und aktualisiert das Kanban-Board.