Testen in agilen Projekten E-Book

Tilo Linz

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 450

Beschreibung

Mit (agilem) Testen zum Erfolg - Eingeführtes Standardwerk in Neuauflage - Brücke zwischen Test-Welt und agiler Welt - Best Practices, Fallbeispiele, Übungsaufgaben und Self-Assessment-Fragen Softwareentwicklung wird heute mit agilen Methoden durchgeführt. Ob ein Team, eine Softwareabteilung oder ein ganzes Unternehmen agile Entwicklung langfristig erfolgreich realisiert und damit die erhofften Vorteile erzielt, hängt entscheidend vom Softwaretest und der agilen Softwarequalitätssicherung ab. Dieses Buch gibt einen praxisorientierten Überblick über die gängigsten Testmethoden und -praktiken sowie Managementwerkzeuge in agilen Projekten. Softwareentwickler, Projektmanager, Product Owner und Scrum Master erhalten Hinweise und Tipps, wie Qualitätssicherung und Testen dazu beitragen können, das Potenzial agiler Vorgehensweisen voll auszuschöpfen. Professionelle (Certified) Tester und Experten für Softwarequalität erfahren, wie sie erfolgreich in agilen Teams mitarbeiten und ihre spezifische Expertise optimal einbringen können. Aus dem Inhalt: - Agile und klassische Vorgehensmodelle - Produktplanung im agilen Projekt - Unit Tests, Test First - Integrationstests, Continuous Integration - Systemtests, Continuous Testing - Qualitätsmanagement, Qualitätssicherung Mehrere Fallstudien, ein durchgängiges Fallbeispiel sowie Übungsaufgaben und Checkfragen zum Self-Assessment runden den Inhalt ab. Die Codebeispiele stehen auf der Website zum Buch zum Download bereit. Das Buch orientiert sich an den Inhalten der ISTQB®-Lehrpläne zum Certified Tester Agile und eignet sich daher nicht nur bestens zur Prüfungsvorbereitung, sondern dient gleichzeitig als kompaktes Grundlagenwerk zu diesen Themen in der Praxis und an Hochschulen. Die 3. Auflage wurde komplett überarbeitet und ist konform zu den ISTQB®-Lehrplänen zum Certified Tester: - Agile Tester - Agile Technical Tester (ATT) - Agile Test Leadership at Scale (CTAL-ATLaS)

Leseprobe

Tilo Linz ist Vorstand und Mitgründer der imbus AG, einem führenden Lösungsanbieter für Softwaretest und seit mehr als 20 Jahren im Themengebiet Softwarequalitätssicherung und Softwaretest tätig. Als Gründer und Vorsitzender des German Testing Board e. V. und Gründungsmitglied im ISTQB® hat er die Aus- und Weiterbildung in diesem Fachbereich auf nationaler und internationaler Ebene maßgeblich mitgestaltet und vorangebracht. Tilo Linz ist Koautor von »Basiswissen Softwaretest« (dpunkt.verlag), einem der erfolgreichsten und meistgelesenen Fachbücher in diesem Themengebiet.

Die vielfältigen Chancen, aber auch Herausforderungen, die sich aus der Einführung und Anwendung agiler Methoden ergeben, kennt und erlebt er täglich aus nächster Nähe: in Softwareprojekten seiner Kunden, in der imbus-internen TestBench-Produktentwicklung, aber auch außerhalb der Softwareentwicklung, z. B. im imbus-Marketing, wo er ein an Kanban orientiertes agiles Marketing eingeführt hat.

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Tilo Linz

Testen inagilen Projekten

Methoden und Techniken fürSoftwarequalität in der agilen Welt

Aus- und Weiterbildung zum ISTQB® Certified Tester:Agile Tester, Agile Technical Tester, Agile Test Leadership at Scale

3., aktualisierte und überarbeitete Auflage

Tilo Linz

[email protected]

www.softwaretest-knowledge.de

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: inpunkt[w]o, Wilnsdorf (www.inpunktwo.de)

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-961-0

PDF

978-3-98890-022-7

ePub

978-3-98890-023-4

mobi

978-3-98890-024-1

3., aktualisierte und überarbeitete Auflage 2024

Copyright © 2024 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Nach der Erstauflage des Buches im Jahr 2013 und der Aktualisierung in 2016 war es 2023 höchste Zeit für eine umfassende Überarbeitung von »Testen in Scrum-Projekten«. Diese liegt nun mit dieser dritten Auflage vor, mit dem neuen Titel »Testen in agilen Projekten«, da die im Buch behandelten Inhalte für alle Arten von agilen Projekten relevant sind, nicht nur für solche, die streng nach Scrum vorgehen.

Aufgrund der hohen Marktresonanz1 hat das ISTQB® im Laufe der Jahre sein Lehrplanportfolio immer wieder ergänzt. Hierzu gehören auch mehrere Lehrpläne zum Thema »Testen in agilen Projekten«. Diese Inhalte wurden in das Buch integriert, und die dritte Auflage behandelt und erläutert somit die Inhalte folgender ISTQB®-Lehrpläne [URL: ISTQB Syllabus]:

ISTQB® Certified Tester – Foundation Level Extension Syllabus – Agile Tester, Ausgabe EN 2014, DE 2017

ISTQB® Certified Tester – Advanced Level Syllabus – Agile Technical Tester (ATT), Ausgabe EN 2019, DE 2019

ISTQB® Certified Tester – Advanced Level Syllabus – Agile Test Leadership at Scale (CTAL-ATLaS), Ausgabe EN 2023

Damit deckt das Buch auch die Inhalte zum Thema »Agiles Testen« des folgenden neuen ISTQB®-Syllabus ab:

ISTQB® Certified Tester Foundation Level Syllabus, v4.0, EN/DE 2023

Diese stark überarbeitete neue Fassung des Certified Tester – Foundation Level Syllabus wurde durch das ISTQB® Anfang 2023 herausgegeben, wobei verschiedene Inhalte, die zuvor nur im Foundation Level Extension Syllabus – Agile Tester enthalten waren, integriert wurden.

Detaillierte Cross-Referenzen zwischen den Lernzielen dieser Lehrpläne und den Abschnitten des Buches sind in Anhang A aufgelistet.

In der dritten Auflage wurden gegenüber der zweiten Auflage Erläuterungen zu folgenden Themen ergänzt oder erweitert:

In

Kapitel 2

wurden die Änderungen des Scrum Guide 2020 eingearbeitet und ein zusätzlicher Abschnitt zu »Agile Scaling« ergänzt.

In

Kapitel 3

wurden die bisherigen Erläuterungen zu »User Stories« um einen neuen Abschnitt zu »agiles Requirements Engineering« erweitert. Die Erläuterungen zu den »Akzeptanzkriterien« wurden klarer gefasst und Erklärungen zu den in den ISTQB-Syllabi erwähnten agilen Requirements-Engineering-Techniken ergänzt.

In

Kapitel 4

wurden die Erläuterungen zu den Abschnitten »Service-Virtualisierung«, »Qualitätskriterien für Unit Tests« und »Technische Schulden« ergänzt.

In

Kapitel 5

wurden die Erklärungen zu »Continuous Integration« aktualisiert und Erläuterungen zur Nutzung virtueller Maschinen und Container (Virtualisierung) ergänzt.

In

Kapitel 6

wurde der Zusammenhang zwischen User Stories und Akzeptanzkriterien (aus

Kapitel 3

) mit Akzeptanztests und abnahmetestgetriebener Entwicklung (

Abschnitt 6.3

) nochmals geschärft. Die Erläuterungen zu »Exploratives Testen«, »Continuous Testing«, »Continuous Integration«, »Continuous Delivery« und »Continuous Deployment« wurden präzisiert oder erweitert, und neu aufgenommen wurde ein Abschnitt zum Thema »DevOps«.

In

Kapitel 7

wurden die Erklärungen zu den Ursachen und Auswirkungen der Veränderungen (z. B. neue Rollenmodelle wie »Quality Assistance«), die mit der weiter zunehmenden Agilisierung (Agile Scaling, Value-Driven Organizations & Business-Agility) von immer mehr Bereichen in den Unternehmen einhergehen, erweitert.

Kapitel 8

wurde um eine neue

Fallstudie 8.1

ergänzt, die den Einsatz fortgeschrittener Tools zur automatisierten Codeanalyse vorstellt. Die

Fallstudie 8.3

»Systemtest nonstop« wurde aktualisiert. Die anderen Fallstudien sind unverändert enthalten, da sie nach wie vor lehrreich sind.

Viele Aspekte, die beim Testen in agilen Projekten eine Rolle spielen, werden in diesem Buch umfassender und über die genannten ISTQB®-Lehrpläne hinausgehend behandelt. Hierzu gehören insbesondere die Erläuterungen zum Unit Test (Kap. 4) und Integrationstest (Kap. 5) sowie die Gegenüberstellung der Qualitätsmanagementansätze in klassischen vs. agilen Projekten (Kap. 7).

Natürlich wurde die Neuauflage auch genutzt, um Fehler, Unklarheiten oder Ungenauigkeiten (soweit bekannt) zu korrigieren. Das Quellenverzeichnis wurde um weitere Bücher und Internetseiten ergänzt bzw. Quellenangaben und Links aktualisiert. Vielen Dank an die Leserinnen und Leser, die mir hierzu Informationen und Anregungen mitgeteilt haben.

Ich wünsche allen Leserinnen und Lesern2 gutes Gelingen bei der Umsetzung der agilen Testansätze in ihrer Praxis und – sollte das Buch als Baustein zur Vorbereitung auf die Zertifizierung genutzt werden – viel Erfolg bei der Prüfung!

Tilo Linz

Möhrendorf, September 2023

Danksagung

Auch wenn nur ein Autor auf dem Cover genannt ist – ohne den Rat und die Unterstützung vieler Fachkolleginnen und Fachkollegen wäre dieses Buch nicht möglich gewesen.

Bedanken möchte ich mich an dieser Stelle bei den Autorinnen und Autoren und interviewten Personen der Fallstudien3: Dr. Stephan Albrecht/Avid GmbH, Dierk Engelhardt und Joachim Hofer/imbus AG, Andrea Heck/Siemens AG, Eric Hentschel/ImmobilienScout24, Sabine Herrmann/zooplus AG, Terry Zuo/General Electric Oil & Gas sowie Elmar Jürgens und Sven Amann/CQSE. In den interessanten Unterhaltungen und Diskussionen mit ihnen konnte ich von ihren umfangreichen Praxiserfahrungen in der agilen Entwicklung und im Einsatz von Scrum profitieren, was maßgeblich zum Buch beigetragen hat.

Mein Dank gilt nach wie vor den fachlichen Reviewern der ersten und zweiten Auflage für ihre wertvollen Anregungen, Kommentare und Korrekturen: Oliver Gradl/Siemens AG für seinen Input über agile Integrations- und Systemtests, Dr. Stefan Kriebel/BMW AG und Horst Pohlmann für ihr Feedback aus dem Blickwinkel »Embedded Systems«, Stefan Schmitz/iq-stz für seine fundierten Anmerkungen zum Thema ISO 9000 und Auditierung, Uwe Vigenschow/oose Innovative Informatik GmbH für die fruchtbare Diskussion über Akzeptanztests, Prof. Mario Winter/Fachhochschule Köln, der trotz parallelem eigenem Buchprojekt als Reviewer mitgewirkt und wichtige Hinweise zum Kapitel Integrationstest beigesteuert hat, und den anonymen Reviewern.

Nicht zuletzt danke ich allen Kolleginnen und Kollegen sowie Mitarbeitenden meiner Firma imbus AG, die mir wertvolle Tipps und Hinweise sowie fundierte Antworten zu jeder meiner Rückfragen gaben, insbesondere Arne Becher, Dr. Christian Brandes, Thomas Roßner und Carola Wittigschlager. Herzlichen Dank auch an Claudia Wissner, ohne deren Beitrag viele der Abbildungen im Buch im Stadium von Skizzen stecken geblieben wären. Für Review und Feedback zu den geänderten Passagen dieser dritten Auflage geht mein herzlicher Dank an Arne Becher, Michael Heller und Thomas Schulte sowie an Frank Schmeißner für den Input zur Verbreitung agiler Methoden in der Praxis und an Violeta Popova für die Reinzeichnung der neuer Abbildungen. Besten Dank euch allen für die wertvolle Unterstützung und die geopferte Zeit.

Dem dpunkt.verlag und hier besonders Christa Preisendanz gilt mein Dank für die tatkräftige Unterstützung bei der Erstellung des Buches und die Geduld, auch wenn die Fertigstellung (wieder) einige »Sprints« länger gedauert hat als geplant.

Und ein ganz großes Dankeschön geht an meine Frau Sabine und meine Kinder Lisa und Lena, die während der Erstellungsphasen der verschiedenen Auflagen viele Wochenenden und Abende auf mich verzichten mussten.

Inhaltsübersicht

1Einleitung

2Agile und klassische Vorgehensmodelle

3Produktplanung im agilen Projekt

4Unit Tests und Test First

5Integrationstests und Continuous Integration

6Systemtests und Continuous Testing

7Qualitätsmanagement und Qualitätssicherung

8Fallstudien

Anhang

ACross-Referenz zu den ISTQB®-Lehrplänen

BGlossar

CQuellenverzeichnis

Index

Inhaltsverzeichnis

1Einleitung

1.1Zielgruppen

1.2Zum Inhalt

1.3Fallbeispiel

1.4Webseite

2Agile und klassische Vorgehensmodelle

2.1Scrum

2.2Kanban

2.3Klassische Vorgehensmodelle

2.4Gegenüberstellung der Modelle

2.5Agile Skalierung

2.6Checkfragen und Übungen

2.6.1Self-Assessment

2.6.2Methoden und Techniken

2.6.3Weiterführende Übungen

3Produktplanung im agilen Projekt

3.1Produktvision

3.2Architekturvision

3.3Product Backlog

3.4Agiles Requirements Engineering

3.5User Story Map

3.6Sprint Backlog

3.7Team Charta

3.8Testplanung und Testmanagement

3.8.1Klassische Aufgaben

3.8.2Testmanagement in Scrum

3.8.3Teststufen, Testpyramide, Testquadranten

3.8.4Agile Testpraktiken

3.8.5Zielbild für agiles Testen

3.9Agiles Planen einführen

3.10Checkfragen und Übungen

3.10.1Self-Assessment

3.10.2Methoden und Techniken

3.10.3Weiterführende Übungen

4Unit Tests und Test First

4.1Unit Tests

4.1.1Klassen und Objekte

4.1.2Test der Methoden einer Klasse

4.1.3Test der Objektzustände

4.1.4Zustandsbezogene Coverage-Kriterien

4.1.5Test mittels Methodenpermutation

4.2Test First

4.2.1Test First und Scrum

4.2.2Test First einführen

4.2.3Test First anwenden

4.3Unit-Test-Frameworks

4.4Stubs, Mocks und Dummies

4.5Testmanagement im Unit Test

4.5.1Unit-Test-Planung

4.6Checkfragen und Übungen

4.6.1Self-Assessment

4.6.2Methoden und Techniken

4.6.3Weiterführende Übungen

5Integrationstests und Continuous Integration

5.1Integrationstests

5.1.1Typische Integrationsfehler und Ursachen

5.1.2Integrationstestfälle entwerfen

5.1.3Abgrenzung zu Unit Tests

5.2Einfluss der Systemarchitektur

5.2.1Abhängigkeiten und Schnittstellen

5.2.2Testbarkeit und Testaufwand

5.3Integrationsstufen

5.3.1Klassenintegration

5.3.2Teilsystemintegration

5.3.3Systemintegration

5.4Klassische Integrationsstrategien

5.5Continuous Integration

5.5.1Der CI-Prozess

5.5.2CI einführen

5.5.3Continuous Integration optimieren

5.6Testmanagement im Integrationstest

5.7Checkfragen und Übungen

5.7.1Self-Assessment

5.7.2Methoden und Techniken

5.7.3Weiterführende Übungen

6Systemtests und Continuous Testing

6.1Systemtests

6.2Systemtestumgebung

6.3Manuelle Systemtests

6.3.1Exploratives Testen

6.3.2Sitzungsbasiertes Testen

6.3.3Abnahmetests

6.4Automatisierte Systemtests

6.4.1Capture and Replay

6.4.2Daten- und schlüsselwortgetriebener Test

6.4.3Behavior-Driven Testing

6.5Test First im Systemtest

6.5.1Systemtest-Repository

6.5.2Pairing

6.6Nicht funktionale Tests

6.7Automatisierte Abnahmetests

6.8Systemtests – wann?

6.8.1Systemtests im »letzten« Sprint

6.8.2Systemtests am Sprint-Ende

6.8.3Continuous Testing

6.9Sprint-Release und Deployment

6.10Zielbild DevOps

6.11Testmanagement im Systemtest

6.12Checkfragen und Übungen

6.12.1Self-Assessment

6.12.2Methoden und Techniken

6.12.3Weiterführende Übungen

7Qualitätsmanagement und Qualitätssicherung

7.1Qualitätsmanagement klassisch

7.1.1Aufbau nach ISO 9000

7.1.2Wirkungsprinzip nach PDCA

7.1.3Stärken und Schwächen

7.1.4Prozessmodellierung und Softwareentwicklung

7.2Qualitätsmanagement agil

7.2.1Dokumentation im Qualitätsmanagement vereinfachen

7.2.2Qualitätsmanagement-Kultur verändern

7.2.3Retrospektive und Prozessverbesserung

7.2.4Systemisches Denken und Ursachenanalyse

7.3Umgang mit Compliance-Anforderungen

7.3.1Anforderungen an den Softwareentwicklungsprozess

7.3.2Anforderungen an die Rückverfolgbarkeit

7.3.3Anforderungen an Produkteigenschaften

7.4Qualitätssicherung klassisch

7.4.1Instrumente

7.4.2Organisation

7.5Qualitätssicherung agil

7.5.1Wirkungsprinzip und Instrumente

7.5.2Stärken und Schwächen

7.6Testen agil

7.6.1Erfolgsfaktoren für agiles Testen

7.6.2Testplanung in Scrum

7.7Skills, Ausbildung, Werte

7.8Checkfragen und Übungen

7.8.1Self-Assessment

7.8.2Methoden und Techniken

7.8.3Weiterführende Übungen

8Fallstudien

8.1Effektiver und schneller Testen mit Test Intelligence

8.2Scrum in der Entwicklung von Video- und Audiosoftware

8.3Systemtest nonstop – Scrum in der TestBench-Toolentwicklung

8.4Scrum in der Webshop-Entwicklung

8.5Scrum bei ImmobilienScout24

8.6Scrum in der Medizintechnik

8.7Testen mit Scrum bei GE Oil & Gas

Anhang

ACross-Referenz zu den ISTQB®-Lehrplänen

BGlossar

CQuellenverzeichnis

C.1Literatur

C.2Webseiten

C.3Normen

Index

1Einleitung

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 ist es nicht verwunderlich, dass in immer mehr Unternehmen 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 bedeutete oder bedeutet dies den Umstieg von einer bisher praktizierten Entwicklung nach V-Modell auf eine agile Entwicklung nach Scrum1.

Weder die initiale Umstellung auf »agil« noch das dann notwendige nachhaltige agile Arbeiten sind jedoch einfach, insbesondere dann nicht, 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 die agile Entwicklung langfristig erfolgreich beherrscht und damit 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 der 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 weiterhin benötigt werden und wie diese in das agile Vorgehen eingebettet werden.

1.1Zielgruppen

Verstehen, wie Testen in agilen Projekten funktioniert

Das Buch richtet sich zum einen an Personen, die in das Thema agile Entwicklung erst einsteigen, weil sie künftig in einem agilen Projekt arbeiten werden oder weil sie Scrum oder agile Vorgehensweisen 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 Personen, 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ührungsverantwortung erfahren in kompakter Form, wie systematisches, hoch automatisiertes Testen funktioniert und welchen Beitrag Softwaretester in agilen Teams 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 enthält viele praxisorientierte Beispiele und Übungsfragen, sodass es auch als Lehrbuch und zum Selbststudium geeignet ist.

1.2Zum Inhalt

Kapitel 2

Kapitel 2 gibt eine knappe Charakteristik des agilen Projektmanagement-Frameworks Scrum und der aus dem Lean Product Development stammenden und zu Scrum einige Ähnlichkeiten aufweisenden Projektmanagementmethode Kanban. Dabei werden auch die Bezüge zu Extreme Programming (XP), aus dem wichtige agile Entwicklungstechniken stammen, erläutert. Diesen agilen Vorgehensweisen wird das Vorgehen in Projekten, die sich an klassischen Vorgehensmodellen orientieren, gegenübergestellt. Personen, die ihr Projekt oder ihre Unternehmenseinheit auf eine agile Vorgehensweise umstellen oder agiler ausrichten wollen, erhalten hier einen Überblick und einen Eindruck von den organisatorischen Veränderungen, die mit der Einführung agiler Ansätze im Unternehmen, der betroffenen Abteilung und den betroffenen Teams einhergehen.

Kapitel 3

Kapitel 3 zeigt auf, welche leichtgewichtigen Techniken und Instrumente zur Planung und Steuerung der Entwicklungsarbeiten zum Einsatz kommen und wie Produkt- bzw. Kundenanforderungen »agil« ermittelt, überprüft und dokumentiert werden. Denn »agil« zu arbeiten bedeutet keineswegs »planlos« zu arbeiten. Das Kapitel richtet sich an Personen, die neu in das Thema »agile Entwicklung« einsteigen. Die Erläuterungen und Hinweise, welchen Beitrag die jeweiligen Instrumente zur Fehlervermeidung beitragen, sind jedoch auch für die Zielgruppe 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 wenig Erfahrung im Unit Test finden hier Grundlagen zu Techniken und Werkzeugen 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 erläutert.

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 zur Softwareintegration und zu 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 befasst sich mit Systemtests und »Continuous Testing«. Aufbauend auf den Grundlagen zu Systemtests werden wichtige Techniken für manuelle und automatisierte System- und Akzeptanztests im agilen Umfeld erläutert. Anschließend wird gezeigt, wie auch Systemtests effizient automatisiert und in den Continuous-Integration-Prozess des Teams eingebunden werden können. Kapitel 6 richtet sich dabei nicht nur an Systemtester und Fachtester, sondern auch an 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. Die Leserinnen und Leser erhalten Hinweise und Tipps, wie Qualitätsmanagement »agiler« realisiert werden kann und wie QS- und Testexperten ihr Know-how in agile Projekte einbringen und so einen wertvollen Beitrag für ein agiles Team leisten können. Auch wie sich Agile Scaling und DevOps auf das Qualitätsmanagement auswirken, wird diskutiert.

Kapitel 8

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

Kapitelstruktur

Die Kapitel 2, 3, 7 und 8 behandeln Prozess- und Managementthemen und richten sich daher an Personen, die an Managementaspekten interessiert sind. Die Kapitel 4, 5 und 6 erörtern das (automatisierte) »agile Testen« auf den verschiedenen Teststufen und sprechen (auch) technisch interessierte Personen an. Dabei wird ausführlich auf die Ziele und Unterschiede von Unit Tests, Integrations- und Systemtests eingegangen. 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–1Kapitelstruktur

Cross-Referenz zu den ISTQB®-Lehrplänen

Das Buch deckt den Stoff folgender ISTQB®-Lehrpläne ab:

ISTQB

®

Certified Tester – Foundation Level Extension Syllabus Agile Tester

, EN 2014, DE 2017,

ISTQB

®

Certified Tester – Advanced Level Syllabus – Agile Technical Tester (ATT)

, EN 2019, DE 2019,

ISTQB

®

Certified Tester – Advanced Level Syllabus – Agile Test Leadership at Scale (CTAL-ATLaS)

, EN 2023 sowie

die agiles Testen betreffenden Inhalte im

ISTQB

®

Certified Tester – Foundation Level Syllabus, v4.0

, EN/DE 2023.

Die Gliederung des Buches folgt jedoch nicht der Gliederung der Lehrpläne. Darüber hinaus werden verschiedene Aspekte, die beim Testen in agilen Projekten eine Rolle spielen, im Buch über die Lehrplaninhalte hinausgehend oder zusätzlich behandelt.

In Anhang A sind daher Cross-Referenz-Tabellen enthalten, mittels derer diejenigen Buchabschnitte, die den Inhalt der in den betreffenden Lehrplänen jeweils genannten Lernziele erläutern, gezielt nachgeschlagen werden können.

Fallbeispiel, Checkfragen und Übungen

Viele, wenn nicht sogar 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 in den folgenden Kapiteln werden 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 um praktisch nachvollziehbar und »erlebbar« zu machen, wo die Herausforderungen liegen, finden sich im Text die folgenden Elemente:

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

Checkfragen und Übungen, anhand derer die Leserinnen und Leser am Ende eines Kapitels die besprochenen Inhalte rekapitulieren, aber auch ihre Situation und ihr Agieren im eigenen Projekt kritisch hinterfragen können.

1.3Fallbeispiel

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 in einem harten Wettbewerb mit einer Vielzahl von Anbietern. Um in diesem Wettbewerb bestehen zu können, 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 die Kunden dieser Hersteller z. B. beim Ausbau ihrer Systeme für die eigenen 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 einzubinden.

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.4Webseite

Die im Buch enthaltenen Codebeispiele sind auf der Webseite zum Buch unter [URL: SWT-knowledge] veröffentlicht und herunterladbar. Die Leserinnen und Leser können diese Beispiele so auf ihrem eigenen Rechner nachvollziehen und mit eigenen Testfällen experimentieren. Auch die Übungsfragen sind dort zu finden.

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

2Agile und klassische Vorgehensmodelle

Dieses Kapitel gibt eine knappe Charakteristik des agilen Projektmanagement-Frameworks Scrum und der aus dem Lean Product Development stammenden und zu Scrum einige Ähnlichkeiten aufweisenden Projektmanagementmethode Kanban. Dabei werden auch die Bezüge zu Extreme Programming (XP), aus dem wichtige agile Entwicklungstechniken stammen, erläutert. Diesen agilen Vorgehensweisen wird das Vorgehen in Projekten, die sich an klassischen Vorgehensmodellen orientieren, gegenübergestellt.

Leserinnen und Leser, die ihr Projekt oder ihre Unternehmenseinheit auf eine agile Vorgehensweise umstellen oder agiler ausrichten 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.

2.1Scrum

Scrum ist ein agiles1 Projektmanagement-Framework, 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 und Extreme Programming (XP)

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)2 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 Scrum3 dafür sind:

Kurze Iterationen:

Scrum gliedert ein Projekt in kurze Iterationen fester Länge. Eine solche Iteration heißt in Scrum »Sprint«4. 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 Refinement« oder »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 dafür zu erledigen sind. 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. Diese »Fertig«-Kriterien werden als »Definition of Done« des Teams (DoD) bezeichnet (vgl. [URL: Scrum Guide]). Sie können global als Checkliste für alle Aufgaben des Sprints formuliert werden oder auch spezifisch für einzelne Aufgaben. 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.6

). 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 Whiteboard5 ö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.3). 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 anzusprechen6. 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

Rollen im Scrum-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. Diese bilden zusammen das Scrum-Team7:

Beim

Scrum Master

handelt es sich um eine durch Scrum neu eingeführte Managementrolle. Er ist verantwortlich, dass die Scrum-Praktiken umgesetzt und durchgesetzt werden. Wenn sie verletzt oder überdehnt werden oder andere praktische Hindernisse (engl. Impediments) auftreten, ist es Aufgabe des Scrum Masters, dies abzustellen bzw. eine Lösung herbeizuführen. Der Scrum Master hat allerdings keine (disziplinarische) Teamleitungsfunktion, sondern er agiert als Coach. Bei Prozessfragen kann die Lösung darin bestehen, dem Team das »richtige« Vorgehen zu erklären oder wieder in Erinnerung zu rufen oder einen Workshop zur Lösungsfindung zu organisieren. Bei anderen »Impediments«, wie z. B. einer schlecht funktionierenden Build-Umgebung, kann es nötig sein, in der Organisation zusätzliche Ressourcen zu organisieren, z. B. einen schnelleren Build-Server oder ein besseres Tool. Es kann auch bedeuten, dafür zu sorgen, dass sich künftig kompetentere Leute um Builds kümmern als bisher. Was der Scrum Master nicht tun darf, ist, das Problem ungelöst an das Team zurück delegieren. Wo das (zu oft) passiert, ist die Lösung ein besserer Scrum Master.

Der

Product Owner

ist die Person, die das Product Backlog verantwortet und führt. Er agiert gegenüber dem Team als Vertreter des oder der Kunden

8

. Der Product Owner trifft die Entscheidungen darüber, welche Features umgesetzt werden. Er verantwortet die Produkteigenschaften! Die Rolle wird in der Praxis unterschiedlich besetzt, z. B. durch den bisherigen Produktmanager, einen bisherigen Teamleiter oder Projektleiter

9

. Aber er ist nicht der (disziplinarische) Leiter des Teams und er verantwortet auch den Scrum-Prozess nicht. Letzteres ist Aufgabe des Scrum Masters, seines Counterparts.

Das

Entwicklungsteam

10

umfasst meist fünf bis neun Personen im Projekt, die das Produkt realisieren. Sie erledigen gemeinsam Sprint für Sprint alle nötigen Aufgaben, um die Anforderungen und das Produkt zu erstellen. »Ein Scrum-[Entwicklungs-]Team sollte Personen mit allen Fähigkeiten, die zur Erreichung des Sprint-Ziels notwendig sind, umfassen. Scrum vermeidet vertikal organisierte Teams aus Analysten, Designern, Qualitätssicherungsspezialisten und Programmierern. Ein Scrum-[Entwicklungs-]Team organisiert sich so, dass jedes Teammitglied zum Ergebnis gleichermaßen beiträgt. Dabei steuert jedes Teammitglied seine spezielle Expertise bei, zu allen anliegenden Aufgaben. Die dadurch entstehende Synergie in der Zusammenarbeit eines Testers, der einem Designer hilft, Programmcode zu entwerfen, verbessert die Codequalität und steigert die Produktivität. Ungeachtet der Teamzusammensetzung ist das [Entwicklungs-]Team als Ganzes für alle Arbeitsschritte verantwortlich: von der Analyse, dem Design, der Codierung über das Testen bis zur Erstellung der Anwenderdokumentation« (nach [

Schwaber & Beedle 02

]).

Interdisziplinäres Team

Die Mitglieder des Scrum-Teams sollen interdisziplinär11 zusammenarbeiten. »Interdisziplinär« bedeutet, dass die Personen funktionsübergreifend arbeiten: Architekt und Programmierer erarbeiten eine Architektur. Anschließend hilft der Architekt dem Programmierer bei der Codierung und lernt dabei z. B., dass sein theoretisch schönes Konstrukt leider sehr umständlich umzusetzen ist. Der Tester hilft dem Programmierer beim Finden guter Unit Tests. Und der Programmierer automatisiert sie und bringt das auch dem Tester bei. Es bedeutet nicht, dass jeder alles gleich gut können muss, sondern dass jeder grundsätzlich bereit ist, an jeder Aufgabe mitzuwirken, seinen Fähigkeiten und Erfahrungen gemäß. Es geht um die Fähigkeiten und die Performance des Teams als Ganzes. Es bedeutet insbesondere nicht, dass niemand im Team Spezialqualifikationen besitzt, mitbringt und einbringt! Das Gegenteil ist der Fall: Der Architekt hat eine Ausbildung als Softwarearchitekt, der Programmierer kann routiniert und sicher programmieren und der Tester ist z. B. Certified Tester. Und je nach aktueller Aufgabe geht einmal der eine und ein andermal der andere führend voran. Aber keiner wird sagen können: »Ich bin Architekt« oder »Ich bin Tester« – »Mit anderen Sachen habe ich nichts zu tun«. Die Fallstudien 8.2 und 8.5 illustrieren einige dieser Stolpersteine, die in der Phase des Umstiegs auf Scrum zu berücksichtigen sind.

Fallbeispiel eHome-Controller 2–1:Projekt-Setup

Nach der Entscheidung, das Projekt zu starten, gibt die Geschäftsleitung das Personalbudget für drei Entwickler, einen Testingenieur, einen Product Owner und einen Teilzeit-Scrum-Master frei.

Bei der Frage, welche Mitarbeiter in das Team kommen sollen und für welche Rolle, gibt es die unterschiedlichsten Ansichten: »unsere Besten«, »die Erfahrensten«, »neue Leute mit neuen Ideen«. Aber auch unter den Mitarbeitern der bisherigen Teams wird die Einführung von Scrum kontrovers diskutiert: »Das wurde ja Zeit«, »Alter Wein in neuen Schläuchen«, »In unserem Team arbeiten wir längst agil«, »Unsere Systeme müssen jeden Tag rund um die Uhr funktionieren. Bei den Busprotokollen müssen wir vorgegebene Normen und Standards bitgenau einhalten. Wie soll das gehen, ohne Dokumente und Spezifikationen?« Aussagen wie diese stehen stellvertretend für die unterschiedlichen Positionen.

Bei der Besetzung der Rollen geben letztlich Know-how und Verfügbarkeit von Mitarbeitern den Ausschlag: Klar ist, dass einer der Entwickler Know-how auf der Ebene der Busprotokolle und der Gerätehardware (sowohl der firmeneigenen Geräte als auch der wichtigsten Wettbewerbsprodukte) besitzen muss. Dieses Know-how hat man »im Haus«. Die Bedienoberfläche soll ein kreativer Webentwickler übernehmen. Die Stelle wird neu ausgeschrieben. Neuer Product Owner wird der Teamleiter des bisherigen Softwareteams.

Da man noch keinerlei praktische Erfahrung mit Scrum besitzt, wird ein externer Berater als Scrum Master engagiert. Dieser soll dem Team möglichst schnell alle nötigen Scrum-Techniken und Fähigkeiten beibringen, für Fragen zur Verfügung stehen und Geschäftsleitung und Team davor bewahren, unbewusst in alte Verhaltensmuster zurückzufallen.

Das Budget wird für zunächst 12 Monate bereitgestellt. Auf Wunsch der Marketingabteilung werden vom Team vier externe Releases erwartet – Release 1 in drei Monaten!

Feature-Teams

Bei größeren, komplexen Produkten muss die Arbeit auf mehrere Scrum-Teams verteilt werden. Das kann entlang der Systemarchitektur passieren. Man hat dann komponentenorientiert arbeitende Teams. Ein anderes Modell sind sogenannte »Feature-Teams«. Ein Feature-Team setzt über ein oder mehrere Sprints hinweg eine Gruppe von Anforderungen um und arbeitet dabei an allen betroffenen Systemkomponenten (»Global Code Ownership«). Die Fallstudie 8.6 »Scrum in der Medizintechnik« stellt ein Projekt vor, das diese Vorgehensweise verfolgt.

Der (theoretische) Vorteil ist, dass das Feature-Team die Anforderungen als Ganzes im Blick hat und daher kundengerechter umsetzt. Der (theoretische) Nachteil besteht darin, dass ein Feature-Team nicht die Tiefe im Verständnis jeder betroffenen Softwarekomponente besitzt, die ein Komponententeam erreichen kann oder besitzt, und deshalb langsamer oder fehlerhafter entwirft, codiert und testet. Welches Modell in der Praxis das richtige ist, muss jede Organisation individuell für sich abwägen, beobachten und lernen.

2.2Kanban

Projekt- und Change-Management-Methode

Kanban (jap. Signalkarte) bezeichnet einen Managementansatz aus dem Lean Product Development, der einige Gemeinsamkeiten mit Scrum aufweist. Erstmals beschrieben wird (Software-)Kanban als Projekt- und Change-Management-Methode für IT-Projekte in [Anderson 11]. Die Ideen gehen zurück auf Prinzipien und Erfahrungen des Lean Management [URL: Lean]. Das Ziel ist, den »Fluss« zu bearbeitender Produkte durch die Fertigung zu optimieren. Oder allgemeiner: den »Fluss« von Aufgaben (Tasks) durch eine Wertschöpfungskette. Kanban verwendet dazu im Wesentlichen zwei Instrumente:

Kanban-Board:

Die zu steuernde Wertschöpfungskette wird auf einem sogenannten Kanban-Board visualisiert. Die »Bearbeitungsstationen« bzw. Prozessschritte werden als Spalten dargestellt. Die zu erledigenden Aufgaben (Tasks) werden durch Karten (Tickets) symbolisiert, die auf dem Board von links nach rechts wandern.

WIP-Limit:

Die Menge der gleichzeitig zu erledigenden Aufgaben (Work-in-Progress, WIP) wird limitiert. Dies geschieht durch Limits für die Anzahl der Tickets, die je Bearbeitungsstation und/oder im gesamten Board erlaubt sind. Hat eine Bearbeitungsstation freie Kapazität, dann »zieht« sich diese Station ein neues Ticket von ihrer Vorgängerstation (»Pull«- statt »Push«-Prinzip).

Dieses Vorgehen ist Scrum sehr ähnlich. In beiden Ansätzen sorgt die Visualisierung am Whiteboard für hohe Transparenz über Inhalt und Bearbeitungsstand aller Aufgaben. Aktuell nicht in Bearbeitung befindliche Aufgaben werden in einer vorgeschalteten Auftragsliste (Backlog) gesammelt. Aus dieser werden Aufgaben ausgewählt und auf das Whiteboard übertragen, sobald dort Platz (d. h. Kapazität) frei wird.

Kanban kennt weder Iterationen noch Sprints.

Im Gegensatz zu Scrum kennt Kanban jedoch keine Iterationen oder Sprints. Denn Kanban zielt darauf ab, kontinuierlich möglichst viele Aufgaben mit (im Mittel) minimalen Durchlaufzeiten zu erledigen. Also einen stetigen hohen Aufgabendurchsatz (Flow) zu erreichen und aufrechtzuerhalten. Ein Kanban-Prozess liefert Einzelergebnisse (Deliverables), die zusammengenommen kein »Release« ergeben müssen. Jedes Deliverable ist unabhängig vom »Rest« auslieferbar und verwertbar. Timeboxing als Synchronisationsmechanismus und die für Timeboxing nötige Aufwandsschätzung entfallen deshalb in Kanban. Scrum hingegen zielt darauf ab, Arbeitsergebnisse in einem fest getakteten Rhythmus zu liefern. Das Sprint-Ende »synchronisiert« dabei alle abgearbeiteten Tasks und liefert dann ein einziges resultierendes Gesamtergebnis: das lieferfähige Release (»Potentially Shippable Product«).

Scrum vs. Kanban

Wenn es wie in der Softwareentwicklung darauf ankommt, Releases auszuliefern, ist daher Scrum das geeignete Projektmanagement-Framework. Wenn es darum geht, voneinander unabhängige Einzelaufgaben durchsatzoptimiert zu steuern, dann bietet sich Kanban als Methode an.

Ein Einsatzbeispiel von Kanban im IT-Umfeld ist die Steuerung eines Supportteams, wobei jede Einzelaufgabe einem Supportauftrag (Ticket) entspricht. Ein anderes Beispiel ist die Steuerung eines Maintenance-Teams (s. [Anderson 11]). Das Maintenance-Team erstellt Software-Patches. Ziel ist, jeden Patch schnellstens zu erstellen und so frühzeitig wie möglich dem Kunden bereitzustellen. Da jeder Patch als unabhängiger Ein-Personen-Programmierauftrag isoliert bearbeitet werden kann, ist Kanban hier die passende Managementmethode.

Fallbeispiel eHome-Controller 2–2:Adapter-Entwicklung per Kanban

Der als Scrum Master bestellte externe Berater lädt die Mitglieder des neuen Scrum-Teams, aber auch alle anderen Hard- und Softwareentwickler sowie das Supportteam zu einer Informationsveranstaltung ein. Ziel ist, über das neue Vorgehen zu informieren und so Fehlinformationen oder Missinterpretationen entgegenzutreten. Der Berater gibt eine Einführung in Scrum und stellt zum Vergleich auch Kanban kurz vor.

Daraus entwickelt sich eine Diskussion, ob es nicht besser wäre, Kanban statt Scrum anzuwenden, oder ob Kanban für andere Teams geeignet wäre. Es kristallisiert sich heraus, dass das Supportteam gesteuert durch sein Support-Ticket-System schon heute einige Elemente aus Kanban zur Arbeitssteuerung nutzt. Von der Adaption weiterer Kanban-Elemente, wie z. B. WIP-Limits, könnte es aber profitieren.

Man überlegt, ob sich die Entwicklung von Busadaptern eventuell per Kanban besser steuern lässt als mit Scrum. Denn ein Adapter kann erfahrungsgemäß »isoliert« entwickelt werden. Es gibt dabei keine Abhängigkeiten zu anderen Adaptern und nur selten Rückwirkungen auf das Gesamtsystem. Ein überarbeiteter oder neuer Adapter kann im Prinzip zu jedem beliebigen Zeitpunkt in das System aufgenommen werden. Die Adapter-Entwicklung muss also nicht unbedingt mit einem festen Sprint-Rhythmus synchron laufen. Man einigt sich daher darauf, Kanban genauer zu betrachten, sobald das Thema Adapter-Entwicklung im Product Backlog erstmals an die Reihe kommt.

2.3Klassische Vorgehensmodelle

Klassische Vorgehensmodelle unterteilen ein Projekt in Phasen, die jeweils bestimmte Zwischenergebnisse (Meilensteine) produzieren, und definieren Rollen, denen bestimmte Aufgaben im Projekt zugeordnet werden und die von den im Projekt mitwirkenden Personen auszufüllen sind.

Phasen als Abstraktionsebenen

Die Projektphasen beschreiben dabei aber nicht nur zeitliche Abschnitte des Projektverlaufs, sondern sie definieren unterschiedliche Abstraktionsebenen, auf denen das zu entwickelnde System jeweils betrachtet wird. Besonders deutlich wird dies im V-Modell12:

Abb. 2–3Abstraktionsebenen und Teststufen im V-Modell

Phasen vs. Sprints

»Der linke Ast steht für die immer detaillierter werdenden Entwicklungsschritte, in deren Verlauf das gewünschte System schrittweise entworfen und schließlich programmiert wird. Der rechte Ast steht für Integrations- und Testarbeiten, in deren Verlauf elementare Programmbausteine sukzessive zu größeren Teilsystemen zusammengesetzt (integriert) und jeweils auf richtige Funktion geprüft werden. Integration und Test enden mit der Abnahmeprüfung des auf diesem Weg entstandenen Gesamtsystems« [Spillner & Linz 19, Abschnitt 3.1]. Damit verbunden ist die Modellvorstellung, dass als Phasenergebnis jeweils ein Satz von Dokumenten oder Artefakten entsteht, die das System auf der jeweiligen Abstraktionsebene vollständig beschreiben. Als Konsequenz wird die Softwareentwicklung als vorwiegend dokumentbasiertes Arbeiten verstanden.

Die Arbeitsweise in Scrum ist eine andere. Das System wird in jedem Sprint auf all seinen Abstraktionsebenen simultan betrachtet und inkrementell fortentwickelt: Die Anforderungen werden ergänzt, die Architektur wird verbessert, der Code wird erweitert und die Tests werden ergänzt. Für zeitlich kurze Iterationen wird der Umfang der Dokumente stark reduziert und das dokumentbasierte Arbeiten tritt zugunsten direkter Kommunikation und Diskussion zwischen allen Beteiligten in den Hintergrund.

Projektmanagement und Planung

Klassisches Projektmanagement versucht ein Projekt in allen relevanten Aspekten (inhaltliche Arbeitspakete, Zeitbedarf, Kosten und Ressourcenbedarf) möglichst exakt und vollständig vorauszuplanen und die Projektdurchführung dann so zu steuern, dass dieser Plan bestmöglich eingehalten wird: vom Projektstart bis zum Projektabschluss.

Basierend auf der durch das Vorgehensmodell gegebenen Projektstruktur erstellt der Projektmanager am Projektbeginn seinen Projektplan. In diesem listet er möglichst alle Projektaufgaben auf und bringt diese unter Beachtung gegenseitiger Abhängigkeiten in eine bestimmte sinnvolle zeitliche Reihenfolge. Er schätzt vorab den vermeintlichen Projektaufwand ab und plant und allokiert frühzeitig die aus seiner Schätzung oder Sicht heraus nötigen Ressourcen. Wenn der eHome-Controller des Fallbeispiels weiterhin klassisch entwickelt werden würde, könnte der initiale Projektplan etwa wie folgt aussehen:

Fallbeispiel eHome-Controller 2–3:eHome-Controller klassisch geplant

Schwächen des klassischen Planungsansatzes

An diesem Beispielplan lassen sich die Schwächen des klassischen, deterministischen Planungsansatzes gut erkennen:

Über die zeitlich nahen Arbeiten ergibt sich ein relativ klares, detail-reiches Bild. Die frühen Phasen bzw. Arbeitspakete (hier z. B. Initialisierung) werden deshalb, im Vergleich zum Plan insgesamt, oft genauer als notwendig geplant und aufwandseitig übergewichtet.

Die für die Zeitplanung eigentlich notwendige Aufwandsschätzung erfolgt oft nicht ausreichend. Denn viele zur fundierten Aufwandsschätzung nötigen Inputdaten entstehen ja erst im zu planenden Projektverlauf (z. B. Anforderungen an das User Interface und Entscheidungen über die zu unterstützenden Busprotokolle). Deshalb stellt der Plan nicht die »vom Team benötigte« Zeit dar, sondern die »vom Management zur Verfügung gestellte« Zeit und alle Plantermine sind mit hoher Unsicherheit behaftet.

Um die ursprüngliche Vorgabe »Release 1 in 3 Monaten ab Projektstart« nicht völlig zu ignorieren, legt der Projektleiter einen Plan B mit einem ersten Release nach 5 Monaten vor. Sein Kunstgriff dabei ist, die Pufferzeiten rauszurechnen.

Der Inhalt der im Plan aufgelisteten Arbeitspakete ist nicht klar definiert. Im besten Fall haben Projektleiter und Team dieselben Vorstellungen dazu im Kopf. Der Projektleiter muss beim Start der Arbeitspakete dafür sorgen, dass die Bearbeiter und er selbst zu einem gemeinsamen Verständnis der Aufgabenpakete gelangen. Andererseits gibt ihm diese Ungenauigkeit der Arbeitspakete auch den notwendigen Spielraum, um Planabweichungen und Planungsfehler »abzufedern«.

Der Tatsache, dass die vorgesehenen Qualitätssicherungsmaßnahmen sehr wahrscheinlich Mängel und Fehler aufdecken werden, wird über Pufferzeiten für »Rework« Rechnung getragen. Allerdings ist reichlich unklar, ob und warum z. B. zwei Wochen »Rework« eine angemessene Zeitspanne sind. Ist das optimistisch oder pessimistisch geplant? So oder so: »Rework« bezieht sich auf »lokale« Korrekturen des betroffenen Meilensteins. Eine unter Umständen notwendig werdende Überarbeitung von Ergebnissen einer Vorphase ist nicht eingeplant.

Bis zum fundierten Prüfen und Testen und bis zur ersten Auslieferung des Produkts kann eine lange Zeitspanne vergehen. Im Beispiel liegen zwischen dem Abschluss der Designphase und dem Integrationstest, wo das Design einen ersten wirklichen Realitätscheck bestehen muss, 20 bzw. 38 Wochen und die Produktauslieferung ist nach frühestens 5 bzw. 9 Monaten avisiert.

Auch wenn der initiale Projektplan realistisch und fehlerfrei sein sollte, wird jeder Planungsaspekt (Aufgaben, Zeit, Ressourcen) im Projektverlauf Veränderungen unterworfen sein. Jeder noch so sorgfältig erstellte Projektplan ist daher schnell veraltet und muss aufwendig nachjustiert oder umgeplant werden. Klassisches Projektmanagement ist daher (überspitzt ausgedrückt) ein fortwährender Kampf gegen unvorhergesehene, aber unausweichliche Veränderungen, der oft verloren wird.

Auch im Scrum-Projekt kann ein Projektplan erforderlich sein.

Scrum löst dieses Dilemma, indem auf einen solchen Projektplan verzichtet wird und stattdessen die oben beschriebenen agilen Projektmanagementinstrumente zum Einsatz kommen. Aber abhängig vom Projektumfeld kann es Gründe geben, warum auch in einem Scrum-Projekt ein Projektplan erforderlich ist. So kann ein Sprint-übergreifender Meilenstein- oder Zeitplan hilfreich oder notwendig sein zur frühzeitigen oder langfristigen vertraglichen Abstimmung mit Kunden, Lieferanten, Mitarbeitern und ggf. parallel laufenden Projekten. Und wenn Ressourcen beantragt oder beschafft werden müssen, kann es nützlich oder unter Umständen erforderlich sein, genau begründen zu können, wann und warum welche Ressourcen gebraucht werden. Ein schriftlicher Ressourcenplan, der mit einer systematischen Aufwandsschätzung unterlegt ist, hilft dabei.

Den oben genannten Schwächen kann durch iteratives und inkrementelles Entwickeln entgegengewirkt werden. Iterative und inkrementelle Entwicklung sind daher auch im klassischen Vorgehen bekannt und üblich.

Iterative Entwicklung

Iterative Modelle definieren ebenfalls unterschiedliche Projektphasen, sehen aber modellseitig explizit13 vor, dass einzelne Phasen oder Phasensequenzen wiederholt durchlaufen (iteriert) werden. Eine Iteration dient dazu, eventuelle Schwächen oder Fehler im Phasenergebnis beim erneuten Phasendurchlauf zu korrigieren. Oder sie kann dazu dienen, das Phasenergebnis inhaltlich zu erweitern, also ein Produktinkrement zu erstellen. Ein Vertreter dieser Art von Modell ist der »Rational Unified Process« [URL: RUP].

Manchmal wird iteratives Entwickeln fälschlicherweise mit agilem Entwickeln gleichgesetzt. Innerhalb eines Scrum-Sprints kommen Aufgaben (Tasks) jeglichen Typs vor (von »Architektur verbessern« bis »Feature implementieren und testen«). Eine klassische Projektphase »kapselt« hingegen Aufgaben eines ganz bestimmten Aufgabentyps (z. B. »Architektur entwerfen«). Und auch die Forderung, dass jede Iteration (wie ein Sprint in Scrum) ein potenziell auslieferbares Produkt hervorbringt, muss iteratives Entwickeln nicht erfüllen.

Durch die Iteration einer klassischen Projektphase entsteht daher kein Sprint, wie Scrum ihn kennt! Wer iterativ entwickelt und auf Scrum umstellen will, muss diesen elementaren Unterschied verstehen und beachten. Auch eine Iteration in Extreme Programming (XP) ist nicht gleichzusetzen mit einem Sprint in Scrum. Ausgeliefert wird in XP nach einer beliebig festlegbaren Anzahl von Iterationen. Abhängig vom angepeilten Ziel kann ein anderer Aufgabenmix je Iteration anstehen, z. B. die Verbesserung der Architektur (Umbau des Systems durch Refactoring) oder die Ergänzung einer bestimmten Funktionalität (Design und Implementierung neuer Funktionen).

Inkrementelle Entwicklung

Inkrementelle Entwicklung ist das heute dominierende, übliche Verfahren und bedeutet, dass der Kunde oder Anwender das Produkt in wachsenden Ausbaustufen erhält. Oder aus Sicht des Herstellers: dass in gewissen zeitlichen Abständen neue, funktional erweiterte Produktreleases erstellt und ausgeliefert werden. Inkrementelle Entwicklung setzt iteratives Entwickeln voraus, weshalb auch von inkrementell-iterativer Entwicklung gesprochen wird.

Die zeitliche Taktung, in der die Inkremente bzw. Releases entstehen, ist dabei je nach Vorgehensmodell unterschiedlich. Wird nach einem klassischen Modell gearbeitet, dann sind Releases im Bereich halbjährlich, jährlich oder länger üblich bzw. erreichbar. Agile Vorgehensweisen reduzieren die Releasezykluszeit drastisch. In Scrum soll jeder Sprint ein Release liefern, das an den Kunden ausgeliefert werden könnte, wenn dies gewünscht wird. In der Praxis wird zwischen internen (Release Candidates) und extern auszuliefernden Releases unterschieden. Die externe Releasefrequenz vieler Scrum-Projekte ist vierteljährlich bei monatlichen Sprints. Teams, die Continuous Integration (s. Kap. 5) zu Continuous Delivery perfektioniert haben, können eine tägliche Lieferung (Deployment) erreichen. Das setzt voraus, dass das Deployment automatisiert in eine vollständig kontrollierte Produktivumgebung erfolgt. Das ist bei manchen firmeninternen IT-Systemen möglich oder bei Webseiten oder Webshops, die so per »Nightly Deployment« aktuell gehalten werden.

2.4Gegenüberstellung der Modelle

Zur zusammenfassenden Gegenüberstellung der Modelle ist es hilfreich, die Dimensionen Projektmanagement, Personal-/Teamführung, Entwicklungstechniken und Qualitätsmanagement zu unterscheiden.

Abb. 2–4Dimensionen eines Vorgehensmodells

Jedes Modell »kümmert« sich um diese Dimensionen unterschiedlich intensiv und propagiert je Dimension unterschiedliche methodische Ansätze und Philosophien:

Scrum

ist ein empirisch, adaptiver Projektmanagementansatz. Ausführliches Planen wird ersetzt durch die Fähigkeit, schnell, flexibel und angemessen zu reagieren. Bestimmte Entwicklungstechniken werden nicht gefordert. Aber es ist üblich, Techniken aus XP einzusetzen. Qualität entsteht durch fachliches Können und konsequentes Anwenden der vereinbarten Entwicklungstechniken. Das Team arbeitet eigenverantwortlich (im Idealbild ohne fachlich weisungsbefugten Vorgesetzten). Über vorgeschriebene »Routinehandlungen« (wie z. B. Retrospektive) ist ein kontinuierlicher, auf Projektebene laufender Verbesserungsprozess integriert.

Kanban

ist ein Ansatz zur Aufgabensteuerung in dauerhaft organisierten Gruppen oder Abteilungen und nicht primär für die Projektsteuerung gedacht. Arbeitstechniken werden nicht vorgegeben. Das Team arbeitet in einer gemeinsamen Wertschöpfungskette, in der jeder spezialisiert ist auf »seine Arbeitsstation« im Prozess. Qualität entsteht durch fachliches Können und sofortiges Ausmerzen und Korrigieren von Fehlern. Über »Routinehandlungen« (wie z. B. Retrospektive) ist ein kontinuierlicher Verbesserungsprozess integriert.

Klassische Modelle

basieren auf einem deterministisch, vorausplanenden Projektmanagementansatz. Das Team arbeitet auf Weisung des Projektleiters (als fachlichen Vorgesetzten). Der Projektleiter überprüft den Fortschritt und ist für die Einleitung von Korrekturmaßnahmen verantwortlich. Welche Entwicklungstechniken genutzt werden, hängt vom Umfang des zugrunde liegenden Modells ab und von ggf. zu beachtenden firmenspezifischen Prozessvorgaben (Qualitätsmanagementsystem). Ein kontinuierlicher Verbesserungsprozess ist in der Regel vorgesehen und wirkt auf Ebene des Qualitätsmanagementsystems über regelmäßige interne und externe Audits.

Tabelle 2–1 stellt die wichtigsten Unterschiede nochmals gegenüber14.

Tab. 2–1Gegenüberstellung der Modelle

a.Aus XP: »Write all production code with two people sitting at one machine« [Beck & Andres 04, S. 42].

b.Aus XP: »Integrate and test changes after no more than a couple of hours« [Beck & Andres 04, S. 49].

c.Aus XP: »Write a failing automated test before changing any code« [Beck & Andres 04, S. 50].

d.Aus XP: »Invest in the design of the system every day« [Beck & Andres 04, S. 51].

e.»We’ll know how to write good code. And we’ll know how to transform bad code into good code« [Martin 08, S. 2].

f.»For each few lines of code we add, we pause and reflect on the new design. Did we just degrade it? If so we clean it up …« [Martin 08, S. 172].

2.5Agile Skalierung

Die in den vorstehenden Abschnitten vorgestellten agilen Frameworks (XP, Scrum, Kanban) beschreiben Vorgehensweisen für die Durchführung und das Management einzelner Softwareprojekte. Ihre Methoden, Spielregeln und die zugehörigen Rollen wirken und funktionieren auf Projektebene.

Bei der Entwicklung großer Produkte oder mehrerer Produkte (einer Produktfamilie oder Produktlinie) oder in der IT-Organisation größerer Unternehmen besteht jedoch die Notwendigkeit, die Zusammenarbeit dieser parallelen Projekte oder Teilprojekte (die jedes für sich agil arbeiten) zu organisieren und zu koordinieren. Das bedeutet, dass Mechanismen existieren und angewendet werden müssen, mittels derer die Ziele und Inhalte der Einzelprojekte untereinander und hinsichtlich übergeordneter Unternehmensziele ausgerichtet werden können. Und es müssen Mechanismen vorhanden sein und praktiziert werden, um die zeitliche Abfolge und die Rhythmen der Iterationen bzw. Sprints zwischen den parallel laufenden Projekten zu koordinieren. Beides soll die Agilität auf Projektebene nicht behindern.

Ein weiteres Motiv ist, die Zusammenarbeit zwischen agilen Projekten und anderen Unternehmensbereichen (Fachbereichsabteilungen, Marketing, Vertrieb, Unternehmensleitung u. a.) zu verbessern und zu »agilisieren«, was zu dem Wunsch führt, dass auch diese Unternehmenseinheiten in ihren eigenen Abläufen agile Arbeitsweisen einführen und praktizieren.

Da XP, Scrum oder Kanban (in ihrer ursprünglichen Form) hierfür keine Mechanismen kennen, wurden Frameworks zur agilen Skalierung (Agile Scaling Frameworks) entwickelt. Die derzeit populärsten derartigen Frameworks15 mit ihren wichtigsten Kennzeichen nach [Dimoulis & Lammering 23] sind:

Large-Scale Scrum (LeSS):