Testen in Scrum-Projekten. Leitfaden für Softwarequalität in der agilen Welt - Tilo Linz - ebook

Testen in Scrum-Projekten. Leitfaden für Softwarequalität in der agilen Welt ebook

Tilo Linz

0,0

Opis

Softwareentwicklung wird heute mit agilen Methoden durchgeführt. Dass ein Team, eine Softwareabteilung oder ein ganzes Unternehmen agiles Entwickeln langfristig erfolgreich realisiert und damit die erhofften Vorteile erzielt, daran haben Softwaretests und agile Softwarequalitätssicherung einen entscheidenden Anteil. Dieses Buch gibt einen praxisorientierten Überblick über die am weitesten verbreiteten Testmethoden und -praktiken sowie Managementinstrumente in agilen Projekten. Entwicklungsleiter, Projektleiter, Testmanager und Qualitätsmanager erhalten Hinweise und Tipps, wie Testen und Qualitätssicherung organisiert werden müssen, damit sie auch in agilen Projekten nicht an Schlagkraft verlieren. Professionelle Tester und Experten für Softwarequalität erfahren, wie sie in agilen Teams erfolgreich mitarbeiten und ihre spezielle Expertise optimal einbringen können. Aus dem Inhalt: • Agile und klassische Vorgehensmodelle • Planung im agilen Projekt • Unit Tests, Test First • Integrationstests, Continuous Integration • Systemtests, Test nonstop • Qualitätsmanagement, Qualitätssicherung Fallstudien, ein durchgängiges Fallbeispiel sowie Übungsaufgaben und Checkfragen zum Self-Assessment runden den Inhalt ab. Das Buch orientiert sich am ISTQB® Certified Tester – Foundation Level Extension Syllabus "Agile Tester". Es eignet sich gleichermaßen für das Selbststudium wie als Begleitliteratur zu den entsprechenden Schulungen. Die 2. Auflage wurde komplett überarbeitet und ist konform zum ISTQB®-Lehrplan Version 2014.

Ebooka przeczytasz w aplikacjach Legimi na:

Androidzie
iOS
czytnikach certyfikowanych
przez Legimi
Windows
10
Windows
Phone

Liczba stron: 367

Odsłuch ebooka (TTS) dostepny w abonamencie „ebooki+audiobooki bez limitu” w aplikacjach Legimi na:

Androidzie
iOS
Oceny
0,0
0
0
0
0
0



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.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.de/plus

Testen in Scrum-Projekten

Leitfaden für Softwarequalität in der agilen Welt

Aus- und Weiterbildung zum ISTQB® Certified Agile Tester – Foundation Extension

2., aktualisierte und überarbeitete Auflage

Tilo Linz

Tilo [email protected]

Lektorat: Christa PreisendanzCopy Editing: Ursula Zimpfer, HerrenbergHerstellung: Nadine ThieleUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen NationalbibliothekDie 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-414-1PDF    978-3-96088-062-2ePub    978-3-96088-063-9mobi    978-3-96088-064-6

2., aktualisierte und überarbeitete Auflage 2016Copyright © 2017 dpunkt.verlag GmbHWieblinger Weg 1769123 Heidelberg

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 ersten Auflage des Buches aus dem Jahr 2013 liegt nun die zweite, aktualisierte Auflage von »Testen in Scrum-Projekten« vor.

Das Buch behandelt und erläutert den Stoff des ISTQB® Certified Tester – Foundation Level Extension Syllabus Agile Tester (Version 2014). Mitte 2016 haben weltweit über 4000 Personen dieses auf dem Foundation Level aufbauende Zusatzzertifikat absolviert. Das ISTQB® geht hier von hohen Wachstumsraten aus. Weitere Lehrplanmodule für agile Tester auf Advanced Level werden deshalb in einer ISTQB®- Arbeitsgruppe, in der der Autor mitarbeitet, vorbereitet bzw. diskutiert.

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

In der 2. Auflage wurden Erläuterungen zu verschiedenen Begriffen ergänzt oder erweitert: in Kapitel 3 zu User Stories, Release- und Sprint-Planung, agile Testpraktiken, Sprint Null sowie zu den Konzepten der Testpyramide und der Testquadranten. In Kapitel 6 wird der Zusammenhang zwischen User Stories, Akzeptanzkriterien, Akzeptanztests und Abnahmetest-getriebener Entwicklung besser dargelegt sowie der Begriff »Hardening Iteration« vorgestellt. Kapitel 8 wurde um eine weitere Fallstudie (die aus der englischen Ausgabe übernommen wurde) ergänzt.

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

Ich wünsche allen Lesern gutes Gelingen bei der Umsetzung der agilen Testansätze in ihrer Praxis und – sollte das Buch die Grundlage für die Vorbereitung zur Zertifizierung sein – viel Erfolg bei der Prüfung!

Tilo LinzMöhrendorf, August 2016

Danksagung

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

Bedanken möchte ich mich an dieser Stelle bei den Autoren und Interviewpartnern der Fallstudien, die auch als Reviewer und Diskussionspartner mitgewirkt haben: Dr. Stephan Albrecht/Avid GmbH, Dierk Engelhardt und Joachim Hofer/imbus AG, Andrea Heck/Siemens AG, Eric Hentschel/ImmobilienScout24, Sabine Herrmann/zooplus AG und Terry Zuo/General Electric Oil & Gas. 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 auch den fachlichen Reviewern 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 Kollegen und Mitarbeitern meiner Firma imbus AG, die mir wertvolle Tipps und Hinweise 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. 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 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 in der Erstellungsphase viele Wochenenden und Abende auf mich verzichten mussten.

Ich wünsche allen Lesern eine interessante Lektüre und ein gutes Gelingen bei der Umsetzung der im Buch beschriebenen Testansätze.

Inhaltsübersicht

1    Einleitung

2    Agile und klassische Vorgehensmodelle

3    Planung im agilen Projekt

4    Unit Tests und Test First

5    Integrationstests und Continuous Integration

6    Systemtests und Test nonstop

7    Qualitätsmanagement und Qualitätssicherung

8    Fallstudien

Anhang

A    Glossar

B    Quellenverzeichnis

Index

Inhaltsverzeichnis

1        Einleitung

1.1      Zielgruppen

1.2      Zum Inhalt

1.3      Fallbeispiel

1.4      Webseite

2        Agile und klassische Vorgehensmodelle

2.1      Scrum

2.2      Kanban

2.3      Klassische Vorgehensmodelle

2.4      Gegenüberstellung der Modelle

3        Planung im agilen Projekt

3.1      Produktvision

3.2      Architekturvision

3.3      Product Backlog

3.4      Story Map

3.5      Sprint Backlog

3.6      Team Charta

3.7      Testplanung und Testmanagement

3.7.1      Klassische Aufgaben

3.7.2      Testmanagement in Scrum

3.7.3      Teststufen, Testpyramide, Testquadranten

3.7.4      Agile Testpraktiken

3.8      Agiles Planen einführen

3.9      Checkfragen und Übungen

3.9.1      Self-Assessment

3.9.2      Methoden und Techniken

3.9.3      Weiterführende Übungen

4        Unit Tests und Test First

4.1      Unit Tests

4.1.1      Klassen und Objekte

4.1.2      Test der Methoden einer Klasse

4.1.3      Test der Objektzustände

4.1.4      Zustandsbezogene Coverage-Kriterien

4.1.5      Test mittels Methodenpermutation

4.2      Test First

4.2.1      Test First und Scrum

4.2.2      Test First einführen

4.2.3      Test First anwenden

4.3      Unit-Test-Frameworks

4.4      Stubs, Mocks und Dummies

4.5      Testmanagement im Unit Test

4.5.1      Unit-Test-Planung

4.6      Checkfragen und Übungen

4.6.1      Self-Assessment

4.6.2      Methoden und Techniken

4.6.3      Weiterführende Übungen

5        Integrationstests und Continuous Integration

5.1      Integrationstests

5.1.1      Typische Integrationsfehler und Ursachen

5.1.2      Integrationstestfälle entwerfen

5.1.3      Abgrenzung zu Unit Tests

5.2      Einfluss der Systemarchitektur

5.2.1      Abhängigkeiten und Schnittstellen

5.2.2      Testbarkeit und Testaufwand

5.3      Integrationsstufen

5.3.1      Klassenintegration

5.3.2      Teilsystemintegration

5.3.3      Systemintegration

5.4      Klassische Integrationsstrategien

5.5      Continuous Integration

5.5.1      Der CI-Prozess

5.5.2      CI einführen

5.5.3      CI optimieren

5.6      Testmanagement im Integrationstest

5.7      Checkfragen und Übungen

5.7.1      Self-Assessment

5.7.2      Methoden und Techniken

5.7.3      Weiterführende Übungen

6        Systemtests und Test nonstop

6.1      Systemtests

6.2      Systemtestumgebung

6.3      Manuelle Systemtests

6.3.1      Exploratives Testen

6.3.2      Sitzungsbasiertes Testen

6.3.3      Akzeptanztests

6.4      Automatisierte Systemtests

6.4.1      Capture and Replay

6.4.2      Schlüsselwortgetriebener Test

6.4.3      Behavior-Driven Test

6.5      Test First im Systemtest

6.5.1      Systemtest-Repository

6.5.2      Pairing

6.6      Nicht funktionale Tests

6.7      Automatisierte Akzeptanztests

6.8      Systemtests – wann?

6.8.1      Systemtests im »letzten« Sprint

6.8.2      Systemtests am Sprint-Ende

6.8.3      Systemtest nonstop

6.9      Sprint-Release und Deployment

6.10    Testmanagement im Systemtest

6.11    Checkfragen und Übungen

6.11.1    Self-Assessment

6.11.2    Methoden und Techniken

6.11.3    Weiterführende Übungen

7        Qualitätsmanagement und Qualitätssicherung

7.1      Qualitätsmanagement klassisch

7.1.1      Aufbau nach ISO 9000

7.1.2      Wirkungsprinzip nach PDCA

7.1.3      Stärken und Schwächen

7.1.4      Prozessmodellierung und Softwareentwicklung

7.2      Qualitätsmanagement agil

7.2.1      QM-Dokumentation vereinfachen

7.2.2      QM-Kultur verändern

7.2.3      Retrospektive und Prozessverbesserung

7.3      Umgang mit Compliance-Anforderungen

7.3.1      Anforderungen an den Softwareentwicklungsprozess

7.3.2      Anforderungen an die Rückverfolgbarkeit

7.3.3      Anforderungen an Produkteigenschaften

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 Scrum1.

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

Lernziele nach Certified Tester – Foundation Level Extension Syllabus, 2014

Kapitel und Abschnitte in diesem Buch

1. Agile Softwareentwicklung

1.1 Die Grundlagen der agilen Softwareentwicklung

FA-1.1.1Das Grundkonzept der agilen Softwareentwicklung basierend auf dem Agilen Manifest beschreiben können.

2

FA-1.1.2Die Vorteile des Whole-Team Approach (interdisziplinäres, selbstorganisiertes Team) verstehen.

2.1, 2.4

FA-1.1.3Den Nutzen von frühen und häufigen Rückmeldungen verstehen.

3.2, 3.4

4.2, 4.4, 4.5

5.5

6.1, 6.2, 6.4, 6.6, 6.8

7.1, 7.2, 7.2.3, 7.5, 7.5.1, 7.6, 7.6.1, 7.7

1.2 Aspekte agiler Ansätze

FA-1.2.1Die Ansätze der agilen Softwareentwicklung nennen können.

2

FA-1.2.2User Stories schreiben in Zusammenarbeit mit Entwicklern und Vertretern des Fachbereichs.

3.3

6.1, 6.3.1, 6.3.3, 6.4, 6.8.2

7.6.2

FA-1.2.3Verstehen, wie in agilen Projekten Retrospektiven als Mechanismus zur Prozessverbesserung genutzt werden.

2.4

3.6

4.5

5.5

6.2

7.2.3, 7.5.1

FA-1.2.4Die Anwendung und den Zweck von Continuous Integration (der kontinuierlichen Integration) verstehen.

5, 5.5

6.9

FA-1.2.5Die Unterschiede zwischen Iterations- und Releaseplanung kennen und wissen, wie sich ein Tester gewinnbringend in jede dieser Aktivitäten einbringt.

3.3, 3.4, 3.5, 3.8

6.9

2. Grundlegende Prinzipien, Praktiken und Prozesse des agilen Testens

2.1 Die Unterschiede zwischen traditionellen und agilen Ansätzen im Test

FA-2.1.1Die Unterschiede der Testaktivitäten zwischen agilen und nicht agilen Projekten benennen und erläutern können.

2, 2.4

3.5, 3.7, 3.7.4

4.5

5.6

6.10

FA-2.1.2Beschreiben können, wie Entwicklungs- und Testaktivitäten in einem agilen Projekt umgesetzt werden.

4

5

6

FA-2.1.3Die Bedeutung von unabhängigem Test in agilen Projekten darlegen können.

6.8, 6.8.1

7.6.1, 7.7

2.2 Der Status des Testens in agilen Projekten

FA-2.2.1Erläutern können, welches Mindestmaß an Arbeitsergebnissen sinnvoll ist, um den Testfortschritt und die Produktqualität in agilen Projekten sichtbar zu machen.

3.7, 3.7.1, 3.7.2

4.5

5.6

6.10

7.5.1

FA-2.2.2Damit vertraut sein, dass sich die Tests über mehrere Iterationen hinweg kontinuierlich weiter entwickeln und daher auch erklären können, warum zum Beherrschen der Risiken im Regressionstest Testautomatisierung wichtig ist.

4.5

5.6

6.2, 6.8, 6.10

2.3 Rolle und Fähigkeiten eines Testers in einem agilen Team

FA-2.3.1Verstehen, über welche Fähigkeiten (bzgl. Menschen, Domainwissen und Testen) ein Tester in agilen Teams verfügen muss.

7.7

FA-2.3.2Wissen, was die Rolle eines Testers in einem agilen Team ist.

2, 2.1

3.7, 3.7.2, 3.7.4

4.2.2

4.5

5.6

6.10

7.5, 7.6, 7.7

3. Methoden, Techniken und Werkzeuge des agilen Testens

3.1 Agile Testmethoden

FA-3.1.1Die Konzepte der testgetriebenen Entwicklung, der abnahmetestgetriebenen Entwicklung und der verhaltensgetriebenen Entwicklung nennen können.

3.3

4.2

5.6

6.1, 6.3.3, 6.5, 6.6, 6.7

FA-3.1.2Die Konzepte der Testpyramide nennen können.

3.7.3

FA-3.1.3Die Testquadranten und ihre Beziehungen zu Teststufen und Testarten zusammenfassen.

3.7.3

FA-3.1.4Für ein vorgegebenes agiles Projekt die Rolle eines Testers in einem Scrum-Team übernehmen.

2, 2.1

3.7, 3.7.2, 3.7.4

4.2.2, 4.5

5.6

6.10

7.5, 7.6, 7.7

3.2 Qualitätsrisiken beurteilen und Testaufwände schätzen

FA-3.2.1Qualitätsrisiken in einem agilen Projekt einschätzen.

3.7, 3.7.2

4.1.2, 4.1.4, 4.5

5.5.3

6.2, 6.3.3, 6.8

7.3.1, 7.6.1

FA-3.2.2Testaufwand auf Basis des Iterationsinhalts und der Qualitätsrisiken schätzen.

3.7

4.1.2

5.2, 5.2.2

6.2, 6.8, 6.10

3.3 Techniken in agilen Projekten

FA-3.3.1Die relevanten Informationen interpretieren können, um Testaktivitäten zu unterstützen.

3.1, 3.2, 3.3

6.6

7.3.1

FA-3.3.2Den Fachbereichsvertretern erklären können, wie testbare Abnahmekriterien zu definieren sind.

3.3

6.1, 6.3, 6.3.3, 6.4.2, 6.6, 6.7

FA-3.3.3Für eine vorgegebene User Story abnahmetestgetriebene Testfälle (ATDD) schreiben können.

3.3

6.3, 6.3.3, 6.4.2, 6.4.3

FA-3.3.4Auf Basis von vorgegebenen User Stories mithilfe von Blackbox-Testentwurfsverfahren funktionale und nicht funktionale Testfälle schreiben können.

4, 4.1, 4.2

5, 5.1, 5.2

6, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7

FA-3.3.5Explorative Tests durchführen können, um das Testen eines agilen Projekts zu unterstützen.

6.3, 6.3.1, 6.3.2

3.4 Werkzeuge in agilen Projekten

FA-3.4.1Verschiedene für Tester verfügbare Werkzeuge gemäß ihrem Zweck und den Aktivitäten in agilen Projekten kennen.

3.7.2, 3.7.4

4.3, 4.4, 4.5

5.3.1, 5.5, 5.6

6.4, 6.5, 6.7

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 agiles1 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 Programming2 (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 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 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«)5. 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 Whiteboard6 ö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 anzusprechen7. 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]):

Beim Scrum Master handelt es sich um eine neu entwickelte 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 Kunden8. 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 Projektleiter9. 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 Entwicklungsteam10 umfasst meistens zwischen fünf bis neun Personen, die das Produkt realisieren. Sie erledigen gemeinsam Sprint für Sprint alle nötigen Aufgaben, um die Anforderungen und das Produkt zu realisieren. »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])11.

Das Team soll demnach interdisziplinär12 aufgestellt sein. Das ist schwierig und gelingt nicht vollständig. 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.

Interdisziplinäre Teams

Die Tatsache, dass Scrum interdisziplinäre Teams propagiert und innerhalb des Teams keine weiteren Rollen unterscheidet, wird oft missverstanden. »Interdisziplinär« bedeutet, dass die Personen im Team 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 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«. Fallstudie 8.1 und 8.4 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?«, 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«). Fallstudie 8.5 »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 ist, 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.2 Kanban

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 Projektmanagementframework. 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.3 Klassische 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-Modell13:

Abb. 2–3 Abstraktionsebenen 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 12, 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.