Möglichkeiten der agilen Softwareentwicklung in einer konservativen Umgebung

Transkript

1 Möglichkeiten der agilen Softwareentwicklung in einer konservativen Umgebung Hochschule Bremen Fakultät Elektrotechnik und Informatik Masterstudiengang Informatik Komplexe Softwaresysteme Gutachter Prof. Dr.-Ing. Andreas Spillner Dipl.-Ing. Thorsten Reinken Master-Thesis Patrick Rehder (199379),

2 >>> Erklärung Master-Thesis I. Erklärung Ich versichere, die vorliegende Master-Thesis ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Bremen, den 3. August 2012 (Ort, Datum) Patrick Rehder (Unterschrift) Patrick Rehder 2

3 >>> Hinweise Master-Thesis II. Hinweise Danke! Ich möchte insbesondere den Kollegen aus der Business-Unit Externe Produkte (Commerz Systems GmbH) danken. Sie standen mir immer rasch mit Rat und Antworten zur Seite. Vielen Dank! Anonymisierung Folgende Namen wurden zwecks Anonymisierung frei erfunden: Rot AG, ASTAT, NIOB, TANTAL. Ähnlichkeiten oder Übereinstimmungen mit echten Projekten und Firmen sind rein zufällig und nicht beabsichtigt. Legende Englische Eigennamen werden kursiv dargestellt. Zum Beispiel: Extreme Programming. Abkürzungen und Übersetzungen werden in runde Klammern eingefasst. Zum Beispiel: Mit freundlichen Grüßen (MFG). Werden Wörter im Glossar erklärt, wird dies beim ersten Vorkommen wie folgt dargestellt: Glossar. Verweise auf Quellen werden in eckige Klammern eingefasst. Zum Beispiel: [5] oder [18, p. 17]. Bei digitalen Quellen ohne Seitenzahlen wird das Kapitel genannt. Zum Beispiel: [2, p. 'Vorwort'] Beiliegender Datenträger Auf dem beiliegenden Datenträger befinden sich: Eine PDF-Version dieser Master-Thesis. Jeweils eine PDF-Version zu genutzten und frei verfügbaren Onlineinhalten. Hilfreiches und verwendete Werkzeuge Dieses Dokument wurde mithilfe von Microsoft Office Word 2010 erstellt. Skizzen von Benutzeroberfläche wurden unter Verwendung von Balsamiq Mockups designet (siehe Das Buch slide:ology von Nancy Duarte gab wertvolle Hinweise zum Entwickeln von Präsentationen, welche im Master-Seminar angewendet wurden und im Kolloquium angewendet werden. Patrick Rehder 3

4 >>> Kurzfassung Master-Thesis III. Kurzfassung Im Zentrum dieser Arbeit steht die agile Softwareentwicklung, welche im Rahmen einer Abteilung der Commerz Systems GmbH betrachtet wird. Der Einstieg erfolgt über das Agile Manifest, welches die Werte einer agilen Vorgehensweise einfängt und als Grundstein der Agilität zu betrachten ist. Die im Folgenden umfassend betrachteten agilen Prozesse zeigen konkrete Lösungen für eine agile Softwareentwicklung auf. Betrachtet werden Scrum, Feature Driven Development und Extreme Programming. Es zeigt sich, dass die Prozesse in vielen Punkten unterscheiden und jeder über eigene Stärken und Schwächen verfügt. Um das Vorgehen bei der Softwareentwicklung für die Abteilung zu bestimmen, werden drei abgeschlossene Projekte betrachtet. Es wird ein allgemeines Vorgehensmodell entwickelt, genutzte Methoden identifiziert und eine Umfrage durchgeführt. Als Ergebnis wird festgehalten, dass die Abteilung bereits eine agile Kultur aufweist oder zumindest auf dem Weg dorthin ist. Auf den vorherrschenden Bedingungen in der Abteilung werden Scrum und Extreme Programming als passende Vorgehensmodelle identifiziert und deren mögliche Einführung betrachtet. Als Alternative wird ein Ansatz aufgezeigt, um das bisherige Adaptieren von Methoden systematisch fortzuführen. Patrick Rehder 4

5 >>> Inhaltsverzeichnis Master-Thesis IV. Inhaltsverzeichnis I. Erklärung...2 II. Hinweise...3 III. Kurzfassung...4 IV. Inhaltsverzeichnis Einleitung Motivation Ziele Vorgehen Umfeld Grundlagen: Agile Softwareentwicklung Agile Manifest Scrum Rollen Ereignisse Artefakte Das Zusammenspiel Feature Driven Development Rollen Prozesse Nachbetrachtung Extreme Programming Werte Prinzipien Methoden Rollen Nachbetrachtung Zusammenfassende Betrachtung Derzeitiges Vorgehen Business-Unit Externe Produkte (CtB10) Vorgehensmodell Vorgehensmodell: ASTAT Vorgehensmodell: NIOB Vorgehensmodell: TANTAL Techniken und Methoden Umfrage in der Business-Unit Entwicklung des Fragebogens Auswertung der Antworten Patrick Rehder 5

6 >>> Inhaltsverzeichnis Master-Thesis Fazit zur Umfrage Mögliches Vorgehen Einsatz eines bestimmten Vorgehensmodells Warum nicht Feature Driven Development? Scrum als eine Möglichkeit Extreme Programming als andere Möglichkeit Einsatz eines eigenen Vorgehensmodells Continuous Method Evaluation Nachbetrachtung Ergebnis A. Glossar B. Abbildungsverzeichnis C. Tabellenverzeichnis D. Quellenverzeichnis E. Anhang Patrick Rehder 6

7 >>> Einleitung Master-Thesis 1. Einleitung Im Mittelpunkt dieser Master-Thesis steht die agile Softwareentwicklung. Da dieses Gebiet sehr umfassend ist, muss der betrachtete Bereich eingeschränkt werden. Die Antworten zu folgenden Fragen helfen dabei: Warum dieses Thema? Unterkapitel 1.1: Motivation (Seite 7) Welche Ziele hat diese Arbeit? Unterkapitel 1.2: Ziele (Seite 8) Was kann wie erreicht werden? Warum dieses Vorgehen und kein anderes? Unterkapitel 1.3: Vorgehen (Seite 8) Gibt es bereits Arbeiten zu diesem Thema? Wenn ja, wo fließen diese Arbeiten ein? Unterkapitel 1.4: Umfeld (Seite 10) 1.1. Motivation Das Thema wurde in der Business-Unit Externe Produkte entwickelt, einer Abteilung der Commerz Systems GmbH. Die Commerz Systems GmbH ist ein mittelständisches Unternehmen mit etwa 350 Mitarbeitern, verteilt auf zwei Standorte: Frankfurt am Main und Bremen. Es handelt sich bei der Commerz Systems GmbH um eine 100%ige Tochter der Commerzbank. Der Mutterkonzern gibt vor, dass sich das Geschäftsfeld der Commerz Systems GmbH auf die Commerzbank beschränken soll. Da die Commerzbank Inhaber und Kunde zugleich ist, wird das Vorgehen bei der Softwareentwicklung maßgeblich durch die Commerzbank beeinflusst. Agile Vorgehensweisen werden in der Commerzbank nur vereinzelt eingesetzt. Es ist das Ziel der Bank erst Erfahrungen zu sammeln. Dies lässt sich beispielsweise am Beta-Status der hauseigenen Scrum-Erweiterung erkennen, dem Information Technology Project Management Framework Agile. Derzeit wird ein agiles Vorgehen von der Commerzbank weder aktiv beworben, noch verlangt. Einige Mitglieder der Business-Unit Externe Produkte beschäftigen sich schon seit längerem mit agilen Ideen im Allgemeinen und Scrum im Speziellen. Sie halten ein agiles Vorgehen für wünschenswert und setzen sich dafür ein. Dies ist der Grund dafür dass einzelne Elemente in der Business-Unit bereits ausprobiert wurden und gegebenenfalls weiter eingesetzt werden. Flächendeckend sind in der Business-Unit Externe Produkte nur die eingesetzten Elemente bekannt. Die Motivation begründet sich damit auf dem Interesse für agile Vorgehenswesen in der Business- Unit Externe Produkte. Patrick Rehder 7

8 >>> Einleitung Master-Thesis 1.2. Ziele Agile Softwareentwicklung betrachten Diese Master-Thesis soll einen Überblick über die agile Softwareentwicklung geben. Dieser Überblick soll jedem Mitglied der Business-Unit Externe Produkte dazu dienen, sich ein Gesamtbild von agilen Vorgehensmodellen zu machen. Folgende Punkte der agilen Softwarentwicklung werden betrachtet: Werte und Prinzipien im Rahmen vom Agile Manifest 1 Prozesse, welche weit verbreitetet sind Methoden im Kontext der Prozesse Vorgehen analysieren und dokumentieren Da aktuell (März 2012) kein größeres Entwicklungsprojekt von der Business-Unit Externe Produkte durchgeführt wird, stehen die letzten drei Projekte 2 im Fokus: ASTAT, NIOB und TANTAL. Das Vorgehen in den genannten Projekten soll analysiert und dokumentiert werden, wobei insbesondere auf die agilen Elemente einzugehen ist. Mögliches Vorgehen zeigen Es sollen Möglichkeiten erarbeitet werden, wie ein agiles Vorgehen weiter zu intensivieren ist. Folgende Punkte sind zu betrachten: Einsatz eines bestimmten agilen Prozesses Erweiterung des derzeitigen Vorgehens um weitere agile Elemente 1.3. Vorgehen In diesem Kapitel wird erläutert, welches Vorgehen zum Erreichen der Ziele genutzt wird. Die Ziele finden sich in der Gliederung der Arbeit wieder (siehe Tabelle 1). Ziel Agile Softwareentwicklung betrachten Vorgehen analysieren und dokumentieren Mögliches Vorgehen zeigen Kapitel Grundlagen: Agile Softwareentwicklung (Kapitel 2, ab Seite 11) Derzeitiges Vorgehen (Kapitel 3, ab Seite 61) Mögliches Vorgehen (Kapitel 4, ab Seite 81) Tabelle 1 - Gegenüberstellung der Ziele und Kapitel 1 Das agile Manifest wird in Kapitel 2.1 (ab Seite 12) erläutert. 2 Die Projekte ASTAT, NIOB und TANTAL werden in Kapitel 3.1 (ab Seite 71) erläutert. Patrick Rehder 8

9 >>> Einleitung Master-Thesis In jedem der aufgezählten Kapitel wird ein Ziel behandelt. Die Kapitel werden ihrer Anordnung nach abgearbeitet. Folgendes spricht für diese Reihenfolge: Die Business-Unit Externe Produkte setzt bereits agile Methoden ein. Um diese identifizieren zu können, werden zunächst die Grundlagen zur agilen Softwareentwicklung erarbeitet. Das derzeitige Vorgehen soll als Basis für das mögliche Vorgehen dienen. Beim Erarbeiten der Grundlagen werden die am weitest verbreiteten agilen Prozesse betrachtet. Hierzu wurden vier Umfragen zusammengefasst (siehe Tabelle 2). Quelle Agilität wird Mainstream: Ergebnisse der Online-Umfrage [1, p. 1] Forrester/Dr. Dobb s Global Developer Technographics Survey [2, p. 2] State of Agile Servey [3, p. 4] Softwaretest in der Praxis [4, pp. 8, 9] Jahr Teilnehmer Verbreitung (Ausschnitte!) Scrum (21%) FDD (17%) XP (14%) - Scrum (10,9%) FDD (3,8%) XP (2,9%) Crystal (0,3%) Scrum (58%) Scrum/XP Hybrid (17%) XP (4%) FDD (2%) Tabelle 2 - Ausschnitte aus Umfragen zur Anwendung agiler Prozesse Diese drei Prozesse wurden am Häufigsten genannt: Scrum (57%) FDD (5,2%) XP (4,0%) Crystal (0,4%) Scrum Feature Driven Development (FDD) Extreme Programming (XP) Der Umfang, mit dem die agilen Prozesse behandelt werden, ergibt sich aus der Zielgruppe. Die Prozesse sind so zu beschreiben, dass alle Mitglieder der Business-Unit Externe Produkte ein gemeinsames Verständnis der agilen Softwarentwicklung aufbauen. Auf Basis dieses gemeinsamen Verständnisses besteht die Möglichkeit, einen agilen Prozess zu etablieren oder weitere agile Methoden einzuführen. Die Grundlagen sollen außerdem als Nachschlagewerk für einzelne Bestandteile der agilen Softwareentwicklung genutzt werden. Als Möglichkeit für ein zukünftiges Vorgehen sollen die agilen Prozesse Scrum, Feature Driven Development und Extreme Programming unter den vorherrschenden Bedingungen betrachtet werden. Patrick Rehder 9

10 >>> Einleitung Master-Thesis Bisher wurden agile Methoden vereinzelt erprobt und gegebenenfalls adaptiert. Es soll auch untersucht werden, ob es eine Alternative darstellt, den eigenen Prozess systematisch um weitere agile Methoden anzureichern Umfeld Der Hype zur agilen Softwareentwicklung ist ungebrochen. Es wird viel in Blogs, Artikeln und Büchern darüber geschrieben und auf Konferenzen präsentiert und diskutiert. Viel wichtiger ist, dass das agile Vorgehen in der Praxis angekommen ist. Dies kann den folgenden Umfrageergebnissen entnommen werden: 2008, 1. Quartal - Agilität wird Mainstream: Ergebnisse der Online-Umfrage 2008 [1] 36% der 207 Befragten gaben an agil vorzugehen. 2009, 3. Quartal - Forrester/Dr. Dobb s Global Developer Technographics Survey [2] 35% der Befragten gaben an agil vorzugehen. 2010, 3. Quartal - Agile Softwareentwicklung am Standort Deutschland [5] 44% der 237 Befragten gaben an bereits Erfahrungen mit agilen Methoden gesammelt zu haben. 2011, 2. Quartal - Umfrage 2011: Softwaretest in der Praxis [4] 28% der Teilnehmer gaben an ein agiles Vorgehensmodell zu nutzen. Aufgrund der zunehmenden Verbreitung und dem vorherrschenden Interesse gibt es viele Informationsquellen zur agilen Softwareentwicklung. Eine gelungene Übersicht bietet die Broschüre Agile Softwareentwicklung - Ein Überblick [6], welche jedoch nicht die gewünschte Tiefe dieser Master- Thesis erreicht. Die Grundlagen werden aus verschiedenen Quellen zusammengetragen, wobei sich auf die Werke der Erfinder konzentriert wird. Auf die verwendete Literatur wird in den entsprechenden Kapiteln verwiesen. Möglichkeiten zur Einführung agiler Prozesse und Methoden werden in der Literatur bereits vielfach genannt. Hier ist beispielsweise ein Kapitel aus dem Buch von Boris Gloger zu nennen: Einführung von Scrum in großen Projekten und Organisationen [7, pp ]. Es gibt aber auch ganze Bücher, die sich mit dem Thema beschäftigen: A Practical Guide to Feature-Driven Development [8], Extreme Programming Applied: Playing to Win [9] und Agile Projekte mit Scrum, XP und Kanban in Unternehmen durchführen [10]. Diesen Werken werden hilfreiche Ideen und Ratschläge entnommen, um Möglichkeiten für das weitere Vorgehen zu bestimmen. Speziell auf Banken bezogene Werke werden in dieser Arbeit mangels öffentlicher Verfügbarkeit nicht einbezogen. Allerdings wurde Feature Driven Development bei einem Projekt in einer Bank entwickelt. Hierauf wird in der Literatur jedoch ausschließlich historisch Bezug genommen und nicht auf den Prozess selber. Patrick Rehder 10

11 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis 2. Grundlagen: Agile Softwareentwicklung Nach dem Agile Manifest werden die folgenden drei agilen Prozesse betrachtet: Scrum Feature Driven Development Extreme Programming 2.1. Agile Manifest Februar 2001, Snowbird Ski Resort (Nord Amerika): Siebzehn anerkannte und erfahrene Softwareentwickler 3 mit ähnlichen Ideen trafen sich für ein Wochenende, um sich über das Vorgehen in der Softwarenentwicklung auszutauschen. Dieses Treffen kann als Geburtsstunde der agilen Softwareentwicklung bezeichnet werden. Die Teilnehmer einigten sich auf den Begriff der Agilität, welcher seither verwendet wird. Außerdem wurde das Agile Manifest [11] verfasst, welches die Gedanken hinter der agilen Softwareentwicklung einfängt und von allen Teilnehmern anerkennend unterzeichnet wurde. [12, pp. 5, 6] [13, pp. vii, viii, ix] Doch was macht das Agile Manifest aus? Es sind die Werte, die vom Manifest beschrieben werden. Sie sind die Basis für ein gemeinsames Verständnis der agilen Softwareentwicklung. wichtiger wichtig Individuen und Interaktionen Prozesse und Werkzeuge funktionierende Software umfassende Dokumentation Zusammenarbeit mit dem Kunden Vertragsverhandlungen Reagieren auf Veränderung Befolgen eines Plans Abbildung 1 - Die Werte vom Agile Manifest Das Agile Manifest nennt acht Bereiche der Softwareentwicklung, die paarweise miteinander verglichen werden (siehe Abbildung 1). Hierbei handelt es sich um einen wertenden Vergleich, der immer 3 zum Beispiel: Ken Schwaber (Scrum), Jeff Sutherland (Scrum) und Kent Beck (Extreme Programming) Patrick Rehder 11

12 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis einen Bereich als wichtiger und wertvoller herausstellt. Durch diese Wertung entsteht ein Bild, auf was es in der agilen Softwareentwicklung ankommt. Im Zusammenhang mit der Wertung ergibt sich oft das Missverständnis, dass die agile Softwareentwicklung ohne Prozesse, ohne Dokumentation, ohne Verträge und ohne Planung auskommt. Dies stimmt nicht: Die Werte auf der rechten Seite werden zwar nicht primär verfolgt, sie sind aber dennoch wichtig. Warum agile Methoden sinnvoll sind geht nur indirekt aus dem Agile Manifest hervor. Folgendes spricht dafür: Individuen und Interaktion sind wichtiger als Prozesse und Werkzeuge Das Wesen der Softwareindustrie liegt in der Verarbeitung von Wissen. Genauer gesagt der Abbildung von Prozessen und Arbeitsabläufen in Software. Diesem Umstand wird sich in der Softwareentwicklung traditionell über Ideen der Massenfertigung 4 genähert. Es wird versucht Arbeitsabläufe in möglichst kleine Einheiten zu zerbrechen, die von spezialisierten Mitarbeitern ausgeführt werden: Analysten analysieren, Architekten entwerfen, Programmierer programmieren und Tester testen. Jeder Mitarbeiter übernimmt hierbei immer ähnliche Aufgaben. Dies führt im besten Fall zu einer hohen Produktivität und im schlechtesten Fall zur Ermüdung und Demotivation des Mitarbeiters. [14, p. 28 f.] Die oft verwendete Bezeichnung Ressource verdeutlich, dass Menschen aus Prozesssicht betrachtet werden und nicht als Individuum. Der dahinterliegende Gedanke ist aus Prozesssicht wünschenswert, aber nicht realistisch: Wenn zwei Menschen die Anforderungen gemäß Prozessdefinition erfüllen, können sie einfach ausgetauscht werden. Das im gleichen Zusammenhang gerne erwähnt wird, wie wichtig der Faktor Mensch ist, wirkt widersinnig. [15] Dieser Widerspruch wird vom Manifest zugunsten des Menschen entschieden. Das Manifest hebt außerdem die Interaktion zwischen den Beteiligten hervor. In traditionellen Prozessmodellen wird selbstverständlich auch miteinander interagiert, allerdings meist über Dokumente. Zu nennen ist das Wasserfallmodell, welches bei Phasenübergängen prozessbedingt Dokumente verlangt. Das Weiterreichen von Informationen über Dokumente führt jedoch zu einem immensen Wissensverlust. [12, p. 18] Der Grund hierfür liegt in der Kommunikationsart Papier. In Abbildung 2 werden unterschiedliche Kommunikationsarten hinsichtlich Effektivität und Vielfalt des Kommunikationskanals (Sprache, Gestik, ) aufgeführt. Die Gedanken hierzu stammen ursprünglich von Alistair Cockburn [16, p. 84] und wurden von Scott Amber übernommen und erweitert. [17, p. 84] Wie Tom DeMarco und Timothy Lister bereits 1987 festhielten, sind die größten Probleme nicht technologischer sondern soziologischer Natur. [18, p. 5] 4 Schülerduden Wirtschaft: Bei der Massenfertigung werden gleiche Erzeugnisse über eine längere Zeit hinweg in großen Mengen hergestellt. [67, p. 139] Patrick Rehder 12

13 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis hoch Effektivität der Kommunikation Diskussion Gespräch Telefon Videoaufnahme Tonaufnahme Gespräch mit Hilfsmitteln (z.b. Whiteboard) Videokonferenz Dokumentation niedrig Papier Vielfalt des Kommunikationskanals hoch Abbildung 2 - Kommunikationsarten zur Diskussion und Dokumentation [17, p. 84] Funktionierende Software ist wichtiger als eine umfassende Dokumentation Der Zweck der Softwareentwicklung ist es Softwaresysteme zu entwickeln, die dem Anwender einen Nutzen bringen. Dieser Nutzen kann nur von einem funktionierenden System erbracht werden, nicht von einer umfassenden Dokumentation. Die Dokumentation kann ein funktionierendes System aus Anwendersicht höchstens unterstützten, so dass das System leichter zu verstehen ist oder die Weiterentwicklung beschleunigt wird. Da das primäre Ziel der Softwareentwicklung darin besteht Software zu entwickeln, ist es nur logisch sich auf die Entwicklung von Software zu konzentrieren. Das alleinige Erstellen von Dokumenten führt dazu, dass sich der Kunde in falscher Sicherheit wiegt. Ihm wird ein Fortschritt aufgezeigt, der ihm keinen Nutzen bringt. Es ist nicht zielstrebig mit einer umfassenden Dokumentation zu beginnen dieses Vorgehen wird besser durch Dokumentationsentwicklung beschrieben, nicht durch Softwareentwicklung. [9, p. 17] [17, pp. 6, 7] Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen Im Buch The Art of Lean Software Development wird die 80/20 Regel genannt. Diese besagt, dass in der Regel 80% der Anforderungen des Anwenders durch 20% der Funktionen abgedeckt werden. Außerdem wird auf eine Studie aus dem Jahr 2001 verwiesen, die 400 Projekte über einen Zeitraum von 15 Jahren betrachtet hat und herausfand, dass weniger als 5% des erzeugten Quelltextes genutzt werden. [12, p. 17] Dies zeigt, dass es wichtig ist, mit dem Kunden und dem Anwender zusammenzuarbeiten. Die Anforderungen des Kunden müssen hinsichtlich des Nutzens bestimmt werden, es gilt goldene Wasserhähne zu vermeiden. Die Zusammenarbeit mit dem Kunden wird im Manifest wichtiger eingestuft, als die Verhand- Patrick Rehder 13

14 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis lung von Verträgen. Hierzu passt eine Aussage von Traian Kaiser 5, die er auf dem ScrumDay 2011 machte. Sinngemäß: Verträge sind weder produktiv, noch risikominimierend, noch transparent!. Anstatt Geld in Juristen zu investieren, die sich damit beschäftigen was passiert, wenn das Projekt scheitert, könnte das Geld bereits in die Entwicklung fließen und Nutzen für den Kunden generieren. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans Einen Plan zu machen ist sinnvoll. Sich auf den Plan zu beziehen ebenfalls zumindest solange der Plan nicht von der Realität abweicht. Einen veralteten Plan mit Scheuklappen zu verfolgen ist sogar kontraproduktiv. Schließlich wird Zeit investiert um in eine falsche Richtung zu arbeiten, anstatt auf Abweichungen zu reagieren. [16, p. 179] Softwareprojekte unterliegen einer hohen Wahrscheinlichkeit für sich verändernde Bedingungen. Die Tatsache dass Software von und für Menschen entwickelt wird, reicht aus um dies zu verdeutlichen. Menschen können sich irren, Fehler machen, sich falsch verstehen oder ihre Meinung ändern. Der Wert einer Software definiert sich über deren Nutzen für den Kunden. Da die Welt während der Entwicklung nicht still steht, können sich die Anforderungen schnell wieder ändern. Wird nicht auf Veränderungen reagiert, sinkt der Wert der Software. Außerdem werden neue Ideen, Wünsche und Probleme meist erst erkannt, wenn eine Aufgabe im Detail bearbeitet wird. [14, p. 44] Es wird von Software sogar erwartet veränderbar zu sein. Durch Software werden Probleme gelöst, die schwierig zu überblicken sind und sich ändern. Andernfalls würde es sich anbieten die Lösung direkt über Hardware zu realisieren. [9, pp. 9, 10] Die zwölf Prinzipien helfen dabei, die Idee hinter dem Agile Manifest besser zu verstehen. Ins Deutsche übersetzt, lauten sie wie folgt [11]: Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Anforderungsänderungen sind auch spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. 5 Traian Kaiser (XING AG, Director Agile Project Management und PMO) Patrick Rehder 14

15 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Funktionierende Software ist das wichtigste Fortschrittsmaß. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. In regelmäßigen Abständen reflektiert das Team wie es effektiver werden kann und passt sein Verhalten entsprechend an. In der Umfrage Forrester/Dr. Dobb s Global Developer Technographics Survey wurden die Prozesse zur Softwareentwicklung in drei Kategorien unterteilt [2, p. 2]: agile, iterative und phasenorientierte 6 Prozesse. Doch was unterscheidet die agile von der iterativen Softwareentwicklung? Nach der Ausarbeitung dieses Unterkapitels wird der Unterschied klar. Bei der agilen Softwareentwicklung geht es in erster Linie um die im Manifest genannten Werte. Es geht nicht um den Prozess selbst, welcher beim iterativen Vorgehen im Vordergrund steht. 6 In der Studie werden phasenorientierte als Wasserfall-Prozesse bezeichnet, was als nicht so passend empfunden wurde. Patrick Rehder 15

16 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis 2.2. Scrum Die Basis von Scrum liegt in der empirischen Prozesssteuerung. Diese geht davon aus, dass Wissen aus Erfahrung gewonnen wird und dass Entscheidungen aufgrund bekannter Tatsachen getroffen werden. [19, p. 4] Sofern sich Prozesse exakt definieren lassen, werden in der Praxis normalerweise definierte anstelle empirischer Prozesse verwendet. Dies ist allerdings nur möglich, wenn die einzelnen Zwischenschritte vom Prozess anschaulich beschrieben werden können. Ist dies nicht der Fall, ist die Komplexität der Zwischenschritte zu hoch. Als Indikator hierfür kann der Aufwand zur Nachbesserung der Produktqualität genutzt werden. Ist der Aufwand zu hoch, ist eine empirische Prozessteuerung in Betracht zu ziehen. [20, p. 3] In der Massenfertigung stellt sich die Frage: definiert oder empirisch? In der Softwareentwicklung lautet die Antwort klar: empirisch. Der Prozess der Softwareentwicklung weist eine hohe Komplexität auf. Dies wird von Ken Schwaber in Agiles Projektmanagement mit Scrum weiter erläutert, siehe hierzu [20, p. 4]. Der Scrum Guide nennt drei Säulen (siehe Abbildung 3). Auf diese stützt sich die empirische Prozesssteuerung und damit auch Scrum. Transparenz Die wesentlichen Aspekte des Prozesses müssen für diejenigen Personen erkennbar sein, die für das Prozessergebnis verantwortlich sind. Transparenz erfordert, dass diese Aspekte durch einen gemeinsamen Standard definiert sind, so dass Beobachter ein gemeinsames Verständnis über das Beobachtete teilen. Überprüfung Scrum Anwender müssen ständig die Scrum Artefakte und den Fortschritt auf dem Weg zur Erreichung des Ziels überprüfen, um unerwünschte Abweichungen zu entdecken. Die Häufigkeit der Überprüfungen sollte [ ] nicht so hoch sein, dass die eigentliche Arbeit dadurch behindert wird. Der größte Nutzen kann aus einer Überprüfung gezogen werden, wenn sie ständig durch sachkundige Personen am Ort des Geschehens vorgenommen wird. Anpassung Wenn bei einer Überprüfung festgestellt wird, dass einer oder mehrere Aspekte des Prozesses außerhalb akzeptabler Grenzen liegen und das Produktergebnis dadurch ebenfalls nicht zu akzeptieren sein wird, muss so schnell wie möglich eine Anpassung des Prozesses oder des Arbeitsgegenstandes vorgenommen werden, um weitere Abweichungen zu minimieren. Abbildung 3 - Scrum: Die drei Säulen der empirischen Prozesssteuerung [19, p. 4] Es geht bei Scrum darum Transparenz zu schaffen, um das Vorgehen bewerten und anpassen zu können. Ein Kollege hat passend hierzu einen Satz von einem Seminar mitgebracht: Scrum löst deine Probleme nicht von alleine. Es sorgt nur dafür, dass sie sichtbar werden und wehtun. Daran schließt sich folgender Gedanke an: Einsicht ist der erste Schritt zur Besserung. Patrick Rehder 16

17 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Der Scrum Guide enthält eine interessante Beschreibung: Scrum ist ein Framework, dass die Entwicklung komplexer Produkte unterstützt. [19, p. 5] Scrum kann also zur Entwicklung von Produkten genutzt werden. Damit ist es nicht auf die Softwareentwicklung beschränkt. Der Erklärung von Scrum als Begriff bleibt der Scrum Guide jedoch schuldig. Übersetzt bedeutet er Gedränge und zwar im Kontext der Sportart Rugby. Zwei Mannschaften stehen sich in einem kreisförmigen Gebilde [ ] gegenüber und versuchen gemeinschaftlich den Gegner daran zu hindern, Raum zu gewinnen [ ]. [14, p. 10] Die Idee, Rugby metaphorisch zu nutzen, stammt nicht von Ken Schwaber oder Jeff Sutherland 7 selbst, sie entspringt einem Artikel, der die Beiden faszinierte. [21, p. 2] Hirotaka Takeuchi und Ikujiro Nonaka beschrieben in The New New Product Development Game, dass eine hohe Qualität, geringe Kosten und die Abgrenzung zu anderen Produkten alleine nicht ausreichen, um sich auf dem heutigen Markt (1980er) hervorzutun. Es ist ebenfalls nötig schnell und flexibel zu agieren. Der Rugby -Ansatz (auch ganzheitlicher Ansatz genannt) verspricht diese Anforderungen an die Produktentwicklung besser zu erfüllen ein Team versucht gemeinsam als Einheit voranzukommen. [22, pp. 2, 3] Unter der Überschrift Moving the Scrum downfield erläutern sie, welche Eigenschaften der Produktentwicklungsprozess in führenden Unternehmen aufweist. [22, p. 4] Der Begriff Scrum wird in dieser Überschrift das erste Mal erwähnt. Abbildung 4 - Scrum: Der Begriff als Zeichnung [ 7 Ken Schwaber und Jeff Sutherland sind die Schöpfer von Scrum. Patrick Rehder 17

18 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis In den folgenden Unterkapiteln werden die einzelnen Bestandteile vom Scrum Framework erläutert. Da sich einige der betrachteten Begriffe gegenseitig bedingen, soll Tabelle 3 die Orientierung erleichtern: Rollen Seite Ereignisse Seite Artefakte Seite Product Owner 18 Sprint 21 Vision 25 Scrum Master 19 Sprint Planning Sprint Ziel 26 Entwicklungs-Team 19 Grooming 22 Product Backlog 27 Kunde 20 Daily Scrum 23 Sprint Backlog 28 Anwender 20 Sprint Review 23 Impediment Backlog 29 Manager 20 Sprint Retrospektive 24 Releaseplan 29 Definition of Done 29 Produkt-Inkrement 30 Tabelle 3 - Scrum: Register der Bestandteile Rollen Rollen werden im Rahmen von Scrum als Container für Verantwortlichkeiten gesehen. Es ist nicht möglich, in eine Rolle eingesetzt zu werden. Der betroffene Mitarbeiter muss die Rolle freiwillig übernehmen; die Entscheidung liegt bei ihm. Es existiert auch keine Idealbesetzung für eine Rolle durch eine bestimmte Position 8. [14, pp ] Zu den Rollen im Detail: Product Owner, Scrum Master und Entwicklungs-Team sind im offiziellen Scrum Guide [19, pp. 5-8] aufgeführt. Kunde, Anwender und Manager werden zusätzlich von Boris Gloger [14, pp. 14, 15] genannt. Product Owner Der Product Owner (PO) ist verantwortlich für die Eigenschaften und die Wertschöpfung des Produkts. Hierzu erledigt er die folgenden Aufgaben: Er entwickelt die Vision, um alle am Projekt beteiligten Personen anzutreiben und für ein gemeinsames Verständnis zu sorgen. Er vermittelt die Bedeutung und Dringlichkeit des Projekts. Er erstellt, verbessert und entfernt Einträge im Product Backlog gemeinsam mit dem Entwicklungs-Team. Er priorisiert die Einträge im Product Backlog nach dessen Geschäftswert. 8 Position meint in diesem Fall eine Position in einem Unternehmen, wie Abteilungsleiter oder Vorstand. Patrick Rehder 18

19 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Er steht als primärer Ansprechpartner für fachliche Fragen vom Entwicklungs-Team zur Verfügung. Er nimmt die vom Entwicklungs-Team umgesetzten Einträge des Product Backlogs im Sprint Review ab. [14, p. 95] Dies geschieht unter Berücksichtigung der Akzeptanztests und der Definition of Done. Er beendet das Projekt, wenn die Wirtschaftlichkeit nicht mehr gegeben ist. [23, p. 221] Scrum Master Der Scrum Master ist verantwortlich für die korrekte Anwendung von Scrum und der Beseitigung von Impediments (deutsch: Hindernisse). Hierzu erledigt er die folgenden Aufgaben: Er sorgt dafür, dass Scrum von allen Beteiligten verstanden und gelebt wird. Er pflegt das Impediment Backlog und sorgt dafür, dass die darin enthaltenen Impediments gelöst werden. Er unterstützt das Entwicklungs-Team und den Product Owner, im Sinne von fördern, nicht im Sinne von Aufgaben übernehmen. Letzteres soll die Ausnahme bleiben. [14, p. 112] Der Scrum Master lässt sich gut mit einem Trainer vergleichen. Beide schaffen ein ideales Umfeld für ihr Team und sorgen dafür, dass das Team zu Höchstleistungen aufläuft. Entwicklungs-Team Das Entwicklungs-Team ist dafür verantwortlich, dass alle Einträge im Sprint Backlog zum Ende des Sprints fertiggestellt sind. Hierzu werden folgende Aufgaben vom Entwicklungs-Team bewältigt: Das Entwicklungs-Team organisiert sich selbst. Es arbeitet nicht auf Anweisung von Oben. Das Entwicklungs-Team hält täglich ein Daily Scrum ab. Das Entwicklungs-Team schätzt den Arbeitsumfang der Einträge des Product Backlogs. Das Entwicklungs-Team stellt das Sprint Backlog auf Basis der verfügbaren Kapazität 9 zusammen und gibt die Zusage, alle Einträge im kommenden Sprint fertigzustellen. Das Entwicklungs-Team erstellt im Sprint Planning 2 Aufgaben zu den Einträgen im Sprint Backlog. Das Entwicklungs-Team demonstriert die fertiggestellten Einträge des Sprint Backlogs im Sprint Review. Ein Entwicklungs-Team muss interdisziplinär aufgestellt sein. Es müssen alle Kompetenzen und Fertigkeiten zur Bewältigung des Projekts vorhanden sein. Dies ist hinsichtlich der Größe des Entwicklungs-Teams zu berücksichtigen. Das Entwicklungs-Team darf nicht zu klein sein, da dies die Wech- 9 Die Kapazität setzt sich aus der Anzahl der Entwickler und ihrer verfügbaren Zeit zusammen. Bekannte Abwesenheiten, wie Fortbildungen, Urlaub und private Angelegenheiten sind abzurechnen. Patrick Rehder 19

20 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis selwirkungen innerhalb des Teams reduziert; aber auch nicht zu groß, da dies einen erhöhten Koordinationsaufwand bedeutet. Der Scrum Guide nennt drei Personen als Minimum und sieben Personen als Maximum. [19, p. 6] Hinsichtlich ihrer Bezeichnung werden alle Mitglieder des Entwicklungs-Teams als Entwickler bezeichnet. Egal ob sie mehr entwickeln, eher testen oder sich lieber um die Architektur kümmern. [19, p. 6] Kunde Der Kunde ist für die Finanzierung des Projekts verantwortlich. Hierfür verlangt er einen Gegenwert: die zu entwickelnde Software. Der Wert für den Kunden entsteht durch den Nutzen, den die Software erbringt. [14, pp. 118, 119] Es bietet sich meist an, dass die Rolle des Product Owners von einem Kunden besetzt wird. Dies ist jedoch nicht zwingend notwendig. Eine Trennung zwischen Kunde und Product Owner hat den Vorteil, dass der Product Owner damit näher ans Team rückt; er ist schließlich kein Externer. [14, pp. 118, 119] Anwender Die Rolle des Anwenders bringt keine Verantwortung mit sich. Er ist derjenige, der das Produkt benutzen wird. Deswegen stellt er eine wesentliche Informationsquelle dar, die aktiv vom Team abgerufen werden soll. Letztlich soll die zu erstellende Anwendung einen Nutzen für den Kunden generieren. Dieser Nutzen wird jedoch maßgeblich durch den Anwender beeinflusst. Nur wenn die Software vom Anwender ohne Probleme eingesetzt werden kann, kann der beabsichtigte Nutzen generiert werden. [14, pp. 120, 121] Manager Der Manager ist dafür verantwortlich, die idealen Rahmenbedingungen für alle Scrum Teams zu schaffen. Hierzu übernimmt er die folgenden Aufgaben: Er beseitigt die vom Scrum Master aufgezeigten Impediments, da er über die notwendigen Befugnisse verfügt. Er kümmert sich um das Umfeld der Scrum Teams. Beispielsweise ermöglicht er das Bereitstellen von Büroausstattung und Infrastruktur. Er beobachtet die Scrum Teams und nimmt sich Zeit für sie. Da sich das Scrum Team selbst organisiert befürchten viele Manager, dass sie überflüssig werden. Vor allem das mittlere Management hegt diese Ängste. Sie sind jedoch unbegründet. Das mittlere Management kann die Rolle Manager annehmen. Es ist jedoch umzudenken: Aus anweisenden Führungskräften werden unterstützende Führungskräfte. Sie empfangen und verarbeiten Impulse aus den Scrum Teams, anstatt Anweisungen von Oben zu erteilen. [14, pp. 121, 124] Patrick Rehder 20

21 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Ereignisse Für jedes Ereignis wird in Scrum ein Start- und Endzeitpunkt definiert. Das sich ergebende Zeitfenster soll dafür sorgen, dass Besprechungen nicht ausufern und Ereignisse besser in den Tagesablauf eingeplant werden können. Wenn das Zeitfenster nicht ausreicht, muss ein neues vereinbart werden das bestehende Zeitfenster wird nicht einfach verlängert. Dieses Vorgehen wird in Scrum als Timeboxing bezeichnet. Damit keine Zeit von Kollegen verschwendet wird ist außerdem Pünktlichkeit geboten. [19, p. 8], [14, p. 183] Sprint Der Sprint stellt das größte Zeitfenster im Scrum Prozess dar und dient als Container für die Produktentwicklung und kleinere Ereignisse. In der Praxis wird die Länge üblicherweise in Wochen festgelegt. Ein Sprint dauert entweder eine, zwei, drei oder vier Wochen, wobei die Obergrenze von einem Monat durch den Scrum Guide festgelegt wird. [19, p. 8] Die Sprintdauer soll während eines Projekts immer gleich sein, um für Kontinuität und Sicherheit zu sorgen. Aus diesem Grund haben Ereignisse im Sprint auch ihren festen Platz. Ein Sprint beginnt immer mit dem Sprint Planning und endet mit dem Sprint Review und der Retrospektive. Außerdem hält das Entwicklungs-Team an jedem Tag, zur selben Uhrzeit ein Daily Scrum ab. Einzig das Grooming (deutsch: Körperpflege) hat keinen festen Zeitpunkt oder Rhythmus. Außerdem bietet der Sprint den nötigen Raum für eine kontinuierliche Verbesserung. Im Sprint sind die Phasen vom Shewhart Cycle zu erkennen: plan, do, check, act (siehe Tabelle 4). Beim Shewhart Cycle handelt es sich um ein anerkanntes Vorgehen, welches bei mehrfacher Iteration sowohl Prozess, als auch Produkt verbessern kann. Bekannt gemacht wurde der Shewhart Cycle in den 50ern durch Dr. W. Edwards Deming, weswegen er auch unter dem Namen Deming Cycle anzutreffen ist. [14, pp. 48, 49] Sprint Grooming Sprint Planning Produktentwicklung Daily Scrum Sprint Review Sprint Retrospektive Shewhart Cycle plan do check act Tabelle 4 - Scrum: Der Shewhart Cycle im Sprint [14, p. 49] Zeitlich betrachtet steht der größte Teil des Sprints für die eigentliche Produktentwicklung zur Verfügung etwa 80%. In der folgenden Tabelle 5 ist eine Rechnung abgebildet, die auf Basis eines vierwöchigen Sprints, die empfohlenen Zeitfenster je Ereignis darstellt und die verbleibende Zeit zur Produktentwicklung berechnet. Patrick Rehder 21

22 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis 160,00 Stunden (100%) Stunden im Sprint (4 Wochen á 40 Stunden) - 4,00 Stunden (2,5%) Sprint Planning 1-4,00 Stunden (2,5%) Sprint Planning 2-12,00 Stunden (7,5%) Grooming (5-10% je Sprint [14, p. 184]) - 4,75 Stunden ( 3%) Daily Scrums (19 Tage 10 á 15 Minuten) - 4,00 Stunden (2,5%) Sprint Review - 3,00 Stunden ( 2%) Sprint Retrospektive = 128,25 Stunden ( 80%) verbleibende Zeit zur Produktentwicklung Tabelle 5 - Scrum: Zeit zur Produktentwicklung in einem vierwöchigen Sprint [19] Als Ergebnis soll jeder Sprint ein potentiell auslieferbares Produkt-Inkrement liefern. [19, p. 16] Sprint Planning Bevor mit der Entwicklung begonnen werden kann, ist zu bestimmen, was in diesem Sprint zu erledigen ist und wie dies getan werden soll. Hierzu dient das Sprint Planning. Im ersten Teil vom Sprint Planning wird ausschließlich das was betrachtet. Der Product Owner stellt dem Entwicklungs-Team die geordneten [und geschätzten] Einträge des Product Backlogs vor und das gesamte Scrum Team verschafft sich gemeinsam ein Verständnis über die [ ] zu verrichtende Arbeit. [19, p. 10] Danach erfolgt die Auswahl der fertigzustellenden Backlog Items durch das Entwicklungs-Team. Entscheidend sind hierbei Priorität und Arbeitsumfang der Backlog Items. Letzteres steht im Bezug zur Kapazität des Entwicklungs-Teams. In den ersten Sprints muss das Entwicklungs-Team seine Kapazität abschätzen. Später ist es möglich die Auswahl anhand von Erfahrungen der vergangenen Sprints zu treffen. Nach der Auswahl sucht das Scrum Team gemeinsam eine passende Beschreibung für diesen Sprint: das Sprint Ziel. Der zweite Teil dreht sich um das wie. Sprich: Welche Aufgaben sind zu erledigen, um die ausgewählten Backlog Items fertigzustellen. Der Product Owner muss beim Sprint Planning 2 nicht zwingend anwesend sein. Ist er anwesend, können jedoch Fragen des Entwicklungs-Teams direkt geklärt werden. Für beide Planungsrunden gilt: Nicht der Plan, [ ] die Artefakte [oder] die Dokumente [ ] sind der Kern. Am Ende zählt nur das Bild in den Köpfen der Beteiligten. [14, p. 134] Grooming In der Praxis finden sich häufig alternative Bezeichnungen zu Grooming [14, p. 184]: Estimation Meeting Pre-Planning Meeting Release-Planning Meeting 10 Die 19 Tage ergeben sich daraus, dass am Tag des Sprint Plannings kein Daily Scrum durchgeführt wird. Patrick Rehder 22

23 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Aus diesen Begriffen lässt sich schon besser deuten, was sich hinter Grooming verbirgt. Beim Grooming wird das Product Backlog durch den Product Owner und das Entwicklungs-Team gepflegt. Als wichtigster Bestandteil werden die Backlog Items vom Entwicklungs-Team auf ihren Arbeitsumfang geschätzt. Die Schätzung erfolgt relativ in einer imaginären Einheit. Als Referenz dient hierbei ein leicht zu überblickendes Backlog Item. Der Grund für die relative Schätzung liegt darin, dass nur der Umfang des Backlog Items betrachtet werden soll und nicht der Aufwand. Es soll das was und nicht das wie betrachtet werden. Für das Grooming gibt es keine festen Vorgaben, wie oft und wann es in einem Sprint stattfinden muss. Zu Beginn eines Projekts kann es sinnvoll sein, mehrere Termine anzusetzen, da das Product Backlog erfahrungsgemäß einer größeren Veränderung unterliegt. Später kann es genügen, ein Grooming je Sprint durchzuführen. [14, p. 185] Es ist jedoch wichtig, dass das Grooming im Sprint Planning berücksichtigt wird, damit der Sprint weiterhin planbar ist. Daily Scrum Das Daily Scrum dient zur Abstimmung des Entwicklungs-Teams untereinander. Das Daily Scrum wird täglich durchgeführt und dauert nie länger als 15 Minuten. In diesen 15 Minuten muss jeder Entwickler die folgenden drei Fragen möglichst knapp beantworten [14, p. 200], [19, p. 11]: Was habe ich seit dem letzten Daily Scrum erreicht? Was will ich bis zum nächsten Daily Scrum erreichen? Welche Impediments sind dabei im Weg? Wenn Probleme oder Fragen auftauchen, die nicht innerhalb weniger Sekunden besprochen werden können, müssen diese unabhängig vom Daily Scrum geklärt werden. Sprint Review Im Sprint Review demonstriert das Entwicklungs-Team die fertiggestellten Backlog Items. Die Vorbereitung hierfür soll möglichst gering ausfallen. Zur Orientierung nennt Ken Schwaber den maximalen Zeitraum einer Stunde [24, p. Appendix A]. Dies ist eine realistische Obergrenze, denn die Entwickler müssen lediglich festlegen, in welcher Reihenfolge welcher Entwickler welches Backlog Item vorstellt. Außerdem werden nur abgeschlossene Backlog Items präsentiert. Der Geschäftswert eines Backlog Items ergibt sich ausschließlich aus der vollständig brauchbaren Funktion. [14, p. 209] Um die Funktion darzustellen, wird das aktuelle Produkt-Inkrement genutzt. Beim Sprint Review soll sich herausstellen, was funktioniert und was nicht dies ist im Sinne der Transparenz. Nach der Demonstration entscheidet der Product Owner ob ein Backlog Item als fertiggestellt gilt oder nicht. Die Vorführung ist aber nicht nur für den Product Owner interessant. Sie kann von allen Interessenten dazu genutzt werden, sich über den aktuellen Stand des Projekts zu informieren. Außerdem sollen alle relevanten Interessenvertreter (Product Owner, Kunde, Anwender) über ihre Eindrücke berichten, um daraus neue Einträge im Product Backlog zu gewinnen oder vorhandene zu aktualisieren. Patrick Rehder 23

24 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Sprint Retrospektive Die Idee der Retrospektive bringt Holger Koschek gut auf den Punkt: Sie ist der Schlüssel zur Prozessverbesserung, gibt die Teamstimmung wieder [ ] [und] deckt Motivationsprobleme auf. Wer auf die Retrospektive verzichtet, [ ] verzichtet auf die Möglichkeit sich kontinuierlich zu verbessern und sein Projektvorgehen an veränderte Bedingungen anzupassen. [10, p. 25] Jeder Sprint endet mit einer Retrospektive einem Rückblick 11. In diesem Ereignis beantwortet das Scrum Team die folgenden Fragen im Hinblick auf den vergangenen Sprint [23, pp ]: Welche wichtigen Ereignisse gab es? Was lief gut? Was kann verbessert werden? Die erste Frage dient dazu, sich den Sprint anhand wichtiger Ereignisse wieder ins Gedächtnis zu rufen. Durch die zweite Frage werden gute Ereignisse und Abläufe aufgezeigt und damit bewusst vom Team wahrgenommen. Der letzte Punkt enthält den eigentlichen Kern der Retrospektive: das Finden von Möglichkeiten zum Verbessern. Boris Gloger nennt einen Sechs-Punkte-Ablauf, der seiner Meinung nach den gelungenen Ablauf einer Retrospektive garantiert [14, pp ]: 1. Sicherheit schaffen 2. Fakten sammeln 3. Funktionierende Prozesse finden 4. Nicht funktionierende Prozesse finden 5. Kompetenz zur Veränderung bestimmen 6. Priorisierung Zum 1. Schritt: Jeder Teilnehmer soll im Rahmen einer Retrospektive frei und offen reden können, ohne dass ihm daraus ein Nachteil entsteht. Durch die explizite Abhandlung dieses Schritts steigt die Wahrscheinlichkeit, dass alle Mitglieder des Scrum Teams ihre wahre Meinung kundtun. Es gilt: Jede Meinung ist willkommen und bereichert die Retrospektive. Die Schritte zwei bis vier beantworten schlicht die oben genannten Fragen. Nachdem die Probleme im vierten Schritt identifiziert wurden, geht es im fünften Schritt darum, die Probleme in zwei Listen einzuteilen. Als Kriterium gilt, ob das jeweilige Problem vom Team behandelt werden kann oder nicht. Der letzte Schritt wird vom Team dazu genutzt, die Probleme je Liste zu priorisieren. 11 Retrospektive (lat. retrospectare zurückblicken ) [wikipedia.org] Patrick Rehder 24

25 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Die Retrospektive wird nicht dazu genutzt Maßnahmen zu bestimmen. Dies wird im anschließenden Sprint Planning gemacht. Nur so besteht die Möglichkeit Maßnahmen direkt einplanen zu können. [25, p. 21] Artefakte Alle vom Scrum Team erzeugten Resultate werden als Artefakt bezeichnet. Die Übersicht in Tabelle 6 zeigt, dass je Quellen unterschiedlich viele Artefakte genannt werden: Scrum Guide [19, pp ] Boris Gloger [14, pp. 16, 17] wibas Scrum Browser [26] Produkt Backlog Product Backlog Product Backlog Sprint Backlog Sprint Backlog Sprint Backlog Inkrement Das Produkt-Inkrement Increment Vision Product Backlog Item Sprint Goal Sprint Goal Selected Product Backlog Die Aufgaben Der Releaseplan Das Impediment Backlog Definition of Done Tabelle 6 - Scrum: Übersicht möglicher Artefakte Im Folgenden erläutert werden: Product Backlog, Sprint Backlog, Produkt-Inkrement, Vision, Sprint Ziel, Releaseplan, Impediment Backlog und Definition of Done. Drei von Boris Gloger genannte Artefakte werden nicht als eigenständiges Artefakt betrachtet. Die Product Backlog Items sind Bestandteil vom Product Backlog und die Aufgaben sind Bestandteil vom Sprint Backlog; diese werden im Rahmen ihres Elternelements betrachtet. Das Zwischenprodukt zwischen dem ersten und zweiten Teil vom Sprint Planning wird als Selected Product Backlog bezeichnet. Damit handelt es sich um eine spezielle Bezeichnung vom Sprint Backlog zu einem bestimmten Zeitpunkt, was nicht als eigenständiges Artefakt anzusehen ist. Vision Wenn Du ein Schiff bauen willst, dann trommle nicht Männer zusammen um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre sie die Sehnsucht nach dem weiten, endlosen Meer. Antoine de Saint-Exupéry ( ), französischer Flieger und Schriftsteller Ein Scrum Projekt beginnt mit einer Vision. Sie gibt dem Projekt einen Sinn und definiert das gemeinsame Ziel. [24] Die Vision muss möglichst präzise und klar sein, damit sie leicht aufgenommen wird und in Erinnerung bleibt. Sie soll aber nicht beschreiben, wie das Ziel zu erreichen ist. Dies würde den Raum der Lösungsmöglichkeiten unnötig einschränken. [14, p. 141] Die Vision wird vom Product Owner entwickelt und kommuniziert. Patrick Rehder 25

26 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Eine Vision zu entwickeln und zu präzisieren ist keine leichte Aufgabe. Zur Orientierung kann beispielsweise das von Jim Highsmith entwickelte Schema genutzt werden [14, p. 143] [27]: Für <Welche Kunden?> die <Welches Bedürfnis haben die Kunden?> ist <Wie soll das Produkt heißen?> eine <Welcher Produktkategorie gehört es an?> die <Welchen besonderen Nutzen bringt das Produkt?> anders als <Welche Alternative gibt es auf dem Markt?> unser Produkt <Welches Alleinstellungsmerkmal hat unser Produkt zur Alternative?> Hier beispielhaft ausgefüllt: Für Besitzer eines Smartphones mit Android die ihre Daten schützen wollen ist FileSafe eine App die ein bestimmtes Verzeichnis verschlüsselt anders als Encrypt/Decrypt wird unser Produkt über Werbung finanziert, nicht über einen Kaufpreis. Sprint Ziel Mit dem Sprint Ziel setzt sich das Scrum Team in jedem Sprint eine schwierige, aber durchführbare Aufgabe. Es bietet dem Scrum Team die Möglichkeit, sich gemeinsam auf etwas zu konzentrieren. So steht das zu erreichende Ziel im Raum und nicht die zu erledigenden Aufgaben. Außerdem sorgen leichter Druck und eine echte Herausforderung für mehr Leistung im Scrum Team, dies zeigt die Kreativitätsforschung, wie Boris Gloger anführt. [14, p. 188] Unabhängig von Scrum sind gute Ziele SMART; so auch die Sprint Ziele [14, p. 189] [28, p. 120]: Spezifisch (Ist das Ziel verständlich und nicht zu allgemein?) Messbar (Kann der Erfolg des Ziels gemessen werden?) Akzeptiert (Hat das Ziel einen Sinn, eine Bedeutung?) Realistisch (Ist das Ziel überhaupt erreichbar?) Terminiert (Hat das Ziel einen zeitlichen Rahmen?) Das Sprint Ziel wird im Sprint Planning 1 zwischen Product Owner und Entwicklungs-Team auf Basis der ausgewählten Backlog Items vereinbart. Patrick Rehder 26

27 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Product Backlog Das Product Backlog beschreibt was entwickelt werden soll. Die gewünschten Eigenschaften, Erweiterungen, Funktionen und Merkmale des Produkts werden in Form von Backlog Items erfasst. [26] Ein Product Backlog Item verfügt hierzu über die folgenden Attribute [19, p. 14]: Beschreibung Priorität (durch den Product Owner festgelegt) Arbeitsumfang (durch das Entwicklungs-Team geschätzt) Für die Beschreibung von Backlog Items können zum Beispiel User Stories genutzt werden [29]: Als <Benutzerrolle> will ich <das Ziel>[, so dass <Grund für das Ziel>]. Hier beispielhaft ausgefüllt: Als Kunde will ich mich anmelden können. Als Kunde will ich mich anmelden können, so dass ich meine bisherigen Bestellungen einsehen kann. Die Form des Product Backlogs ist nicht entscheidend und wird nicht vorgegeben. Im Kapitel Rollen wurde bereits erwähnt, dass der Product Owner auf Basis des Geschäftswerts die Priorität der Backlog Items festlegt. Ein Backlog Item, dass nach der Umsetzung einen großen Geschäftswert liefert, ist zu bevorzugen. Hierdurch ergibt sich ein optimales Kosten-Nutzen- Verhältnis. Da es in der Praxis oft Missverständnisse zum Product Backlog gibt, führt Boris Gloger fünf Punkte auf, die nicht auf ein Product Backlog zutreffen [14, pp. 146, 147]: Das Product Backlog besteht nicht aus Anforderungen. Das IEEE definiert Anforderung wie folgt: Eine Anforderung ist: (1) Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. (2) Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente erfüllen. (3) Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß (1) oder (2). [30, p. 11] Ein Backlog Item als Anforderung zu bezeichnen, ist nicht falsch. Der Inhalt eines Backlog Items wird durch Punkt (1) beschrieben und die schriftliche Repräsentation über Punkt (3). Boris Gloger meint an dieser Stelle, dass ein Backlog Item nicht beschreiben darf, wie etwas umzusetzen ist: Auf der Produkt-Katalog-Hauptseite gibt es ein Displayfeld für den Preis. Was er als Patrick Rehder 27

28 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis klassische Anforderung bezeichnet. Es muss wie folgt heißen: Als Kunde kann ich den Preis eines Buches einfach erkennen, so dass ich entscheiden kann, ob ich das Buch kaufe. [14, p. 146] Das Product Backlog ist keine Spezifikation eines Produktes. Eine Spezifikation ist sehr detailliert. Dies geht aus der Definition von Cynthia Stackpole im Rahmen der Projektmanagementmethode PMBOK hervor: Specification. A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system, component, product, result, or service and, often, the procedures for determining whether these provisions have been satisfied. [ ] [31, p. 794] Ein Product Backlog soll diesen Detailgrad nicht erreichen. Es soll vor allem als Gedächtnisstütze dienen und Diskussionen provozieren. Das Product Backlog ist nie vollständig. Der Satz findet sich im Scrum Guide nahezu wörtlich: Ein Product Backlog ist niemals vollständig. [19, p. 14] Mit nie vollständig ist gemeint, dass das Product Backlog nie fertig ist. Es ist immer möglich neue Backlog Items aufzunehmen und vorhandene Backlog Items anzupassen oder zu verwerfen. Das Product Backlog wird nicht alleine vom Product Owner geschrieben. Der Product Owner ist für die Pflege des Product Backlogs verantwortlich. Er muss sie jedoch nicht selber durchführen. Den Arbeitsumfang eines Backlog Items einzuschätzen ist ihm sogar untersagt, da er nicht über die notwendige Kompetenz verfügt. Es ist von daher möglich, dass das Entwicklungs-Team dem Product Owner dabei hilft, die Ideen in Form von Backlog Items zu erfassen. Es gibt keine technischen Product Backlogs. Eine der wichtigsten Eigenschaften von Product Backlog Items ist es, dass sie einen Geschäftswert liefern. Bei fachlichen Funktionen ist dies der Fall; bei rein technischen in der Regel nicht. Ein Refactoring kann beispielsweise den Aufwand für andere Aufgaben reduzieren. Es liefert aber für sich gesehen keinen Nutzen für den Kunden. Vielmehr müsste das Refactoring, als Teil der Aufgaben gesehen werden, die hierdurch schneller umgesetzt werden kann. Sprint Backlog Das Sprint Backlog besteht aus den im Sprint Planning 1 ausgewählten Backlog Items und den zugehörigen im Sprint Planning 2 definierten Aufgaben. Damit stellt das Sprint Backlog die Grundlage für die Entwicklung innerhalb des Sprints dar. Das Entwicklungs-Team bedient sich an den Aufgaben und arbeitet diese über den Sprint ab. Patrick Rehder 28

29 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Impediment Backlog Das Impediment Backlog wird vom Scrum Master gepflegt und enthält alle Impediments die im Laufe des Projekts identifiziert wurden und den Projektverlauf stören. Insbesondere das Daily Scrum und die Sprint Retrospektive sind Ereignisse in denen Impediments benannt, beziehungsweise aufgedeckt werden. Für die Struktur eines Impediment Backlogs nennt Holger Koschek 12 die folgenden vier Spalten [23, p. 161]: Bezeichnung vom Impediment Wer kann das Impediment beseitigen? (Scrum Master, Scrum Team oder Andere) Wann wurde das Impediment bekannt? Wann wurde das Impediment gelöst? Die Form ist nicht vorgegeben. Dem Scrum Master stehen alle Möglichkeiten offen. Releaseplan Der Releaseplan ergibt sich aus drei Faktoren [14, p. 130]: Reihenfolge der Backlog Items auf Basis der Priorität geschätzter Arbeitsumfang der Backlog Items Kapazität 13 des Entwicklungs-Teams Aus diesen Faktoren kann errechnet werden, welche Funktionalität voraussichtlich in welchem Sprint fertiggestellt wird. Der Ausblick erfolgt auf Basis des derzeitigen Wissens und muss nach jeder Änderung der Faktoren neu berechnet werden. Hierbei wird der Releaseplan jedes Mal etwas genauer. Der Arbeitsumfang von Backlog Items wurde auf Basis neuer Erkenntnisse noch einmal neu geschätzt oder die Kapazität des Entwicklungs-Teams wurde nach einem Sprint aktualisiert. Die Pflege obliegt dem Product Owner. Er hat schließlich ein Interesse daran zu wissen, welche Funktionen in einem Release enthalten sein werden. Bei einem Release stellt der Product Owner dem Kunden das aktuelle Produkt-Inkrement zur Verfügung. [26] Definition of Done Die Definition of Done soll für ein gemeinsames Verständnis im Scrum Team sorgen, wann ein Backlog Item fertig ist. Für das Produkt bedeutet dies, dass die durch fertige Backlog Items geforderten Funktionen uneingeschränkt zur Verfügung stehen müssen. Das gemeinsame Verständnis ist insbesondere für die Kommunikation zwischen Entwicklungs-Team und Product Owner wichtig. Schließlich nimmt der Product Owner die Backlog Items im Sprint 12 Holger Koschek arbeitet als Berater und Coach für agile Vorgehensweisen bei der Holisticon AG. [23, p. ii] 13 Anmerkung: Die Kapazität wird bei Scrum in Form der Velocity (deutsch: Geschwindigkeit) erfasst. Patrick Rehder 29

30 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Review ab. Dem Entwicklungs-Team muss folglich bewusst sein, was der Product Owner verlangt. Außerdem hilft die Definition of Done dem Entwicklungs-Team beim Schätzen der Backlog Items. Sie gibt an, was bei der Entwicklung bedacht werden muss und damit auch was den Arbeitsumfang des Backlog Items beeinflusst. [19, p. 16] Die Definition of Done enthält die nicht-funktionalen Anforderungen 14. [26] Bei einem frischen Scrum Team wird der Umfang der Definition geringer ausfallen, als bei einem erfahrenen Scrum Team. Gemäß dem Prinzip der Verbesserung wird die Definition of Done über die Zeit ausgebaut und damit für eine Qualitätssteigerung gesorgt. [19, p. 17] Produkt-Inkrement Der fertige Teil eines Produkts wird bei Scrum als Produkt-Inkrement bezeichnet. Es setzt sich aus den Funktionen aller fertiggestellten Backlog Items unter Berücksichtigung der Definition of Done zusammen. Das Produkt-Inkrement muss zum Ende jedes Sprints in einem einsatzfähigen Zustand sein, so dass der Product Owner es ohne weitere Anpassungen an den Kunden ausliefern kann auch wenn die Auslieferung tatsächlich nicht nach jedem Sprint erfolgt. [19, p. 16] 14 Eine ausführliche Erläuterung zu nicht-funktionalen Anforderungen befindet sich im ISO/IEC 25010:2011. Patrick Rehder 30

31 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Das Zusammenspiel Nachdem die einzelnen Bestandteile betrachtet wurden, wird der Ablauf im Gesamten anhand des Artikels The Scrum Framework in 30 Seconds skizziert [32]: 1. Der Product Owner entwickelt eine Vision vom zu entwickelnden Produkt. 2. Der Product Owner erstellt mit dem Entwicklungs-Team eine Liste der gewünschten Funktionen: das Product Backlog. 3. Die einzelnen Einträge werden vom Entwicklungs-Team auf ihren Umfang geschätzt und durch den Product Owner über ihren Geschäftswert priorisiert. 4. Im ersten Teil des Sprint Plannings wählt das Entwicklungsteam die wichtigsten Einträge aus dem Product Backlog aus und erstellt damit das Sprint Backlog. 5. Im zweiten Teil des Sprint Plannings entscheidet das Entwicklungs-Team über die Umsetzung der Einträge des Sprint Backlogs und zerteilt diese hierzu in kleine Aufgaben. 6. Die gefundenen Aufgaben werden in einem definierten Zeitraum (ein bis vier Wochen) abgearbeitet: dem Sprint. 7. Jeden Tag informiert sich das Entwicklungs-Team gegenseitig im Daily Scrum über den Fortschritt und aufgetretene Probleme. 8. Die Pflege des Product Backlogs erfolgt während des Sprints im sogenannten Grooming. 9. Die Entwicklung endet mit dem Sprint Review, hier werden die fertiggestellten Einträge des Sprint Backlogs am Produkt-Inkrement vorgestellt. Die umgesetzten Funktionen müssen ohne Anpassungen produktiv eingesetzt werden können. 10. Der Sprint endet mit einer Retrospektive. Diese wird vom Scrum Team dazu genutzt den vergangenen Sprint zu reflektieren und primär Maßnahmen zur Steigerung der Produktivität zu finden. 11. Es beginnt ein neuer Sprint (siehe Schritt 4). Dieser Kreis wird solange wiederholt bis das Kosten-Nutzen-Verhältnis kippt. Dies ist der Fall, wenn der zu erwartende Geschäftswert die Entwicklung nicht mehr rechtfertigt. Es existieren viele Grafiken zu Scrum, die den Ablauf übersichtlich darstellen. Insbesondere der wibas Scrum Browser ist zu nennen. Er bietet sowohl einen schnellen Überblick, als auch detaillierte Informationen zu den Rollen, Ereignissen und Artefakten von Scrum. Aufgrund der gelungen Übersicht wird auf eine Grafik verzichtet und auf den wibas Scrum Browser verwiesen: Patrick Rehder 31

32 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis 2.3. Feature Driven Development Feature Driven Development (FDD) ging aus einem gescheiterten Projekt für eine Bank hervor. Eine externe, namhafte Firma war mit diesem Projekt betraut. Sie konzipierte über zwei Jahre und kam letztlich zu dem Ergebnis, dass das Projekt nicht durchführbar sei. Zu diesem Zeitpunkt waren rund dreieinhalbtausend Seiten mit Modellen der zukünftigen Software entstanden, aber noch keine einzige Zeile Quelltext. Für den zweiten Versuch entwickelten Jeff De Luca und Peter Coad einen neuen Prozess, der später als Feature Driven Development bekannt wurde. Sie stellten das Projekt fertig: pünktlich und signifikant unter dem festgelegten Budget ein glänzender Erfolg. [33, p. 1], [13, p. 150] Im Zuge dieses Erfolgs wurde Jeff De Luca von John Gage (Sun Microsystems) gebeten, das in der Praxis entwickelte Verfahren aufzuschreiben. [13, p. 149] Im Jahr 1999 erschien das Buch Java Modeling in Color with UML. Dessen letztes Kapitel die Überschrift Feature-Driven Development [34] trägt. Ansonsten ist die Fülle an Literatur verglichen mit Scrum jedoch gering. Auch die Community ( macht einen verschlafenen Eindruck. Die letzten offiziellen Beiträge wurden 2008 erstellt, einzig die Liste der Zertifizierten wird aktuell gehalten. (Stand: April, 2012) Laut Jeff De Luca zeichnet sich Feature Driven Development dadurch aus, dass es die Bedürfnisse aller am Entwicklungsprozess Beteiligten berücksichtig. Alle Entwickler werden mit den Aufgabenfeldern Analyse, Design und Implementierung betraut. Aufgrund von kurzen Iterationen stellen sie häufig etwas fertig und werden dadurch regelmäßig mit neuen Aufgaben 15 betraut. Manager erhalten Methoden zum Planen, Überwachen und Berichten vom Projektstatus. Außerdem wirkt das regelmäßige Fertigstellen von Programmteilen risikominimierend. Kunden und Anwender erhalten früh greifbare Ergebnisse und können sich darauf beziehen. [34, pp. 183, 184] [8, pp. xix, xxii] Zusammenfassend werden Feature Driven Development folgende Eigenschaften zugesprochen [8, p. xxii]: Das Vorgehen erfolgt iterativ, in kleinen Zyklen. In jedem der fünf Prozesse 16 wird betont auf Qualität geachtet. Greifbare Ergebnisse werden regelmäßig erarbeitet. Der Projektstatus und -fortschritt wird klar und mit möglichst wenig Aufwand dargestellt. Die Begriffe der Bestandteile von Feature Driven Development sind der aktuellen Prozessbeschreibung [35] entnommen. Einzig der Chief Modeler bildet eine Ausnahme, dies wird später erläutert. Um die Orientierung zu erleichtern, wird in Tabelle 7 ein Überblick über die Begriffe von Feature Driven Development gegeben. 15 Developers love new things. [34, p. 183] 16 Feature Driven Development besteht aus fünf Unterprozessen, diese werden in Kapitel erläutert. Patrick Rehder 32

33 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Rollen Seite Prozesse Seite Project Manager 33 Develop an Overall Model 36 Domain Expert 33 Build a Features List 37 Chief Modeler 34 Plan by Feature 38 Development Manager 34 Design by Feature 39 Chief Programmer 34 Build by Feature 40 Class Owner 35 Tabelle 7 - FDD: Register der Bestandteile Rollen Feature Driven Development verfügt über sechs Schlüsselrollen: Project Manager, Domain Expert, Chief Modeler, Development Manager, Chief Programmer und Class Owner. Im Buch A Practical Guide to Feature-Driven Development werden noch neun weitere Rollen genannt. Diese werden aufgrund des Umfangs nicht in dieser Arbeit erläutert. [8, pp ] Die Übernahme einer Rolle ist nicht auf eine Person beschränkt. Es ist sowohl möglich dass eine Person mehrere Rollen einnimmt, als auch dass eine Rolle von mehreren Personen übernommen wird. Dies ist je nach Größe des Projekts und den damit einhergehenden Anforderungen an die Rolle zu überlegen. [8, p. 29] Project Manager Der Project Manager ist dafür verantwortlich den Fortschritt darzustellen, die Kosten zu beobachten, benötigte Ressourcen bereitzustellen und sich um das Projektteam zu kümmern. Er erkennt, beseitigt und verhindert Störungen, die auf das Projekt einwirken. Der Project Manager soll seine Aufgabe im Sinne eines Service verstehen. Er stellt seinem Projektteam eine ideale Umgebung zur Verfügung und sorgt dafür, dass das Projektteam effizient arbeiten kann. [8, p. 28] Domain Expert Der Domain Expert benötigt ein fundiertes Verständnis vom Fachgebiet, als auch die nötigen Fähigkeiten dieses Wissen anderen Menschen verständlich zu machen. Ist eine dieser Voraussetzungen nicht gegeben, ist der Erfolg des Projekts gefährdet. In diesem Fall geht der Domain Expert entweder von falschen Anforderungen aus oder die Entwickler verstehen ihn nicht richtig. Außerdem muss der Domain Expert im neuen Softwaresystem eine Verbesserung zur jetzigen Situation sehen. Wenn von fachlicher Seite kein Mehrwert zu erkennen ist, sollte das System auch nicht entwickelt werden. Letztlich muss der Domain Expert wissen, was sinnvoll ist und was nicht. Dies trifft auch auf den Detailgrad der Anforderungen zu. Bei Feature Driven Development werden die Anforderungen zu Beginn nicht bis ins kleinste Detail erfasst. Die Anforderungen werden über die Laufzeit des Projekts immer weiter verfeinert. Dies wiederum erfordert, dass der Domain Expert erreichbar ist. [13, p. 154] [8, p. 30] Patrick Rehder 33

34 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Chief Modeler In einem Interview (2007) sagte Jeff De Luca, dass er mit der Bezeichnung Chief Architect nicht mehr zufrieden sei. Er nennt die Rolle nun Chief Modeler und begründet dies damit, dass die Rolle unter dem alten Titel zu hoch gehandelt wurde. Der Chief Modeler soll die Domain Experts und Chief Programmer auf Basis seiner Erfahrung anleiten und zusammenbringen und nicht das Design in Eigenregie entwickeln. [33, p. 4] Der Chief Modeler ist dafür verantwortlich, dass ein in sich schlüssiges Overall Design erstellt wird. Um dies zu gewährleisten benötigt er ein exzellentes technisches Verständnis, viel Erfahrung im Modellieren und ausgeprägte zwischenmenschliche Fähigkeiten. Mit diesen Eigenschaften organisiert und moderiert er die Treffen der Domain Experts und Chief Programmer, in denen gemeinsam das Overall Design entwickelt wird. Bei Meinungsverschiedenheiten stellt er die letzte Instanz dar. [8, pp. 28, 29] Feature Driven Development ist in fünf Prozesse unterteilt. Da das Overall Design bereits im ersten Prozess entwickelt wird, wird die Rolle des Chief Modelers nur in diesem Prozess benötigt. [35, pp. 1, 2] Development Manager Der Development Manager ist für die störungsfreie Arbeit der Chief Programmer untereinander verantwortlich. Sofern sich Konflikte zwischen Chief Programmern nicht direkt lösen lassen, muss der Development Manager einschreiten und eine Lösung herbeiführen. In kleineren Projekten bietet es sich an, die Rolle des Development Managers mit dem Chief Modeler oder dem Project Manager zu kombinieren. [8, p. 29] Chief Programmer Ein Chief Programmer ist an allen Prozessen von Feature Driven Development beteiligt. Hierbei muss er sich stets mit den anderen Chief Programmern abstimmen. Begonnen wird mit dem Overall Design, das die Chief Programmer zusammen mit den Domain Experts unter Leitung des Chief Modelers entwickeln. Danach bestimmen die Chief Programmer die benötigten Funktionen in Form von Features und verteilen diese untereinander. Die Features werden nicht direkt durch die Chief Programmer umgesetzt. Sie bilden hierzu Feature Teams, welche das Design im Detail und die Implementierung übernehmen. [8, p. 29] Gemäß Brooks Gesetz sorgt der Einsatz zusätzlicher Entwickler für eine Verlangsamung: Adding manpower to a late software project makes it later. [36, p. 25] Jeff De Luca unterstützt diese Aussage, sagt aber auch, dass es eine Ausnahme gibt. Mit leichtgewichtigen Prozessen, die Funktionalität möglichst klein und auf den Kundennutzen bezogen betrachten, ist es möglich weitere Entwickler zum Projekt hinzuzuziehen und dadurch eine Steigerung der Geschwindigkeit zu erreichen. Durch weitere Chief Programmer, können weitere Feature Teams gebildet werden, die Features parallel zu den bestehenden Feature Teams umsetzen. Diese Skalierung ist nicht beliebig möglich, da Features auch in Abhängigkeit zueinander stehen können. [34, p. 196] Patrick Rehder 34

35 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Class Owner Über die Rolle des Class Owners, übernimmt ein Entwickler die Verantwortung für eine oder mehrere Klassen. Er ist derjenige, der alle seine Klassen betreffenden Arbeiten durchführt. Dieses Prinzip wird als Class Ownership bezeichnet; eine Klasse gehört einem Entwickler. Feature Driven Development grenzt sich in diesem Punkt von Scrum und Extreme Programming ab. Letztere nutzen das gegenteilige Prinzip Collective Ownership. Die Vorteile von Class Ownership und Collective Ownership sind in Tabelle 8 gegenübergestellt. Vorteile der Class Ownership Der Verantwortliche für eine Klasse kennt sich in dieser sehr gut aus. Hierdurch kann er schnell Anpassungen vornehmen oder Auskunft über die Funktionsweise geben ohne sich erst einarbeiten zu müssen. Da eine Klasse nur von einem Entwickler bearbeitet wird, kann es nicht zu Versionskonflikten 17 kommen. Die Klassen eines Entwicklers weisen einen einheitlichen Schreibstil auf. Dies sorgt für eine bessere Lesbarkeit der Klassen. Durch die Kombination aus Verantwortung und Ehrgeiz kann ein Entwickler dazu motiviert werden, seine Klassen möglichst effizient zu gestalten. Da Entwickler nur ihre Klassen bearbeiten, kann es nicht dazu kommen, dass ein Entwickler durch das Ändern einer fremden Klasse, einen Fehler verursacht. Vorteile der Collective Ownership Der Sinn, Aufbau und die Funktionsweise einer Klasse ist mehreren Entwicklern bekannt. Die Abwesenheit eines Entwicklers kann somit besser vom Team aufgefangen werden. Die Verteilung von Aufgaben gestaltet sich einfacher, da die Aufgaben nicht noch weiter auf einzelne Klassenbesitzer aufgeteilt werden müssen. Die Auslastung der Entwickler ist einfacher zu gewährleisten, da nicht nur bestimmte Entwickler Änderungen durchführen dürfen. Da die Verantwortung für den Quelltext im Team liegt, wird die Schuld im Falle eines Fehlers vom gesamten Team übernommen. Fehler werden mit einer höheren Wahrscheinlichkeit entdeckt, da der Quelltext durch andere Entwickler angesehen werden muss. Tabelle 8 - FDD: Die jeweiligen Vorteile von Class Ownership und Collective Ownership Sofern die Klasse eines Class Owners für die Umsetzung eines Features benötigt wird, wird der Class Owner temporär zu einem Feature Team hinzugefügt. Das Feature Team besteht aus allen Class Ownern, die zur Umsetzung eines Features benötigt werden. Das Feature wird in Gänze durch das Feature Team bearbeitet: es wird analysiert, entworfen, entwickelt, getestet und dokumentiert. [33, p. 5] [13, p. 155] [34, p. 196] [8, pp. 29, 30] [37, pp. 9-11] 17 Versionskonflikte: Eine Datei wird parallel von mehreren Personen verändert, so dass die Änderungen nachträglich zusammengeführt werden müssen. Patrick Rehder 35

36 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Prozesse Feature Driven Development besteht aus fünf Prozessen [35]: Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature und Build by Feature. Die Anordnung der Prozesse wird in Abbildung 5 dargestellt. Vor allem die Prozesse #4 und #5 fallen auf. Sie machen zusammen über Dreiviertel der Zeit aus und werden mindestens alle zwei Wochen erneut durchlaufen. Was auf den ersten Blick nicht aus der Grafik hervorgeht ist, dass die fünf Prozesse insgesamt auch erneut durchlaufen werden. Ein solcher Durchlauf darf maximal sechs Monate in Anspruch nehmen, danach muss eine Iteration erfolgen. [6, p. 19] Die Grafik liefert einen Hinweis darauf: Es wird zwischen initialem und fortlaufendem Anteil unterschieden wird. Abbildung 5 - FDD: Prozessübersicht mit zeitlicher Verteilung [34, p. 198] Die fünf Prozesse werden auf Basis der aktuellsten Prozessbeschreibung [35] erläutert: Develop an Overall Model Im Prozess #1 wird das Overall Model des zu entwickelnden Systems erstellt. Hierzu resultiert der Prozess in folgenden Ergebnissen: Die zentralen Klassen sind identifiziert und werden durch ein UML Klassendiagramm in Verbindung gebracht. Komplexe, fachliche Abläufe werden über UML Sequenzdiagramme abgebildet. Notizen zu getroffenen Entscheidungen reichern die Diagramme an. Der Detailgrad ist im Prozess #1 gering zu halten. Sonst besteht die Gefahr, dass sich während der Modellierung in Detailfragen verloren wird. Diese Fragen werden in den Prozessen #4 und #5 beantwortet. In der Prozessbeschreibung werden die folgenden Schritte genannt: 1. Der Project Manager stellt das Modeling Team aus Chief Programmern, Domain Experts und einem Chief Modeler zusammen. Patrick Rehder 36

37 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis 2. Ein Domain Expert gibt einen Überblick über das Fachgebiet. Das Modeling Team sichtet vorhandene Dokumente, wie beispielsweise Datenmodelle, Anforderungsbeschreibungen oder Richtlinien. Das Modeling Team teilt sich in kleine Gruppen auf, die maximal drei Personen umfassen. Jede dieser Gruppen entwickelt ein mögliches Modell für das Fachgebiet. Die Ergebnisse der einzelnen Gruppen werden anschließend dem gesamten Modeling Team vorgestellt. Für diesen Schritt kann es hilfreich sein, wenn der Chief Modeler zuvor ein Schema vorgibt. Dies sorgt für vergleichbare Ergebnisse, schränkt aber zugleich den Lösungsraum ein. 3. Nun verständigt sich das gesamte Modeling Team unter Moderation vom Chief Modeler auf ein gemeinsames Overall Model. Dieses kann entweder von einer Gruppe übernommen werden, eine Mischung aus verschiedenen Modellen darstellen oder auch ein neues Modell sein. 4. Die Schritte 3 und 4 werden mehrfach durchlaufen und das Overall Model bei jedem Durchlauf weiter verfeinert. Der Chief Modeler beendet diese Schleife, wenn er mit dem Ergebnis zufrieden ist. [8, p. 133] Während des gesamten Prozesses werden signifikante Entscheidungen schriftlich fixiert. Es wird notiert, warum sich für etwas entschieden wurde als auch betrachtete andere Lösungen. Hierdurch wird gewährleistet, dass die getroffenen Entscheidungen später nachvollzogen werden können. Die Überprüfung der Ergebnisse erfolgt durch die Domain Experts. Diese können anhand des entwickelten Overall Models und den geführten Gesprächen erkennen, ob ihre Anforderungen richtig verstanden wurden. Außerdem besteht die Möglichkeit den Kontakt mit der Fachabteilung zu suchen. Build a Features List Der Prozess #2 besteht aus den folgenden Schritten: 1. Der Project Manager stellt mithilfe vom Chief Modeler und dem Development Manager das Features List Team zusammen. Das Features List Team besteht aus den Chief Programmern, die am Prozess #1 teilgenommen haben. Domain Experts können ebenfalls beteiligt sein. Meist gehören sie jedoch nicht zum Features List Team, sondern stehen ausschließlich für Fragen zur Verfügung. 2. Das Features List Team identifiziert die Features auf Basis seiner Erfahrungen aus Prozess #1. Die Features werden gruppiert und schriftlich fixiert. Ein Feature stellt die Beschreibung einer Funktion dar, die einen Kundennutzen bringt. Der Umfang eines Features wird durch die maximale Entwicklungsdauer eingeschränkt. Sie darf maximal 2 Wochen [6, p. 19] betragen. Außerdem erfolgt die Bezeichnung nach folgendem Muster: <action> <result> <object> Patrick Rehder 37

38 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Hier zwei Beispiele: Berechne die Summe des Warenkorbs. Stelle eine Auswahl der möglichen Versandarten für eine Bestellung dar. Da Features sehr granular sind, und bei großen Projekten 18 in einer entsprechenden Anzahl identifiziert werden, ist es unerlässlich die Features zu strukturieren. Hierfür werden sogenannte Feature Sets und Major Feature Sets verwendet. Ein Feature Set beschreibt eine Tätigkeit und ein Major Feature Set ein Fachgebiet. Das folgende Beispiel könnte der Planung einer Webpräsenz entnommen sein: Major Feature Set Feature Set Feature Feature Online Shop... Bestellung durchführen Berechne die Summe des Warenkorbs Stelle eine Auswahl der möglichen [ ]. Der Prozess #2 endet, wenn der Project Manager und der Development Manager mit der erstellten Features List zufrieden sind. [8, p. 143] Zu diesem Zeitpunkt sind die Features zwar strukturiert, aber noch nicht priorisiert. [13, p. 153] Plan by Feature In Prozess #3 werden die Features priorisiert und verteilt. Es wird mit folgendem Schritt begonnen: 1. Der Project Manager stellt das Planning Team aus dem Development Manager und den Chief Programmern zusammen. Die folgenden Schritte werden nicht der Reihe nach, sondern parallel abgearbeitet: Das Planning Team ordnet jedem Feature Set ein Fertigstellungsdatum zu es sind nur Monat und Jahr anzugeben. Die Feature Sets werden unter den Chief Programmer verteilt. Jede Klasse wird einem Entwickler zugeteilt, dem Class Owner. Wobei auch Chief Programmer Klassen übernehmen können und damit Class Owner werden. Die parallele Bearbeitung ist notwendig, da sich die Schritte aufgrund neuer Erkenntnisse gegenseitig beeinflussen. Außerdem müssen noch folgende Punkte bei der Planung berücksichtigt werden: Abhängigkeiten zwischen Features müssen beachtet werden. Risikoreiche und komplexe Feature Sets sollen möglichst früh realisiert werden. Die Arbeitsbelastung von Class Ownern soll gleichmäßig verteilt sein. Meilensteine müssen berücksichtigt werden, beispielsweise Vorabversionen. 18 Um eine Größe zu nennen: Im ersten FDD-Projekt wurden 2000 Features identifiziert. [13, p. 150] Patrick Rehder 38

39 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Die Ergebnisse von Prozess #3 werden als Development Plan bezeichnet. Es handelt sich hierbei um eine erweiterte Features List und eine Liste mit der Zuordnung von Entwicklern auf ihre Klassen: der Class Owner List. Sofern der Project Manager und der Development Manager mit dem Development Plan zufrieden sind, wird der Prozess #3 beendet. [8, pp. 154, 155] Design by Feature Die lineare Abfolge der vorherigen Prozesse, wird an dieser Stelle durchbrochen; Prozess #4 wird je Feature durchgeführt. Der Chief Programmer ist für das Durchführen der folgenden Schritte verantwortlich: 1. Der Chief Programmer stellt je Feature ein Feature Team zusammen. Ein Feature Team besteht aus allen Class Ownern, deren Klassen vom umzusetzenden Feature betroffen werden. 2. Sofern vorhanden, können referenzierte Dokumente durch das Feature Team gesichtet werden. In Abhängigkeit zur Komplexität des Features kann es sinnvoll sein, dass ein Domain Expert dem Feature Team den Anwendungsbereich noch einmal erläutert. 3. Das Feature Team entwickelt nun ein UML Sequenzdiagramm, welches das Feature beschreibt. Wie in Prozess #1 sind signifikante Entscheidungen schriftlich zu fixieren. 4. Der Chief Programmer reichert das Overall Model mit neu identifizierten Klassen, Methoden und Attributen an. 5. Jeder Class Owner schreibt Klassen- und Methodenkommentare für seine Klassen. Auf Basis der Kommentare generiert der Chief Programmer die API-Dokumentation. 6. Die Ergebnisse prüft das Feature Team bei einer Inspektion 19. Hierbei aufgezeigte Fehler werden direkt durch das Feature Team behoben. 7. Jeder Class Owner erstellt je Klasse eine Liste mit durchzuführenden Aufgaben. Danach entwickelt er einen persönlichen Terminplan, in dem er notiert, wann er welche Aufgabe erledigen wird. Das Ergebnis von Prozess #4 wird als inspiziertes Design Package bezeichnet, es setzt sich aus den folgenden Bestandteilen zusammen: Referenzierte Dokumente UML Sequenzdiagramm aktualisiertes Overall Model generierte API-Dokumentation Terminplan der Class Owner 19 Der Umfang oder exakte Ablauf einer Inspektion wird nicht weiter erläutert. Da es standardübergreifend keine einheitliche Definition gibt, sind Umfang und Ablauf selbst zu bestimmen. Patrick Rehder 39

40 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Build by Feature Im Prozess #5 werden die Features umgesetzt. Das zuvor erarbeitete Design Package dient hierbei als gemeinsame Basis. Die im Folgenden genannten Schritte werden je Klasse durchgeführt: 1. Der Class Owner passt die Methoden seiner Klassen so an, dass sie den Anforderungen des Features genügen. 2. Der Quelltext wird einer Inspektion unterzogen. Hierbei sind die folgenden Szenarien durch den Chief Programmer abzuwägen: Keine Inspektion für triviale Änderungen durchführen. [8, p. 185] Inspektion für mehrere Klassen in einer Sitzung durchführen. Inspektion erst nach dem Erstellen der Unit-Tests durchführen. 3. Der Class Owner schreibt für jede Methode Unit-Tests. 4. Die Klasse wird nun durch den Class Owner freigegeben. Dieser Schritt verdeutlicht, dass die Klasse fertig ist und bezüglich dieses Features nicht mehr bearbeitet wird. Der Grad der freigegebenen Klassen dient dem Chief Programmer als Fortschrittsmaß. Nachdem ein Feature umgesetzt wurde, werden die Prozesse #4 und #5 erneut für weitere Features durchlaufen Nachbetrachtung Beim Betrachten der einzelnen Prozesse entsteht schnell der Anschein, dass Menschen bei Feature Driven Development keinen hohen Wert besitzen. Das Gegenteil ist jedoch der Fall: Wenn die Projektbeteiligten nicht über die benötigten Fähigkeiten verfügen, können die Prozesse noch so gut sein das Projekt wird mit hoher Wahrscheinlichkeit scheitern. Gute Prozesse wiederum können guten Projektteams dabei helfen effizienter zu arbeiten. Ein gutes Projektteam stellt den Schlüssel für ein erfolgreiches Projekt dar. Der Grund hierfür liegt darin, dass es sich bei der Softwareentwicklung um eine Aktivität zwischen Menschen handelt. [13, p. 150] Um die Kommunikation zwischen den am Projekt beteiligten Menschen zu erleichtern, werden Modelle gegenüber Texten bevorzugt. Durch die Nutzung von UML zur Modellierung entsteht ein weiterer Vorteil: Mithilfe entsprechender Tools ist es möglich, das Modell und den Quelltext synchron zu halten. [13, p. 149] Generell wird bei Feature Driven Development viel Wert auf das Generieren von Inhalten gelegt (siehe API-Dokumentation in Prozess #4). Gemäß dem agilen Manifest sollen Anforderungsänderungen zu jeder Zeit des Projekts willkommen geheißen werden. [11] Dies wird bei Feature Driven Development über die maximale Laufzeit von sechs Monaten für einen kompletten Prozessdurchlauf sichergestellt, als auch über die 10%- Schlupfregel 20. Die Begrenzung der maximalen Laufzeit sorgt dafür, dass die Anforderungen spätestens nach sechs Monaten neu betrachtet werden. Die 10%-Schlupfregel handelt noch kurzfristigere Anforderungsänderungen ab. Sie besagt, dass eine Features List um knapp zehn Prozent anwachsen 20 Übersetzt aus dem Englischen: 10% Slippage Rule. [8, p. 235] Patrick Rehder 40

41 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis darf, ohne dass Maßnahmen vom Project Manager erforderlich werden. Danach muss der Project Manager über einen der folgenden Punkte eingreifen [8, pp ]: weniger wichtige Features streichen Projektlaufzeit verlängern Kapazität durch neue Chief Programmer und Entwickler erhöhen Damit der Prozentsatz der neuen und geänderten Features nachverfolgt werden kann, empfiehlt es sich die betroffenen Features entsprechend zu markieren. [13, p. 155] Feature Driven Development auf einen Blick [6, p. 19]: bietet eine elegante Strukturierungsmöglichkeit für Anforderungen auch für große Projektteams gut geeignet bietet durch sein Rollenmodell eine gesunde Basis für ein diszipliniertes Vorgehen ist für Festpreisprojekte gut geeignet lässt sich leichter als andere agile Vorgehen in große Organisationen einführen Patrick Rehder 41

42 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis 2.4. Extreme Programming Extreme Programming (XP) nimmt anerkannte Methoden der Softwareentwicklung und kombiniert diese mit dem Ansatz: Wenn ich aus Erfahrung weiß, dass etwas gut funktioniert, setze ich es im maximal möglichen Rahmen ein. Kent Beck, der Erfinder von Extreme Programming, hatte hierbei das Bild eines Steuerpults im Kopf. Jede Methode stellt darauf einen Regler dar, welcher bis zum Anschlag aufgedreht wird. Er wollte sehen was passiert Überraschenderweise erwies sich dieses Paket von [Methoden] als stabil, vorhersehbar und flexibel. [38, p. xv] Abbildung 6 - XP: Den Regler auf 10 drehen. [38, p. xv] Laut Kent Beck verspricht Extreme Programming [38, p. xvi]: Projektrisiken zu reduzieren. Sich ändernde, geschäftliche Anforderungen zu berücksichtigen. Die Produktivität fortlaufend zu erhöhen. Dass Softwareentwicklung im Team Spaß macht. Hierzu werden vier Tätigkeiten für die Entwicklung von Software genannt: Zuhören, Entwerfen, Programmieren und Testen. Diese Tätigkeiten werden über Methoden realisiert, welche wiederum definierte Werte und Prinzipien berücksichtigen. Der Zusammenhang wird in Abbildung 7 verdeutlicht. [39, p. 'Defining XP'] Patrick Rehder 42

43 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Abbildung 7 - XP: Unter der Lupe betrachtet. Im Folgenden werden die Bestandteile von Extreme Programming einzeln erläutert. Angefangen mit den Werten, werden folgend die Prinzipien und zum Schluss die Methoden betrachtet. Die vier Tätigkeiten werden nicht weiter im Detail behandelt, da diese bereits aufgelistet wurden und die Begriffe sprechend sind. Zur besseren Übersicht sind die einzelnen Bestandteile in Tabelle 9 indexiert. Werte Seite Methoden Seite Communication 44 Energized Work 49 Simplicity 45 Whole Team 50 Feedback 45 Sit Together 50 Courage 45 On-Site Customer 51 Respect 46 Informative Workspace 51 Prinzipien Seite User Stories 51 Rapid Feedback / Reflection 46 Weekly Cycle 52 Assume Simplicity 46 Quarterly Cycle 52 Incremental Change / Baby Steps 47 Metaphor 53 Embrace Change / Improvement 47 Slack 53 Quality Work / Quality 47 Incremental Simple Design 53 Humanity 47 Collective Ownership 54 Economics 47 Coding Standards 54 Mutual Benefit 47 Test-First Programming 55 Self-Similarity 48 Pair Programming 56 Diversity 48 Refactoring 57 Patrick Rehder 43

44 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Flow 48 Continuous Integration 57 Opportunity 48 Ten-Minute Build 58 Redundancy 48 Failure 48 Accepted Responsibility 48 Tabelle 9 - XP: Register der Bestandteile Es ist auffällig, dass das Bestandteil-Register für Extreme Programming mehr Begriffe enthält, als die Register von Scrum und Feature Driven Development. Dies liegt daran, dass Extreme Programming feiner strukturiert ist. Des Weiteren wird neben der ersten Version [38] auch die weiterführende Version [40] berücksichtigt. In der weiterführenden Version wurden unter anderem neue Methoden aufgenommen; aber auch vorhandene angepasst und umbenannt. Holger Breitling bezeichnet die weiterführende Version in einem Artikel als Extreme Programming 2.0 und findet folgende Adjektive: [ ] nachdenklicher, durchdachter, differenzierter als das ursprüngliche XP, aber auch weniger frisch, komplizierter und unübersichtlicher. [41] Werte Software wird von Menschen entwickelt. Jeder Beteiligte am Prozess, hat hierbei eine eigene Vorstellung davon, was wertvoll ist und was nicht. Für eine effektive und effiziente Zusammenarbeit der Beteiligten ist es jedoch entscheidend eine gemeinsame Wertvorstellung zu entwickeln. Ein gemeinsames Wertverständnis sorgt dafür, dass das Vorgehen einheitlich wahrgenommen wird. Extreme Programming nennt für eine gemeinsame Basis fünf Werte. Gemäß Kent Beck sortiert, lauten diese wie folgt: Communication Simplicity Feedback Courage Respect Die Werte werden im Kommenden einzeln erläutert. Als Quelle dienen die beiden Werke von Kent Beck, in der ersten [38, pp ] und zweiten Auflage [40, p. 'Chapter 4. Values']. Communication In der Softwareentwicklung lassen sich viele Probleme auf einen Mangel an Kommunikation zurückführen. Die Ausprägungen sind vielfältig. Zum Beispiel: Aus Bequemlichkeit werden Annahmen über die Wünsche des Kunden getroffen, anstatt ihn zu fragen. Patrick Rehder 44

45 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Aus Angst vor Konsequenzen werden negative Nachrichten nicht mitgeteilt. Aus Scham werden Probleme langwierig alleine gelöst, statt auf das Wissen eines Anderen zuzugreifen. Viele Methoden bei Extreme Programming verlangen deswegen explizit die Kommunikation zwischen den Beteiligten. Hinter dem Wert Communication verbirgt sich aber nicht nur, dass überhaupt kommuniziert wird. Es geht auch darum über welches Medium kommuniziert wird. Dieses Thema wurde bereits im Rahmen vom Agile Manifest erläutert (siehe Individuen und Interaktion sind wichtiger als Prozesse und Werkzeuge ab Seite 12). In Extreme Programming soll ein Gespräch stets einem anderen Medium vorgezogen werden. Simplicity Der Wert Simplicity lässt sich als Einfachheit übersetzen. Dahinter verbirgt sich, dass in Extreme Programming immer eine möglichst einfache Lösung gewählt werden soll. Die gewählte Lösung muss hierbei den Anforderungen des Kunden genügen, aber eben nicht mehr. Sie lässt sich deswegen schneller und kostengünstiger umsetzen, als eine allgemeine Lösung. Hierbei wird in Kauf genommen, dass eine Änderung im Nachhinein eventuell mehr kostet. Diese Ansicht ist vor allem für den Kunden wertvoll, denn er erhält nur die Funktionen die er auch wirklich benötigt. Feedback Bei Extreme Programming wird davon ausgegangen, dass sich innere und äußere Begebenheiten stets ändern können. Um sich daran anpassen zu können, müssen diese Änderungen wahrgenommen werden. Das Feedback (deutsch: Rückmeldung) übernimmt diese Aufgabe. Hierbei gilt: Feedback ist möglichst häufig einzuholen, damit Änderungen unmittelbar bekannt werden und darauf reagiert werden kann. Als Beispiel lassen sich Unit-Tests nennen. Unit-Tests geben schnell Aufschluss darüber, ob die getesteten Methoden so arbeiten wie erwartet. Vor dem Hintergrund späterer Änderungen ist dies besonders hilfreich; es bildet Vertrauen ins System. Courage Courage bedeutet Mut, welcher bei Extreme Programming durch die Beteiligten aufzubringen ist. Mut ist vor allem im Kontext der zuvor genannten Werte wertvoll: Kommunikation wird gefördert, wenn der Mut aufgebracht wird unangenehme und wahre Tatsachen offen anzusprechen. Es sorgt auch für Vertrauen. Einfachheit wird gefördert, wenn der Mut aufgebracht wird vorhandene Lösungen zu verwerfen, um bessere Lösungen und neue Ideen zu finden. Feedback wird gefördert, wenn der Mut aufgebracht wird nach Problemen zu suchen und wirkliche Lösungen zu bestimmen. Patrick Rehder 45

46 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Respect Ursprünglich nannte Kent Beck vier Werte. In seiner überarbeiteten Version fügte er noch einen fünften Wert hinzu: Respekt. Die Beteiligten müssen sich sowohl gegenseitig, als auch das Projekt respektieren sonst funktioniert Extreme Programming nicht. Es geht bei der Softwareentwicklung um die Menschen und ihr Miteinander: jede Meinung ist wichtig, jeder Gedanke ist wichtig, jede Idee ist wichtig jeder ist wichtig Prinzipien Werte sind sehr allgemein. Es ist deswegen wahrscheinlich, dass die Werte von unterschiedlichen Personen, unterschiedlich gedeutet werden. Aus diesem Grund nennt Extreme Programming Prinzipien. Sie geben den Werten eine Ausrichtung. Die erste Version nennt fünf Grund- und zehn weiterführende Prinzipien. Die überarbeitete Version vierzehn Prinzipien. Da Kent Beck die Prinzipien hierbei komplett überarbeitet hat, ist es schwierig die Versionen gegenüberzustellen. In der überarbeiteten Version sind sowohl bestehende, als auch neue Ideen eingeflossen. Im Folgenden werden zuerst die fünf Grundprinzipien der ersten Version und danach die thematisch nicht genannten Prinzipien der überarbeiteten Version erläutert. Aufgrund des Umfangs wird darauf verzichtet, die weiterführenden Prinzipien der ersten Version explizit zu nennen; zumal einige der Prinzipien in den überarbeiteten Prinzipien aufgehen. Als Quelle dienen die beiden Werke von Kent Beck, in der ersten [38, pp ] und zweiten Auflage [40, p. 'Chapter 5. Principles'], als auch die Zusammenfassung von Eckhart Hanser [42, pp ]. Die fünf Grundprinzipien Rapid Feedback / Reflection Unmittelbares Feedback (engl. Rapid Feedback) und Reflexion (engl. Reflection) beschreiben den Wert Feedback genauer. Der Gedanke hinter unmittelbarem Feedback ist, dass bereits früh Erkenntnisse gewonnen werden, so dass zeitnah darauf reagiert werden kann. Unmittelbares Feedback ergibt allerdings nur Sinn, wenn das Team an Verbesserungen interessiert ist. Dieser Punkt wird von der Reflexion aufgegriffen. Ein gutes Team erledigt seine Arbeit nicht nur, es überlegt wie es sich verbessern kann. Assume Simplicity Hinter Assume Simplicity verbirgt sich die Idee, Probleme so zu betrachten, als seien sie ganz einfach zu lösen. Dieses Prinzip verkörpert damit direkt den Wert der Einfachheit, welcher zuvor bereits erläutert wurde. Patrick Rehder 46

47 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Incremental Change / Baby Steps Die Prinzipien Incremental Change und Baby Steps beschreiben im Kern, dass es besser ist, immer wieder kleine Schritte zu machen, als einmal einen Großen. Kleinere Schritte sind besser zu überblicken und damit zu kontrollieren. Dies trifft sowohl auf Änderungen am Prozess, als auch auf Entwicklungsarbeiten zu. Bei Entwicklungsarbeiten ist es außerdem hilfreich regelmäßig vorzugehen. Dies sorgt für Routine und reduziert damit den Organisationsaufwand. Embrace Change / Improvement Bei der Entwicklung von Software gibt es kein perfektes Vorgehen. Es gibt nur die Möglichkeit, sein derzeitiges Vorgehen weiter zu perfektionieren. Die eigenen Prozesse müssen ständig hinterfragt werden, um für Verbesserung (engl. Improvement) zu sorgen. Hierbei ist es eine Grundvoraussetzung, dass alle Beteiligten auch bereit sind Veränderungen zu begrüßen (engl. embrace changes). Quality Work / Quality Qualität (engl. Quality) wird bei Extreme Programming als unantastbare Größe gesehen. Sie dient nicht als Stellgröße, falls ein Projekt in Verzug gerät. Es ist ein Trugschluss zu denken, dass mindere Qualität für eine schnellere Lieferung sorgt. Durch das Vernachlässigen von Qualität schleichen sich Fehler ein, die nachträglich zu mehr Aufwand führen. Außerdem ist es bei einer geringeren Qualität wahrscheinlicher, dass die gelieferte Software nicht den erwarteten Nutzen erbringt. Damit ist weder dem Kunden, noch dem Entwicklungsteam geholfen. Weitere Prinzipien Humanity Das Prinzip der Menschlichkeit (engl. Humanity) besagt: Software wird von Menschen entwickelt, dies muss bedacht werden. Für eine optimale Leistung, müssen menschliche Bedürfnisse berücksichtigt werden. Zum Beispiel: Sicherheit des Arbeitsplatzes, persönliche Weiterbildung und Akzeptanz im Team. Economics Wirtschaftlichkeit (engl. Economics) ist stets zu gewährleisten. Wenn die Kosten den Nutzen übersteigen, gibt es keine Rechtfertigung für ein Projekt. Außerdem ist folgende Regel für Investitionen zu bedenken: Je früher Geld eingenommen wird, desto besser und je später Kosten entstehen, desto besser. [28, p. 1309] Mutual Benefit Bei Extreme Programming soll kein Nutzen auf Kosten anderer, sondern gegenseitiger Nutzen (engl. Mutual Benefit) gewonnen werden. Tätigkeiten sollen stets Vorteile für alle Beteiligten mit sich bringen. Patrick Rehder 47

48 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Self-Similarity Das Prinzip der Selbstähnlichkeit (engl. self-similarity) besagt, dass gute Lösungen auch in einem anderen Kontext funktionieren können dies gilt es auszuprobieren. Diversity Die Vielfalt (engl. Diversity) der Teammitglieder und Ideen ist ein weiteres Prinzip. Es geht darum, dass unterschiedliche Eigenschaften und Fähigkeiten von Teammitgliedern zu völlig neuen Lösungen führen können. Die entstehende Vielfallt an Ideen ist als Chance zu sehen: Es kann immer die beste Idee ausgewählt werden. Flow Damit der Kunde den aktuellen Stand der Software nutzen und sich darauf beziehen kann, ist ein ständiger Fluss (engl. Flow) anzustreben. Die Software soll dem Kunden schnellstmöglich zur Verfügung gestellt und danach kontinuierlich angepasst werden. Opportunity Jedes Problem soll bei Extreme Programming als Gelegenheit (engl. Opportunity) betrachtet werden. Gelegenheiten sich zu verbessern. Es darf nicht das Ziel sein, Probleme nur zu überstehen. Dieses Prinzip minimiert die Schwächen und maximiert die Stärken des Teams. Redundancy Redundanz (engl. Redundancy) sorgt für Sicherheit, dieses Prinzip ist deswegen in kritischen und komplexen Bereichen der Softwareentwicklung anzuwenden. Das Auffinden von Fehlern ist ein gutes Beispiel für einen solchen Bereich, es ergibt Sinn nicht einmalig nach Fehlern zu suchen, sondern hierfür mehrere Instanzen vorzusehen. Failure Ein Misserfolg (engl. Failure) kann dazu genutzt werden, Wissen zu gewinnen. So ist trial and error ein zweckmäßiger Weg, schnell Erkenntnisse zu gewinnen. Außerdem kann es günstiger sein, eine Lösung auszuprobieren, statt lange darüber zu diskutieren. Im Kern besagt dieses Prinzip, dass Fehler nicht immer schlecht sind wenn aus ihnen gelernt wird. Accepted Responsibility Wenn Aufgaben vorgeschrieben werden, ist es unwahrscheinlich dass sie engagiert umgesetzt werden. Um das Engagement einer Person zu wecken, muss sie die Verantwortung für eine Aufgabe übernehmen (engl. Accepted Responsibility). Verantwortung kann nicht zugewiesen werden. Letztlich muss nicht nur jeder die Verantwortung für seine Aufgaben übernehmen; das Team muss sich für das Produkt verantwortlich fühlen. Patrick Rehder 48

49 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Methoden Die Methoden von Extreme Programming geben sich wie ein Baukasten. Sie müssen nicht alle auf einmal eingeführt werden, sondern können nach und nach etabliert werden. Der Einsatz einer Methode führt bereits zu einer Verbesserung. Für eine entschiedenere Verbesserung müssen sich die Methoden jedoch gegenseitig stützen. Hierbei ist es nicht sinnvoll den Einsatz einer Methode zu erzwingen. Wenn eine Methode nicht funktioniert, ist sie nicht einzusetzen. Die erste Version von Extreme Programming enthält 12 Methoden. In der überarbeiteten Version sind 25 Methoden genannt, die sich in 13 primäre und 12 resultierende Methoden aufteilen. Die 12 resultierenden Methoden werden in dieser Arbeit nicht weiter erläutert, da sie erst nach den primären Methoden relevant werden. Wenn bei den verbleibenden Methoden die Übereinstimmungen zusammengefasst werden, ergibt sich eine Summe von 18 Methoden. Die 18 Methoden wurden in drei Kategorien eingeordnet, siehe Tabelle 10. Allgemein Ablauf und Planung Entwicklung Energized Work User Stories Incremental Simple Design Whole Team Weekly Cycle Collective Ownership Sit Together Quarterly Cycle Coding Standards On-Site Customer Metaphor Test-First Programming Informative Workspace Slack Pair Programming Refactoring Continuous Integration Ten-Minute Build Tabelle 10 - XP: Strukturierung der Methoden Als Quelle dienen die beiden Werke von Kent Beck, in der ersten [38, pp ] und zweiten Auflage [40, p. 'Chapter 7. Primary Practices'], als auch die Zusammenfassung von Eckhart Hanser [42, pp ] und das Buch Software entwickeln mit extreme Programming [43, pp ]. Allgemein Energized Work Niemand kann [ ] über viele Wochen hinweg, 60 Stunden in der Woche arbeiten und dann immer noch frisch, kreativ, sorgfältig und voller Selbstvertrauen sein. [38, p. 60] Bei regelmäßigen Überstunden kann nicht von energiegeladener Arbeit (engl. energized work) gesprochen werden. Dies zeigt vielmehr, dass es ein Problem gibt, welches erkannt und gelöst werden muss. Wer krank oder müde ist, wer ständig Anrufe erhält oder auf s antwortet, der kann nicht 100% seiner Leistung erbringen. Patrick Rehder 49

50 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Für energiegeladene Arbeit müssen die genannten Störungen beseitigt werden: wer krank ist bleibt zuhause, wer müde ist legt sich früher hin und wer ständig abgelenkt wird, der stellt das Telefon auf lautlos und beendet das -Programm. Es bietet sich an, den Arbeitstag in Abschnitte zu unterteilen: Programmierzeit, Verwaltungszeit und Pausen. In den einzelnen Abschnitten wird sich auf die entsprechende Arbeit konzentriert. Dies gilt auch für Pausen, sie sind genauso intensiv wahrzunehmen wie die vorangegangene Arbeit. Whole Team Ein ganzes Team (engl. Whole Team) vereint alle Fähigkeiten in sich, die derzeit zur Bearbeitung des Projekts benötigt werden. Es ist möglich, dass Teammitglieder im Laufe eines Projekts aufgrund ihrer Fähigkeiten aufgenommen oder abgegeben werden. Das derzeitige Team sieht sich hierbei stets als Ganzes, der Team-Gedanke ist wichtig nur wenn alle an einem Strang ziehen ist die Wirkung maximal. Sit Together Diese Methode besagt, dass das Team zusammensitzen (engl. Sit Together) soll. Dies ist zum einen die Voraussetzung für andere Methoden (zum Beispiel: Pair Programming), aber auch förderlich für den Wert der Kommunikation. Nur wenn das Team gemeinsam in einem Raum sitzt, besteht die Möglichkeit, kurzfristig Fragen in die Runde zu werfen oder Gespräche zwischen anderen Kollegen aufzugreifen, um hilfreiches beizusteuern. Eine förderliche Anordnung der Büromöbel ist in Abbildung 8 skizziert. Im Zentrum des Raums befinden sich Arbeitsplätze fürs Pair Programming und an den Wänden kleine Parzellen für ungestörte Einzelarbeit. Abbildung 8 - XP: Team Workspace [40, p. 'Figure 5. A team workspace'] Patrick Rehder 50

51 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis On-Site Customer Die Methode On-Site Customer oder Kunde vor Ort sieht vor, dass der Kunde nicht nur zu Beginn des Projekts einmal vorbeischaut und sagt was er haben möchte, sondern täglich für Fragen zur Verfügung steht. Hierbei ist es im Sinne der Kommunikation von Vorteil, wenn der Kunde im Team- Büro sitzt und bei Unklarheiten direkt kontaktiert werden kann. Der Nutzen wird maximiert wenn der On-Site Customer die folgenden Punkte erfüllt: Er verfügt über fundierte fachliche Kenntnisse. Er arbeitet mit der zu ersetzenden Anwendung. Er soll die zu entwickelnde Anwendung später nutzen. Für die Entwickler gilt: Wenn die fachlichen Anforderungen nicht eindeutig sind, ist der On-Site Customer zu fragen. Es sollen keine Annahmen von Entwicklern getroffen werden. Auch bei gleichwertigen Lösungen gilt: Nicht selber entscheiden, sondern den On-Site Customer fragen. In der Praxis ist es meist schwierig eine Person aus der Fachabteilung zu 100% freizustellen dies ist erfahrungsgemäß auch nicht notwendig. Der On-Site Customer verfügt über Freiräume, in denen er sich um seine eigentlichen Aufgaben kümmern kann. Für den Fall, dass es dem On-Site Customer nicht möglich ist im Team-Büro zu sein, nennt Eckart Hanser eine interessante Lösung: Der On-Site Customer erhält ein rotes Telefon, dessen Nummer im Idealfall nur den Entwicklern bekannt ist. Das rote Telefon kann beispielsweise ein Prepaid-Handy sein. Anrufe auf diesem Telefon werden vom On-Site Customer schnellstmöglich entgegengenommen und zeitnah beantwortet. Informative Workspace Eine informative Arbeitsumgebung (engl. Informative Workspace) bietet die Möglichkeit, sich innerhalb weniger Sekunden über den aktuellen Stand des Projekts zu informieren. Dies lässt sich beispielsweise über die Anordnung der User Stories in Kategorien (zum Beispiel: offen, in Arbeit, erledigt) an einer Wand erreichen. Anstatt aktuelle Messdaten 21 über zu verschicken oder auf einer internen Webseite bereitzustellen, soll eine große Tafel im Team-Büro zum Darstellen genutzt werden. Ablauf und Planung User Stories User Stories oder Benutzergeschichten benennen Funktionen, die von der Anwendung zur Verfügung gestellt werden sollen. Jede User Story verfügt hierbei mindestens über die folgenden Informationen: Bezeichnung Beschreibung (zwei bis drei Halbsätze) 21 zum Beispiel: Fehler in Produktion oder Anzahl der Klassen Patrick Rehder 51

52 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Aufwand (durch die Entwickler geschätzt) Der geringe Detailgrad gewährleistet, dass die Informationen auf einer DIN A5 Karte Platz finden. Hierbei ist eine physische Repräsentation, laut Kent Beck, stets einer digitalen vorzuziehen. Die User Stories lassen sich so einfacher in Besprechungen verwalten, außerdem können sie an einer Wand aufgehängt (siehe Informative Workspace) und anhand ihres Status sortiert werden. Die Gesamtheit der User Stories reicht nicht aus, um das System zu spezifizieren. Eine Funktion lässt sich nicht allein auf Basis der zugehörigen User Story umsetzen. Die kurze Beschreibung reicht nicht aus, um die Gedanken des Kunden vollständig wiederzugeben. Dies ist gewünscht; der Entwickler soll die Details vom Kunden erfragen. Aus diesem Grund ist es wichtig, dass der Kunde auch zur Verfügung steht. User Stories werden zur Iterationsplanung genutzt. Alle vom Kunden gewünschten Funktionen werden in Form von User Stories aufgeschrieben. Danach wird der Aufwand zur Umsetzung für jede User Story von den Entwicklern geschätzt und notiert. Der Kunde erhält damit einen Überblick, wie viel je Funktion investiert werden muss. Auf Basis dieser Information kann der Kunde die User Stories priorisieren und damit festlegen, was zuerst umgesetzt werden soll. Die Entwickler können nun, anhand ihrer Kapazität, die User Stories für die kommende Iteration auswählen. Weekly Cycle Die User Stories werden in Iterationen abgearbeitet. Zu Beginn einer Iteration werden die umzusetzenden User Stories vom Team ausgewählt. Die Auswahl erfolgt im sogenannten Iteration Planning Meeting und wird auf Basis der Priorität für den Kunden und der Kapazität des Teams durchgeführt. Als Zeitraum nannte Kent Beck ursprünglich ein bis vier Wochen. In der überarbeiteten Version legte er sich letztlich auf einen wöchentlichen Zyklus (engl. Weekly Cycle) fest. Dieser sei Ideal, da er eine natürliche Grenze hat das Wochenende. Das Team kann sich darauf konzentrieren, die gewählten User Stories bis zum Wochenende zu erledigen und nach dem Wochenende, ausgeruht in die neue Iteration starten. Am Ende der Iteration werden dem Kunden die umgesetzten User Stories vorgestellt. Dieser kann sich ein Bild von der Umsetzung machen und unmittelbar Feedback geben. Dadurch können neue User Stories entstehen, alte verworfen, verändert oder umpriorisiert werden. Ziel jeder Iteration ist es, eine produktiv einsetzbare Anwendung zu haben, die den Anforderungen des Kunden genügt. Quarterly Cycle Der Quartalszyklus (engl. Quarterly Cycle) lehnt sich am Quartal eines Jahres an und umfasst damit drei Monate. Dies ist der von Kent Beck empfohlene Zeitraum für ein Release. Für die Planung eines Release ist es schwierig, den Inhalt anhand von User Stories zu überblicken. Es bietet sich an, für ein Release Themen zu definieren. Die User Stories können dann anhand solcher Themen gruppiert werden. Patrick Rehder 52

53 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Außerdem soll in jedem Quartal eine Reflexionssitzung erfolgen, in der Probleme identifiziert und Lösungen gesucht werden. Metaphor Eine Metapher (engl. Metaphor) kann dazu genutzt werden, das Softwaresystem in einem übertragenen Sinn zu betrachten. Als Beispiel kann für ein Textverarbeitungsprogramm, eine Schreibmaschine als Metapher verwendet werden. Der Vorteil liegt darin, dass alle Beteiligten hierdurch eine vertraute Vorstellung vom zu entwickelnden System erhalten. Außerdem kann eine Metapher die Kreativität im Team anregen und zu neuen Ideen führen. Es ist jedoch nicht einfach eine gute Metapher zu finden, die gleichzeitig von allen Beteiligten auf die gleiche Weise verstanden wird. Slack Slack lässt sich unter anderem mit Pufferzeit oder Leerlauf übersetzten. Diese Methode wird durch beide Begriffe in Kombination ideal beschrieben: Jeder Plan soll über Pufferzeiten verfügen. Hierbei ist ein Teil der verfügbaren Zeit entweder gar nicht oder mit niedrig priorisierten, notfalls wegzulassenden Aufgaben zu verplanen. Das eigentliche Ziel bleibt damit erreichbar, auch wenn unvorhersehbare Ereignisse eintreten (zum Beispiel: Krankheit oder Fehleinschätzung). Bleiben Pufferzeiten unangetastet, besteht immer noch die Möglichkeit, weitere Aufgaben im Nachhinein einzuplanen. Leerlauf bezeichnet einen Zeitraum, der nicht durch vorgegebene Aufgaben definiert wird. Die freie Zeit soll von den Entwicklern für eigene Interessen genutzt werden, dies kann beispielsweise eine neue Technologie oder andere Vorgehensweise sein, aber auch die Mitarbeit an einem Open Source Projekt. Hierbei gewonnene Ideen können sich positiv auf das eigentliche Projekt auswirken. Entwicklung Incremental Simple Design Ziel des schrittweisen, einfachen Entwurfs (engl. Incremental Simple Design) ist es, zu jedem Zeitpunkt der Entwicklung die einfachst mögliche Architektur zu haben, die den bekannten Anforderungen entspricht. Die Architektur wird beim Incremental Simple Design regelmäßig kontrolliert und angepasst, damit sie den momentanen Anforderungen bestmöglich gerecht wird. Hierbei ist es nicht untersagt eine grundlegende Struktur festzulegen oder Frameworks zu verwenden. Der Einsatz von Architectural Patterns ist zum Beispiel sinnvoll, da hierdurch ein gemeinsames Verständnis der Struktur gewährleistet wird. Jeder Teil, eines auf einem einfachen Entwurf basierenden Systems, muss sein Vorhandensein rechtfertigen. Das System soll die folgenden Merkmale erfüllen: Das System besteht alle Tests. Das System ist selbstbeschreibend. Patrick Rehder 53

54 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Das System einhält keinen gleichen Quelltext an verschiedenen Stellen. Das System besteht aus so wenigen Klassen wie möglich. Die Klassen im System enthalten so wenige Methoden wie möglich. Die Merkmale sind hierbei in absteigender Reihenfolge zu berücksichtigen. Es ist beispielsweise wichtiger, dass sich das System selbst beschreibt, als dass die Zahl der Klassen möglichst gering ist. Eine beliebte Ausprägung von Incremental Simple Design ist die Quick Design Session. Eine Runde mit wenigen Entwicklern (drei sind am besten, fünf das Maximum) trifft sich, um die Architektur des Systems zu besprechen und weiterzuentwickeln. Es gilt die Regel: Lieber ausprobieren, statt zu diskutieren. Collective Ownership Die Methode vom Kollektivbesitz (engl. Collective Ownership) besagt, dass das Team gemeinsam für den Quelltext verantwortlich ist. Jeder Entwickler darf jede Stelle im Quelltext anpassen es wird sogar von ihm erwartet: Von jedem, der eine Möglichkeit sieht, irgendeinen Teil des Codes etwas Sinnvolles hinzuzufügen, wird erwartet, dass er dies jederzeit tut. [38, p. 59] Hauptsächlich lassen sich die folgenden Vorteile gegenüber der Einzelverantwortlichkeit auflisten: Der Ausfall eines Teammitglieds kann leichter kompensiert werden, da der Quelltext auch anderen Entwicklern bekannt ist. Oft genutzter Quelltext, wird durch mehrere Entwickler begutachtet. Fehler fallen hier mit einer größeren Wahrscheinlichkeit auf und werden direkt behoben. Bei Fehlern versucht der Entdecker schnellstmöglich eine Lösung zu finden und nicht einen Schuldigen. Der Schuldige steht automatisch fest: das Team. Bei einem stark schwankenden Qualitätsniveau im Team und in großen Softwaresystemen stößt Collective Ownership jedoch an seine Grenzen: Bei Ersterem ist es wahrscheinlich, dass der Quelltext von schwächeren Teammitgliedern überarbeitet und angepasst werden muss, um den Qualitätsansprüchen des Teams zu genügen. Um dieses Problem zu lösen, muss das Qualitätsniveau im Team vereinheitlicht werden. Hier eignet sich vor allem die später erläuterte Methode Pair Programming. Der zweite Punkt bezieht sich darauf, dass Entwickler in großen Systemen viel Zeit aufwenden, sich in unbekannten Quelltext einzuarbeiten. Der Aufwand hierfür kann jedoch reduziert werden, wenn die Methoden übersichtlich gestaltet und ausreichend dokumentiert sind. Coding Standards Coding Standards sind Richtlinien für das Programmieren. Sie geben beispielsweise vor welche Form der Quelltext haben soll, wie Dateien und Klassen zu benennen und welche Werkzeuge einzusetzen Patrick Rehder 54

55 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis sind. Das Vorgehen beim Programmieren soll vereinheitlich werden. Beim optimalen Einsatz von Coding Standards ist nicht mehr zu erkennen, welcher Entwickler welchen Quelltext geschrieben hat. Ein Coding Standard soll den folgenden Punkten genügen: Der Programmieraufwand soll durch die Richtlinien so gering wie möglich gehalten werden; sonst hält sich keiner dran. Die Richtlinien sollen kurz, einfach und klar formuliert sein; sonst liest sie keiner. Die Kommunikation soll durch ein einheitliches Verständnis beim Programmieren gefördert werden. Letztlich muss das gesamte Team die Richtlinien freiwillig befolgen. Test-First Programming 22 Beim Test-First Programming wird nicht mit dem produktiven Quelltext begonnen, sondern mit automatisierten Testfällen. Daraus ergeben sich mehrere Vorteile: Da frisch erstellte Testfälle erst einmal fehlschlagen, können sie während der Entwicklung zur Anzeige des Fortschritts genutzt werden. Beim Test-First Programming kann nicht drauflos entwickelt werden. Der Entwickler muss sich über die beabsichtigte Funktion im Klaren sein und sich Gedanken über die Schnittstelle machen, um die Testfälle erstellen zu können. Die Schnittstelle wird durch den Testfall von außen betrachtet, was der späteren Nutzung entspricht. Die Schnittstelle wird damit auf ihre Nutzung optimiert. Komplexere Komponenten lassen sich schwieriger testen, als einfachere Komponenten. Beim Test-First Programming entstehen deswegen tendenziell, einfachere Komponenten. Wenn sich etwas nicht gut testen lässt, ist dies meist ein Hinweis auf ein unzureichendes Design. Testfälle prüfen, ob sich das System so verhält wie es soll. Wenn alle Testfälle ohne Fehler durchlaufen, schafft dies Vertrauen in das getestete System. Dies ist besonders wertvoll, wenn das System geändert oder erweitert wird. Die beabsichtigte Nutzung einer Komponente wird durch einen Testfall dokumentiert. Beim Extreme Programming wird zwischen zwei Test-Arten unterschieden: Ein Komponententest oder Unit-Test bezieht sich auf eine Komponente im System. Zum Beispiel ein Modul oder eine Klasse. Die Testfälle werden von den Entwicklern geschrieben. Für viele Programmiersprachen gibt es passende Frameworks, die das Erstellen und automatisierte Ausführen von Testfällen vereinfachen. 22 Die Methode Test-Frist Programming wird auch beim Test-Driven Development (TDD) eingesetzt. [69] Patrick Rehder 55

56 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Durch Akzeptanztests oder auch Funktionstests wird geprüft, ob eine realisierte User Story den Erwartungen des Kunden entspricht. Aus einem Akzeptanztest können diese Erwartungen extrahiert werden, was die Umsetzung erleichtert. Der Aufwand für eine automatisierte Überprüfung ist hingegen meist unverhältnismäßig hoch. Es bietet sich deswegen an, zumindest einen Teil der Tests manuell auszuführen. Test-First Programming ist auch beim Beseitigen von Fehlern anzuwenden. Bevor ein Fehler behoben wird, wird ein Testfall zu diesem Fehler geschrieben. Falls der Fehler später wieder eingebaut wird, schlägt der Test fehl und weist darauf hin. Pair Programming Wenn sich zwei Entwickler einen Rechner teilen und gemeinsam an einer Aufgabe arbeiten, wird dies als Pair Programming bezeichnet. Da nur ein Entwickler zurzeit aktiv den Rechner bedient, ist der Gedankenaustausch zwischen beiden entscheidend. Der eingebende Entwickler erklärt dem beisitzenden Entwickler warum er etwas macht und der beisitzende Entwickler weist den eingebenden Entwickler auf Fehler hin. Die Paarungen, als auch die Rolle des Eingebenden und Beisitzenden, sollen hierbei nicht fest vergeben sein, sondern kontinuierlich wechseln. Es lassen sich die folgenden Vorteile aufzählen: Je zwei Entwickler wird nur ein leistungsfähiger Entwicklungsrechner zwingend benötigt. Mögliche Rechner an Einzelarbeitsplätzen (siehe Sit Together, Seite 50) müssen nicht über das Leistungsniveau eines Entwicklungsrechners verfügen. Der Quelltext und das Design unterliegen einem ständigen Review durch den Beisitzenden, hierbei werden Fehler entdeckt und dadurch die Qualität gesteigert. Durch den fortlaufenden Austausch von Erfahrungen, gleicht sich das Niveau zwischen unerfahrenen Entwicklern und Experten mit der Zeit an. Wenn der eingebende Entwickler nicht weiterkommt, können die Rollen getauscht werden und der beisitzende Entwickler übernimmt. Da zwei Entwickler über die Lösung eines Problems nachdenken, ergeben sich neue Lösungsideen, die einem Entwickler alleine nicht eingefallen wären. Der Ausfall eines Entwicklers kann, aufgrund des verteilten Wissens, besser vom Team kompensiert werden. Es ist für ein Entwickler-Paar einfacher sich gemeinsam auf eine Aufgabe zu konzentrieren. Die Zeit des Kollegen will schließlich nicht mit für ihn belanglosen Dingen 23 verschwendet werden. Team-Praktiken werden einheitlicher gelebt, da sich ein einzelner Entwickler nicht unentdeckt darüber hinwegsetzen kann. 23 Für den Kollegen können zum Beispiel belanglos sein: Telefonate, s und Börsenkurse. Patrick Rehder 56

57 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Pair Programming ist eine der bekanntesten Methoden von Extreme Programming und wird aufgrund unterschiedlichster Meinungen viel diskutiert. Insbesondere die Auswirkung auf Qualität, Zeit- und Kostenaufwand wurde in vielen Studien untersucht. Die Anzahl an Studien ist sogar so groß, dass es inzwischen zusammenfassende Studien gibt. Johannes Brodwall bringt das Ergebnis der zusammenfassenden Studie Are Two Heads Better than One? On the effectiveness of pair programming in einem Online-Artikel auf den Punkt [44]: Pair Programming sorgt dafür, dass ein Projekt etwas früher fertig wird, mit einer signifikant besseren Qualität, aber zu höheren Kosten. Er bemängelt jedoch, dass die folgenden Punkte in der Studie nicht berücksichtigt werden: Eine bessere Qualität sorgt langfristig für geringere Kosten. Der Ausfall eines Entwicklers kann durch Wissensteilung besser kompensiert werden. Der Einfluss von Erfahrung beim Pair Programming. Refactoring Beim Refactoring oder Überarbeiten, nennt Extreme Programming zwei Beweggründe: Das Hinzufügen einer neuen Funktion wird vereinfacht. Es gibt eine einfachere Lösung, als die gerade implementierte. Durch Refactorings wird versucht den Aufwand für zukünftige Änderungen zu reduzieren und das System damit wartbar zu machen. Hierbei dürfen die Anforderungen der Kunden und Anwender nicht aus den Augen verloren werden. Eine Voraussetzung für Refactorings sind flächendeckende Komponententests. Nur so lässt sich gewährleisten, dass Änderungen keine Seiteneffekte auf die Funktionalität haben. Um das Risiko weiter zu senken bietet es sich an, große Refactorings in kleine Schritte zu unterteilen. Continuous Integration Bei einer kontinuierlichen Integration (engl. continuous integration) werden die Anpassungen der einzelnen Entwickler in möglichst kleinen Schritten im Gesamtsystem zusammengefügt. Sie stehen den anderen Entwicklern damit schnell zur Verfügung. Dadurch fallen konkurrierende Änderungen schneller auf oder entstehen gar nicht erst. Die Integration umfasst nicht nur das Zusammenfügen des Quelltextes, sondern auch das Sicherstellen der Funktionalität vom Gesamtsystem. Der Funktionsumfang soll hierbei auf einem extra Integrationssystem geprüft werden, welches der produktiven Umgebung möglichst ähnlich ist. Nur so fallen fehlende Komponenten auf, die auf dem Entwicklungsrechner installiert sind, aber nicht mit verteilt werden. Da eine Integration möglichst oft stattfinden soll, sind Tests möglichst zu automatisieren. Dies spart nicht nur Zeit, sondern stellt auch sicher, dass keine Tests vergessen oder aus Bequemlichkeit ausgelassen werden. Patrick Rehder 57

58 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis Ten-Minute Build Laut der Methode Ten-Minute Build darf ein Build nicht länger als zehn Minuten 24 dauern. Unter Build ist in diesem Fall das Übersetzten der Anwendung und das Ausführen aller automatisierten Tests zu verstehen. Ein längerer Build würde dafür sorgen, dass die Akzeptanz für den Build sinkt und dieser nicht mehr so häufig genutzt wird. Wenn der Build länger dauert, muss der Vorgang optimiert werden. Eine Möglichkeit ist es das System in Abschnitte zu unterteilen, um nur die Abschnitte übersetzten und testen zu müssen, die sich auch geändert haben. Ein weiterer Weg ist es die Geschwindigkeit über leistungsfähigere Hardware zu erhöhen Rollen Die in Extreme Programming genannten Rollen haben sich in vergangenen Projekten etabliert; beziehungsweise wurden dort vorgefunden. Sie sind jedoch weder ein Garant für den Erfolg eines Projekts, noch sind sie zwingend in jedem Projekt zu besetzen. Es soll nicht darum gehen die Teammitglieder in Rollen zu pressen, um ein vordefiniertes System zu besetzten; es muss darum gehen, ein neues System auf Basis der Stärken der Mitglieder zu entwickeln. Zu Beginn eines Projekts kann es jedoch hilfreich sein, sich an den vordefinierten Rollen zu orientieren. Die Rollen sind hierbei flexibel zu behandeln: Eine Rolle kann von mehreren Teammitgliedern übernommen werden und ein Teammitglied kann mehrere Rollen innehaben. Unter dem Begriff Team sind an dieser Stelle übrigens sowohl Entwickler, Kunden, als auch das Management gemeint. Letztlich müssen alle Beteiligten das große Ganze im Blick haben: Die Entwicklung einer Anwendung unter ökonomischen Gesichtspunkten. [38, pp. 139, 140] [40, p. 'Chapter 10. The Whole XP Team'] [43, p. 121] Aufgrund des Umfangs werden die einzelnen Rollen in dieser Arbeit nicht erläutert Nachbetrachtung Auf den ersten Blick gibt Extreme Programming vor, wie bei der Softwareentwicklung in kleinen, lokalen Teams 25 vorzugehen ist. Dahinter verbirgt sich der Wunsch ein Gemeinschaftsdenken zu entwickeln. Die Art und Weise soll sich ändern, wie die Beteiligten miteinander umgehen. Die Aufgaben sollen nicht durch Vorgesetzte diktiert werden sie sollen bereitwillig übernommen werden. Dem Kunden soll kein Schauspiel geboten werden. Er soll Nutzen erhalten. Er soll dem Team vertrauen. [13, p. 28] Die Methoden alleine reichen hierzu nicht aus. Auch wenn sie detailliert beschrieben sind und auf bewährten Verfahren beruhen. Sie ergeben erst im Kontext der Werte und Prinzipien betrachtet den 24 Erfahrungswert von Kent Beck 25 Ein kleines, lokales Team im Sinne von Extreme Programming besteht aus zwei bis zehn Entwickler, welche gemeinsam an einem Ort arbeiten. [38, p. xviii] Patrick Rehder 58

59 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis gewünschten Sinn. Neben der Einführung der Methoden ist es entscheidend, die Werte und Prinzipien zu vermitteln. [38, p. xviii] Die Einführung von Extreme Programming gestaltet sich einfach, da die einzelnen Methoden schrittweise etabliert werden können [38, p. 123]: 1. Das größte Problem beim derzeitigen Vorgehen identifizieren. 2. Lösung des Problems über ein oder mehrere Methoden von Extreme Programming. 3. Wenn das Problem nicht mehr das Größte ist, geht es wieder zum ersten Punkt. Die Methoden schrittweise einzuführen birgt weniger Risiken, als alle Methoden auf einmal einzusetzen. Dies gilt insbesondere für laufende Projekte, die auf Extreme Programming umstellen wollen. Dass Extreme Programming nur richtig erlernt werden kann, wenn es in der Praxis angewendet wird, spricht ebenfalls für eine schrittweise Einführung. Nur über Methoden zu lesen versetzt einen noch nicht in die Lage eine Methode zu beherrschen. [40, pp. 'Chapter 3. Values, Principles, and Practices'] Extreme Programming (XP) auf einen Blick [6, p. 13] [38, p. xvii]: XP gibt frühzeitig und fortlaufend Feedback durch kurze Zyklen. XP berücksichtigt sich ändernde geschäftliche Anforderungen. XP ist vor allem für kleine Projekte geeignet (2 bis 10 Entwickler). XP legt großen Wert auf Qualität. XP macht klare Vorgaben für Management, Team und Programmierung. XP ist eine mächtige, aber anspruchsvolle Methode. Patrick Rehder 59

60 >>> Grundlagen: Agile Softwareentwicklung Master-Thesis 2.5. Zusammenfassende Betrachtung In diesem Kapitel werden die drei zuvor erläuterten Prozesse: Scrum, Feature Driven Development und Extreme Programming gemeinsam betrachtet. Begonnen wird mit einer gelungenen Übersicht aus der Broschüre Agile Softwareentwicklung - Ein Überblick, siehe Tabelle 11. Die Übersicht beschreibt, unter welchen Voraussetzungen sich welcher Prozess besser eignet. Je mehr Sterne, desto besser ist der Prozess unter den gegebenen Voraussetzungen geeignet. Voraussetzungen Scrum FDD XP Großes Projekt Kleines Projekt Festpreisprojekt Zugriff auf Fachexperten ist schwierig Selbstgesteuerte Teams Entwickler sind räumlich getrennt Spezialisierung der Teammitglieder Erfahrung mit agilen Prozessen ist gering (mehr Sterne = Der Prozess ist unter den jeweiligen Voraussetzungen besser geeignet.) Tabelle 11 - Prozesseignung hinsichtlich Voraussetzung (angepasst) [6, p. 22] Die ungleiche Verteilung der Sterne in Tabelle 11 verdeutlicht, dass sich die Prozesse stark voneinander unterscheiden. Scrum konzentriert sich mehr auf die Prozessebene als Feature Driven Development und Extreme Programming, wodurch der Detailgrad auf Methodenebene geringer ausfällt. Feature Driven Development beschreitet hinsichtlich Organisationsstruktur einen anderen Weg. Während Scrum und Extreme Programming auf selbstgesteuerte Teams setzen, gibt es bei Feature Driven Development klare Hierarchien mit strikter Aufgabentrennung. Hierdurch entsteht ein Vorteil für Feature Driven Development: Es passt sich bequemer in klassische Organisationsstrukturen ein. Eine Sache haben Scrum, Feature Driven Development und Extreme Programming jedoch gemein: Sie vertreten alle die Werte und Prinzipien vom Agile Manifest. Letztlich sind es diese Werte und Prinzipien, die ein agiles Vorgehen ausmachen. Patrick Rehder 60

61 >>> Derzeitiges Vorgehen Master-Thesis 3. Derzeitiges Vorgehen Dieses Kapitel ist in vier Unterkapitel untergliedert: Business-Unit Externe Produkte (CtB10) Vorgehensmodell Techniken und Methoden Umfrage in der Business-Unit Zunächst wird die Business-Unit Externe Produkte vorgestellt, auch die durchgeführten Projekte werden betrachtet. Darauffolgend wird ein allgemeingültiges Vorgehensmodell aufgezeigt, welches das aktuelle Vorgehen beschreibt. Die anschließend beschriebenen Methoden detaillieren das zuvor gezeigte Vorgehensmodell und verdeutlichen den Stand der Business-Unit beim Entwickeln und Steuern von Projekten. Im letzten Kapitel wird die Betrachtung durch das Meinungsbild der Business- Unit abgeschlossen, welches über eine Umfrage ermittelt wurde Business-Unit Externe Produkte (CtB10) Die Commerz Systems GmbH ist organisatorisch in drei Bereiche unterteilt: Steuerung / Service- und Zentralbereiche Run the Bank (RtB) Change the Bank (CtB) Der erste Bereich ist in sechs Business-Units gegliedert. Deren Aufgaben unterteilen sich in: Personalverwaltung, Finanzbuchhaltung und infrastrukturelle Tätigkeiten. Run the Bank teilt sich ebenfalls in sechs Business-Units auf. Diese kümmern sich um die Administration und den Betrieb von Softwaresystemen in der Commerzbank. Die Business-Unit Externe Produkte ist eine von zehn Business-Units aus dem Bereich Change the Bank. Die Aufgaben dieses Bereichs liegen in der Neu- und Weiterentwicklung von Softwaresystemen für die Commerzbank. Insgesamt ist die Commerz Systems GmbH damit in 22 Business-Units untergliedert. Die Business-Unit Externe Produkte umfasst 13 Entwickler (Stand: Mai 2012), welche durch einen Business-Unit Manager geleitet werden. Durch die unterschiedlichen Kenntnisse und Interessen der Team-Mitglieder verfügt die Business-Unit über breit gefächerte fachliche, technische, und methodische Kompetenzen. Neben der täglichen Projekt- und Wartungsarbeit hat das Thema Ausbildung eine hohe Bedeutung in der Business-Unit. Im Folgenden werden die letzten drei großen Projekte der Business-Unit beschrieben. Patrick Rehder 61

62 >>> Derzeitiges Vorgehen Master-Thesis ASTAT ASTAT ist eine branchenunabhängige Softwarelösung für Revisionen. Bei einer Revision handelt es sich um eine Stabsabteilung, zum Beispiel: bei einer Bank oder einem börsennotierten Unternehmen. Sie ist gesetzlich vorgeschrieben und unterstützt den Vorstand im Rahmen seiner Kontrollfunktion. Die Entwicklung der Software wird im Auftrag der Rot AG durchgeführt, welche den Vertrieb übernimmt. ASTAT ist damit das einzige Produkt, welches nicht direkt im Auftrag der Commerzbank entwickelt wird. Hieraus resultiert auch die Bezeichnung der Business-Unit: Externe Produkte. [45, pp. 5, 6] NIOB Die Anwendung NIOB wurde für die unternehmensinterne Nutzung entwickelt. Mit ihr ist es möglich Verträge zu verwalten, in denen externe Dienstleister auf interne Projekte vermittelt werden. Das Datenvolumen beträgt etwa 800 Projekte, auf die rund 1000 Dienstleister aus 500 Firmen vermittelt werden. TANTAL Dieses Projekt entstand im Rahmen der Übernahme der Dresdener Bank durch die Commerzbank. Es handelt sich um ein Produkt zur Depotverwaltung von fondgebundenen Rentenversicherungen, welche über die Allianz vermittelt und dessen zugehöriges Depot von der Commerzbank verwaltet wird. Da die EDV Systeme der Dresdener Bank komplett abgeschaltet wurden und das alte Softwaresystem für davon betroffene Großrechner konzipiert war, wurde TANTAL komplett neu entwickelt. Nach der Neuentwicklung wurde die Wartung für dieses Produkt übernommen. Patrick Rehder 62

63 >>> Derzeitiges Vorgehen Master-Thesis 3.2. Vorgehensmodell Das Vorgehensmodell zur Softwareentwicklung in der Business-Unit Externe Produkte kann nicht ohne weiteres durch ein klassisches Vorgehensmodell beschrieben werden. Dies ist deswegen schon schwierig, da sich das Vorgehen in den einzelnen Projekten voneinander unterscheidet. Dennoch lassen sich Gemeinsamkeiten erkennen, die über ein allgemeines Vorgehensmodell beschrieben werden (siehe Abbildung 9). [nach Vorabtest] Analyse Design Implementierung Test Verteilung [nächstes Release] Abbildung 9 - Allgemeines Vorgehensmodell Das allgemeine Vorgehensmodell lässt fünf Phasen erkennen, die nacheinander durchschritten werden. Dieses Vorgehen erinnert auf den ersten Blick an das Wasserfallmodell. Auch die Inhalte der Phasen spiegeln sich im Wasserfallmodell wieder: In der Analysephase werden die Anforderungen der zu entwickelnden Anwendung bestimmt und dokumentiert. Die technische Umsetzung wird in der Designphase besprochen und festgehalten. Während der Implementierung wird der Quelltext der Anwendung geschrieben, aber auch Maßnahmen zur Qualitätssicherung durchgeführt. Die Testphase wird in Form von Vorabtests oder eines Systemtest durchlaufen. Bei der Verteilung wird ein Installationspaket zusammen- und bereitgestellt. Hierbei wird ein Projekt durch alle Phasen von einem Team erfahrener Entwickler begleitet. Im Übergang von der Designphase zur Implementierung werden weitere Entwickler hinzugezogen. Die erfahrenen Entwickler stellen Aufgaben für die neuen Entwickler bereit und stehen für Fragen zur Verfügung. Der Kontakt zum Kunden erfolgt größtenteils über die erfahrenen Entwickler. Im allgemeinen Vorgehensmodell ist der Rücklauf von der Test- zur Analysephase auffällig. Während eines geplanten Release werden ein oder mehrere Vorabtests durchgeführt. Bei einem solchen Vorabtest werden neben Fehlern, auch Änderungswünsche des Kunden identifiziert. Sofern der Umfang der gewünschten Änderung nicht nennenswert 26 ist, wird die Änderung als Kleinstaufgabe aufgenommen und von einem Entwickler abgearbeitet. Ansonsten wird der Änderungswunsch durch 26 Nicht nennenswert sind beispielsweise kleine Änderungen an der Benutzeroberfläche, wie das Ändern einer Beschriftung oder das Verschieben eines Kontrollelements. Patrick Rehder 63

64 >>> Derzeitiges Vorgehen Master-Thesis das Entwicklungs-Team analysiert und geschätzt. Übersteigt der geschätzte Aufwand die Kapazität des Entwicklungs-Teams, muss der Kunde eine der folgenden Optionen wählen: Die Änderung soll nicht durchgeführt werden. Der Umfang vom Release wird verringert. Der Zeitraum für das Release wird vergrößert. Durch Vorabtests wird auch sichergestellt, dass der Kunde nicht erst im Systemtest bemerkt, dass die Anwendung nicht seinen Wünschen entspricht. Ein Release läuft im Schnitt über fünf Monate (siehe Tabelle 12). Da je Release ein bis zwei Vorabtestzyklen durchlaufen werden, umfasst ein Zyklus zwischen ein- und zweieinhalb Monaten. Projekt Version Dauer Projekt Version Dauer ASTAT 1 5 Monate NIOB 1 4 Monate ASTAT 2 5 Monate TANTAL 1 6 Monate ASTAT 3 4 Monate TANTAL 2 6 Monate Tabelle 12 - Projektdauer je Release (Dauer gerundet) Das allgemeine Vorgehensmodell deckt sowohl die Neu-, als auch die Weiterentwicklung ab. Nicht betrachtet wird hingegen das Vorgehen bei der Wartung von Software, welche sich vor allem durch kontinuierlich auftauchende Aufgaben auszeichnet Vorgehensmodell: ASTAT Abbildung 10 bildet das Vorgehen bei der Weiterentwicklung von ASTAT ab. Für die Abbildung gilt: In der linken, oberen Ecke ist je Phase zu erkennen, ob der Kunde oder das Entwicklungs-Team (E- Team) maßgeblich involviert ist. Kunde E-Team Kunde/E-Team E-Team Fachkonzept erstellen Fachkonzept schätzen Fachkonzept anpassen DV-Konzept anpassen E-Team Kunde Kunde E-Team Setup bereitstellen Systemtest durchführen Vorabtest durchführen Implementierung durchführen [Entwicklung abgeschlossen] Abbildung 10 - Vorgehen bei der Weiterentwicklung von ASTAT Die Analyse-Phase ist im abgebildeten Vorgehensmodell in drei Schritte unterteilt. Zu Beginn erstellt der Kunde das Fachkonzept, welches die im Release umzusetzenden Funktionen nennt und beschreibt. Nachfolgend werden die im Fachkonzept enthaltenen Themen durch das Entwicklungsteam Patrick Rehder 64

65 >>> Derzeitiges Vorgehen Master-Thesis geschätzt. Da der Zeitraum für das Release und die vom Entwicklungs-Team zu erbringende Leistung meist festgelegt sind, kann nur der Umfang variieren. Damit die Anforderungen von der zur Verfügung stehenden Kapazität gedeckt werden, wird das Fachkonzept entsprechend angepasst. Außerdem wird das Fachkonzept in diesem Schritt weiter detailliert und Fehler korrigiert. Aufbauend auf dem Fachkonzept, wird das Datenverarbeitungskonzept (DV-Konzept) erstellt. Dieser Schritt beschreibt die Design-Phase aus dem allgemeinen Vorgehensmodell. Das Datenverarbeitungskonzept beschreibt aus technischer Sicht, wie die Funktionen umgesetzt werden sollen. Da ASTAT weiterentwickelt wird, steht die grundlegende Architektur der Anwendung bereits fest. Die Schritte Implementierung, Vorab-, Systemtest und das Bereitstellen eines Setups weisen keine nennenswerten Merkmale auf, die nicht bereits genannt wurden Vorgehensmodell: NIOB Das Vorgehen bei der Neuentwicklung von NIOB ist in Abbildung 11 dargestellt. Kunde/E-Team E-Team E-Team [Entwicklung abgeschlossen] Kunde Anforderungen ermitteln DV-Konzept erstellen Implementierung durchführen Systemtest durchführen Diskussion mithilfe von Entwürfen der Benutzeroberfläche Kunde Vorabtest durchführen [nächste Stufe] E-Team Anwendung verteilen Abbildung 11 - Vorgehen bei der Neuentwicklung von NIOB Die Neuentwicklung von NIOB erfolgte in zwei Stufen, wobei das Vorgehensmodell je Stufe durchlaufen wurde. Im Gegensatz zum Vorgehen bei ASTAT sammelte der Kunde seine Anforderungen nicht in einem Fachkonzept. Der Kunde und das Entwicklungs-Team entwickelten die Anforderungen in einem Gespräch und hielten diese im Datenverarbeitungskonzept fest. Bei den Gesprächen halfen Entwürfe der Benutzeroberfläche ein gemeinsames Verständnis der Benutzeroberfläche zu schaffen. Die Designphase fiel entsprechend gering aus, da dieselbe Architektur wie bei ASTAT genutzt wurde. Die Schritte Implementierung, Vorab- und Systemtest weisen keine nennenswerten Merkmale auf, die nicht bereits genannt wurden. Da es sich bei NIOB um ein internes Projekt handelte, wurde die Verteilung der Software vom Entwicklungs-Team in Kooperation mit der Infrastruktur durchgeführt. Patrick Rehder 65

66 >>> Derzeitiges Vorgehen Master-Thesis Vorgehensmodell: TANTAL In der folgenden Abbildung 12 wird das Vorgehensmodell bei TANTAL beschrieben. Kunde Konzept vom Altsystem Kunde/E-Team Konzeption Neusystem Fach- und Datenverarbeitungskonzept Use Cases E-Team UML Klassen, Ablauf- und Sequenzdiagramme Datenmodell E-Team Design entwerfen Installationspaket bereitstellen E-Team Implementierung durchführen Kunde Kunde Vorabtest durchführen Systemtest durchführen [Entwicklung abgeschlossen] Abbildung 12 - Vorgehen bei der Neuentwicklung von TANTAL Die Anforderungen an TANTAL ergaben sich weitgehend aus dem Altsystem, welches mit einigen Anpassungen nachgebildet werden sollte. Der Kunde stellte das Konzept des Altsystems bereit, auf dessen Basis ein Konzept für das Neusystem entwickelt wurde. Hierbei wurden vom Entwicklungs- Team Use Cases erarbeitet, die mit dem Kunden abgestimmt wurden, aber auch ein Fach- und ein Datenverarbeitungskonzept. Ein Use Case bildete jeweils die Grundlage für eine Aufgabe, die von einem Entwickler bearbeitet wurde. Design und Implementierung hingen in diesem Fall eng zusammen. Jeder Use Case wurde von einem Entwickler durch ein UML Ablauf- oder Sequenzdiagramm dargestellt. Die dabei identifizierten Klassen und Methoden wurden in ein Klassendiagramm eingefügt. Nachdem die Ergebnisse einem informellen Review unterzogen wurden, konnte der Entwickler mit der Umsetzung beginnen. Die Schritte Vorab-, Systemtest und Bereitstellen des Installationspakets weisen keine nennenswerten Merkmale auf, die nicht bereits genannt wurden. Patrick Rehder 66

67 >>> Derzeitiges Vorgehen Master-Thesis 3.3. Techniken und Methoden In diesem Kapitel werden einzelne Techniken und Methoden genannt, die in den Projekten Anwendung gefunden haben. Freiräume Damit sich das Vorgehen in der Business-Unit Externe Produkte verbessern und weiterentwickeln kann, werden Freiräume 27 vorgesehen. Freiräume bieten Teammitgliedern die Möglichkeit sich mit neuen Technologien, Prozessen und Methoden auseinandersetzen; beispielsweise beim Vorstellen von Themen durch Kollegen oder dem Besuch von Schulungen und Konferenzen. Es ist aber auch die Zeit gemeint, um neue Ideen umsetzen und etablieren zu können den Veränderungen benötigen Zeit zur Ein- und zur Durchführung. Die Freiräume sind nicht fest vorgegeben, sondern werden nach Bedarf genommen. Hierbei bedarf es der Zustimmung des Vorgesetzten, dem Business-Unit Manager. Damit ist es entscheidend, dass der Vorgesetzte den Nutzen von Freiräumen erkennt und diese auch gewährt. In der Business-Unit Externe Produkte ist dies der Fall. Die Methode Slack (siehe Seite 53) von Extreme Programming beschreibt ähnliches. Architecture Board Das Architecture Board besteht aus drei bis fünf erfahrenen Entwicklern. Diese treffen sich einmal in der Woche, um projektübergreifende Architekturthemen zu besprechen. Zum Beispiel: Verwendung neuer Technologien, Aufstellen von Programmierrichtlinien und Diskussionen über Zweckmäßigkeit von gemachten Umsetzungen. Jeder Entwickler hat außerdem die Möglichkeit Themen im Architecture Board zu platzieren; über diese Themen wird beraten und ein Vorgehen vorgeschlagen. Dies zeigt, dass es sich beim Architecture Board um eine beratende Einheit handelt. Bei Extreme Programming findet sich mit der Quick Design Session aus der Methode Incremental Simple Design (siehe Seite 53) eine ähnliche Einrichtung. Stand-Up Meetings Zweimal in der Woche trifft sich die Business-Unit zum Stand-Up Meeting. Dieses Treffen lehnt sich an die Idee des Daily Scrums (siehe Seite 23) an und soll 30 Minuten nicht überschreiten. Im Stehen sind von jedem Teilnehmer drei Fragen zu beantworten: 1. Was habe ich seit dem letzten Meeting erreicht? 2. Was will ich bis zum nächsten Meeting erreichen? 3. Welches Problem hindert(e) mich an der Erreichung? 27 Warum Freiräume so wichtig sind wird von Tom DeMarco in seinem Buch Slack [70] beschrieben. Patrick Rehder 67

68 >>> Derzeitiges Vorgehen Master-Thesis Planning Poker Planning Poker ist eine Methode zum Schätzen mit mehreren Personen. Der Begriff wurde 2002 von James Grenning [46] eingeführt und über das Buch Agile Estimation and Planning von Mike Cohn [47] weit verbreitet. Mittlerweile stellt Planning Poker einen essentiellen Bestandteil des agilen Methodenkoffers dar. Beim Planning Poker gibt es zwei Arten von Teilnehmern: Kunden und Entwickler. Der Kunde bringt die zu schätzenden Themen ein und steht für Fragen zur Verfügung. Die Entwickler schätzen die Themen gemeinsam ein. Hierzu erhält jeder Entwickler einen Satz Planning Poker Karten, wie in Abbildung 13 dargestellt. Ist bereits umgesetzt. oder Kann in wenigen Minuten umgesetzt werden. 0 ½ ? c Ich brauche mehr Informationen, bevor ich schätzen kann. Diese Anforderung ist zu groß zum Schätzen. Ich brauche eine Pause. Abbildung 13 - Umfassender Kartensatz für Planning Poker Die Zahlenkarten repräsentieren ihren Wert in einer festzulegenden Einheit. Ein Kartensatz muss nicht unbedingt alle der abgebildeten Karten enthalten. So bestand der ursprüngliche Kartensatz von James Grenning aus den Werten: 1, 2, 3, 5, 7, 10 und dem Unendlichkeitszeichen. Bei einer Schätzung in Tagen war es somit nicht möglich, über zwei Wochen zu schätzen. Dies zwingt den Kunden dazu, die Anforderungen feiner zu gliedern; Grenning erachtet dies für sinnvoll. [46, p. 3] Durchgesetzt haben sich jedoch die Werte von Mike Cohn, welche sich an die Fibonacci-Folge 28 anlehnen. Durch die sich vergrößernden Abstände zwischen den Werten, wird die Unsicherheit beim Schätzen großer Anforderungen berücksichtigt. [23, p. 50] Je zu schätzender Anforderung werden die folgenden Schritte durchlaufen: 1. Der Kunde stellt die zu schätzende Anforderung vor. 2. Unklarheiten zur Anforderung werden in der Gruppe diskutiert. 3. Jedes Mitglied der Schätzrunde wählt verdeckt eine Karte. 4. Sobald alle gewählt haben, werden die gewählten Karten aufgedeckt. 5. Eine der folgenden Situationen tritt ein: a. Alle Karten sind nahezu identisch; das Schätzergebnis steht fest. b. Die Karten weichen voneinander ab. In diesem Fall wird über die Abweichung gesprochen. Diejenigen mit dem kleinsten und dem größten Wert stehen hierbei im 28 Fibonacci-Folge: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, Patrick Rehder 68

69 >>> Derzeitiges Vorgehen Master-Thesis Vordergrund. Danach wird eine neue Schätzrunde durchgeführt. Dies wird solange wiederholt, bis sich auf ein Schätzergebnis geeinigt wurde. In den Projekten ASTAT und TANTAL wurden die Anforderungen in der Analyse-Phase mithilfe von Planning Poker geschätzt. Als Einheit wurden Personentage gewählt. Außerdem war der Kunde in den Schätzrunden nicht vor Ort, stattdessen wurde auf Basis vom Fachkonzept oder der Use Cases geschätzt. Unklarheiten wurden hierbei notiert und zur nächsten Runde Planning Poker geklärt. Visual Studio Team Foundation Server Den Projekten ASTAT, NIOB und TANTAL ist die Verwendung der gleichen Programmiersprache gemein; alle Projekte nutzen C#. Da C# von Microsoft entwickelt wird ist Visual Studio die Entwicklungsumgebung der Wahl. Als zentrale Plattform, für die Softwareentwicklung in Teams, bietet Microsoft den Visual Studio Team Foundation Server an. Der Visual Studio Team Foundation Server wird in der Business-Unit Externe Produkte für folgende Aufgaben verwendet: Versionsverwaltung des Quelltextes Verwaltung der Aufgaben (Work Item Tracking) zentralisierte Builds (Team Builds) Der Funktionsumfang vom Team Foundation Server wird damit im Kern ausgeschöpft. [48] Analoges Task Board An einer großen freien Wand wurde ein Whiteboard angebracht, dass eine Fläche von etwa 2m 4,5m hat. Dieses Whiteboard wird unter anderem als Task Board genutzt. Ein Task Board ist eine tabellarische Darstellung von Aufgaben, die den aktuellen Stand je Aufgabe darstellt. (siehe Abbildung 14) Folgende Punkte sind im Zusammenhang zum Task Board zu nennen: Die Methode ist leicht zu verstehen und mit einfachen Mitteln durchzuführen. Abbildung 14 - Schema: Task Board [25, p. 12] Es entsteht ein Aufgabenpool, an dem sich die Entwickler bedienen können. Die aufgrund der Kartengröße in Kürze notierten Aufgaben sind ohne Kontextwissen nur zu erahnen. Hierdurch werden Diskussionen im Team und mit dem Kunden angeregt. Der Fortschritt kann auf einen Blick erkannt werden. Patrick Rehder 69