Testen in Scrum-Projekten

7.4      Qualitätssicherung klassisch

7.4.1      Instrumente

7.4.2      Organisation

7.5      Qualitätssicherung agil

7.5.1      Wirkungsprinzip und Instrumente

7.5.2      Stärken und Schwächen

7.6      Testen agil

7.6.1      Erfolgsfaktoren für agiles Testen

7.6.2      Testplanung in Scrum

7.7      Skills, Ausbildung, Werte

7.8      Checkfragen und Übungen

7.8.1      Self-Assessment

7.8.2      Methoden und Techniken

7.8.3      Weiterführende Übungen

8        Fallstudien

8.1      Scrum in der Entwicklung von Video- und Audiosoftware

8.2      Systemtest nonstop – Scrum in der TestBench-Toolentwicklung

8.3      Scrum in der Webshop-Entwicklung

8.4      Scrum bei ImmobilienScout24

8.5      Scrum in der Medizintechnik

8.6      Testen mit Scrum bei GE Oil & Gas

Anhang

A        Glossar

B        Quellenverzeichnis

B.1      Literatur

B.2      Webseiten

B.3      Normen

Index

1 Einleitung

Software ist allgegenwärtig. Nahezu jedes komplexere Produkt ist heute softwaregesteuert und auch viele Dienstleistungen stützen sich auf Softwaresysteme. Software und Softwarequalität sind daher ein entscheidender Wettbewerbsfaktor. Ein Unternehmen, das neue oder bessere Software in kürzerer Zeit in sein Produkt integrieren bzw. auf den Markt bringen kann (Time-to-Market), ist seinen Mitbewerbern überlegen.

Agile Entwicklungsmodelle versprechen eine schnellere »Time-to-Market« bei gleichzeitig besserer Ausrichtung an den Kundenanforderungen und nicht zuletzt bessere Softwarequalität. So erstaunt es nicht, dass heute in Unternehmen zunehmend agile Methoden eingesetzt werden – auch in großen, internationalen Projekten und in Produktentwicklungseinheiten großer Konzerne, quer durch alle Branchen. In den meisten Fällen bedeutet dies den Umstieg von der Entwicklung nach V-Modell auf die agile Entwicklung mit Scrum¹.

Die Umstellung auf »agil« und das nachhaltige produktive agile Arbeiten sind jedoch nicht ganz einfach. Insbesondere dann, wenn mehr als nur ein Team davon betroffen ist. Jedes Teammitglied, das Projektmanagement, aber auch das Management in der Linienorganisation muss teils gravierende Änderungen gewohnter Abläufe und Arbeitsweisen vollziehen. Dabei sind Softwaretest und Softwarequalitätssicherung ganz entscheidend daran beteiligt, ob ein Team, eine Softwareabteilung oder ein ganzes Unternehmen agiles Entwickeln langfristig erfolgreich beherrscht und so die erhofften Vorteile nachhaltig realisieren kann.

Zu den populären agilen Entwicklungsmethoden gibt es eine Fülle auch deutschsprachiger Literatur. Einige empfehlenswerte Einführungen, z. B. zu Scrum, finden sich im Literaturverzeichnis dieses Buches. In der Regel wird das Thema »agile Softwareentwicklung« in diesen Büchern aus Sicht des Entwicklers und Programmierers betrachtet. Demgemäß stehen agile Programmiertechniken und agiles Projektmanagement im Vordergrund. Wenn das Thema Testen erwähnt wird, geht es meistens um Unit Test und zugehörige Unit-Test-Werkzeuge, also im Wesentlichen um den Entwicklertest. Tatsächlich kommt dem Testen in der agilen Entwicklung aber eine sehr große und erfolgskritische Bedeutung zu und Unit Tests alleine sind nicht ausreichend.

Dieses Buch möchte diese Lücke schließen, indem es agile Softwareentwicklung aus der Perspektive des Testens und des Softwarequalitätsmanagements betrachtet und aufzeigt, wie »agiles Testen« funktioniert, wo »traditionelle« Testtechniken auch im agilen Umfeld weiter benötigt werden und wie diese in das agile Vorgehen eingebettet werden.

1.1 Zielgruppen

Verstehen, wie Testen in agilen Projekten funktioniert.

Das Buch richtet sich zum einen an Leser, die in das Thema agile Entwicklung erst einsteigen, weil sie künftig in einem agilen Projekt arbeiten werden oder weil sie Scrum in ihrem Projekt oder Team einführen wollen oder gerade eingeführt haben:

• Entwicklungsleiter, Projektmanager, Testmanager und Qualitätsmanager erhalten Hinweise und Tipps, wie Qualitätssicherung und Testen ihren Beitrag dazu leisten können, das Potenzial agiler Vorgehensweisen voll zu entfalten.

• Professionelle (Certified) Tester und Experten für Softwarequalität erfahren, wie sie in agilen Teams erfolgreich mitarbeiten und ihre spezielle Expertise optimal einbringen können. Sie lernen auch, wo sie ihre aus klassischen Projekten gewohnte Arbeitsweise umstellen oder anpassen müssen.

Wissen über (automatisiertes) Testen und agiles Qualitätsmanagement erweitern

Ebenso angesprochen werden aber auch Leser, die bereits in agilen Teams arbeiten und eigene »agile« Erfahrungen sammeln konnten und die ihr Wissen über Testen und Qualitätssicherung erweitern wollen, um die Produktivität und Entwicklungsqualität in ihrem Team weiter zu erhöhen:

• Product Owner, Scrum Master, Qualitätsverantwortliche und Mitarbeiter mit Führungsfunktion erfahren in kompakter Form, wie systematisches, hoch automatisiertes Testen funktioniert und welchen Beitrag Softwaretester im agilen Team leisten können, um kontinuierlich, zuverlässig und umfassend Feedback über die Qualität der entwickelten Software zu liefern.

• Programmierer, Tester und andere Mitglieder eines agilen Teams erfahren, wie sie hoch automatisiertes Testen realisieren können, und zwar nicht nur im Unit Test, sondern auch im Integrations- und im Systemtest.

Das Buch beinhaltet viele praxisorientierte Beispiele und Übungsfragen, sodass es auch als Lehrbuch und zum Selbststudium geeignet ist.

1.2 Zum Inhalt

Kapitel 2

Kapitel 2 gibt einen knappen, vergleichenden Überblick über die derzeit populärsten agilen Vorgehensmodelle Scrum und Kanban. Leser mit Managementaufgaben, die ihr Projekt oder ihre Unternehmenseinheit auf »agil« umstellen wollen, erhalten hier eine Zusammenfassung der wichtigsten agilen Managementinstrumente. Dem gegenübergestellt wird das Vorgehen in Projekten, die sich an klassischen Vorgehensmodellen orientieren. Dies vermittelt einen Eindruck über die Veränderungen, die mit der Einführung agiler Ansätze einhergehen. Leser, die Scrum und Kanban schon kennen, können dieses Kapitel überspringen.

Kapitel 3

Kapitel 3 zeigt auf, welche leichtgewichtigen Planungs- und Steuerungsinstrumente in Scrum anstelle des klassischen Projektplans zum Einsatz kommen. Denn »agil« zu arbeiten, bedeutet keineswegs »planlos« zu arbeiten. Auch Kapitel 3 richtet sich primär an Leser, die auf agile Entwicklung umsteigen. Die Erläuterungen und Hinweise, welchen Beitrag die jeweiligen Planungsinstrumente zur »konstruktiven Qualitätssicherung« und damit zur Fehlervermeidung liefern, sind jedoch auch für Leser mit agiler Projekterfahrung wertvoll.

Kapitel 4

Kapitel 4 behandelt das Thema Unit Tests und »Test First«. Es erklärt, was Unit Tests leisten und wie Unit Tests automatisiert werden. Systemtester, Fachtester oder Projektbeteiligte ohne oder mit geringer Erfahrung im Unit Test finden hier Grundlagen über die Techniken und Werkzeuge im entwicklungsnahen Test, die ihnen helfen, enger mit Programmierern und Unit-Testern zusammenzuarbeiten. Programmierer und Tester mit Erfahrung im Unit Test erhalten hilfreiche Tipps, um ihre Unit Tests zu verbessern. Ausgehend von diesen Grundlagen wird Test First (testgetriebene Entwicklung) vorgestellt und die hohe Bedeutung dieser Praktik für agile Projekte erklärt.

Kapitel 5

Kapitel 5 erklärt Integrationstests und »Continuous Integration«. Auch Programmierer, die ihren Code intensiv mit Unit Tests prüfen, vernachlässigen dabei oft Testfälle, die Integrationsaspekte überprüfen. Daher werden in diesem Kapitel zunächst wichtige Grundlagen über Softwareintegration und Integrationstests vermittelt. Anschließend wird die Continuous-Integration-Technik vorgestellt und erläutert, wie ein Continuous-Integration-Prozess im Projekt eingeführt und angewendet wird.

Kapitel 6

Kapitel 6 erörtert Systemtests und »Test nonstop«. Aufbauend auf den Grundlagen über Systemtests werden wichtige Techniken für manuelle und automatisierte System- und Akzeptanztests im agilen Umfeld erläutert. Anschließend wird aufgezeigt, wie auch Systemtests effizient automatisiert und in den Continuous-Integration-Prozess des Teams eingebunden werden können. Kapitel 6 ist dabei nicht nur für Systemtester und Fachtester gedacht, sondern auch für Programmierer, die besser verstehen wollen, welche Testaufgaben jenseits des entwicklungsnahen Tests im agilen Team gemeinsam zu bewältigen sind.

Kapitel 7

Kapitel 7 stellt klassisches und agiles Verständnis von Qualitätsmanagement und Qualitätssicherung gegenüber und erläutert die in Scrum »eingebauten« Praktiken zur vorbeugenden, konstruktiven Qualitätssicherung. Der Leser erhält Hinweise und Tipps, wie Qualitätsmanagement »agiler« realisiert werden kann und wie Mitarbeiter aus Qualitätssicherungsabteilungen, Qualitätsmanagementbeauftragte und andere Qualitätssicherungsspezialisten ihr Know-how in agilen Projekten einbringen und so einen wertvollen Beitrag für ein agiles Team leisten können.

Kapitel 8

Kapitel 8 präsentiert mehrere Fallstudien aus Industrie, Onlinehandel und Unternehmen der Softwarebranche. Diese spiegeln Erfahrungen und Lessons Learned wider, die die Interviewpartner bei der Einführung und Anwendung agiler Vorgehensweisen in ihrem jeweiligen Unternehmen gesammelt haben.

Kapitelstruktur

Die Kapitel 2, 3, 7 und 8 erörtern Prozess- und Managementthemen und sprechen demgemäß den an Managementaspekten interessierten Leser an. Die Kapitel 4, 5 und 6 erörtern das (automatisierte) »agile Testen« auf den verschiedenen Teststufen und sprechen den (auch) technisch interessierten Leser an. Dabei werden die Ziele und Unterschiede von Unit Tests, Integrations- und Systemtests ausführlich angesprochen. Denn wie bereits erwähnt, wird Testen leider in vielen agilen Projekten oft mit Unit Tests gleichgesetzt. Abbildung 1–1 illustriert die Kapitelstruktur nochmals:

Abb. 1–1 Kapitelstruktur

Cross-Referenz zum ISTQB^®-Syllabus

Das Buch deckt den Stoff des ISTQB^® Certified Tester – Foundation Level Extension Syllabus Agile Tester (Version 2014) ab. Die Gliederung des Buches folgt jedoch nicht der Gliederung des Lehrplans. Auch werden viele Aspekte, die beim Testen in agilen Projekten eine Rolle spielen, im Buch über den ISTQB^®-Lehrplan hinausgehend oder zusätzlich behandelt.

Die folgende Cross-Referenz-Tabelle erleichtert es, gezielt den ISTQB^®-Lehrstoff anhand der im Lehrplan genannten Lernziele nachlesen zu können:

Tab. 1–1 Cross-Referenz zum ISTQB^®-Syllabus

Fallbeispiel, Checkfragen und Übungen

Viele, wenn nicht die meisten agilen Ideen, Techniken und Praktiken sind, wenn man den Ausführungen in der entsprechenden Literatur folgt, einfach nachzuvollziehen. Auch die Ideen, Hinweise und Tipps der folgenden Kapitel werden dem Leser vielleicht zunächst einfach erscheinen. Die Knackpunkte stellen sich erst in der Praxis bei der Umsetzung heraus. Das Buch geht auf diese Hürden ein, und damit der Leser praktisch nachvollziehen und »erleben« kann, wo die Herausforderungen stecken, sind folgende Elemente im Text zu finden:

• Ein durchgängiges Fallbeispiel, anhand dessen die jeweils vorgestellten Methoden und Techniken veranschaulicht werden.

• Checkfragen und Übungen, anhand derer der Leser am Ende eines Kapitels den besprochenen Stoff rekapitulieren kann, aber auch seine Situation und sein Agieren im eigenen Projekt kritisch hinterfragen kann.

1.3 Fallbeispiel

Dem Fallbeispiel des Buches liegt folgendes fiktives Szenario zugrunde: Die Firma »eHome-Tools« entwickelt Systeme zur Hausautomation. Das Funktionsprinzip solcher Systeme ist folgendes:

Fallbeispiel eHome-Controller

• Aktoren:

  Lampen und andere elektrische Verbraucher werden mit elektronischen Schaltern verbunden (sog. Aktoren). Jeder Aktor ist (per Kabel- oder Funkverbindung) an einen Kommunikationsbus angeschlossen und über diesen »fernsteuerbar«.

• Sensoren:

  An den Bus können zusätzlich elektronische Temperaturfühler, Windmesser, Feuchtigkeitssensoren usw. angekoppelt werden, aber auch einfache Kontaktsensoren, die z. B. geöffnete Fenster erkennen und melden.

• Bus:

  Schaltkommandos an die Aktoren, aber auch Statusmeldungen der Aktoren und Messwerte der Sensoren werden in Form von sogenannten Telegrammen über den Bus von und zum Controller übertragen.

• Controller:

  Der Controller sendet Schaltkommandos an die Aktoren (z. B. »Licht Küche ein«) und empfängt Statusmeldungen der Sensoren (z. B. »Temperatur Küche 20 Grad«) und Aktoren (z. B. »Licht Küche eingeschaltet«). Er ist in der Lage, ereignisgesteuert (also abhängig von eingehenden Meldungen) oder auch zeitgesteuert Folgeaktionen auszulösen (z. B. »20:00 Uhr → Rollo Küche schließen«).

• Bedienoberfläche:

  Der Controller bietet den Bewohnern des eHome auch eine geeignete Bedienoberfläche. Diese visualisiert den aktuellen Status des eHome und ermöglicht es den Bewohnern, Befehle (z. B. »Licht Küche aus«) per »Mausklick« an die Hauselektrik zu senden.

»eHome-Tools« steht mit seinen Produkten im harten Wettbewerb zu einer Vielzahl von Anbietern. Um in diesem Wettbewerb zu bestehen, wird beschlossen, eine neue Controller-Software zu entwickeln. Allen Beteiligten ist klar, dass Schnelligkeit ein wesentlicher Erfolgsfaktor für das Vorhaben ist. Denn immer mehr Interessenten und Kunden fragen »eHome-Tools« nach einer Bediensoftware, die auf Smartphones und anderen mobilen Geräten läuft. Auch die Offenheit und Erweiterbarkeit des Systems für Geräte von Fremdherstellern ist enorm wichtig, um Marktanteile hinzuzugewinnen. Wenn das neue System Geräte konkurrierender Hersteller steuern kann, rechnet man sich Chancen aus, auch Kunden dieser Hersteller z. B. beim Ausbau ihrer Systeme für eigene Geräte begeistern zu können. Dazu muss man nicht nur möglichst schnell eine möglichst breite Palette von Wettbewerbs-Hardware unterstützen, sondern auch künftig in der Lage sein, neu am Markt auftauchende Gerätemodelle kurzfristig zu unterstützen.

Daher wird entschieden, den Controller »agil« zu entwickeln und monatlich eine verbesserte, neue Version des Controllers herauszubringen, die mehr Geräte und weitere Protokolle unterstützt.

1.4 Webseite

Die im Buch enthaltenen Codebeispiele sind auf der Webseite zum Buch unter [URL: SWT-knowledge] veröffentlicht und herunterladbar. Der Leser kann diese Beispiele so auf seinem eigenen Rechner nachvollziehen und mit eigenen Testfällen experimentieren.

Auch die Übungsfragen sind dort veröffentlicht und kommentierbar. Über eine rege Onlinediskussion im Leserkreis über mögliche Lösungsalternativen freue ich mich.

Trotz der hervorragenden Arbeit des Verlags und der Reviewer und mehrerer Korrekturläufe sind Fehler im Text nicht auszuschließen. Notwendige Korrekturhinweise zum Buchtext werden ebenfalls auf der Webseite veröffentlicht werden.

2 Agile und klassische Vorgehensmodelle

Dieses Kapitel gibt eine knappe Charakteristik des agilen Projektmanagementframeworks Scrum und der inzwischen auch populären, aus dem Lean Product Development stammenden und zu Scrum einige Ähnlichkeiten aufweisenden Projektmanagementmethode Kanban. Beiden gegenübergestellt wird das Vorgehen in Projekten, die sich an klassischen Vorgehensmodellen orientieren. Leser mit Managementaufgaben, die ihr Projekt oder ihre Unternehmenseinheit auf eine agile Vorgehensweise umstellen wollen, erhalten hier einen Überblick und Eindruck von den organisatorischen Veränderungen, die mit der Einführung agiler Ansätze im Unternehmen, der betroffenen Abteilung und den betroffenen Teams einhergehen. Leser, die Scrum und Kanban schon kennen, können dieses Kapitel überspringen.

2.1 Scrum

Scrum ist ein agiles¹ Projektmanagementframework, das von Ken Schwaber erstmalig 1999 mit seinem Artikel »Scrum: A Pattern Language for Hyperproductive Software Development« [Beedle et al. 99] eingeführt wurde und das ab 2002 mit seinem Buch »Agile Software Development with Scrum« [Schwaber/Beedle 02] breiter bekannt wurde.

Scrum regelt nicht, welche Softwareentwicklungstechniken (wie beispielsweise Refactoring) die Entwickler einzusetzen haben, um Software zu schreiben. Dies überlässt Scrum der Selbstorganisation des Teams, das dann meistens geeignete Praktiken, die aus dem Extreme Programming² (XP) stammen, auswählt und im Zuge des Umstiegs auf Scrum mit einführt. Ebenso wenig gibt Scrum vor, wie das Testen in einem nach Scrum ablaufenden Projekt gestaltet werden soll.

Agile Praktiken für das Management

Das Scrum-Rahmenwerk beschreibt Praktiken für das Management von (Software-)Projekten und verändert dieses Projektmanagement radikal! Es ersetzt den klassischen deterministisch vorausplanenden Ansatz durch eine empirisch adaptive Projektsteuerung [Schwaber/Beadle 02]. Das Ziel ist, auf Änderungen schnell, unkompliziert und dennoch angemessen zu reagieren, anstatt Zeit und Energie auf die Erstellung, Durchsetzung und Nachführung veralteter Pläne zu verschwenden. Die wesentlichen Projektmanagementinstrumente in Scrum³ dafür sind:

• Kurze Iterationen:

  Scrum gliedert ein Projekt in kurze Iterationen fester Länge. Eine solche Iteration heißt in Scrum »Sprint«⁴. Jede Iteration soll ein potenziell auslieferbares Produkt erzeugen, dessen Funktionsumfang mit jeder Iteration wächst. Die Idee dahinter: Wenn der zu planende Zeitraum – also ein Sprint – kurz ist, z. B. ein bis drei oder vier Wochen (vgl. [Schwaber/Beedle 02, S. 52]), dann ist das Planen und Steuern per se einfacher und funktioniert zuverlässiger als bei langen (Release-)Zyklen von z. B. ½ bis 1 Jahr oder gar länger.

• Product Backlog:

  Wenn man die Planung auf nur eine Dimension reduziert, auf eine simple Liste der Arbeitsergebnisse, die erreicht werden sollen, dann verschwindet eine Menge Komplexität. Genau dies passiert in Scrum. Der Product Owner (s. u.) führt ein sogenanntes Product Backlog: »Es enthält alle bekannten Anforderungen und Arbeitsergebnisse, die zur Erreichung des Projektziels umgesetzt oder erbracht werden müssen. Hierzu zählen funktionale und nicht funktionale Anforderungen sowie Anforderungen an die Benutzerschnittstelle. Außerdem kann das Product Backlog Arbeitsergebnisse wie das Aufsetzen der Test- und Entwicklungsumgebung oder das Beseitigen von Defekten (Bugs) enthalten« [Pichler 08, Abschnitt 4.2]. Die Einträge in dieser Sammlung aller bekannten oder in Betracht stehenden Produktanforderungen und Arbeitsergebnisse werden relativ zueinander priorisiert. Weitere gegenseitige Abhängigkeiten oder eine bestimmte zeitliche Reihenfolge werden nicht betrachtet. Das Product Backlog hat nicht den Anspruch, vollständig zu sein. Es entwickelt und verändert sich über die Sprints hinweg. Dieses Arbeiten am Backlog wird auch »Backlog Grooming« genannt: Der Product Owner ergänzt es um neu erkannte Anforderungen oder zerlegt diese wenn nötig in kleinere Teile, sobald er und das Team die Anforderung dazu gut genug verstanden haben. Anforderungen werden neu bewertet und umpriorisiert. Obsolete Anforderungen werden gestrichen. Zugespitzt heißt das: Planen wird einfach und zuverlässig, weil alles, was Planen fehlerträchtig macht, vermieden wird.

• Sprint Backlog:

  Ganz so einfach ist es natürlich nicht. Nur mit einem Sack voll priorisierter Anforderungen kann ein Softwareprojekt nicht gesteuert werden. Auch im Scrum-Projekt muss entschieden werden, wer im Team wann welche Anforderung umsetzt und welche Aufgaben er dazu erledigen muss. Aber in Scrum entscheidet das nicht ein einsamer Projektleiter vorab für alle Aufgaben. Sondern die Entscheidungen trifft das Team zusammen mit dem Product Owner »portionsweise« je Sprint. Zu Beginn eines jeden Sprints »zieht« das Team diejenigen Anforderungen, die im priorisierten Product Backlog an der Spitze stehen und die es in diesem Sprint umsetzen will, aus dem Product Backlog in ein kleineres Sprint Backlog. Dabei achtet das Team darauf, dass diese Anforderungen gut genug verstanden und genau genug formuliert sind. Anforderungen, die diese Kriterien (»Definition of Ready«) nicht erfüllen, sind noch nicht reif für die Übernahme in den Sprint. Alle Überlegungen und Entscheidungen über Abhängigkeiten zwischen diesen Anforderungen, resultierende Aufgaben und Aufwände sowie sinnvolle zeitliche Reihenfolgen werden erst jetzt angestellt und getroffen. Alle Aufgaben, die das Team als nötig identifiziert, um die für diesen Sprint ausgewählten Anforderungen umzusetzen, werden im Sprint Backlog eingetragen. Um abzusichern, dass am Sprint-Ende tatsächlich ein fertiges Produktinkrement vorliegen wird, formuliert das Team Kriterien, anhand derer es überprüfen und entscheiden kann, »ob die Arbeit an dem Inkrement abgeschlossen ist« [URL: Scrum Guide]. Diese »Fertig«-Kriterien werden als »Definition of Done« des Teams (DoD) bezeichnet. Sie können global als Checkliste für alle Aufgaben des Sprints formuliert werden oder auch für einzelne Aufgaben spezifisch. Die gemeinsame Diskussion über angemessene »Fertig«-Kriterien trägt ganz wesentlich dazu bei, den Inhalt einer Anforderung oder einer Aufgabe zu klären und im Team ein gemeinsames, gleiches Verständnis über jede Aufgabe zu erhalten. Alle diese Überlegungen erfolgen dabei aber nur für die Aufgaben, die den anstehenden Sprint betreffen. Der Planungshorizont ist kurz. Die Aufgabenmenge ist (verglichen mit dem Gesamtprojekt) klein. Das Team hat einen klaren Fokus. Und der Sprint ist geschützt! Das bedeutet, dass während des laufenden Sprints das Sprint Backlog nicht mehr verändert oder gar erweitert werden darf (s. a. [Pichler 08, Abschnitt 6.2.2]). Eine solche Sprint-Planung hat sehr gute Chancen, eingehalten zu werden!

  Abb. 2–1Scrum

• Timeboxing:

  In Scrum hat jeder Sprint die Pflicht, lieferfähige Software zu produzieren (»potentially shippable product«)⁵. Das bedeutet: In das Sprint Backlog kommen nur Aufgaben, die zu diesem potenziell einsetzbaren Produkt beitragen – nichts anderes. Produktteile, die zum Sprint-Ende nicht fertig werden, fallen weg. Um das zu vermeiden, versucht das Team am Sprint-Anfang Produkteigenschaften (Features) auszuwählen, die im Sprint zum Abschluss gebracht und realisiert werden können. Im Zweifel gilt: Am Stichtag »auslieferbar« geht vor »Funktionsumfang«. Dieses Prinzip nennt man »Timeboxing«. Um Timeboxing möglich zu machen, muss am Sprint-Anfang für alle zur Debatte stehenden Produktfeatures, die im Sprint realisiert werden könnten, der Realisierungsaufwand geschätzt werden. Features mit zu hohem Aufwand werden weggelassen, zerlegt oder so weit wie nötig funktional abgespeckt. Natürlich stellt sich dem Team hier genau wie bei klassischem Vorgehen das Problem der Aufwandsschätzung. Zwei Dinge sorgen aber dafür, dass die Aufwandsschätzung in Scrum-Projekten besser gelingt als klassisch:

  • Es muss »nur« der kurze direkt anliegende Sprint betrachtet werden. Die fraglichen Aufgaben sind »kleinteilig« und durch die vorangehenden Sprints in der Regel relativ gut gedanklich vorbereitet.

  • Die Schätzung erfolgt durch das Team per »Planning Poker« (s. Abschnitt 3.5). Auch diese Technik stammt ursprünglich aus XP. Die Schätzungen der einzelnen Teammitglieder können untereinander stark variieren. Aber im Mittel erhält man erstaunlich zutreffende Gesamtschätzungen.

  Timeboxing wird in Scrum nicht nur auf Ebene der Sprints angewendet, sondern in vielen Situationen, wo es darum geht, »fertig« zu werden. So ist Timeboxing ein nützliches Instrument, um z. B. in Meetings einen pünktlichen Beginn und strikte Einhaltung des geplanten Endezeitpunkts durchzusetzen und zur Meetingkultur zu machen.

• Transparenz:

  Das vielleicht mächtigste Werkzeug in Scrum ist Transparenz. Das Sprint Backlog wird auf einem Whiteboard⁶ öffentlich geführt. Inhalt und Fortschritt des aktuellen Sprints sind so für das gesamte Team, aber auch für das Management und alle anderen Interessierten jederzeit sichtbar. Das Board enthält zeilenweise die Anforderungen und die zugehörigen Entwicklungsaufgaben. Die Spalten bilden den Fortschritt ab (z. B. offen, in Arbeit, erledigt). Der Sprint-Status wird täglich (im »Daily Scrum«, der täglichen Statusrunde des Teams) aktualisiert und abgebildet, indem die Aufgabenkärtchen gemäß ihrem Fortschritt von links nach rechts durch die Spalten des Boards wandern. Abbildung 2–2 zeigt als Beispiel das Whiteboard des TestBench-Teams (vgl. Fallstudie 8.2). Die über das Board im Daily Scrum hergestellte Transparenz hat zwei Effekte: Jeder im Team weiß tagesaktuell, was um ihn herum passiert. Fehler durch »aneinander vorbei arbeiten« werden so von vornherein minimiert. Und jeder sieht die Aufgaben und den Fortschritt des anderen. Das erzeugt einen nicht zu unterschätzenden Erfolgsdruck. Es zwingt, Probleme aus- und anzusprechen⁷. Sind Schwierigkeiten erst einmal angesprochen, wird es auch einfacher, Hilfe und Unterstützung den Teamkollegen anzubieten oder selbst anzunehmen. Andererseits erzeugt das Besprechen der Aufgaben und das Präsentieren der erreichten Ergebnisse täglich viele kleine Erfolgserlebnisse für jeden Einzelnen im Team und für das Team als Ganzes.

  Abb. 2–2Whiteboard des TestBench-Teams

Rollenverteilung im Team

Neben den Projektmanagementinstrumenten sind auch die Rollenverteilung im Team und der Stellenwert des Teams in Scrum im Vergleich zu den klassischen Vorgehensmodellen anders definiert. Scrum unterscheidet begrifflich nur drei Rollen (nach [Schwaber/Beedle 02, Kap. 3]):