Master-Thesis - Hochschule Wismarcleve/vorl/projects/da/12-Ma-MeierSebastian.pdf · A. BSTRACT. A....

Aspekte eines unternehmensübergreifenden agilen Softwareentwicklungsprozesses für

unternehmenskritische Systeme zur Einbindung externer Qualitätssicherung

Master-Thesis

Zur Erlangung des Grades

Master of Science (MSc.)

EINGEREICHT BEI: PROF. DR. DR. HERBERT NEUNTEUFEL

PROF. DR. ERHARD ALDE

EINGEREICHT AM: 12.09.2012

EINGEREICHT VON: SEBASTIAN B. MEIER

GEB. AM. 17.02.1987 IN HAMBURG

MATRIKELNUMMER: 109872

INSTITUTION: HOCHSCHULE WISMAR

FAKULTÄT DER WIRTSCHAFTSWISSENSCHAFTEN

WIRTSCHAFTSINFORMATIK, MASTER

ABSTRACT

ABSTRACT

Die agile Softwareentwicklung hat im letzten Jahrzehnt in vielen IT-Projekten Einzug gehal-ten. Als eines der verbreitetesten Modelle hat sich Scrum etabliert und wird zunehmend für die Entwicklung kritischer Systeme eingesetzt. In der konventionellen Softwareentwicklung ist das Einbeziehen einer externen Qualitätssicherung in solchen Fällen verbreitet. In der agi-len Softwareentwicklung ist dieses Vorgehen noch nicht üblich. In der vorliegenden Master-Thesis wurde untersucht, wie externe Qualitätssicherung in die agile Softwareentwicklung eingeführt werden kann, um Systeme mit hohen Qualitätsanforderungen zu entwickeln.

Scrum hat sich als geeignetes Referenzmodell herausgestellt. Erweitert um Kanban ermög-licht es entfernten Teams zusammenzuarbeiten. Internetbasierte Kollaborationswerkzeuge können eine enge Kooperation ermöglichen. Im Testprozess durchläuft jede User Story ein abgewandeltes V-Modell. Nicht die komplette Software wird am Ende des Sprints getestet, sondern jede User Story direkt nach ihrer Implementierung. Automatisierte Regressionstest sichern die Qualität der kompletten Software. Durch die Ermittlung von Kennzahlen über das Kanbansystem sowie über Softwaremetriken kann ein kontinuierlicher Verbesserungsprozess etabliert werden. Als Ausgangspunkt dient die Sprint Retrospective, in der alle Projektbetei-ligten nach jeder Iteration gemeinsam die Optimierung des Entwicklungsprozess hinsichtlich Prozess- und Produktqualität anstreben.

Die Ergänzung agiler Vorgehen um eine externe Qualitätssicherung ist möglich. Sie trägt zur Produktqualität bei und schafft Vertrauen in die entwickelte Software. Scrum wurde in sei-nem Kern wenig verändert, die getroffenen Maßnahmen können mit geringem Aufwand ein-geführt werden.

A lot of projects implemented agile software development over the last decade. Scrum is one of the most widespread models. It's increasingly used for the development of critical systems. In such a case it is not uncommon to use external quality assurance in heavyweight methods. Agile methods are not supporting external quality assurance yet. This master thesis evaluates the integration of external quality assurance into agile software development to allow the pro-duction of company critical software systems.

Scrum has shown to be the best reference model. It was extended with the Kanban method to allow remote teams to cooperate. Teamwork is enhanced through the supplement of internet-based collaboration tools. The test process is derived from the V-Model. Not the complete software will be tested on the end of the sprint. But, every user story is tested after its imple-mentation. Automated regression tests ensure the quality of the whole software on the end of the sprint.

Key figures are raised through the Kanban system and software metrics are measured during development. They are used to establish a continual improvement process. All stakeholders meet to improve and optimize the process and product quality of the development process in sprint retrospective after each iteration.

It is possible to extend agile development methods with external quality assurance. The prod-uct quality is improved and trust is created for the developed software. Scrum stayed mostly unchanged in its core. The undertaken measures can be implemented with little effort.

INHALTSVERZEICHNIS

I

INHALT

ABKÜRZUNGEN III ABBILDUNGEN IV

TABELLEN V

1 Einführung ..................................................................................................... 7 1.1 Motivation und Hintergrund der Arbeit ............................................................. 9 1.2 Aufgabenstellung und Abgrenzung.................................................................. 9

2 Einführung in die agile Softwareentwicklung und Scrum ........................ 11 2.1 Einführung in Vorgehensmodelle .................................................................. 11 2.2 Entstehung und Prinzipien agiler Modelle ...................................................... 15 2.3 Scrum............................................................................................................ 21 2.3.1 Grundgedanken und Begrifflichkeiten ......................................................... 21 2.3.2 Prozessverlauf ............................................................................................ 25 2.4 Zusammenfassung ........................................................................................ 25

3 Analyse des Qualitätsmanagements zur Verwendung mit agilen Modellen ....................................................................................................... 27

3.1 Einführung in das Qualitätsmanagement ....................................................... 27 3.2 Prozessqualität in der agilen Softwareentwicklung ........................................ 34 3.3 Zusammenfassung ........................................................................................ 38

4 Software-Qualitätssicherung im agilen Umfeld ........................................ 41 4.1 Relevanz und Einordnung ............................................................................. 41 4.2 Konventionelles Testen ................................................................................. 45 4.3 Qualitätssicherung in der agilen Softwareentwicklung ................................... 49 4.4 Zusammenfassung ........................................................................................ 53

5 Teilung des Softwareentwicklungsprozesses auf die beteiligten Unternehmen ............................................................................................... 55

5.1 Festlegung der Aufgaben der beteiligten Unternehmen................................. 56 5.2 Zusammenspiel und Schnittstellen ................................................................ 59 5.3 Zusammenfassung ........................................................................................ 67

6 Unterstützung des Softwareentwicklungsprozesses ............................... 69 6.1 Einbindung von Qualitätsmanagementelementen ......................................... 70 6.1.1 Kanban und Scrum ..................................................................................... 71 6.1.2 Einsatz zur Einbindung der externen Software-Qualitätssicherung ............. 74

INHALTSVERZEICHNIS

II

6.2 Werkzeuge .................................................................................................... 77 6.2.1 Kommunikationswerkzeuge ........................................................................ 78 6.2.2 Taskmanagement ....................................................................................... 81 6.2.3 Qualitätsmanagementwerkzeuge ................................................................ 82 6.2.4 Entwicklungs- und Testwerkzeuge .............................................................. 83 6.3 Zusammenfassung ........................................................................................ 84

7 Gestaltung des Softwareentwicklungsprozesses ..................................... 87 7.1 Prozessmodellierung ..................................................................................... 87 7.2 Prozess und Prozessmodell .......................................................................... 90 7.3 Ausnahmen und informelle Kommunikation ................................................. 100 7.4 Zusammenfassung ...................................................................................... 103

8 Fallbeispiel ................................................................................................. 105 8.1 Darstellung und Analyse des Beispielprojekts ............................................. 105 8.2 Anwendung des ausgearbeiteten Prozesses auf das Fallbeispiel ................ 109 8.3 Zusammenfassung ...................................................................................... 113

9 Schlussbetrachtungen .............................................................................. 115 9.1 Zusammenfassung ...................................................................................... 115 9.2 Fazit ............................................................................................................ 118 9.3 Ausblick ....................................................................................................... 119

LITERATUR VI SONSTIGE QUELLEN UND VERWEISE XI GLOSSAR XIV

ANHANG 1

ABKÜRZUNGSVERZEICHNIS

III

ABKÜRZUNGEN

BPMN Business Process Modelling Notation BTS Bug-Tracking-System CMMI Capability Maturity Model Integration EPK Ereignisgesteuerte Prozesskette FDD Feature Driven Development FIT Framework for Integrated Test PDCA Plan Do Check Act QMS Qualitätsmanagementsystem QS Qualitätssicherung TDD Test Driven Development TOC Theory of Constraints TPS Toyota Production System TQM Total Quality Management

UML Unified Modelling Language WIP Work in Progress XP eXtreme Programming

ABBILDUNGSVERZEICHNIS

IV

ABBILDUNGEN

Abbildung 2.1: Das V-Modell .................................................................................... 13

Abbildung 2.2: Die grafische Darstellung von Scrum ................................................ 22

Abbildung 4.1: Dokumente nach Standard IEEE 829 [entnommen aus IEEE829] .... 48

Abbildung 5.1: Verteilung der Aufgaben ................................................................... 60

Abbildung 5.2: Schnittstellen zwischen den Rollen und Systemen ........................... 64

Abbildung 6.1: Beispiel für ein Kanbanboard [entnommen aus Kanbanboard] .......... 72

Abbildung 6.2: An die Gegebenheiten angepasstes Kanbanboard ........................... 77

Abbildung 6.3: Vergleich von Kommunikationswerkzeugen [aus HR01] ................... 79

Abbildung 6.4: Beispiel eines virtuellen Kanbanboards [smartq] ............................... 82

Abbildung 7.1: Popularität von Prozessnotationen [entnommen aus FR12, S. XIII] .. 88

Abbildung 7.2: Basiselemente der BPMN ................................................................. 89

Abbildung 7.3: Darstellung des gesamten Entwicklungsprozesses ........................... 91

Abbildung 7.4: Darstellung der Pflege des Product Backlogs ................................... 92

Abbildung 7.5: Darstellung des Sprint Planning ........................................................ 93

Abbildung 7.6: Darstellung des Sprints Teil 1 ........................................................... 96

Abbildung 7.7: Darstellung des Sprints Teil 2 ........................................................... 97

Abbildung 7.8: Darstellung des Sprint Review und der Sprint Retrospective ............ 99

TABELLENVERZEICHNIS

V

TABELLEN

Tabelle 2.1: Anzahl und Stärke von Beschränkungen von Vorgehensmodellen [aus BT08, S. 167]................................................................................. 20

7

1 EINFÜHRUNG

Die Entwicklung von Softwareprodukten mit hoher Qualität und im festgelegten Zeitrahmen

ist schon seit Beginn des Software Engineering mit Schwierigkeiten verbunden. Als Begriff

für diese Problematik manifestierte sich „die Softwarekrise“. Der Begriff der Softwarekrise ist

erstmals 1968 verwendet worden. Auf einer Konferenz des NATO Science Comittees über

Software Engineering in Garmisch, Deutschland, wurde eine zunehmende Abweichung zwi-

schen den gewünschten Anforderungen an Softwaresystemen und deren Erreichung diskutiert.

Unterschiede zwischen der versprochenen und implementierten Funktionalität, Überschrei-

tung der Budgets und Überziehung des Zeitrahmens in fast allen Softwareentwicklungspro-

jekten wurden festgestellt. 1972 griff Edsger Dijkstra den Begriff erneut auf und verhalf ihm

zu einer gewissen Popularität [Dij72]. Er beschrieb, wie die Softwareentwicklung der schnell

steigenden Leistung der Hardwaresysteme sowie den wachsenden Anforderungen der Benut-

zer nicht mehr gerecht werden konnte.

In einem zusammenfassenden Report der Konferenz [NR68] tauchte ein interessantes Zitat

von Kenneth W. Kolence auf.

„Programming management will continue to deserve its current poor reputation for cost and

schedule effectiveness until such time as a more complete understanding of the program de-

sign process is achieved.“ Kenneth W. Kolence

Mit der Thematik von Softwareentwicklungsmodellen wurde sich seitdem eingehend beschäf-

tigt. Verschiedene Vorgehensmodelle sind entwickelt und verbessert worden, einige wenige

haben sich als Standardmodelle etabliert. Meist wurde versucht, die Probleme mit möglichst

standardisierten Prozessen, viel Dokumentation und festen Meilensteinen zu überwinden.

Nach einer Erhebung von 2009 schlossen etwa ein Drittel aller Projekte die Entwicklung im

Zeit- und Kostenrahmen mit vollem Funktionsumfang ab. [standish] Das bedeutet jedoch,

dass in zwei Dritteln aller Softwareentwicklungsprojekte noch Verbesserungsbedarf vorhan-

den ist. Obwohl viel Zeit seit der Feststellung einer Softwarekrise vergangen ist, scheinen die

Probleme noch nicht behoben zu sein. Ein volles Verständnis für den Softwareerstellungspro-

zess hat sich bisher nicht eingestellt.

Die etablierten, starren Entwicklungsmodelle scheinen nicht genug zur Eingrenzung der

Softwarekrise beigetragen zu haben. Durch die zunehmende Schnelllebigkeit und

KAPITEL 1: EINFÜHRUNG

8

Komplexität der Programme ist es umso wichtiger geworden, ein Entwicklungsmodell zu

etablieren, das auf alle Anforderungen eines Entwicklungsprozesses eingeht. Lange, starre

Entwicklungszeiten können heutzutage nicht mehr gerechtfertigt werden. Die Software läuft

Gefahr, an den Anforderungen des Kunden vorbei entwickelt zu werden und bei

Fertigstellung schon veraltet zu sein.

Deshalb wurde die agile Softwareentwicklung auf Basis des agilen Manifests begründet. Sie

verspricht schnelle Auslieferungen bei einer kundenorientierten Sichtweise, so dass schon

früh von der in Auftrag gegebenen Software profitiert werden kann. Ein großer Teil der Do-

kumentation entfällt dadurch, das gesamte System wird nicht von Anfang an spezifiziert, son-

dern stetig erweitert. Die konventionelle Qualitätssicherung hängt stark von diesen Dokumen-

ten ab. Sie dienen als Grundlage für die Testfallerstellung, die zeitgleich mit dem Entwick-

lungsprozess beginnt. Änderungen an den Anforderungen verursachen weitreichende Nachar-

beiten an den Testfällen. Um mit agilen Modellen Software für kritische Aufgaben zu entwi-

ckeln, wird jedoch für jede Auslieferung eine entsprechend hohe Qualität erwartet, für deren

Sicherstellung eine umfassende Qualitätssicherung nötig ist. Bei linearen Vorgehensmodellen

wurde ein umfassender Test vor der Auslieferung vorgenommen. Nun gibt es während der

Entwicklung nach jedem Iterationsschritt eine Auslieferung. Dementsprechend oft wird ein

kompletter Softwaretest benötigt.

Hinzu kommt, dass unternehmenskritische Software von einer von der Entwicklung unabhän-

gigen Institution überprüft werden sollte, um möglichst viel Vertrauen in das Produkt zu

schaffen und einen objektiven Eindruck von der Qualität zu bekommen.

Es treffen zwei gegensätzliche Anforderungen aufeinander. Auf der einen Seite schnelle,

kundenorientierte Entwicklung mit möglichst vielen Auslieferungen und wenig Dokumentati-

on, auf der anderen Seite eine aufwändige, externe Qualitätssicherung mit einem hohen Do-

kumentationsbedarf, die in bisherigen Modellen einmalig bei Projektende vorgenommen

wurde.

Zwischen diesen beiden Aspekten soll eine Schnittmenge gefunden werden, um den agilen

Entwicklungsprozess mit einer tiefgehenden Qualitätssicherung in Einklang zu bringen. Als

Ergebnis der folgenden Arbeit wird ein Vorgehensmodell erstellt, das den benötigen Prozess

und seine einzelnen Aspekte beschreibt. Vielleicht birgt diese Betrachtung ein tieferes Ver-

ständnis für einen idealen Entwicklungsprozess.

1.1 MOTIVATION UND HINTERGRUND DER ARBEIT

9

1.1 MOTIVATION UND HINTERGRUND DER ARBEIT

Die Thesis entsteht in Zusammenarbeit mit dem Büro für praktische Informatik – BFPI

GmbH (im folgenden BFPI genannt). Die BFPI ist bestrebt, externe Qualitätssicherung als

Dienstleistung für ihre Kunden anzubieten. Durch langjährige Zusammenarbeit in Software-

entwicklungsprojekten für ihre Kunden aus dem Maschinen- und Anlagenbau ist sie dafür

prädestiniert, Qualitätssicherungsmaßnahmen für Applikationen durchzuführen, die von die-

sen an andere Auftragnehmer vergeben wurden.

Die Kunden lassen ihre Software häufig mit dem agilen Entwicklungsmodell Scrum (vgl.

Kap. 2.3) erstellen. Mangelnde Kapazitäten, fehlendes Wissen über das Testen von Software

und die Kritikalität des Produkts auf Seiten der Auftraggeber führten dazu, dass eine unab-

hängige Qualitätssicherung gewünscht wurde. Diese Rolle fällt dem BFPI zu.

Es stellte sich die Frage, wie die externe Qualitätssicherung mit dem agilen Vorgehensmodell

in Einklang gebracht werden kann, um einen möglichst hohen Mehrwert zu schaffen und den

Entwicklungsprozess nicht zu behindern.

Als Verantwortlicher für den Bereich der externen Qualitätssicherung bei der BFPI hat der

Autor umfassende Kenntnisse zu den Bedürfnissen der beteiligten Unternehmen und den An-

forderungen an das erweiterte Entwicklungsmodell erworben.

1.2 AUFGABENSTELLUNG UND ABGRENZUNG

Es ist ein Konzept zu erarbeiten, das die Integration von Qualitätssicherung in einem Soft-

wareentwicklungsprozess über drei Unternehmen (Auftraggeber, Auftragnehmer der Entwick-

lung sowie Auftragnehmer der QS) beschreibt. Die Standorte der Unternehmen sind dabei

voneinander getrennt, die Zusammenarbeit ist über die räumliche Ferne zu koordinieren. Das

Ausleihen von Mitarbeitern für die Projektdauer ist nicht möglich.

Dabei stehen die Erhöhung der Produktqualität und die Orientierung an der agilen Methodik

Scrum im Vordergrund.

Es werden die Aufgabenteilung, der Methoden- und der Werkzeugeinsatz sowie die unter-

nehmensübergreifenden Abläufe dargestellt.

Das Konzept wird in einem Prozessmodell zusammengefasst, das geeignete Qualitätsmana-

gementmethoden zur langfristigen Erhöhung von Prozess- und Produktqualität integriert.

KAPITEL 1: EINFÜHRUNG

10

Zur Evaluierung des Konzepts findet eine abschließende Anwendung auf ein Fallbeispiel

statt.

Es wird sich nur mit den Themen tiefer befasst, die zur Lösung beitragen. Grundlagen werden

kurz umrissen, um die benötigte Theorie zu vermitteln.

Der Fokus der Arbeit liegt auf unternehmensübergreifender Ebene. Die Aufgaben der einzel-

nen Beteiligten werden dargestellt und zugewiesen, eingesetzte Methoden und Werkzeuge

erklärt. Die genaue Umsetzung innerhalb der Unternehmen wird nicht betrachtet, da hierfür

bereits allgemein anerkannte Modelle existieren. Stattdessen stehen die Schnittstellen und

Abläufe zwischen den beteiligten Unternehmen im Vordergrund.

Eine genaue Beschreibung der einzelnen Aufgabendefinitionen, des Informationsbedarfes und

Identifikationsmöglichkeiten möglicher Schwierigkeiten bei Entwicklung und im Prozess

werden vorgenommen.

Als weitere Einschränkung ist die Begrenzung auf drei beteiligte Unternehmen zu nennen.

Eine Erweiterung auf mehrere Auftragnehmer ist nicht vorgesehen.

Die Fallstudie dient zur Verdeutlichung des Konzepts anhand eines bereits durchgeführten

Projekts. Auch hier steht die Beziehung zwischen den Unternehmen im Vordergrund, die Ar-

beitsweise innerhalb der einzelnen Firmen wird nicht betrachtet.

11

2 EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICK-LUNG UND SCRUM

Um externe Qualitätssicherung in ein agiles Vorgehen zu integrieren, ist es erforderlich, die

Problematik der Softwareentwicklung zu verstehen und bestehende Lösungsansätze zu be-

trachten. Dabei stehen die Unterschiede zwischen konventionellen und agilen Vorgehen im

Vordergrund. Aufgrund der Vielfalt von agilen Methoden muss eine speziell für die Integra-

tion externer Qualitätssicherung ausgewählt und näher erläutert werden.

2.1 EINFÜHRUNG IN VORGEHENSMODELLE

Die Entwicklung von Software ist ein hoch komplexes Fachgebiet. Viele verschiedene Auf-

gaben, Personalbedarfe und Abläufe müssen geplant, organisiert und koordiniert werden.

Zwischen dem ersten Gedanken und dem fertigen Produkt liegen oft mehrere Monate bis Jah-

re Entwicklungszeit. Das zu entwickelnde Produkt ist hochkomplex. Eine hohe Anzahl an

Abhängigkeiten, Schnittstellen, intransparenten Anforderungen sowie komplizierte Program-

miersprachen bergen zusätzlich ein hohes Fehlerpotenzial. Ein entsprechend klares Vorge-

hensmodell wird benötigt, um den Überblick zu behalten und ein funktionierendes Produkt

gemäß den Anforderungen liefern zu können.

Seit Beginn der Software-Technik wurden Ingenieure mit diesem Problem konfrontiert und

mussten sich aktiv mit der Gestaltung der Softwareentwicklung beschäftigen, da diese ohne

klare Methoden und Strukturen nicht bewältigt werden konnten. Auch das für komplexe Ar-

beiten benötigte Projektmanagement war zur damaligen Zeit noch nicht ausgereift. Es wurde

fast zeitgleich beim Manhattan Projekt und dem sogenannten „Wettlauf ins All“ entwickelt

und erstmals angewandt. [vgl. Lit07, S. 23f]

Aus diesem Grund wurde schon früh damit begonnen verschiedene Methoden und Abläufe

speziell für die Softwareentwicklung in sogenannten Vorgehensmodellen zusammenzufassen.

Ein Vorgehensmodell ist eine Ablaufbeschreibung, mit der ein bestimmtes Ergebnis erreicht

werden soll. Es ist meist in einzelne, zeitlich getrennte Abschnitte geteilt, sogenannte Phasen,

die konsekutiv zu durchlaufen sind. Dies führt zu einer Verringerung der Gesamtkomplexität.

Aufgabenbereiche sind zeitlich und inhaltlich unabhängig voneinander und können einzeln

angegangen werden. [vgl. Hof08, S. 491]

KAPITEL 2: EINFÜHRUNG IN DIE AGILE SOFTWAREENTWICKLUNG UND SCRUM

12

Im Laufe der Zeit wurde eine Vielzahl an Vorgehensmodellen entwickelt.

1956 wurde das erste sequentielle Vorgehensmodell für die Softwareentwicklung von Herbert

D. Benington beschrieben, das sogenannte Stagewise Modell. [vgl. Ben56]

Es beschreibt ein phasenorientiertes Vorgehen, das schon viele Elemente moderner Vorge-

hensmodelle enthält. So sind bereits Phasen für die Programm- und Quellcodespezifikation

vorhanden, für das Schreiben des Quellcodes und das Testen.

Mehr als ein Jahrzehnt später, 1970, erweiterte Winston Royce das Stagewise Modell. Er fügt

zu den einzelnen Phasen Rückkopplungen hinzu. Damit in jeder Phase der Entwurf detaillier-

ter werden kann, kommt es oft zu Iterationen mit der vorherigen Phase. Jedoch nicht mit wei-

ter entfernten Phasen, da dies den Prozess unnötig verkomplizieren würde. Eine effektive Ab-

sicherung wurde geschaffen, um auf Unstimmigkeiten früh zu reagieren. Dieses grobe Kon-

zept wurde von Royce in seinem eigenen Paper kritisiert und weiter verbessert. [Roy70] Bei

der Erstellung des Militärstandards, dem DoD-STD-2167, wurde jedoch nur der erste Teil

aufgenommen und Royce Bedenken sowie weitere Verbesserungen nicht mit einbezogen.

[vgl. Lar04] Das Modell gewann schnell an großer Popularität und wurde seitdem viel ver-

wendet. Seinen heutigen Namen, „Wasserfallmodell“, bekam es jedoch erst 1981 durch Barry

Boehm. [Boe81]

Wasserfallmodell

Das Wasserfallmodell unterliegt bestimmten Kriterien. [vgl. Bal08, S. 520] Die Aktivitäten

müssen in der vorgegebenen Reihenfolge vollständig durchlaufen werden. Jede Phase muss

abgeschlossen werden, bevor die Nächste beginnt. Für den Abschluss einer Phase ist jeweils

ein bestimmtes Dokument zu erstellen. Die Einbindung der Nutzer geschieht nur in den Defi-

nitionsphasen zu Beginn der Entwicklung.

Das Modell hat heutzutage jedoch keine praktische Relevanz mehr. Zwei ausschlaggebende

Nachteile sind dazu besonders hervorzuheben.

Dem Wasserfallmodell fehlt es an Flexibilität. Es ist völlig statisch, die Anforderungen wer-

den zu Beginn aufgenommen und Phase um Phase strikt abgearbeitet. Das die Anforderungen

zu Beginn der Projekte häufig unklar sind und sich zudem mit der Zeit ändern können, wird

nicht in Betracht gezogen. Somit sind die Projekte häufig zum Scheitern verurteilt, da das

Produkt nicht den Bedürfnissen des Anforderers genügt.

2.1 EINFÜHRUNG IN VORGEHENSMODELLE

13

Ein weiterer großer Nachteil ist die einmalige Testphase am Ende des Projekts. Sie findet

unabhängig von der Implementierung statt. Fehler werden so erst sehr spät erkannt und sind

dementsprechend teuer bei der Behebung. Sollte der Bedarf nach grundlegenden Änderungen

festgestellt werden, kann eine komplette Neuplanung des Projektes nötig sein. [vgl. Hof08, S.

495f]

Um diesen Nachteilen entgegenzuwirken, wurde das Wasserfallmodell erweitert. Es entstand

das sogenannte V-Modell.

V-Modell

Das V-Modell erweitert die Phasen des Wasserfallmodells um Qualitätssicherung. Zu jeder

Phase werden simultan passende Testfälle erstellt. So wird bei der Anforderungsanalyse der

Abnahmetest geplant und bei dem Systementwurf der Systemtest. Nachdem die Implementie-

rung abgeschlossen wurde, werden die Tests von unten nach oben ausgeführt. Bei grafischer

Gegenüberstellung der Entwicklungs- und der Testphasen entsteht ein V, welches die Na-

mensgebung erklärt.

ABBILDUNG 2.1: DAS V-MODELL

Zusätzlich trennt das V-Modell die Validierung und die Verifizierung voneinander. In den

niedrigeren Teststufen wird die Software darauf geprüft, ob sie sich gemäß der Spezifikatio-

nen verhält. In den höheren Teststufen hingegen, steht die Eignung der Software für den Kun-

den im Vordergrund.

Das Vorgehen ähnelt sonst dem Wasserfallmodell. Die Phasen werden konsekutiv durchlau-

fen, es gibt jeweils Rückkopplungen mit der vorherigen Phase. [vgl. Hof08, S. 496f] Der Test


14

wird schon früh definiert, findet jedoch immer noch am Ende der Entwicklung statt. Der

Kunde wird weiterhin nur zu Beginn mit in den Entwicklungsprozess einbezogen.

Das V-Modell erfreute sich besonders im deutschsprachigen Raum großer Beliebtheit und

war lange Zeit Standard für IT-Projekte von Bund und Ländern bis es durch eine Erweiterung,

das V-Modell XT, abgelöst wurde.

V-Modell XT

Das V-Modell XT [vgl. HH08] ist kein Vorgehensmodell, sondern vielmehr ein Leitfaden zur

Entwicklung eines projektspezifischen Vorgehensmodells. XT steht für extreme tailoring und

soll verdeutlichen, dass es auf verschiedene Projekttypen zugeschnitten werden kann.

Um mit dem V-Modell XT ein Vorgehensmodell zu erstellen, ist zuerst der Projekttyp auszu-

wählen. Die Auswahl beschränkt sich auf drei verschiedene Möglichkeiten.

• Systementwicklungsprojekt eines Auftraggebers

• Systementwicklungsprojekt eines Auftragnehmers

• Einführung und Pflege eines organisationsspezifischen Vorgehensmodells

Zu jedem Projekttyp gibt es verschiedene verpflichtende und optionale Vorgehensbausteine,

die beschreiben, welche Aktivitäten durchgeführt und welche Produkte erreicht werden müs-

sen. Ein Produkt ist in dem Zusammenhang nicht nur das Endprodukt, sondern auch die Zwi-

schenergebnisse. Dies können unter anderem Dokumente und Quellcode sein.

Da die Vorgehensbausteine in keiner Reihenfolge zueinander stehen, muss zusätzlich eine

Projektdurchführungsstrategie ausgewählt werden. Sie beschreibt die Reihenfolge der einzel-

nen Arbeitsschritte. Es gibt verschiedene Projektdurchführungsstrategien. Demgemäß kann

unter anderem die inkrementelle, die komponentenbasierte oder die agile Entwicklung ge-

wählt werden.

Das Vorgehensmodell ist jedoch immer noch stark dokumentenlastig. Es müssen zum Ab-

schluss vieler Vorgehensbausteine Dokumente erstellt werden, um in den nächsten Schritt

überzugehen. Somit entfällt ein hoher Aufwand auf die Dokumentation.

Spiralmodell

Die vorhergehenden Modelle sind alle stark dokumentengetrieben. Das V-Modell und das

Wasserfallmodell sind strikt linear.

2.2 ENTSTEHUNG UND PRINZIPIEN AGILER MODELLE

15

Eine andere Herangehensweise wurde von Barry Boehm [Boe88] beschrieben. Im Gegensatz

zu den sequentiellen Modellen beschreibt er ein evolutionäres Vorgehen. Es ist ein Metamo-

dell, in dem 4 Schritte immer wieder von neuem durchlaufen werden. In jeder Phase kann das

geeignete Vorgehensmodell gewählt werden, um die Ziele zu erreichen. Da die Anforderun-

gen zu Projektbeginn meistens unklar sind, wird darauf gesetzt schon sehr früh eine laufende

Software zu entwickeln, den sogenannten Prototyp. Dieser wird zusammen mit dem Nutzer

evaluiert und mit jedem Durchlauf weiter verfeinert. Jeder Durchlauf wird mit einem Prototyp

abgeschlossen. Dies wird solange wiederholt, bis der Prototyp zum Endprodukt gereift ist.

Eine zusätzliche wichtige Erweiterung ist das Hinzufügen von Risikoanalysen. So können

Risiken frühzeitig entdeckt und Gegenmaßnahmen rechtzeitig geplant und umgesetzt werden.

Dadurch ist das Modell risikogetrieben, das Risiko ist möglichst zu minimieren.

Das Spiralmodell konnte sich jedoch nicht gegen die sequentiellen Pendants durchsetzen,

auch wenn es in der Theorie viel Anerkennung fand. [vgl. OW08]


Ende der 90er Jahre entwickelte sich mit der agilen Softwareentwicklung eine Gegenströ-

mung zu den zunehmend monumentalen Modellen. Diese beruhten vor allem auf einem itera-

tiven Vorgehen, ähnlich dem Spiralmodell.

Der lang verfolgte Ansatz, der Softwareentwicklung durch starke Standardisierung ihre

Komplexität zu nehmen, führte zu einer hohen Bürokratisierung. Die Entfaltung der Mitglie-

der wurde gehemmt und eigenverantwortliches Handeln verhindert. Teams mit hohem Poten-

tial erfuhren eine Standardisierung auf das Mittelmaß. Hinzu kommt, dass die Entwicklung zu

einem Selbstzweck wurde. Das Produkt stand nicht mehr im Vordergrund, der Praxisbezug

ging verloren, es wurden die einzelnen Phasen abgearbeitet, ohne dass eine Validierung er-

folgte. [vgl. OW08, S. 14]

Die agile Bewegung setzt sich zum Ziel, den Fokus von den Vorgehensmodellen zurück auf

das Produkt und den Kunden zu lenken. Dabei sollen die Vorteile und Errungenschaften der

bisherigen Entwicklungsformen erhalten bleiben, die starken Begrenzungen jedoch aufgelöst

werden. [vgl. OW08, S. 12f]

Im Jahr 2000 wurde das agile Manifest von führenden Personen der agilen Softwareentwick-

lung niedergeschrieben, um verbindliche Grundsätze festzuhalten.


16

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen

dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge

• Funktionierende Software mehr als umfassende Dokumentation

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte

auf der linken Seite höher ein.“ [agile_manifesto]

Es wird deutlich, dass der Fokus auf die Erstellung funktionierender Software gelegt wird, bei

einer möglichst hohen Befriedigung der Kundenbedürfnisse. Die Werte der rechten Seite sind

immer noch willkommen und sollten nach Möglichkeit eingehalten werden, sie dürfen jedoch

nicht die Werte auf der linken Seite einschränken. Bei monumentalen Modellen war dies der

Fall. Prozesse, Werkzeuge, Dokumentation, Vertragsverhandlung und Pläne fallen jedoch

nicht völlig weg, sie nehmen nur einen geringeren Stellenwert ein. Eine Entwicklung agil zu

nennen, nur auf Grund fehlender Dokumentation, ist falsch.

Ein weiteres Manifest wurde durch eine Gruppe um David Anderson verfasst, die Declaration

of Interdependence. Sie begründet agile Grundlagen für das Management agiler Projekte

[pmdoi].

Agile and adaptive approaches for linking people, projects and value

We are a community of project leaders that are highly successful at delivering results. To

achieve these results:

We increase return on investment by making continuous flow of value our focus.

We deliver reliable results by engaging customers in frequent interactions and shared owner-

ship.

We expect uncertainty and manage for it through iterations, anticipation, and adaptation.

We unleash creativity and innovation by recognizing that individuals are the ultimate source

of value, and creating an environment where they can make a difference.


17

We boost performance through group accountability for results and shared responsibility for

team effectiveness.

We improve effectiveness and reliability through situationally specific strategies, processes

and practices.

Mit „interdependence“ wird sowohl die Wechselbeziehung zwischen den einzelnen Team-

mitgliedern bezeichnet, als auch die Zusammenhänge zwischen dem Team, den Kunden und

den Interesseneignern. Der Schwerpunkt liegt hier auf dem Projektmanagement und lässt die

erhofften Mehrwerte durch agile Methoden erkennen sowie die Mittel, durch die sie erreicht

werden sollen.

Es ist ersichtlich, wodurch die agilen Methoden ihren Namen bekommen haben.

Statt eines streng regulierten Prozesses gibt es einen Rahmen, in dem die Teammitglieder

eigenverantwortlich arbeiten. Die Entwicklung einer funktionierenden Software steht im Vor-

dergrund; Dokumentation erfolgt nur dort, wo es notwendig ist. Teammitglieder sollen sich

mit dem Projekt identifizieren und selbst für die Ergebnisse einstehen, bessere Leistung durch

erhöhte Motivation wird erhofft. Mehr Freiheiten bedeuten eine steigende Innovationsfähig-

keit, die bessere Ergebnisse hervorbringen kann.

Zu Beginn der Entwicklung wird nicht davon ausgegangen, dass alle Anforderungen schon

existieren und dokumentiert werden können. Die Bedürfnisse der Nutzer sollen sich während

der Entwicklung herauskristallisieren. Dafür ist eine enge Zusammenarbeit mit den späteren

Nutzern notwendig. Meist wird den Entwicklern eine konkrete Ansprechperson zugewiesen,

auf die während des Entwicklungsprozesses immer zurückgegriffen werden kann.

Eine kurzfristige Reaktion auf Änderungen ist notwendig, eine flexible Anpassung auf sich

ändernde Ausgangsbedingungen gewollt. [vgl. OSW, S. 17f]

Die Entwicklungszyklen sind möglichst kurz gehalten, in der Regel 4-6 Wochen. Alle drei

Entwicklungszyklen ist eine neue Produktversion fertigzustellen, die an den Kunden überge-

ben werden kann. Es wird so früh wie möglich ein brauchbares Produkt produziert, so dass

sich für den Auftraggeber unmittelbar ein Mehrwert ergibt. Die Ergebnisse des Projekts erfah-

ren eine frühe Evaluierung, über die der weitere Verlauf der Entwicklung gegebenenfalls an-

passbar ist. [vgl. HRS09, S.8f]

Die agile Methode setzt ein gut eingespieltes Team voraus. Kommunikation ist notwendig,

alle Teammitglieder müssen zusammenarbeiten. Die Größe eines agilen Teams beträgt in der


18

Regel weniger als 12 – 15 Mitglieder. Mit wachsender Teamgröße wird es zunehmend schwe-

rer, ein agiles Vorgehen umzusetzen. Es gibt jedoch Ansätze, um ein agiles Vorgehen auch in

größeren Projekten mit über 300 Projektmitarbeitern zu verwirklichen. [vgl. HRS09, S. 92]

Für die Umsetzung der agilen Methode gibt es unterschiedliche Modelle.

Das erste agile Vorgehensmodell war XP (eXtreme Programming). Es wurde von Kent Beck

1999 während eines Projekts für Chrysler entwickelt und kurz darauf publiziert. Einige dabei

eingesetzte Praktiken sind bezeichnend für agile Modelle und werden auch in anderen Model-

len eingesetzt. [Bec99]

On-site customer

Der Kunde ist während der Entwicklung vor Ort. Es wird zu Beginn keine umfassende An-

forderungsspezifikation geschrieben. Stattdessen steht der Kunde selbst stets zur Verfügung,

um fachliche Unterstützung zu geben und darauf zu achten, dass seine Wünsche richtig ver-

standen werden. Er führt am Ende den Akzeptanztest durch, um die Software zu validieren.

Planning game

Mit „planning game“ wird die Planung des nächsten Entwicklungszyklus bezeichnet. Der

Kunde nennt und priorisiert seine Anforderungen. Die Entwickler schätzen den benötigten

Aufwand.

Short releases

Die Entwicklungszyklen sind kurz. Es wird dem Kunden oft eine neue Version der Software

übergeben. Die Erfahrungen der Anwender mit dem Produkt werden bei der Weiterentwick-

lung berücksichtigt. Es wird möglichst früh ein return-on-investment erzielt.

Metaphor

Eine Metapher beschreibt auf einfache Weise das System und seine Architektur. Sie dient

dazu, schnell und einfach die Software zu erklären, ohne dass ein technischer Hintergrund

zwingend erforderlich ist.

Collective ownership

Es gibt nur eine Codebasis, für die alle Entwickler gemeinsam verantwortlich sind. Jeder

Entwickler des Teams darf den Code von jedem anderen Entwickler ändern.


19

Continuous integration

Der geschriebene Quellcode wird kontinuierlich in das gesamte Produkt integriert, um späte-

ren Kompatibilitätsproblemen vorzubeugen. Die Software kann schon frühzeitig als Gesamt-

system getestet werden.

Coding standards

Das Team einigt sich schon früh auf Richtlinien für die Codeerstellung. Der Quellcode soll

einheitlich gestaltet und gut lesbar sein.

40 – hour week

Es wird ein einheitliches Entwicklungstempo eingehalten. Die Entwickler sollen auf dem Ni-

veau ihrer höchsten Leistungsfähigkeit arbeiten. Dies aber nicht mehr als notwendig und nicht

länger als 40 Stunden die Woche. Sollten Überstunden zur Regel werden, deutet dies auf ein

Managementproblem hin, nicht auf Schwächen in der Entwicklung.

Testing

Die Programmierer schreiben automatisch ausführbare Tests für die Software, nach Möglich-

keit vor Implementierung der Funktion in Form von Test Driven Development (TDD). Die

Kunden schreiben Funktionstest in Form von Anwendungsfällen. Der finale Akzeptanztest

findet im laufenden Betrieb statt.

Simple design

Das Programmdesign soll so einfach wie möglich gehalten werden. Ein gutes Verständnis und

leichte Änderbarkeit des Quellcodes stehen im Vordergrund.

Refactoring

Der Quellcode soll wann immer möglich umstrukturiert werden, wenn sich damit ein einfa-

cheres Ergebnisse erzielen lässt. Bei der Änderung oder Implementierung einer Funktion soll

immer die Lösung gewählt werden, die zum einfachsten Design führt, auch wenn dies Mehr-

aufwand zur Folge hat.

Pair programming

Eine der umstrittensten Vorschläge Becks ist die paarweise Programmierung. Zwei Personen

sitzen an einem Computer. Während einer die Anforderung implementiert, denkt der zweite

mehr strategisch über das Vorgehen nach. Er soll mögliche Probleme frühzeitig erkennen und


20

auf einfachere Lösungen hinweisen. Durch ein regelmäßiges Wechseln der Partner wird ein

Gruppenverständnis über den kompletten Code gefördert.

Diese 12 Faktoren sind für XP verbindlich. Mehrere agile Vorgehensmodelle wurden von

diesen Praktiken inspiriert und setzen sie zumindest zum Teil um. Neben XP haben sich wei-

tere agile Modelle herausgebildet. Zu den populäreren Modellen neben XP gehören Crystal,

FDD und Scrum. [vgl. Bal08, S. 651ff]

Einen Vergleich zwischen verschiedenen Vorgehensmodellen, agilen wie auch konservativen,

haben Boehm und Turner vorgenommen. [vgl. BT08, S.165ff] Sie haben die Modelle nach

Bezug auf kritische Bereiche, Life Cycle Aktivitäten und Beschränkungen analysiert. Tabelle

2.1 zeigt verschiedene Vorgehensmodelle nach einem Agilitäts-Ranking, aufsteigend nach der

Anzahl der Beschränkungen. Ist für ein Vorgehensmodell eine unterschiedliche Anzahl an

Beschränkungen ausgewählt, ist dies als von-bis anzusehen.

Agility Rank

Methode Sehr Niedrig

Niedrig Mittel Hoch Sehr Hoch

1 Scrum •

2 Adaptive Software Development (ASD)

• • •

3 Lean Development (LD) • • •

4 Crystal • • •

5 eXtreme Programming (XP) • •

6 Dynamic Systems Development Method (DSDM)

• • •

7 Rational Unified Process (RUP) • • •

8 Team Software Process (TSP) • • •

9 Feature-Driven Development (FDD)

•

10 Capability Maturity Model Inte-gration (CMMI)

• • • •

11 Capability Maturity Model for Software (SW-CMM)

• •

12 Personal Software Process (PSP) •

13 Cleanroom •

TABELLE 2.1: ANZAHL UND STÄRKE VON BESCHRÄNKUNGEN VON VORGEHENSMODELLEN [AUS BT08, S. 167]

2.3 SCRUM

21

Es ist gut ersichtlich, dass Scrum die leichtgewichtigste Methodik ist. Sie gibt kaum mehr als

einen Prozessrahmen vor, in dem das Team selbstbestimmt arbeitet. Nach unten nehmen die

Beschränkungen für den Prozess zu. Dies führt über XP mit der expliziten Einhaltung der

Praktiken bis zu Cleanroom, mit einer strikten, auf fehlerfreien Code ausgelegten Methodik.

Scrum bringt für Einbindung von externer Qualitätssicherung in die agile Softwareentwick-

lung verschiedene Vorteile mit. Durch die wenigen Beschränkungen lässt sich das Modell

anpassen, ohne von seinen Vorgaben abzuweichen. Je restriktiver ein Modell gestaltet ist,

desto schwerer wird es, sinnvolle Anpassungen zu bewirken. Des Weiteren ist Scrum in sei-

nem Kern sehr agil. Die Gefahr den agilen Prinzipien zu widersprechen, dementsprechend

geringer. Hinzu kommt, dass Scrum eines der beliebtesten agilen Vorgehensmodelle ist und

dementsprechend viele repräsentative Studien zu seinem Einsatz vorliegen. Zusätzlich ergib

sich Scrum durch die Aufgabenstellung als Ausgangsmodell.

Aus diesen Gründen wurde Scrum im Kontext dieser Arbeit als agiles Modell ausgewählt und

um externe Qualitätssicherung erweitert. Da weiterhin die agilen Richtlinien beachtet werden,

sollte das Ergebnis mit kleinen Änderungen auch auf andere agile Modelle anwendbar sein.

2.3 SCRUM

Nach der Auswahl von Scrum als Referenzmodell ist eine Aufarbeitung der Grundlagen des

Vorgehensmodells notwendig. Basierend auf dem ursprünglichen Prozess kann eine Erweite-

rung um die externe Qualitätssicherung stattfinden

2.3.1 GRUNDGEDANKEN UND BEGRIFFLICHKEITEN

Ursprünglich wurde Scrum nicht direkt für die Softwareentwicklung entwickelt. Es stammt

aus einer Zeit, in der von agilen Modellen noch nicht die Rede war. Takeuchi und Nonaka

beschrieben 1986 eine inkrementelle-iterative Projektmanagementmethodik. [TN86] Es wird

von einem sich selbst verwaltenden Team ausgegangen, eine subtil geführte, lernende Organi-

sation. Das Vorgehen wird immer wieder mit dem „Scrum“ aus dem Sport Rugby verglichen,

bei dem alle Teammitglieder zusammenarbeiten und gemeinsam auf das ständig wechselnde

Spielgeschehen reagieren, um den Sieg zu erringen.

Zu seinem heutigen Bekanntheitsgrad verhalfen Jeff Sutherland und Ken Schwaber durch ihre

Präsentation zu Scrum 1995 auf der OOPSLA ’95 in Austin, Texas.


22

Scrum ist ein Rahmenwerk, in dem die Entwicklung eines Softwareprodukts stattfindet.

Das Vorgehen ist iterativ. Die Entwicklung findet in so genannten Sprints statt. Ein Sprint ist

„timeboxed“, er hat eine zuvor genau festgelegte Länge, in der Regel vier Wochen. In diesen

vier Wochen werden zuvor festgelegte Anforderungen umgesetzt. Die Anforderungen wurden

zuvor priorisiert. So kann mit den wichtigsten Anforderungen begonnen und sich zu den

zweitrangigen vorgearbeitet werden. Sollten am Ende des Sprints noch Anforderungen offen

sein, ist dies unproblematisch, da die wichtigen bereits umgesetzt wurden. Am Ende eines

Sprints sollte das entwickelte Teilprodukt lauffähig sein. [vgl. Pic08, S. 7f] In Abbildung 2.2

ist das Vorgehen grafisch dargestellt.

In Scrum sind mehrere Rollen definiert, der ScrumMaster, der Product Owner, das Scrum-

Team sowie Nebenrollen. [vgl. Wir09, S. 36ff]

Das ScrumTeam ist für die Entwicklung des Produkts verantwortlich. Es besteht aus allen

Personen, die für die Erstellung der Software erforderlich sind. Es ist funktionsübergreifend.

So können Softwareentwickler, Dokumentatoren, Analysten, Tester und alle weiteren zur

Entwicklung benötigten Kompetenzen Teil des ScrumTeams sein. Zu beachten ist, dass die

ideale Größe für ein ScrumTeam zwischen 3 und 9 Personen liegt.

Es ist keine Führungsrolle vorgesehen, Hierarchien sind nicht vorhanden. Das ScrumTeam ist

selbst organisierend. Das Ziel der Entwicklung ist für das gesamte Team verbindlich, alle sind

gemeinsam für die Ergebnisse verantwortlich.

ABBILDUNG 2.2: DIE GRAFISCHE DARSTELLUNG VON SCRUM

2.3 SCRUM

23

Der ScrumMaster ersetzt den Projektmanager. Er hat eine unterstützende Funktion und nur

bedingt eine führende. Seine Aufgabe ist es, den Erfolg des Projekts zu sichern. Dies ge-

schieht auf zwei Wegen. Zum einen stellt er sicher, dass die Regeln und Rahmenbedingungen

von Scrum eingehalten werden. Zum anderen steht er schützend über dem ScrumTeam, nega-

tive Einflüsse auf das Projekt sind abzuwehren und Hindernisse von ihm zu beseitigen. Der

ScrumMaster nimmt jedoch keinen Einfluss auf die Entwicklung, eine Intervention ist nur

nötig, wenn das ScrumTeam nicht von alleine zur Lösung eines Problems kommt.

Der Product Owner ist für das endgültige Produkt und den wirtschaftlichen Erfolg des Pro-

jekts verantwortlich. Er stellt die Schnittstelle zum Kunden und Nutzer dar. Seine Aufgabe ist

es, sich in die Anwendungsdomäne des Kunden einzuarbeiten und mit ihm zusammen die

Anforderungen an das Projekt in sogenannten User Storys niederzuschreiben. Im Laufe des

Projekts wird der Product Owner die User Storys regelmäßig aktualisieren und anpassen. Er

ist während der Entwicklung der Ansprechpartner für das Team.

In den Nebenrollen sind die Stakeholder des Projekts enthalten, also alle mit einem Interesse

am Gelingen des Projekts. Zum einen ist dies der Kunde, zum anderen das Management des

eigenen Unternehmens. Zu Kunden hält der Product Owner engen Kontakt, zum eigenen Ma-

nagement der ScrumMaster, um den Entwicklungsstand zu kommunizieren und Hindernisse

zu beseitigen.

Neben der ständigen Kommunikation innerhalb des Teams und zwischen den Rollen gibt es

verbindliche Meetings zu festgelegten Zeitpunkten. [vgl. Han10, S. 61ff]

Das Sprint Planning Meeting dient als Vorbereitung auf den Sprint. Es kommen Product

Owner, ScrumMaster und das ScrumTeam zusammen und gehen gemeinsam das Product

Backlog, eine Anforderungsliste, durch. Geeignete User Storys werden gemeinsam ausge-

wählt und in das Selected Backlog übertragen. Das Selected Backlog wird daraufhin für die

Zeit des Sprints nicht mehr verändert, während der Product Owner das Product Backlog stän-

dig verändern kann. Im weiteren Verlauf des Meetings werden die User Storys des Selecteted

Backlogs in einzelne Aufgaben zerlegt. Es entsteht ein Sprint Backlog, dem während des

Sprints die einzelnen Aufgaben entnommen werden. Anhand des Sprint Backlogs ist der Fort-

schritt des Projekts erkennbar.

Innerhalb des Sprints findet jeden Tag zu einem festen Zeitpunkt ein Meeting statt, das

sogenannte Daily Scrum. Der Vortag wird reflektiert und die Aufgaben des laufenden Tages

besprochen. Das Meeting ist in der Regel 15 Minuten lang. Aufgetretene Probleme werden


24

erwähnt, die Lösung der Probleme findet jedoch außerhalb des Meetings statt. Das Daily

Scrum hilft dem ScrumMaster dabei, den Fortschritt des Projekts festzustellen und mögliche

Hindernisse zu erkennen.

Am Ende eines jeden Sprints werden zwei Meetings durchgeführt. Im Sprint-Review werden

die Ergebnisse des Sprints den Kunden und Stakeholdern vorgestellt. Es ist eine Präsentation

der laufenden Software. Wichtig ist das Feedback der Beteiligten, da das Sprint-Review eine

wichtige Funktion für die Bestimmung des weiteren Verlaufs der Entwicklung hat.

Die Sprint-Retrospektive ist eine Diskussion der Projektbeteiligten am Ende des Sprints. Sie

soll einen kontinuierlichen Lernprozess anstoßen. Positive und negative Aspekte der Zusam-

menarbeit und des Entwicklungsprozesses werden zusammengetragen und Schlüsse für die

nächsten Sprints gezogen. Am Ende soll eine Liste mit konkreten Verbesserungsvorschlägen

entstehen, die vom ScrumMaster und Team umgesetzt wird.

Neben den Rollen und Meetings sind verschiedene Dokumente vorgesehen. Das Product

Backlog enthält alle Anforderungen des Kunden als User Storys. Eine User Story ist die De-

finition einer Programmfunktion in Form einer Beschreibung, was der Kunde mit ihr verrich-

ten möchte. Der Aufwand der UserStorys ist geschätzt, die Priorität nach Wert für den Kun-

den defniert. Das Product Backlog wird durch den Product Owner gepflegt und Änderungen

sind stets vorbehalten.

Im Sprint Backlog werden die im Sprint umzusetzenden Aufgaben festgehalten. Hierzu wer-

den aus dem Product Backlog UserStorys vom Product Owner, ScrumMaster und Scrum-

Team ausgewählt und in einzelne Aufgaben zerlegt. Die einzelnen Aufgaben werden im

Sprint Backlog dokumentiert. Das Sprint Backlog ist während des Durchlaufs eines Sprints

fest. An ihm orientiert sich das Team während der Entwicklung, der Fortschritt wird an der

Abarbeitung der Aufgaben gemessen.

Zusätzlich gibt Scrum mehrere verbindliche Prinzipien vor. Während sich die meisten aus den

Prinzipien der agilen Softwareentwicklung ergeben, gilt es eine besonders hervorzuheben. Die

„Definition of Done“, also die Definition, wann eine User Story als abgeschlossen angesehen

werden kann. Sobald eine User Story beendet wurde, soll sie für den Kunden verfügbar sein.

Eine User Story, die nur zu 90 % abgeschlossen ist, bietet keinen Mehrwert. Meist handelt es

sich dabei um mehrere Kriterien. Eine „Definition of Done“ könnte die erfolgreiche Abnahme

durch die Qualitätssicherung sein. [vgl. Wir09, S.32ff]

2.4 ZUSAMMENFASSUNG

25

2.3.2 PROZESSVERLAUF

Der Prozess von Scrum beginnt mit einer Vision, einer Idee für das zu entwickelnde Produkt.

[vgl. Wir09, S. 29] Der darauf folgende Ablauf ist grob vorgegeben. [vgl. Pic08, S. 81ff] Der

Product Owner setzt sich daraufhin mit dem Kunden zusammen, um seine Anforderungen in

Form von User Storys aufzunehmen und in das Product Backlog zu übertragen. In dem Pro-

duct Backlog werden die Anforderungen priorisiert und der Aufwand geschätzt.

Vor Beginn des ersten Sprints setzen sich ScrumMaster, ScrumTeam und Product Owner zu-

sammen, um die User Storys für den ersten Sprint auszuwählen und in Aufgaben zu zerlegen.

Das Sprint Backlog wird erstellt.

Während des Sprints entnimmt das Team eigenständig die Aufgaben aus dem Sprint Backlog.

Hier ist keine Steuerung durch den ScrumMaster erforderlich. Dieser ist damit beschäftigt,

alle Hindernisse aus dem Weg zu räumen, so dass das Team ohne Schwierigkeiten arbeiten

kann. Der Product Owner hält regelmäßig Rücksprache mit dem Team und lässt sich die

neuesten Ergebnisse zeigen.

Jeden Tag findet ein kurzes Meeting statt, in dem der Stand und zukünftige Schwierigkeiten

besprochen werden.

Das Resultat am Ende des Sprints wird im Sprint-Review vorgestellt und kann sofort an den

Kunden übergeben werden. In der Sprint Retrospective wird der vergangene Sprint analysiert

und Veränderungen für die Zukunft herausgearbeitet.

Es ist gut ersichtlich, dass die Mehrheit der 12 von Beck postulierten Regeln für XP auch in

Scrum wieder zu finden sind. Auch XP typische Praktiken wie TDD und Pair Programming

lassen sich gut in Scrum umsetzen. [vgl. Pic08, S. 85]

Scrum ist ein durch und durch agiles Vorgehensmodell, das dennoch klare Richtlinien und

einen übergeordneten Prozess liefert, in dem die Rahmenbedingungen klargestellt werden.

2.4 ZUSAMMENFASSUNG

Zu Beginn des Kapitels wurde eine Einführung in Vorgehensmodelle gegeben und der Unter-

schied zwischen konventionellen und agilen Modellen herausgearbeitet. Die konventionellen

Modelle mit ihren konsekutiven Phasen wurden vorgestellt. Für die Entwicklung von komp-

lexen Produkten hat sich in Deutschland das V-Modell als Standard durchgesetzt. Auf Grund


26

von Inflexibilität, einem geringen Kundenbezug und hohem bürokratischen Aufwand sind mit

diesen Modellen entwickelte Projekte oft gescheitert.

Zu den zunehmend monumentaleren Modellen hat sich Ende der 90er Jahren eine Gegens-

trömung entwickelt, die agile Softwareentwicklung. Mit kurzen Iterationen, hoher Kundennä-

he und selbstständigen Entwicklern wird die Software inkrementell erstellt.

Im Gegensatz zum konventionellen Vorgehen, bei der das vollständige Produkt erst am Ende

der Entwicklung übergeben wird, entsteht die Software nun Stück für Stück. Der Kunde be-

kommt schon früh ein Produkt, das in jeder Iteration an Funktionsumfang gewinnt.

In der agilen Softwareentwicklung gibt es verschiedene Vorgehensmodelle. Eines der Leicht-

gewichtigsten ist Scrum. Es wurde als Referenzmodell für die weitere Verwendung in der

Arbeit ausgewählt.

Scrum definiert drei Rollen: Den Product Owner, den ScrumMaster und das ScrumTeam. Der

Product Owner übernimmt die Kommunikation mit dem Kunden und stellt die Anforderungen

bereit, der ScrumMaster schützt das ScrumTeam vor Unterbrechungen und beseitigt Hinder-

nisse. Das ScrumTeam entwirft, implementiert und testet die Software. Die Entwicklung fin-

det in einem Zeitrahmen von 2 bis 6 Wochen statt, wobei dem jeden Tag ein kurzes Meeting

stattfindet.

Scrum ermöglicht es dem Team, völlig frei zu arbeiten und bietet viel Platz für den Einsatz

einer externen Qualitätssicherung.

Mit der Aufarbeitung der verschiedenen Vorgehensmodelle wurde die Grundlage für die Ge-

staltung des Entwicklungsprozesses vermittelt. Konventionelle und agile Modelle wurden

beschrieben und voneinander abgegrenzt. Scrum ist als passendes Referenzmodell identifi-

ziert worden und wird in der vorliegenden Arbeit als Vorgehensmodell genutzt.

27

3 ANALYSE DES QUALITÄTSMANAGEMENTS ZUR VERWENDUNG MIT AGILEN MODELLEN

Während Vorgehensmodelle den projektspezifischen Ablauf beschreiben, zielt das Qualitäts-

management auf organisatorische Optimierung zur Verbesserung der Produktqualität. Um die

Prozess- und die Produktqualität langfristig zu erhöhen, sollen Qualitätsmanagementelemente

in den Entwicklungsprozess eingearbeitet werden. Während es Qualitätsmanagementkonzepte

für schwergewichtige Modelle gibt, muss dies für die agile Softwareentwicklung im Einzel-

nen erarbeitet werden.

3.1 EINFÜHRUNG IN DAS QUALITÄTSMANAGEMENT

Zur Vertiefung in diesem Gebiet ist eine klare Definition von dem Begriff „Qualität“ notwen-

dig.

In der ISO 9001:2005-01, der gültigen Norm für Qualitätsmanagement, wird Qualität wie

folgt definiert:

„Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt.“

Qualität gibt also das Ausmaß an, in dem zuvor festgelegte Anforderungen an das Produkt

umgesetzt wurden. Zu beachten ist, dass die beschriebenen Anforderungen selbst eine gewis-

se Qualitätsdefinition mitbringen. Werden in den Anforderungen Toleranzgrenzen gesetzt,

kann das Produkt trotz eines hundertprozentigen Qualitätsgrades fehleranfällig sein, da diese

Toleranzen zuvor, meist aus Kostengründen, mit einkalkuliert wurden.

Dies wird in der Definition von R. A. Broh aus Managing Quailty for Higher Profits von 1982

[Bro82] deutlich.

„Quality is the degree of excellence at an acceptable price and the control of variability at an

acceptable cost“

Es wird das Kosten-Nutzen-Verhältnis in den Vordergrund gestellt. Die Kosten für die Quali-

tätserreichung sollten nicht über den Kosten liegen, die durch mangelhafte Produkte entste-

hen.

KAPITEL 3: ANALYSE DES QM ZUR VERWENDUNG MIT AGILEN MODELLEN

28

Die Ausrichtung der Qualität im Unternehmen sollte am Kunden und im Vergleich zu den

Mitbewerbern geschehen. Ein Wettbewerbsvorteil ist anzustreben, um die Kunden zu einer

Kaufentscheidung für das eigene Produkt zu bewegen. [vgl. BW08, S. 3]

Unter Qualitätsmanagement werden laut ISO9000 alle “Aufeinander abgestimmte Tätigkei-

ten zum Leiten und Lenken einer Organisation bezüglich Qualität” verstanden. Ziel ist die

Sicherung eines langfristigen Unternehmenserfolges durch die Erhöhung der Kundenzufrie-

denheit und Reduzierung von Kosten und Mängeln.

Die Produktqualität ist stark von der Prozessqualität abhängig. Ein reibungsloser Prozess hat

eine hohe Produktqualität zur Folge, da alle Arbeitsschritte überprüfbar und standardisiert

ablaufen. Die Prüfung eines Produktes nur nach seiner Fertigstellung hat sich als zu teuer und

langwierig erwiesen. Die Korrekturkosten für Fehler steigen mit jeder durchlaufenen Ent-

wicklungsphase nahezu exponentiell an. [vgl. Lig09, S. 32] Aufgabe des Qualitätsmanage-

ments ist es, die Entstehung der Fehler zu vermeiden oder für eine frühestmögliche Aufde-

ckung zu sorgen. Schon während der Entwicklung des Produkts müssen Maßnahmen ergriffen

werden, um eine hohe Qualität zu gewährleisten.

Als Prozess definiert die ISO 9000:2000 (2000) „. . . einen Satz von in Wechselwirkung ste-

henden Tätigkeiten, der Eingaben in Ergebnisse umwandelt.“ Ein Prozess hat folglich einen

Input, der über eine aufeinanderfolge Durchführung verschiedener Aktivitäten in einen be-

stimmten Output umgewandelt wird. Als Geschäftsprozess werden die Prozesse mit direktem

Kundennutzen bezeichnet. In einem Softwareentwicklungsprozess wird das Produkt herges-

tellt und Mehrwert für den Kunden generiert. Dementsprechend ist er ein Geschäftsprozess. In

dieser Arbeit wird Prozess und Geschäftsprozess als synonym verwendet.

Die Gestaltung, Steuerung und Kontrolle der Geschäftsprozesse geschieht durch das Pro-

zessmanagement. Siehe hierzu Kapitel 7.1.

Das Qualitätsmanagement besteht aus fünf Komponenten. Die Qualitätspolitik, Qualitätspla-

nung, Qualitätssicherung, Qualitätslenkung und Qualitätsverbesserung. [vgl. Wal11, S. 40f u.

KW08, S. 38]

Unter Qualitätspolitik wird die Ausrichtung des Unternehmens auf Qualität bezeichnet. Sie ist

Aufgabe des obersten Managements, wird schriftlich festgelegt und dient als Basis zur Ablei-

tung von Qualitätszielen für die Geschäftsebene.


29

Die Qualitätsplanung legt die Qualitätsziele fest. Qualitätsziele sind die Ergebnisse, die durch

das Qualitätsmanagement zu erreichen sind. Des Weiteren werden die zur Umsetzung benö-

tigten Ressourcen und Prozesse geplant und eingeführt. In der Softwareentwicklung werden

hier insbesondere genaue Spezifikationen der Anforderungen gefordert, um daraus die Quali-

tätsziele abzuleiten.

Qualitätssicherung ist der vertrauensbildende Teil des Qualitätsmanagements. Der Nachweis

über die Einhaltung der Qualitätsanforderungen wird erbracht und die eingesetzten Maßnah-

men des Qualitätsmanagements überprüft. Zudem ist Qualitätssicherung für die Dokumen-

tation der eingesetzten Methoden verantwortlich. Die Qualitätssicherung geht fließend in die

Qualitätslenkung über. Die Qualitätslenkung dient der Aufdeckung und Vermeidung von Feh-

lern im Prozess und beim Produkt. Dies kann zum einen konstruktiv, also durch Maßnahmen

zur Verhinderung von Fehlern, geschehen. Andererseits sind analytische Maßnahmen durch

die Prüfung der End- und Zwischenprodukte möglich.

Die Qualitätsverbesserung steigert die Fähigkeit des Unternehmens, Qualitätsanforderungen

zu erreichen. Dies geschieht durch kontinuierliche Prozessverbesserung oder die Steigerung

der Reifegrade der Prozesse.

Die Umsetzung des Qualitätsmanagement geschieht in einem Qualitätsmanagementsystem

(QMS). In der ISO 9000:2000 ist es als ein „System für die Festlegung der Qualitätspolitik

und von Qualitätszielen sowie zum Erreichen dieser Ziele“ definiert.

Kern des Qualitätsmanagementsystems ist die Aufbau- und Ablauforganisation. Die Organi-

sation wird durchgängig transparent gestaltet und gut dokumentiert, die Qualität fördernden

Maßnahmen direkt in den Ablauf eingebunden und mit messbaren Größen versehen. [vgl.

BW08, S.22ff]

Zur Umsetzung eines Qualitätsmanagementsystems im Unternehmen gibt es im Wesentlichen

zwei verschiedene Ansätze. Auf der einen Seite haben wir kontinuierliche Ansätze mit einer

problemorientierten Vorgehensweise, auf der anderen Seite stehen die modellbasierten Ansät-

ze mit einem lösungsorientierten Vorgehen. [vgl. Lig09, S. 11]

Kontinuierliche Ansätze

Die kontinuierlichen Ansätze bestehen aus fortlaufender Verbesserung gezielter Problemfel-

der der Organisation. Das Hauptaugenmerk liegt auf der Verbesserung der Prozesse. Konti-

nuierlichen Ansätzen liegt in der Regel der PDCA-Zyklus (bzw. Deming-Zyklus) zu Grunde.


30

PDCA steht für Plan-Do-Check-Act und wurde in den 1950ger Jahren von W. Edwards De-

ming entwickelt.

PDCA ist in vier Phasen unterteilt, mit denen Prozesse und deren Aktivitäten verbessert wer-

den sollen. [vgl. Koc11, S. 118f]

• Planen (plan)

Zu Beginn wird eine Ist-Analyse vorgenommen. Aufgrund der gewonnen Erkenntnis-

se wird ein Verbesserungsplan erstellt und Ziele für die weiteren Schritte festgelegt.

• Umsetzen (do)

Einleiten der nötigen Maßnahmen und Ausrollen des Verbesserungsplans im Unter-

nehmen.

• Überprüfen (check)

Die eingeführten Veränderungen werden durch erneute Aufnahme und Analyse von

Qualitätsindikatoren überprüft.

• Verbessern (act)

Bestehen Abweichungen zwischen Soll und Ist, sind die Phasen „Planen“ und „Um-

setzen“ erneut anzustoßen und solange zu durchlaufen, bis die Prozesse die gesetzten

Ziele erreichen. Bei Zielerreichung müssen Maßnahmen für die weitere Optimierung

und Einhaltung des Prozesses geplant und ergriffen werden.

Dieses Vorgehen erlaubt Verbesserungen gezielt zu priorisieren und kritische Probleme direkt

zu beheben. Das Qualitätsmanagementsystem wird direkt auf das Unternehmen zugeschnitten

und hilft die individuellen Stärken weiter auszubauen.

Es ist jedoch ein schwieriger und langwieriger Prozess, bis das gewünschte Maß an Optimie-

rung eingetreten ist.

Modellbasierte Ansätze

Modellbasierte Ansätze basieren auf standardisierten Vorgaben. Die im Unternehmen vor-

handenen Prozesse und Praktiken werden gegen ein Referenzmodell geprüft, in dem Refe-

renzprozesse und Best Practices festgehalten sind. Auf diese Weise ist der Stand des Quali-

tätsmanagements mit anderen Unternehmen vergleichbar.

Weiter ist es möglich, die Modelle auf das eigene Unternehmen anzuwenden und ein Quali-

tätsmanagementsystem gemäß erprobter Praktiken aufzubauen. Die Anforderungen an die


31

Prozesse und zu erreichenden Ziele werden beschrieben, wie genau der Prozess eingeführt

und umgesetzt wird, ist in den Modellen nicht enthalten.

Oft bieten die Modelle mehrere Reifegrade („Maturity Models“). Somit kann das Unterneh-

men selbst festlegen, bis zu welcher Stufe dem Modell gefolgt werden soll.

Zu den meisten Referenzmodellen gibt es Zertifizierungsmöglichkeiten, um seinen Prozess-

standard auch zu Marketingzwecken einzusetzen. [vgl. Hof08 S514ff]

Kontinuierliche und modellbasierte Vorgehen müssen sich nicht ausschließen. Ab einem ge-

wissen Grad verlangen modellbasierte Vorgehen die Einführung kontinuierlicher Methoden

zur weiteren Optimierung der eingeführten Prozesse.

Kontinuierliche Vorgehen können darüber hinaus gut zur Problemidentifikation eingesetzt

werden, um mit standardisierten Prozessen und Best Practices aus einem Referenzmodell

schneller zu Ergebnissen zu kommen. [vgl. Lig09, S. 13]

Qualitätsmanagement wird in der Softwareentwicklung meist zusammen mit konventionellen

Vorgehensmodellen benutzt. Die dokumentengetriebene Entwicklung mit ihren klaren Pro-

zessen unterstützt die Vorgaben des Qualitätsmanagement gut und integriert sich problemlos

in ein Qualitätsmanagementsystem. Der agilen Softwareentwicklung hingegen fehlen diese

Eigenschaften. Sie verzichtet bewusst auf fest definierte Prozesse und reichhaltige Dokumen-

tation. Dies führt zu Konflikten mit den Vorgaben der Qualitätsmanagementmodelle. Agile

Softwareentwicklung lässt sich jedoch in den Organisationsrahmen einbetten und bringt eige-

ne Praktiken zur Umsetzung von Qualitätsanforderungen mit.

Das Qualitätsmanagement beschreibt nicht nur die organisationsweiten Abläufe, sondern de-

finiert zusätzlich die Anforderungen zur Umsetzung eines Projekts. So beschreibt der zweite

Reifegrad des CMMI-Modells als ersten Schritt zur Einführung eines unternehmensweiten

Qualitätsmanagementsystems die Sicherstellung der Projektprozesse und ihrer Ergebnisse,

sowie das Überwachen, Überdenken und Verbessern der Vorgehensweisen. [CMMI] Ziel ist

die Definition eines standardisierten Projektablaufs um alle Projekte erfolgreich auf gleiche

Art und Weise durchzuführen.

Erst in den darauf folgenden Reifegraden werden organisationsweite Verbesserungsprozesse

implementiert.

Es lässt sich eine Sicht des Projektverantwortlichen und eine organisationsweite Sicht im

Qualitätsmanagement feststellen.


32

Die organisationsweite Sicht beschäftigt sich mit dem Aufbau einer Qualitätsmanagementor-

ganisation, einer Supportorganisation für Prozesse und Qualität. Das projektbezogene Quali-

tätsmanagement beschäftigt sich mit der Qualität der Projektprozesse, der End- und Zwi-

schenprodukte sowie der eingesetzten Ressourcen. Des weiteren werden vor- und nachgela-

gerte, sowie Übergangsprozesse betrachtet. [vgl. Wal11, S. 151f]

Durch diese Unterscheidung ist es möglich, dass Qualitätsmanagement des Projekts unabhän-

gig von der Organisation zu betrachten, in der es umgesetzt wird. Da das organisationsweite

Qualitätsmanagement in jedem Unternehmen auf eine andere Weise umgesetzt wird, lässt sich

keine allgemeine Aussage über die Einbindung von agilem Projektmanagement in dieses Sys-

tem geben. Die Projektprozesse sind im organisatorischen Qualitätsmanagement definiert,

liegen jedoch in der Verantwortung des Projektmanagements. Ebenso wird durch die meisten

Referenzmodelle vorgegeben, welche Prozesse im Projekt vorhanden und welche Tätigkeiten

durchgeführt werden müssen, jedoch nicht auf welche Weise sie im Projekt umzusetzen sind.

Statt durch streng reglementierte Prozesse können die Anforderungen des Qualitätsmanage-

ments an das Projekt auch durch agile Praktiken und Herangehensweisen erbracht werden.

Dadurch wird die Vorgehensweise des agilen Teams reifer und lässt sich besser auf größere

Teams skalieren, da die explizite Nutzung bestimmter Praktiken und die Ausführung spezifi-

scher Tätigkeiten gefordert wird. Auf der anderen Seite profitiert CMMI von einem Konzept

mit sinnvollen Techniken, die bisher noch keinen Eingang in das Modell gefunden haben.

Auf diese Weise ist es möglich, Qualitätsmanagementsysteme auch in der agilen Entwicklung

umzusetzen. [CMMI_Agile]

Im Bezug auf die Einführung externer Qualitätssicherung kann durch projektbezogenes Quali-

tätsmanagement die Zusammenarbeit der beiden Unternehmen verbessert und dadurch die

Softwarequalität erhöht werden. Hierfür ist es erforderlich, die Möglichkeiten von agiler

Softwareentwicklung, inklusive Scrum, für die Erweiterung mit Qualitätsmanagementmetho-

den auszuloten. Die Software-Qualitätssicherung ist eine projektspezifische Aufgabe. Die

organisationsweite Sicht ist für diese Aufgabe nicht von Relevanz, sie orientiert sich an den

Anforderungen der Unternehmen bezüglich Qualität und benötigt die Kennzahlen des Pro-

jekts. Daher wird das unternehmensweite Qualitätsmanagement nicht betrachtet, sondern

Schnittstellen zu diesem definiert.

Die Qualitätsplanung ist stark von den Anforderungen abhängig. In der agilen

Softwareentwicklung werden diese nicht vorher definiert. Die benötigte Qualität des


33

Produktes kristallisiert sich während der Entwicklung heraus. Die Qualitätszielbestimmung ist

daher dem agilen Prozess inhärent, jedoch nicht als eigenständige Funktion. Es ist dennoch

erforderlich, die eingesetzten Ressourcen zu planen. Zusätzlich entsteht durch den Einsatz

einer externen Qualitätssicherung ein Prozess außerhalb von Scrum. Dieser ist in der

Qualitätsplanung zu berücksichtigen und zu definieren.

Die Verwendung der Begriffe Qualitätslenkung und Qualitätssicherung sind in der Software-

entwicklung nicht eindeutig zu trennen. Obwohl laut allgemeiner Definition die Qualitätslen-

kung die prüfende und weisende und die Qualitätssicherung eine nachweisende Funktion in-

nehat, werden in der Literatur zur Software-Qualitätssicherung die produktorientierten Tests

der Qualitätssicherung als Funktionen zugeschrieben. [vgl. Hof08/Lig09 u. Wal11, S. 44f] Im

Gegensatz zum produzierenden Gewerbe, ist in der Softwareentwicklung eine ständige Pro-

duktprüfung notwendig. Es wird nur ein komplexes Produkt entwickelt, nicht eine hohe An-

zahl gleicher Produkte. Somit ist die Lenkung der Qualität sowie die Sicherstellung derselben

ein kontinuierlicher, entwicklungsbegleitender Prozess auf dem selben Werkstück, um dessen

Qualität zu erhöhen, während er in der Industrie stichpunktartiger Natur ist, um unter anderem

Ausschuss auszusortieren.

Da in dieser Arbeit die Einführung einer externen Software-Qualitätssicherung behandelt

wird, sind in diesem Kontext die prüfenden Maßnahmen gegenüber dem Produkt zu verste-

hen. Diese darf nicht mit der Qualitätssicherung und Qualitätslenkung verwechselt werden,

welche im Folgenden für die Qualität des übergeordneten Testprozesses verantwortlich sein

wird. Die Produktqualität wird allein durch die Software-Qualitätssicherung sichergestellt.

Qualitätsverbesserung stützt sich auf das Prozessmanagement. Das kontinuierliche Verbes-

sern der Prozesse führt zu einer Kostenreduktion und Steigerung der Zuverlässigkeit. [vgl.

FB08, S. 20] Da die Entwicklung in einem sich selbst regulierenden Prozess stattfindet, ist es

nicht möglich, eine Verbesserung von außen herbeizuführen. Es können jedoch die vor-, so-

wie nachgelagerten Prozesse, die Kommunikationsprozesse nach außen sowie zur externen

Qualitätssicherung definiert und einer kontinuierlichen Verbesserung unterworfen werden.


34

3.2 PROZESSQUALITÄT IN DER AGILEN SOFTWAREENTWICK-LUNG

Grundsätzlich ist es möglich, in Unternehmen aus dem IT-Sektor sowohl kontinuierliche als

auch modellbasierte Qualitätsmanagementansätze umzusetzen. Für die Prozessqualität in der

agilen Softwareentwicklung, insbesondere für den Zweck der Einführung einer externen Qua-

litätssicherung, ist der geeignete Ansatz zu identifizieren.

Referenzmodelle sind in der Softwarebranche weit verbreitet. Zum einen werden die konti-

nuierlichen Maßnahmen im Rahmen des Referenzmodells mit eingeführt, zum anderen bieten

sie eine gute Vergleichbarkeit zu Wettbewerbern. Große Auftraggeber setzen oft eine be-

stimmte Prozessreife bei Auftragnehmern voraus. Sie ist eine Bedingung für die Auftragsver-

gabe.

In der Literatur wird deutlich, dass Qualitätsmanagement im Softwareengineering noch nicht

den Stellenwert wie in der konventionellen Industrie erreicht hat. Der Schwerpunkt liegt hier

auf der Qualitätssicherung, der Rahmen des Qualitätsmanagements spielt eine untergeordnete

Rolle.

Deutlich wird jedoch, dass weder Qualitätsmanagement, Software-Qualitätssicherung oder

Vorgehensmodelle allein zum erfolgreichen Abschluss von IT-Projekten führen. Alle drei

sind erforderlich, um Projekte im größeren Umfang abzuwickeln.

Es darf jedoch zu Recht angezweifelt werden, ob ein umfassendes Qualitätsmanagement im-

mer angebracht ist. Ziel beim Aufbau eines Qualitätsmanagementsystems sollte nicht die un-

bedingte Einführung einer Methodik mit allen ihren Konsequenzen sein, sondern die Prozess-

und Produktqualität nachhaltig und kontinuierlich zu erhöhen. [vgl. Pet01, S. 203]

Die Rolle der Prozessqualität ist nicht zu vernachlässigen, da das Vermeiden von Fehlern und

eine Beschleunigung der Zusammenarbeit die Wertschöpfung erhöhen. Es ist zu beachten,

dass die Prozesse vor allem für die wichtigsten Aufgaben vorhanden sind und reibungslos

ablaufen.

Auf Projektebene sind verschiedene Aufgaben im Rahmen des Qualitätsmanagements zu er-

füllen, um den Erfolg des Projekts sicherzustellen. [vgl. Wal11, S. 152ff] Dazu zählen das

Managen kritischer Entscheidungen, Beschaffungs- und Lieferantenmanagement, Architek-

turmanagement, Risikomanagement sowie Projekt-, Programm- und Portfoliomanagement.

3.2 PROZESSQUALITÄT IN DER AGILEN SOFTWAREENTWICKLUNG

35

Die verschiedenen Aufgaben verfolgen das Ziel, das Projekt und die darin erfolgende Ent-

wicklung in ihrer Komplexität zu erfassen und durch verschiedene Maßnahmen zu vereinfa-

chen.

Sie sind umfassend in verschiedenen Standards und Reifegradmodellen beschrieben. Wie und

in welcher Form diese Aufgaben im Projekt umgesetzt werden, ist projektspezifisch und

hängt vor allem von der Größe und Komplexität der entwickelten Software ab. Den klaren

Vorgaben an Aufgaben, sowie der damit einhergehenden Dokumentation stehen die agilen

Methoden diametral gegenüber. Die Aufgaben mögen durch verschiedene Praktiken, aber

auch vollständig gemäß der Beschreibung, in der Entwicklung umgesetzt werden. Die Ent-

scheidung, ob sie umgesetzt werden, obliegt jedoch der Verantwortung des Teams und nicht

des Managements. Anderenfalls wäre die Selbstverwaltung des agilen Teams nicht mehr ge-

geben.

Kontinuierliche Qualitätsmanagementansätze hingegen besitzen mehrere Gemeinsamkeiten

mit der agilen Softwareentwicklung. So zeigt Poppendieck [Pop01] die Anwendung von Lean

Manufacturing und TQM auf die Softwareentwicklung. Lean Manufacturing zielt darauf ab,

Verschwendung in den Prozessen zu reduzieren und durch kontinuierliche Verbesserung Po-

tentiale zu nutzen. Ein Konzept, das in das agile Umfeld mit seiner iterativen Vorgehensweise

und dem Fokus auf lauffähige Software passt. Während TPS, TQM, Six Sigma und weitere

kontinuierliche Qualitätsmanagementmodelle viele verschiedene Methoden zur Verbesserung

heranziehen, haben sie die kontinuierliche Prozessverbesserung gemeinsam. [vgl. BW08, S.

259ff] Es soll sich zur Betrachtung des übergeordneten Testprozesses auf eine kontinuierliche

Prozessverbesserung bezogen werden. Praktiken wie “Do it Right the First Time”, “Empower

Workers” und weitere TQM- und Lean- spezifische Methoden sind schon in Scrum umge-

setzt. Es fehlt jedoch eine Messung der Wertsteigerung und Performanz, um das Management

mit objektiven Daten über das Projekt zu versorgen. [vgl. And04, S. 257] Diese werden be-

nötigt, um den Erfolg des Projekts zu messen und Verbesserungsmaßnahmen zu steuern.

Kontinuierliche Prozessverbesserung kann auf zwei Wegen erreicht werden, Bottom Up und

Top Down. Zum einen können Verbesserungsideen von den Mitarbeitern ausgehen. Dies ist

in Scrum der Fall, am Ende von jedem Sprint setzt sich das ScrumTeam zusammen und be-

schließt Verbesserungen für die nächste Iteration. Zum anderen kann das Management anhand

zuvor definierter Prozesskennzahlen die Leistung der Prozesse beurteilen und Änderungen

anstoßen. Bei aktuellen Qualitätsmanagementmodellen werden beide Methoden angewandt.


36

[vgl. Koc11, S. 42f] Es ist erforderlich das agile Modell, in diesem Falle Scrum, um die Erhe-

bung von Prozesskennzahlen zu erweitern.

Scrum verfügt über kein Planungsinstrument, um vorab den Mehrwert zu bestimmen, der

während eines Sprints geschaffen wird. Im Sprint Backlog sind User Stories nicht vollständig

vorhanden. Stattdessen werden große Stories in Tasks aufgeteilt. Somit steht die Erledigung

eines Backlog Items nicht im direkten Verhältnis zum Kundennutzen. Erst wenn alle Tasks

einer Story umgesetzt wurden, kann eine Anforderung als erfüllt angesehen werden. Die

Schätzung des Aufwandes einer Story und die Aufteilung in Tasks dienen dazu, das Sprint

Backlog zu füllen. Es werden jedoch nicht alle Stories im Backlog während einer Iteration

umgesetzt. Somit ist es nicht möglich, eine Kosten-Nutzen-Schätzung vor dem Projekt durch-

zuführen, sondern erst nach Abschluss einer Iteration.

Außerdem werden keine Metriken festgehalten. Befindet sich die User Story in der Entwick-

lung, werden lediglich Mann-Stunden aufgenommen. Diese sind jedoch nicht aussagekräftig

für den Prozess, da dadurch Behinderungen des Prozessablaufs nicht aufgedeckt werden. Der

genaue Weg der User Story durch das Team wird nicht erfasst.

Eine Methode zur Optimierung des Durchsatzes ist die Theory of Constraints. Sie besagt, dass

es zu einer Zeit immer nur einen Engpass im Prozess geben kann. Zur Auflösung des Engpas-

ses müssen entweder alle Aktivitäten auf das Niveau des Engpasses herabgesenkt oder der

Engpass erweitert werden. Nach Auflösen eines Engpasses, entsteht an anderer Stelle ein

neuer. Dadurch entsteht ein Kreislauf, in dem jedes Mal der Engpass gefunden und aufgeho-

ben werden muss. Dies lässt sich auch in der Softwareentwicklung anwenden. [vgl. And04, S.

35] Laufen die User Stories an einer Stelle auf, zum Beispiel vor der Integration, handelt es

sich hier um einen Flaschenhals. Es sollten nun Maßnahmen ergriffen werden, um besagte

Aufgabe zu beschleunigen.

Zur Kontrolle des Prozesses werden im industriellen Prozessmanagement verschiedene Kenn-

zahlen herangezogen. [vgl. FB08, S. 46f] Dies können unter anderem die Anzahl der Prozess-

instanzen, die Durchlaufzeit, Pünktlichkeit oder Zuverlässigkeit sein. Für jede Kennzahl sind

die Kriterien nachvollziehbar zu definieren, Messpunkte zu etablieren und die Daten zu erhe-

ben.

Die agile Softwareentwicklung sieht keine Messpunkte zur Datenerhebung vor.

3.2 PROZESSQUALITÄT IN DER AGILEN SOFTWAREENTWICKLUNG

37

David Anderson [And04] hat verschiedene Punkte aufgezeigt, an denen es möglich ist, Mes-

sungen vorzunehmen. Hierfür bezieht er sich auf Feature Driven Development. Die einzelnen

Feature dienen als Bezugspunkt. Zu Beginn der Entwicklung werden die einzelnen Features

geschätzt. Während die Features die Entwicklung durchlaufen, wird ihr Status regelmäßig

aktualisiert. So kann ständig abgelesen werden, welche Aktivität wie viel Zeit in Anspruch

genommen hat und wo sich die einzelnen Features im Entwicklungsprozess befinden. Die

Entwicklung wird dadurch transparent, Engpässe sind frühzeitig erkennbar. Die Zeiten lassen

sich aufschlüsseln und können direkt mit der Schätzung verglichen werden. Es ist ersichtlich,

welche Tätigkeit schlecht geschätzt wurde. So liegen Daten vor, auf die zukünftige Schätzun-

gen aufbauen können. In Scrum ließe sich dies ebenso umsetzen. Die Tasks dienen als Refe-

renz, mehrere Tasks zusammen gehören zu einer User Story, also einem Feature. Hierbei ist

zu beachten, dass nur Tasks mit Kundennutzen positive Kennzahlen liefern können. Tasks für

Bugfixes würden zwar als abgeschlossene Aufgaben gelten und die Organisation effizient

aussehen lassen, jedoch keinen zusätzlichen Kundenutzen generieren, da die Fehler nach

Möglichkeit gar nicht erst entstehen sollten.

Nur Kennzahlen mit einem Fokus auf Wiederholbarkeit und Zuverlässigkeit der Prozesse

sollten erfasst werden. Kennzahlen, die der Performanzmessung einzelner Teammitglieder

dienen, sind der selbstständigen Arbeit des Teams nicht zuträglich. Vergleichswerte sind hier-

für in der Softwareentwicklung kaum zu setzen. Eine traditionelle Metrik ist die Messung von

geschriebenen Zeilen Quellcode. Hier steht Quantität Qualität gegenüber, es lässt sich keine

Aussage über die Brauchbarkeit des geschriebenen Codes treffen. So lassen sich auch Metri-

ken über Fehler in der agilen Entwicklung schwer erstellen, da viele Fehler nach direktem

Feedback sofort behoben werden. Die Dauer zwischen Fertigstellen der Funktion und Test,

sowie Auftreten von Fehlern und deren Bugfix, sollte dieser nicht direkt geschehen, lässt sich

jedoch bestimmen und gibt Aufschluss über die Integration des Testprozesses. [vgl. CG09, S.

74f]

Durch die Aufnahme von Kennzahlen und die kurzen Iterationen ist es möglich, den Entwick-

lungsprozess ständig zu verbessern. Es ist zu vermeiden, ein Gefühl der Überwachung bei den

Teammitgliedern hervorzurufen. Wie bei jeder organisatorischen Veränderung ist Akzeptanz

ein wichtiger Faktor. [vgl. FB08, S. 180f] Aus diesem Grund sollte das Team in alle Ent-

scheidungsprozesse eingebunden werden und eigene Ideen einbringen können. Eingriffe in


38

die einzelnen Arbeitsabläufe während des Sprints und in die einzelnen Arbeitsweisen der

Teammitglieder sind grundsätzlich zu unterlassen.

Das Management kann mit den aufgenommenen Informationen grundsätzliche Entscheidun-

gen fällen. Ein Vergleich zwischen der angewandten Methodik und anderen Projekten wird

möglich. Zusätzlich kann bestimmt werden, ob die Einbeziehung der externen Qualitätssiche-

rung einen Nutzen erbringt, oder die Entwicklung zu sehr behindert. Eine Kosten-Nutzen-

Beurteilung zum Weiterführen oder Stoppen des Projektes muss auf dieser Ebene durchführ-

bar sein. Entscheidungen über den konkreten Projektablauf obliegen jedoch in der Regel nicht

dem Management, sondern dem Projektleiter. Diese Rolle ist in Scrum jedoch nicht vorgese-

hen. Alternativ ist es möglich, ein Gremium aus allen Projektbeteiligten zu gründen, dessen

Aufgabe es ist, die Zahlen vom letzten Sprint zu analysieren und Verbesserungen für den Pro-

zess abzuleiten. Eine Erweiterung der Sprint Retrospective bietet sich dafür an. Auf diese

Weise ist das Team mit eingebunden und Kunde, Project Owner sowie Scrum Master können

ihr Wissen einbringen. Zusätzlich können Spezialisten zu dem Gremium hinzu gezogen wer-

den. Die Verbesserung des Prozesses wird dadurch effektiv gestaltet und eine hohe Akzeptanz

beibehalten.

Um Qualitätsmanagement in einen agilen Entwicklungsprozess einzuführen ist ein kontinuier-

licher Ansatz einem modellbasierten Ansatz vorzuziehen. Um Daten als Grundlage für die

Optimierung zu sammeln sind die User Stories ein guter Ansatzpunkt. An ihrem Durchfluss

kann die Dauer sowie die Auslastung der einzelnen Arbeitsschritte abgelesen werden. In der

Sprint Retrospective können die Verbesserungen von allen Projektbeteiligten für den nächsten

Sprint festgelegt werden.

3.3 ZUSAMMENFASSUNG

Um eine langfristige Optimierung der Entwicklung zu ermöglichen, wurde die Verwendung

von Qualitätsmanagement in agilen Vorgehensmodellen betrachtet. Zunächst ist Qualität als

„Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“ [ISO 9001:2005-01] de-

finiert worden. Die Qualität eines Softwareprodukts erschließt sich folglich aus dem Ausmaß,

in dem eine bestimmte Anzahl an Anforderungen umgesetzt wird. Das Qualitätsmanagement

beschäftigt sich damit, alle Maßnahmen zum Erreichen der Anforderungen zu planen, zu lei-

ten und zu steuern. Es setzt sich aus den Teilbereichen Qualitätspolitik, Qualitätsplanung,

Qualitätssicherung, Qualitätslenkung und Qualitätsverbesserung zusammen. Für die

3.3 ZUSAMMENFASSUNG

39

Umsetzung von Qualitätsmanagement im Unternehmen gibt es kontinuierliche und modellba-

sierte Ansätze. Modellbasierte Ansätze basieren auf Referenzmodellen, die vorgeben, durch

welche Praktiken die Qualität im Unternehmen sichergestellt werden kann. Kontinuierliche

Ansätze setzen hingegen auf einen stetigen Verbesserungsprozess. Eine ständige Optimierung

der innerbetrieblichen Abläufe führt das Unternehmen langsam zur gewünschten Reife.

Die Betrachtung der beiden Ansätze bezüglich ihrer Eignung zum Einsatz in einem agilen

Entwicklungsprojekt ergab ein höheres Potential für kontinuierliche Methoden. Während mo-

dellbasierte Ansätze die Selbstverwaltung des Teams einschränken, ist für kontinuierliche

Ansätze durch die kurzen Iterationen und die Sprint Retrospective bereits der Grundstein ge-

legt. Um eine Messbarkeit des Prozesses zu gewährleisten, bietet sich die Betrachtung der

User Stories an. Unter anderem geben ihre Bearbeitungs-, Liege- und Durchlaufzeit einen

interessanten Einblick in die Auslastung der einzelnen Aktivitäten und Rollen.

Es wurde gezeigt, dass sich agile Methoden mit einer abgeschwächten Form des Qualitätsma-

nagements vereinen lassen. Der Entwicklungsprozess sollte folglich um entsprechende Me-

chanismen erweitert werden, damit eine hohe Produktqualität ermöglicht wird.

41

4 SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD

Herkömmliches Qualitätsmanagement bezieht sich überwiegend auf die Prozessqualität und

steuert darüber die Produktqualität. In der Softwareentwicklung nimmt die Produktqualität

jedoch eine Sonderrolle ein. Daher muss zusätzlich die Software-Qualitätssicherung im Ein-

zelnen betrachtet werden. Die gängigen Modelle kommen aus der konventionellen Software-

entwicklung, während sich in der agilen Softwareentwicklung eigene Regeln etabliert haben.

Die agile und die konventionelle Softwareentwicklung müssen voneinander abgegrenzt wer-

den. Es sind geeignete Software-Qualitätssicherungsmaßnahmen zu identifizieren, die hohe

Qualität in agilen Modellen ermöglichen.

4.1 RELEVANZ UND EINORDNUNG

In der Softwareentwicklung muss die Qualität des Produktes auf zwei verschiedenen Wegen

sichergestellt werden. Sowohl die Gestaltung eines reibungslosen Prozesses, als auch die Prü-

fung des Produktes sind notwendig.

Während der Softwareentwicklung entsteht ein komplexes, einzigartiges Produkt. Im Gegen-

satz zur Massenproduktion muss hier jedes Ergebnis der Entwicklung eingehend geprüft wer-

den. Somit kann die Sicherstellung eines reibungslosen Prozessablaufs keine eingehende Pro-

duktprüfung ersetzen.

Die Qualitätssicherung ist ein Teilgebiet des Qualitätsmanagements. Im Qualitätsmanagement

liegt der Schwerpunkt klar auf der Prozessoptimierung. Daher beschäftigt sich die Qualitätssi-

cherung hauptsächlich mit der Sicherstellung der Prozessqualität durch die Prüfung der Wirk-

samkeit des Qualitätsmanagements, Dokumentation, Zertifizierung und dem Einsatz von Ver-

besserungsprogrammen. [vgl. Wall11, S. 45f]

Die Software-Qualitätssicherung nimmt jedoch eine Sonderrolle ein. Durch den stark pro-

duktbezogenen Ansatz der Softwareentwicklung ist die Software-Qualitätssicherung nicht

schwerpunktmäßig auf die Prozessqualität, sondern zusätzlich auf die Sicherstellung der Pro-

duktqualität ausgelegt. Die prozessbezogenen Maßnahmen wurden bereits in Kapitel 3 darge-

legt.

KAPITEL 4: SOFTWARE-QUALITÄTSSICHERUNG IM AGILEN UMFELD

42

Die produktbezogenen Maßnahmen der Qualitätssicherung lassen sich in zwei Bereiche auf-

teilen, die konstruktive und die analytische Qualitätssicherung. Ersteres dient zur Verhinde-

rung von Fehlern während der Entwicklung, Letzteres zum Aufdecken möglicher Fehler in

den verschiedenen Artefakten. [vgl. Pet01, S. 42] Als Artefakte werden Dokumente, Quellco-

de und Programme bezeichnet, die während der Entwicklung entstehen, wobei auch Zwische-

nergebnisse unter den Begriff fallen.

Konstruktive QS

Die konstruktive Qualitätssicherung ist darauf ausgerichtet, die Qualitätsanforderungen gleich

in das Softwareprodukt hinein zu entwickeln. Petrasch [vgl. Pet01, S.43ff] unterscheidet drei

verschiedene konstruktive Qualitätssicherungsmaßnahmen. Er nennt organisatorische Maß-

nahmen, technische Maßnahmen und personelle Maßnahmen.

Unter organisatorischen Maßnahmen wird nicht die Aufbauorganisation des Unternehmens,

sondern die Organisation der Softwareentwicklung mit Hilfe von Vorgehensmodellen und

Methoden betrachtet. Technische Maßnahmen betreffen vor allem die Unterstützung der Ent-

wicklung durch Werkzeuge. Dies könnten zum einen Computer Aided Software Engineering

(CASE) Werkzeuge sein, aber auch Werkzeuge zur Unterstützung des Projektmanagements,

der Planung, Dokumentation und Automatisierung.

Unter personelle Maßnahmen fällt die Besetzung der im Qualitätsmanagement festgelegten

Rollen.

Hoffmann [vgl. Hof08, S. 65ff] hingegen sieht in der konstruktiven Qualitätssicherung vor

allem Richtlinien und Standards für den Aufbau des Quellcodes sowie der Dokumentation.

Der Begriff der konstruktiven Qualitätssicherung ist demnach nicht klar abgegrenzt und wird

in der Literatur verschieden weit gefasst.

Der Begriff der konstruktiven Qualitätssicherung lässt sich nicht so einfach auf verschiedene

Teilbereiche einschränken. Im Folgenden werden alle Maßnahmen die a priori für eine hohe

Qualität im Softwareprodukt sorgen als konstruktive Qualitätssicherung verstanden. Dies gilt

sowohl für die organisatorischen, technischen und personellen Maßnahmen als auch für Rich-

tlinien und Standards.

4.1 RELEVANZ UND EINORDNUNG

43

Analytische QS

Die analytische Qualitätssicherung beschäftigt sich mit dem Aufdecken von Fehlern innerhalb

der einzelnen Artefakte des Softwareentwicklungsprozesses. Als Artefakte werden Dokumen-

te, Quellcode und Programme bezeichnet, die während der Entwicklung entstehen, wobei

auch Zwischenergebnisse unter den Begriff fallen.

Bei einer vollständigen Qualitätssicherung würde jedes Ergebnis und Zwischenergebnis ge-

prüft werden, welches während des Entwicklungsprozesses entsteht. Dies ist jedoch mit ei-

nem sehr hohen Aufwand verbunden. Vor Entwicklungsbeginn werden deshalb bestimmte

Artefakte ausgewählt und die Prüfmethoden festgelegt.

Für Softwaretests hat sich ein stufenartiges Vorgehen etabliert, jede Testphase wird als Test-

stufe bezeichnet. Die Teststufen wurden aus dem V-Modell abgeleitet und sind gleichwertig

zur Entwicklung. Sie lassen sich auch auf andere Vorgehensmodelle übertragen. [vgl. SL10,

S. 41 ff]

Es gibt vier Teststufen, der Unittest, der Integrationstest, der Systemtest und der Abnahme-

test. Sie folgen in genannter Reihenfolge aufeinander.

Jede Teststufe ist eng mit einer Konstruktionsphase verbunden. Die Spezifikation der jeweili-

gen Phase wird zur Erstellung der Testfälle herangezogen. So werden für jede Konstruktions-

phase passende Testfälle geschrieben. Die Erstellung der Tests beginnt so früh wie möglich.

Die vier Teststufen unterscheiden sich stark. Für jede Teststufe gibt es unterschiedliche Me-

thoden, Tester und Artefakte. Die Teststufen werden in Kapitel 4.2 näher erläutert.

Die Qualitätssicherungsmaßnahmen können im Unternehmen selbst oder über externe Dienst-

leister erbracht werden. Unter externer Qualitätssicherung wird im Rahmen dieser Arbeit ein

unabhängiger Dienstleister verstanden, der Aufgaben zur Qualitätsprüfung wahrnimmt.

Aufgrund seiner Position ist es für ein externes Unternehmen nur schwer möglich die Sicher-

stellung des Prozessablaufs zu gewährleisten oder die Definition konstruktiver Maßnahmen

vorzunehmen. Dies ist über punktuelle Beratungsleistungen möglich, sollte auf lange Sicht

jedoch im Unternehmen selbst gehandhabt werden.

Bei analytischen Maßnahmen ist es möglich, diese dauerhaft an Dritte zu übergeben. Das ex-

terne Testteam wird mit den fertiggestellten Artefakten beliefert und führt zuvor festgelegte


44

Tests durch. Die Ergebnisse werden an den Auftraggeber zurück geliefert. Im Fehlerfall wer-

den dort Maßnahmen zur Produktverbesserung eingeleitet.

Durch eine unabhängige analytische Qualitätssicherung lassen sich verschiedene Vorteile

nutzen.

• Die Unabhängigkeit der Tester verhindert eine Einflussnahme der Entwicklungsabtei-

lung. Ungeschönte Ergebnisse sind gewährleistet.

• Fehler am eigenen Produkt zu finden widerstrebt Entwicklern, daher sind unabhängige

Tester objektiver.

• Durch die Trennung von Test und Entwicklung ist es möglich, Interpretationen und

Annahmen der Entwickler kritisch zu hinterfragen.

• Die Einbindung einer unabhängigen Institution zwingt dazu, das Testen schon früh zu

planen.

• Auf Testen spezialisierte Dienstleister verfügen über ein hohes Spezialwissen und die

nötigen Werkzeuge.

Es können jedoch auch Nachteile entstehen, deren Vermeidung eine gute Organisation erfor-

dert.

• Bei einem eigenständigen Testteam kann es zu starker Isolation kommen, so dass die

Kommunikation zwischen Testern und Entwicklern behindert wird.

• Durch Fehlplanung kann der unabhängige Test die Entwicklung behindern, da auf Er-

gebnisse gewartet werden muss.

• Die Entwickler übernehmen weniger Verantwortung für die Qualität, sondern übertra-

gen diese auf das Testteam [vgl. SL 10, S. 173]

Bei einer nach außen vergebenen Entwicklung entsteht ein weiterer Vorteil, da die externe

Qualitätssicherung zusätzlich an den Auftraggeber berichten kann. Dadurch ist dieser durch

eine unabhängige Stelle über den Stand der Entwicklung informiert und kann bei Problemen

dementsprechend steuernd eingreifen.

Zu beachten ist, dass die externe Qualitätssicherung von dem Auftragnehmer für die Entwick-

lung nicht als feindlich gesinnt erachtet werden darf. Dies kann zu einer Erschwerung der

Zusammenarbeit bis zu einer vollständigen Verweigerung führen. Eine transparente Gestal-

tung von Aufgaben und Prozessen ist nötig, eine enge Integration der externen Institution in

4.2 KONVENTIONELLES TESTEN

45

den Entwicklungsprozess notwendig. Das Schaffen von Akzeptanz sollte gerade zu Beginn

der Entwicklung eine hohe Priorität erhalten.

Die Einbindung externer Qualitätssicherung in einen Entwicklungsprozess erfordert ein hohes

Maß an Planung und sollte beim Aufbau des Qualitätsmanagementsystems mit beachtet wer-

den.

In der Regel wird nicht die gesamte Qualitätssicherung ausgelagert. Es werden sogenannte

„Blended Service Delivery“ Modelle genutzt, bei denen die Leistungen zum Teil lokal und

zum Teil extern erbracht werden. Nur 14 Prozent der in einer Studie von Pierre Auodin Con-

sultants Befragten konnten sich vorstellen mehr als 50 % der Testaktivitäten auszulagern. Es

war kein Trend über Anzahl und Art der auszulagernden Testaktivitäten abzulesen, da die

getroffenen Maßnahmen sich an den individuellen Gegebenheiten einzelner Unternehmen

orientierten. [SQS Market Research 2011] Interne und externe Qualitätssicherungsmaßnah-

men sind daher aufeinander abzustimmen.


Es gibt drei unterschiedliche Prüftechniken, White-Box-Tests, Black-Box-Tests und Grey-

Box-Tests. [vgl. Hof08, S. 174ff] Die Software wird im Falle dieser Techniken jeweils als

Box betrachtet. Bei einem White-Box-Test ist das Innere der Box sichtbar, zur Erstellung der

Tests wird der interne Aufbau des Produkts herangezogen. Daher sind sie auch unter dem

Namen strukturorientierte Tests bekannt. Bei Black-Box-Tests ist der Inhalt der Box nicht

erkennbar, die Tests werden aus funktionalen Beschreibungen abgeleitet. Diese Art von Tests

werden auch funktionale Tests genannt. Der Grey-Box-Test ist ein Hybrid zwischen White-

Box- und Black-Box-Test. Er wird häufig in der agilen Softwareentwicklung beim Test-First-

Ansatz verwendet. Die Tests werden aus der funktionalen Beschreibung abgeleitet und vor

der Unit geschrieben, die Ausführung findet jedoch auf Codeebene statt. [vgl. Wall11, S. 299]

Bei den oben aufgeführten Testtechniken handelt es sich um so genannte dynamische Tests,

da der Quellcode ausgeführt wird. Eine weitere Prüfmethode sind sogenannte statische Tests.

Das Testobjekt wird nicht zur Ausführung gebracht, sondern einer Analyse unterzogen. Die

Methode kann auf jedes Dokument angewandt werden, das relevant für die Softwareerstel-

lung ist. Zusätzlich lassen sich Werkzeuge auf Dokumente mit formaler Struktur anwenden.


46

Auf diese Weise lassen sich Metriken aus dem Quelltext gewinnen, um unter anderem die

Einhaltung von Programmierkonventionen zu prüfen. [vgl. SL10, S. 81ff]

Das konventionelle Testen in einem linearen Vorgehensmodell baut auf die vier Teststufen

auf. Jede Teststufe testet andere Merkmale des Produkts und zieht dazu unterschiedliche Spe-

zifikationen heran.

Die erste Teststufe ist der Unittest. Als Unit wird die kleinste sinnvolle testbare Einheit der

Software bezeichnet. Dies sind in der Regel Prozeduren, Klassen oder Objekte. Die Unit wird

aus dem Kontext des Programms heraus gelöst und unabhängig vom Gesamtsystem getestet.

Dadurch werden externe Einflüsse ausgeschlossen und die Ursachen sind leichter zu identifi-

zieren. Unittests werden von den Entwicklern durchgeführt. Die Tests werden anhand des

Quellcodes erstellt und automatisiert. Folglich handelt es sich um White-Box-Tests. Die Aus-

führung der Module findet in einem Testrahmen statt. Die aufrufenden und aufgerufenen

Komponenten werden durch Treiber und Dummies ersetzt, solange die Originale nicht fertig

sind. Durch die Automatisierung ist es möglich, Unittests schnell und oft auszuführen. [vgl.

Lig09, S. 371]

Ein neuerer Ansatz ist das sogenannte Test-Driven-Development, durch den der Test-First-

Ansatz umgesetzt wird. Der Test wird vor Implementierung der Unit geschrieben. Die Unit

wird vom Entwickler später erstellt und so lange verfeinert, bis sie alle Tests besteht. Durch

Unittests soll zum einen die richtige und fehlerfreie Implementierung der Unit sichergestellt

werden, zum anderen wird durch das Ausführen aller Unittests auf ungewollte Seiteneffekte

in den restlichen Units geprüft. [vgl. SL10, S. 51]

Die zweite Teststufe ist der Integrationstest. Er erfolgt nach dem Unittest während der Integ-

ration der einzelnen Module zu einem Gesamtsystem. Die einzelnen Units werden schrittwei-

se zusammengeschlossen und gemeinsam getestet. Es wird sichergestellt, dass die Kompo-

nenten auch zusammengeschlossen ein funktionsfähiges System ergeben. [vgl. Hof08, S. 163]

Die Tests basieren auf dem Software- und Systemdesign, sie sind somit White-Box-Tests. Die

Ausführung der Tests erfolgt nach wie vor automatisch, der Testrahmen wird nach Möglich-

keit von den Unittests wieder verwendet.

Zum Zusammenfügen der Units können verschiedene Integrationsstrategien verfolgt werden.

Die Ansätze reichen von Bottom-Up, dem schrittweise Integrieren von der untersten Schicht


47

an, bis zum gleichzeitigen Aneinanderfügen aller Units, genannt Big-Bang Integration. [vgl.

SL10, S. 54ff]

Die dritte Teststufe ist der Systemtest. Während die vorherigen Teststufen auf Grundlage der

technischen Spezifikation stattfanden, zieht der Systemtest die Anforderungen als Referenz

heran. Da nun die Funktionen der Software im Vordergrund stehen, sind Systemtests Black-

Box-Tests. Das Testobjekt wird aus Sicht der Anwender betrachtet. Spätestens ab dieser Pha-

se sollten die Tests nicht mehr von Entwicklern durchgeführt werden, sondern von unabhän-

gigen Testern. Bisher wurde die Software nur verifiziert. Dies bedeutet, sie wurde auf Kon-

formität zur Spezifikation geprüft. [vgl. SL10, S. 60f, 173f] Nun wird die Software auch vali-

diert, es erfolgt nicht nur eine Prüfung, ob das System richtig reagiert, sondern auch, ob die

Bedürfnisse des Kunden richtig verstanden und umgesetzt wurden. [vgl. Wall11, S. 252]

Der Systemtest umfasst mehrere Tätigkeiten, um die verschiedenen Aspekte der Software zu

testen. Um sicherzustellen, dass die Funktionalität der Software richtig umgesetzt wurde,

werden sogenannte Funktionstests durchgeführt. Das Verhalten des Systems unter Last wird

durch Lasttest beurteilt. Für Überlastung über die Leistungsgrenzen hinaus und die Simulation

von teilweisen Systemausfällen, sind Stresstests zuständig. Ein weiterer wichtiger Test ist der

sogenannte Regressionstest, der besonders bei einer inkrementellen Entwicklung nicht zu

vernachlässigen ist. Hierbei handelt es sich um wiederholbare, meist automatisierte Testfälle.

Sie werden nach Fertigstellung einer neuen Version ausgeführt, um Seiteneffekte von neuen

oder veränderten Funktionen auszuschließen. Um das System unter möglichst produktivnahen

Bedingungen zu testen, werden Betatests durchgeführt. Da Betatests häufig zusammen mit

dem Kunden durchgeführt werden, gehen diese in die nächste Testphase über. [vgl. Lig09, S.

377]

Der Abnahmetest ist die letzte Teststufe und findet kurz vor der Inbetriebnahme der Software

statt. Der Test wird selbstständig oder mit Unterstützung durch Tester vom Kunden durchge-

führt. Sein Hauptzweck ist die Validierung der Software vor der Abnahme. Der Kunde soll

durch den Test feststellen, ob die Software seinen Anforderungen genügt. Hierbei sind drei

verschiedene Perspektiven zu beachten. Die zukünftigen Nutzer sind für die Prüfung der

Software auf ihre Eignung zur Verrichtung der vorgesehenen Aufgaben im geplanten Ein-

satzgebiet verantwortlich. Weiter müssen die vertraglichen Aspekte beachtet werden. Es ist

festzustellen, ob alle zuvor geforderten Leistungen erbracht wurden. Schlussendlich ist das


48

neue System in die Systemlandschaft einzufügen, um die Integration in das bestehende Ge-

samtsystem zu überprüfen.

Technische Fehler sollten in dieser Testphase weitestgehend eliminiert worden sein. Eine be-

sondere Aufmerksamkeit sollten die Schnittstellen zu anderen Systemen im Unternehmen

bekommen. [vgl. SL10, S. 63ff]

ABBILDUNG 4.1: DOKUMENTE NACH STANDARD IEEE 829 [ENTNOMMEN AUS IEEE829]

Neben dem Durchführen der Tests kommt der Software-Qualitätssicherung auch die Aufgabe

zu, die Planung, die Testfälle sowie die Ergebnisse zu dokumentieren. Die Dokumentation

des Testprozesses ist in dem Standard IEEE 829 geregelt. Er fordert insgesamt acht verschie-

dene Dokumente. In Abbildung 4.1 ist der Zusammenhang der Dokumente zu erkennen. Zwei

Kategorien von Dokumenten lassen sich unterscheiden: die für die Planung und die für die

Durchführung. In den Planungsdokumenten wird der Test vorbereitet. Es wird ein Plan für

den Test erstellt und die Testfälle spezifiziert. Die Reihenfolge zur Abarbeitung der Testfälle

wird in einem weiteren Dokument festgelegt. Während der Durchführung steht die Protokol-

lierung und das Erstellen von Berichten im Vordergrund.

4.3 QUALITÄTSSICHERUNG IN DER AGILEN SOFTWAREENTWICKLUNG

49

4.3 QUALITÄTSSICHERUNG IN DER AGILEN SOFTWAREENT-WICKLUNG

Das Konzept des starren phasenorientierten und dokumentengetriebenen Testens steht den

agilen Prinzipien diametral gegenüber. Flexible Prozesse, kurze Entwicklungszyklen und

knappe Anforderungsbeschreibungen lassen keinen Platz für einen eigenständigen, umfassen-

den Testprozess mit Fokus auf den Spezifikationen. Dennoch haben sich die Praktiken be-

währt und wurden zu Recht als Standard etabliert. Daher ist das Vorgehen nicht von vornhe-

rein abzulehnen. Vielmehr ist es nötig, die konventionelle Qualitätssicherung zu verschlanken

und auf die geforderten Eigenschaften agiler Methoden anzupassen.

Agile Softwareentwicklung baut stark auf konstruktive Qualitätssicherungsmaßnahmen auf.

Dies beginnt schon mit kurzen Releasezyklen und einer engen Zusammenarbeit mit dem

Kunden, wodurch die Software regelmäßig validiert wird. Durch die kontinuierliche 40-

Stundenwoche wird Überlastung der Mitarbeiter vermieden und damit Flüchtigkeitsfehlern

vorgebeugt. Beim Pair Programming existiert ein kontinuierliches Code-Review, weil jedes

Stück Quelltext von zwei Entwicklern gleichzeitig betrachtet wird. Aus diesen und ähnlichen

Praktiken ist zu erkennen, dass Fehlervermeidung höchste Priorität hat. Als analytische Quali-

tätssicherungsmaßnahme werden in der Regel nur der Unit- und Integrationstest thematisiert.

Hier hat sich der Test-First-Ansatz durchgesetzt, des Weiteren sollte keine Unit ohne zugehö-

rige Tests existieren. Im Idealfall sollte die Software die Entwicklung schon fehlerfrei verlas-

sen. Die Hauptaufgabe der Tester ist somit nicht mehr das Aufdecken von Fehlern, sondern

das Validieren der Software. [vgl. Eck04, S. 153f] Hinzu kommen Qualitätsprüfungen, die

durch Unittests nicht abgedeckt werden können. Dies wären unter anderem Lasttest, Stress-

tests oder Tests auf der Oberfläche.

Problematisch ist der Wegfall von Dokumentation für die Qualitätsprüfung. Basierten die

System- und Akzeptanztests zuvor auf umfangreichen Anforderungsbeschreibungen, ist die-

ses Vorgehen nun nicht mehr möglich. Als Lösung dieses Problems werden die Tester zum

Teil des agilen Teams. Sie werden volle Mitglieder des Teams und an allen Aktivitäten betei-

ligt. [vgl. CG09, S.59ff] Es gibt keine unabhängige Qualitätssicherung außerhalb der Ent-

wicklung. Die Tester arbeiten eng mit Kunden und Entwicklern zusammen, das Verständnis

für die Funktionsweise der Software gewinnen sie aus den User Stories und Meetings mit dem

Kunden. Hierzu unterstützen sie den Kunden beim Erstellen der User Stories. Zu jeder User

Story werden nach Möglichkeit gleichzeitig Akzeptanzkriterien erstellt. Der Tester kann


50

daraufhin gegen diese Akzeptanzkriterien prüfen und das Produkt validieren. Zusätzlich

gelten die Akzeptanzkriterien den Entwicklern als Orientierungshilfe. Die Tests erfolgen

zeitnah. [vgl. CG09, S. 37ff]

Eine Einbindung des traditionellen Ablaufes des V-Modells in jedes Inkrement klingt verlo-

ckend. Hierbei würden die Tests während des Inkrements erstellt und am Ende ausgeführt. In

jedem Inkrement entstünden weitere Tests, die zum Bestand hinzugefügt werden. [vgl. SL10,

S. 71] In agiler Softwareentwicklung ist dieses Vorgehen jedoch nicht optimal. Der Test am

Ende eines Entwicklungszyklus wird eine unbekannte Anzahl an Fehlern aufdecken. Diese

Fehler müssen behoben und erneut getestet werden. Die hierfür benötigte Zeit lässt sich nicht

einschätzen. Bei unpassender Zeitplanung verlässt das Produkt die Iterationen mit Fehlern,

der Einsatz in der Produktion verschiebt sich nach hinten.

Beim sogenannten „Pipelining“ [vgl. Pic08, S. 147f] findet der Test deshalb erst im nächsten

Zyklus statt und die Fehler werden während der Entwicklung behoben. Die Software wird erst

in sogenannten Releasesprints ausgeliefert, die hauptsächlich aus Test und Fehlerbehebung

bestehen. Dieses Vorgehen sollte jedoch nach Möglichkeit vermieden werden, da keine unge-

testeten oder fehlerhaften Funktionen den Sprint verlassen sollten und sich die Auslieferung

der Software verzögert. Ist dies nicht möglich, sind sehr kurze Zykluszeiten zu wählen, um

die Auslieferung der Software nicht zu sehr zu verzögern.

Die Software sollte sich nach jeder Iteration in einem Zustand befinden, der eine Auslieferung

an den Kunden ermöglicht. Dies kann weder mit einem Mini-Wasserfall bzw. Mini-V-Modell

noch mit „Pipelining“ gewährleistet werden.

Idealerweise finden die Tests zeitgleich mit der Entwicklung statt, um Fehler frühestmöglich

aufzudecken. Aus diesem Grund muss die Abnahme der Tests zur „Definition of Done“ gehö-

ren. Eine Funktion ist erst fertig, nachdem sie getestet worden ist. Auf diese Weise wird ein

irreführender Projektfortschritt vermieden. [vgl. ECK09, S.89]

Dies ist im Zusammenhang mit der Praktik „Continous Integration“ möglich, also die konti-

nuierliche Codeintegration. Sobald eine Funktion implementiert und mit Unittests überprüft

worden ist, wird sie in das Produkt integriert. Ziel dieser Praktik ist es, zu jeder Zeit ein lauf-

fähiges Programm mit allen bisher umgesetzten Funktionen zu besitzen. Der Tester kann nun

anhand dieses Artefakts die Tests durchführen. Die Ergebnisse werden direkt mit dem Ent-

wickler besprochen und die Fehlerbehebung erfolgt so früh wie möglich. Erst wenn die User

Story durch die Qualitätssicherung abgenommen wurde, gilt sie als erledigt. Dadurch wird

4.3 QUALITÄTSSICHERUNG IN DER AGILEN SOFTWAREENTWICKLUNG

51

sichergestellt, dass nur getestete Backlog Items zum Fortschritt des Entwicklungszyklus bei-

tragen.

Die agile Softwareentwicklung legt einen Schwerpunkt auf die Testautomatisierung. Dies gilt

nicht nur für Unit- und Integrationstest, sondern auch für Systemtests und teileweise für den

Akzeptanztest. Hierfür werden Regressionstests mit Werkzeugen wie FIT, Selenium oder

Watir automatisiert. So ist es möglich, die Software am Ende eines Tages einem kompletten

Test zu unterziehen. [vgl. CG09 255ff] Seiteneffekte durch Änderungen sind so praktisch

auszuschließen. Durch die durchgängigen Unit- und Integrationstests, sowie die parallelen

System- und Akzeptanztests befinden sich am Ende des Zyklus nur wenig Fehler im Produkt,

die direkt behoben werden müssen. Ein automatisierter Systemtest kann regelmäßig die ge-

samte Software prüfen und ermöglicht einen schnellen Test am Zyklusende. Es ist möglich,

die Tests schon zu Beginn zu schreiben und zu implementieren, als eine Art Anforderungs-

spezifikation. [vgl. ECK09, S. 172f]

Die agile Qualitätssicherung mit Scrum umzusetzen bedeutet zunächst, auf eine Qualitätssi-

cherung außerhalb des Projekts zu verzichten. Es empfiehlt sich, möglichst viele Praktiken

der agilen Softwareentwicklung anzuwenden. Durch diese konstruktiven Maßnahmen wird

die Produktqualität von Anfang an erhöht. Die Praktiken müssen jedoch vom Team selbst

aufgegriffen werden, da Scrum steuernde Eingriffe dieser Art verbietet. Es ist jedoch von

vornherein klarzustellen, dass das gesamte Team für die Qualität verantwortlich ist. Die Tes-

ter im Team sind wie alle Mitglieder an den Meetings beteiligt. Der genaue Umfang der Test-

arbeiten ist vom Team abhängig. Ob Code Reviews durchgeführt werden oder die Tester sich

nur auf Akzeptanztests beschränken, kann variieren. Die Tester sollen auf alle Fälle den Pro-

duct Owner beim Erstellen der User Story und ihrer Akzeptanzkriterien unterstützen. Bevor

die ersten User Storys umgesetzt wurden, beginnen die Tester bereits mit der Automatisierung

von Testfällen. Direkt nach der Umsetzung sollten die Akzeptanztests zusammen mit dem

Product Owner durchgeführt werden, um aufwendige Systemtests auf unpassende Funktiona-

lität zu vermeiden. Hier wird nur betrachtet, ob die Funktion den Vorstellungen des Kunden

entspricht. Da dabei noch nicht tiefgreifend nach Fehlern gesucht wurde, sind die Systemtests

im Anschluss durchzuführen. Am Ende des Sprints sind nur die User Stories als abgeschlos-

sen anzusehen, welche von der Qualitätssicherung abgenommen wurden. Gegen die komplet-

te Software sollten die automatisierten Tests ausgeführt werden. [vgl. CG09, S. 97ff]


52

Die Software hat somit ein verändertes V-Modell durchlaufen. Der Unterschied ist, dass jede

User Story ein eigenes V-Modell besitzt. Eine User Story wird zuerst mit Unittests verifiziert

und in das Gesamtsystem integriert. Während der Integration findet ein Integrationstest statt.

Nun folgen System- und Akzeptanztest durch Tester und Product Owner, wobei es sich anbie-

tet den Akzeptanztest vor dem Systemtest durchzuführen. Auf diese Weise wird sicherge-

stellt, dass jede Anforderung ihre eigenen automatisierten Unittests, Integrationstests und

nach Möglichkeit auch Systemtests besitzt.

Trotz des kontinuierlichen Testens fallen vor Auslieferung des Produkts weitere Testaktivitä-

ten an. Die Zeit kurz vor der Auslieferung wird „End Game“ genannt. [vgl. CG09, S. 456ff]

Der Aufwand für das „End Game“ kann stark in Abhängigkeit von den nötigen Tests variie-

ren. Gibt es aufwendige Tests, die erst am Ende der Iteration durchgeführt werden können, ist

entsprechend mehr Zeit einzuplanen. In der Regel fallen verschiedene Tätigkeiten in jedem

Projekt an. Zum einen ist ein Test auf dem sogenannten „Staging environment“ nötig, eine

Umgebung, die das Produktivsystem nachbildet. Die Umgebung für die kontinuierliche Integ-

ration ist meist eine Testumgebung, das Verhalten in der Produktivumgebung kann davon

abweichen. In diesem System ist zudem die Integration in alle benötigten Systeme zu testen

und auf kundenspezifische Besonderheiten zu achten. Zudem ist es erforderlich die Installati-

on des gesamten Produkts zu testen, da während der Entwicklung inkrementelle Updates zum

Aktualisieren des Systems ausgeführt werden und keine komplette Installation durchgeführt

wird.

Um Vertrauen in die Software zu gewinnen, sind zusätzlich alle automatisierten Regressions-

test auszuführen und manuelle Szenarien über die komplette Software durchzuführen. Funk-

tionale Fehler sollten in dieser Phase nicht mehr auftreten, im Vordergrund steht das Sichers-

tellen der Lauffähigkeit in der neuen Umgebung. Ein weiterer Faktor ist das Testen der nicht-

funktionalen Anforderungen. Obwohl nicht-funktionale Tests schon während der Entwick-

lung durchgeführt wurden, ist zu prüfen, ob die Software unter der neuen Hardware dieselben

Eigenschaften aufweist.

Für die Prüfung am Ende des Sprints ist das gesamte Team verantwortlich. In dieser Zeit wer-

den keine neuen Funktionen realisiert. Dies bedeutet, dass dementsprechend weniger Zeit für

die Entwicklung bleibt und bei der Planung entsprechend berücksichtigt werden muss. [vgl.

Wir09, S. 167f]

4.4 ZUSAMMENFASSUNG

53

Die Rolle des Testers ist in der agilen Softwareentwicklung variabel ausgelegt. Stauen sich

am Ende der Iteration die Testaufgaben, können Entwickler beim Testen oder Automatisieren

der Regressionstests helfen, während Tester am Anfang der Iteration Aufgaben in der Ent-

wicklung wahrnehmen können.

4.4 ZUSAMMENFASSUNG

Die Software-Qualitätssicherung ist von der allgemeinen Qualitätssicherung abgegrenzt wor-

den. Während sich die Qualitätssicherung mit der Prüfung der Wirksamkeit des Qualitätsma-

nagements beschäftigt, steht in der Software-Qualitätssicherung die Produktqualität im Vor-

dergrund. Die Software-Qualitätssicherung teilt sich in zwei Bereiche, die konstruktive Quali-

tätssicherung und die analytische Qualitätssicherung. Unter die konstruktive Qualitätssiche-

rung fallen Maßnahmen, um die Qualität in die Software hinein zu entwickeln. Die analyti-

sche Qualitätssicherung ist für die Prüfung der Artefakte des Produktes verantwortlich. Dies

geschieht in der Regel in vier Teststufen, Unittest, Integrationstests, Systemtest und Akzep-

tanztest.

Während die konstruktiven Qualitätssicherungsmaßnahmen durch eine externe Qualitätssi-

cherung schwer einzuführen sind, da diese während der Planung des Projekts vor Ort definiert

werden müssen, können analytische Maßnahmen problemlos nach außen vergeben werden.

Durch die Unabhängigkeit und das Fachwissen der externen Tester lassen sich daraus Poten-

tiale aktivieren.

Das Testen in der konventionellen Softwareentwicklung unterscheidet sich stark von der agi-

len Softwareentwicklung. Nach dem V-Modell werden die Tests phasenweise durchgeführt.

Dies bedeutet, erst nachdem alle Anforderungen umgesetzt wurden, wird getestet. Dies ist in

der agilen Softwareentwicklung nicht durchführbar, da die Iterationsziele auf diese Weise

nicht erreichbar sind. Stattdessen wird jede Funktion direkt nach ihrer Umsetzung getestet.

Dies erfordert eine erhöhte Zusammenarbeit zwischen Entwicklern und Testern. Des Weite-

ren ist der Einsatz von automatisierten Tests in der agilen Softwareentwicklung von größerer

Bedeutung, da in jeder Iteration die komplette Software getestet werden muss. In der konven-

tionellen Softwareentwicklung geschieht dies hingegen nur ein einziges Mal am Ende der

Entwicklung.


54

Die Unterschiede in der Qualitätssicherung von konventioneller und agiler Softwareentwick-

lung wurden verdeutlicht. Da sich die einzelnen Teststufen der konventionellen Softwareent-

wicklung bereits bewährt haben, wurden Ansätze aufgezeigt, sie in die agile Softwareent-

wicklung einzubinden, um die Produktion qualitativ hochwertiger Software zu gewährleisten.

Zusätzlich sind automatisierte Tests zu verwenden, wie sie im Umfeld der agilen Software-

entwicklung propagiert werden.

Folglich kann die agile Softwareentwicklung mit einer effektiven Software-

Qualitätssicherung ausgestattet werden, um das benötigte Vertrauen für die Entwicklung von

unternehmenskritischen Systemen zu schaffen.

55

5 TEILUNG DES SOFTWAREENTWICKLUNGSPRO-ZESSES AUF DIE BETEILIGTEN UNTERNEHMEN

Nach dem die Grundlagen zu Vorgehensmodellen, Qualitätsmanagement und Qualitätssiche-

rung erläutert wurden, müssen diese nun auf die besondere Situation angepasst werden. Die

agile Softwareentwicklung mit Scrum über drei beteiligte Unternehmen - Auftraggeber, Auf-

tragnehmer für die Entwicklung (Auftragnehmer SE) und Auftragnehmer für die Qualitätssi-

cherung (Auftragnehmer QS) - an verschiedenen Standorten - lässt sich nicht mit der einfa-

chen Vergabe von Testaufgaben nach außen lösen. Durch die oberflächliche Spezifikation in

agilen Entwicklungsprojekten ist ein entkoppelter Test der Software nicht sinnvoll. Die Tester

benötigen das Kontextwissen, um ihren Tätigkeiten nachzukommen.

Darüber hinaus findet die Kommunikation über größere räumliche Entfernungen über Doku-

mente statt, insbesondere bei der konventionellen Qualitätssicherung. Diese Dokumente wer-

den von einem agilen Prozess nicht ausreichend unterstützt.

Es existieren zwei verschiedene Möglichkeiten, den Testern das Wissen über die Anforderun-

gen der Applikation zukommen zu lassen. Auf der einen Seite besteht die Möglichkeit, den

Prozess von Scrum soweit zu verändern, dass die benötigten Informationen niedergeschrieben

und weitergeleitet werden. Der Auftragnehmer QS testet die vollständige Software nach

Sprintende gegen die Spezifikation und liefert die Ergebnisse zurück. Die Fehlerbehebung

findet im Laufe des nächsten Sprints statt. Dies würde jedoch den agilen Prinzipien wider-

sprechen und einige Probleme der dokumentengesteuerten Vorgehensmodelle mit sich brin-

gen. Die Flexibilität wird gesenkt und ein zusätzlicher Zeitaufwand für die Dokumentation

kommt hinzu. Ein weiterer Faktor ist die Verschiebung der Auslieferung um mindestens einen

Sprint. Diese Lösung ist aber in ihrer Umsetzung einfach und erfordert vor allem von der

Qualitätssicherung nur einen kleinen Anpassungsaufwand.

Eine andere Lösung ist die Integration der externen Qualitätssicherung in die Prozesse von

Scrum. Obwohl die Qualitätssicherung nicht vor Ort untergebracht ist, wird sie in alle Ent-

scheidungsprozesse einbezogen. Dies geschieht durch die Unterstützung bei der Erstellung

der Backlog Items, Teilnahme an den Hauptsitzungen wie Sprint Planning, Sprint Review und

Sprint Retrospective. Über Kollaborationswerkzeuge findet eine transparente Zusammenar-

beit zwischen Entwicklungsteam und Qualitätssicherung während des Sprints statt.

KAPITEL 5: TEILUNG DES ENTWICKLUNGSPROZESSES AUF DIE BETEILIGTEN UNTERNEHMEN

56

Übergeordnete Prozesse steuern die Zusammenarbeit, schränken die flexible Kommunikation

jedoch nicht ein. Auf einem zentralen Testsystem werden die Funktionen im Gesamtsystem

direkt nach Fertigstellung getestet. Der Zugriff erfolgt per Fernzugriff. Die Ergebnisse des

Sprints können wie beim agilen Vorgehen direkt nach Sprintende als fertig angesehen und

ausgeliefert werden. Diese Lösung erfordert ein hohes Maß an Bereitschaft zum Umdenken in

der Qualitätssicherung und viel Akzeptanz bei den Entwicklern, die die Qualitätssicherung

nicht als hindernd betrachten dürfen.

Während die erste Lösung eine einfache Umsetzung verspricht, verlässt sie doch das agile

Feld. So weit möglich, sollten die agilen Prinzipien beibehalten werden, um schnelle Auslie-

ferungen und eine hohe Flexibilität beizubehalten. Aus diesem Grund wird im weiteren Ver-

lauf die zweite Lösung verfolgt.

5.1 FESTLEGUNG DER AUFGABEN DER BETEILIGTEN UNTER-NEHMEN

Scrum definiert verschiedene Rollen, den Product Owner, den ScrumMaster, das ScrumTeam

sowie die Stakeholder, bestehend aus Kunden, Management und sonstigen Interessenvertre-

tern.

Product Owner, ScrumMaster und ScrumTeam dürfen nicht getrennt werden. Sie sind in den

Räumlichkeiten des Auftragnehmer SE untergebracht. An ihren Aufgaben ändert sich nichts

Grundsätzliches, die Entwicklung der Software läuft nach demselben Schema ab wie zuvor.

Das Team wird um ein externes Mitglied mit der Funktion zur Qualitätssicherung ergänzt.

Sollte das alte ScrumTeam keinen dedizierten Tester besessen haben, ändert sich an der

Teamstruktur nichts. Anderenfalls muss das Zusammenspiel zwischen externen und internen

Testern abgestimmt werden.

Die Aufgabe der Qualitätssicherung in agilen Softwareprojekten ist die Unterstützung des

Product Owners bei der Erstellung von User Stories und Akzeptanztests, Testen und Testau-

tomatisierung während des Sprints sowie verifizieren und validieren der Software am Sprint-

ende. Durch eine gute Integration ist es für die externe Qualitätssicherung möglich, alle diese

Aufgaben zu übernehmen.

Die Abstimmungen zwischen Product Owner und Kunde zur Erstellung des Product Backlogs

finden in der Regel nicht kontinuierlich, sondern punktuell statt. So wird es der

5.1 FESTLEGUNG DER AUFGABEN DER BETEILIGTEN UNTERNEHMEN

57

Qualitätssicherung ermöglicht, an dem Treffen teilzunehmen. Bei kurzfristigen,

außerplanmäßigen Treffen kann die Qualitätssicherung per Telefon o.ä. hinzu gezogen

werden.

Zum Durchführen der Tests ist vorab die Testart zu bestimmen. Je näher am Code gearbeitet

werden muss, desto größer wird der Abstimmungsaufwand mit den Entwicklern. Für einen

Test auf der Oberfläche ist keine weitere Erklärung erforderlich, während der Tester für Unit-

tests in die Programmstruktur eingeführt werden muss. Aus diesem Grund ist genau zu pla-

nen, auf welchen Schichten sich der Tester bewegen soll. In der agilen Softwareentwicklung

sind Tester sehr flexibel und übernehmen auch Aufgaben der Entwickler. Für die externe

Qualitätssicherung empfiehlt es sich jedoch, an den traditionellen Prinzipien festzuhalten, um

den Kommunikationsbedarf gering zu halten. Die White-Box-Tests sind Aufgabe der Ent-

wickler, die Black-Box-Tests werden von der Qualitätssicherung durchgeführt. Jede Funktion

wird von den Entwicklern während des Sprints einmal Unit- und Integrationstests unterzogen

und danach gibt es von den Testern System- und Akzeptanztests. Dabei sind beide Tests so-

weit wie möglich zu automatisieren.

Der Test am Ende des Sprints ist Aufgabe des gesamten Teams. Je nach Länge des Sprints

sind mehrere Tage einzuplanen, in denen alle automatisierten Tests ausgeführt werden. Die

Qualitätssicherung sollte sich hier auf Validierung der nichtfunktionalen Anforderungen kon-

zentrieren, da jede Funktion einzeln während des Sprints getestet wurde und nach Möglich-

keit automatisiert geprüft werden kann.

Wurde die externe Qualitätssicherung vom Kunden selbst hinzugezogen, besteht die Mög-

lichkeit, unabhängige Statusberichte abzufragen. Die Aufgabe besteht darin, den Kunden über

die Qualität der Software zu informieren. Aufgrund der Aussage kann der Kunde entscheiden,

ob eine Qualität erreicht wurde, die das Ausrollen des Releases im Unternehmen erlaubt.

Durch ein hohes Fachwissen im Bereich Softwarequalität sind spezialisierte externe Dienst-

leister für eine derartige Einschätzung besonders qualifiziert. Aufgrund der Qualitätseinschät-

zung kann der Auftraggeber auch weitere Maßnahmen zur Qualitätserhöhung anstoßen, soll-

ten die Ergebnisse nicht positiv ausfallen.

Im Falle der konstruktiven Qualitätssicherungsmaßnahmen fällt dem Auftragnehmer QS eine

beratende Funktion zu. Sie hat keine Weisungsbefugnis, um die Entwickler zum Nutzen be-

stimmter agiler Praktiken zu bewegen. Er sollte Vorschläge möglichst früh zur Sprache brin-

gen und auf deren Einhaltung dringen. Durch die räumliche Trennung wird diese Aufgabe


58

zusätzlich erschwert. In Scrum ist das komplette Team für die Qualität verantwortlich, Ent-

wickler, Analysten, Tester und die Inhaber weiterer Funktionen. Es darf nicht der Eindruck

entstehen, dass mit einer zusätzlichen Rolle für die Qualitätssicherung den Entwicklern Ver-

antwortung für die Qualität der Software abgenommen wird. Um den Sprint mit auslieferbarer

Software abzuschließen, ist der Bedarf von Nachbesserungen zum Ende möglichst gering zu

halten.

Der Scrum Master ist dafür zuständig, alle Hindernisse, die das Team in seiner Arbeit ein-

schränken können, zu beseitigen. Durch die Integration der externen Qualitätssicherung muss

er auf die Einbindung der neuen Mitglieder achten. Dies wird durch die räumliche Entfernung

erschwert, da die Qualitätssicherung nicht am Daily Scrum teilnehmen kann. Seine Aufgabe

ist nicht, eine Zusammenarbeit zu erzwingen, sondern die nötigen Mittel und Kompetenzen

bereitzustellen, um sie zu ermöglichen. Unternehmensübergreifende Kommunikation kann zu

unterschiedlichen Problemen führen. Sie kann einerseits schnell zu Misstrauen führen, ande-

rerseits kann die Qualitätssicherung als Überwachungsfunktion angesehen werden oder ein

Mangel an Werkzeugen die Zusammenarbeit verhindern. Um dem Vorzubeugen muss sich

der ScrumMaster nicht nur im eigenen Unternehmen und mit dem Auftraggeber in Verbin-

dung setzen, sondern auch mit dem Auftragnehmer QS auseinander setzen. Es ist wichtig,

dass der ScrumMaster sich zur externen Qualitätssicherung bekennt, da er eine treibende

Kraft für den Erfolg der Integration darstellen kann.

Der Product Owner ist nach wie vor für die Zusammenstellung und Auswahl der User Stories

verantwortlich. Die User Stories werden jedoch von Anfang an um Akzeptanzkriterien erwei-

tert. Zur Erstellung von Akzeptanzkriterien und dem Ableiten von Akzeptanztests wird er von

der Qualitätssicherung unterstützt. Das frühzeitige Definieren von Akzeptanzkriterien hilft

zusätzlich den Entwicklern dabei, die Anforderungen zu verstehen. Auch während der Akzep-

tanztests kann die Qualitätssicherung mit Wissen zur Seite stehen und den Product Owner

unterstützen. Bei Tests der Qualitätssicherung müssen bei Unklarheiten regelmäßige Rück-

sprachen mit dem Product Owner getroffen werden, um Missverständnissen vorzubeugen.

Bei der Umsetzung von Veränderungen ist das Management immer eine treibende Kraft. Nur

mit seiner Unterstützung kann ein unternehmensübergreifendes Projekt funktionieren. Die

Entscheidung zur Einbindung externer Qualitätssicherung wird vom Management getroffen.

Dies kann mit oder ohne Anreiz vom Kunden geschehen. Das Management muss alle Betei-

ligten von der Einführung externer Qualitätssicherung überzeugen und die benötigten Mittel

5.2 ZUSAMMENSPIEL UND SCHNITTSTELLEN

59

und Werkzeuge dafür bereitstellen. Eine enge Zusammenarbeit mit dem ScrumMaster ist auf-

grund seines Wissens über die Arbeitsweise des Teams dringend erforderlich. Der ScrumMas-

ter benötigt aktive Hilfe zur Beseitigung von Hindernissen. Durch einen direkten Zugang zu

Entscheidungsträgern in allen beteiligten Unternehmen können Schwierigkeiten des Scrum-

Teams schnell aus dem Weg geräumt werden.

Geht die Entscheidung zur Einbeziehung einer externen Qualitätssicherung vom Kunden aus,

muss dieser klarstellen, welche Vorteile er sich davon erhofft. Je nach Geschäftsverhältnis

kann der Kunde Einfluss auf die Auftragnehmer ausüben. Dadurch kann er den Erfolg des

Projekts maßgeblich beeinflussen. Es liegt an ihm, das Management des Auftraggeber SE von

der Sinnhaftigkeit dieses Vorgehens zu überzeugen. Fühlt sich der Auftraggeber SE kontrol-

liert, ist mit starken Widerständen zu rechnen. Des Weiteren obliegt es ihm, zu definieren,

welche Leistungen von der externen Qualitätssicherung verlangt werden sollen. Eine kurze

Abnahme der Software nach Sprintende zur Evaluierung der Qualität bis zur kompletten Ein-

bindung der externen Qualitätssicherung ist möglich. Außerdem kann er großen Einfluss auf

die Einbindung der externen Qualitätssicherung bei der Anforderungsdefinition nehmen.

Sollte der externe Dienstleister nicht vom Auftraggeber hinzugezogen worden sein, entfallen

keine zusätzlichen Aufgaben auf den Kunden.


In Scrum verwaltet sich das Team selbstständig. Die Qualitätssicherung ist Teil des Teams

und unterliegt somit keiner Weisung durch einen Projektleiter. Bei einer externen Qualitätssi-

cherung, die nicht am selben Ort wie das Team operiert, könnte sich dieses Vorgehen anfangs

aus zwei Gründen als problematisch erweisen. Zum einen muss die Kommunikation zwischen

internen und externen Teammitgliedern angestoßen werden. Ohne geeignete Kanäle und

technische Unterstützung besteht die Gefahr, dass der externe Part des Teams nicht als zuge-

hörig angesehen wird, die Kommunikation nicht beginnt oder frühzeitig zum Erliegen kommt.

Zum anderen sind bei einer unternehmensübergreifenden Zusammenarbeit die geschäftlichen

Aspekte nicht zu vernachlässigen. Je nachdem, von wem die externe Qualitätssicherung hin-

zugezogen wurde, muss die erbrachte Arbeit gegenüber dem Auftraggeber transparent sein. Je

nach Vergütungsgrundlage ist es erforderlich, die Leistungen zu erfassen und gegenüber den

internen Mitgliedern abzugrenzen. Dafür ist es erforderlich festzustellen, wo die Arbeit der


60

externen Teammitglieder beginnt und endet. Da sich das Team auf ihre Aufgaben bezüglich

der Softwareentwicklung konzentrieren soll, kann nicht davon ausgegangen werden, dass es

derartige Mechanismen von sich aus entwickelt. Folglich sind vorab Kommunikationskanäle

zwischen internen und externen Teammitgliedern zu definieren und zu schaffen, sowie

Schnittstellen und Leistungserfassungsmechanismen herauszuarbeiten.

Durch überschneidungsfreie Aufgaben und Kompetenzverteilung ist es möglich, den Kom-

munikationsaufwand gering zu halten und eine Leistungsunterscheidung zu treffen.

Zur Vereinfachung werden die Unternehmen für die Implementierung und für die Qualitätssi-

cherung als zwei getrennte Systeme betrachtet, deren Kommunikation über klar definierte

Schnittstellen abläuft. Anschließend ist es möglich, die Schnittstellen aufzuweichen, um der

agilen Methodik entgegen zu kommen.

ABBILDUNG 5.1: VERTEILUNG DER AUFGABEN

Wie in Bild 5.1 zu sehen, ist eine überschneidungsfreie Aufteilung der Aufgaben von Scrum-

Team und Qualitätssicherung möglich. Das dominierende Artefakt der Entwicklung ist die

User Story. Sie wird zu Beginn der Entwicklung definiert und dient als Vorlage für alle weite-

ren Aufgaben. Die Erstellung der User Story findet spätestens vor dem nächsten Scrum Zyk-

lus statt. Der Kunde, Product Owner und die externe Qualitätssicherung erstellen die User

Stories gemeinsam. Jeder der drei Beteiligten bringt sein Wissen ein. Der Kunde kennt als

einziger seine Anforderungen an das Produkt, der Product Owner gibt ihm Hilfestellung, die

Anforderungen zu konkretisieren und zu formulieren, während die Qualitätssicherung bei der

Erstellung von Akzeptanzkriterien unterstützt. Diese Tätigkeit wird in der Regel nur einmal

vor jedem Sprint durchgeführt. Ein Zusammenkommen der Parteien sollte daher möglich

sein.


61

Der Aufbau und die Pflege des Product Backlogs erfolgt nach wie vor einzig durch den Pro-

duct Owner.

Das Sprint Planning Meeting spielt eine zentrale Rolle bei der Vorbereitung des Teams auf

den kommenden Sprint. Es ist die einzige Besprechung bis zum Ende der Iteration, in dem

das Team inklusive der Qualitätssicherung vollständig zusammenkommt.

Bei der Auswahl der User Stories für das Product Backlog während des Sprint Planning Mee-

tings ist die Anwesenheit aller Projektbeteiligten nötig, auch der Qualitätssicherung [vgl.

CG09, S. 333f]. Zu diesem Zeitpunkt erfolgt die Aufwandsschätzung der User Stories, die ins

Sprint Backlog übertragen werden. In der Regel sind die Mitglieder der Qualitätssicherung als

einzige in der Lage, den Aufwand für die Tests richtig einzuschätzen.

Die übergeordneten Prozesse, Qualitätskennzahlen und Werkzeuge müssen dem Team vor-

gestellt werden. Es dürfen keine Unklarheiten bestehen bleiben. Alle wichtigen Aspekte be-

züglich der Zusammenarbeit sind hier zu besprechen und festzulegen. Dem ScrumMaster

kommt die Aufgabe zu, alle Spannungspunkte zwischen den einzelnen Teammitgliedern an-

zusprechen und aufzulösen. Die Besprechung ist erst dann beendet, wenn sich das Team auf

eine gemeinsame Vorgehensweise bezüglich der Qualitätssicherung geeinigt hat.

Sollte es sich um das erste Meeting vor dem Sprint mit externer Qualitätssicherung handeln,

ist eine Einbeziehung des Managements zur Akzeptanzschaffung wünschenswert. Die Inten-

tionen hinter diesen Maßnahmen müssen offen gelegt werden. Bei mangelnder Transparenz

kann es zu Misstrauen gegenüber der externen Qualitätssicherung kommen, die Entwickler

könnten sich gegen eine Zusammenarbeit sperren oder nur spärlich Informationen weiter ge-

ben.

Nach dem Sprint Planning Meeting beginnt der Sprint. Die Kommunikation findet von nun an

über entfernte Kommunikationskanäle und Kollaborationsplattformen statt. Die Zielsetzung

besteht darin, die Zusammenarbeit möglichst reibungslos zu gestalten. Dazu müssen geeigne-

te Werkzeuge und Systeme bereitgestellt werden, zu denen beide Seiten Zugriff bekommen.

Es muss für beide ersichtlich sein, welches Mitglied zurzeit an welcher Story arbeitet, bezie-

hungsweise gearbeitet hat. Dies bezieht Design, Implementierung und Test mit ein. Nachdem

die ausgewählten Stories in das Sprint Backlog übertragen wurden, sind sie in ein geeignetes

Werkzeug zu übertragen.


62

Bei Scrum werden die Tasks auf einem Taskboard festgehalten. Das Board ist in verschiedene

Spalten geteilt, die den jeweiligen Status des Tasks darstellen. Im Laufe der Entwicklung

wandert der Task über das Board, bis er in der letzten Spalte „done“ angekommen ist. Die

einzelnen Teammitglieder suchen sich selbstständig Aufgaben vom Board aus und sortieren

sie nach Beendigung ihrer Aufgabe im zugehörigen Status wieder ein. [vgl. Pic08, S. 102f]

Hierfür ist eine Lösung zu finden, die verteiltes Arbeiten zulässt und in der alle Mitglieder

gleichermaßen auf die Tasks und deren Status zugreifen können. Eine internetbasierte Appli-

kation, die verteilten Zugriff erlaubt, bietet sich an.

Alle wichtigen Informationen zur Story können dem Werkzeug entnommen werden. Kommen

während der Entwicklung weitere wichtige Ergänzungen durch Absprache mit dem Product

Owner zustande, sind diese nachträglich einzupflegen. Hierbei ist zu beachten, dass diese

Ergänzungen nur Erklärungen und Konkretisierungen zu bestehenden User Stories sein dür-

fen, da während des Sprints keine neuen Anforderungen hinzukommen dürfen. Bei Beginn

der Arbeit an einer Story wird im System das betreffende Mitglied eingetragen. Der Status

wird auf die entsprechende Tätigkeit gesetzt. So ist für jeden ersichtlich, von wem die Story

bearbeitet wird und welche Arbeitsschritte er ausführt. Nach Ende der Implementierung wer-

den die Funktionen in das Testsystem integriert und der Status der Story erneut verändert. Der

Tester erkennt daran, dass die Story für den Test bereit ist. Er kann nun von sich aus die Story

aufgreifen und mit dem Testen beginnen. Für Rückfragen stehen die Entwickler zur Verfü-

gung und sind über verschiedene Kommunikationskanäle erreichbar.

Auf diese Weise wird erreicht, dass die Qualitätssicherung ihrer Arbeit unabhängig von der

Entwicklung nachgehen kann, jedoch auf beiden Seiten der gleiche Informationsstand

herrscht. Da die Qualitätssicherung schon während der Erstellung der Story involviert ist, hat

sie gutes Verständnis über die Bedürfnisse der Kunden. Kommen weitere Informationen wäh-

rend der Entwicklung hinzu, wird entweder die Story erweitert oder in einem Gespräch vor

dem Test abgeklärt.

Die Übermittlung der Testergebnisse ist kritisch. In der Regel werden von der Qualitätssiche-

rung Testberichte verfasst und an die Entwickler weitergereicht. Dies ermöglicht eine un-

komplizierte Kommunikation, der Entwickler kann den Berichten die Fehler entnehmen und

im Quellcode beheben. Dabei werden jedoch nicht die Notwendigkeit der Fehlerpriorisierung,

der Abstimmung bei Unklarheiten sowie die Besonderheiten agiler Prozesse berücksichtigt.


63

Fraglich ist, wer den Zeitpunkt der Fehlerbehebung bestimmt. In der konservativen Software-

entwicklung wurde eine Behebung aller Fehler vor Auslieferung der Software angestrebt. In

der agilen Softwareentwicklung bleibt mehr Spielraum. Unkritische Fehler können in späteren

Iterationen behoben werden, bei schwerwiegenden Fehlern muss die Fehlerbehebung

schnellstmöglich erfolgen, damit ein erneutes Testen vor Iterationsende möglich ist. Hinzu

kommt, dass nur getestete Funktionen nach der Iteration ausgeliefert werden dürfen, diese

jedoch noch nicht völlig fehlerfrei sein müssen. Es ist zu bestimmen, ob eine Funktion den

Auslieferungskriterien gerecht geworden ist. Ein weiterer Faktor ist die Abstimmung bei Un-

klarheiten. User Stories geben keine konkrete Vorgabe für die Umsetzung der geforderten

Funktion. Da die Qualitätssicherung eine validierende Instanz ist, kann die Implementierung

der Entwickler hinterfragt werden. Ist die Qualitätssicherung anderer Meinung als die Ent-

wicklung, entsteht Diskussionsbedarf, der nicht über Dokumente austragbar ist. Des Weiteren

erfordern agile Prozesse kurze Kommunikationswege. Der Aufwand, um einen umfassenden

Testbericht zu erstellen, ist in einer wenige Wochen umfassenden Iterationsphase nicht gege-

ben. Die Kommunikation muss zeitnah erfolgen, um die User Story schnellstmöglich abzu-

schließen.

Die Tester können die direkte Kommunikation zu den Entwicklern suchen. Auf diese Weise

müssen nicht alle Fehler festgehalten werden. Die Behebung kleiner Fehler ist mit wenig

Aufwand verbunden. Eine schnelle Behebung des Fehlers und ein gleich darauf folgender

Nachtest ist möglich. [vgl. CG09, S. 420f] Findet sich kein Entwickler oder ist der Fehler

nicht trivialer Natur, ist er festzuhalten.

Eine Einspeisung der Fehler in die laufende Iteration ist erforderlich. Da nicht alle Fehler di-

rekt behoben werden müssen, obliegt es dem Product Owner zu entscheiden, welche Fehler

für die Fertigstellung der Story zu beheben sind. Da das Team während der Tests mit der Ar-

beit an einer neuen Story begonnen hat, ist es sinnvoll, die Fehlerbehebung als Teil der ak-

tuellen Story zu vollziehen. Dies bedeutet, dass die aktuelle Story erst abgeschlossen ist, wenn

alle freigegebenen Fehler aus der vorherigen Phase behoben worden sind. [vgl. Wir09, S.

157] Der Product Owner kann zusätzlich Unstimmigkeiten mit den Anforderungen bei der

Umsetzung von Funktionen direkt überprüfen und gegebenenfalls die Story konkretisieren.

Wichtig ist, dass die Zusammenarbeit mit dem Product Owner augenblicklich funktioniert, so

dass wenig Zeit zwischen Aufdeckung des Fehlers und der Eintaktung der Fehlerbehebung

entsteht.


64

Zusätzlich sollten die Fehler in einem offenen System festgehalten werden, einem sogenann-

ten Bug-Tracking-System. Die Entwickler bekommen so direkten Zugriff auf alle Fehler und

können diese in Phasen geringer Auslastung abarbeiten.

Nach dem Beheben eines Fehlers ist der Status im Bug-Tracking-System zu ändern und die

Änderung in das Testsystem zu integrieren. Der Tester kann daraufhin sofort mit dem Nach-

test beginnen.

Um dieses Vorgehen umzusetzen, wird kein Testbericht für eine komplette Story erstellt, son-

dern eine knappe Beschreibung für jeden Fehler. Die Fehlerbeschreibung wird einer Funktion

zugeordnet. Auf diese Weise können die Fehler einer Funktion schnell identifiziert werden,

und eine voneinander unabhängige Behandlung der Fehler wird ermöglicht. Durch die Tren-

nung von Story und Fehler ist es möglich, einen Überblick über alle Fehler im System zu be-

kommen und nicht nur über fehlerhafte Stories. Durch den verbesserten Überblick wird die

Qualität des Systems transparenter.

ABBILDUNG 5.2: SCHNITTSTELLEN ZWISCHEN DEN ROLLEN UND SYSTEMEN


65

In Bild 5.2 sind die Schnittstellen zwischen den einzelnen Rollen und Systemen visualisiert.

Zu beachten ist, dass in der agilen Entwicklung die Interaktion zwischen Menschen einen

höheren Stellenwert einnimmt als die Einhaltung von Prozessen und das Benutzen von Werk-

zeugen. Es entstehen Synergieeffekte durch die direkte Kommunikation. Unter anderem er-

folgt ein Wissenstransfer, der dem Entwickler hilft, seinen Code besser zu testen und dem

Tester Verständnis für Probleme der Implementierung zu vermitteln. Lösungsmöglichkeiten

können durch die unterschiedlichen Sichtweisen schneller gefunden und Kompromisse aus-

gearbeitet werden. Zusätzlich erfolgt die Fehlerbehebung übergangslos. Wird der Fehler nur

in einem Bug-Tracking-System aufgenommen, besteht keine Garantie auf zeitnahe Behand-

lung. Somit ist die direkte Kommunikation zwischen Team und Qualitätssicherung möglichst

auszureizen. [vgl. CG09, S. 412f]

Da Situationen entstehen können, in denen kein Entwickler zur Verfügung steht, wird die

Möglichkeit geschaffen, Testergebnisse zentral festzuhalten. Für schwerwiegende Fehler, für

die möglicherweise neue User Stories verfasst oder Tasks angelegt werden müssen, sowie bei

Unstimmigkeiten gegenüber den Anforderungen, ist der Weg über den Product Owner unum-

gänglich.

Der ScrumMaster ist nicht aufgeführt, da er keine Rolle im Entwicklungsprozess selbst über-

nimmt. Er muss jedoch die Kommunikation zwischen den Rollen und die Nutzung der Werk-

zeuge betrachten, um gegebenenfalls gegenzusteuern. Eine wichtige Funktion ist dabei der

Schutz des Sprint Backlogs. Der Product Owner darf hier nur Informationen zur Klärung der

Anforderungen nachtragen und nicht den Aufwand von User Stories erhöhen, beziehungswei-

se neue User Stories einpflegen.

Während der Entwicklung kann es nun zu verschiedenen ad hoc Kommunikationssituationen

kommen, bei denen Informationen zwischen zwei Parteien ausgetauscht werden, ohne dass

die dritte Partei ohne übergeordneten Prozess davon erfahren würde. Die dort ausgetauschten

Informationen könnten kritischer Natur sein und dringend benötigt werden. In einem her-

kömmlichen Vorgehensmodell trat diese Situation in der Regel nicht auf, da alle Anforderun-

gen und Zeitpläne zuvor genau festgelegt wurden. In einem agilen Umfeld sind kurzfristige

Planänderungen und Absprachen bezüglich der Anforderungen gewollt und müssen daher

genau betrachtet werden. Es sind Mechanismen zu planen und zu implementieren, über die

Informationen mit allen Teammitgliedern geteilt werden können.


66

Es gibt drei Konstellationen, in denen eine dritte Partei nicht in die direkte Kommunikation

eingebunden ist. Dies sind:

• Kunde – Entwicklung,

• Kunde – QS und

• Entwicklung - QS.

Die Entwicklung und der Kunde kommunizieren meistens über den Product Owner. Je nach-

dem von welcher Seite die Kommunikation initiiert worden ist, geht es entweder darum, zu-

sätzliche Informationen zu einer Aufgabe zu erhalten oder zusätzliche Wünsche zu äußern.

Zweites ist für Aufgaben in der laufenden Iteration nicht möglich, da das Sprint Backlog in

der jeweiligen Iteration gesperrt ist. Zusätzliche Wünsche gehören ins Product Backlog. Zu-

sätzliche Informationen zu einer Aufgabe oder einer User Story sind auch für die Qualitätssi-

cherung von Bedeutung, da diese Auswirkung auf die Tests haben können. Deshalb sollten sie

als Ergänzung im Sprint Backlog dokumentiert werden.

Ähnliche Informationen können zwischen Qualitätssicherung und Kunde ausgetauscht wer-

den. Diese müssen über das Sprint Backlog, wie oben beschrieben, an die Entwickler weiter-

geleitet werden, um das Verständnis für Fehler zu verbessern. Absprachen zwischen Entwick-

lung und Qualitätssicherung können für den Kunden sowie weitere Stakeholder interessant

sein, wenn diese Planänderungen oder Prozessänderungen vorsehen.

All diese Informationen und das Wissen werden im herkömmlichen agilen Vorgehen direkt

zwischen den Teammitgliedern geteilt. Dies ist aufgrund der Nähe der Teammitglieder zuei-

nander und der begrenzten Teamgröße möglich. In der verteilten Entwicklung sind dafür

technische Hilfsmittel in Form von Kollaborationswerkzeugen nötig. Hierfür sind unter ande-

rem Wiki-Webs und E-Mail Listen geeignet. [vgl. Eck04, S.59] Außerdem können Möglich-

keiten geschaffen werden, User Stories um eine Änderungsliste zu erweitern. So sind zusätz-

liche Informationen direkt dort untergebracht, wo sie benötigt werden. Das Dokumentieren

von Änderungen und zusätzlichen Informationen ist in einem agilen Prozess jedoch nicht

selbstverständlich. Es müssen Anreize geschaffen werden, um dies zu fördern. Jutta Eckstein

schlägt den Einsatz eines Kommunikationsteams vor. Dies können eine oder mehrere Perso-

nen sein, die in regelmäßigen Abständen alle Teammitglieder nach neuen Informationen be-

fragen. Diese Person muss als Vertrauensperson und nicht als Kontrolleur wahrgenommen

werden. [vgl. Eck04, S. 60f] Dieser Aufgabe könnte unter anderem der ScrumMaster nach-

kommen.

5.3 ZUSAMMENFASSUNG

67

5.3 ZUSAMMENFASSUNG

Durch das Einbinden einer externen Qualitätssicherung in den agilen Entwicklungsprozess

müssen die Aufgaben der verschiedenen Beteiligten genau definiert werden, um Kompetenz-

streitigkeiten zu vermeiden sowie die Beschreibung von klaren Schnittstellen zwischen den

Unternehmen zu ermöglichen.

Die Rollen des Product Owners, ScrumMasters und des ScrumTeams beim Auftragnehmer

der Entwicklung bleiben erhalten. Die Rolle der externen Qualitätssicherung musste hingegen

in Scrum eingefügt werden. Der Product Owner ist weiterhin die Schnittstelle zum Kunden

und für die Auswahl der umzusetzenden User Stories verantwortlich. Zusätzlich wird er bei

der Aufnahme und Erstellung der Akzeptanzkriterien von der Qualitätssicherung unterstützt.

Dadurch wird diese detailliert über die Anforderungen informiert.

Der Scrum Master dient zusätzlich als Schnittstelle zum externen Team und muss alle Hin-

dernisse beseitigen, die der Zusammenarbeit hinderlich sind. Das Management muss dem

Projekt seine volle Unterstützung zusichern und eine Infrastruktur bereitstellen, in der ein

verteiltes Arbeiten möglich ist.

Die Teststufen werden auf die beteiligten Unternehmen aufgeteilt. Die Entwickler sind für die

Unit- und Integrationstest zuständig, da sie detaillierte Einblicke in den Quellcode und die

technische Umsetzung besitzen. Die externe Qualitätssicherung ist für die Systemtests und

soweit machbar, für die Akzeptanztests zuständig.

Um das Zusammenspiel zwischen den Beteiligten zu optimieren, sind an den großen Mee-

tings alle Teammitglieder aus Entwicklung und Qualitätssicherung beteiligt. So herrscht bei

Entwicklungsbeginn ein Informationsgleichstand. Kommen während der Entwicklung weitere

Informationen zu den User Stories hinzu, muss der Informationsgleichstand wieder hergestellt

werden. Dies geschieht über eine Erweiterung der User Stories um die neuen Informationen.

Zu diesem Zweck müssen die User Stories in einem zentralen, für beide Unternehmen zu-

gänglichen System festgehalten werden.

Die Fehlerbehebung erfolgt so früh wie möglich: Entweder über eine direkte Kommunikation

mit dem Tester oder spätestens während der Entwicklung der nächsten User Story. Dazu wer-

den etwaige Fehler zu Tasks der aktuellen User Story in der Entwicklung.


68

Um die Zusammenarbeit weiter zu verbessern, sollten Kollaborationswerkzeuge eingesetzt

werden.

Die verschiedenen Aufgaben der Rollen im erweiterten Scrumprozess, ihre Schnittstellen und

ihr Zusammenwirken wurden beschrieben. Sie dienen als weitere Grundlage der Prozessbe-

schreibung.

69

6 UNTERSTÜTZUNG DES SOFTWAREENTWICK-LUNGSPROZESSES

Die Gestaltung eines Softwareentwicklungsprozesses erfordert Berücksichtigung aller Anfor-

derungen. Wir haben auf der einen Seite ein agiles Vorgehen, dem die aus einem starren Ent-

wicklungsmodell stammende Qualitätssicherung entgegen steht. Hinzu kommt die Anwend-

barkeit für die Entwicklung unternehmenskritischer Systeme, die oft sehr hohen Qualitätsan-

forderungen entsprechen müssen und aus diesem Grund unterer starker Kontrolle in einem

konservativen Kontext hergestellt wurden.

Boehm und Turner haben agile und plangetriebene Entwicklungsmodelle untersucht, um die

jeweiligen Anwendungsgebiete festzustellen. Hierbei hat sich herausgestellt, dass keines der

beiden eine allgemeingültige Lösung liefert, sondern eine Mischung aus beiden die größte

Aussicht auf Erfolg hat. Zudem scheint das größte Potential nicht bei den eingesetzten Me-

thoden, sondern bei den Menschen, Werten, Kommunikation und dem Erwartungsmanage-

ment zu liegen. [vgl. BT08, S. 147ff] Sie haben gezeigt, dass viele verschiedene Randbedin-

gungen die Eignung eines Projekts für agile oder plangetriebene Vorgehensmodelle, bzw. den

Grad der Mischung von Beidem beeinflussen. Aus diesem Grund ist es nicht möglich, ein

allgemeingültiges Modell unter Berücksichtigung aller möglichen Randbedingungen aufzu-

stellen. Daher wird im Weiteren mit Scrum gearbeitet, dessen Skalierung unter anderen

Randbedingungen in einschlägiger Literatur festgehalten wurde. [u.a. in Eck04, Eck09] Die

Sicherstellung der hohen Qualitätsanforderungen geschieht allein durch die umfassende ana-

lytische und konstruktive Softwarequalitätssicherung sowie hohe Prozessqualität.

Während der Beschreibung der Schnittstellen begann der Entwicklungsprozess sich herauszu-

bilden. Die Entwicklung mit Scrum konnte unverändert bleiben, da es möglich ist, die Rolle

der externen Qualitätssicherung zusätzlich einzuführen. Sie befindet sich jedoch in einem

eigenen System außerhalb des implementierenden Unternehmens. Je nachdem, wie sehr der

Kunde die externe Qualitätssicherung als unabhängiges Kontrollorgan nutzen möchte, gibt es

zwei bis drei verschiedene Systeme, die über Schnittstellen miteinander kommunizieren.

Die Beschreibung des unternehmensübergreifenden Prozesses ist erforderlich. Aufgrund des

agilen Vorgehens ist dieser jedoch nicht verbindlich für alle Mitglieder festzulegen, sondern

dient als Leitfaden. Sollte sich der Prozess als nicht optimal herausstellen, können

KAPITEL 6: UNTERSTÜTZUNG DES SOFTWAREENTWICKLUNGSPROZESSES

70

Änderungen eingearbeitet werden. Wie in Scrum üblich, sollte dies in der Sprint

Retrospective geschehen.

Um die Einbindung der externen Qualitätssicherung für Management und Kunde transparen-

ter zu gestalten, sollte der Prozess durch Qualitätsmanagementmaßnahmen begleitet werden.

Auf diese Weise können alle Beteiligten zur Qualitätssteigerung beitragen.

Das Vorgehen während der Entwicklung orientiert sich an den User Stories und den daraus

resultierenden Tasks. Die User Story bildet ein geschlossenes Werk, welches während der

Entwicklung bearbeitet wird. Alle User Stories abzuschließen und zusammenzufügen, ist das

Ziel der Entwicklung. Die dabei entstandene Software das Produkt. Wird die Qualität zur

Entwicklung der einzelnen User Stories hoch angesetzt, kann daraus geschlossen werden,

dass das Gesamtsystem über eine hohe Qualität verfügen wird. Somit liegt der Fokus des Pro-

zesses auf der Umsetzung einzelner User Stories und nicht auf der aufeinander folgenden

Abarbeitung ganzer Phasen, in denen jeweils alle Anforderungen umgesetzt werden. Die Be-

trachtung einer User Story lässt sich gut als Prozess abbilden und bezieht alle Entwicklungs-

schritte ein. Die Aufgaben der drei Parteien wurden zuvor festgelegt.

Bevor der Prozess vollständig ausgestaltet werden kann, ist zu klären, auf welche Weise Qua-

litätsmanagement eingesetzt werden kann, um die Grundlage für eine stetige Optimierung zu

schaffen. Des Weiteren sind die eingesetzten Informationskanäle und Systeme für eine rei-

bungslose Verzahnung beider Auftragnehmer wichtig.

6.1 EINBINDUNG VON QUALITÄTSMANAGEMENTELEMENTEN

Scrum regelt nicht den Fluss der Aufgaben innerhalb des Projektes. Es wurde jedoch gezeigt,

dass eine Betrachtung der Arbeitsschritte den Prozessablauf optimieren kann. Um Ver-

schwendung im Projekt zu minimieren und eine Grundlage für die Optimierung der Durch-

laufzeiten zu schaffen, sind zur agilen Softwareentwicklung passende Qualitätsmanagement-

ansätze einzubringen. Wie bereits dargelegt, eignen sich modellbasierte Qualitätsmanage-

mentansätze nur bedingt für die agile Softwareentwicklung, kontinuierliche Ansätze sind ih-

nen vorzuziehen. Bei den kontinuierlichen Ansätzen gibt es viele verschiedene Modelle, wie

TQM und Six Sigma. Je nach Projektgröße und Kritikalität kann der geeignete Ansatz umge-

setzt werden. Da agile Projekte meist im kleineren Rahmen durchgeführt werden, ist der

Aufwand für die Einführung eines großen Modells zu hoch. Aus diesem Grund wird im


71

Folgenden kein konkretes Qualitätsmanagementmodell verwendet, vielmehr stehen eine kon-

tinuierliche Prozessverbersserung und eine Zusammenarbeit von Entwicklern und Manage-

ment, basierend auf wenigen aussagekräftigen Kennzahlen im Fokus.

Dass die Praktiken von Lean Manufacturing gut in das agile Umfeld passen, wurde in Kapitel

3.2 dargestellt. In den letzten Jahren gab es unter der Bezeichnung Lean Development zu-

nehmend Bemühungen, diese Praktiken in der Softwareentwicklung umzusetzen. Es wurde

ein Vorgehen nach der TOC als wirkungsvolle Methode identifiziert, um den Durchsatz in der

Softwareentwicklung zu optimieren.

Folglich ist der Einsatz einer Methodik ideal, die sowohl aus dem Bereich Lean Development

kommt als auch TOC unterstützt. Passend dazu eignet sich Kanban, ein Vorgehen aus der

industriellen Produktion, welches den Grundstein für Lean Manufacturing legte. Kanban wur-

de von David J. Anderson als Vorgehensmodell adaptiert und 2007 offiziell vorgestellt. Kan-

ban gehört zum Bereich des Lean Software Development. [vgl. Epp11, S. 34f]

Während Scrum einen Managementrahmen bietet, in dem die Entwicklung eigenverantwort-

lich stattfindet, optimiert Kanban die Zusammenarbeit der Teammitglieder und den Fluss der

Aufgaben. Die beiden Methoden ergänzen sich sehr gut. Ansätze, die beide Techniken mitei-

nander verbinden werden ScrumBan genannt. [ScrumBan]

6.1.1 KANBAN UND SCRUM

Scrum und Kanban besitzen viele Gemeinsamkeiten und lassen sich gut kombinieren. Wäh-

rend Scrum eine Management Methodik ist, die Teams einen Rahmen für selbstständiges Ar-

beiten bereitstellt, bringt Kanban eine Grundlage zur Optimierung des Prozessdurchsatzes

sowie aussagekräftige Kennzahlen mit. [siehe KS10]

Kanban begrenzt den Work in Progress (WIP) in einem System. Hierzu wird eine bestimmte

Anzahl an Signalkarten in Umlauf gebracht. Jede Karte steht für eine Aufgabe. Erst wenn eine

Aufgabe erledigt ist, wird die dazugehörige Karte aus dem System genommen und eine weite-

re kann hinzugefügt werden. Im Gegensatz zu den üblichen Push-Prozessen, handelt es sich

bei Kanban um ein Pull-Prinzip. Die Aufgaben können nicht in das System geschoben wer-

den, da eine Kapazitätsbeschränkung existiert. Die Aufgaben werden in das System gezogen,

sobald wieder Kapazität vorhanden ist. [vgl. And10, S. 14/15]


72

In der Softwareentwicklung findet die Koordination mit Kanban über ein sogenanntes Kan-

banboard statt. Es ähnelt dem Scrumboard und ist beispielhaft in Bild 6.1 zu sehen:

Die Zahlen neben oder unter den Spaltentiteln zeigen die Kapazitätsgrenzen an. Die Höhe der

Kapazitätslimits ist zu Beginn der Entwicklung zu bestimmen, kann vom Team jedoch nach

Absprache geändert werden. Die Aufgaben werden auf Karten geschrieben. In "Todo" sind

momentan drei von drei Tickets vorhanden, es kann folglich kein weiteres hinzugefügt wer-

den. In der Entwicklung befinden sich drei von vier Tickets. Die Entwickler können also eine

Karte von "Todo" in die Entwicklung übernehmen. Nur Teammitglieder, die eine Aufgabe

bearbeiten, dürfen deren Status ändern. So darf kein Entwickler eine Karte von "Complete" in

"Test" verschieben, dies darf nur der Tester, der die Aufgabe bearbeiten möchte. [vgl. And10,

S. 87f] Eine gute Darstellung von Henrik Kniberg ist im Anhang 1 zu finden.

ABBILDUNG 6.1: BEISPIEL FÜR EIN KANBANBOARD [ENTNOMMEN AUS KANBANBOARD]

Diese Technik lässt sich sehr gut ergänzend zu Scrum einsetzen. Um erste Verbesserungen zu

erreichen, genügt schon die Einführung eines WIP-Kapazitätslimits für die einzelnen Arbeits-

schritte. Kommt es innerhalb des Prozesses zu einem Stau, wird dies sofort offensichtlich.

Das ganze Team muss bestrebt sein, den Stau aufzulösen, da aufgrund der WIP-

Begrenzungen nicht mehr weitergearbeitet werden kann. Auf diese Weise wird eine konti-

nuierliche Verbesserungsmentalität im Team angestrebt. Durch die hohe Transparenz ist sich

jeder im Team bewusst, welche Auswirkungen handeln oder untätig bleiben haben können.

Die Zusammenarbeit wird verbessert, da Probleme gemeinsam gelöst werden müssen, um

weiter arbeiten zu können. Arbeit ohne Rücksicht auf nachgelagerte Arbeitsschritte


73

durchzuführen, ist nicht mehr möglich, da bei Problemen das WIP-Limit erreicht wird. [vgl.

And10, S. 57ff]

Dieser Effekt ist für die nötige Zusammenarbeit von Entwicklern und externen Testern be-

sonders wünschenswert. Aufgrund der räumlichen Distanz sind Techniken zur Transparenzer-

zeugung einzuführen. Kommt es während der Entwicklung zu Problemen, ist nun das gesamte

Team gezwungen, näher zusammenzuarbeiten, während sich ein Teil des Teams einer Blo-

ckade sonst nicht bewusst geworden wäre. Es ist nicht mehr möglich, Probleme zu verschlep-

pen. Dies steigert die Effizienz, da zuerst alles dafür getan werden muss, Aufgaben abzu-

schließen, bevor neue ins System gezogen werden können.

Zusätzlich ist es für den Product Owner möglich, noch während des Sprints Veränderungen

an den Prioritäten der Items im Sprint Backlog vorzunehmen. Die Karten werden während der

Entwicklung nach Priorität ausgewählt, so dass sehr viel flexibler auf neue Bedingungen ein-

gegangen werden kann. Je länger sich Aufgaben im System befinden, desto höher steigt ihre

Priorität. Auf diese Weise ist es nicht möglich Aufgaben zu ignorieren oder zu vergessen.

Die Karten von Kanban dienen nicht nur der Visualisierung, sondern lassen sich um viele

Informationen erweitern. Neben einer eindeutigen ID der Anforderungen, einer Kurzbe-

schreibung sowie weiteren Informationen ist es möglich, Änderungen, Bearbeitungszeiten,

Durchlaufzeiten und beteiligte Personen während des Prozesses zu erfassen. Diese Daten

können am Ende einer Iteration ausgewertet werden und liefern viele Informationen über den

Prozessablauf. Dies ermöglicht es dem Management, die Entwicklung zu beurteilen und un-

terstützt die Teammitglieder dabei, Verbesserungspotentiale zu erkennen und zu nutzen. [vgl.

Epp11, S. 79]

Des Weiteren sollten weitere Metriken aus dem Bereich der Produktqualität erhoben werden.

Hier sollte sich vor allem auf die Anzahl der gefunden Fehler im Code bezogen werden. Es ist

zu beachten, dass dies nicht geschieht, um die Qualitätssicherung zu beurteilen, sondern die

Qualität des Produktes. Die initiale Qualität des Produktes ist ein wichtiger Faktor, eine hohe

Fehleranzahl lässt auf Probleme während der Implementierung schließen. Hier ist auch die

Art von Fehlern interessant, fehlgeschlagene Validierungen lassen auf unklare Anforderungen

schließen. Metriken von der Testautomatisierung wie Anforderungs- oder Codeüberdeckung

geben Aufschluss über die Aussagekraft der eingesetzten Testtechniken. Dabei wird gemes-

sen, wie viele der gesamten Anforderungen oder des gesamten Codes von den Tests


74

abgedeckt wird. Werden nur 50 % der Anforderungen abgedeckt, sind die Tests nicht aussa-

gekräftig, da die anderen 50 % fehlerhaft sein können. [vgl. CG09, S.73f]

Durch die Einführung von Kanban in Scrum wird folglich ein sich selbst regulierender Pro-

zess mit hoher Transparenz und aussagekräftigen Metriken implementiert. Zusätzlich wird

das Entstehen einer Kultur der kontinuierlichen Verbesserung gefördert. Ansätze für Verbes-

serungen sind klar ersichtlich.

Die Einführung von Veränderungen ist stark von der Unternehmenskultur abhängig. Agile

Softwareentwicklung befürwortet jedoch eigenständiges Handeln der Mitarbeiter. Somit sollte

das Team ermächtigt werden, auch während einer Iteration Änderungen am Prozess, am Kan-

banboard oder anderen Aspekten der Entwicklung vorzunehmen. Das Management sowie

weitere Stakeholder bekommen während der Sprint Retrospektive die Gelegenheit, sich zu

äußern und Vorschläge zu unterbreiten. Funktioniert die Arbeit im Team nicht, müssen Ein-

griffe von außen erfolgen. Durch die Transparenz des Kanban-Boards können sich Außenste-

hende ständig informieren und notfalls reagieren. Für den ScrumMaster stellt es ein mächtiges

Werkzeug zur frühzeitigen Aufdeckung von potentiellen Schwachstellen dar, auf die er im

täglichen Stand-up Meeting direkt eingehen kann.

Darüber hinaus ist es möglich, Praktiken von Lean Development, wie Eliminate Waste und

Amplify Learning, in die Entwicklung einzubeziehen. Dieses Thema würde jedoch den Rah-

men sprengen und wird nicht weiter betrachtet.

6.1.2 EINSATZ ZUR EINBINDUNG DER EXTERNEN SOFTWARE-QUALITÄTSSICHERUNG

Um Kanban und Scrum zu vereinen, sind für die praktische Umsetzung einige Besonderheiten

zu beachten. Dies bezieht sich vor allem auf die Gestaltung des Kanbanboards, dass auf die

Bedürfnisse von Scrum sowie die Teilung der Entwicklung über zwei Unternehmen angepasst

werden muss. Um Unterscheidungen auf dem Kanbanboard zwischen einzelnen Aufgaben

und User Stories hervorzuheben, können verschiedene Farben und zusätzliche vertikale Zei-

len eingesetzt werden.

Aus Platzgründen ist die Anzahl der Zeilen so gering wie möglich zu halten. Es ist anzuneh-

men, dass die Arten unterschiedlicher Aktivitäten, wie Implementierung, Bug Fix, Testvorbe-

reitung, die höchste Anzahl an Unterscheidungen bietet. Diese können nicht alle in Spalten


75

dargestellt werden, dort sind nur die wichtigsten Funktionen zu finden. So kann die Aktivität

Implementierung und Bugfix in der Spalte "Entwicklung" umgesetzt werden, ebenso ge-

schieht dort die Testvorbereitung. Für die Art der Aufgabe ist dann die farbliche Unterschei-

dung zu wählen.

Weitere Besonderheiten sind im Detail näher zu betrachten:

Kanban wird in der Regel für die Entwicklung kleiner User Stories, wie sie beispielsweise in

der Wartung vorkommen, verwendet. Daher stellt in Kanban eine Karte eine User Story dar.

In Scrum werden die Feature im Sprint Planning Meeting zuvor in Tasks aufgeteilt, um bei

größeren User Stories Aufgaben mit überschaubaren Aufwänden zu bekommen und eine bes-

sere Arbeitsverteilung zu gewährleisten. Eine Aufgabe steht jedoch in keinem unmittelbaren

Bezug zu der Anforderung des Kunden. Erst wenn alle Aufgaben zu einer Anforderung, bzw.

User Story, umgesetzt wurden, ergibt sich ein Mehrwert aus der Entwicklung. Aus diesem

Grund ist sicherzustellen, dass erst alle Tasks einer User Story abgearbeitet werden, bevor mit

der nächsten User Story begonnen wird. Befinden sich mehrere User Stories zur selben Zeit in

der Entwicklung, müssen diese visuell voneinander unterscheidbar sein. Dies kann durch

farbliche Gestaltung der Karten oder durch Einführen von horizontalen Bereichen auf dem

Kanbanboard geschehen. Da die farbliche Gestaltung für die Aufgabenart vorgesehen ist,

wird im Folgenden eine horizontale Trennung bevorzugt.

Ein weiterer Punkt ist die Testentwicklung. Das Erstellen von Testfällen und die Testfallau-

tomatisierung finden gleichzeitig mit der Implementierung des Tasks statt. Hier ist es nötig,

Nebenläufigkeit darzustellen. Für diesen Fall stellt Kanban bereits eine Lösung bereit. Wird

eine Aufgabe entnommen, wird sie in zwei verschiedene Karten geteilt, eine für die Entwick-

lung und eine für die Testentwicklung. Die Trennung der Aufgabenbereiche können entweder

farblich oder durch die Einführung einer weiteren horizontalen Ebene kenntlich gemacht wer-

den. Nach Erledigung beider Teilaufgaben ist es möglich, die Karte wieder zusammenzufüh-

ren und in den nächsten Schritt zu übertragen. [vgl. And10, S. 82f] Auch hier wird eine hori-

zontale Trennung auf Grund der Vorbelegung der Farben durch die Rollen und der benötigten

expliziten Unterscheidung zwischen Entwicklung und Qualitätssicherung (zwei getrennte

Unternehmen) genutzt.

Fraglich ist die Rückführung von Bugfixes in das Kanban-System.

Die einfachste Lösung ist, das Bugfixing direkt mit dem Testen zu verbinden. Sobald ein Feh-

ler gefunden wurde, wird dieser behoben. Die Kanbankarte bleibt in diesem Fall für den


76

Bugfix in der Testspalte. Wenn der Fehler behoben und nachgetestet wurde, wird die Kan-

bankarte auf "Done" gesetzt. Dieses Vorgehen ist nur bei einfachen Fehlern und einem sehr

eng zusammenarbeitenden Team möglich, da Fehler nicht transparent hervorgehoben und den

Entwicklern direkt zugewiesen werden. Aus diesem Grund wurden Vorgehen entwickelt, bei

denen Fehler wieder in das Kanban-System zurückgeführt werden. Die fehlerhafte User Story

wird direkt in die Spalte für die Entwicklung gesetzt und durchläuft den Zyklus erneut. Mit-

tels der Prioritäten ist eine schnelle Durchlaufzeit der Kanbankarten für die Fehlerbehebung

gewährleistet. Schwierigkeiten entstehen hier bei der Rückführung der Karten, wenn die WIP-

Limits der benötigten Spalten bereits voll sind. In diesem Fall müsste das WIP-Limit entwe-

der gebrochen oder die Karte zurück ins Backlog geführt werden. [Kanbancard]

Um dieses Problem zu umgehen, bietet es sich an, die Bugfixes außerhalb des regulären Ab-

laufs zu halten. Es wird eine weitere vertikale Linie für die Fehlerbehebung eingeführt. Die

Karten können hier direkt abgelegt werden. Die Karte durchläuft weiterhin alle Phasen. Kar-

ten in der Zeile für die Fehlerbehebung sind mit höchster Priorität zu behandeln. So lange an

dieser Stelle Aufgaben existieren, ist es verboten weitere Arbeit ins System zu ziehen. [Lean-

rework]

Durch die weite Entfernung zwischen Qualitätssicherung und Entwicklung sollten Bugs so

deutlich wie möglich hervorgehoben werden. Somit birgt die letztgenannte Lösung das größte

Potential. Ein dediziertes Bug-Tracking-System, wie in Kapitel 5.2 beschrieben, ist trotzdem

weiterhin nötig. Für Fehler, die nicht direkt behandelt, sondern auf einen späteren Sprint ver-

schoben werden, ist die Möglichkeit zur langfristigen Dokumentation notwendig. Dies ist

über das Kanbanboard nicht möglich. Für diese Fehler ist der Einsatz eines Bug-Tracking-

Systems weiterhin empfehlenswert.

In Bild 6.2 ist ein beispielhaftes Kanbanboard zu sehen, dass auf die Bedürfnisse von Scrum

und der verteilten Entwicklung angepasst wurde:

In den ersten beiden Spalten befinden sich die User Stories mit ihren Tasks in priorisierter

Reihenfolge. Nach Auswahl einer User Story zur Bearbeitung wird diese mit all ihren Tasks

nach "todo" verschoben, wo jede User Story eine eigene Zeile bekommt. Von "todo" ziehen

sich die Bearbeiter ihre Tasks nach "Entwicklung". Die Unterscheidung zwischen Entwick-

lung der Applikation, in der Spalte "In Arbeit" und der Tests, in Spalte "Testentwicklung", ist

gut ersichtlich untereinander angeordnet. Die Spalte "User Story Done" nimmt die User Story

auf, nach dem alle Tasks umgesetzt wurden. In "Pre Test" wird der Vortest des Product

6.2 WERKZEUGE

77

Owners durchgeführt. Er prüft, ob die User Story seiner Vorstellung entspricht. Nach dem

"Pre Test" landet die User Story in "Test todo", von wo aus sich die Tester ihre Testaufträge

entnehmen und nach "Test" verschieben.

Der Bereich für die Bugfixes, die Zeile "Rework", wurde hervorgehoben in die Mitte gesetzt.

Da in der Regel nur die Entwickler und Tester an der Fehlerbehebung beteiligt sind, wurden

die wichtigsten Felder rot markiert. Dadurch wird verdeutlicht, dass Karten direkt von „In

Arbeit“ nach „Test todo“ verschoben werden können. Die einzelnen User Stories sind mittels

gestrichelter Linien von einander abgetrennt worden. Die Darstellung dient lediglich als Bei-

spiel, die einzelnen Spalten sowie die WIP-Limits können je nach Projekt angepasst werden.

ABBILDUNG 6.2: AN DIE GEGEBENHEITEN ANGEPASSTES KANBANBOARD

6.2 WERKZEUGE

Durch das Arbeiten an verschiedenen Standorten nimmt die Gestaltung von Werkzeugen und

Systemen einen hohen Stellenwert ein.

Verschiedene Teilbereiche sind zu beachten, um die Entwicklung und die Qualitätssicherung

zu verzahnen. Zum einen muss eine Auswahl von Werkzeugen für eine reibungslose und enge

Kommunikation getroffen werden, zum anderen ist eine Auswahl von Werkzeugen zur Un-

terstützung der Entwicklung sowie des Entwicklungsprozesses nötig.


78

Es folgt eine Beschreibung der nötigen Werkzeuge und Systeme, die für einen reibungslosen

Ablauf der Entwicklung erforderlich sind. Auf Grund des allgemeinen Charakters eines Ent-

wicklungsmodells werden keine Empfehlungen für bestimmte Produkte abgegeben, da sich

diese nach den besonderen Anforderungen des Projekts richten.

6.2.1 KOMMUNIKATIONSWERKZEUGE

Die Bedeutung von Kommunikation für die agile Entwicklung findet sich schon in den Prin-

zipien des agilen Manifests.

Die effizienteste und effektivste Methode, Informationen

an und innerhalb eines Entwicklungsteam zu übermitteln,

ist im Gespräch von Angesicht zu Angesicht.

[agile_principle]

In den vorherigen Kapiteln wurde gezeigt, dass für die Einbindung der externen Software-

Qualitätssicherung in die agile Entwicklung eine reibungslose, entfernungsunabhängige

Kommunikation essentiell ist.

Zusätzlich ist Wartezeit ein Kostenfaktor. Die Zeit, in der auf die Antwort einer Person ge-

wartet oder die für die Initialisierung des Gesprächs benötigt wird, ist nicht produktiv. So

kann es passieren, dass der Mitarbeiter anfängt, mit Annahmen zuarbeiten, da er den Kom-

munikationsaufwand scheut. [vgl. Coc02, S.77 f ] In Bild 6.3 sind die verschiedenen Kom-

munikationswege dargestellt, erweitert um Kollaborationswerkzeuge von Microsoft, die zur

Unterstützung eingesetzt werden können. Hering und Rees haben in einer Studie gezeigt, dass

Technologie ein hohes Maß an Kommunikation und Zusammenarbeit über verschiedene

Standorte hinweg ermöglichen kann. [vgl. HR01]

Die Werkzeuge dienten dabei verschieden Zwecken, von einem entfernten Meeting, über ver-

teilte Kommunikation bis zur Teilung der Artefakte zwischen den Teammitgliedern.

Für die Auswahl der Werkzeuge sind die Anzahl der gleichzeitigen Nutzer, die Antwortzeit

und die Kommunikationsrichtung von Bedeutung. [vgl. Eck09, S. 78] Für jeden benötigten

Zweck ist das geeignete Werkzeug auszuwählen.

Je nach Entfernung des Teams wird ein Werkzeug zum Abhalten von Meetings benötigt. Sit-

zen die Teams an weniger weit entfernten Standorten, ist ein persönliches Treffen vorzuzie-

hen, da sich mit persönlicher Kommunikation eine bessere Zusammenarbeit erzielen lässt.

6.2 WERKZEUGE

79

Bei entfernter Kommunikation ist nicht unbedingt eine visuelle Verbindung nötig, da diese

kaum mehr Informationen beisteuert als ein rein auf Audio ausgelegtes Gespräch. Für diesen

Zweck gibt es eine Vielzahl von Werkzeugen (Skype, NetMeeting, Adobe Acrobat Connect

Professional). Auch die Telefonie kann für diesen Zweck zum Abhalten von Telefonkonfe-

renzen genutzt werden.

ABBILDUNG 6.3: VERGLEICH VON KOMMUNIKATIONSWERKZEUGEN [AUS HR01]

Auch für die direkte Kommunikation zwischen zwei Teammitglieder bietet sich die Telefonie

an. Ein Nachteil von ad hoc Anrufen ist jedoch, dass die Erreichbarkeit des anderen Team-

mitglieds nicht zuvor erkannt werden kann. Zusätzlich stellt ein Anruf immer eine garantierte

Unterbrechung für den anderen dar. Er kann nur durch ignorieren des Anrufs signalisieren,

dass er nicht gestört werden möchte.

Für den täglichen Arbeitsgebrauch bietet sich daher Instant Messaging an. Zum einen ermög-

licht es einen Zustand von “presence and awareness”. [siehe HR01] Die Verfügbarkeit der

anderen Teammitglieder ist sofort ersichtlich und ihre Präsenz wird wahrgenommen. Durch

Statusänderungen können sie signalisieren, ob Störungen erwünscht sind oder sie sich in einer

intensiven Arbeitsphase befinden. Außerdem bieten Instant Messenger weitere Funktionen für

Gruppenchats oder VOIP Gespräche. So lassen sich zusätzliche Informationskanäle öffnen.

Instant Messaging unterstützt informelle Kommunikation die face-to-face Gesprächen ähnelt.

Die Hemmschwelle zum Beginn einer Konversation wird gesenkt und ein Vertrauensverhält-

nis zwischen den Teammitgliedern geschaffen. [NWB00]


80

Die zuvor genannten Kommunikationsmittel laufen synchron ab, die beiden Teilnehmer ste-

hen zeitgleich in Verbindung. Für die asynchrone Kommunikation hat sich der E-Mail-

Verkehr etabliert. Die E-Mail birgt jedoch mehrere Nachteile. Bei E-Mails kommt es schnell

zu einer E-Mail-Flut. Das Medium wird nicht nur zum Versand essentieller Informationen

gebraucht, sondern auch für viele unwichtige Informationen. So kann es passieren, dass E-

Mails über einen Verteiler verschickt werden, von dem sich nur wenige für den Inhalt interes-

sieren. Dies führt dazu, dass das Interesse an E-Mails sinkt und wichtige E-Mails nicht mehr

gelesen werden. Genauso kann es in E-Mails zu interessanten Diskussionen kommen, diese

sind später jedoch nur noch schwer nachzuvollziehen und sollten daher in Kollaborations-

plattformen geführt werden, auf denen sie für alle Mitglieder zugänglich sind. [vgl. ECK09,

S. 82] Für den E-Mail Verkehr sind klare Richtlinien zu schaffen, um dieses Medium nicht zu

überlasten. In agilen Projekten sollte die synchrone Kommunikation vorgezogen und wichtige

Informationen in transparenten Kollaborationsplattformen statt in geschlossenen E-Mails

festgehalten werden.

Die bekannteste Kollaborationsplattform ist das Wiki. Eine Wiki ist eine Server-Software die

Benutzern erlaubt, eine Webseite zu editieren. Sie unterstützt Links zwischen verschiedenen

Seiten. Dadurch können Nutzer Informationen aus dem Wiki entnehmen oder neue hinzufü-

gen. Ein für alle zugänglicher Informationssammelpunkt entsteht. [WIKI] Bei Wikis lässt sich

jedoch nicht zeitgleich an einem Artefakt arbeiten.

Es gibt Werkzeuge, die das zeitgleiche Arbeiten an einem Artefakt ermöglichen. Verbunden

mit Audiounterstützung bietet sich ein sehr mächtiges Werkzeug, das die Zusammenarbeit

zwischen zwei Standorten intensivieren kann. Eine Vielzahl von Werkzeugen stellt bereits

virtuelle Whiteboards zur Verfügung. Anbieter von Office-Anwendungen bieten diese meist

auch mit der Möglichkeit für kollaboratives Arbeiten an. [vgl. Eck08, S. 83/84]

Es bietet sich folglich eine große Anzahl von Werkzeugen an, um die Zusammenarbeit über

die verschiedenen Standorte zu gestalten. Wichtig ist die Auswahl des geeigneten Werkzeugs

für das geplante Einsatzgebiet. Das beste Werkzeug nützt jedoch nichts, wenn es von den

Teammitgliedern abgelehnt oder falsch genutzt wird. Es ist nötig, Anreize zur Kommunikati-

on zu setzen. Hier sollte der Scrum Master mit gutem Beispiel vorangehen und die Nutzung

der Kommunikationswerkzeuge vorantreiben.

6.2 WERKZEUGE

81

6.2.2 TASKMANAGEMENT

Damit das Kanbansystem funktioniert, ist ein gutes Kanbanboard essentiell. Es gibt verschie-

dene Ansätze, ein Kanbanboard über verschiedene Standorte hinweg zu nutzen. Hierbei wird

insbesondere zwischen einem physischen und einem virtuellen Kanbanboard unterschieden.

Bei einem physischen Kanbanboard wird es wie bei einem stationären Team üblich auf einem

Whiteboard aufgezeichnet und mit Kanbankarten versehen. Die Karten werden von den

Teammitgliedern vor Ort verschoben und mit dem jeweils anderen Kanbanboard am entfern-

ten Standort synchronisiert. So können sie sich das aktuelle Kanbanboard jederzeit ansehen,

müssen jedoch darauf achten, es regelmäßig zu aktualisieren. [vgl. And10, S. 97] Diese Va-

riante ist sehr einfach umzusetzen. Sie bietet den entfernten Teams jedoch nur begrenzte

Möglichkeiten, mit dem Board zu arbeiten, da der Stand nicht immer aktuell ist. Des Weiteren

müssen Kennzahlen für jeden Task manuell erfasst werden. Nähere Informationen zu den

Tasks sind noch einmal digital zu speichern, da nicht direkt auf die physischen Karten der

anderen Seite zugegriffen werden kann. Transparenz bezüglich Änderungen an den Karten

gibt es nicht, da keine Änderungshistorie existiert. [richhewlett] Um diesen Problemen entge-

genzusteuern, bieten sich virtuelle Kanbanboards an. Virtuelle Kanbanboards sind meist

Webapplikationen, die sich über das Internet von beliebigen Standorten aus aufrufen lassen.

Neben den Funktionen eines physischen Kanbanboards können auf einem virtuellen viele

zusätzliche Funktionen umgesetzt werden. Der Zugriff erfolgt von jedem Standort in gleicher

Weise.

Kanbansysteme gibt es in unterschiedlichen Größen. Während für ein kleines Projekt eine

einfache Open-Source Anwendung ausreicht, können für komplexe Projekte umfangreiche

Systeme mit großem Funktionsumfang benutzt werden. Um das Qualitätsmanagement zu un-

terstützen und die Mitarbeiter zu entlasten, ist eine automatisierte Erfassung aller Kennzahlen

zu den Karten wünschenswert. So sollte festgehalten werden, zu welchem Zeitpunkt einzelne

Karten verschoben wurden, wann sie bearbeitet oder aktualisiert wurden und wie lange sie

sich im System befanden. Welcher Mitarbeiter explizit für welche Karte zuständig war, ist

dabei nicht wichtig, da dies zu einzelnen Schuldzuweisungen führt und die Ergebnisse Span-

nungen im Team hervorrufen können. Eine höhere Akzeptanz ist bei anonymisierter Datener-

hebung zu erwarten. In der agilen Softwareentwicklung sind Aufgaben nicht klar einzelnen

Personen zuzuordnen, da die Zusammenarbeit des Teams explizit gefordert wird.


82

Das gesamte Team ist für das Produkt verantwortlich. Im Fokus der Kennzahlen stehen daher

die Identifikation von Engpässen und die Gewährleistung eines reibungslosen Ablaufs.

ABBILDUNG 6.4: BEISPIEL EINES VIRTUELLEN KANBANBOARDS [SMARTQ]

Eine Reportfunktion sowie eine Schnittstelle zur Anbindung weiterer Systeme sind nötig.

Reporte geben dem Management einen guten Überblick über den Stand der Entwicklung. Für

tiefgreifende Analysen müssen die erfassten Daten in Analysetools übertragen werden kön-

nen. Hierfür sollten nach Möglichkeit Schnittstellen bereitstehen, um die Daten möglichst

einfach zu übernehmen.

Je nach Möglichkeit, die Anforderungen über das Kanbansystem zu verwalten, sollten zusätz-

liche Anforderungsmanagementsysteme für große Projekte oder eine Ticketverwaltung für

kleine Projekte bereitstehen. Wichtig sind hier die Rückverfolgung von Änderungen sowie

das Zusammenführen des Wissens aller Beteiligten.

6.2.3 QUALITÄTSMANAGEMENTWERKZEUGE

Als ein Ziel des Qualitätsmanagements im Rahmen der Einbindung externer Qualitätssiche-

rung in Scrum wurde die Sicherstellung der Prozessqualität identifiziert. Hierzu werden in der

Regel Prozessmanagementsysteme eingesetzt. Diese dienen zum einen der Dokumentation

des Prozesses, zum anderen unterstützen sie die Ausführung der Abläufe. Bei einem strikten

Einsatz dieser Systeme bekommen die Prozessbeteiligten ihre Aufgaben über das Prozessma-

nagementsystem zugeteilt. [vgl. SN11, S. 27f] Dies lässt sich in einem agilen Projekt jedoch

6.2 WERKZEUGE

83

nicht umsetzen, da sich die Teammitglieder ihre Aufgaben selbstständig aussuchen. Auch

wird der Prozess nicht immer in der vorgegebenen Reihenfolge ausgeführt, kurzfristige Ände-

rungen im Ablauf sind an der Tagesordnung. Ein umfassendes Prozessmanagementsystem,

dass den Prozessfluss steuert wird daher nicht benötigt.

Dennoch existiert ein dokumentierter, übergeordneter Prozess. Auch wenn dieser nicht bin-

dend ist, sollte der Ist-Zustand abgeglichen und seine Abweichungen dokumentiert werden.

Hierfür würde sich ein abgespecktes Prozessmanagementsystem eigenen, das nur zur Proto-

kollierung des Ablaufs gedacht ist. Die hierfür erforderlichen Kennzahlen werden durch das

Kanbansystem erhoben. Es werden dadurch jedoch nur grobe Prozessschritte, wie Implemen-

tierung oder Test, erfasst. Unterprozesse sowie die unternehmensübergreifende Kommunika-

tion sind nicht Bestandteil der Erhebung. Hinzu kommt, dass die Übertragung der Kennzahlen

aus dem Kanbansystem in ein Prozessmanagementsystem, zeitgleich mit ihrer Entstehung

oder nachträglich inkrementell, speziell angepasste Software benötigt. Die Betrachtung des

Prozesses über ein Prozessmanagementsystem ist somit sehr aufwendig in der Einführung und

bietet nur einen geringen Mehrwert. Je nach Projekt sollte daher im Einzelnen darüber ent-

schieden werden, ob die Einführung eines solchen Werkzeugs sinnvoll ist. In kleineren Pro-

jekten genügt eine regelmäßige Evaluierung des Prozesses mit allen Teammitgliedern. Um

frühzeitig Engpässe zu erkennen, ist Kanban ausreichend.

6.2.4 ENTWICKLUNGS- UND TESTWERKZEUGE

Zwei Werkzeuge sind für die Entwicklung von besonderer Bedeutung. Dies ist zum einen

eine Versionsverwaltung für die kontinuierliche Codeintegration sowie die Nutzung eines

Frameworks für die Testautomation.

In einer Versionsverwaltung wird der Code der verschiedenen Entwickler zusammengeführt,

so dass eine zentrale Sammelstelle des Quellcodes geschaffen wird. Gleichzeitig werden wäh-

rend der Zusammenführung die Kompatibilität der Stände geprüft und Konflikte gemeldet.

Hier gibt es sowohl freie [SVN] als auch proprietäre Werkzeuge [IBM Rational Synergie].

Das benötigte Produkt kann je nach Umfang des Projektes ausgewählt werden. Wichtig ist die

regelmäßige Nutzung des Werkzeugs. Umfangreiche Änderungen sind schwerer zu integrie-

ren als viele kleine. Des Weiteren sind die Entwickler und Tester von einem aktuellen Stand

abhängig. Sinnvolle Erweiterung der Versionsverwaltung ist eine Funktion zum automati-

schen Erstellen einer lauffähigen Applikation aus dem Quellcode. Dadurch bekommen Tester


84

schnell Zugriff auf die aktuelle Version, ohne von den Entwicklern für den Build Prozess ab-

hängig zu sein.

Auch für die Testautomatisierung gibt es Werkzeuge in allen Größenordnungen und für jede

Teststufe. Für Unittests ist JUnit [JUnit] ein verbreitetes Werkzeug aus der Java Welt, für die

überwiegenden Programmiersprachen gibt es ähnliche Umsetzungen, meist als Open Source.

Bei der Automatisierung von Systemtests, insbesondere bei der Oberfläche, gibt es Imple-

mentierungen für alle Komplexitätsstufen. Für die Webentwicklung haben sich Selenium

[Selenium] als auch Watir [Watir] als freie Werkzeuge etabliert. Im kommerziellen Bereich

ist das HP Quality Center [HP Quality Center] stark vertreten, welches Tests auf allen Ober-

flächen unterstützt.

Als Bug-Tracking-Systeme sind sowohl der Mantis Bug Tracker [mantis] als auch Bugzilla

[bugzilla] weit verbreitet. Zudem können auch Ticketsysteme wie Trac [trac] zu diesem

Zweck genutzt werden. Wichtig ist, dass die Fehler nach Kritikalität priorisiert werden kön-

nen.

Auch hier hängt die Auswahl des Werkzeugs von Umfang und Komplexität des Projektes ab.

Zusätzlich sind die Qualifikationen der Mitarbeiter zu beachten.

6.3 ZUSAMMENFASSUNG

Zur Unterstützung von Scrum wurde Kanban eingeführt. Zwischen Scrum und Kanban gibt es

mehrere Synergieeffekte, da Scrum einen Managementrahmen bereitstellt und Kanban für

eine Regulierung des Durchflusses sorgt. Die beiden Methoden lassen sich gut miteinander

kombinieren. Durch den Einsatz von Kanban wird eine enge Zusammenarbeit der beteiligten

Standorte erzwungen. Es sorgt für eine hohe, standortübergreifende Transparenz und ermög-

licht die Ermittlung von Kennzahlen. Das inkrementelle Vorgehen von Scrum bleibt jedoch

erhalten und bietet einen Managementrahmen. Um Kanban für Scrum und den Einsatz exter-

ner Qualitätssicherung zu optimieren, wurde ein spezielles Kanbanboard entworfen. Die Ent-

wicklung und die Testvorbereitung sind dabei in zwei Zeilen unterteilt worden. Für die Feh-

lerbehandlung ist eine weitere Zeile eingeführt worden, die einen Schnelldurchlauf der fehler-

haften User Story ermöglicht.

Gleichzeitig wurden die Möglichkeiten zur technischen Unterstützung des Entwicklungspro-

zesses betrachtet. Die benötigten Werkzeuge wurden vorgestellt und ihr Einsatzgebiet erklärt.

6.3 ZUSAMMENFASSUNG

85

Für die Kommunikationswerkzeuge wurde Instant Messaging als Schwerpunkt identifiziert,

welches einen Zustand von “presence and awareness” erzeugt. Des Weiteren ist die Werk-

zeugauswahl des Kanbanboards entscheidend für den Entwicklungsprozess, um die Akzep-

tanz zu erhöhen und Kennzahlen automatisiert erfassen zu können. Weitere Entwicklungs-

und Testwerkzeuge wurden vorgestellt.

Scrum wird dennoch kaum verändert und ein agiles Vorgehen bleibt uneingeschränkt mög-

lich. Die beschriebenen Elemente müssen nun in einen Entwicklungsprozess eingebunden

werden.

87

7 GESTALTUNG DES SOFTWAREENTWICKLUNGS-PROZESSES

Nachdem die Aufgaben auf die beteiligten Unternehmen aufgeteilt, die Qualitätsmana-

gementmethodik ausgewählt und die eingesetzten Werkzeuge und Systeme bestimmt

wurden, wird nun der konkrete Entwicklungsprozess beschrieben. Die Darstellung erfolgt

mittels einer Prozessnotation, auf der die ausführliche, schriftliche Beschreibung fußt.

Abschließend werden die Regelungen bei Aktivitäten außerhalb des Prozesses dargestellt.

7.1 PROZESSMODELLIERUNG

Wie in Kapitel 3 verdeutlicht, ist die Betrachtung von Prozessen ein wichtiger Bestandteil

des Qualitätsmanagements. Dies geschieht im Prozessmanagement Es besteht aus drei

Phasen, der Prozessabgrenzung, der Prozessmodellierung und der Prozessdurchführung.

Während der Prozessabgrenzung entsteht der Prozess. Ausgehend von den unternehmeri-

schen Anforderungen werden Prozesse für jedes Geschäftsfeld identifiziert und bewertet.

Die zu modellierenden Prozesse werden abschließend ausgewählt. Die Prozessmodellie-

rung bildet die Prozesse ab. Dabei kann eine Optimierung der bestehenden Prozesse oder

eine völlige Neugestaltung entstehen. Während der Prozessdurchführung werden die Pro-

zesse ausgeführt und ihr Erfolg an Messgrößen beurteilt. Je nach Ergebnis ist eine erneute

Prozessmodellierung zu durchlaufen. [vgl. Gad10, S. 2f]

Der zu implementierende Prozess ist bereits ausgewählt worden, ein Softwareentwick-

lungsprozess mit Scrum unter Berücksichtigung externer Qualitätssicherung. Nun ist die

Aufgabe ihn zu modellieren um eine Grundlage für seine Ausführung zu bekommen und

anhand von Messgrößen eine langfristige Optimierung zu ermöglichen.

Prozessmodellierung ist die grafische Darstellung eines Prozesses unter Zuhilfenahme

einer Notation, das Ergebnis ist das Prozessmodell. [vgl. SN11, S. 33] Verschiedene No-

tationen haben sich etabliert. Als die drei Bekanntesten sind die Ereignisgesteuerte Pro-

zesskette (EPK), die Unified Modelling Language (UML) sowie die Business Process

Model and Notation (BPMN) zu nennen. In Abbildung 7.1 sind die drei Notationen im

Vergleich nach Interesse und Praxiserfahrung der Nutzer der Website bpm-netzwerk.de

KAPITEL 7: GESTALTUNG DES SOFTWAREENTWICKLUNGSPROZESSES

88

aufgelistet. Im deutschen Raum am weitesten verbreitet ist die EPK. Ihr hauptsächliches

Einsatzgebiet ist auf der Geschäftsebene. Durch ihre langjährige Verwendung ist das

Interesse an der Sprache jedoch zurückgegangen. Die UML ist eine technikorientierte

Sprache und für den Einsatz in der Geschäftsprozessmodellierung nur auf einem hohen

Abstraktionsniveau geeignet. Die BPMN ist eine relativ junge Notation. Ihre Verwen-

dung ist noch nicht so weit verbreitet wie bei der EPK, wird in neuen Projekten jedoch

vermehrt eingesetzt. Da sie die Möglichkeit bietet, auf Geschäftsebene zu modellieren

und trotzdem einen schnellen Einsatz auf der technischen Ebene und Unterstützung von

Geschäftsprozessautomatisierung ermöglicht, ist das Interesse entsprechend hoch. Da

BPMN in den letzten Jahren viel Potential erkennen ließ, sich zunehmender Beliebtheit

erfreut und bei Bedarf in einer Process Engine ausgeführt werden kann, wird sie im Fol-

genden als Notation genutzt.

ABBILDUNG 7.1: POPULARITÄT VON PROZESSNOTATIONEN [ENTNOMMEN AUS FR12, S. XIII]

Zum besseren Verständnis des Prozessmodells werden die wichtigsten Elemente von

BPMN kurz erläutert. Zur Vertiefung ist der Standard auf der Seite der Object Manage-

ment Group (OMG) zu finden. [BPMN]

Es gibt drei Flussobjekte: Aktivitäten, Gateways und Ereignisse. Ihre grafische Darstel-

lung ist in Abbildung 7.2 enthalten.

Die Aktivitäten beschreiben die Tätigkeiten, welche innerhalb des Prozesses durchgeführt

werden. Es existieren zwei verschiedene Arten von Aktivitäten. Einfache Aktivitäten be-

schreiben nur die auszuführende Tätigkeit. Aktivitäten mit einem kleinen Kreuz sind zur

7.1 PROZESSMODELLIERUNG

89

Übersicht zusammengefasste Unterprozesse. Sie lassen sich in Modellierungswerkzeugen

expandieren und zeigen dann einen weiteren Prozess.

Kommt es zu einer Verzweigung, bei der aus verschiedenen Tätigkeiten ausgewählt oder

mehrere Tätigkeiten zusammengeführt werden, wird dies über Gateways gelöst. Das

XOR-Gateway erlaubt nur die Ausführung einer einzigen Folgeaktivität, während beim

AND-Gateway alle angeschlossen Aktivitäten ausgeführt werden. Das OR-Gateway lässt

die Ausführung beliebiger Aktivitäten zu.

ABBILDUNG 7.2: BASISELEMENTE DER BPMN

Eine weitere Kategorie der Flussobjekte sind die Ereignisse. Sie sind auslösender oder

beendender Natur. Unter anderem gibt es Nachrichten-, Zeit und Fehlerereignisse, mit

denen Teile des Prozesses jeweils angestoßen oder beendet werden können.


90

Die Verbindung zwischen den Flussobjekten wird durch Sequenzflüsse hergestellt.

Die Prozessbeteiligten einer Gruppe werden in einem Pool dargestellt. Weitere Gruppen,

Abteilungen oder Bereiche können in zusätzlichen Pools dargestellt werden, zwischen

denen es Kommunikation über Nachrichtenflüsse gibt. Der Pool wird für jeden Beteilig-

ten in eine Lane unterteilt. Die Aktivitäten befinden sich in der Lane des für sie verant-

wortlichen Prozessbeteiligten.

Zusätzlich kann das Prozessdiagramm um Datenobjekte und Artefakte erweitert werden.

Diese sind an die jeweilige Aktivität anzuhängen.

Das Prozessmodell für den Testprozess wird im Wesentlichen mit den in Abb. 7.2 gezeig-

ten Elementen modelliert und dokumentiert.

7.2 PROZESS UND PROZESSMODELL

In Abbildung 7.3 ist der Prozess in seiner niedrigsten Detailstufe zu sehen. Nachdem die

Entscheidung zur Entwicklung gefällt und alle Ressourcen und Systeme zur Verfügung

gestellt wurden, beginnt die Entwicklung. Im ursprünglichen Scrum ist die Pflege des

Product Backlogs kontinuierlich und kann auch während des Sprints stattfinden. Dies ist

möglich da nur der Kunde und der Product Owner daran beteiligt sind. Im neuen Prozess

ist die Qualitätssicherung jedoch zusätzlich anwesend. Sie muss die Anforderungen aus

erster Hand hören, um die Tests genauer gestalten zu können und ist zusätzlich für die

Erstellung der Akzeptanzkriterien verantwortlich. Kontinuierliche Treffen während des

Sprints sind für die externe Qualitätssicherung aufgrund der Entfernung und der Arbeits-

belastung im Sprint schwierig. Aus diesem Grund gibt es einen kontinuierlichen Prozess,

in dem sich Product Owner und Kunde regelmäßig über die Anforderungen austauschen

können. Die Ergebnisse notieren sie sich informell oder in einem separaten Backlog. Im

ersten Schritt des Entwicklungsprozesses werden diese Informationen für die Erstellung

des Product Backlogs herangezogen. Während laufend Anforderungen für das Product

Backlog gesammelt werden können, findet dessen Pflege nun einmal pro Iteration statt.

Nachdem das Product Backlog erstellt wurde folgt das Sprint Planning Meeting, in dem

die einzelnen User Stories ausgewählt und in einzelne Tasks herunter gebrochen werden.

Die ausgewählten Tasks sind die Grundlage für den Sprint, sie werden mit ihren User

Stories in einem Sprint Backlog festgehalten. Bis zum Sprintende wird an den Aufgaben


91

aus dem Sprint Backlog gearbeitet. Nach dem Sprintende findet das Sprint Review zur

Produktvorstellung sowie die Sprint Retrospective für die kontinuierliche Verbesserung

statt. Ist das Produkt fertiggestellt, wird der Prozess beendet. Anderenfalls beginnt er mit

der Pflege des Product Backlogs von neuem.

Auf dieser Detailstufe ist kein Unterschied zum regulären Scrum zu erkennen. Die Abfol-

ge der einzelnen Schritte erfolgt wie vorgeschrieben. Die einzelnen Rollen sind erst in

den Unterprozessen erkennbar.

ABBILDUNG 7.3: DARSTELLUNG DES GESAMTEN ENTWICKLUNGSPROZESSES

Der geöffnete Unterprozess der Aktivität „Pflegen des Product Backlog“ ist in Abbildung

7.4 zu sehen. Beteiligt sind hier der Product Owner, der Kunde und die externe Qualitäts-

sicherung. Ziel ist es, das Product Backlog für das Sprint Planning Meeting vorzuberei-

ten. Der Product Owner ist für den Prozess verantwortlich und führt durch die einzelnen

Schritte. Der Product Owner beruft das Meeting ein. In dem Diagramm sind die Aktivitä-

ten jeweils in der Lane des Verantwortlichen, die Gruppierung der Elemente signalisiert,

dass alle Rollen an ihrer Ausführung beteiligt sind.

Der Produktverantwortliche des Auftraggebers wird im folgenden als Kunde referenziert.

Er beginnt das Meeting damit, seine Anforderung als User Story zu äußern. Dabei wird er

vom Product Owner unterstützt. Ist es eine komplett neue User Story, muss der Kunde sie

genau beschreiben. Haben alle die User Story verstanden, wird sie priorisiert. Die Priori-

sierung gibt wieder, wie dringend die Umsetzung der Anforderung ist. Ein Kriterium für


92

die Priorität kann der erwartete Mehrwert für den Kunden sein. Nach der Priorisierung

identifiziert die Qualitätssicherung die Akzeptanzkriterien des Kunden. Hierdurch wird

der Kunde gezwungen, sich noch einmal konkret mit seinen Wünschen auseinander zu

setzen. Die Akzeptanzkriterien werden für den späteren Test genau dokumentiert. Ab-

schließend erfasst der Product Owner die User Story und fügt die Akzeptanzkriterien bei.

Dies wird solange wiederholt, bis der Kunde alle seine Anforderungen geäußert hat.

Möchte der Kunde eine bestehende Anforderung ändern, werden die Korrekturen an User

Story und Akzeptanzkriterien direkt eingetragen.

Nach der Besprechung erfolgt die Aktualisierung des Product Backlogs durch den Pro-

duct Owner. Es enthält nun alle aktuellen Anforderungen.

ABBILDUNG 7.4: DARSTELLUNG DER PFLEGE DES PRODUCT BACKLOGS

Nach dem das Product Backlog vollständig ist, folgt das letzte Meeting vor dem Sprint. In

Vorbereitung für das Meeting legt der Product Owner die Sprintziele fest. Das Sprintziel

stellt klar, was das erwartete Ergebnis des Sprints ist. Zusätzlich trifft der Product Owner

eine Vorauswahl der Anforderungen für das Sprint Backlog. Das Sprint Planning Meeting

wird vom Scrum Master moderiert, weitere Teilnehmer sind der Product Owner und das

ScrumTeam, nach Möglichkeit vollständig mit externer Qualitätssicherung. Zu Beginn


93

des Meetings stellt der Product Owner das Sprintziel vor und diskutiert es mit dem Team.

Sind alle mit dem Ziel einverstanden, werden die User Stories vorgestellt. Jede User Sto-

ry wird in Tasks zerlegt und ihr Aufwand geschätzt.

Abschließend wird das Kanban System durch das Anlegen der User Stories mit ihren da-

zugehörigen Tasks vorbereitet. Zu diesem Zeitpunkt werden auch die WIP Limits der

einzelnen Spalten vom ScrumTeam gemeinsam mit Product Owner und Scrum Master

festgelegt. Eine Veränderung der WIP Limits ist während des Sprints möglich. Um eine

bessere Identifikation mit den Limits zu erreichen, sollte die Zahl jedoch möglichst ver-

bindlich vom Team zu Beginn bestimmt werden.

ABBILDUNG 7.5: DARSTELLUNG DES SPRINT PLANNING

Das Kanbanboard entspricht dem von Abbildung 6.2 in Kapitel 6.1.2. Es wird für diesen

Prozess davon ausgegangen, dass das Kanbansystem selbstständig alle Metadaten zu dem

Prozess sammelt. Dies bedeutet, dass zu einer Kartenbewegung gleichzeitig alle Zeitin-

formationen sowie die beteiligten Personen erfasst werden.

Während des Meetings sind des Weiteren alle Aktivitäten der Software-

Qualitätssicherung zu klären. Dies bezieht sich sowohl auf die konstruktiven als auch auf

die analytischen Maßnahmen. Für die konstruktive Qualitätssicherung bieten sich regel-

mäßige Reviews der produzierten Artefakte an. Bei komplexeren Sachverhalten ist Pair

Programming empfehlenswert. Für die analytische Qualitätssicherung mit ihren Software-

tests sollten auf jeden Fall Unit Tests durch die Programmierer durchgeführt werden. So

wird schon früh eine Grundqualität in der Software sichergestellt. Nach einer Codeinteg-

ration lassen sich alle Unit Tests durchführen, um ungewollte Seiteneffekte

auszuschließen. Dies ermöglicht der Qualitätssicherung, sich auf die neuen


94

Funktionalitäten zu konzentrieren. Für die externe Qualitätssicherung ist festzulegen, in

wie weit die System- und Akzeptanztests zu automatisieren sind. Die Entscheidung hängt

stark von der Größe des Projektes, der Komplexität der Software und der Reife der An-

forderungen ab. Ist mit vielen Änderungen an der Software zu rechnen, wird der Bedarf

an Nacharbeiten für die automatisierten Testfälle schnell sehr groß. Des Weiteren muss

sich auf zu erfassende Metriken geeinigt werden. Die Metriken sollten aussagekräftig sein

und aus verschiedenen Bereichen stammen. So geben Fehler pro 1000 Zeilen Code eine

gute Auskunft über die konstruktiven Maßnahmen, während Code-Komplexität die Wart-

barkeit der Software offen legt.

Nach dem Sprint Planning Meeting kann der Sprint beginnen (Darstellung auf Seite 96

und 97). Da der Prozess den Durchlauf einer User Story beschreibt, wird das tägliche

Daily Scrum nicht betrachtet. Es dient zum Austausch von Information und zur internen

Koordination, bezieht sich jedoch nicht direkt auf die Umsetzung einer User Story. An

dem Sprint sind drei Rollen direkt beteiligt. Der Product Owner gibt die zu entwickelnden

User Stories vor und nimmt sie ab. Die Entwicklung implementiert die User Stories und

behebt die Fehler. Die Qualitätssicherung testet die User Stories im Einzelnen und das

Softwareprodukt im Ganzen.

Zu Beginn des Sprints wählt der Product Owner eine oder mehrere User Stories aus. Die

User Stories werden in der Spalte Sprint Backlog an die oberste Stelle gesetzt. Von dort

aus entnehmen sowohl die Entwicklung als auch die Qualitätssicherung ihre Aufträge.

Bei jeder Verschiebung einer Karte wird ein Service ausgelöst. Der Status innerhalb des

Kanban Werkzeugs wird automatisch verändert und alle Metadaten vervollständigt und

gespeichert.

Es gibt jeweils Aufgaben für die Implementierung als auch für die Qualitätssicherung

während der Entwicklung. Die Aufgaben der Softwareentwickler beschäftigen sich mit

dem Design der Softwarearchitektur und der Implementierung der Funktionen. Die Tasks

der Qualitätssicherung haben ihren Schwerpunkt auf der Testfallerstellung und Testauto-

matisierung. Die Entwickler und die Tester stimmen sich auf eine der vom Product Ow-

ner ausgewählten User Stories ab. Die zur User Story gehörenden Tasks werden in die

Spalte todo gezogen. Von dort können die Teammitglieder ihre Aufgaben entnehmen. Die

Entwickler ziehen sich ihre Kanbankarten in die Spalte „In Arbeit“ und beginnen mit

ihrer Umsetzung. Das Umsetzen eines Tasks beinhaltet die Implementierung sowie die


95

Sicherstellung einer ausreichenden Qualität durch zuvor festgelegte Maßnahmen wie Re-

views und Unittests. Nach der Erfüllung der Aufgabe wird der Quellcode in das Gesamt-

system integriert. Zur Integration gehört das Ausführen aller Unittests, um Seiteneffekte

auszuschließen.

Fehler sind sofort zu beheben. Nach einer erfolgreichen Integration wird der Task zu

„Done“ verschoben. Dies wird solange wiederholt, bis alle Tasks einer User Story umge-

setzt wurden. Ähnlich läuft es bei der Qualitätssicherung ab, mit dem Unterschied, dass

hier keine kontinuierliche Integration stattfindet, da nicht am Produkt entwickelt wird.

Das Speichern und Zusammenführen der Ergebnisse geschieht während der Umsetzung

des Tasks.

Durch das Kanbanboard und die Aufteilung in verschiedene Zeilen können die Qualitäts-

sicherung und die Entwicklung parallel an unterschiedlichen Aufgaben einer User Story

arbeiten, obwohl sie an unterschiedlichen Orten untergebracht sind. Der Fortschritt der

User Story und die offenen Aufgaben für beide Seiten sind transparent und fördern ein

Gefühl der Zusammengehörigkeit.

Nach dem alle Tasks einer User Story umgesetzt wurden, wird die Software automatisch

erstellt, so dass die aktuellste Version für die Tester zugänglich ist. Die Tasks werden

gebündelt und unter der User Story zusammengefasst. Die User Story wird in die Spalte

User Story Done verschoben. Entwickler und Tester beginnen mit der Arbeit an der näch-

sten User Story. Die Arbeit an der nächsten User Story wird von den Testern unterbro-

chen, wenn der Product Owner die vorherige zum Testen freigegeben hat. Selbiges zählt

für die Entwickler, sobald Fehler gefunden wurden.

Bevor umfangreiche Tests an der User Story vorgenommen werden, obliegt es erst dem

Product Owner, alleine oder zusammen mit dem Kunden die fertiggestellte User Story zu

überprüfen. Sie Testen nicht auf Fehler, sondern validieren, ob sich die Umsetzung mit

den Anforderungen an das Produkt deckt. Sollten trotz Unittest Ausführungsfehler oder

Änderungen aufgrund mangelnder Anforderungsumsetzung auftreten, können diese je

nach Schwere direkt von den Entwicklern behoben oder als Fehlerkarte in die Zeile „Re-

work“ des Kanbanboards abgelegt werden. Wird der Fehler direkt behoben oder tritt kei-

ner auf, ist die Kanbankarte nach „Test todo“ zu verschieben.


96

ABBILDUNG 7.6: DARSTELLUNG DES SPRINTS TEIL 1


97

ABBILDUNG 7.7 DARSTELLUNG DES SPRINTS TEIL 2


98

Die Tester müssen eine gute Balance zwischen Testvorbereitungsaktivität und dem Tes-

ten von User Stories finden. Bei einem hohen Anteil von automatisierten Testfällen wird

mehr Zeit mit der Testvorbereitung verbracht, da die Testfälle während der Entwicklung

zu automatisieren sind. Bei einem hohen Anteil an manuellen Tests nimmt die Testvorbe-

reitung entsprechend weniger Zeit ein, dafür dauert die Testdurchführung länger.

Die Tester wählen die User Story jeweils nach der höchsten Priorität aus. Meistens ist es

die User Story, die am längsten in der Warteschlange steht. Kommt jedoch eine User Sto-

ry hinzu, deren Priorität kurzfristig geändert wurde, kann diese schnellstmöglich getestet

werden.

Die User Story wird wie festgelegt getestet. Zwei Arten von Tests sind in der Regel

durchzuführen. Auf der einen Seite die Tests der User Story selbst. Hier werden die neu

implementierten Funktionen gegen die Anforderungen und Akzeptanzkriterien geprüft.

Zusätzlich ist es noch nötig, mittels Regressionstest Seiteneffekte auf andere Module aus-

zuschließen. Tritt ein Fehler auf, wird der Test sofort gestoppt und der Fehler an die Ent-

wickler weitergereicht. Auch hier gibt es dazu zwei Möglichkeiten. Ist der Aufwand für

die Fehlerbehebung gering und steht ein Entwickler zur Verfügung, sollte eine direkte

Fehlerbehebung initialisiert werden. Mit der neuen Version sind die Tests direkt fortzu-

setzen.

Lässt sich der Fehler nicht sofort beheben, ist eine Kanbankarte für die Spalte „Rework“

zu erstellen, bevor der Test weitergeführt wird. Sind nach Abschluss der Tests offene

Fehler in der Zeile „Rework“ zu der User Story vorhanden, wird diese auch dort abgelegt.

Sie wandert mit ihren Tasks durch die Spalten bis sie wieder bei den Testern ankommt.

Existieren keine offenen Fehler, ist die User Story abgeschlossen und wird in der Spalte

„User Story Done“ abgelegt.

Bei der Auswahl von Tasks haben die Aufgaben der Spalte „Rework“ höchste Priorität.

Sie gewährt einen schnellen Durchlauf für die User Story und ihre Tasks zur Fehlerbehe-

bung. Auf dem Kanbanboard ist sie extra gekennzeichnet, um ihre Wichtigkeit hervorzu-

heben. Wurde die Story bereits vom Product Owner überprüft, wird dieser Schritt über-

sprungen und die Story direkt an die Qualitätssicherung weiter gereicht. Desto länger sich

eine User Story im System befindet, desto höher wird ihre Priorität. Befinden sich nach

mehrmaligem Testen noch Fehler in der User Story, ist ihre Priorität derart angestiegen,

das ein sehr schneller Wechsel zwischen Qualitätssicherung und Entwicklung entsteht,


99

der nur in direkte Kommunikation münden kann, da sonst keine anderen Tätigkeiten mehr

möglich sind. Zusätzlich begrenzen die WIP Limits die im Umlauf befindlichen Karten,

so dass beide Unternehmen gemeinsam Engpässe beseitigen müssen, um weiter arbeiten

zu können. Das Vorhaben, die Fehler einer User Story zu Aufgaben der nächsten User

Story zu machen, wird so umgesetzt. Neue Tasks der aktuellen User Story dürfen erst ins

System gezogen werden, wenn die Fehler der vorherigen User Story behoben worden

sind.

Der Prozess lässt die Grenzen zwischen den verschiedenen Aufgabengebieten der Unter-

nehmen deutlich erkennen. Es herrscht trotzdem eine hohe Transparenz und eine enge

Verbindung zwischen den Unternehmen, so dass ein Gefühl der Zusammengehörigkeit

entstehen kann und die gute Zusammenarbeit gewährleistet wird.

Nach dem Sprint findet, wie in Scrum vorgesehen, das Sprint Review statt, bei dem das

Team gemeinsam mit ScrumMaster dem Product Owner und dem Kunden die Ergebnisse

vorstellt (siehe Abbildung 7.8). Hier findet keine Veränderung vom regulären Vorgehen

statt, die Anwesenheit der externen Qualitätssicherung ist nicht unbedingt nötig, würde

jedoch zur Teambildung beitragen.

ABBILDUNG: 7.8: DARSTELLUNG DES SPRINT REVIEW UND DER SPRINT RETROSPECTIVE

Veränderungen werden in der Sprint Retrospective geplant. Ursprünglich dient sie auch

der Prozessverbesserung, jedoch nur für ScrumTeam, ScrumMaster und Product Owner.

Da der Prozess über mehrere Unternehmen an Komplexität gewonnen hat und für kriti-

sche Systeme ein besonderes Interesse an hoher Qualität besteht, fällt der Prozessverbes-

serung ein höheres Gewicht zu. Aus diesem Grund sind auch der Kunde sowie weitere

Stakeholder aus dem Management der beteiligten Unternehmen anwesend. Die durch das

Kanbanwerkzeug erfassten Daten und die erhobenen Metriken sind schon zuvor ausge-

wertet worden und stehen jedem Beteiligten zur Verfügung. Die Daten werden


100

gemeinsam besprochen. Das Team sowie das Management legen jeweils ihre Sichtweise

über den Erfolg des vergangenen Sprints sowie zukünftige Verbesserungspotentiale dar.

Dies kann zu völlig unterschiedlichen Ergebnissen aus dem jeweiligen Blickwinkel füh-

ren, da das Team seine Erkenntnisse direkt aus der Arbeit erhält, während das Manage-

ment die Situation aus der Distanz beurteilt. So ist sowohl Praxisnähe als auch eine unab-

hängige Distanz gewährleistet.

Nachdem die Sprint Retrospective abgeschlossen wurde, beginnt der Zyklus erneut mit

dem Pflegen des Product Backlogs.

7.3 AUSNAHMEN UND INFORMELLE KOMMUNIKATION

Der dargestellte Prozess stellt den idealen Durchlauf einer User Story da. Nicht alle in

Kapitel 5.2 identifizierten Schnittstellen zu Kommunikation und Informationsaustausch

sind abgedeckt. Insbesondere auf die Kommunikation von Team zu Product Owner und

Kunde wurde nicht weiter eingegangen. Es wurde angenommen, dass keine weiteren In-

formationen von Kunde und Product Owner benötigt werden, da die User Story alle Be-

teiligten vollständig informiert.

Dies ist in der Praxis jedoch meistens nicht der Fall. Aus diesem Grund existieren Kon-

zepte wie „On Site Customer“. In Scrum wurde hierfür die Rolle eines Product Owner

erstellt. Des Weiteren ist der Umgang mit Fehlern nicht immer klar, da nicht immer ein

Bugfix im selben Sprint nötig ist. Die Entscheidung, wann eine Story fertig ist, obliegt

letztendlich dem Product Owner.

Folglich ist der Umgang mit verschiedenen Ausnahmen im Prozess sowie die Verbreitung

wichtiger Informationen zu klären.

Während des Designs und der Implementierung der Tasks oder der Vorbereitung der

Testfälle zu den User Stories beschäftigen sich Entwickler und Tester zum ersten Mal

intensiv mit den Anforderungen. Zu diesem Zeitpunkt können unklare Beschreibungen zu

einem Informationsmangel führen. Ein Mitglied des Teams wird mit dem Product Owner

in Verbindung treten und um Klarstellung bitten. Die aus dem Gespräch gewonnen In-

formationen können für das gesamte Team von Bedeutung sein. Würden die konkretisier-

ten Anforderungen nicht mit dem Rest des Teams geteilt werden, können andere Team-

mitglieder zu eigenen, abweichenden Interpretationen der User Story kommen.

7.3 AUSNAHMEN UND INFORMELLE KOMMUNIKATION

101

Aus diesem Grund sind zwei Aktivitäten durchzuführen. Die User Story und die zugehö-

rigen Tasks sind um die konkretisierten Anforderungen zu erweitern. Dies sollte direkt an

den Kanbankarten geschehen, bzw. im System, in dem die Anforderungen festgehalten

werden. Um die Verbreitung der zusätzlichen Informationen zu gewährleisten und um die

Teammitglieder nicht von ihrer Kernaufgabe abzulenken, sollte der Product Owner per-

sönlich für die Verbreitung der Informationen sorgen. Da der Scrum Master das Team vor

Änderungen der Anforderungen während des Sprints schützen muss, hat er jeden Eintrag

des Product Owners zu prüfen und festzustellen, ob es sich um Konkretisierungen und

nicht um Erweiterungen handelt. Folglich sind Product Owner und ScrumMaster gemein-

sam für die Verbreitung der Informationen zuständig, der erstgenannte als Initiator und

Dokumentator, der zweite als Kontrollinstanz. Wichtig ist, dass das System, in dem die

Anforderungen festgehalten werden, sei es direkt das Kanbanwerkzeug oder eine externe

Software, über eine Änderungshistorie verfügt. Es muss ersichtlich sein, welche Ände-

rungen an der Anforderung vorgenommen wurden.

Neben der Dokumentation der neuen Informationen sind alle Teammitglieder über die

Anpassung der User Story in Kenntnis zu setzen. Dies sollte so früh wie möglich gesche-

hen. Als Kommunikationswerkzeug bietet sich E-Mail-Verkehr aufgrund seiner Asynch-

ronität an.

Der Product Owner muss sich nicht nur seiner Rolle als Vertreter des Kunden bewusst

sein, sondern sich auch als Informationsvermittler für das gesamte Team verstehen.

Durch die Trennung auf zwei Standorte und der Abwesenheit der Qualitätssicherung

während des Daily Scrum ist diese weitere Funktion notwendig.

Ein weiterer Zeitpunkt, an dem die Kommunikation mit dem Product Owner benötigt

wird, ist die Beurteilung von Fehlern. Im Prozess wurde vereinfacht angenommen, dass

jeder Fehler zu beheben ist und die nötigen Änderungen bekannt sind. Neben Fehlern,

deren Behandlung einfach ersichtlich ist, existieren unklare Fälle.

Den Testern können neben direkten Fehlern auch Unstimmigkeiten auffallen. Durch die

Arbeit mit der Software während der Tests können zusätzlich Verbesserungsvorschläge

entstehen.

Diese müssen zum einen erst vom Product Owner gesichtet werden. Stimmt der Product

Owner zu, muss er den Zeitpunkt der Einarbeitung bestimmen. Soll dies gleich


102

geschehen, sind sie wie Fehler zu behandeln und im Kanbanboard entsprechend

einzutragen. Sollen die Fehler in einem späteren Sprint behandelt werden, sind sie in

einem Bug-Tracking-System abzulegen.

Dieselbe Prozedur muss mit Fehlern geschehen, die keine direkte Auswirkung auf die

Funktionsweise der Software haben. Dies könnte zum Beispiel bei langen Antwortzeiten

oder der falschen Anordnung von Elementen auf der Oberfläche der Fall sein.

Die Akzeptanzkriterien können nicht zu der umgesetzten User Story passen, obwohl sie

schon zuvor vom Product Owner abgenommen wurde. Hier ist eine Diskussion mit dem

Kunden anzuregen, um zu klären, von wem die User Story falsch verstanden wurde.

Die informelle Kommunikation zwischen den beiden Standorten wurde in den Prozess

nicht aufgenommen. Zum einen kann diese jederzeit stattfinden, zum anderen ist es den

Teammitgliedern überlassen, wie sie diese gestalten. Es ist jedoch wichtig, dass Abspra-

chen, die weitere Mitglieder oder den ganzen Prozess betreffen, verteilt werden. Hier sind

dieselben Kommunikationswege wie vom Product Owner zu nutzen. Die Kommunikation

wird nicht weiter reguliert da die Teammitglieder, wie in agilen Teams üblich, frei zu-

sammen arbeiten sollen.

Neben der Kommunikation ist der Umgang mit Ausnahmefehlern im Bug-Tracking-

System zu beschreiben. Die Spalte „Rework“ des Kanbanboard dient als Bug-Tracking-

System für Fehler, die unmittelbar zu beheben sind. Ein weiteres System ist für Fehler zu

verwenden, deren Behebung nicht unmittelbar im Sprint geschehen muss. Die im Bug-

Tracking-System abgelegten Fehler sind für alle ersichtlich. Die Tester können erkennen,

ob ein gefundener Fehler schon zuvor gemeldet worden ist. Der Product Owner kann

Fehler aus dem Bug-Tracking-System entnehmen und in das Kanbanboard überführen.

Die Entwickler können jederzeit Fehler aus dem BTS beheben. Dies bietet sich an, wenn

eine Funktion erweitert werden soll, für die zuvor schon Fehler eingetragen wurden. Das

BTS ist vom Product Owner regelmäßig zu überprüfen. Dort abgelegte Fehler laufen Ge-

fahr, vergessen zu werden.

Ein weiterer Sonderfall ist die Beauftragung der externen Qualitätssicherung durch den

Auftraggeber der Entwicklung. Dadurch ist die externe Qualitätssicherung nicht nur für

die Prüfung der Software zuständig, sondern informiert den Kunden regelmäßig über den

Stand der Entwicklung. Am Ende des Sprints hat die Qualitätssicherung das beste

7.4 ZUSAMMENFASSUNG

103

Verständnis über die Qualität und Leistung der Software. Besonders bei kritischen Sys-

temen ist die Bewertung der Reife von besonderer Relevanz. Der Einsatz der Software im

Produktivsystem hängt davon ab. Der externen Qualitätssicherung kommt somit eine be-

ratende Funktion hinzu. Sie kann vom Einsatz der Software nach einem Sprint abraten

und den Kunden auf Probleme hinweisen. Dadurch kann der Kunde direkten Einfluss auf

die Software nehmen. Unter anderem könnte er einen Release Sprint initialisieren, um die

Software für die Auslieferung vorzubereiten.

7.4 ZUSAMMENFASSUNG

Der Entwicklungsprozess wurde mittels BPMN modelliert. Durch die Modellierung ist

der Prozess dokumentiert und kann einfach nachgeschlagen werden. Des Weiteren wird

die Ausführung durch eine Prozess Engine ermöglicht. Die Dokumentation des Prozesses

dient als Grundlage für die Optimierung in den folgenden Sprints.

Der ideale Ablauf des Entwicklungsprozesses ist gut ersichtlich. Während in den von

Scrum vorgesehenen Vorbereitungs- und Nachbereitungsbesprechungen wenige Verände-

rungen notwendig waren, ist der Sprint aufgebrochen worden. Es wurde gezeigt, dass

trotz räumlicher Entfernung mittels des Einsatzes von Kanban eine enge Zusammenarbeit

erzwungen wird. Durch die hohe Transparenz des Kanbanboards und die Beschränkung

des WIP sind die beiden Auftragnehmer gezwungen, regelmäßig in Kontakt zu treten.

Trotzdem lässt der Prozess unabhängiges Arbeiten zu. Die Schnittstellen der Unterneh-

men sind klar definiert, die Arbeiten überlappen sich an keiner Stelle. Das Vorgehen ist

darauf ausgelegt, User Stories so schnell wie möglich abzuarbeiten. Hierzu wird ein

schneller Wechsel zwischen Test und Fehlerbehebung implementiert. Die Bearbeitung

weiterer User Stories ist erst durchgehend möglich, wenn die vorherigen um Fehler berei-

nigt wurden. Die intensive Prüfung durch die Qualitätssicherung, die in agilen Methoden

verwendeten konstruktiven Maßnahmen und die Konzentration auf wenige Aufgaben zur

gleichen Zeit ermöglichen eine hohe Softwarequalität.

Doch nicht alle Aktivitäten wurden vom Standardablauf abgedeckt. Es kann Kommunika-

tion auftreten, die Information mit Dokumentationsbedarf hervorbringt, wie z.B. zum

besseren Verständnis von Anforderungen. Da dies meist ad hoc und auf verschiedenen

Wegen geschieht, wird es hier nicht prozessual geregelt. Es wird jedoch verdeutlicht, was


104

in diesem Fall zu geschehen hat. Auch der Einsatz eines Bug Tracking Systems und das

Verhältnis der Qualitätssicherung zum Kunden wurden beschrieben.

Mittels des Prozesses und unter Berücksichtigung seiner Ausnahmen ist es möglich, ex-

terne Qualitätssicherung in den agilen Softwareentwicklungsprozess, insbesondere

Scrum, zu integrieren und Software mit hoher Qualität für den Einsatz in kritischen Be-

reichen herzustellen.

105

8 FALLBEISPIEL

Nachdem der Entwicklungsprozess herausgearbeitet und verdeutlicht wurde, wird seine

Anwendung in der Praxis gezeigt. Hierfür wird ein reales Projekt herangezogen, das

durch den Prozess zu optimieren ist. Zuerst wird die Ist-Situation dargestellt und analy-

siert. Es werden die Probleme und Schwierigkeiten des aktuellen Vorgehens aufgezeigt.

Davon ausgehend wird betrachtet, wie sich der Entwicklungsprozess einführen lässt und

welche Verbesserungen zu erwarten sind.

8.1 DARSTELLUNG UND ANALYSE DES BEISPIELPROJEKTS

Das Büro für praktische Informatik (BFPI) aus Wismar ist Auftragnehmer eines mittels-

tändischen Unternehmens aus Hamburg, von mir bezeichnet als Wind AG (Name geän-

dert), die im Windkraftbereich tätig ist. Über mehrere Jahre hinweg hat sich eine enge

Geschäftsbeziehung entwickelt, durch die ein hohes Wissen über die Bedürfnisse des

Kunden entstanden ist. Durch die Bereitstellung qualitativ hochwertiger Software sowie

einer stabilen Termintreue hat die Wind AG viel Vertrauen in die Arbeit des BFPI ge-

wonnen. Um die gleichen Resultate mit anderen Auftragnehmern zu erreichen, ist die

Wind AG dazu übergegangen, das BFPI als externe Qualitätssicherung in Auftragspro-

duktionen hinzuzuziehen. Dabei steht insbesondere die Schaffung von Vertrauen in die

eingekauften Softwareprodukte im Vordergrund, da diese in unternehmenskritischen Be-

reichen eingesetzt werden. Zusätzlich wird für interne Richtlinien ein unabhängiger Test-

bericht vor der Produktivsetzung gefordert.

In einem jüngeren Projekt wurde ein Entwicklungsauftrag an einen Softwareentwickler

aus Hamburg vergeben, die Entwicklung GmbH (Name geändert). Gefordert war eine

Software zu Auswertung und Visualisierung von Betriebsdaten. Diese Daten dienen zum

einen zur Verrechnung mit dem Kunden, zum anderen als Referenz bei der Entwicklung

neuer Produkte. Sie ist somit kritisch für das Kerngeschäft des Unternehmens. Die Ent-

wicklung GmbH benutzt Scrum zum Herstellen ihrer Softwareprodukte. Auch in diesem

Projekt ist eine unabhängige Qualitätssicherung vom Kunden gewünscht worden. Vor

Entwicklungsbeginn ist die Einbindung der Qualitätssicherung nicht durchgeplant wor-

den, die entstandene Vorgehensweise hat sich während der Entwicklung herausgebildet.

KAPITEL 8: FALLBEISPIEL

106

Da zum Entwicklungsbeginn die konkrete Vorgehensweise für die Einbindung der Quali-

tätssicherung noch nicht feststand, war diese nicht an den Planungsprozessen beteiligt.

Die Entwicklung begann gemäß den Vorgaben von Scrum. Der Product Owner traf sich

mit dem Kunden, um die Anforderungen aufzunehmen. Bei der Wind AG lag ein internes

Dokument vor, indem das gewünschte Softwareprodukt grob beschrieben wurde. Dies ist

der Entwicklung GmbH zur Verfügung gestellt worden und diente als Grundlage für die

User Stories. Unklare Positionen sind mit dem Kunden abgesprochen worden, so dass

manche User Stories von den Vorgaben der internen Spezifikation abwichen. Die erstell-

ten User Stories ließen viel Interpretationsspielraum zu, der Product Owner musste dem

Scrum Team regelmäßig Hilfestellung bei deren Umsetzung leisten. So wurde die Soft-

ware mehrere Iterationen lang entwickelt, bis sie einen Stand erreicht hatte, an dem eine

erste Produktivsetzung sinnvoll war.

Erst zu diesem Zeitpunkt wurde die externe Qualitätssicherung hinzugezogen. Ihr wurde

die interne Spezifikation sowie die Featurelisten mit den User Stories übergeben. Es gab

keine nähere Einführung in die Thematik der Software. Aus den vorliegenden Artefakten

wurden Testfälle abgeleitet. Die Testfälle sind in ein Open-Source Testmanagement Sys-

tem eingepflegt worden. Auf diese Weise hatte der Kunde direkten Zugriff auf die Test-

fälle. Sobald die Testfälle aus den vorliegenden Artefakten erstellt wurden, sind sie vom

Kunden abgenommen worden. Hierbei sind schon einige Änderungen an den Anforde-

rungen festgestellt worden, die in die User Stories und die Spezifikation noch nicht ein-

geflossen waren. Die Testfälle mussten mehrmals korrigiert werden.

Nachdem die Testfälle abgenommen worden sind, wurde die Software an das BFPI über-

geben. Diese installierte die Software in Eigenregie auf ihrem Testserver. Danach wurde

mit dem Testen begonnen. Automatisierte Testfälle wurden von der externen Qualitätssi-

cherung nicht erstellt, da dieser Aufwand nicht gerechtfertigt erschien. Während die Test-

ergebnisse in dem Testmanagement System gespeichert wurden, sind parallel Tickets mit

Änderungsaufgaben für die Entwickler in einem Ticketsystem der Wind AG angelegt

worden. Die Entwickler der Entwicklung GmbH exportierten die Tickets aus diesem Ti-

cketsystem in ihr eigenes Ticketsystem. Der Kunde wünschte einen Testbericht nach je-

dem Testdurchlauf. Dieser wurde aus dem Testmanagementsystem generiert. Die gefun-

denen Fehler wurden in den nächsten Sprints behoben. Sowie erneut eine auslieferbare

Version erstellt worden ist, wurde geprüft, ob die Fehler korrekt behoben worden sind.

8.1 DARSTELLUNG UND ANALYSE DES BEISPIELPROJEKTS

107

Zusätzlich mussten aufgrund der Implementierung weiterer User Stories neue Testfälle

erstellt und ausgeführt werden. Zum Ende der Entwicklung waren die meisten User Sto-

ries umgesetzt und in den Sprints sind größtenteils Bug Fixes vorgenommen worden, bis

schließlich nur noch Fehlerbehebung betrieben wurde, um das Produkt ausliefern zu kön-

nen.

Dieses Vorgehen brachte diverse Schwierigkeiten mit sich.

Da die externe Qualitätssicherung nicht von Anfang an in die Planungsprozesse einbezo-

gen wurden, ist nie ein konkreter Zeitpunkt zur Erstellung der Testfälle und Durchfüh-

rung der Tests festgesetzt worden. Die Entwicklung setzte dadurch die für den Sprint ge-

forderten User Stories um, jedoch nie mit der für eine Auslieferung erforderlichen Quali-

tät. Als vom Kunden kurzfristig ein Termin für die erste Auslieferung zum Test gesetzt

wurde, war dies sowohl für die Entwicklung als auch für die Tester problematisch. Die

Entwicklung hatte bislang nicht auf eine Auslieferung hingearbeitet und musste nun die

Software von bekannten Fehlern und offenen User Stories bereinigen. Die Tester hatten

dadurch nur wenig Zeit, sich in die Anforderungen einzuarbeiten. Eine detaillierte Erklä-

rung des Einsatzgebietes und der Anforderungen an die Software gab es nicht. Dadurch,

dass die interne Spezifikation nicht weiter gepflegt wurde, sind viele Testfälle entstanden,

die für die bestehende Software nicht gültig waren. Zudem sind durch die oberflächlichen

User Stories auch sehr oberflächliche Testfälle entstanden, die viel Interpretationsspiel-

raum zuließen. Da die externe Qualitätssicherung vom Kunden beauftragt und keine

Kommunikation zum Product Owner oder den Entwicklern angeregt wurde sowie ein

knapper Zeitrahmen bestand, hat keine tiefgreifende Kooperation zwischen den Auftrag-

nehmern stattgefunden, während der die Anforderungen hätten konkretisiert werden kön-

nen. Diese Situation erschwerte das Testen der Software. Es war nicht immer klar zu un-

terscheiden, ob es sich um einen Fehler handelte oder die Anforderungen an dieser Stelle

von den Testern fehlinterpretiert wurden. Unnötig erstellte Fehlertickets verschlechterten

die Beziehung zwischen Testern und Entwicklern zusehends. Die Entwickler hatten das

Gefühl, dass die Tester ihre Arbeit nicht korrekt ausführten, während die Tester durch

scheinbar grundlos abgelehnte Testfälle ihre Arbeit nicht gewürdigt sahen.

Eine weitere Schwierigkeit entstand dadurch, dass die Installation der Software vom

BFPI vorgenommen wurde. Bei der zu testenden Applikation handelte es sich um eine

Webapplikation, für die eine aufwendige Konfiguration des Webservers erforderlich war.


108

Durch unzureichende Installationsbeschreibung sowie die komplexen Einstellungen kam

es zu Konfigurationsfehlern, die sich auf das Programm auswirkten. So entstanden Feh-

ler, die von den Entwicklern auf ihren Systemen nicht nachvollzogen werden konnten.

Die Identifikation der Probleme erforderte von beiden Seiten einen hohen Aufwand.

Neben den durch die Anforderungen und die Testumgebung hervorgerufenen Problemen

verkomplizierten die eingesetzten Systeme zusätzlich das Vorhaben. Durch die Trennung

des Testmanagementsystems für den Kunden und das Ticketsystem für die Entwickler

mussten Fehler und Anmerkungen an zwei unterschiedlichen Orten festgehalten werden.

Dies erhöhte den Aufwand für die Qualitätssicherung bei der Erstellung der Testergebnis-

se und Tickets, als auch beim Nachtest, da die Einträge in beiden Systemen gesucht und

ergänzt werden mussten. Wurden Informationen nur in einem der beiden Systeme festge-

halten, bekamen diese entweder der Kunde oder die Entwickler nicht zu sehen, was je-

weils zu einem falschen Eindruck über den Stand der Tests als auch der Qualität geführt

hat. Zusätzlich bekamen die Entwickler nur negatives Feedback aus der Qualitätssiche-

rung, da sie nur die Fehlertickets, jedoch nicht die bestandenen Testfälle sahen.

Neben den genannten Schwierigkeiten blockierten die Mechanismen zur Fehlerbehebung

die inkrementelle Auslieferung der Software zur Produktivsetzung komplett. Durch die

zuvor beschriebenen Hindernisse und die Notwendigkeit, die Software komplett am Stück

zu testen, dauerte die Testphase sehr lange, etwa die Dauer von 2 Sprints. Erst im dritten

Sprint konnten die gefundenen Fehler behoben werden. Dies hatte zum einen zur Folge,

dass Fehler bereits nicht mehr aktuell waren, da die Funktion, auf die sie sich bezogen,

bereits geändert worden war. Zum anderen konnte die Software nach der Fehlerbehebung

nicht produktiv gesetzt werden, da sich bereits neue Funktionalitäten von 3 Sprints in der

Software befanden, die zuerst getestet werden mussten. Um auch Seiteneffekte abzude-

cken, wurden die Tests wieder entsprechend aufwendig, so dass sich die Fehlerbehebung

verschob. Entsprechend entstand in keinem Inkrement eine Software, die getestet und von

der Qualitätssicherung freigegeben wurde. Erst nachdem alle Anforderungen umgesetzt

waren, wurde sich komplett auf die Qualität konzentriert. Dadurch ergab sich trotz der

Nutzung eines agilen Vorgehensmodells kein frühzeitiger Return on Investment.

Es konnte zwar sichergestellt werden, dass keine fehlerhafte Software in die produktive

Umgebung eingespielt wurde, dafür ist eine frühzeitige Nutzung der Software jedoch

komplett verhindert worden. Einer der großen Vorteile der agilen Softwareentwicklung

8.2 ANWENDUNG DES AUSGEARBEITETEN PROZESSES AUF DAS FALLBEISPIEL

109

wurde durch den Einsatz externer Qualitätssicherung ausgeschaltet. Die mangelhafte In-

tegration der Qualitätssicherung, das unzureichende Anforderungsmanagement, die unge-

nügende Nutzung von Werkzeugen und die nicht vorhandene Eintaktung des Testens in

den Zeitplan führten zu erhöhten Aufwänden und einem schlechten Verhältnis zwischen

Qualitätssicherung und Entwicklung.

Um künftige Projekte mit größerem Erfolg abschließen zu können, muss die externe Qua-

litätssicherung besser in den Entwicklungsprozess integriert werden. Der zuvor ausgear-

beitete Entwicklungsprozess wird daher im Folgenden auf das Projekt angewandt und

beschrieben, wie das Projekt mit dem Vorgehen hätte ablaufen können.


Bei der Anwendung des Prozess in einem Projekt mit den genannten Rahmenbedingun-

gen ist der Tatsache, dass die externe Qualitätssicherung durch den Auftraggeber hinzu-

gezogen wurde, besondere Aufmerksamkeit zu schenken.

Weder die Entwicklung, noch die Qualitätssicherung ist sich vor Testbeginn einander

bewusst gewesen. Die Entwickler bekamen plötzlich das Gefühl, einer Überwachungsin-

stanz gegenüberzustehen, während die Tester von der Aufgabe, aus einer für ein agiles

Vorgehen vorgesehenen Spezifikation Testfälle abzuleiten, frustriert wurden. Diese nega-

tive Situation zeigt deutlich, wie wichtig die frühzeitige Integration der externen Quali-

tätssicherung in die Entwicklung ist.

Der Prozess sieht das erste Zusammentreffen mit dem Auftragnehmer während der Auf-

nahme der User Stories mit dem Product Owner und beim Sprint Planning mit dem Rest

des Teams vor. Aufgrund der geringen Entfernung zwischen Hamburg und Wismar ist die

regelmäßige Teilnahme an allen größeren Treffen möglich. Ein persönlicher Kontakt

kann so früh hergestellt werden.

Bei der Aufnahme der User Stories ist die Qualitätssicherung ein wichtiger Faktor. Die

im Fallbeispiel aus der Spezifikation abgeleiteten User Stories waren ungenau. Durch die

Forderung der externen Qualitätssicherung nach konkreten Akzeptanzkriterien sind die

User Stories schon sehr viel genauer zu gestalten.


110

Die Wind AG spezifiziert die benötigen Systeme intern. Die Spezifikation wird benötigt,

um Gelder für die Entwicklung beantragen zu können. Solch ein Dokument diente als

Grundlage für die User Stories. Dies sollte zwingend vom Product Owner als auch von

der Qualitätssicherung vor dem Meeting durchgearbeitet werden. So könnten beide in-

formiert in die Besprechung gehen und Fragen formulieren. Jede einzelne User Story

würde besprochen und die Akzeptanzkriterien dabei definiert werden. Entstehen nun Ab-

weichungen von der Dokumentation, ist die Qualitätssicherung direkt darüber informiert.

Zusätzlich sollte das interne Dokument weiter gepflegt werden, damit es nicht zu Miss-

verständnissen kommt, falls sich doch jemand an der Spezifikation orientiert. Aus der

Perspektive der Qualitätssicherung ist es jedoch nicht mehr notwendig, da die User Sto-

ries über eine geeignete Aussagekraft verfügen.

Die zweite große Besprechung ist das Sprint Planning Meeting. Hier werden die User

Stories vorgestellt, in Tasks unterteilt und der Aufwand geschätzt. Außerdem trifft die

externe Qualitätssicherung das erste Mal auf das ursprüngliche ScrumTeam. Da der Kun-

de die Einbeziehung der externen Qualitätssicherung gewünscht hat, sollte er auf jeden

Fall anwesend sein. Des Weiteren wird die Unterstützung des Managements der Entwick-

lung und des ScrumMaster benötigt, um die Gründe hinter der Einbeziehung der Quali-

tätssicherung klarzustellen. Hierbei ist darauf zu achten, diese als positive Ergänzung für

das Team hervorzuheben. Befürchtungen wegen vermuteter Nachteile für das Team soll-

ten ausgeräumt werden.

Vor dem Beginn des Sprints ist zudem das neue Vorgehen vorzustellen. Das Team ist in

Kanban und die benutzten Systeme einzuführen. Dies kann während des Sprint Plannings

oder in einem separaten Meeting geschehen. Sind noch viele offene Fragen zu klären, ist

ein separates Meeting vorzuziehen. So sollte das Team und insbesondere die Qualitätssi-

cherung ein Mitspracherecht bei den eingesetzten konstruktiven und analytischen Quali-

tätssicherungsmaßnahmen haben.

Ein grobes Konzept sollte jedoch schon im Voraus erstellt werden, um eine Diskussions-

grundlage zu bekommen.

Im Beispielprojekt sind bislang die kontinuierliche Integration sowie automatisierte Unit-

tests als agile Praktiken benutzt worden. Für kritische Bereiche ist es sinnvoll, zusätzlich

Pair Programming zu nutzen, um hier die Qualität gezielt zu erhöhen. Simple Design und

Refactoring erhöhen die Wartbarkeit der Software und sind deshalb


111

wünschenswert. Wichtig ist, dass sich die Entwickler diesen Praktiken verschreiben, da

sie keine Wirkung erzielen, wenn sie erzwungen werden.

Im Fallbeispiel haben die Entwickler bislang automatisierte Unit- und Integrationstests

durchgeführt. Die Aufgabe der Qualitätssicherung kann somit wie vorgesehen mit dem

Systemtest beginnen. Bei der zu entwickelnden Software handelt es sich um eine Web-

applikation. Die Automatisierung von Tests auf der Oberfläche lässt sich mit Werkzeugen

wie Watir oder Selenium gut durchführen. Um die Wiederholbarkeit der Tests zu gewähr-

leisten, sollten auch die Tests für die Oberfläche automatisiert werden. Seiteneffekte sind

auf diese Weise einfach auszuschließen.

Als Grundlage für die Testfallerstellung dienen die User Stories. Es liegt keine formale

oder technische Spezifikation vor, aus der die Testfälle abgeleitet werden können. Die

Tests sind daher mit funktionsorientierten Testtechniken zu erstellen und durchzuführen.

Diese können von einer einfachen Äquivalenzklassenbildung bis zu Entscheidungstabel-

len und -bäumen reichen. Da die Testfälle sowohl für einzelne, verschieden komplexe

User Stories, als auch übergreifend für das gesamte System zu erstellen sind, kann jeweils

die geeignete Testart ausgewählt werden. Der Einsatz dedizierter Tester ermöglicht durch

das vorhandene Wissen solch ein Vorgehen.

Neben den Qualitätssicherungsmaßnahmen ist die technische Unterstützung des Prozes-

ses zu planen. Hier muss ein Kanbanboard ausgewählt und der Umgang mit den bisheri-

gen Systemen geklärt werden. Die bisher eingesetzten Systeme sind Open-Source. Da

Anschaffungskosten nach Möglichkeit vermieden werden sollen, bis sich der Prozess

bewährt hat, ist auch weiterhin freie Software zu verwenden. Freie Kanbanboards verfü-

gen nicht über alle benötigten Funktionen. Während das Einfügen verschiedener Zeilen

noch möglich ist, bleibt die automatische Erfassung und Auswertung von Zeiten den kos-

tenpflichtigen Varianten vorbehalten. Das bisher verwendete Ticketsystem Trac [trac]

verfügt jedoch über diese Funktion und lässt einen Export der erfassten Daten zu. Es las-

sen sich Status gemäß den Spalten im Kanbansystem definieren. Wird eine Karte im

Kanbansystem verschoben, ist der Status des zugehörigen Tickets zu ändern, der Zeit-

punkt wird automatisch erfasst. Außerdem verfügt es über eine gute Änderungshistorie

und ein Wiki. Wird das Kanbansystem nur verwendet, um auf die User Stories und Ti-

ckets in einem gemeinsam verwendeten Trac-System zu verweisen, kann mit einer freien

Variante ausgekommen werden, ohne große Einschränkungen hinnehmen zu müssen.


112

An die Benutzung von Trac sind alle Projektbeteiligten bereits gewöhnt. Das Kanbantool

dient nur noch der Referenzierung auf die Tickets, der Visualisierung und der Begren-

zung des WIP. Um weiterhin die Testfälle zu verwalten, bietet sich fürs Erste die Weiter-

führung des Testmanagementsystems an. Auf lange Sicht ist es jedoch zu empfehlen, ein

kommerzielles Werkzeug zu nutzen, das alle Funktionalitäten vereint und Tickets direkt

mit ihren Testfällen verknüpft.

Für die Kommunikation mit dem Kunden nutzen bereits die Qualitätssicherung als auch

die Entwickler den Microsoft Office Communicator. Dieser bietet u.a. Funktionen für

(Video-)Telefonie, Instant Messaging und Dateiaustausch. Es ist jeder Zeit ersichtlich, ob

die Ansprechperson momentan am Platz ist und ob sie für ein Gespräch zur Verfügung

steht.

Als Werkzeug für die kontinuierliche Integration ist Subversion [SVN] in beiden Unter-

nehmen im Einsatz. Es kann zum Speichern des Quellcodes des Softwareprodukts und

der automatisierten Tests verwendet werden. Mittels eines Skripts lassen sich die Appli-

kationen erstellen und im Webserver bereitstellen. Das Skript kann sowohl von den Tes-

tern als auch von den Entwicklern aufgerufen werden. So ist sichergestellt, dass den Tes-

tern immer die neueste Version zur Verfügung steht.

Die technische Unterstützung des Entwicklungsprozesses kann somit mit kostengünstigen

Mitteln sichergestellt werden.

Für die langfristige Optimierung des Prozesses sind Kennzahlen und Metriken auszuwäh-

len. Auch der Auftraggeber ist an einer Auswertung interessiert, die den erhöhten Auf-

wand durch den Einsatz einer externen Qualitätssicherung rechtfertigt. Durch die erhobe-

nen Daten im Trac kann genau ermittelt werden, wie viele Kanbankarten zu welchem

Zeitpunkt im System waren. So können durchschnittliche Liegezeiten in den einzelnen

Spalten abgeleitet und Engpässe identifiziert werden. Anhand der Art der Tickets lässt

sich erkennen, wie die Kommunikation zwischen Qualitätssicherung und Entwicklung

verläuft. Handelt es sich um viele kleine Tickets, die auch auf informelle Weise schnell

behoben werden können, besteht kein direkter Kontakt. Entstehen Fehler durch unter-

schiedliche Interpretationen von User Stories, weist dies auf ein Problem mit der internen

Informationsverteilung hin. Die unterschiedlichsten Interpretationen der Daten sind mög-

lich und je nach Bedarf anzuwenden.

8.3 ZUSAMMENFASSUNG

113

Für den Auftraggeber sind Metriken wichtig, die die Wirksamkeit der Qualitätssicherung

belegen. So sollte erfasst werden, wie viele Fehler während der Tests auftreten. Auch

über informelle Wege weitergegebene Fehler zählen dazu. Zudem sollten die Fehler in

verschiedene Kategorien eingeteilt werden, um zu bewerten, ob diese im Produktivsystem

zum Problem geworden wären. Sind nur wenige Fehler im System identifiziert worden,

scheint der Auftragnehmer für die Entwicklung ausreichende Qualität abzuliefern und die

Einbindung der externen Qualitätssicherung kann in Frage gestellt werden. Befinden sich

jedoch sehr viele Fehler im System, ist bei den Entwicklern zu eskalieren und für eine

stärkere konstruktive Qualitätssicherung zu sorgen. Die Maßnahmen der analytischen

Qualitätssicherung sind gegebenenfalls noch zu erhöhen, um bei Mängeln der Entwick-

lung konsequent gegensteuern zu können.

Da sich alle Bedingungen für den Entwicklungsprozess erfüllen lassen, kann er wie be-

schrieben eingeführt werden. Dies gibt jedoch keine Garantie, dass der Prozess von allen

Beteiligten angenommen wird. Hier ist besonders der ScrumMaster gefragt, die Entwick-

ler und Tester im Auge zu behalten und notfalls einzugreifen. Durch die Transparenz des

Kanbanboards können Probleme im Prozess frühzeitig von ihm erkannt werden.

Zum Ende eines jeden Sprints sollte nach Einführung der hier beschriebenen Maßnahmen

eine lauffähige Software zur Verfügung stehen. Der Auftraggeber kann nach jedem Sprint

einen Testbericht verlangen und auf Anraten der Qualitätssicherung darüber entscheiden,

ob die momentane Version in eine Produktivumgebung übergeführt werden kann. Alter-

nativ können auch nach mehreren Sprints Releasesprints durchgeführt werden, damit

nicht so häufig Testberichte anfallen und sich das Team in den übrigen Sprints mehr auf

die Entwicklung konzentrieren kann.

Für die Sprint-Retrospektive ist die Anwesenheit der Qualitätssicherung wieder erforder-

lich. Alle Projektbeteiligten entscheiden zusammen über das weitere Vorgehen. Da sich

die Entwickler und die Tester das erste Mal seit dem Sprint Planning wieder begegnen,

können sie gemeinsam über den vergangenen Sprint reflektieren.

8.3 ZUSAMMENFASSUNG

Die Probleme, die eine mangelhaft integrierte externe Qualitätssicherung in einem agilen

Softwareentwicklungsprozess mit sich bringt, wurden anhand eines Fallbeispiels


114

beschrieben. So stieg der Arbeitsaufwand stark an und auf Grund langer Test- und Feh-

lerbehebungsdauern konnten keine Zwischenprodukte ausgeliefert werden. Die Sprintzie-

le wurden nicht erreicht, die Entwicklung nur mit Mühe abgeschlossen.

Durch geeignete Maßnahmen wurde anschaulich gezeigt, auf welche Weise die Rahmen-

bedingungen für den Entwicklungsprozess geschaffen werden können, so dass eine Ein-

führung des ausgearbeiteten Entwicklungsprozesses möglich ist. Die verwendeten Syste-

me sind hauptsächlich Open-Source und frei verfügbar.

Es wurde dargestellt, dass ohne erheblichen Mehraufwand der hier umgestaltete Entwick-

lungsprozess effizient und lauffähig in die Praxis umgesetzt werden kann.

115

9 SCHLUSSBETRACHTUNGEN

9.1 ZUSAMMENFASSUNG

Als Zielsetzung der vorliegenden Master Thesis wurde die Schaffung eines unterneh-

mensübergreifenden agilen Softwareentwicklungsprozesses für unternehmenskritische

Systeme zur Einbindung externer Qualitätssicherung gesetzt.

Das Thema ist systematisch erschlossen worden. Es wurde in die Theorie eingeführt, um

die Grundlagen für die Entwicklung des Prozesses zu schaffen. Aufbauend auf den

Grundlagen sind die benötigten Aspekte herausgearbeitet worden. Abschließend wurde

der Prozess samt Randbedingungen erstellt und an einem Fallbeispiel angewandt.

Konventionelle und agile Vorgehensmodelle wurden betrachtet. Die Unterschiede zwi-

schen den beiden Modellen sowie deren Einsatzschwerpunkte wurden dargestellt. Als

agiles Referenzmodel ist Scrum aufgrund seiner geringen Einschränkungen gut geeignet.

Das Team verwaltet sich innerhalb eines Managementrahmens selbst, es bestehen noch

keine Vorgaben, die die Einbindung einer externen Qualitätssicherung verhindern kön-

nen. Die Vorgehensweise von Scrum ist erklärt und seine Eigenheiten sind dargestellt

worden.

Um die Qualität langfristig zu erhöhen, wurde die Einführung von Qualitätsmanagement

in agile Vorgehensmodelle betrachtet. Dazu wurden die beiden unterschiedlichen Quali-

tätsmanagementansätze, modellbasiertes und kontinuierliches Qualitätsmanagement, be-

trachtet. Bezüglich ihrer Eignung zum Einsatz mit agiler Softwareentwicklung ist ein

höheres Potential bei den kontinuierlichen Methoden ausgemacht worden. Während mo-

dellbasierte Ansätze die Selbstverwaltung des Teams einschränken, ist für kontinuierliche

Ansätze durch die kurzen Iterationen und die Sprint Retrospective bereits ein Grundstein

gelegt.

Neben den prozessorientierten Maßnahmen des Qualitätsmanagements liegt in der Soft-

wareentwicklung ein Schwerpunkt auf der produktorientierten Software-

Qualitätssicherung. Hier wurden die vier Teststufen Unittest, Integrationstests, System-

test und Akzeptanztest des V-Modells im deutschsprachigen Raum identifiziert. Sie ha-

ben sich bei der Erstellung qualitativ hochwertiger Software bewährt. Da in der agilen

KAPITEL 9: SCHLUSSBETRACHTUNGEN

116

Softwareentwicklung ein phasenweises Vorgehen nicht vorgesehen ist und mehrere Prob-

leme mit sich bringt, wurde sich dafür entschieden das V-Modell in abgewandelter Form

für jede User Story einzeln zu durchlaufen. Zusätzlich wurden weitere Eigenheiten der

Qualitätssicherung in agilen Prozessen dargestellt. Dies sind unter anderem eine hohe

Testautomatisierung und die enge Zusammenarbeit zwischen Testern und Entwicklern.

Nach der Präsentation der Grundlagen sowie der Auswahl des Referenzmodells, des Qua-

litätsmanagementansatzes und des Vorgehens bei der Qualitätssicherung wurde der Ent-

wicklungsprozess entwickelt.

Der erste Schritt war die Verteilung der Aufgabenbereiche auf die beteiligten Unterneh-

men. Die Rollen von Scrum vorgegebenen Rollen behielten ihre grundsätzlichen Aufga-

bengebiete. Das ScrumTeam ist um die externe Qualitätssicherung erweitert worden. Die

Entwickler führen Unit- und Integrationstest durch. Die Verantwortung für die System-

und Akzeptanztest liegt bei der externen Qualitätssicherung. Der ScrumMaster stellt die

Schnittstelle zwischen den beiden Unternehmen dar und muss alle Hindernisse beseitigen,

die der Zusammenarbeit hinderlich sind. Der ProductOwner wird von der externen Quali-

tätssicherung bei der Aufnahme der Anforderungen unterstützt. Um das Zusammenspiel

der Entwicklung und Qualitätssicherung zu optimieren, müssen beide Seiten über densel-

ben Informationsstand verfügen. Hierfür wurde die User Story als zentrale Informations-

quelle beschrieben, die um alle wichtigen Informationen erweitert wird. Des Weiteren hat

der Abschluss einer User Story höchste Priorität, so dass die gefundenen Fehler auf dem

kürzesten Weg an die Entwickler gemeldet und möglichst schnell behoben werden müs-

sen.

Nach der Aufteilung der einzelnen Aufgaben ist die konkrete Umsetzung von Qualitäts-

managementmaßnahmen im Entwicklungsprozess betrachtet worden.

Um den Fluss zwischen den Unternehmen zu optimieren, wurde Kanban als Methodik

eingeführt.

Kanban fügt sich gut in den Rahmen von Scrum ein, reguliert den Durchfluss, liefert

Kennzahlen und sorgt für eine hohe Transparenz. Durch die Begrenzung der einzelnen

Aufgaben im System werden Tester und Entwickler zur Zusammenarbeit gezwungen.

Darüber hinaus wurden die Möglichkeiten zur technischen Unterstützung des Entwick-

lungsprozesses betrachtet, um die Zusammenarbeit und Kommunikation der Entwickler

9.1 ZUSAMMENFASSUNG

117

über größere Entfernung hinweg zu verbessern. Es wurden mehrere Werkzeuge

identifiziert. Besonders Instant Messaging hat ich durch die Erzeugung eines Gefühls der

Präsenz und Aufmerksamkeit in beiden Unternehmen hervorgetan. Das Kanbanboard

sollte soweit wie möglich alle Kennzahlen, die von den Kanbankarten ausgehen, erfassen

können, um die Entwickler nicht mit zusätzlichen Aufgaben zu belasten.

Der Ablauf von Scrum wird durch die hinzugefügten Maßnahmen und Werkzeuge nicht

verändert. Die Selbstverwaltung des Teams bleibt weitestgehend erhalten.

Aus den herausgearbeiteten Aspekten ist ein Entwicklungsprozess erstellt worden. Dieser

wurde mit BPMN modelliert. Die Dokumentation des Prozesses dient sowohl als Grund-

lage für die weitere Optimierung als auch zur Referenz für alle Projektbeteiligten.

Bei den Besprechungen zur Vorbereitung des Sprints sind können Änderungen hinzuge-

kommen, lediglich die Rolle der externen Qualitätssicherung wurde mit ihren Aktivitäten

hinzugefügt.

Im Sprint ist der Prozess darauf ausgelegt worden, eine möglichst schnelle Durchlaufzeit

der User Stories zu ermöglichen. Die Vorbereitung der Tests und die Entwicklung laufen

parallel ab. Der Product Owner begutachtet die Software direkt nach Implementierung,

um das Testen von falsch interpretierten User Stories zu vermeiden. Vom Product Owner

oder der Qualitätssicherung gefundene Fehler werden entweder im direkten Kontakt mit

den Entwicklern gelöst oder über das Kanbanboard an diese übergeben. Auf dem Kan-

banboard bekommen Fehler die höchste Priorität, müssen folglich behoben werden, bevor

eine neue Aufgabe begonnen werden darf. So wird sichergestellt, dass keine User Stories

im System hängen bleiben.

Der Einsatz einer unabhängigen Software-Qualitätssicherung, zusammen mit konstrukti-

ven Qualitätssicherungsmaßnahmen und den Praktiken der agilen Softwareentwicklung

sowie der Beschränkung auf wenige Aufgaben zurzeit sorgten für eine hohe Qualität in

der Software.

Um die Qualität langfristig verbessern zu können, werden über das Kanbansystem Kenn-

zahlen erhoben sowie Metriken benutzt. Diese Daten sind in der Sprint Retrospective mit

allen Projektbeteiligten zu besprechen und Verbesserungsmaßnahmen abzuleiten.

Neben dem optimalen Prozess wurden Ausnahmen betrachtet, die vom Prozessablauf

abweichen. Der Umgang mit diesen Situationen wurde beschrieben.


118

Abschließend wurde die Anwendung des Entwicklungsprozess beispielhaft für ein reales

Projekt beschrieben.

9.2 FAZIT

Um externe Qualitätssicherung in einen agilen Softwareentwicklungsprozess einzuführen,

wurden verschiedene Teilgebiete betrachtet. Während Vorgehensmodelle und die Soft-

ware-Qualitätssicherung aus dem Gebiet der Softwaretechnik als einem Teilgebiet der

Informatik stammen, sind Qualitätsmanagement und Prozessmanagement Teilgebiet der

Betriebswirtschaftlehre.

Die Verknüpfung der verschiedenen Gebiete führt zu einer Lösung, die Rücksicht auf

gängige Praktiken aus der Softwaretechnik nimmt, sie auf agile Modelle abbildet und eine

langfristige Optimierung ermöglicht.

Das Ziel der Arbeit, einen unternehmensübergreifenden agilen Softwareentwicklungspro-

zess für unternehmenskritische Systeme zur Einbindung externer Qualitätssicherung zu

schaffen, wurde erreicht.

Mehrere Herausforderungen waren zu überwinden.

Während die konventionellen Entwicklungsmodelle gut dokumentiert und auch im aka-

demischen Umfeld genauer betrachtet worden sind, weisen die agilen Modelle noch Lü-

cken auf. Die Literatur ist oft sehr einseitig und mit wenig wissenschaftlichem Hinter-

grund verfasst. So gibt es kein allgemeingültiges Vorgehen, das die Rolle der Qualitätssi-

cherung in der agilen Softwareentwicklung beschreibt. Alles was über die idealen Um-

stände, in denen ein agiles Projekt stattfinden kann, hinaus geht (u.a. hochspezialisierte

Entwickler, Kunde vor Ort und die Möglichkeit für automatisierbare Regressionstest)

wird nicht betrachtet. Dies ist sehr schade, da es eine ernsthafte Auseinandersetzung mit

der agilen Softwareentwicklung erschwert. Trotzdem existieren interessante Ansätze mit

ausreichend fundiertem Hintergrund, aus denen sich viele Anregungen für den Entwick-

lungsprozess entnehmen ließen.

Ähnlich sah es mit der Einbindung von Qualitätsmanagementelementen in die agile

Softwareentwicklung aus. Zum einen sind die Qualitätsmanagementansätze mit der Zeit

sehr umfangreich geworden, so dass sie auf kleine Projekte nicht anwendbar sind. Zum

anderen gibt es immer noch wenig Bemühungen, agile Softwareentwicklung in

9.3 AUSBLICK

119

Qualitätsmanagementsysteme zu integrieren. Folglich musste ein leichtgewichtiger

Ansatz gefunden werden. Dies ist mit Kanban und einer Fixierung auf User Stories

gelungen.

Deutlich wurde, dass nur sehr wenige Autoren sich sowohl mit agilen als auch konven-

tionellen Modellen auseinandergesetzt haben, um einen Vorteil aus der Kombination bei-

der zu erhalten.

In gleichem Maße waren soziale und technische Aspekte zu beachten, die in dem neu zu

beschreibenden Prozess untergebracht werden mussten.

Es ist gelungen, einen Entwicklungsprozess zu erstellen, der allen Anforderungen gerecht

geworden ist und sich für den praktischen Einsatz eignet.

Die zusammengefasste Problematik verdeutlicht, wie wichtig die Auseinandersetzung mit

dem Thema war. Obwohl der Softwareentwicklungsprozess von enormer Wichtigkeit für

die Erstellung von Software ist, findet er in Forschung und Lehre noch sehr wenig Ank-

lang. Die am Anfang zitierte Aussage von Kenneth W. Kolence wird noch für einige Zeit

Bestand haben.

Mit der Einbindung externer Qualitätssicherung in die agile Softwareentwicklung ist ein

kleines Gebiet der Softwaretechnik beleuchtet worden, das uns dem Verständnis von

Softwareentwicklungsprozessen zumindest einen kleinen Schritt näher gebracht hat.

9.3 AUSBLICK

Der beschriebene Entwicklungsprozess ist allgemein gehalten. Die Betrachtung unter

spezielleren Randbedingungen kann für weitere Erkenntnisse sorgen. So ist die Skalie-

rung auf mehrere Projektteams möglich, um größere, komplexere Projekte abzuschließen.

Hierbei können mehrere ScrumTeams eine zentrale Qualitätssicherung beliefern, um

nicht in jedem Team Tester vorhalten zu müssen. Des Weiteren haben neben anderen

Aspekten auch steigende oder fallende Qualitätsanforderungen, eingesetzte Technologien

und Sprintlängen Einfluss auf den Prozess. Er muss für die im Projekt vorgefundenen

Bedarfe jeweils angepasst werden.

Es reicht folglich nicht aus nur, den Prozess zu verwenden, sondern es muss sich näher

mit der Thematik auseinander gesetzt werden, um zu bestimmen, wie unter bestimmten


120

Umständen zu verfahren ist. Eine nähere Betrachtung unter weiteren Randbedingungen

stellt eine interessante Ergänzung zur Arbeit dar.

Momentan nutzt der Prozess sowohl Scrum als auch Lean Software Development. Die

zukünftige Entwicklung von Lean Software Development oder die Verbesserung der

Kommunikationswerkzeuge könnte dazu führen, dass nur eines der beiden Modelle ver-

wendet werden muss.

Eine nähere Betrachtung von Lean Software Development kann Erkenntnisse hervorbrin-

gen, die Scrum obsolet erscheinen lassen. Lean Development ist eine vergleichsweise

junge Disziplin mit viel Potential. Mit Kanban ist erst kürzlich ein mächtiges Werkzeug

entstanden. In Zukunft dürfte in diesem Bereich noch einiges zu erwarten sein, mit dem

das Managementmodell von Scrum ausgetauscht werden könnte.

Andererseits wird das Einbinden von entfernten Standorten mit zunehmender Technolo-

gisierung zusehends einfacher. Telefonkonferenzen über VoiP ist heutzutage an der Ta-

gesordnung, Videokonferenzen die Regel. Mit einer dauerhaften audiovisuellen Verbin-

dung kann es in Zukunft möglich sein, den Eindruck eines Teams an zwei Standorten zu

vermitteln. Dies würde den Einsatz von purem Scrum ermöglichen und einen aufwendi-

gen Prozess überflüssig machen. Eine informelle und enge Zusammenarbeit der Teams

wäre ohne die Unterstützung durch Kanban möglich. Ein tieferer Einblick in die Medien-

nutzung sowie ihre zukünftigen Potentiale kann die Einbindung einer externen Qualitäts-

sicherung weiter verbessern.

Agile und konventionelle Softwareentwicklung haben viele Unterschiede, jedoch beide

ihre Daseinsberechtigung. Die Vertreter beider Richtungen beharren noch sehr auf ihrer

Art der Softwareentwicklung. Es ist schade, dass sich so wenig damit beschäftigt wird,

die Vorteile beider Modelle in einem Vorgehen unterzubringen. Während agile Modelle

mit ihren kurzen Iterationen für einen frühen Kundennutzen sowie eine hohe Flexibilität

sorgen, haben konventionelle Modelle einen gut strukturierten Ablauf, der mit seiner um-

fangreichen Dokumentation eine umfassende Qualitätssicherung ermöglicht. Sollte ein

Modell entstehen, das ein wenig von beidem aufgreift und so die Vorteile vereint, wären

wir dem Verständnis eines guten Softwareentwicklungsprozesses ein Stück näher ge-

kommen.

QUELLENVERZEICHNIS

VI

LITERATUR

[And04]

Anderson, David J. (2004) Agile management for software engineering. 1. Aufl., New Jersey,

Pearson Education

[And11]

Anderson, David J. (2011) Kanban Evolutionäres Change Management für IT-Organisa-

tionen. (1. Aufl.) Heidelberg, dpunkt-Verlag (orig.: Kanban: Successful Evolutionary Change

Management, 2010, Blue Hole Press, Sequim WA)

[Bal08]

Balzert, Helmut. (2008). Lehrbuch der Softwaretechnik: Softwaremanagement. 2. Aufl., Hei-

delberg, Spektrum Akademischer Verlag.

[Bec99]

Beck, Kent. (1999) Extreme Programming Explained: Embrace Change. 1. Aufl., Amster-

dam, Addison-Wesley Longman

[Ben56]

Benington, Herbert D. (1956) Production of Large Computer Systems. in: Symposium on

Advanced Programming Methods for Digital Computers, Washington

[Boe81]

Boehm, Barry W. (1981) Software Engineering Economics, Enlglewood Cliffs, Prentice Hall

[Boe88]

Boehm, Barry W. (1988) A Spiral Model of Software Development and Enhancement. In:

IEEE Compunter, May 1988

[Bro82]

Broh, R.A. (1982) Managing Quality for Higher Profits: A Guide for Business Executives and

Quality Managers. McGraw Hill Higher Education

QUELLENVERZEICHNIS

VII

[BT08]

Boehm, B., Turner, R. (2008) Balancing Agility and Discipline A Guide for the Perplexed. 1.

Aufl. Boston MA, Addison-Weasley

[BW08]

Brunner, F., Wagner, K. W. (2008) Taschenbuch Qualitätsmanagement Leitfaden für Studium

und Praxis. 2. Aufl., München, Hanser Verlag

[CG09]

Crispin, L., Gregory, J. (2009) Agile Testing A Practical Guide for Testers and Agile Teams.

1. Aufl., Boston, Pearson Education

[Coc02]

Cockburn, Alistair (2002) Agile Software Development. 2. Aufl., Boston, Addison-Wesley

[Dij72]

Dijkstra, Edsger W.(1972) The humble programmer. In: Communications of the ACM 15

[Eck04]

Eckstein, Jutta (2004) Agile Softwareentwicklung im Großen.1. Aufl., Heidelberg, dpunkt-

Verlag

[Eck09]

Eckstein, Jutta (2009) Agile Softwareentwicklung mit verteilten Teams. 1. Aufl., Heidelberg,

dpunkt-Verlag

[Epp11]

Epping, Thomas (2011) Kanban für die Softwareentwicklung. 1. Aufl., Heidelberg, Springer-

Verlag

[FB08]

Feldbrügge, R., Brecht-Hadrashek, B. (2008) Prozessmanagement leicht gemacht Geschäfts-

prozesse analysieren und gestalten. (2. Aufl.) München, Redline Wirtschaft, Finanzbuch Ver-

lag GmbH

[FR12]

Freund, J., Rücker, B. (2012) Praxishandbuch BPMN 2.0. 3. Aufl. München, Hanser Verlag

QUELLENVERZEICHNIS

VIII

[Gad10]

Gadatsch, Andreas (2010) Grundkurs für Geschäftsprozess-Management Methoden und

Werkzeuge für die IT-Praxis: Einführung für Studenten und Praktiker. 6. Aufl. Wiesbaden,

Vieweg+Teubner

[Han10]

Hanser, Eckhard (2010) Agile Prozesse: Von XP über Scrum bis MA. 1. Aufl. Berlin Heidel-

berg, Springer-Verlag

[HR01]

Herring, R., Rees, M., Internet-based Collaborative Software Development Using Microsoft

Tools. in Proceedings of the 5th World Multiconference on Systemics, Cybernetics and In-

formatics (SCI'2001). 22-25 July, 2001. Orlando, Florida, online unter

http://www.charlesherring.com/SoftwareEngineering0verInternet-SCI2001.pdf (abgerufen am

09.08.2012)

[HH08]

Höhn, R., Höppner, S. (2008) Das V-Modell XT Anwendungen, Werkzeuge, Standards . 1.

Aufl. Berlin Heidelberg: Springer-Verlag

[Hof08]

Hoffmann, Dirk W. (2008) Software Qualität. 1. Aufl., München Heidelberg: Springer.

[HRS09]

Ηruschka, P., Rupp, C., Starke, G. (2009) Agility kompakt Tipps für erfolgreiche Systement-

wicklung .Heidelberg, Spektrum Akademischer Verlag

[Koc11]

Koch, Susanne (2011) Einführung in das Management von Geschäftsprozessen. 1. Aufl. Hei-

delberg, Springer

[KS10]

Kniberg, H., Skarin, M. (2010) Kanban and Scrum – making the most of both. o.O, C4Media

INC. (erhältlich unter http://www.infoq.com/minibooks/kanban-scrum-minibook, Zugriff am:

12.07.2012)

QUELLENVERZEICHNIS

IX

[Lar04]

Larman, Craig (2004) The historical accident of waterfall validity?. In: Agile & Iterative De-

velopment, Amsterdam, Addison-Wesley Longman

[Lig09]

Liggesmeyer, Peter. (2009). Software-Qualität: Testen, Analysieren und Verifizieren von

Software. 2. Aufl., Heidelberg: Spektrum Akademischer Verlag.

[Lit07]

Litke, Hans-D. (2007) Projektmanagement Methoden, Techniken, Verhaltensweisen.(5. Aufl.)

München, Hanser Verlag

[NWB00]

Nardi, B., Whittaker, S., Bradner, E., Interaction and Outeraction: Instant Messaging in Ac-

tion. in Proceedings of the 2000 ACM conference on Computer supported cooperative work.

Online unter http://www.interruptions.net/literature/Nardi-CSCW00-p79-nardi.pdf (abgerufen

am 10.08.2012)

[NR68]

Naur P., Randell B. (1968) Software Engineering: Report of a conference sponsored by the

NATO Science Committee. Garmisch, NATO Scientific Affairs Division

[OW08]

Oestereich, B., Weiss, C. (2008) APM - Agiles Projektmanagement, erfolgreiches Timeboxing

für IT-Projekte. 1. Aufl., Heidelberg, dpunkt-Verlag

[Pet01]

Petrasch, Roland (2001) Einführung in das Software-Qualitätsmanagement. 1. Aufl., Berlin,

Logos-Verlag

[Pic08]

Pichler, Roman (2008) Scrum Agiles Projektmanagement erfolgreich einsetzen. 1. Aufl., Hei-

delberg, dpunkt-Verlag

[Pop01]

Poppendieck, Mary (Mai/Juni 2001) Lean programming, Software Development Magazine

QUELLENVERZEICHNIS

X

[SN11]

Slama, D., Nelius, R. (2011) Enterprise BPM Erfolgsrezepte für unternehmensweites Pro-

zessmanagement. 1. Aufl., Heidelberg, dpunkt-Verlag

[SL10]

Spillner, A., Linz, T. Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester.

4. Aufl., Heidelberg, dpunkt-Verlag

[Roy70]

Royce, Winston W. (1970) Managing the development of large software systems. in: WES-

CON, August 1970, pages 1-9.

[TN86]

Takeuchi, H., Nonaka, I. (1986) The new product development game. Havard Business Re-

view, January-February

[Wal11]

Wallmüller, Ernest (2011) Software Quality Engineering. 3. Aufl. München, Hanser Verlag

[WK08]

Wagner, K. W., Käfer, R. (2008) PQM Prozessorientiertes Qualitätsmanagement – Leitfaden

zur Umsetzung der neuen ISO 9001: Rollen im prozessorientierten Qualitätsmanagement. 4.

Aufl., München, Hanser Verlag

[Wir09]

Wirdemann, Ralf (2009) Scrum mit User Stories.1. Aufl., München, Hanser Verlag

QUELLENVERZEICHNIS

XI

SONSTIGE QUELLEN UND VERWEISE

[agile_manifesto]

Agiles Manifest abgerufen am 30.06.2012 von http://agilemanifesto.org/

[agile_principle]

Agile Prinzipien abgerufen am 01.08.2012 http://agilemanifesto.org/iso/de/principles.html

[BPMN]

Standard der Business Process Model and Notation 2.0 abgerufen am 20.08.2012 von

http://www.omg.org/spec/BPMN/2.0/

[CMMI]

Dokumentation des CMMI for Development 1.3 abgerufen am 18.07.2012 von

http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm

[CMMI_Agile]

CMMI or Agile: Why not Embrace Both! abgerufen am 02.07.2012 von

http://www.sei.cmu.edu/reports/08tn003.pdf

[HP Quality Center]

http://www8.hp.com/us/en/software-solutions/software.html?compURI=1172141

[IBM Rational Synergy]

http://www-01.ibm.com/software/awdtools/synergy/

[IEE829]

http://de.wikipedia.org/w/index.php?title=Datei:IEEE829_Uebersicht_Deutsch.png&filetimes

tamp=20081014091319 abgerufen am 31.07.2012

[JUnit]

http://www.junit.org/

[Kanbancard]

The Kanban Story: Moving Cards Back abgerufen am 11.08.2012 von

http://blog.brodzinski.com/2010/10/kanban-moving-cards-back.html

QUELLENVERZEICHNIS

XII

[Kanbanboard]

Bild eines Kanbanbaords abgerufen am 12.08.2012 http://blog.brodzinski.com/wp-

content/uploads/2010/02/kanban-5.png

[lean_rework]

Accounting for bugs and rework abgerufen am 15.08.2012 von

http://leansoftwareengineering.com/2007/11/25/accounting-for-bugs-and-rework/

[mantis]

http://www.mantisbt.org/

[bugzilla]

http://www.bugzilla.org/

[pmdoi]

Declaration of Interdependence abgerufen am 30.06.2012 von http://pmdoi.org/

[ScrumBan]

Scrum-ban abgerufen am 16.08.2012 von http://leansoftwareengineering.com/ksse/scrum-

ban/

[Selenium]

http://seleniumhq.org/

[smartq]

http://www.getsmartq.com/

[standish]

Standish Chaos Report abgerufen am 20.06.2012 von

http://www.portal.state.pa.us/portal/server.pt/document/standish_group_chaos_summary_200

9_pdf

[SVN]

http://subversion.apache.org/

QUELLENVERZEICHNIS

XIII

[SQS Market Research 2011]

Wachstumsmarkt Software-Testing Markttrends, Dienstleister und Erfolgsfaktoren abgerufen

am 10.07.2012 http://www.sqs.com/de/group/das-unternehmen/market-research-studie-

2011.php

[trac]

http://trac.edgewall.org/

[Watir]

http://watir.com/

[WIKI]

What is Wiki abgerufen am 17.08.2012 von http://www.wiki.org/wiki.cgi?WhatIsWiki

[richhewlett]

Physical vs Virtual Kanban Boards abgerufen am 28.08.2012 von

http://richhewlett.com/2012/03/02/physical-vs-virtual-kanban-boards/

GLOSSAR

XIV

GLOSSAR

Amplify Learning: Amplify Learning ist einer der sieben Grundsätze von Lean Software

Development. Er besagt, dass die Software in kleinen Inkrementen entwickelt wird. Fertige

Artefakte werden ständig im Team und mit dem Kunden geteilt. Durch ständiges Feedback

soll voneinander gelernt werden. So lernen z.B. die Entwickler die Anforderungen an das Pro-

jekt im Laufe der Entwicklung näher kennen, anstatt diese zuvor im Detail zu spezifizieren.

Bugfixes: Als Bugfix wird die Beseitigung einer Fehlerquelle im Quellcode bezeichnet.

Computer Aided Software Engineering: Unter Computer Aided Software Engineering wird

die technische Unterstützung der Softwareentwicklung bezeichnet. Sie unterstützt bei der Pla-

nung, dem Entwurf und der Dokumentation.

Deming-Zyklus: siehe PDCA-Zyklus

Eliminate Waste: Eliminate Waste ist eine der sieben Grundsätze von Lean Software Deve-

lopment. Er besagt, dass alles was kein Mehrwert für den Kunden liefert, als Verschwendung

angesehen werden kann. Diese Verschwendung ist zu eliminieren.

Feature Driven Development: Feature Driven Development ist eine iterative und inkremen-

telle Softwareentwicklungsmethodik. Sie vereint mehrere Best-Practices miteinander. Dabei

werden die Praktiken durch Funktionalitäten mit Kundennutzen gesteuert, die Feature.

Lean: Siehe Lean Manufacturing

Lean Manufacturing: Lean Manufacturing ist eine Produktionsmethode, die sich die Redu-

zierung von Ressourcen um jeden Preis als Ziel gesetzt hat. Der Einsatz von Ressourcen für

jede Aktivität, die keinen Kundennutzen erzielt, wird als Verschwendung angesehen. Flussop-

timierung hat hohe Priorität.

Lean software development: Lean software development ist die Übertragung der Prinzipien

und Praktiken des lean manufacturing auf die Softwareentwicklung. Sie basiert auf sieben

Kernpraktiken ähnlich den Prinzipien des lean manufacturing.

Maturity Models: siehe Reifegrade

PDCA-Zyklus: Der PDCA-Zyklus ist eine iterative, vierstufige Managementmethode. Die

Aktivtäten Planen (Plan), Umsetzen (Do), Überprüfen (Check) und Verbessern (act) werden

aufeinanderfolgenden durchlaufen.

GLOSSAR

XV

Prozessmodell: Ein Prozessmodell ist die Beschreibung eines oder mehrerer Prozesse auf

gleicher Ebene. Dies geschieht meist über eine grafische Darstellung.

Reifegrade: Reifegrade sind verschiedene Ebenen in einem Modell, die beschreiben in wie

weit die Praktiken und Prozesse einer Organisation verlässliche und gleichbleibende Ergeb-

nisse liefern können.

Return on Investment: Return on Investment ist eine Metrik, die den Gewinn im Verhältnis

zum eingesetzten Kapital beschreibt.

Six Sigma: Six Sigma versucht die Qualität der Prozessergebnisse durch das Entfernen von

Fehlerquellen und der Minimierung von Schwankungen zu verbessern. Dabei werden mehrere

Qualitätsmanagementmethoden angewandt, darunter auch statistische.

Test-First-Ansatz: Die Tests werden vor der Implementierung einer Methode geschrieben.

Die Methode wird danach implementiert und so lange verfeinert, bis alle Tests bestanden

sind.

Ticketsystem: Ein Ticketsystem ist eine Applikation die eine Liste von Aufgaben führt. Ein

Ticket beinhaltet die Aufgabe sowie zusätzliche Informationen die für seine Erledigung benö-

tigt werden. Tickets können innerhalb des Systems von den Benutzern verwaltet werden.

Timeboxed: Der Begriff timeboxed bezeichnet, dass für eine bestimmte Aktivität ein festge-

legter Zeitrahmen existiert.

Total Quality Management: Total Quality Management ist eine Management Philosophie

zur ständigen Verbesserung von Produkt- und Prozessqualität. Sie bezieht das komplette Un-

ternehmen mit ein. So sind auch die Mitarbeiter, Zulieferer und Kunden an der Erreichung der

Qualitätsanforderungen beteiligt.

Work in Progress: Als Work in Progress wird in Kanban die Anzahl an Karten bezeichnet,

die sich zu einem bestimmten Zeitpunkt im System befinden.

ANHANGSVERZEICHNIS

1

ANHANG

Anhang 1: Beispiel für Kanban ......................................................................... 2

Anhang 2: CD-ROM ........................................................................................... 4

ANHANG

2

ANHANG 1: BEISPIEL FÜR KANBAN

ANHANG 1: BEISPIEL FÜR KANBAN

3

Abbildung A.1: Beispielhafte Darstellung von Kanban entnommen aus

http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000

ANHANG

4

ANHANG 2: CD-ROM

Im Buchrücken befindet sich eine CD-Rom. Die CD-Rom enthält:

• Die vorliegende Master-Thesis im PDF Format.

• Material aus nicht gedruckten Quellen.

• Die BPMN-Diagramme des Entwicklungsprozesses.

EIDESSTATTLICHE ERKLÄRUNG

5

Eidesstattliche Erklärung

Hiermit erkläre ich Sebastian Meier, geb. 17.02.1987, dass ich die vorliegende Master-Thesis

zum Thema:

Aspekte eines unternehmensübergreifenden agilen Softwareentwicklungsprozesses für

unternehmenskritische Systeme zur Einbindung externer Qualitätssicherung

selbstständig und ohne fremde Hilfe angefertigt und nur die angegebenen Quellen und Hilfs-

mittel benutzt habe.

Wismar, 12.08.2010 Sebastian Meier

Master-Thesis - Hochschule Wismarcleve/vorl/projects/da/12-Ma-MeierSebastian.pdf · A. BSTRACT. A....

Documents

Transcript of Master-Thesis - Hochschule Wismarcleve/vorl/projects/da/12-Ma-MeierSebastian.pdf · A. BSTRACT. A....