Vorgehensmodelle: Scrum

avatar

Der Begriff Scrum entstammt der Sportsprache. Im Rugby bezeichnet er das kreisförmige „Gedränge“ zweier Mannschaften beim Neustart eines Spiels. Das Vorgehensmodell Scrum nimmt aus diesem Bild vor allem den Teamgedanken und die zentrale Fragestellung, wie sich Entwicklungsteams organisieren sollten. Zugleich markiert es schon begrifflich die Abkehr vom Wasserfallmodell mit seiner linearen Prozessmodellierung. Das Vorgehensmodell von Scrum kennt Rollen, Events und Artefakte.

In Scrum gibt es sechs verschiedene Rollen für Projektbeteiligte, davon drei interne, also dem Scrum-Team zugehörige (Product Owner, Entwicklungsteam, Scrum Master) und drei externe (Kunde, Anwender. Management).

  • Product Owner

Der Product Owner ist der Visionär und Stratege. Er entwickelt die Produktidee und Produktspezifikation und entscheidet darüber, ob ein Release freigegeben wird. Für das Projekt trägt er die kaufmännische Verantwortung gegenüber dem eigenen Unternehmen und führt die Kommunikation zum Kunden.

  • Entwicklungsteam

Das Entwicklungsteam (Development Team) ist interdisziplinär besetzt und besteht aus allen Personen, die für die Entwicklung des Produkts benötigt werden. Seine Größe ist auf 3 bis 9 Personen begrenzt, um einerseits alle notwendigen Qualifikationen zu integrieren, andererseits aber den internen Organisationsaufwand zu minimieren. Entscheidend für Scrum ist, dass das Entwicklungsteam sich selbst managt und alle internen Prozesse eigenverantwortlich steuert. Beispielsweise hat auch der Product Owner keinen Einfluss darauf, wer welche Aufgabe im Team übernimmt. Das Team ist „als Team“ verantwortlich für das Erreichen der Entwicklungsziele und für die Qualität der Leistung, entsprechend den vorher vereinbarten Standards.

  • Scrum Master

Der Scrum Master ist der Supervisor, Berater und Moderator in allen Scrum-Prozessen. Ohne weisungsbefugt zu sein, sorgt er doch dafür, dass die Regeln von Scrum im Team eingehalten werden. Er arbeitet an der Beseitigung von Hindernissen und Kooperationsproblemen innerhalb des Entwicklungsteams bzw. zwischen Entwicklungsteam und Product Owner. Zudem schult er die an Scrum beteiligten Personen.

Die Produktentwicklung erfolgt in sogenannten Sprints. Dabei handelt es sich um zeitlich vorab befristete Entwicklungsschritte, an deren Ende das fertige, qualitätsgesicherte und dokumentierte Release bestimmter Produktfunktionalitäten ausgeliefert wird. Die Dauer eines Sprints beträgt zwischen einer und maximal vier Wochen. Ein Sprint wird initialisiert und begleitet von Meetings, die entsprechend ihrer Position im Scrum-Prozess, ihrer Aufgaben und ihrer Organisationsform in verschiedene Kategorien unterteilt werden:

  • Im Sprint Planning Meeting zu Beginn eines Sprints verständigen sich Product Owner, Entwicklungsteam, Scrum Master, Management und Anwender auf die Ziele und Anforderungen des anstehenden Sprints.

  • Im Daily Scrum treffen sich sämtliche Mitglieder des Entwicklungsteams täglich zur selben Uhrzeit für eine Viertelstunde, um die Tagesarbeit zu koordinieren. Unter Moderation des Scrum Masters legen die Teammitglieder eigenverantwortlich fest, welche Aufgabe sie übernehmen. Außerdem kann über eventuelle Probleme und Hindernisse an den Scrum Master berichtet werden.

  • Am Ende eines Sprints stellt das Entwicklungsteam im Sprint Review den Kunden und Anwendern die Resultate ihrer Arbeit vor. Dabei werden nur die fertigen und getesteten Funktionalitäten präsentiert.

Im Scrum-Prozess entsteht eine Reihe unterschiedlicher Artefakte, die entweder als Planungs- und Ergebnisdokumente den Entwicklungsprozess unterstützen oder das Produkt-Inkrement als Ergebnis des Entwicklungssprints beinhalten. Einige Artefakte sind:

  • Product Backlog: In einer Liste werden alle zu entwickelnden Funktionalitäten festgehalten.
  • Sprint Backlog: Hier wird die Funktionalitätenliste des Product Backlog auf die zu erledigenden Entwicklungsaufgaben eines Sprints heruntergebrochen. Festgehalten werden nicht nur die Tasks in der vorgegebenen Reihenfolge, entsprechend den Diskussionen und Entscheidungen in den beiden Sprint Planning Meetings, sondern auch kontinuierlich der jeweilige Bearbeitungsstand der Tasks, wie er im Daily Scrum besprochen wird.

Scrum ist als Vorgehensmodell auf die inkrementelle Produktentwicklung in kurzen, schnellen Zyklen ausgelegt. Die dafür bereitgestellten Instrumente erlauben neben der zügigen und regelmäßigen „Sichtbarkeit“ von fertigen Produktinkrementen eine sehr flexible Prozessgestaltung auf Grundlage eng getakteter Performance-Analysen der Entwickler und regelmäßiger Feedbacks der Anwender. Der Fokus liegt auf der Organisation des Entwicklerteams, die für die laufende Projektarbeit weitgehend eine Selbst-Organisation des Teams ist.

Quelle
Rising, Linda & Janoff, N.S.. (2000). The Scrum Software Development Process for Small Teams. Software, IEEE. 17. 26 - 32. DOI: 10.1109/52.854065



0
0
0.000
0 comments