Cover.html

2 Agile and Scrum with your own words

In den letzten Jahren hat die Softwareindustrie, angetrieben durch die Softwarekrise, ihre Methoden bei der Produkterstellung und Projektdurchführung reflektiert und Prozessmodelle entwickelt, die einem Scheitern von Softwareprojekten entgegenwirken können. Klassische, statische Modelle wie das Wasserfallmodell haben sich als zu starr herausgestellt: Durch die zu späte Integration von Feedbackschleifen konnten Abweichungen zwischen Anforderung und Implementierung oder von Spezifikation und tatsächlichen Anforderung erst sehr spät erkannt werden. Die daraus resultierenden Änderungen waren sehr aufwändig und dadurch teuer.

Das Ergebnis dieser Überlegungen waren die agilen Methoden wie Extreme Programming und Scrum. Diese Methoden haben die Eigenart, bereits in frühen Phasen und kontinuierlich im Entwicklungsprozess Rückkopplungen zu den Kunden herzustellen und sie damit aktiv in den Prozess einzubinden. Auf diese Weise sollten teure Änderungen am Ende des Prozesses auf frühere Phasen verschoben werden.

Die agilen Methoden wurzeln in dem agilen Manifest, das folgende Kernprinzipien formuliert:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Das Manifest erkennt an, dass die Punkte auf der rechten Seite von Wert sind, zugleich aber von den Punkten auf der linken Seite ein höherer Wert ausgeht.

Unter den Prozessen, die sich an diesem Manifest ausrichten, hat sich Scrum in der Softwarebranche einen Namen gemacht. Ziel ist es, den Erstellungsprozess der Software transparenter zu gestalten. Alle notwendigen Kompetenzen sollen im Team vorhanden sein, das Team ist gleichzeitig voll verantwortlich. Auf diese Weise werden Ausreden und das Abschieben von Verzögerungen auf externe Faktoren ausgeschlossen. Durch die Einbeziehung der Kunden wird die Akzeptanz der Anwender erhöht und verschiebt diesen Punkt nicht auf eine späte Endabnahme, während der Kunde vorher nichts von seiner Software gesehen hat. Ziel ist eine kontinuierliche Wertschöpfung, die früh brauchbare Software entstehen lässt, deren Wert im Laufe des Prozesses ständig gesteigert wird. Entspricht etwas nicht dem Wunsch des Kunden, kann es rechtzeitig erkannt und korrigiert werden.

Scrum ist im Kern simpel, denn es definiert nur wenige Rollen und Meetings. Der organisatorische Überhang bleibt dadurch gering. Der Prozess selbst ist technologieneutral und kann nicht nur für die Softwareentwicklung eingesetzt werden. Er lässt sich gut mit anderen agilen Techniken wie Pair Programming oder Test-driven Development kombinieren.

Abbildung 2.1: Überblick über den Scrum-Prozess

Der Ablauf ist in Abbildung 2.1 schematisch dargestellt. Alle Anforderungen werden im Backlog des Produkts verwaltet. Von dort aus werden die am höchsten priorisierten Aufgaben in einem Backlog für einen Sprint ausgewählt, der somit eine Teilmenge des gesamten Backlogs darstellt. Die endgültige Entscheidung darüber, wie viele Einträge für einen Sprint ausgewählt werden, trifft das Team. Ein Sprint ist ein kurzer, konstanter Zeitabschnitt. In der Regel wählt man Zeiträume zwischen einer Woche - extrem sportlich - bis zu einem Monat – moderat. Längere Zeiträume sind nicht zu empfehlen, da sich das Team sonst zu lange einkapselt und am Ende des Zeitraums wieder hohe Änderungsaufwände riskiert. Im Lauf des Sprints trifft sich das Team täglich zu kurzen Statusmeetings, in denen der Fortschritt und akute Probleme angesprochen werden. Neue Anforderungen, die während des Sprints erkannt werden, sollen im Product Backlog gesammelt werden, sie werden nicht im laufenden Sprint bearbeitet. Nur so kann gewährleistet werden, dass das Team die zuvor gesteckten Ziele erreichen kann – schließlich wird es am Ende des Sprints daran gemessen und für nicht umgesetzte Punkte verantwortlich gemacht. Es gilt die Annahme, dass die Punkte, die das Team für einen Sprint auswählt, auch erledigt werden. Am Ende des Sprints wird zu den erledigten Punkten ein Feedback des Kunden eingeholt. Auf diese Weise wird sofort festgestellt, welche Punkte erledigt sind und bei welchen Punkten noch Arbeit erforderlich ist. In jedem Fall sieht der Kunde einen Fortschritt, denn am Ende des Sprints soll immer eine fertige, installierbare Software stehen, die einen höheren Nutzen hat als die im Sprint davor. Neue Punkte werden wieder im Backlog gesammelt und priorisiert, und dann geht es mit dem nächsten Sprint von vorne los.

Der TFS zielt in der neuen Version durch eine speziell angepasste Vorlage für Teamprojekte auf die optimale Unterstützung von Scrum. Andere Features wie die Sprintplanung und das Taskboard sollen die Integration des Teams und die Umsetzung des Prozesses weiter fördern. Auch mit den neuen Möglichkeiten, Feedback einzuholen, kommt der TFS Scrum entgegen.

2.1 Ziele von Scrum

Scrum hat zum Ziel, den Fortschritt in einem Projekt explizit zu machen. So wird sichtbar, ob die Software mit dem gegebenen Team im Sinne des Kunden umsetzbar ist. Dieser unter Umständen schwierigen Wahrheit mögen sich einige Firmen nicht stellen wollen. Der Prozess ist in dieser Hinsicht sehr hart.

Durch kontinuierliche Soll-/Ist-Vergleiche und den kurzen Zeitraum sollen Aufwandsschätzungen nachvollziehbar und präziser werden. Gründe für Verzögerungen sollen in der Retrospektive festgestellt und im Folgenden abgestellt werden.

Die Kompetenz und Verantwortung des Teams soll gestärkt werden. Durch die systematische Abschaffung von Ausreden wird das Team in die Pflicht genommen, seine verbindlichen Aussagen zu erfüllen. Durch die Fernhaltung neuer Anforderungen vom Team während des Sprints und durch die Interdisziplinarität des Teams werden diesem hierzu auch die Kompetenzen gegeben. Ziel ist, dass das Team als Team funktioniert und mehr wird als die Summe seiner Teile.

Durch Feedback und die Einbindung des Kunden sollen Fehlentwicklungen schnell erkannt und ausgeräumt werden. Es soll ständig prüfbar sein, ob das Projekt noch auf dem richtigen Weg ist.

2.2 Rollen in Scrum

Der Product Owner ist der Wächter über die Anforderungen an ein Projekt oder Produkt. Er bestimmt, welche Anforderungen umgesetzt werden sollen. Der Product Owner ist eine einzelne natürliche Person; kein Komitee, keine Abteilung oder eine andere Gruppe. Er hat die inhaltliche Verantwortung für das Produkt. Meist muss er mit weiteren Stakeholdern interagieren und sich ihnen gegenüber im Sinne des Produkts verantworten.

Die Gruppe von Personen, die Anforderungen durch Softwareentwicklung umsetzen, ist das Team. Da das Team sich selbst organisieren soll, empfehlen sich zumeist Teamgrößen von bis ca. 7 Personen. Das Team agiert immer als Ganzes und wird nicht z. B. entsprechend den Fähigkeiten unterteilt. Tester, Entwickler und Architekten arbeiten gemeinsam, möglichst Hand in Hand.

Der Scrum Master wird zur Überwachung der formalen Einhaltung der Scrum-Vorgehensweise bestimmt. Er soll Hindernisse der Entwicklung aus dem Weg räumen und vertritt in solchen Situation das Entwicklungsteam. Der Scrum Master hat keine disziplinarische Kompetenz über das Team, sondern soll die Belange des Teams und die Anforderungen des Prozesses gegenüber der Geschäftsleitung vertreten und dafür sorgen, dass der Prozess sauber durchläuft. Daher kann diese Rolle nicht von einem Teammitglied eingenommen werden, da die Teammitglieder im Regelfall nicht die nötigen Kompetenzen besitzen.

Die Rollen sind völlig unabhängig von disziplinarischen Strukturen im Team oder der Organisation. Es ist nicht vorgegeben, ob der Product Owner Kunde des Projekts ist oder ein Kunden- oder Produktmanager im Unternehmen. Die Scrum-Rollen sind in Tabelle 2.1 noch einmal zusammengefasst.

Rolle	Beschreibung
Product Owner	Er vertritt die Interessen der Software und behält die Roadmap im Blick. Er spricht mit dem Kunden über die nächsten erforderlichen Entwicklungsschritte.
Scrum Master	Räumt organisatorische Hindernisse für das Team aus dem Weg und sorgt für einen reibungslosen Ablauf des Prozesses.
Team	Eine interdisziplinär aufgestellte Gruppe von Personen, die an der Umsetzung der konkreten Aufgaben arbeiten.

Tabelle 2.1: Zusammenfassung der Scrum-Rollen