Entwicklung eines Vorgehensmodells für die Imagefilmproduktion auf der Basis agiler Vorgehensmodelle und Techniken in der Softwareentwicklung

Transkript

1 Entwicklung eines Vorgehensmodells für die Imagefilmproduktion auf der Basis agiler Vorgehensmodelle und Techniken in der Softwareentwicklung BACHELORARBEIT ausgearbeitet von Kai Mario Wittmann zur Erlangung des akademischen Grades BACHELOR OF SCIENCE (B.SC.) vorgelegt an der FACHHOCHSCHULE KÖLN CAMPUS GUMMERSBACH FAKULTÄT FÜR INFORMATIK UND INGENIEURWISSENSCHAFTEN im Studiengang MEDIENINFORMATIK Erster Prüfer: Zweiter Prüfer: Prof. Hans Kornacher Fachhochschule Köln Prof. Dr. Mario Winter Fachhochschule Köln Gummersbach, im August 2015

2 Adressen: Kai Mario Wittmann Löhestraße 17a Gummersbach Prof. Hans Kornacher Fachhochschule Köln Institut für Informatik Steinmüllerallee Gummersbach kornacher@gm.fh-koeln.de Prof. Dr. Mario Winter Fachhochschule Köln Institut für Informatik Steinmüllerallee Gummersbach mario.winter@fh-koeln.de

3 3 Kurzfassung Die Produktion von Imagefilme stellt die Beteiligten vor einige Herausforderungen: Es muss eine effiziente Kommunikation mit dem Kunden entwickelt werden, der nicht die Fachsprache der Filmproduktion spricht, außerdem müssen Anforderungen an den Imagefilm identifiziert und verwaltet werden. In dieser Arbeit wird ein Vorgehensmodell entwickelt, welches auf den Grundlagen der agilen Vorgehensmodelle der Informatik basiert. Ansatz ist hier, die bereits in der Softwareentwicklung bekannten Probleme mit den dort etablierten Techniken und Methoden zu lösen. Dabei werden auch Anforderungen an ein Vorgehensmodell für Imagefilmproduktion ermittelt. Ziel der Arbeit ist die Adaption der agilen Prinzipien, indem ein Vorgehensmodell entwickelt wird. Dieses soll anhand der identifizierten Anforderungen überprüft und bewertet werden.

4 4 Inhaltsverzeichnis 1 Einleitung Persönlicher Hintergrund Methodik und Aufbau der Arbeit Problemfeld Agile Vorgehensmodelle Einleitung Aufbau des Kapitels Definition Vorgehensmodell Phasen in der Software Entwicklung Planung des Prozesses Spezifikation der Anforderungen Design Implementieren Testen Historie der Vorgehensmodelle Wasserfallmodell Spiralmodell Schwergewichtige Vorgehensmodelle Agile Vorgehensmodelle Agiles Manifest XP Die 5 Werte Die Praktiken Praktiken der Planung Praktiken des Managens Praktiken des Designs Praktiken des Kodierens Praktiken des Testens Kanban Was ist Kanban? Was ist Kanban nicht? Historie Werte von Kanban Prinzipien von Kanban Techniken von Kanban Scrum Projektrollen Der Prozess

5 Artefakte Problemfeld Filmproduktion Einleitung Definition Imagefilm Phasen in der Filmproduktion Entwicklung Pre Produktion Produktion Post Produktion Absatz und Marketing Vorgehen in der Produktion eines Imagefilms Projektfindung Aufgabenfindung Ideenfindung Konzeptvorstellung Vertiefende Anforderungsanalyse Produktion Schnitt und Montage Gewerke in der Filmproduktion Autor Kameramann Tonmann Cutter Tonmeister Zusammenarbeit als Team Anforderungen an ein agiles Vorgehensmodell Einleitung Stakeholderanalyse Methodik der Stakeholderanalyse Grobe Analyse der Stakeholder Feine Analyse der Stakeholder Personae Ralf Müller, Werksstudent einer Medienagentur Thorsten Nadel, Filmproduktion als Nebengewerbe Robert Bach, eigene TV Produktionsfirma Anforderungen Zusammenfassung der Stakeholderanalyse Analyse der Personae Zusammenführung, Kategorisierung und Gewichtung aller Anforderungen Entwurf eines agilen Vorgehensmodells Einleitung

6 6 5.2 Werte Kommunikation Feedback Offenheit für Änderungen Frühe Produktion Botschaft als zentrales Ziel Rollen Product Owner Kunde Teamleiter Team Ablauf Projekt Initialisierung Sprint Projekt Abschluss Artefakte Film Vision Film Backlog Sprint Backlog Sprintergebnisse Wachsender Film Aktivitäten Recherche Projekt Initialisierung Sprint Planning Pioneer Phase Produktions Phase Post Phase Sprint Review Retrospektive Techniken Film Statements Kanban Board Burndown Chart Daily Standup Cheap Production Planning Poker Timeline Karten Auswertung Einleitung Anforderungen der Kategorie Kunde K01: Laienkonforme Präsentation der Zwischenergebnisse K02: Kommunikation des Projektstatus an Außenstehende K03: Mitgestalten des Kunden

7 7 6.3 Anforderungen der Kategorie Team T01: Zielgerichtetes Planen und Handeln T02: Kommunikation im Team T03: Einbringen von Fachwissen der Spezialisten T04: Werkzeuge für das Anforderungsmanagement T05: Schnelle Fertigstellung des Projekts Anforderungen der Kategorie Finanzielles F01: Kostentransparenz F02: Geringe finanzielle Kosten Anforderungen der Kategorie Anderes A01: Hohe Qualität des Imagefilms A02: Aufgabenbeschreibung für Laiendarsteller Übersicht aller Anforderungen und deren Erfüllung Fazit 119 Abbildungsverzeichnis 121 Tabellenverzeichnis 122 Literaturverzeichnis 125 Eidesstattliche Erklärung 126

8 6 1 Einleitung 1.1 Persönlicher Hintergrund Die Produktion von Imagefilmen stellt die alle Beteiligten vor Herausforderungen, die in der klassischen Welt der Filmproduktion so nicht vorkommen: Ein Imagefilm ist auf der einen Seite das Ergebnis kreativen Schaffens, aber auf der anderen Seite stehen auch harte, wirtschaftliche Interessen hinter ihm. Es existiert ein Kunde, dessen Fachsprache vom Team, also von den Leuten, die den Imagefilm produzieren, nicht gesprochen wird. Andererseits kann nicht davon ausgegangen werden, dass der Kunde die Fachsprache der Filmproduktion kennt. Kommunikation muss aber trotzdem in beide Richtungen funktionieren, damit hier ein effektiver Gestaltungsprozess entstehen kann. Dies sind nur einige der Probleme, denen ich persönlich in verschiedenen Filmprojekten - sei es im Rahmen meines Studiums oder in anderen Kontexten - immer wieder begegnet bin. Das hauptsächliche Problem war oft die Frage: Was soll eigentlich gemacht werden? Und obwohl diese Frage so trivial klingt, ist das Finden der Antwort meist ein weiter Weg. In dem Praxis Projekts in meinem Studium planten wir ein Imagefilm für ein externes Unternehmen zu drehen. Natürlich gehört zu dem organisatorischen Rahmen des Praxis Projekts ein formulierter Zeitplan. Wir machten uns also daran, Meilensteine zu setzen. Da es sich um die Produktion eines Filmes handelte, waren die Meilensteine naheliegend: Wir benutzten dafür die einzelnen Phasen der Filmproduktion wie Konzept erstellt, Drehbuch erstellt und Post Produktion abgeschlossen. Im Verlauf des Projektes bemerkten wir allerdings, dass diese Meilensteine so nicht eingehalten werden konnten: Immer wieder musste das Konzept überarbeitet werden, da Anforderungen des Kunden nicht von Beginn an klar waren oder sich im Verlauf des Projekts auch änderten. Mir fiel auf, dass dies Probleme sind, die auch in der Software Entwicklung vorkommen. Es stellte sich also die Frage, ob die Produktion von Imagefilmen viel Gemeinsamkeit mit der Entwicklung von Software Produkten hat. Und schnell entdeckte ich, dass wir im Wasserfallmodell geplant hatten, aber schlussendlich im Spiralmodel vorgegangen sind 1. 1 Die Begriffe werden im Verlauf der Arbeit erklärt.

9 7 Es stellte sich die Frage, inwiefern die Imagefilmproduktion von der Softwareentwicklung lernen kann. Und ob es möglich sei, auf Basis der bereits in der Informatik bekannten agilen Vorgehensmodelle ein neues Vorgehensmodell für die Imagefilmproduktion zu entwickeln. Dies soll Thema dieser Arbeit sein. Gleichzeitig gibt die Arbeit einen Überblick über die beiden Problemfelder, die hier behandelt werden: Die agilen Vorgehensmodelle der Informatik einerseits und der Kontext der Imagefilmproduktion andererseits. Außerdem werden Anforderungen an ein agiles Vorgehensmodell definiert, auf deren Basis zum Ende hin das entwickelte Vorgehensmodell bewertet werden kann. 1.2 Methodik und Aufbau der Arbeit Der strukturelle Aufbau der Arbeit wird in der Abbildung 1.1 dargestellt. Abbildung 1.1: Struktureller Aufbau der Arbeit Zuerst wird in Kapitel 2 der Kontext der agilen Vorgehensmodelle der Informatik vorgestellt: Es werden die Grundlagen zum Thema Agile Vorgehensmodelle gelegt, wobei insbesondere auf die Phasen der Softwareentwicklung, die historische Entwicklung der Vorgehensmodelle und die Unterschiede zwischen agiler und schwergewichtiger Vorgehensmodelle eingegangen wird. Kapitel 3 öffnet das Problemfeld der Imagefilmproduktion: Die Begriffe Imagefilm und Imagefilmproduktion werden definiert, analog zur Software Entwicklung werden die Pha-

10 8 sen der Filmproduktion erläutert und es werden die verschiedenen Gewerke erklärt, die bei der Produktion eines Imagefilms beteiligt sind. Auf Grundlage des Wissens aus Kapitel 3 wird in Kapitel 4 eine Anforderungsanalyse für das zu entwickelnde Vorgehensmodell durchgeführt. Hier werden mithilfe einer Stakeholder Analyse die Beteiligten des Vorgehensmodells ermittelt und dessen grobe Anforderungen identifiziert. Anschließend werden Personae entwickelt, und deren Verhalten im Kontext der Imagefilmproduktion beschrieben, um noch detailliertere Anforderungen an das Vorgehensmodell zu finden. Schlussendlich werden alle ermittelten Anforderungen zusammengeführt, kategorisiert und gewichtet. Aus Basis der Erkenntnisse aus Kapitel 2 wird in Kapitel 5 ein agiles Vorgehensmodell für die Imagefilmproduktion entworfen. Es werden dabei sowohl Werte, als auch Rollen, Aktivitäten, Ablauf, Artefakte und Techniken definiert, dies das Vorgehensmodell charakterisieren. In Kapitel 6 wird das entwickelte Vorgehensmodell anhand der aufgestellten Anforderungen untersucht und bewertet, inwiefern es diesen entspricht.

11 9 2 Problemfeld Agile Vorgehensmodelle 2.1 Einleitung Aufbau des Kapitels In diesem Kapitel soll das Poblemfeld der agilen Vorgehensmodelle aufgemacht werden. Die Abbildung 2.1 zeigt den strukturellen Aufbau des Kapitels. Abbildung 2.1: Struktureller Aufbau von Kapitel 2 In den Abschnitten werden die Grundlagen zum Thema Agile Vorgehensmodelle gelegt: Abschnitt 2.2 stellt die typischen Aktivitäten in der Softwareentwicklung vor und beschreibt die Phasen, die ein Softwareentwicklungsprojekt durchläuft. Abschnitt 2.3 behandelt die historische Entwicklung, wie aus dem klassischen Wasserfallmodell die ersten iterativen Ansätze entstanden.

12 10 In den Abschnitten 2.4 und 2.5 werden dann die beiden Ansätze von modernen Vorgehensmodellen vorgestellt, die schwergewichtigen und die agilen Vorgehensmodelle. Auf dieser Grundlage werden in den folgenden Abschnitten auf die drei bekanntesten agilen Vorgehensmodelle detailliert eingegangen: In Abschnitt 2.6 wird das Vorgehensmodell extreme Programming - oder kurz XP - und vor allem seine Praktiken vorgestellt. Viele dieser Praktiken bieten eine Grundlage für die in Kapitel 5 entwickelten Techniken. In Abschnitt 2.7 wird das Vorgehensmodell Kanban mit den Prinzipien der schlanken Softwareentwicklung aber auch der Technik des Kanban Boards vorgestellt. In Abschnitt 2.8 wird das Vorgehensmodell Scrum vorgestellt. Die Ergebnisse aus diesem Kapitel sollen hauptsächlich Grundlage für Kapitel 5 sein. Ziel dieses Kapitels ist es also, sowohl die allgemeinen Grundlagen zum Thema Agile Vorgehensmodelle zu legen, als auch mehrere agile Vorgehensmodelle zu betrachten. Dies soll dazu dienen, um ein agiles Vorgehensmodell entwickeln zu können Definition Vorgehensmodell Da das Thema dieser Arbeit die Entwicklung eines Vorgehensmodell ist, möchte dieser Begriff zuerst einmal definiert werden. Ein Vorgehensmodell kann als eine Beschreibung definiert werden, wie für eine bestimme Aufgabe vorgegangen wird. Je nach Aufgabe ist hier ein gewisses Level der Abstraktion vonnöten. Ein Vorgehensmodell beschreibt nicht die Umsetzung einer konkreten Aufgabe, sondern eher eine bestimmte Klasse von Aufgaben [Han10]. Hanser [Han10] schreibt, dass er als Synonym zu dem Begriff Vorgehensmodell den Begriff Prozessmodell verwendet und definiert diesen Begriff für die Software Entwicklung wie folgt: Ein Software-Prozessmodell ist ein Modell für den Ablauf der Entwicklung eines Software-Systems. Dabei geht es nicht um die Darstellung des Ablaufs eines bestimmten Software-Entwicklungsprojekts, sondern einer ganzen Klasse von Projekten. [Han10] Vorgehensmodelle gehören in der Informatik zum Bereich des Projektmanagement. Projektmanagement wird wie folgt definiert: Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten. [DIS09b]

13 Phasen in der Software Entwicklung Um in der Software Entwicklung von einem Auftrag zu einer fertigen und lauffähigen Software zu kommen, die am Ende beim Kunden in Betrieb genommen werden kann, sind verschiedene Aktivitäten notwendig. Als Laie könnte man meinen, Software Entwicklung sei Programmieren, also das schreiben von Code. Das ist nicht ganz falsch, das Programmieren ist tatsächlich ein Teil der Software Entwicklung. Allerdings gehören hier noch mehr Tätigkeiten dazu. Die erforderlichen Tätigkeiten der Software Entwicklung können in folgende Phasen unterteilt werden: [Han10] Planung des Prozesses Spezifikation der Anforderungen Design Implementieren (Programmieren) Testen Bei jedem Software-Entwicklungs-Projekt wird es nötig sein, die Aktivitäten dieser Phasen durchzuführen. Deswegen sei hier grob erklärt, was diese Phasen bedeuten und welche Aktivitäten sie beinhalten Planung des Prozesses Für jedes organisierte Handeln braucht es einen Plan, der früher oder später von dem Projektleiter oder dem Team ausgearbeitet werden soll. Je nach Vorgehensmodell werden hier die nächsten Schritte geplant und festgelegt, welche Aktivitäten von wem, wann erledigt werden sollen. In dieser Phase wird also geplant, wie die anderen Phasen durchgeführt werden sollen Spezifikation der Anforderungen Bei Software-Entwicklungs-Projekten handelt es sich meist um Projekte, die für eine bestimmte Domäne entwickelt werden. Software ist nicht zum Selbstzweck da, sondern dient immer dazu, dem Benutzer in seinem Nutzungskontext bei der Durchführung seiner Aufgabe zu unterstützen. Dabei gilt es diesen Kontext erst zu verstehen und auf dieser Grundlage Anforderungen an das System zu formulieren. In dieser Phase liegt der Schwerpunkt auf der Frage, was entwickelt werden soll.

14 Design Auf Basis der formulierten Anforderungen wird ein System entworfen. Hier werden die Entscheidungen getroffen, wie und mit welchen Hilfsmitteln es aufgebaut wird. In dieser Phase liegt der Schwerpunkt auf der Frage, wie entwickelt werden soll Implementieren Mithilfe der Entscheidungen aus der Design Phase kann nun (endlich) programmiert werden. Die in der Design Phase festgelegten Funktionen werden den Anforderungen entsprechend kodiert Testen Nach dem Kodieren wird die Software getestet, um zu validieren, dass sowohl das richtige Produkt, als auch das Produkt richtig entwickelt wurde. 2.3 Historie der Vorgehensmodelle Wasserfallmodell Hanser [Han10] beschreibt das Wasserfallmodell als den einfachsten Ansatz, ein Software Entwicklungsprojekt umzusetzen. Hierfür können die Phasen aus Abschnitt 2.2 betrachtet werden. Das ganze Projekt läuft beim Wasserfallmodell diese Phasen der Reihe nach durch. Jede Phase wird dabei nur ein mal durchgeführt. Jede Phase baut auf den Ergebnissen der vorherigen Phase auf. Somit herrscht für jede Phase die Bedingung, dass alle vorhergehenden Phasen keine Fehler enthalten und vollständig bearbeitet wurden. Vorteil bei diesem Modell ist die wahrgenommene Einfachheit in seiner Umsetzung. Da die Phasen, die in einem Software Projekt durchlaufen werden, aufeinander aufbauen und dadurch einen gewissen kanonischen Aufbau darstellen, bietet es sich natürlich an, diesen Aufbau genau so auch zu übernehmen. Allerdings bietet dieses Vorgehensmodell Nachteile, die gerade in Software Entwicklung negative Konsequenzen mit sich tragen. Das Wasserfallmodell geht davon aus, dass jede Phase zu einem definierten Zeitpunkt abgeschlossen ist. Das bedeutet, dass es z. B. einen Zeitpunkt gibt, an dem man behaupten kann, die Spezifikation der Anforderungen sei abgeschlossen und die nächste Phase könne nun beginnen. Was geschieht nun aber, wenn in der nächsten Phase deutlich wird, dass gewisse Anforderungen nicht detailliert genug spezifiziert worden

15 13 sind, oder sogar gar nicht beachtet wurden? Im Wasserfallmodell wird so etwas nicht mit in Betracht gezogen. Gerade in der Software Entwicklung ist dies aber häufig der Fall. Da das Wasserfallmodell ein Zurück-Gehen in eine vorherige Phase nicht vorsieht, ist es für solche Situationen nicht geeignet. Ein weiterer Nachteil des Wasserfallmodells ist, dass Probleme verschleppt werden, ohne dass dies offensichtlich ist. Grund dafür ist die Tatsache, dass eine Verifikation erst am Ende des Prozesses stattfinden kann; erst, wenn der komplette Prozess der Software Entwicklung abgeschlossen ist, kann der Auftraggeber überprüfen, ob das entwickelte Software Produkt seinen Anforderungen und Erwartungen entspricht. Wenn am Ende der Entwicklung deutlich wird, dass bestimmte Anforderungen oder Funktionen nicht richtig verstanden worden sind, kann darauf nicht mehr eingegangen werden. Das Wasserfallmodell sieht eine Korrektur durch den Auftraggeber so nicht vor. Es wird also deutlich, dass im Wasserfallmodell die Gefahr besteht, durch fehlendes Feedback des Auftraggebers ein Software Produkt zu entwickeln, das nicht den realen Anforderungen entspricht Spiralmodell Software Entwicklung nach dem Wasserfallmodell sieht aus der Sicht des Auftraggebers wie folgt aus: Nachdem der Auftragnehmer der Ansicht ist, die Anforderungen verstanden zu haben, verschwindet er für einen längeren Zeitraum aus dem Blickfeld des Auftraggebers und meldet sich dann nach längerer Zeit wieder mit einem fertigem Software Produkt. Leider ist dieses Produkt erwartungsgemäß nicht das, was der Auftraggeber wirklich braucht, und somit ist ein Teil - wenn nicht im schlimmsten Fall sogar die ganze Arbeit - der Entwicklung unbrauchbar. Dies liegt vor allem an der Herausforderung des Auftraggebers, die Anforderungen zu identifizieren, spezifizieren und verifizieren zu können. Es gibt hier mehrere Probleme: Der Auftragnehmer versteht die Problemstellung des Auftraggebers nicht richtig Der Auftraggeber ist sich seiner eigenen Problemstellung nicht vollständig bewusst Die Anforderungen ändern sich Die Unschärfe, die diese Probleme der Anforderungsanalyse mit sich bringen, kann man als Moving Target bezeichnen. (siehe dazu Abbildung 2.2 nach [Han10]) Barry Boehm [Boe88](zitiert nach [Han10]) schlug in den 80er Jahren des 20. Jahrhunderts das Spiralmodell vor, das einen iterativ-inkrementellen Ansatz verfolgte. Inkrementell bedeutet, anstatt das vollständige Produkt der Software auf einmal zu entwickeln, was meist mehrere Jahre in Anspruch nimmt, wird die Software in kleineren Paketen entwickelt. Die einzelnen Pakete bauen aufeinander auf und erweitern die Software Stück für Stück um die gewünschten

16 14 Abbildung 2.2: Die Vision des Endprodukts als Moving Target Funktionen. Iterativ bedeutet, dass für die Entwicklung jedes Inkrements (Pakets) die einzelnen Phasen der Software Entwicklung durchlaufen werden. Mithilfe des Spiralmodells kann auf die Problemstellung des Moving Targets besser reagiert werden: Die Software wird schrittweise entwickelt und nach jedem Schritt wieder mit den Wünschen und Anforderungen des Auftraggebers oder des Anwenders abgeglichen. So kann sichergestellt werden, dass die Entwicklung der Software den Erwartungen des Auftraggebers entspricht. Bei ändernden Wünschen kann schnell darauf reagiert werden, da diese bereits in die nächste Iteration eingebaut werden können. Ein weiterer Vorteil des Spiralmodells ist die Möglichkeit, dem Kunden schon früh funktionierende Software zeigen zu können. Zwar sind dies zu Anfang der Entwicklung nur kleine Teilaspekte von funktionierender Software, aber der Auftraggeber bekommt schnell einen Eindruck, wie die Software später aussehen und funktionieren wird. Dies ermöglicht dem Auftragnehmer, klarer zu kommunizieren, was entwickelt wird. Durch die Präsentation bereits funktionierender Software kann der Auftraggeber außerdem sehen, welche Funktionen noch fehlen. 2.4 Schwergewichtige Vorgehensmodelle Man unterscheidet zwischen schwergewichtigen und leichtgewichtigen Vorgehensmodelle [Han10]. Schwergewichtige Vorgehensmodelle sind dokumentenlastig. Die Dokumentation und eine formale Strukturierung der Prozesses spielen hier eine wesentliche Rolle. Schwergewichtige

17 15 Vorgehensmodelle eignen sich vor allem für die Entwicklung für Software, die in lebenskritischen Situationen zum Einsatz kommt. Das bedeutet, wenn die Fehlfunktion der Software eine Gefahr für Menschenleben birgt, oder die Entwicklung sonstiger strenger Auflagen standhalten muss und somit eine ausführliche Dokumentation und Planung wirklich notwendig ist, ist man gut beraten, sich dieser schwergewichtigen Vorgehensmodelle zu bedienen. Als Beispiel für schwergewichtige Vorgehensmodelle seien hier das V-Modell - XT und der Unified Software Development Process genannt [Han10]. Die schwergewichtigen Vorgehensmodelle gelten als dokumentenlastig und damit auch als teuer, da viel Zeit und Arbeit in Dokumente investiert wird. Zwar sind auch in den schwergewichtigen Vorgehensmodelle Iterationen und das Entwickeln von Inkrementen vorhanden, allerdings gelten sie durch ihre formale Strukturierung trotzdem als eher unflexibel auf wechselnde Anforderungen. Im Gegensatz dazu stehen die leichtgewichtigen Vorgehensmodelle, die auch als agile Vorgehensmodelle bezeichnet werden. Auf diese soll im Folgenden näher eingegangen werden. 2.5 Agile Vorgehensmodelle Agil bedeutet von großer Beweglichkeit zeugend; regsam und wendig [Dud15a], betont in dem Kontext von Vorgehensmodellen also die Möglichkeit, schnell auf Änderungen reagieren zu können. Agile Vorgehensmodelle sind die Reaktion auf die Unflexibilität und die Trägheit schwergewichtiger Vorgehensmodelle. Ein Vorgehensmodell ist agil, wenn es dem agilen Manifest entspricht Agiles Manifest Das Agile Manifest (oder auch das Manifest für Agile Softwareentwicklung ) ist die Erklärung führender Software Entwicklungs Experten, bewusst auf die Schwergewichtigkeit in Vorgehensmodellen zu verzichten und somit ein schnelleres, flexibleres und auf Änderungen reaktionsfähigeres Vorgehen zu entwickeln. Somit entschlossen sie sich im Februar 2001 für die 4 Werte Agilen Manifests [BBvB + 14]. Siehe hierfür Abbildung 2.3. Wie auch schon in Abbildung 2.3 beschrieben, bedeutet das, dass die Werte auf der rechten Seite zwar immer noch als wichtig erachtet werden, aber die Werte auf der linken Seite einen höheren Stellenwert haben. Betrachtet man z. B. den zweiten Satz: Funktionierende Software mehr als umfassende Dokumentation

18 16 Abbildung 2.3: Das Manifest für Agile Softwareentwicklung

19 17 Dies bedeutet eben nicht, dass in agilen Projekten gar nicht mehr dokumentiert wird. Dokumentation hat immer noch seinen Stellenwert. Allerdings hat funktionierende Software einen höheren Stellenwert. Da, wo Dokumentation eingesetzt werden kann, um dem Ziel der funktionierenden Software näher zu kommen, darf und soll sie auch eingesetzt werden. Diese Interpretation kann genau so auf die anderen Sätze angewendet werden: Die Prozesse und Werkzeuge sollen die Individuen und die Interaktionen unterstützen, der Vertrag soll die Zusammenarbeit mit dem Kunden fördern (dies ist meist ein nicht unkompliziertes Unterfangen) und der Plan sollte es möglich machen, auf Veränderungen reagieren zu können. Wichtig ist an dieser Stelle dem schnell entstehenden Gedanken zu widersprechen, dass agile Softwareentwicklung willkürlich, chaotisch oder gar anarchisch sei. Das stimmt so nicht. Es gibt immer noch Dokumentation, und es gibt immer noch eine Form, sich zu organisieren und einen Plan. Die Betonung liegt nur darauf, dass dieser Plan flexibel ist und auf Veränderungen reagieren kann. Diese Leitsätze bilden ein Wertesystem, dass die Grundeinstellung in der agilen Softwareentwicklung erklärt. Für ein konkretes Vorgehen in einem Projekt gibt dies allerdings keine große Hilfestellung [Han10]. Hierfür gibt es die agilen Vorgehensmodelle, die sich dem agilen Manifest verschrieben haben und die Werte des Manifests auf verschiedene Art und Weise umsetzen. Jedes dieser Vorgehensmodelle hat nicht nur andere Ansätze sondern, bewegt sich auch auf verschiedenen Abstraktionsgraden. XP beispielsweise ist eher eine Ansammlung von vielen Praktiken und Methoden, die beschreiben, wie konkret in den verschiedenen Phasen der Software Entwicklung vorgegangen wird. Hier werden Methoden fest gefordert und es wird behauptet, dass XP ohne diese Methoden nicht mehr XP ist. Scrum hingegen ist ein Meta Vorgehensmodell, welches keine konkreten Praktiken vorschreibt, sondern dem Team die Möglichkeit bietet oder sogar fordert, die Praktiken selbst zu wählen. Der unterschiedliche Ansatz der Vorgehensmodelle macht es schwierig, sie direkt miteinander zu vergleichen. Allerdings bietet sich so auch die Möglichkeit, die Vorgehensmodelle in vielerlei Hinsicht zu kombinieren, da sie ja auf unterschiedlicher Ebene agieren und sich so nicht widersprechen, sondern meist ergänzen. So steht zum Beispiel als Schlussbemerkung im Scrum Guide: Scrum existiert nur in seiner Gesamtheit und funktioniert sehr gut als Container für andere Techniken, Methoden und Praktiken. [SS13] Im Folgenden werden die drei populärsten Vorgehensmodelle der agilen Softwareentwicklung vorgestellt und deren Kernaspekte dargestellt.

20 XP Als erstes Vorgehensmodell soll das extreme Programming - oder kurz: XP - betrachtet werden. XP wurde von Kent Beck 1996 [Wel13] zum ersten mal eingesetzt und gilt als eines der ersten Vorgehensmodelle, die die Ansätze und Prinzipien von Agiler Softwareentwicklung in einem ganzheitlichem Rahmen umsetzen. Der größte Unterschied zu den anderen Vorgehensmodellen, die nachfolgend betrachtet werden, ist, dass XP klar vorschreibt, welche Methoden und Techniken für die Umsetzung des Vorgehensmodells zu benutzen sind. Scrum und Kanban sind eher Meta Modelle, das heißt, sie beschreiben das Vorgehen auf der Meta Ebene. Sie lassen ein individuelles Auswählen der konkreten Techniken zur Umsetzung nicht nur zu, sondern machen dies sogar erforderlich. Viele Aspekte der Umsetzung werden in diesen Modellen bewusst offen gehalten. XP ist da anders. Es schreibt ganz konkrete Praktiken und Regeln vor, die benutzt werden sollen. Kent Beck [Bec00] (zitiert nach [Han10]) verlangt sogar, dass XP nur in der Gesamtheit aller Methoden übernommen werden kann Die 5 Werte Um die Philosophie von XP verstehen zu können, sollen zuerst die Werte von XP betrachtet werden. Diese Werte geben keine Hinweise auf konkrete Handlungsanweisungen, stellen aber das Fundament dar, auf dem XP basiert. Während sich über bestimmte Praktiken diskutieren lässt, sind diese Werte wesentliche Grundlage. Alle Beteiligten von XP sollten diese Werte bejahen können. Die Praktiken und Regeln in XP unterliegen den 5 Werten: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Kommunikation Ein zentrales Anliegen in XP ist die Kommunikation. Da die Arbeit an dem Projekt nicht von Einzelkämpfern, sondern von einem Team geleistet wird, ist es wesentlich, dass die Kommunikation innerhalb des Teams funktioniert. Aber nicht nur die interne Kommunikation ist wichtig, sondern auch die Kommunikation mit dem Auftraggeber ist in XP sehr wichtig. So schreibt XP z.b. vor, dass ein Vertreter des Auftraggebers vor Ort für das Team da ist und durchgehend ansprechbar sein muss. Dies ist die unkomplizierteste und effizienteste Art der Kommunikation mit dem Auftraggeber.

21 19 Einfachheit In der Software Entwicklung tendiert man schnell dazu, Funktionen komplizierter zu machen, als es sein muss. Zum Beispiel kann man eine Funktion genau so bauen, dass sie den momentanen Ansprüchen genügt (einfach). Oder man kann sich überlegen, in welchen ähnlichen Situationen diese Funktion vielleicht auch noch gebraucht werden könnte um dann die Funktion so generisch wie möglich zu implementieren (kompliziert). In der Welt der agilen Software Entwicklung gibt es als Antwort auf diese Tendenz zwei Akronyme: KISS: Keep it simple, stupid (deutsch: Halte es dumm und einfach) YAGNI: You ain t gonna need it [Epp11](deutsch: Du wirst es sowieso nicht brauchen) Einfachheit bedeutet also, die Entwicklung so simpel und grundlegend zu halten, wie möglich. Es wird nicht darüber nachgedacht, was noch alles gemacht werden könnte, sondern genau das entwickelt, was wirklich auch gebraucht wird. Feedback Feedback spielt in vielen Bereichen von XP eine Rolle. Feedback als wichtig zu erachten bedeutet, sich einzugestehen, dass Ergebnisse Fehler enthalten können. Es zeugt davon, sich selbst hinterfragen zu können und Arbeitsergebnisse immer wieder auf den Prüfstand zu legen, um Fehler so früh wie möglich finden zu können. Diese Feedback Kultur wird sowohl intern als auch in der Kommunikation zum Kunden gelebt. Bei der Entwicklung werden Systemtests geschrieben. Diese ersetzen die Spezifikationen von Funktionen und ermöglichen ein direktes Testen der implementierten Funktionen. Somit kann auch bei späterer Veränderung der Funktionen oder bei einem Refactoring sicher gestellt werden, dass alle implementierten Funktionen und Klassen wie gewünscht funktionieren. Das Feedback des Auftraggebers wird so früh wie möglich eingeholt. Inkrementelle Entwicklung macht es möglich, schon sehr früh dem Auftraggeber lauffähige Software zu zeigen. Dieses Feedback ist wesentlich für die weitere Entwicklung. Hier kann sehr früh nachgeprüft werden, ob sich die Entwicklung auf dem richtigen Weg befindet und ob Anforderungen und Probleme richtig verstanden wurden. Bei Kommunikation und Feedback vom Auftraggeber ist es wichtig, die Sprache des Auftraggebers zu verwenden. Hier ist es wichtig, dass das Team domänenspezifische Fachbegriffe lernt.

22 20 Mut In vielen Bereichen der Entwicklung mit XP ist Mut nötig. Es braucht Mut, ein Refactoring zu machen, weil man sieht, dass bestimmte Teile des entwickelten Codes unübersichtlich werden. Entwickler tendieren dazu, geschriebenen und funktionierenden Code nicht zu ändern. Es braucht auch Mut, dem Auftraggeber bereits seinen noch sehr frühen Prototypen zu zeigen. Und es braucht sicher auch Mut, sich immer wieder auf die Änderungswünsche des Auftraggebers einzulassen und nicht an dem Plan festzuhalten. Mut zeigt die Bereitschaft, aus der Komfortzone herauszutreten und Schritte für eine zielgerichtete und effiziente Entwicklung zu gehen. Transparenz gegenüber dem Auftraggeber wird zuerst oft skeptisch hinterfragt: Wenn der Kunde weiß, wie es bei der Entwicklung der Software im Team wirklich zugeht, vor welchen Problemen das Team steht und welche Fehler bei der Entwicklung auftreten, wird er doch nicht mehr an die Professionalität des Software Teams glauben können. Die Erfahrung zeigt aber, dass sich dieser mutige Schritt meistens mit größerem Vertrauen und Verständnis der Auftraggebers auszahlt [Han10] - also eher das Gegenteil bewirkt. Respekt Software Entwicklung ist eine Arbeit mit Menschen. Ob im Team oder in der Kommunikation mit dem Auftraggeber, es handelt sich um Menschen, deren Ehre respektiert werden möchte. Respekt ist für jede Art der Zusammenarbeit zwischen Menschen erforderlich, um langfristig Vertrauen und eine positive Haltung zum Gegenüber zu entwickeln Die Praktiken Auf Basis der vorgestellten Werte führt XP viele Praktiken und Regeln ein, die konkret beschreiben, wie ein agiles Handeln möglich gemacht werden kann. Diese Praktiken sind im Folgenden aufgeführt. Hierbei sei erwähnt, dass nicht alle Praktiken nur XP typisch sind. Viele Praktiken wurden übernommen. Speziell an XP ist die Zusammenstellung dieser Praktiken und das konsequente und strukturierte Benutzen dieser. Die Praktiken sind eingeteilt in die verschiedenen Phasen der Software Entwicklung, angelehnt an die Phasen aus dem Wasserfall Modell: Planung, Managen, Design, Kodieren und Testen. [Wel13] Die Praktiken werden hier nicht in der Tiefe aller Details besprochen. Es soll nur ein grober Überblick gegeben werden. Für eine tiefere Einarbeitung sei auf weitere Literatur verwiesen [Han10] [Bec00] [Wel13].

23 Praktiken der Planung Für die Phase der Planung sieht Kent Beck [Bec00] folgende Techniken vor. User Stories User Stories ist eine Technik für die Anforderungsspezifikation. User Stories stellen ähnlich wie Use Cases die Benutzung des Systems aus der Anwender Sicht dar. Während allerdings Use Cases darauf aus sind, möglichst viele Details zu erfassen, reißt man mit User Stories ein bestimmtes Arbeitspaket nur an. Mithilfe von maximal drei Sätzen wird erklärt, wie eine bestimmte Funktion aus Anwender Sicht funktionieren soll. Dies dient vor allem zur groben Spezifikation der Anforderungen. Mithilfe aller User Stories soll die ganze zu entwickelnde Software beschrieben werden. Gleichzeitig dienen die User Stories auch der Einteilung in Arbeitspakete. Für Iterationen werden bestimmte User Stories ausgewählt, die dann zum nächsten Release fertig gestellt werden müssen. Somit lässt sich der Funktionsumfang des nächsten Releases klar definieren. Alle Details der Anforderungen, die in der User Story nicht verfügbar sind, sollen mit dem Kunden direkt besprochen werden. Dieser ist also die wandelnde Spezifikation [Bec00]. Mithilfe von Unit Tests werden dann die herausgearbeiteten Spezifikationen festgehalten (siehe dazu auch Abschnitt 2.6.7). Releases Releases sind mit dem Auftraggeber, dem Management und dem Entwicklungsteam festgelegte Zeitpunkte, zu denen eine definierte Menge von User Stories fertig gestellt sein soll. Dies wird in XP mithilfe des Planning-Game [Cun13] geplant, in welchem das Entwicklungsteam festlegt, wie viel Zeit es für jede einzelne der User Stories braucht. Die Menge der User Stories soll so gewählt werden, dass ein in sich sinnvoller Funktionsumfang der Software erreicht wird, dieses Release einen möglichst hohen business value besitzt und riskante Teile der Software möglichst in frühen Releases angegangen werden [Cun13]. Es wird empfohlen, Releases in einem zeitlichen Rahmen von 3 Monaten zu planen [Bec00] (nach [Han10]). Iterationen Wie in jedem modernen Vorgehensmodell wird in XP - angelehnt an das Spiralmodell - mit Iterationen gearbeitet. Es wird empfohlen, Iterationen in der Länge einer Woche anzusetzen[bec00]

24 22 (nach [Han10]). Für eine Iteration nimmt sich das Team eine oder mehrere User Stories aus dem vorhandenen Pool, schreibt die nötigen Tests und verbringt den Rest der Woche dann damit, diese User Stories und die damit verbundenen Funktionen zu implementieren. Die Tests helfen dabei, zu messen, wie weit die gewünschte Funktionalität bereits implementiert wurde und bieten somit dem Entwicklungsteam immer wieder auch die Möglichkeit, sich auf die wesentlichen Anforderungen zu fokussieren. Hier wird deutlich, dass innerhalb einer Iteration die verschiedenen Phasen des Wasserfallmodells durchlaufen werden: Es wird mithilfe der User Stories der Verlauf der nächsten Woche geplant (Phase Planung), dann wird zusammen mit dem Kunden die konkreten Anforderungen spezifiziert (Phase Anforderungsspezifikation). Diese Spezifikation wird in Unit Tests festgehalten (Phase Test), um diese im Verlauf der Woche dann zu entwickeln (Phasen Design und Kodieren). Mithilfe der User Stories und deren geschätzten Aufwand, die innerhalb einer Iteration abgearbeitet wurden, kann die Projektgeschwindigkeit gemessen werden. Somit lässt sich schnell der aktuelle Stand des Projektes schätzen. Es ist normal, dass diese Geschwindigkeit schwankt. Falls das aber über Iterationen hinweg auftritt, empfiehlt sich ein neues Release Planning [Wel13] Praktiken des Managens Die Phase Managen findet sich so nicht im Wasserfallmodell wieder. Es handelt sich hierbei auch nicht um eine zusätzliche explizite Phase, sondern eher um Rahmenbedingungen für die gesamte Entwicklungsarbeit. Die Praktiken, die hier beschrieben werden, können nicht einer bestimmten Phase zugeordnet werden. Sie bestimmen die Faktoren, die unabhängig von den Arbeitsphasen gleich bleiben. Offene Arbeitsumgebung Kommunikation ist - wie schon weiter oben erwähnt - eins der Kernwerte von XP. Aus diesem Grund soll das Team nicht räumlich getrennt sein, sondern zusammen in einem informativ gestalteten Raum zu arbeiten. Dies bedeutet, dass die Wände des Raums benutzt werden, um User Stories zu befestigen und Arbeitsergebnisse für alle sichtbar visualisiert werden. Außerdem sollte das Team in einem offenen Raum arbeiten. So ergeben sich viele Möglichkeiten, Probleme auf möglichst schnellem Wege zu klären. Wenn ein Entwickler an einer bestimmten Stelle nicht weiterkommt, kann er direkt einen Kollegen fragen. Dies ist weniger aufwändiger, als z.b. s zu schreiben oder ständig zwischen Büroräumen hin und her zu wechseln. Außerdem ermöglicht es allen Mitgliedern des Entwicklerteams zu wissen, mit wel-

25 23 chen Angelegenheiten sich die Kollegen gerade beschäftigen. Falls es ein Gespräch über ein Thema ist, das man als Entwickler gerade auch bearbeitet, gibt es unkompliziert die Möglichkeit, sich im Gespräch zu beteiligen. Alistair Cockburn nennt diesen Effekt osmotische Kommunikation [Coc03] (zitiert nach [Krs12]). Stand-Up Meeting Jeder Arbeitstag in XP beginnt mit einem Stand-Up Meeting. In diesem Treffen wird möglichst präzise, klar und schnell kommuniziert, wie der aktuelle Stand des Projekts ist, woran jedes Team arbeitet und was es für Probleme gibt. Zeiteffizienz spielt hier eine große Rolle, da dieses Treffen jeden Tag stattfindet und eine ineffiziente Arbeitsweise bei diesem Treffen langfristig große Folgen für die Zeiteffektivität des Teams hat. Hierbei hilft die Tatsache, dass diese Treffen - wie der Name schon andeutet - im Stehen abgehalten werden. Dies hat den psychologischen Effekt, dass man sich nicht lange an einem Diskussionspunkt aufhält. 1 Fix XP when it breaks XP ist sich der Individualität eines Software Projekts bewusst. Man sieht der Tatsache ins Auge, dass kein Software Projekt so ist wie das andere und dass Methoden, die bei einem Projekt gut funktioniert haben, nicht bei allen anderen Projekten genau so gut funktionieren. Dafür sind vierteljährige [Han10] Reflektionssitzungen vorgesehen, in denen die Effektivität der momentanen Praktiken hinterfragt wird. Hier reflektiert das gesamte Team über die momentane Arbeitsweise und überprüft diese auf potenzielle Probleme. Wichtig ist hierbei, dass Probleme nicht nur angesprochen, sondern auch konkrete Entscheidungen getroffen werden, um diese anzugehen. XP geht davon aus, dass diese Anpassungen der Arbeitsweise zu den normalen Aktivitäten der Entwicklungsarbeit gehören und immer wieder durchgeführt werden. Deswegen wird hier bei auch die Formulierung when (englisch: temporale Formulierung, zu übersetzen mit immer dann, wenn... ) und nicht die Formulierung if (englisch: konditionale Formulierung, zu übersetzen mit falls ) benutzt Praktiken des Designs In der Design Phase wird die Systemarchitektur der zu entwickelnden Software entworfen. Hierbei ist zu beachten, dass in XP die Design Phase nicht eine Phase mit Anfang und Ende ist, sondern, dass in jeder Iteration (also idealer weise wöchentlich) das Design überdacht und 1 Anmerkung des Autors: Man kann bei diesem Treffen also nicht von einer Sitzung sprechen, da sich ja keiner setzt.

26 24 den entsprechenden Anforderungen angepasst wird. Die folgenden Regeln und Praktiken gibt XP hierfür vor: CRC Karten CRC Karten (Class, Responsibilities and Collaboration Cards) sind eine einfache Möglichkeit, im Team schnell und zeiteffektiv Systeme zu entwerfen, zu diskutieren und zu revidieren. Es werden ca. DIN A5 große Karten benutzt, die einen Teil der Software repräsentieren. Dies können konkrete Klassen sein, müssen es aber nicht. Die Karte wird mit einem Namen versehen ( Class ) und es kann in maximal 4 Halbsätzen formuliert werden, was die Klasse leisten soll ( Responsibilities ). Zusätzlich kann noch notiert werden, mit welchen anderen Klassen diese Karte in Wechselwirkung steht ( Collaboration ). Der wesentliche Teil der Praktik besteht in der Möglichkeit, sehr schnell und flexibel über den gesamten Aufbau und die Zusammenhänge der einzelnen Klassen zu diskutieren. Hierfür befindet sich das Team an einem Tisch und legt die Karten so auf den Tisch, wie sie sich die Struktur der zu entwickelnden Software vorstellen. Es werden Vor- und Nachteile der Systemarchitektur besprochen und die Karten können immer wieder neu angeordnet werden. Die Möglichkeit, die Karten neu anzuordnen und somit also wirkliche Haptik für die Problemstellung zu entwickeln, verstärkt im Team das Denken in Objektorientierung. Da ein Revidieren oder auch ein neues Anordnen der Karten nur eine Sache von einigen Sekunden ist, kann hier sehr zeiteffizient gearbeitet werden und neue Entwürfe ohne Scheu vor Revision schnell diskutiert werden [Han10] [Wel13]. Spike Solutions Spike Solutions werden dann benutzt, wenn das Team sich nicht sicher ist, wie und ob ein Problem genau zu lösen ist und wie viel Aufwand das bedeutet. Spike Solutions sind kleine Prototypen, die quick and dirty entwickelt werden, um technologisches Neuland auszuprobieren. Der Code sollte nicht wiederverwendet werden [Han10]. Mithilfe des technologischen Durchstichs zu einem bestimmten Problem kann das Team aufgrund der Erfahrungen, die es dabei macht, sehr viel besser abschätzen, was an Aufwand und Komplexität hinter einem Problem steht. Außerdem kann das Team so fremde Technologien - wie z.b. ein neues Framework - ausprobieren, ohne zu viel Zeit durch eine Einarbeit zu verlieren, nur um danach festzustellen, dass das Benutzen des Frameworks nicht hilfreich ist.

27 Praktiken des Kodierens Für die Phase des Kodierens sieht XP folgende Praktiken vor. Kunde immer verfügbar XP sieht vor, dass der Kunde immer für das Team als Ansprechpartner verfügbar ist. Konkret wird empfohlen, dass ein Experte von Kundenseite ständig an der Seite des Teams ist [Wel13]. Dies mag seltsam erscheinen, da der Kunde während der gesamten Projektlaufzeit auf eine wichtige Ressource (einen Experten) im eigenen Betrieb verzichten muss. Dies ist aber für die verschiedenen Aktivitäten und für das agile Vorgehen notwendig. Wie schon im Abschnitt erwähnt, kann nur mithilfe des Experten vor Ort eine detaillierte Anforderungsspezifikation durchgeführt werden. Nur der Hilfe des Kunden ist es beim Release Planning möglich, eine Priorisierung der User Stories nach business value vorzunehmen [Wel13]. Und nur mit dem Kunden vor Ort ist es möglich, so schnell wie möglich auf Anforderungsänderungen einzugehen. Ein weiterer Einwand gegen die Arbeit mit dem Kunden vor Ort ist die daraus resultierende totale Transparenz des Teams und seines Fortschritts gegenüber dem Kunden. Wie auch in Abschnitt beschrieben, könnte eine Transparenz gegenüber dem Kunden doch zu einem eher unprofessionellen Eindruck führen, denn vor ihm werden alle Probleme, Hindernisse, sowie auch die Schwächen und der Arbeitsablauf des Teams sichtbar. Führt dies nicht zu einem Vertrauensverlust des Kunden gegenüber dem Team? Die Erfahrung [Han10] zeigt hier, dass der Kunde - durch das Einbinden in das Team - eher ein besseres Verständnis für das Projekt, sowie mehr Vertrauen dazu entwickelt. Die Zeitinvestition, die der Kunde mit der ständigen Anwesenheit eines Experten vor Ort, scheint sehr groß zu sein. Hierbei sei erwähnt, dass für diesen Ansatz allerdings die gesamte Zeit einer ausführlichen Anforderungsanalyse mit dem Kunden gespart werden kann. Zudem kann davon ausgegangen werden, dass durch die Anwesenheit des Experten am Ende die Ergebnisse - wenn überhaupt - nur geringfügig von den Anforderungen des Kunden abweichen, und somit die Zeit der ansonsten notwendigen Korrektur gespart werden kann [Wel13]. Pair Programming Pair Programming ist die Praxis, dass sich zwei Entwickler zusammen mit einer Aufgabe beschäftigen. Sie sitzen dabei zusammen an einem Rechner, ein Entwickler benutzt die Tastatur und der andere sitzt daneben. Die Rollen des Schreibens und des Beobachtens werden regelmäßig zwischen den beiden Entwicklern getauscht.

28 26 Die Idee des Pair Programmings ist auf der Idee der gedanklichen Arbeitsteilung begründet: Während der Entwickler an der Tastatur das Problem auf taktischer Ebene angeht, macht sich sein beobachtender Kollege über die strategischen Dimensionen des Problems Gedanken. Pair Programming hat verschiedene Vorteile. Es bietet die Möglichkeit, Wissensinseln zu vermeiden, indem mindestens zwei Entwickler über das Wissen der Codebasis für die zu entwickelnde Funktionalität verfügen [WA12]. Wenn beide Entwickler ungefähr gleich viel Erfahrung haben, können sie sich gegenseitig gut unterstützen. Wenn ein Entwickler des Paars deutlich erfahrener als der andere ist, kann der Unerfahrene durch die Zusammenarbeit viel von dem Erfahrenen lernen. Hier gilt wieder der Wert der Kommunikation (siehe Abschnitt 2.6.1), ein Reden über den Code von Angesicht zu Angesicht - während man am Code Änderungen vornimmt - erweist sich als gute Grundlage, Wissenslücken zu füllen [Roo14] Praktiken des Testens Die Phase des Testens - die im Wasserfallmodell (siehe Abschnitt 2.3.1) eine explizite Phase war - ist in XP in der Entwicklung der Software integriert. Die folgenden Praktiken und Regeln sieht XP für das Testen vor. Unit Tests für den gesamten Code Unit Tests, also Tests, die nah an der Funktionalität einzelner Codeabschnitte liegen, bilden in XP die Grundlage für ein zeiteffizientes Entwickeln. Wells [Wel13] widerspricht der Annahme, dass das Entwickeln von Tests zu viel Zeit in Anspruch nehmen würde. Das Entwickeln des Tests nimmt als solches kaum Zeit in Anspruch, wenn man es in der Kombination mit der Entwicklung der gewünschten Funktionalität sieht. 2.7 Kanban Das nächste zu betrachtende Vorgehensmodell ist Kanban. Kanban hat im Vergleich zu den beiden anderen in dieser Arbeit vorgestellten Vorgehensmodelle XP und Scrum die Besonderheit, dass es nicht für die Softwareentwicklung entworfen wurde. Ursprünglich wurde Kanban von Toyota entwickelt und diente zum Managen und Optimieren Prozessen in der Automobilherstellung. Die Tatsache, dass das Vorgehensmodell - wenn auch mit Änderungen - aus der Domäne Automobilindustrie in die Domäne Softwareentwicklung übertragen werden konnte, diente auch zum Teil als Motivation für diese Arbeit. Da Kanban nun bereits schon einmal erfolgreich in eine andere Domäne adaptiert werden konnte, gibt es also Grund genug, es als Vorgehensmodell hier genauer zu betrachten.