Читать книгу Der Scrum-Reiseführer - Tobias Renk - Страница 13

Die Hauptaufgabe der Entwickler ist es, ein nutzbares Produktinkrement am Ende eines Sprints erzeugt zu haben. Wir werden in Kapitel 5.5 und 5.6 noch einmal intensiv auf diesen Punkt eingehen, da er ein essenzieller Bestandteil von Scrum ist und in der Praxis manches Mal falsch umgesetzt wird. Die Betonung liegt insbesondere auf nutzbares Produktinkrement, also etwas, was Fachabteilungen im operativen Geschäft verwenden können und das einen Nutzen, einen Mehrwert, bringt.

Die lediglich drei vorhandenen Rollen in Scrum erwecken den Eindruck, dass Vorgehensmodell sei einfach umzusetzen und strukturiert. In der praktischen Anwendung führt ebendiese Einfachheit jedoch gelegentlich zu Verwirrungen. Das Verständnis für das Konzept crossfunktionaler Teams ist deshalb umso wichtiger. Crossfunktional bedeutet, dass in einem Entwicklerteam alle notwendigen Kenntnisse, um ein Produktinkrement zu erzeugen, vorhanden sind. Zerlegen wir als Beispiel einen Softwareentwicklungsprozess in drei Schritte: Analyse, Programmierung, Testen. Ein Scrum Team würde mindestens diese drei Fähigkeiten abbilden müssen. Im Idealfall wird jeder Schritt von einem Experten begleitet, der über zusätzliches Know-how in den anderen Bereichen verfügt. Solche Teammitglieder bezeichnet man als T-Shaped ProfessionalsT-Shaped Professional (siehe Abbildung 6). Der große Vorteil besteht darin, dass T-Shaped Professionals Tiefenwissen (Expertenwissen) in einem Bereich besitzen und zeitgleich über ein Breitenwissen aus anderen Bereichen verfügt. Solche Mitarbeiter haben in der Regel einen scharfen Blick für das große Ganze und greifen die Gesamtzusammenhänge schnell; eine Fähigkeit, die besonders in dynamischen und agilen Arbeitsumgebungen von Vorteil ist.

Abbildung 6:

T-Shaped Professionals

Um die oben beschriebene Hauptaufgabe, ein nutzbares Produktinkrement am Ende eines Sprints zu erzeugen, erreichen zu können, sind folgende Tätigkeiten ebenfalls in der Verantwortung des Entwicklerteams: Das Team erzeugt einen Plan für den Sprint, das sogenannte Sprint Backlog. Hierin werden alle Aufgaben, die innerhalb des Sprints erledigt werden sollen, transparent aufgelistet. Um jedoch eine zielgerichtete Erledigung der Aufgaben zu gewährleisten, ist es notwendig, Abhängigkeiten bereits im Vorfeld zu identifizieren und die Planung entsprechend anzupassen. Wird dieser Punkt nicht beachtet, könnten einzelne Aufgaben die Tätigkeiten anderer Teammitglieder blockieren und somit die Erreichung des Sprintziels gefährden. Das Entwicklerteam ist maßgeblich für die Qualität des Produktes zuständig. Hierbei ist vor allem die Definition of Done wichtig, die konkret definiert, wann eine bestimmte Aufgabe oder User Story fertiggestellt ist. Qualität sollte dabei bereits als integraler Bestandteil des Entwicklungsprozesses gesehen werden, um sie von vornherein in das Produkt zu integrieren und nicht erst anschließend in aufwendigen Testphasen zu ergänzen. Dieser Umgang mit Qualität ist eine Umsetzung des Andon Cords, dass bei Toyota Verwendung findet und zu einer enormen Steigerung der Qualität geführt hat. Das Andon Cords ist eine Leine, die jeder Mitarbeiter entlang der Produktionsstrecke ziehen kann – und damit die gesamte Produktion stoppt –, sobald ihnen Qualitätsmängel auffallen. Als Folge werden Probleme und Qualitätsmängel frühzeitig im Prozess erkannt und können kostengünstiger korrigiert werden, als wenn man diese nach der Produktion feststellt. Die tägliche Anpassung des Plans gehört deshalb zu den Aufgaben eines Entwicklerteams. Die Korrekturen finden im Rahmen der Daily Stand-ups statt. Sie dienen dazu, den Weg zum Sprintziel zu optimieren und somit das Ziel schneller, effizienter oder günstiger zu erreichen. Veränderungen, die keinen Einfluss auf die Erreichung des Sprintziels haben sind obsolet. Darüber hinaus trägt jedes Teammitglied die Verantwortung, sich selbst und die anderen immer wieder aufs Neue in die Pflicht zu nehmen, die vereinbarten Ergebnisse im Rahmen eines Sprints zu erreichen.