Integration agiler Entwicklungszyklen in das V-Modell auf Basis von Informationsflüssen

Größe: px
Ab Seite anzeigen:

Download "Integration agiler Entwicklungszyklen in das V-Modell auf Basis von Informationsflüssen"

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Integration agiler Entwicklungszyklen in das V-Modell auf Basis von Informationsflüssen Masterarbeit im Studiengang Informatik von Stephan Kiesling Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Dr.-Ing. Eric Knauss Betreuer: M. Sc. Kai Stapel Hannover,

2 Zusammenfassung Um die Vorteile sowohl dokumentenlastiger, als auch agiler Prozesse in einem einzigen Projekt nutzen zu können, wird in dieser Arbeit am Beispiel von SCRUM ein agiler Entwicklungsprozess in das V-Modell XT integriert. Die Integration geschieht auf Basis von Informationsflüssen. Es werden zuerst Informationsflüsse in beiden Prozessen ermittelt und analysiert. Anschließend werden die Informationsflüsse an den Schnittstellen der Prozesse angepasst, so dass eine Integration möglich wird. Zum Schluss werden Integrationsvarianten beispielhaft angegeben, um unterschiedliche Integrationsbereiche zu kennzeichnen. Diese können mit Hilfe eines Leitfadens an die Bedürfnisse von Unternehmen angepasst werden. ii

3 Inhaltsverzeichnis 1 Einleitung Motivation Ziele der Arbeit Aufbau der Arbeit Grundlagen Vorgehensmodelle bei der Softwareentwicklung Dokumentenlastige Prozesse Agile Methoden V-Modell V-Modell XT SCRUM FLOW FLOW-Notation FLOW-Methode Einordnung der Arbeit mit Hilfe der FLOW-Methode Informationen und Informationsflüsse Informationsflüsse in SCRUM und im V-Modell XT Grundidee Annahmen Beschreibung von SCRUM auf Basis von Informationsflüssen Beschreibung des V-Modells auf Basis von Informationsflüssen Produktabhängigkeiten Von den Produktabhängigkeiten zum Informationsfluss Anpassung von SCRUM an die Informationsflüsse des V-Modells Grundlegende Schnittstellenvarianten Schnittstellenvariante 1: Elementarer Informationsfluss Schnittstellenvariante 2: Sequentieller Informationsfluss Schnittstellenvariante 3: Paralleler Informationsfluss Schnittstellenvariante 4: Informationsfluss mit mehreren Eingängen Schnittstellenvariante 5: Informationsfluss mit mehreren Ausgängen Anpassung von SCRUM Kunde SCRUM Master Product Backlog iii

4 Inhaltsverzeichnis Product Owner SCRUM Team Daily SCRUM Meetings Sprint Planning Meeting Sprint Sprint Review Vor- und Nachteile der Integration Vorteile Nachteile Probleme bei der Integration von SCRUM Integrationsvarianten von SCRUM in das V-Modell XT Integrationsvarianten auf Basis von Entscheidungspunkten Variante 1: SCRUM für Systementwicklung Variante 2: SCRUM für Komponentenentwicklung Variante 3: SCRUM für Entwurf Variante 4: SCRUM für Realisierung, Integration und Test Allgemeine Variationen Anzahl der eingesetzten Teams Endpunkt der Integration von SCRUM für Entscheidungspunkte Integration von SCRUM ohne Entscheidungspunkte Integration von SCRUM für einzelne Informationsflüsse Nachdokumentation Implementierung Prototypische Entwicklung zur Ermittlung und Darstellung von Produktabhängigkeiten des V-Modells Funktionsweise Technische Realisierung Leitfaden zur Integration von SCRUM in das V-Modell XT Gewichtung der Kriterien des Leitfadens Fazit Kritische Würdigung Ausblick iv

5 1 Einleitung 1.1 Motivation Dokumentenlastige Prozesse wie das V-Modell sind in der Regel, auf Grund des hohen Anteils zu erstellender Dokumente, sehr unflexibel. Späte Änderungen der Anforderungen verursachen einen hohen Zeit- und Kostenaufwand und sind in vielen Fällen nur durch Nachverhandlung mit dem Kunden möglich. Zudem fließt ein hoher Anteil der Projektzeit in die Erstellung vieler Dokumente. Diese Nachteile versuchen die agilen Methoden, ihnen voran SCRUM, zu beheben, indem funktionierende Software wichtiger als umfassende Dokumentation gesetzt wird. Kundenzufriedenheit wird als höchstes Gut betrachtet, Flexibilität als Grundvoraussetzung angesehen. Dadurch gehen allerdings einige Vorteile, welche die umfassende Erstellung von Dokumenten mit sich bringt, verloren. Auf Grund der Unterschiede zwischen dokumentenlastigen und agilen Prozessen ist es nicht offensichtlich, wie diese in einem Projekt zu vereinen sind. Gelingt dies aber, ist es vorstellbar, dass sowohl die Vorteile dokumentenlastiger Prozesse, als auch die Vorteile agiler Methoden genutzt werden können. 1.2 Ziele der Arbeit In dieser Arbeit soll SCRUM, als die häufigste, in Projekten verwendete agile Methode, in das V-Modell XT integriert werden, um die Vorteile beider Prozesse ausnutzen zu können und ihre Nachteile möglichst gering zu halten. Die Integration selbst soll auf Basis von Informationsflüssen geschehen, da viele relevante Softwareentwicklungsphänomene mit Informationsflüssen beschrieben werden können. Die Arbeit soll eine Vorgehensweise beschreiben, mit dessen Hilfe Unternehmen SCRUM in ihren V-Modell-basierten Entwicklungsprozess einbinden können. Dazu soll aufgezählt werden, welche Anpassungen vorgenommen werden müssen, damit eine Integration von SCRUM durchgeführt werden kann. Zudem werden Varianten angegeben, die sich für die Integration gut oder weniger gut eignen. 1

6 1 Einleitung 1.3 Aufbau der Arbeit Die Arbeit gliedert sich in insgesamt sieben Kapitel. In gewisser Weise beschreibt diese Gliederung, wie in Abbildung 1.1 dargestellt wird, ebenfalls eine Art V. Nach den in diesem Kapitel vorgenommenen, einleitenden Worten, werden in Kapitel 2 die Grundlagen erklärt, die für diese Arbeit benötigt werden. Ausgehend von diesen Grundlagen wird in Kapitel 3 ein Abstraktionsschritt nach unten durchgeführt, der das V-Modell und SCRUM auf Basis von Informationsflüssen beschreibt. Basierend auf den Informationsflüssen werden in Kapitel 4 Anpassungen an SCRUM vorgenommen. Anschließend werden die so entstandenen Informationsflüsse von SCRUM am Beispiel von Integrationsvarianten in den gesamten Informationsfluss des V-Modells integriert, was in Kapitel 5 geschieht. Zum Schluss gibt der in Kapitel 6 vorgestellte Leitfaden eine grundlegende Übersicht über die Integration, wie auch der Prototyp zur Ermittlung und Darstellung von Produktabhängigkeiten des V-Modells eine Übersicht über die Informationsflüsse des V-Modells vermittelt. Ein Fazit der vorherigen 6 Kapitel wird in Kapitel 7 vorgenommen. Abbildung 1.1: Graphische Visualisierung der Gliederung dieser Arbeit 2

7 2 Grundlagen 2.1 Vorgehensmodelle bei der Softwareentwicklung Unter einem Vorgehensmodell oder auch Softwareentwicklungsprozess versteht man eine Vorgehensweise oder ein Modell, das ein genaues Vorgehen zur Herstellung von Software spezifiziert [SCHNEIDER 2010]. Dabei werden die Ingenieursprinzipien Kostendenken Qualitätsbewusstsein Anwendung von Normen und Regeln Baugruppen und Wiederverwendung Probleme durch Zerlegung lösen genau berücksichtigt, um eine schnelle, qualitativ hochwertige Erstellung von Software zu gewährleisten. Ein derartiges Vorgehensmodell dient als Aufbau- und Ablaufplan, um Software koordiniert zu erstellen. Dadurch wird der Vorgang der Softwareentwicklung verbessert und standardisiert. Die Entwicklung einzelner Teilstücke wird zeitlich und kontextuell begrenzt. Für jeden Entwicklungsschritt kann der Plan angeben, welches Produkt aus dem jeweiligen Schritt entstehen soll. Dies können zum Beispiel fertige Teilstücke oder auch Dokumente sein, an die wiederum vom Entwicklungsprozess Qualitätsbedingungen gestellt werden können. Außerdem lässt sich das Projekt einfacher planen und der aktuelle Entwicklungsstand des Projekts besser einschätzen. Im Laufe der Zeit haben sich zwei große, gegensätzliche Vorgehensmodelltypen entwickelt, die nachfolgend dargestellt werden sollen Dokumentenlastige Prozesse Die folgenden Grundlagen basieren auf [SCHNEIDER 2010, vor]. Der Fortschritt eines dokumentenlastigen Prozesses wird an der Erstellung von Dokumenten gemessen, was wiederum durch das Verarbeiten von Dokumenten geschieht. Ob ein Prozess starten kann, hängt davon ab, ob die benötigten Dokumente vorliegen. Ebenso ist ein Prozess beendet, wenn die erzeugten Dokumente den geforderten Dokumenten entsprechen. Es stehen also die Dokumente eines solchen Prozesses im Vordergrund. Zu Beginn eines jeden Projekts muss überlegt werden, welches Vorgehensmodell ein- 3

8 2 Grundlagen gesetzt werden soll. Dies ist keine leichte Entscheidung und kann zusätzlich erhebliche Kosten verursachen, wenn das falsche Vorgehensmodell gewählt wurde. Die Wahl des Vorgehensmodells hängt von vielen Faktoren ab. Die wichtigsten sind: Akzeptanz im Unternehmen Vertrautheit mit Vorgehensmodellen und Tools Standardsoftware im Unternehmen Implementierungsfähigkeiten des Vorgehensmodells Nutzen, den dieses Vorgehensmodell bringt Kosten, die dieses Vorgehensmodell verursacht Betrachtung, ob V-Modell ein möglicher Kandidat ist Dies sind nur einige der Fragen, die bei der Wahl des passenden Vorgehensmodells in Betracht gezogen werden müssen. Es ist empfehlenswert zu prüfen, ob das V-Modell geeignet ist. Die Gesellschaft für Informatik [vor] empfiehlt auf jeden Fall zu prüfen, ob das V-Modell geeignet ist und hebt dieses namentlich hervor. Neben dem V-Modell gibt es allerdings noch weitere Modelle: Wasserfallmodell Das Wasserfallmodell unterteilt den Prozess der Softwareentwicklung in unterschiedliche Phasen. Jede Phase (bis auf die erste) benötigt als Eingabe die Ausgabe der vorherigen Phase. Alle Phasen werden nacheinander abgearbeitet. Im erweiterten Wasserfallmodell sind Rücksprünge zu vorherigen Phasen möglich. Spiralmodell Nach dem Wasserfallmodell folgte das Risiko-getriebene Spiralmodell. Im Projekt auftretende Risiken sollen dabei möglichst früh erkannt und entschärft werden. Die Idee ist, alle Risiken zu suchen und jeweils das größte Risiko zu eliminieren. Gibt es keine Risiken mehr, ist das Projekt erfolgreich abgeschlossen. Ist das größte Risiko nicht zu eliminieren, ist das Projekt gescheitert. V-Modell / V-Modell XT Eine detaillierte Beschreibung des V-Modells wird in Kapitel 2.2 gegeben. Allerdings sind Änderungs- oder Anpassungswünsche am Konzept des Produkts oder der Software selbst abhängig vom gewählten Vorgehensmodell nicht immer leicht durchzuführen. Oft werden späte Änderungen vom Kunden teuer bezahlt oder sind schlimmstenfalls nicht umsetzbar. Dies liegt in der Natur der Vorgehensmodelle, die mehr oder weniger starr ablaufen. Das Wasserfallmodell sieht beispielsweise ursprünglich nicht vor, dass Stufen, die bereits durchlaufen wurden, erneut aufgegriffen werden können Agile Methoden Die in Kapitel beschriebenen Prozesse verlangen viele Dokumente (Lastenheft, Pflichtenheft, Dokumentation der Anforderungen, Dokumentation des Grobentwurfs, 4

9 2 Grundlagen Dokumentation des Feinentwurfs und viele mehr) und somit einen sehr hohen Zeitaufwand für das Erstellen dieser Dokumente, was gleichzeitig eine geringere Zeitspanne für die eigentliche Implementierung nach sich zieht. Dies führte zu der Entwicklung der Agilen Methoden und dem Manifesto for Agile Software Development [agi] und kann als Gegenbewegung zu den dokumentenlastigen Prozesse verstanden werden. Das Agile Manifesto besagt Folgendes [agi]: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. [Wir enthüllen bessere Wege der Softwareentwicklung, indem wir Software entwickeln und anderen dabei helfen, Software zu entwickeln. Aufgrund dieser Tätigkeit sind wir zu dem Schluss gekommen, die folgende Wertung vorzunehmen: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge Funktionierende Software ist wichtiger als eine umfassende Dokumentation Kundenzusammenarbeit ist wichter als Vertragsaushandlungen Auf Änderungen zu reagieren ist wichtiger als einem Plan zu folgen Obwohl die Aspekte auf der rechten Seite auch wichtig sind, gestehen wir den Aspekten auf der linken Seite ein höheres Gewicht zu.] Basierend auf [SCHNEIDER 2011] zeichnen sich Agile Methoden durch einige Aspekte besonders aus. Sie liefern früh erste Ergebnisse, die dem Kunden präsentiert werden können. Dadurch kann der Kunde abschätzen, ob das Projekt in die richtige Richtung geht. Unklar formulierte Anforderungen werden leicht als solche erkannt und können genauso leicht durch Zusammenarbeit mit dem Kunden geklärt werden. Späte Änderungen des Kunden können zeitnah durchgeführt werden und es wird eine hohe Qualität erreicht. Diese Aspekte sind umso wichtiger, da der Zeitdruck für aktuelle Projekte immer größer wird. Deutlich wird auch, dass die Zusammenarbeit mit dem Kunden im Vordergrund steht. Eines der wichtigsten Ziele der Agilen Methoden ist, Software-Entwicklung flexibler zu machen. Dies wird versichert, indem sogenannte Grundwerte, Prinzipien und Praktiken definiert wurden. Die Grundwerte (vergleiche Agile Manifesto oben) dienen als gemeinsame Basis. Von ihnen werden die Prinzipien abgeleitet. Aus den Prinzipien ergeben sich wiederum die Praktiken, die für jede Agile Methode (z.b. SCRUM, vergleiche Kapitel 2.3) anders 5

10 2 Grundlagen formuliert sein können. Zur Verdeutlichung sei das folgende Beispiel gegeben: Ein Grundwert ist gemäß dem Agile Manifesto Kundenzusammenarbeit ist wichtiger als Vertragsaushandlungen. Dies wird zum Beispiel durch die Prinzipien Höchste Priorität: Kundenzufriedenheit, Direkte Mensch-zu-Mensch Kommunikation und Auch späte Änderungen werden willkommen geheißen genauer umgesetzt. Die konkrete Umsetzung der Prinzipien geschieht unter anderem durch die Praktiken (in diesem Fall von Extreme Programming) On-site Customer, Short Releases und Planning Game. Hohe Flexibilität wird insbesondere durch die höchste Priorität für Kundenzufriedenheit und die daraus resultierende enge Zusammenarbeit mit dem Kunden gewährleistet. Ohne hohe Flexibilität ist eine hohe Kundenzufriedenheit nur sehr schwer zu erreichen. 2.2 V-Modell Das V-Modell 1 ist nach [LUDEWIG. LICHTER 2007, Seiten ], [vmo] ein international anerkannter Entwicklungsstandard für IT-Systeme, der einheitlich und verbindlich festlegt, was zu tun ist, wie die Aufgaben durchzuführen sind und womit dies zu geschehen hat. Es umfasst das Vorgehensmodell, die Methodenzuordnung und die funktionalen Werkzeuganforderungen [vmo]. Dabei steht das V nicht nur für Vorgehen, sondern auch für die Idee, die hinter dem V-Modell steckt. Die Aufgabenbereiche Spezifikation und Zerlegung auf der einen Seite stehen der Realisierung und Integration auf der anderen Seite gegenüber. Abbildung 2.1 zeigt einen möglichen Ablauf in der Systementwicklung, welche zwischen der Projektplanungs- und abschlussphase durchgeführt wird. Letztere laufen in der Regel linear ab, während das eigentliche V nur in der Systementwicklung auftaucht. Die Entwicklung des ersten V-Modells begann im Jahr 1986 und wurde vom deutschen Bundesministerium für Verteidigung in Auftrag gegeben, worauf im Jahr 1993 eine allgemeine Fassung für sämtliche Bundesbehörden folgte. Im Jahr 1997 wurde das V-Modell überarbeitet, um es an gängige Entwicklungsstandards und -ansätze anzupassen. Im Februar 2005 entstand aus dem V-Modell das V-Modell XT, welches Firmen mehr Flexibilität in Bezug auf die Anpassung des V-Modells an die eigene Unternehmensstruktur bieten sollte (vergleiche Kapitel 2.2.1). Da das V-Modell 1996 öffentlich zugänglich gemacht wurde, war es für Unternehmen möglich, das V-Modell ohne das Risiko einer Fehlinvestition leicht auszuprobieren. Dadurch nahm die Verbreitung des V-Modells zu und es konnten Erfahrungen über die Benutzung und den Umgang mit dem V-Modell gemacht werden. Diese Erfahrungen wurden dokumentiert und flossen in die Entwicklung des V-Modells 97 ein. Das V-Modell ist bei den Beauftragten der Bundesregierung für Informationstechnik erhältlich [vmo]. Es liegt aktuell in der Version 1.3 vor und beinhaltet Werkzeuge zur Anpassung der Prozesse an die Bedürfnisse des Unternehmens und zur Durchführung 1 V-Modell R ist eine geschützte Marke der Bundesrepublik Deutschland 6

11 2 Grundlagen und Planung des Projekts, sowie eine umfassende Dokumentation, die sich selbst als Pflichtlektüre für jeden Entwickler bezeichnet, der mit dem V-Modell arbeitet. Externe Vorgaben (AG) Rahmenbedingungen (für SE 1.7) Protokoll System (installiert und in Betrieb) SE 1 System-Anforderungsanalyse SE 1.1 bis SE 1.8 SWPÄ-Konzept SE 9 Überleitung in die Nutzung SE 9.1 bis 9.3 Anwenderforderungen Produktinformationen Kosten-/Nutzenanalyse Angebotsbewertung Betriebsinformationen System (installierbar) SE 2 System-Entwurf SE 2.1 bis SE 2.6 Integrationsplan SE 8 System-Integration SE 8.1 bis SE 8.3 System- Ebene Schnittstellenübersicht Systemarchitektur Schnittstellenbeschreibung Betriebsinformationen Technische Anforderungen SW-Einheit Implementierungsdokumente (SW-Einheit) HW-Einheit Nicht-IT-Anteile SE 3 SW-/HW-Anforderungsanalyse SE 3.1 bis SE 3.5 Betriebsinformationen Technische Anforderungen SE 4-SW SW-Grobentwurf SE 4.1-SW bis SE 4.3-SW SE 7-SW SW-Integration SE 7.1-SW bis SE 7.4-SW Implementierungsdokumente (SW-Komponente) SW-Komponente SW-Einheits-/ HW-Einheits- Ebene SW-Kompo- nenten- Ebene Schnittstellenübersicht Schnittstellenbeschreibung Betriebsinformationen SW-Architektur Datenbank SW-Modul Implementierungsdokumente (SW-Modul, Datenbank) SE 5-SW SW-Feinentwurf SE 5.1-SW und SE 5.2-SW Datenkatalog SW-Entwurf Betriebsinformationen Modul-/Datenbank- Ebene Legende: SE 6-SW SW-Implementierung SE 6.1-SW bis SE 6.3-SW Prüfaktivitäten (siehe QS) Abbildung 2.1: Systementwicklung im V-Modell 97 [vmo, Dokumentation V-Modell, Kapitel 4: Regelung Submodell Systemerstellung ] Das V-Modell ist nach [LUDEWIG. LICHTER 2007, Seiten ] durch die folgenden Merkmale charakterisiert: Das V-Modell ist ein aktivitätsorientiertes Modell, das Produkte, Aktivitäten und Rollen miteinander verknüpft. Es ist in sogenannte Phasen, beziehungsweise Projektabschnitte unterteilt, die durch Meilensteine oder auch Entscheidungspunkte voneinander abgegrenzt werden. Die Meilensteine werden derart plat- 7

12 2 Grundlagen ziert, dass eine deutliche Änderung eintritt, wenn ein Meilenstein erreicht und überschritten wird. Wie genau die Meilensteine platziert werden müssen, ist zu Beginn des Projekts noch nicht bekannt und muss daher in der Projektplanung geschätzt werden. Ein Meilenstein ist wie folgt definiert [WALLIN. 2002]: A milestone is defined as a scheduled event that marks the completion of one or more important tasks and it is used to measure achievements and development progress. At a milestone, a predefined set of deliverables should have reached a predefined state to enable a review. Das V-Modell ist für unterschiedliche Projektarten einsetzbar. Die ursprüngliche Version beschäftigt sich nur mit der Erstellung von Software. In der Version von 1997 wird zusätzlich die Hardware-Entwicklung unterstützt. Das V-Modell XT bietet sogar die Möglichkeit, Projekte durchzuführen, in denen andere Vorgehensmodelle mit Hilfe des V-Modells erstellt werden. Derartige Projekte heißen Metaprojekte. Das V-Modell wird in erster Linie für die Erstellung des eigentlichen Produkts verwendet. Allerdings stehen auch Aspekte wie Qualitätssicherung, Konfigurationsverwaltung und Projektmanagement im Vordergrund und werden unterstützt. Hier unterscheidet sich das V-Modell von anderen Modellen, wie zum Beispiel dem Wasserfallmodell, das diese zusätzlichen Aspekte nicht unterstützt. Das V-Modell lässt sich gut anpassen und erweitern. Dies wird noch einmal besonders durch die neue Version von 2005 unterstrichen (Stichwort: extreme Tailoring ). Das V-Modell besitzt viele weitere Aspekte, die für diese Arbeit grundlegend sind. Allerdings muss im Folgenden zwischen V-Modell 97 und V-Modell XT unterscheiden werden. Da für diese Arbeit ausschließlich das V-Modell XT relevant ist, wird dieses in Kapitel weiter erklärt V-Modell XT Das V-Modell XT ist eine Weiterentwicklung des V-Modells von XT steht dabei für extreme Tailoring. Ein Hauptgrund für die Entwicklung des V-Modells XT ist die mangelnde Flexibilität für Firmen. Nicht jede Firma möchte beziehungsweise kann den gesamten Prozess des V-Modells für jedes V-Modell-Projekt anwenden. Daher bietet das neue V-Modell XT die Möglichkeit, die Projektdurchführung flexibel an das eigene Unternehmen anzupassen. Dabei wird dennoch eine gewisse Qualität des Entwicklungsablaufes und auch des Produkts selbst bewahrt, da einige Schritte für jedes Unternehmen zwingend vorgeschrieben werden (Stichwort: V-Modell-Kern). Diese Anpassung, auf englisch Tailoring, spiegelt sich im Namen des neuen V-Modells wider und kann somit als Hauptneuerung des V-Modells XT angesehen werden. In dieser Arbeit wird im Folgenden der Begriff V-Modell als Synonym für V-Modell XT benutzt. Es werden zwei zentrale Bezeichnungen eingeführt. Die sogenannten Vorgehensbau- 8

13 2 Grundlagen steine sind das Konzept für die Prozesserarbeitung und -anpassung. Sie beinhalten miteinander verknüpfte Produkte und Aktivitäten und Rollen. Abbildung 2.2 zeigt die allgemeine Struktur eines solchen Vorgehensbausteins. Vorgehensbausteine sind die zentrale Einheit des Tailorings und bietet alle Komponenten, die für die Bearbeitung einer im V-Modell gestellten Aufgabenstellung notwendig sind. Jeder Vorgehensbaustein kann einzeln verändert oder erweitert werden. Abbildung 2.2: Vorgehensbaustein aus dem V-Modell [vmo, Dokumentation V-Modell XT, Seite 15] Produkte sind die Ergebnisse oder Zwischenergebnisse, die erzeugt werden. Sie können in Disziplinen zusammengefasst werden, wobei die Produkte einer Disziplin inhaltlich eng zusammengehören müssen. Ein Produkt wiederum kann sich in Themen unterteilen lassen. Themen sind die wesentlichen Bestandteile eines Produkts und werden in Arbeitsschritten bearbeitet. Produkte können voneinander abhängig sein. Die Abhängigkeit kann innerhalb eines Bausteins existieren, aber auch über Bausteine hinaus. Zudem lassen sich Produkte als initiales Produkt oder als externes Produkt kennzeichnen. Ein initiales Produkt ist ein Produkt, das im gesamten Projekt immer und exakt einmal erstellt werden muss (z.b. die Bedienungsanleitung). Ein externes Produkt ist eine Eingabe an das V-Modell. Es wird also nicht während des V-Modell- Projekts erstellt, sondern kommt von anderer Stelle. Allerdings muss ein externes Produkt die vom V-Modell angegebenen Bedingungen erfüllen. Produkte, die nicht initial sind, werden von anderen Produkten des V-Modells erstellt. Im V-Modell XT werden sogenannte Produktabhängigkeiten vorgestellt, die eine Konsistenzbeziehung zwischen mehreren Produkten beschreibt. Das V-Modell definiert fünf unterschiedliche Produktabhängigkeiten. Erzeugende Produktabhängigkeiten bestimmen Bedingungen oder Regeln an die Erstellung nicht initialer Produkte des V-Modells durch andere Produkte. Inhaltliche Produktabhängigkeiten verknüpfen Produkte auf inhaltlicher Ebene. Ändert sich ein Produkt, so können sich alle Produkte, die von diesem Produkt inhaltlich abhängen, ebenfalls ändern. Relevante Produktabhängigkeiten kennzeichnen die Produktabhängigkeiten, welche sich nach Durchführung des Tailorings auf noch mindestens zwei Produkte beziehen. 9

14 2 Grundlagen Strukturelle Produktabhängigkeiten beschreiben, welche Produkte in enger Beziehung zueinander stehen. So kann beispielsweise beschrieben werden, dass eine SW-Einheit aus mehreren SW-Komponenten bestehen, die wiederum aus mehreren SW-Modulen zusammengesetzt sein können. Tailoring Produktabhängigkeiten verdeutlichen die Beziehungen von Produkten zu Vorgehensbausteinen und sind somit für das Tailoring relevant. Produkte werden von Aktivitäten fertiggestellt. Dabei besitzt jedes Produkt genau eine Aktivität, in der es fertiggestellt wird. Aktivitäten, die inhaltlich zusammengehören, werden genau wie Produkte in einer Disziplin zusammengefasst. Dabei werden die zusammengehörigen Produkte und Aktivitäten in derselben Disziplin vereint. Eine Aktivität besteht aus Arbeitsschritten. Sie stellt genau ein Produkt fertig, während die Arbeitsschritte die Themen des Produkts bearbeiten. Arbeitsschritte beziehen sich also immer auf Themen, genauso wie sich Aktivitäten jeder Zeit auf Produkte beziehen. Dabei sind Arbeitsschritte mit einer Arbeitsanleitung vergleichbar. Eine Arbeitsanleitung kann sowohl ein einziges als auch mehrere Themen bearbeiten. Zuletzt muss noch angegeben werden, wer die Aktivitäten durchführt und somit Produkte fertigstellt. Dazu bietet das V-Modell die Rollen. Eine Rolle kann an einem Produkt mitwirken oder auch verantwortlich für ein solches sein. Außerdem gibt eine Rolle die Fähigkeiten an, die für die Aufgaben benötigt werden. Jedem Produkt muss genau eine verantwortliche Rolle zugeteilt sein. Es können aber mehrere Rollen an einem Produkt mitwirken. Erst zu Beginn eines Projekts werden den Rollen konkrete Mitarbeiter zugeteilt. Vorher wird immer von der Rolle selbst gesprochen. Ein V-Modell-Projekt wird in Projektabschnitte unterteilt, was mit Hilfe von Entscheidungspunkten geschieht. Entscheidungspunkte sind das im V-Modell verwendete Konzept zur Projektdurchführung beziehungsweise Projektfortschrittskontrolle. In einem Entscheidungspunkt wird entschieden, ob das Projekt fortgesetzt und der nächste Projektabschnitt begonnen werden kann. Die Kriterien, die für die Entscheidung notwendig sind, werden vom V-Modell XT durch die Produkte, die beim Erreichen des Entscheidungspunkts fertiggestellt sein müssen, definiert. Jeder Entscheidungspunkt fordert Produkte, die zum Überschreiten des Entscheidungspunkts erforderlich sind. Ein Entscheidungspunkt muss immer derart platziert werden, so dass beim Erreichen und Überschreiten des Entscheidungspunkts eine deutliche Änderung eintritt. Die Reihenfolge der im Projekt zu durchlaufenden Entscheidungspunkte wird von der Projektdurchführungsstrategie festgelegt. Diese wird vom zuvor gewählten Projekttyp und dem Anwendungsprofil bestimmt. Abbildung 2.3 zeigt alle im V-Modell XT vorgesehenen Entscheidungspunkte. Das Tailoring beginnt beim V-Modell XT bereits mit der Wahl des Projekttyps, welcher wiederum eine Auswahl von Projekttypvarianten nach sich zieht. Es gibt die folgenden Projekttypen (PT) und Projekttypvarianten (PTV): PT: Systementwicklungsprojekt (AG) Entwicklungsprojekt aus Sicht des Auftraggebers. Der Auftraggeber erstellt eine Ausschreibung und wählt einen Auftragnehmer. Ist System fertiggestellt worden, nimmt der AG das System ab. Es gibt fol- 10

15 2 Grundlagen Abbildung 2.3: Übersicht über alle im V-Modell XT vorgesehenen Entscheidungspunkte [vmo] gende Projekttypvarianten: PTV: AG-Projekt mit einem Auftragnehmer PTV: AG-Projekt mit mehreren Auftragnehmern PT: Systementwicklungsprojekt (AN) Entwicklungsprojekt aus Sicht eines Auftragnehmers. Die Ausschreibung wurde bereits erstellt und der Auftrag erteilt. Der Auftragnehmer entwickelt das System und übergibt es nach Fertigstellung dem Auftraggeber. Es gibt folgende Projekttypvarianten: PTV: AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration PTV: AN-Projekt mit Wartung und Pflege PT: Systementwicklungsprojekt (AG/AN) Keine separaten Projekte auf Auftraggeber und Auftragnehmer Seite notwendig. Die Anforderungen werden vom Auftraggeber ermittelt und anschließend durch den Auftragnehmer umgesetzt. Das fertige Produkt wird anschließend vom Auftraggeber abgenommen. Es gibt folgende Projekttypvarianten: PTV: AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration PTV: AG/AN-Projekt mit Wartung und Pflege PT: Einführung und Pflege eines organisatorischen Vorgehensmodells Dient zur Erstellung eines Vorgehensmodells. Es gibt die folgende Projekttypvariante: PTV: Einführung und Pflege eines organisatorischen Vorgehensmodells Auf Basis dieser Auswahl erstellt das V-Modell XT ein Anwendungsprofil, indem weitere Projektmerkmale, welche das Projekt näher charakterisieren, bewertet werden können. Eine Übersicht über alle Projektmerkmale gibt es in Kapitel??. Durch das komplette Anwendungsprofil werden die möglichen, verwendbaren Vorgehensbausteine, sowie die Projektdurchführungsstrategie und somit die Reihenfolge der Entscheidungspunkte definiert. Dieses Vorgehen wird als statisches Tailoring bezeichnet. 11

16 2 Grundlagen Wenn nun während der Projektlaufzeit Vorgehensbausteine hinzugefügt oder entfernt werden sollen, wird von dynamischem Tailoring gesprochen. Für eine dynamische Änderung definiert das V-Modell XT ebenfalls genaue Regeln und bietet Produktabhängigkeiten an, die vorgeben, welche Kombination von Vorgehensbausteinen eingesetzt werden müssen, sofern ein bestimmter Vorgehensbaustein eingesetzt wird. In Abbildung 2.4 wird analog zur V-Modell 97 Variante (Abbildung 2.1) der Ablauf der Systementwicklung im V-Modell XT dargestellt. Abbildung 2.4: Systementwicklung im V-Modell XT [vmo, Dokumentation V-Modell XT, Seite 35] 2.3 SCRUM SCRUM ist nach [LÜBKE, SCHNEIDER 2011] eine Management-Hülle und wurde 1996 von Ken Schwaber [BEEDLE. SCHWABER 2002] vorgestellt. Die Grundidee ist, Anforderungen zu bündeln und schrittweise abzuarbeiten. Änderungen werden nur zwischen den Abarbeitungsphasen zugelassen. Dies gewährleistet unter anderem der sogenannte SCRUM Master. Das Entwicklerteam selbst besteht aus fünf bis neun Entwicklern. Der Name SCRUM (aus dem Sport: Zusammenraufen im Team) spiegelt die Idee der Methode wider. Ein Projekt ist aufgeteilt in mehrere Abschnitte. Das Entwicklerteam trifft sich zu Beginn eines solchen Abschnitts und berät über das weitere Vorgehen für die nächste Abarbeitungsphase, den sogenannten Sprint. In jedem Sprint wird versucht, eine neue Teilfunktionalität des Produkts fertigzustellen. Jeden Tag findet ein 15-minütiges Meeting statt, der Daily SCRUM, in dem das Vorgehen bis zum nächsten Meeting besprochen wird und berichtet werden soll, was seit dem letzten Meeting erreicht wurde. 12

17 2 Grundlagen Dieses Vorgehen stellt zum einen hohe Anforderungen an die Entwickler und das Management in Bezug auf Selbstdisziplin, Eigenverantwortung und Vertrauen. Zudem müssen die Praktiken von SCRUM klar definiert und durchdacht sein. Es muss sicher gestellt sein, dass diese Praktiken reibungslos funktionieren und von Anfang bis Ende durchgesetzt werden, damit SCRUM funktioniert. Abbildung 2.5 bietet einen groben Überblick über die wichtigsten Praktiken von SCRUM. Im Folgenden werden die Praktiken von SCRUM vorgestellt. Abbildung 2.5: Übersicht über SCRUM [SCHNEIDER 2011] Der sogenannte SCRUM Master ist eine Managementrolle, die dafür sorgt, dass die Praktiken von SCRUM jederzeit eingehalten werden und das Team unter allen Umständen unbeschwert arbeiten kann. Er ist verantwortlich für die Sprints und die Meetings und achtet darauf, dass diese reibungslos durchgeführt werden können. Er ist verantwortlich für das Voranschreiten des Projekts und muss den erwarteten Fortschritt mit dem aktuellen Fortschritt vergleichen. Hat das Team Schwierigkeiten bei der Entwicklung, muss sich der SCRUM Master diese Probleme anhören und versuchen, sie zusammen mit dem Team zu lösen. Der SCRUM Master muss jederzeit in der Lage sein, Entscheidungen schnell zu treffen. Dabei können die Entscheidungen durchaus falsch sein, wobei sie schnellstmöglich rückgängig gemacht werden müssen. Dadurch sorgt er dafür, dass das Team jederzeit mit höchster Produktivität arbeitet. 13

18 2 Grundlagen Im Product Backlog werden die Anforderungen festgehalten, die an das System oder Produkt gestellt werden. Diese Anforderungen können technische Aufgaben sein, wie beispielsweise Klasse A muss refactored werden oder benutzerzentrierterer Natur, wie zum Beispiel Text muss markiert und kopiert werden können. Außerdem können sogenannte User Stories enthalten sein. User Stories sind natürlichsprachige Anforderungen aus Sicht eines Nutzers. Sie sind kurz gehalten und umfassen nur wenige Sätze. Das Product Backlog wird durch eine Zusammenarbeit zwischen SCRUM Master und Product Owner (dazu unten mehr) gefüllt. Außerdem kann jeder, der Ideen oder Anregungen hat, die das Produkt betreffen, diese im Product Backlog festhalten. Das Product Backlog ist zu Beginn unvollständig und wird im Verlauf der Entwicklung vervollständigt. Um einen ersten Sprint zu starten, muss das Product Backlog lediglich genug Informationen besitzen, um diesen Sprint 30 Tage lang durchzuführen. Es entwickelt sich zusammen mit dem Verständnis des Kunden und der Entwickler weiter. Alle Einträge des Product Backlogs sind priorisiert. Die Inhalte mit der höchsten Priorität werden für einen Sprint übernommen. Der Aufwand für die Erstellung der Inhalte des Product Backlogs werden vom Product Owner geschätzt, indem dieser Entwickler und Verantwortliche befragt, die mit dem Produkt zu tun haben. Der Product Owner kontrolliert und managt das Product Backlog. Er wird durch den SCRUM Master in Zusammenarbeit mit dem Kunden bestimmt und muss dafür sorgen, dass das Product Backlog zu jeder Zeit für jeden zugänglich und einsehbar ist und dass jeder über den aktuellen Stand des Product Backlogs informiert ist. Damit der Product Owner erfolgreich seine Arbeit ausführen kann, muss jeder seine Entscheidungen respektieren. Das SCRUM Team ist verantwortlich dafür, die durch das Product Backlog geforderte Funktionalität für einen Sprint in einem Sprint herzustellen. Es wird vom SCRUM Master in Zusammenarbeit mit dem Management zusammengestellt und besitzt während eines Sprints völlige Autorität um alles zu tun, damit das geforderte Ziel des Sprints erreicht werden kann. Die einzigen Einschränkungen und Bedingungen werden durch die Standards der Organisation vorgeschrieben. Die Größe des SCRUM Teams sollte zwischen 5 und 9 Personen betragen. Kleinere Teams können auch ihr Ziel erreichen, allerdings fällt die Produktivität in kleinen Teams geringer aus. Größere Teams besitzen das Problem, dass die Kontrollmechanismen von SCRUM nicht mehr ausreichend gut greifen und die Produktivität ebenfalls sinkt. Sind mehr als 9 Personen verfügbar, können die Personen in mehrere Teams aufgeteilt werden, die alle für sich arbeiten. Bei mehreren Teams können sich die SCRUM Master treffen, um ein sogenanntes SCRUM of SCRUMs durchzuführen. Jedes Team trifft sich täglich zu einem 15-minütigen Daily SCRUM Meeting. Während des Meetings hat jeder Teilnehmer zwei bis drei Minuten Zeit zu erklären, was er seit dem letzten Treffen geschafft hat, was er bis zum nächsten Treffen schaffen möchte und welche Schwierigkeiten aufgetreten sin. Die Daily SCRUM Meetings sind für alle anderen Personen, die ein Interesse am Fortschritt haben, offen zugänglich. Allerdings darf niemand das Meeting durch Zwischenfragen unterbrechen oder stören. Der SCRUM Master ist verantwortlich für die Organisation der Räumlichkeiten und das Planen und Durchführen des SCRUM Meetings. Wichtig ist, dass während 14

19 2 Grundlagen des Daily SCRUM Meetings keine Designentscheidungen getroffen und keine Fragen geklärt werden sollen. Es sollen lediglich alle Teammitglieder auf den aktuellen Stand der Dinge gebracht werden. Allerdings kann jedes Mitglied seinen Wunsch äußern, zu einem Thema mehr hören zu wollen. In diesem Fall wird ein anschließendes Meeting durchgeführt, in dem diesem Wunsch Folge geleistet wird. Während eines Sprint Planning Meetings planen Entwickler, Kunden, Management und Product Owner die nächsten Schritte. Das Team legt fest, wie das Ziel des Sprints aussehen soll und welche Funktionalitäten umgesetzt werden sollen. Das Sprint Planning Meeting besteht aus zwei separaten Meetings. Zuerst versucht das Team zusammen mit allen Beteiligten herauszufinden, welche Funktionalität umgesetzt werden soll. Danach beratschlagt das Team in einem zweiten Meeting, wie diese Funktionalität konkret umgesetzt werden kann. Ist bekannt, welche Funktionalität erstellt werden soll, werden die Aufgaben festgelegt, um diese Funktionalität bereit zu stellen. Diese Aufgaben werden in das sogenannte Sprint Backlog geschrieben. Nur das Team kann das Sprint Backlog während eines Sprints verändern. Während des anschließenden Sprints versucht das Team, die geforderte Funktionalität, so gut es geht, umzusetzen. Dabei stellt SCRUM keine Bedingungen, wie genau dies geschehen soll. Das Team muss selbst entscheiden, was auf welche Art und Weise zu tun ist. Zu jeder Zeit steht das Team somit in der Eigenverantwortung, so gut wie möglich zu arbeiten. Ein Sprint sollte in der Regel 30 Tage dauern. Dies ist eine angemessene Zeit, um dem Team die Möglichkeit zu geben, sich in die Problematik und Aufgabenstellung einzuarbeiten und ein gutes Ergebnis abzuliefern. Zugleich ist im Falle des Scheiterns des Teams die Dauer des Sprints derart kurz gewählt, so dass kein erheblicher Schaden entsteht, zumal die Zeit nicht komplett verschwendet wurde, da das Team Wissen und Erfahrung gewonnen hat. Während des gesamten Sprints darf das Team nicht von außen beeinflusst oder unterbrochen werden. Zudem dürfen keine zusätzlichen Aufgaben nachträglich hinzugefügt werden. Das Team selbst darf die Funktionalität des Sprints ändern, solange dadurch das Ziel des Sprints unverändert bleibt. Unter besonderen Umständen darf ein Sprint abgebrochen werden. Das vierstündige Sprint Review Meeting ist ein informelles Meeting, in dem das Team dem Kunden, dem Management, den Benutzern und dem Product Owner erklärt, was während des Sprints bewerkstelligt wurde. Basierend auf diesen Ergebnissen können bearbeitete und unbearbeitete Aufgaben neu bewertet werden und somit bestimmt werden, welche Richtung für die noch anstehende Entwicklungszeit eingeschlagen wird. Dieses Meeting ist ebenfalls für alle Interessierten offen zugänglich. Dadurch, dass das Team allen Beteiligten das Inkrement vorstellt und erklärt, können Schwachstellen erläutert oder aufgedeckt werden. Die Anwesenden bekommen dadurch ein besseres Verständnis von dem Produkt und dem Projekt selbst. 2.4 FLOW In diesem Kapitel werden die für diese Arbeit relevanten Konzepte von FLOW, basierend auf [STAPEL. SCHNEIDER 2012], detailliert dargestellt. Zum einen wird durch 15

20 2 Grundlagen FLOW eine Notation vorgestellt, mit deren Hilfe Informationsflüsse grafisch dargestellt werden können. Diese Notation kommt in dieser Arbeit zum Einsatz, da die Integration von SCRUM in das V-Modell XT auf Basis von Informationsflüssen geschehen soll und diese Informationsflüsse ermittelt und auch grafisch dargestellt werden müssen. Zum anderen bietet FLOW eine Methode, bestehende Informationsflüsse zu verbessern, um somit die Softwareentwicklung effizienter zu gestalten. Die nachfolgende Arbeit ist eine Technik innerhalb dieser FLOW-Methode und soll daher in Kapitel kurz in diese eingeordnet werden. Der Erfolg eines Softwareprojekts hängt in hohem Maße von den Informationsflüssen in diesem Projekt ab. Sei es durch die Anforderungen, die in das Projekt einfließen oder den Informationen, die von Projektabschnitt zu Projektabschnitt fließen, um Fortschritte zu erzielen. Um diese Flüsse verstehen zu können, müssen sie zuerst visualisiert werden. Informationen können entweder in fester oder in flüssiger Form vorliegen. Informationen, die in fester Form vorliegen, sind Informationen, die langfristig und wiederholt abrufbar und für Dritte verständlich sind. Alle anderen Informationen, die nicht auf diese Beschreibung zutreffen, sind flüssig. Feste Informationen sind beispielsweise in Dokumenten enthalten, während Informationen, die im Gedächtnis einer Person vorliegen, flüssig sind FLOW-Notation Die FLOW-Notation ist eine Möglichkeit, Informationsflüsse visuell darzustellen. Sie wurde speziell für Informationsflüsse konstruiert, um alle Besonderheiten dieser Flüsse abbilden zu können. Die FLOW-Notation soll dabei einige Anforderungen erfüllen. Einige dieser Anforderungen werden im Folgenden genannt. Die FLOW-Notation soll: Leicht verständlich sein Unterscheiden zwischen festen und flüssigen Informationsflüssen Nahe an bekannte Notation angelehnt sein Komplexität mit hierarchischen Modellen begegnen In Abbildung 2.6 werden die Symbole der FLOW-Notation dargestellt. Das Dokumentensymbol steht für die festen Informationsspeicher, während dessen das Smileysymbol für die flüssigen Informationsspeicher verwendet wird. Die festen Informationsflüsse werden durch einen durchgehenden Pfeil und die flüssigen Informationsflüssen durch einen gestrichelten Pfeil gekennzeichnet. Die Informationsflussaktivität kann sowohl normale, als auch Kontrollinformationsflüsse als Ein- oder Ausgang besitzen. In dieser Arbeit werden auf Grund von technischen Grenzen und Übersichtlichkeit der Abbildungen einige Einschränkungen dieser Notation gemacht. Die Bezeichnungen der Dokumente werden in der Regel in das Dokument selbst geschrieben. In einigen 16

21 2 Grundlagen Abbildung 2.6: Symbole der FLOW-Notation [STAPEL. SCHNEIDER 2012] Abbildungen werden die flüssigen Informationsspeicher nicht mit einem Smiley gekennzeichnet, da die Tools, die diese Abbildungen erstellt haben, diese Möglichkeit nicht unterstützten. Stattdessen werden die flüssigen Speicher als Ovale eingezeichnet, die ebenfalls den Namen im Oval beinhalten. Des weiteren werden Kontrollinformationsflüsse in dieser Arbeit nicht betrachtet. Aus Gründen der Übersichtlichkeit werden Informationsflüsse, die von oben oder unten in oder aus Aktivitäten fließen, immer als normale Informationsflüsse dargestellt FLOW-Methode Informationen sind die wichtigste Ressource in der Softwareentwicklung. Mit FLOW wird eine Methode angeboten, die zur Analyse und Verbesserung dieser Informationsflüsse genutzt werden kann. Die Flow-Methode besteht, wie Abbildung 2.7 zeigt, aus einer Vorbereitungsphase und einem Verbesserungszyklus, der aus Erhebung, Analyse und Verbesserung besteht. Abbildung 2.7: Der iterative FLOW-Verbesserungsprozess [STAPEL. SCHNEIDER 2012] In der Vorbereitungsphase wird das Ziel des Verbesserungsschritts und die gewünsch- 17

22 2 Grundlagen ten Techniken, um dieses Ziel zu erreichen, bestimmt. Jede Phase des anschließenden Verbesserungszykluses erzeugt eine Ausgabe, die von der jeweils nächsten Phase benötigt und verwendet wird. Alle drei Phasen beziehen sich auf Informationsflüsse in einem Softwareprojekt, welche erhoben, analysiert und verbessert werden sollen. Das Erheben der Informationsflüsse schafft eine Basis für spätere Phasen. Das Analysieren der Informationsflüsse trägt zum Verständnis dieser Flüsse bei, indem sie visualisiert werden. Verbessert werden die Informationsflüsse durch das Ausräumen erkannter Informationsflussprobleme Einordnung der Arbeit mit Hilfe der FLOW-Methode In diesem Kapitel wird die vorliegende Arbeit, die als Technik innerhalb der FLOW- Methode angesehen werden kann, in FLOW eingeordnet. Tabelle 2.1 zeigt diese Einordnung. Es wird beschrieben, welche Aufgaben mit welchem Ziel zu welchem Zeitpunkt durchgeführt werden und welche Eigenschaften die Informationsflüsse der Softwareprojekte besitzen. Name der Technik Ziel 1 Absicht Zeit Umfang Integration von SCRUM in das V-Modell XT Verstehen Verbessern vorher während dessen nachher Aktivität Projekt Organisation Phase 2 Erheben Analysieren Verbessern Projektparameter Projektgröße Domäne Vorgehensmodell Teamgröße: Budget: Benötigte Ressourcen: Anwendungsdomäne: Softwaredomäne: Prozess: Agil: Andere: Verteiltheit Lokal Verteilt (Art: ) Sonstiges 1 FLOW-Ziel-Aspekte, die mit dieser FLOW-Technik verfolgt werden können 2 Diese Technik bietet Unterstützung in diesen Phasen des FLOW-Verbesserungsprozesses Tabelle 2.1: Klassifikation dieser Arbeit als FLOW-Technik Das Ziel dieser Arbeit besteht in der Verbesserung der durch das V-Modell und SCRUM gegebenen Informationsflüsse. Sowohl das V-Modell, als auch SCRUM, werden in Projekten eingesetzt. Also werden Informationsflüsse in diesen Projekten verbessert. Dies kann vor und während eines solchen Projekts geschehen. 18

23 2 Grundlagen Dabei werden alle drei Phasen durchlaufen. Kapitel 3 beschreibt das Erheben der Informationsflüsse. Mit Hilfe des Prototypen (siehe Kapitel 6.1) werden die Informationsflüsse des V-Modells visualisiert. In Kapitel 3 werden die Informationsflüsse in SCRUM hinein und aus SCRUM heraus beschrieben. In Kapitel 4 werden Formen des Informationsflusses im V-Modell dargestellt. Einige konkrete Beispiele für Informationsflüsse im V-Model und an den Schnittstellen von SCRUM werden in Kapitel 5 gegeben. In Kapitel 4 werden Anpassungen von SCRUM durchgeführt, um Informationsflüsse zu verbessern und somit die Integration von SCRUM in das V-Modell XT zu ermöglichen. Da sowohl Informationsflüsse im V-Modell, als auch in SCRUM betrachtet werden, sind somit sowohl agile, als auch dokumentenlastige Prozesse betroffen. Allerdings wird durch SCRUM vorausgesetzt, dass die Projekte lokal und nicht verteilt durchgeführt werden, da verteilte Projekte mit SCRUM nur sehr schwer durchzuführen sind. Dieses Problem ist nicht Bestandteil dieser Arbeit Informationen und Informationsflüsse Da Information und Informationsflüsse in dieser Arbeit eine zentrale Rolle spielen, soll hier kurz mit Hilfe der Informationsflusstheorie [STAPEL 2012] erläutert werden, was genau im Rahmen dieser Arbeit mit Information gemeint ist und was ein Informationsfluss ist. Nach [STAPEL 2012] können viele relevante Softwareentwicklungsphänomene mit Informationsflüssen beschrieben werden. Informationen liegen entweder in Form von Wissen im Gedächtnis von Personen oder in Form von Daten, beispielsweise in Dokumenten, vor. Ein Softwareprojekt schreitet durch Weitergabe von Wissen, also durch Kommunikation, sowie durch Konkretisierung von Daten voran. Diese Kommunikation und Konkretisierung sind Informationsflüsse. Daher können die wesentlichen Vorgänge der Softwareentwicklung mit Hilfe von Informationsflüssen dargestellt werden. Die Informationsflusstheorie der Softwareentwicklung definiert Kommunikation als Wissensaustausch zwischen Menschen. Dieser Wissensaustausch kann direkt oder über Dokumente erfolgen. Eine Kommunikation kann als Untermenge von Informationsflüssen aufgefasst werden. Mit Hilfe der Informationen können nun zentrale Aspekte der Softwareentwicklung, wie zum Beispiel Kommunikation und Dokumentation, einheitlich beschreiben werden. In Abbildung 2.8 wird eine solche Information beschrieben. Dabei besteht eine Information aus einer Nachricht und einem Kontext. Ein Kontext ist wiederum eine Information, die aber nicht gespeichert wird, sondern als Vorwissen zum Verstehen der Information vorausgesetzt wird. Jede Information muss auf eine bestimmte Art und Weise codiert werden. Die Codierung kann entweder durch Wissen oder durch Daten geschehen. Beide sind jederzeit in einem Informationsspeicher abgelegt. Wissen wird in einem Gedächtnis gespeichert, Daten hingegen in einem Dokument. Informationen lassen sich typisieren. Jede Information besitzt einen der folgenden Typen: Fact Atomare Aussage über einen konkreten Sachverhalt. Beispiel: Die Farbe der 19

24 2 Grundlagen Abbildung 2.8: Beschreibung einer Information [STAPEL 2012] Tapete ist weiß. Concept Aussage über einen abstrakten Sachverhalt. Fakten und Konzepte haben eine ähnliche Beziehung wie Klassen und Objekte aus Programmiersprachen. Beispiel: Ein Hund ist ein Säugetier. Hierbei wäre das Säugetier das Konzept. Rule Aussage, die an eine Bedingung geknüpft ist. Beispiel: Wenn wir für unser Produkt einen Treiber schreiben müssen, werden wir dies in C++ tun. Procedure Beschreibung von Arbeitsschritten mit Reihenfolge. Beispiel: Zuerst wird ein Grobentwurf erstellt, dann ein Feinentwurf. Zusätzlich lassen sich Informationen in Domänen einordnen. Es gibt eine Domäne für das generelle Lösen von Problemen und als Teil dieser eine Software-Domäne. Diese lässt sich in die Bereiche Anforderung, Architektur, Code und Test unterteilen. Das zu lösende Problem befindet sich in der Problemdomäne, die beispielsweise aus den Domänen Automotive, Financial oder Medical kommen kann. Es gibt also eine Domäne, in der die Lösung eines Problems mit Softwaremethoden angestrebt wird und eine Domäne, in der das Problem liegt. 20

25 2 Grundlagen Eine Information besteht aus einer Nachricht und einem Kontext. Die Nachricht ist die Aussage, die getroffen wird. Der Kontext ist der Hintergrund, der benötigt wird, um die Nachricht verstehen zu können. In der Regel ist der Kontext nicht leer, da eine Kommunikation viel zu ineffizient wäre, wenn immer versucht wird, viel in der Nachricht auszudrücken und wenig im Kontext vorauszusetzen. Ein Beispiel für eine Nachricht wäre: Das Wetter bei uns war gestern sonnig. Eine Möglichkeit für einen passenden Kontext wäre: Die Person hat sich gestern in Hannover aufgehalten. Zusammen ergibt es die Information, dass das Wetter in Hannover gestern sehr schön war. Ist der Kontext anders, beispielsweise: Die Person hat sich gestern in Paris aufgehalten, wäre die Information eine andere. Die Größe der Nachricht kann je nach vorausgesetztem Vorwissen variieren. Abhängig vom Kontext kann eine kleine Nachricht die gleiche Information bieten, wie eine große Nachricht. Dies bedeutet, dass bei einer Kommunikation der nicht übermittelte Kontext entscheidend für das richtige Verständnis und den Erfolg der Kommunikation ist. Große Nachrichten und eine daraus resultierende, größere Wahrscheinlichkeit, dass die Information richtig verstanden wird, stehen einer kleinen Nachricht gegenüber, die wiederum die Effizienz der Kommunikation steigert. Effizienz ist hierbei die benötigte Zeit, in der eine Information vermittelt werden kann. In Abbildung 2.9 wird dies genauer dargestellt und der Kommunikationsprozess erläutert. Wissen kann nur dann richtig übertragen werden, wenn es einen gemeinsamen Kontext gibt. Will ein Sender Wissen vermitteln, trennt er zuerst Nachricht und Kontext voneinander. Dies geschieht bewusst oder auch unbewusst. Die Nachricht wird in geeigneter Form übermittelt und vom Empfänger wahrgenommen. Dieser muss die Nachricht in einen gemeinsamen Kontext bringen und kann die Information nur so korrekt erhalten. Die Information wird anschließend interpretiert und wieder in Wissen umgewandelt. Unterscheidet sich der gemeinsame Kontext von Sender und Empfänger, schlägt die Kommunikation fehl. Abbildung 2.9: Kommunikationsablauf zwischen Sender und Empfänger [STAPEL 2012] Wenn Informationen von einer Quelle zu einem Ziel fließen, wird von Informationsfluss gesprochen. Sowohl Quelle, als auch Ziel eines Flusses sind Informationsspei- 21

26 2 Grundlagen cher. Wird die Tatsache berücksichtigt, dass es zwei unterschiedliche Informationsspeicher gibt, die auf zwei mögliche Arten angeordnet werden können, ergeben sich vier Kombinationsmöglichkeiten für die Art der Übertragung. Diese Kombinationsmöglichkeiten werden Basisinformationsflüsse genannt, die wie folgt bezeichnet werden: Externalisation/Documentation Es werden Informationen von einem Gedächtnis in ein Dokument übertragen (dokumentiert). Combination/Transformation Es werden Informationen von einem Dokument in ein anderes übertragen oder in das gleiche kopiert. Internalisation/Learning Es werden Informationen von einem Dokument in ein Gedächtnis übertragen (erlernt). Socialisation/Communication Es werden Informationen von einem Gedächtnis in ein anderes übertragen (kommuniziert). Zuletzt wird die Softwareentwicklung in Abbildung 2.10 aus Informationsflusssicht dargestellt. Auf der einen Achse wird die Domäne dargestellt, auf der anderen die Abstraktheit. Es gibt die beiden Domänen Problem und Problemlösung. Die Problemdefinition wird in der Problemdomäne vorgenommen. Durch einen Lösungsvorschlag wird in die Problemlösungsdomäne gewechselt. Dort wird mit Hilfe von Softwareentwicklungsaktivitäten Software zum Lösen des Problems erstellt. Das Testen der Software, also die Prüfung der Lösung, führt wieder in die Problemdomäne zurück. Abbildung 2.10: Softwareentwicklung aus Informationsflusssicht [STAPEL 2012] 22

27 3 Informationsflüsse in SCRUM und im V-Modell XT 3.1 Grundidee Das Ziel dieser Arbeit ist, Informationsflüsse im V-Modell und in SCRUM zu identifizieren, um mit deren Hilfe eine Integration von SCRUM in das V-Modell XT leichter durchführen zu können. Die Informationsflüsse in SCRUM lassen sich, wie in Kapitel 3.3 beschrieben wird, ableiten, indem die Praktiken und Methoden von SCRUM und die damit verbundenen Arbeitsabläufe analysiert werden. Somit kann ein Informationsfluss in SCRUM ermittelt werden. Der Informationsfluss im V-Modell kann auf den ersten Blick über mehrere Möglichkeiten gewonnen werden. In Kapitel 3.4 werden die Produktabhängigkeiten des V-Modells analysiert, um Informationsflüsse aus ihnen abzuleiten. Sind die Informationsflüsse sowohl im V-Modell, als auch in SCRUM bekannt, kann SCRUM auf Basis dieser Informationsflüsse in das V-Modell integriert werden. Wie genau die Integration aussieht und welche Anpassungen vorgenommen werden müssen, wird in den nachfolgenden Kapiteln 4 und 5 ausführlich beschrieben. Es gibt allerdings prinzipielle Ideen, die auf die Analyse des Informationsflusses Auswirkungen haben und somit bereits in diesem Kapitel berücksichtigt werden müssen. Da sich SCRUM an jeder sinnvollen Stelle des V-Modells integrieren lassen sollte, müssen die Informationsflüsse im gesamten V-Modell betrachtet werden. Dies ist zum einen wichtig, da somit analysiert werden kann, welche Stelle sinnvoll ist. Auf der anderen Seite muss aber auch an jeder dieser Stellen die Analyse des Informationsflusses vorliegen, um SCRUM tatsächlich an dieser Stelle integrieren zu können, da die Integration, wie schon beschrieben, auf Basis dieser Informationsflüsse stattfinden soll. Da nun SCRUM integriert werden soll, reicht es aus, den Informationsfluss von SCRUM an dessen Schnittstellen nach außen zu betrachten. Ist der Informationsfluss an diesen Schnittstellen analysiert, kann die Integration durchgeführt werden. Als Schnittstellen von SCRUM sollen in diesem Kapitel alle ein- und ausgehenden Informationsflüsse, die in SCRUM hinein und aus SCRUM heraus gehen, gelten. Der innere oder interne Ablauf von SCRUM bezeichnet die Arbeitsabläufe und -schritte, die mit SCRUM durchgeführt werden, um ein gefordertes Ziel zu erreichen. Ein Sprint wäre beispielsweise Bestandteil des inneren Ablaufs. Ebenso ist das SCRUM Team ausschließlich in den inneren Ablauf integriert und hat auf die Außenwelt aus Informationsflusssicht keine Auswirkungen. Der innere Ablauf von SCRUM kann also als eine 23

28 3 Informationsflüsse in SCRUM und im V-Modell XT Black Box angesehen werden. Es werden Eingaben benötigt, damit SCRUM ablaufen kann. Nach einer gewissen Zeitspanne produziert SCRUM auf zunächst unbekannte Art und Weise Ausgaben, die wiederum vom V-Modell weiterverwendet werden können und sollen. Der innere Ablauf von SCRUM ist natürlich genauso wichtig, wie die Schnittstellen von SCRUM nach außen. Daher wird dieser ausführlich in Kapitel 4 erläutert. 3.2 Annahmen Um nun die oben genannten Ideen einheitlich umzusetzen, muss eine Basis von Informationen und Tatsachen definiert werden, damit jeder einzelne Schritt plausibel erklärt werden kann. Die Basis oder auch der Rahmen diese Arbeit, wird zum Teil vom V-Modell selbst, als auch von den Gegebenheiten von SCRUM definiert. Da allerdings nicht jede Einzelheit im V-Modell oder in SCRUM erklärt wird und oft Spielraum für Interpretationen offen bleibt, werden an dieser Stelle einige Annahmen getroffen, die notwendig sind, um eben diese gemeinsame Basis zu schaffen, damit die Integration von SCRUM später erfolgreich durchgeführt werden kann. Die hier gemachten Annahmen sollen durchaus realistisch gehalten werden. Sie sind so formuliert, dass eine Anwendung in der Praxis Sinn ergibt. Da sie aber nirgends explizit erwähnt sind, müssen sie an dieser Stelle festgehalten werden. Annahme 3.1 Die Ersetzung durch SCRUM wird immer so gewählt, dass mindestens ein Sprint durchgeführt werden kann. Diese Annahme ist wichtig, da es in der Regel nicht gut ist, einen Sprint abzubrechen. Die Ersetzung durch SCRUM sollte niemals derart gewählt werden, dass schon im Vorfeld eine Durchführung eines ganzen Sprints unmöglich wird. Annahme 3.2 Das SCRUM Team besteht aus Entwicklern des V-Modell-basierten Entwicklungsprozesses. In der Regel soll davon ausgegangen werden, dass die Entwickler, die zuvor im V-Modell-basierten Entwicklungsprozess mitgewirkt haben, danach auch Teil des SCRUM-Teams sind. Dadurch kann die Projekterfahrung der Mitarbeiter in den SCRUM-Prozess einfließen. Würde andernfalls ein Team für den SCRUM-Prozess eingesetzt werden, dass mit dem Projekt zuvor noch nichts zu tun hatte, so muss mit einer hohen Einarbeitungszeit gerechnet werden. Außerdem würden sich die Arbeitsmechanismen und Abläufe deutlich verlangsamen, da immer wieder Fragen auftauchen, die im Zweifelsfall mit dem vorherigen Team abgesprochen werden müssen. Die Vorteile von SCRUM würden durch die hohen Abstimmungsaufwände relativiert werden. Dennoch kann es gewünscht sein, dass ein externes SCRUM Team, welches mit dem 24

29 3 Informationsflüsse in SCRUM und im V-Modell XT Projekt zuvor nichts zu tun hatte, die Aufgaben übernimmt. In diesem Fall werden in Kapitel gesonderte Betrachtungen durchgeführt. Annahme 3.3 Alle Aktivitäten im V-Modell, die Produkte erzeugen und füllen, dauern länger als 30 Tage. Im V-Modell wird nicht definiert, wie lange ein Arbeitsschritt zur Erzeugung eines Produkts dauert. Um eine Basis für spätere Argumentationen zu schaffen, soll hier davon ausgegangen werden, dass ein solcher Schritt mindestens 30 Tage dauert. Die Zahl ergibt sich aus der impliziten Annahme, dass im V-Modell ausschließlich sinnvolle Produkte erzeugt werden, die einen späteren Nutzen für das Projekt besitzen. Somit müssen diese Produkte umsichtig und in vollem inhaltlichen - und Qualitätsumfang erzeugt werden. Annahme 3.4 Erzeugende Produktabhängigkeiten beschreiben Informationsflüsse. Durch eine erzeugende Produktabhängigkeit werden Produkte nicht nur erzeugt, sondern auch gefüllt. In welcher Form sie gefüllt werden, hängt von dem Produkt ab. Produkte, die erzeugt wurden, besitzen somit immer einen Inhalt und sind keine leere Hülle. Annahme 3.5 Inhaltliche Produktabhängigkeiten beschreiben nicht zwingend Informationsflüsse. Durch eine inhaltliche Produktabhängigkeit wird eine Konsistenzabhängigkeit zwischen Produkten beschrieben. Ändert sich ein Produkt, müssen sich möglicherweise alle von diesem Produkt inhaltlich abhängenden Produkte ebenfalls ändern. Anders als bei der erzeugenden Produktabhängigkeit, stellt die inhaltliche Produktabhängigkeit keine Bedingungen bezüglich der Erzeugung von Inhalten von Produkten. Inhaltliche Produktabhängigkeiten werden daher nicht zur Herleitung der Informationsflüsse genutzt. Annahme 3.6 Relevante Produktabhängigkeiten, strukturelle Produktabhängigkeiten, sowie Tailoring-Produktabhängigkeiten tragen nicht zum Informationsfluss bei. Die Annahmen 3.4, 3.5 und 3.6 sind wichtig für die Herleitung eines Informationsflusses. Sie müssen getroffen werden, da sie im V-Modell nicht explizit genannt werden und werden in Kapitel genau begründet. Annahme 3.7 Teilaufgaben des Projekts werden nicht an Lieferanten vergeben. Diese Annahme wird getroffen, da Teile des V-Modells mit SCRUM durchgeführt werden sollen und SCRUM selbst in der ursprünglichen Idee keine Auslagerung von Teilaufgaben vorsieht. 25

30 3 Informationsflüsse in SCRUM und im V-Modell XT 3.3 Beschreibung von SCRUM auf Basis von Informationsflüssen In diesem Kapitel werden Informationsflüsse von SCRUM mit Hilfe seiner Praktiken und Abläufe identifiziert. Da SCRUM an jeder Stelle integriert werden soll, an der eine Integration sinnvoll erscheint, muss das gesamte V-Modell auf Informationsflüsse untersucht werden, um bewerten zu können, an welchen möglichen Stellen eine Integration tatsächlich sinnvoll ist. Hingegen reicht es, nur den Informationsfluss an den Schnittstelen von SCRUM zu betrachten, da lediglich diese Bereiche für die Integration von Interesse sind. Dies liegt daran dass für die Integration entscheidend ist, dass die Informationsflüsse aus dem V-Modell heraus korrekt in den SCRUM Prozess hinein fließen. Dieser Fluss muss korrekt vollzogen werden, um eine reibungslose Arbeit mit SCRUM aufnehmen zu können. Welche Informationsflüsse in SCRUM selbst fließen, spielt für die Integration aus Sicht der Schnittstellen keine Rolle. Der eigentliche Ablauf von SCRUM soll so weit es geht nach Schwaber [BEEDLE. SCHWABER 2002] durchgeführt werden, um die Vorteile von SCRUM durch die Integration so gut wie möglich nutzen zu können. Natürlich ist es notwendig, die Abläufe von SCRUM zu untersuchen und zu beschreiben, ob oder wie sie geändert werden müssen, falls dies notwendig ist. Zudem ist es wichtig, die Schnittstellen genau zu beschreiben und eventuell anzupassen. Dies wird in Kapitel 4.2 genauer ausgeführt. Nun werden, wie schon erwähnt, die Praktiken von SCRUM untersucht, um analysieren zu können, wie Informationen in SCRUM hinein und aus SCRUM heraus fließen. In Kapitel 2.3 werden die Praktiken von SCRUM genau erklärt. An dieser Stelle werden die relevanten Aspekte für den Informationsfluss zusammenfassend erklärt um zu beschreiben, wie der Informationsfluss in SCRUM aussieht. Der SCRUM Master stellt sicher, dass die Interna von SCRUM korrekt ablaufen. Außerdem dient er als Grenze zwischen Außenwelt und Team. Er ist von außen stets sicht- und ansprechbar. Allerdings ist seine Funktion in erster Linie abblockender Natur. Die Informationen, die er erhält, werden selten direkt an das Team weitergegeben. SCRUM besitzt andere Mechanismen für einen produktbezogenen Informationsfluss. Der SCRUM Master ist zwar sehr wichtig für SCRUM, indem er die Arbeitsbedingungen auf höchstem Niveau hält, für stets hohe Produktivität des Teams sorgt und Probleme von außen abfängt, was aber eher die interne Arbeit, als die Schnittstellen von SCRUM betrifft. Seine Aufgabe ist es, die Informationsflüsse an den Schnittstellen zu steuern. Im Product Backlog werden alle Anforderungen und Ideen gespeichert, die sowohl von innen, als auch von außen kommen. Für die Schnittstelle nach außen ist das Product Backlog also sehr wichtig. Die Anforderungen von außen können auf viele Wege in das Product Backlog einfließen. Im Falle des V-Modells liegen fertige Produkte in der Regel bereits vor. Informationen aus diesen Produkten können somit direkt in das Product Backlog einfließen. Eine Rolle, zum Beispiel der Product Owner, muss dafür sorgen, dass die Informationen in das Product Backlog übernommen werden. Somit kann sichergestellt werden, dass benötigte Informationen für SCRUM zur Verfügung stehen. Die Übernahme der Informationen in das Product Backlog zieht zudem mit 26

31 3 Informationsflüsse in SCRUM und im V-Modell XT sich, dass dem Team bekannt gegeben werden muss, welche Informationen sich im Product Backlog befinden. Das Team muss also konkret wissen, mit welchen Informationen es arbeiten soll und kann. In Kapitel 4.2 wird genau erklärt, was bei der Benutzung des Product Backlogs zu berücksichtigen ist. Soll SCRUM bereits zu Beginn eines Projekts angewendet werden, also genau dann, wenn noch keine Schritte im V-Modell durchgeführt worden sind, liegen noch keine Produkte vor. In diesem Fall startet SCRUM mit leerem Product Backlog. Das Product Backlog muss somit zuerst ausreichend gefüllt werden, um einen Sprint zu starten. Dies kann geschehen, indem Anforderungen oder Informationen aus einem informellen Anforderungsdokuments (feste Informationen) oder aus Gedanken oder Überlegungen von Kunden oder Benutzern (flüssige Informationen) gewonnen werden. In Abbildung 3.1 wird ein vorläufiger Informationsfluss gemäß den obigen Überlegungen dargestellt. Die mit SCRUM bezeichnete Aktivität stellt die Entwicklung mit SCRUM dar. Unter der Entwicklung mit SCRUM sind sämtliche Arbeitsschritte und Praktiken, die in SCRUM durchgeführt werden, gemeint, inklusive mehrerer Sprints. Die Aktivität stellt nicht nur einen einzigen Sprint dar. Von außen sichtbar ist das Produkt Backlog, in das Informationen aus dem Eingangsprodukt P E übernommen werden. In der Abbildung und in allen weiteren Abbildungen dieses Kapitels wird die Flow-Notation [STAPEL. SCHNEIDER 2012] verwendet. Abbildung 3.1: SCRUM aus Informationsflusssicht inklusive Product Backlog Da das Product Backlog nach außen hin sichtbar ist, ist leicht einzusehen, dass die Rolle des Product Owners, der für das Managen und Kontrollieren des Product Backlogs zuständig ist, ebenfalls Bestandteil des Informationsflusses ist. Der Product Owner ist allerdings nicht nur für das Product Backlog verantwortlich, sondern muss auch Sorge tragen, dass das gesamte Team stets über das Product Backlog bescheid weiß. Der Product Owner trifft zudem Entscheidungen, die vom Team respektiert werden müssen und Auswirkungen auf den gesamten Arbeitsablauf von SCRUM haben. Er nimmt am Sprint Planning Meeting, sowie am Sprint Review teil. Um das Product Backlog verwalten zu können, muss er ebenfalls über die Produkte, deren Informationen in das Product fließen, bescheid wissen. Abbildung 3.2 beschreibt diese Funktionen des Product Owners. Er hat sowohl Einfluss auf das Product Backlog, als auch auf Aktivitäten, die die SCRUM Interna beeinflussen. Die Daily SCRUM Meetings, das Sprint Planning Meeting, die Sprints selbst, sowie das abschließende Sprint Review spielen für die Integration keine Rolle, da sie nur die interne Arbeit von SCRUM beeinflussen. Diese Arbeit wird durch die SCRUM Aktivität 27

32 3 Informationsflüsse in SCRUM und im V-Modell XT Abbildung 3.2: SCRUM aus Informationsflusssicht inklusive Product Owner komplett dargestellt und ist somit als Black Box in gewisser Hinsicht Bestandteil des Informationsflusses. Jedoch ist der interne Informationsfluss der SCRUM Aktivität aus Informationsflusssicht an den Schnittstellen nicht weiter von Bedeutung. In Kapitel 4.2 werden die Anpassungen der internen Mechanismen von SCRUM, wie schon erwähnt, detailliert beschrieben. Abbildung 3.3 zeigt nun den gesamten Informationsfluss in SCRUM hinein und aus SCRUM heraus. Informationen aus Produkten, die benötigt werden, werden in das Product Backlog übernommen, welches vom Product Owner verwaltet wird. Dieser hat ebenfalls Aufgaben, die innerhalb von SCRUM eine Rolle spielen und kennt die Produkte. Informationen des Product Backlogs dienen als Eingang für SCRUM und werden innerhalb von SCRUM verwendet. In der SCRUM Aktivität werden die Arbeitsschritte von SCRUM durchgeführt. Am Ende der Durchführung von SCRUM werden schließlich Produkte erzeugt, die für das V-Modell weiter verwendet werden können. Zusätzlich sind hier die Informationsflüsse der Schnittstellen verdeutlicht, die in die Aktivität SCRUM-Integration hinein und aus ihr heraus fließen. 3.4 Beschreibung des V-Modells auf Basis von Informationsflüssen In diesem Kapitel wird beschrieben, auf welche Weise Informationsflüsse im V-Modell erkannt werden können, um später SCRUM in das V-Modell integrieren zu können. Dazu werden die Bestandteile des V-Modells, die dazu beitragen könnten, analysiert. Prinzipiell stehen die drei Komponentenarten Vorgehensbaustein, Entscheidungspunkt und Produkt zur Verfügung, sowie die Bestandteile eines Vorgehensbausteins Rolle und Aktivität. Aus diesen Komponentenarten soll nun versucht werden, ein Informationsfluss herzuleiten, was nicht bei allen Komponenten problemlos möglich ist. Vorgehensbausteine werden im V-Modell für die Planung und die Anpassung der durch- 28

33 3 Informationsflüsse in SCRUM und im V-Modell XT Abbildung 3.3: Gesamter Informationsfluss in SCRUM hinein und aus SCRUM heraus zuführenden Prozesse verwendet und spielen für die eigentliche Projektdurchführung später keine Rolle mehr. Für die Durchführung sind die Entscheidungspunkte von Bedeutung. Daher scheiden die Vorgehensbausteine als Lieferant für Informationsflüsse, die während des Projekts fließen, aus. Die Entscheidungspunkte werden schrittweise nacheinander ausgeführt und bilden somit einen fortschreitenden Ablauf. Allerdings definieren sie nicht, wie die Produkte erzeugt werden oder wann dies geschieht. Sie legen lediglich fest, dass zu einem gegebenen Zeitpunkt eine definierte Menge von Produkten vorhanden sein muss. Auf oberster Abstraktionsebene geben sie zwar eine grobe Richtung vor, allerdings muss, um einen konkreten Informationsfluss zu erkennen, noch näher ins Detail gegangen werden. Daher lohnt es sich, die Komponenten Rolle, Aktivität und Produkte des V-Modells zu betrachten. Diese sind, wie in Kapitel beschrieben, miteinander verknüpft. Da ein Produkt von einer Rolle mittels einer Aktivität erstellt wird, erscheint es logisch, die Abhängigkeiten zwischen den jeweiligen Produkten zu suchen, da diese die Menge der finalen Produkte darstellen und in handfester Form vorliegen. Diese Wahl wird durch die Tatsache unterstützt, dass das V-Modell XT bereits Abhängigkeiten zwischen Produkten identifiziert hat Produktabhängigkeiten Das V-Modell gibt insgesamt fünf unterschiedliche Typen von Produktabhängigkeiten an. Es gibt erzeugende Produktabhängigkeiten, inhaltliche Produktabhängigkeiten, relevante Produktabhängigkeiten, strukturelle Produktabhängigkeiten, sowie Tailoring-Produktabhängigkeiten. Nicht alle davon tragen zum Informationsfluss bei. Daher soll an dieser Stelle untersucht werden, welche Produktabhängigkeiten zum Informationsfluss beitragen und welche nicht weiter betrachtet werden müssen. Diese 29

34 3 Informationsflüsse in SCRUM und im V-Modell XT fünf Produktabhängigkeiten werden laut V-Modell [vmo] wie folgt definiert und erklärt. Erzeugende Produktabhängigkeiten legen Bedingungen oder Regeln zum Erzeugen von Produkten fest. Sie beschreiben auf unterer Abstraktionsebene, wie die einzelnen Produkte erzeugt werden. Für genau diesen Schritt der Erzeugung von Produkten müssen Informationen fließen. Es werden also Informationen aus Produkten gezogen, die von Entwicklern benutzt werden, um andere Produkte zu erzeugen. Daher beschreiben, wie in Annahme 3.4 erklärt wird, die erzeugenden Produktabhängigkeiten einen Informationsfluss. Inhaltliche Produktabhängigkeiten sind gegeben, wenn die Änderung eines Produkts eine Änderung anderer Produkte nach sich zieht. Für die Änderungen der Produkte muss natürlich auch ein Informationsfluss vorliegen. Dieser Informationsfluss soll aber nicht betrachtet werden, da ein allgemeiner, immer gegebener Informationsfluss identifiziert werden soll (siehe Annahme 3.5). Würden alle Informationsflüsse berücksichtigt werden, die zu Änderungen beitragen, wäre der Graph, der diese Informationsflüsse beinhaltet, ein nahezu vollständiger Graph. Ein Beispiel ist in Abbildung 3.4 dargestellt. Daher sind inhaltliche Produktabhängigkeiten in diesem Kontext nicht von Bedeutung. Abbildung 3.4: Beispiel für inhaltliche Produktabhängigkeiten des V-Modells Relevante Produktabhängigkeiten sind gegeben, wenn sie nach Durchführung des Tailorings noch mindestens zwei verbliebene Produkte enthalten. Diese Eigenschaft macht keine Aussage darüber, wie Produkte konkret voneinander abhängen, sondern ist viel mehr ein Maß dafür, ob eine vordefinierte Produktabhängigkeit nach dem Tailoring immer noch Bestand hat. Für den Informationsfluss ist daher von Bedeutung, dass jede Abhängigkeit, die zum Informationsfluss beiträgt, eine relevante Produktabhängigkeit sein muss. Strukturelle Produktabhängigkeiten sind hierarchische Anordnungen von Produkten. Da sie nur Angaben darüber machen, wie das fertige Produkt aufgebaut ist, nicht aber, wie der Ablauf der Entwicklung aussieht, tragen sie nichts zum Informationsfluss bei. Tailoring-Produktabhängigkeiten sind Produktabhängigkeiten, die wichtig in Bezug auf das Tailoring sind. Sie werden bei der Prozesserarbeitung, nicht jedoch bei der 30

35 3 Informationsflüsse in SCRUM und im V-Modell XT Prozessdurchführung benötigt und tragen daher auch nicht zum Informationsfluss bei. Alles in allem sind alle erzeugenden Produktabhängigkeiten für den Informationsfluss wichtig, sofern sie relevante Produktabhängigkeiten sind. Die erzeugenden Produktabhängigkeiten werden genau im V-Modell definiert. Aus diesen Produktabhängigkeiten kann nun nachfolgend ein Informationsfluss gewonnen werden Von den Produktabhängigkeiten zum Informationsfluss Ausgehend von den Produktabhängigkeiten im V-Modell kann nun ein Informationsfluss bestimmt werden. Da der Informationsfluss allerdings nicht direkt aus den Abhängigkeiten hervorgeht, wird hier beschrieben, wie der Informationsfluss bestimmt werden kann. Die Abhängigkeiten im V-Modell bestehen zwischen Produkten. Abbildung 3.5 zeigt ein Beispiel für mehrere Produktabhängigkeiten. Es muss beachtet werden, dass sowohl Eingangs-, als auch Ausgangspunkt einer Abhängigkeit ein Produkt ist. Außerdem sind die Abhängigkeiten gerichtet. Es kann also immer ein Ein- und Ausgangspunkt einer Abhängigkeit eindeutig identifiziert werden. In Abbildung 3.5 erzeugt das Produkt SW- Architektur die Produkte SW-Komponente, SW-Spezifikation und SW-Modul. Abbildung 3.5: Beispiel für Produktabhängigkeiten des V-Modells Zuerst müssen alle Produkte und ihre Abhängigkeiten, sowie die dazugehörigen Rollen identifiziert werden. Die Produkte werden, wie schon erwähnt, über die Produktabhängigkeiten richtungsweisend zu einem ersten Informationsflussansatz zusammengefasst. Der eigentliche Informationsfluss wird über die Aktivitäten und Rollen konstruiert, die bereits den Produkten zugeordnet sind. Nun wird jeweils zwischen zwei Produkten eine FLOW-Aktivität geschaltet. Diese Flow- Aktivität steht symbolisch als Beschreibung für die durchzuführenden Aktivitäten, die benötigt werden, um ein Produkt zu erstellen oder zu verändern. Die Flow-Aktivität bekommt denselben Namen, wie die Aktivität, die im V-Modell dem Ausgangsprodukt zugeordnet wird. Da jedem Produkt im V-Modell auch genau eine Aktivität zugeordnet wird, bekommt jede FLOW-Aktivität exakt einen Namen. Abbildung 3.6 zeigt eine solche Zuordnung. Hier erzeugt das Produkt SW-Architektur das Produkt SW-Modul. Dies geschieht durch die Aktivität SW-Modul realisieren. Somit steht zwischen jedem Produkt eine FLOW-Aktivität. Der bisherige Informationsfluss ist so zu verstehen, dass Dokumente (Produkte) durch FLOW-Aktivitäten 31

36 3 Informationsflüsse in SCRUM und im V-Modell XT Abbildung 3.6: Beispiel für Produktabhängigkeiten und Aktivitäten des V-Modells (Aktivitäten) erzeugt werden. Die Weitergabe von Informationen geschieht somit in den Schritten zwischen den Produkten, also genau in den FLOW-Aktivitäten. In diesen FLOW-Aktivitäten werden Informationen weitergegeben, neue Dokumente erzeugt oder bestehende Dokumente verändert. Letztendlich wird im V-Modell keine Aussage getroffen, was genau dort getan wird oder wie es geschieht. Sie stehen lediglich als Platzhalter für die Tatsache, dass etwas passiert. Somit wird das Projekt voran getrieben, indem neue Dokumente durch FLOW-Aktivitäten erzeugt werden. Zuletzt werden die Rollen, die den Produkten und Aktivitäten zugeordnet sind, in den Informationsfluss aufgenommen. Mitwirkende Rollen sind Rollen, die zwar an der Fertigstellung eines Produkts mitwirken, an der Erzeugung allerdings nicht direkt beteiligt sind. Beispielsweise schreibt eine Person, die einer mitwirkenden Rolle zugewiesen wurde, keinen Code. Der Code selbst wird durch Personen geschrieben, die einer verantwortliche Rolle zugeteilt wurden. Verantwortliche Rollen sind also direkt für die Erzeugung von Produkten zuständig, daran beteiligt und dafür verantwortlich, dass das Produkt fertiggestellt und weitergegeben wird. Da die Informationen, die die Rollen besitzen, zum Erstellen eines Produkts benutzt werden und die Erstellung in den Aktivitäten geschieht, fließen die Informationen der Rollen direkt in die Aktivitäten und somit indirekt in das Produkt. Dabei muss beachtet werden, dass die Informationen einer Rolle, die verantwortlich für ein Produkt B ist, in die Aktivität fließen, in der das Produkt B erstellt wird. Die Produkte sind in FLOW feste Informationsspeicher und werden als Dokument- Symbol dargestellt. Die Rollen hingegen sind flüssige Informationsspeicher. In der FLOW-Notation würden sie mit dem Smiley-Symbol dargestellt werden. Aus Platzgründen werden sie allerdings im Folgenden als Oval dargestellt. Abbildung 3.7 zeigt ein Beispiel für einen derart erarbeiteten Informationsfluss aus einem Ausschnitt des V-Modells aus einem AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration. Verantwortliche Rollen werden durch rote, ausgehende Pfeile und mitwirkende Rollen durch schwarze, ausgehende Pfeile dargestellt. 32

37 3 Informationsflüsse in SCRUM und im V-Modell XT Abbildung 3.7: Beispiel eines Informationsflusses aus einem Ausschnitt des V-Modells 33

38 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells In Kapitel 3 wurden Informationsflüsse im V-Modell und in SCRUM identifiziert. Um SCRUM in das V-Modell integrieren zu können, müssen die Informationsflüsse des V-Modells zuerst allgemein betrachtet werden, um herauszufinden, bei welchen Informationsflussabläufen und -verzweigungen Schwierigkeiten auftreten und wie diese Schwierigkeiten zu lösen sind. Kapitel 4.1 stellt insgesamt 5 unterschiedliche Informationsflussabläufe vor und geht auf eventuelle Schwierigkeiten ein. Anschließend wird in Kapitel 4.2 beschrieben, welche Apsekte von SCRUM angepasst werden müssen, damit eine Integration von SCRUM in das V-Modell möglich ist, da eine Integration ganz ohne Anpassungen spätestens an den Schnittstellen zwischen dem V-Modell und SCRUM scheitern würde. 4.1 Grundlegende Schnittstellenvarianten In Kapitel 3 wurde ein Informationsfluss im V-Modell identifiziert. Nun muss im Hinblick auf eine spätere Integration von SCRUM betrachtet werden, welche Integrationsmöglichkeiten existieren und an welchen Stellen im Informationsfluss eine Integration allgemein möglich ist. Die Betrachtung ist wichtig, da auf diese Weise die Schnittstellen von SCRUM und dem V-Modell im Informationsfluss analysiert werden können. Die Analyse der Schnittstellen und des Informationsflusses zeigt, in welchen Bereichen eine Integration problemlos durchgeführt werden kann und in welchen Bereichen Einschränkungen in Kauf genommen oder weiterführende Konzepte erläutert werden müssen, um eine reibungslose Integration von SCRUM gewährleisten zu können. FLOW bietet sogenannte Informationsflussaktivitäten an (siehe Kapitel 2.4). Die Idee für die spätere Integration von SCRUM ist nun, ein oder mehrere Informationsflüsse (und somit auch die zugehörigen Produkte) als Informationsflussaktivität darzustellen. Anschließend werden alle Arbeitsschritte, die in dieser Informationsflussaktivität liegen, durch SCRUM ersetzt. Die Herausforderung hierbei ist, den im V-Modell vorhandenen Informationsfluss an der richtigen Stelle zu schneiden, so dass er zu dem Informationsfluss in SCRUM passt und somit ein Übergang möglich ist. In Abbildung 4.1 wird die Grundidee dieses Verfahrens dargestellt. Der gesamte Informationsfluss des V-Modells (links) besteht in diesem Beispiel aus zwei Informationsflüssen zwischen dem Produkt P E und dem Produkt P A. Anschließend werden einige Informationsflüsse im V-Modell ausgewählt (Mitte) und durch Informationsflüsse von 34

39 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells SCRUM ersetzt (rechts). Abbildung 4.1: Grundidee der Integration von SCRUM auf Basis von Informationsflüssen Definition 4.1 Die mit SCRUM durchzuführende Informationsflussaktivität wird im Folgenden als SCRUM-Aktivität bezeichnet. Definition 4.2 Die durch SCRUM zu ersetzende Informationsflussaktivität wird im Folgenden als Zu-ersetzende-Aktivität bezeichnet. Wie genau die SCRUM-Aktivität (in Abbildung 4.1 mit SCRUM-Integration gekennzeichnet) auf Basis von Informationsflüssen aussieht, wird in Kapitel 3.3 im Detail erläutert. An dieser Stelle sind nun die Schnittstellen der SCRUM-Aktivität nach außen von Bedeutung, um die SCRUM-Aktivität in den Informationsfluss sinnvoll einzubinden. Die Schnittstellen werden in Kapitel 3.3 erklärt und in Abbildung 3.3 dargestellt. In diesem Beispiel gibt es genau ein Eingangsprodukt P E und ein Ausgangsprodukt P A. Informationen des Eingangsprodukts werden in das Product Backlog von SCRUM übernommen und sind somit Eingabe für die SCRUM-Aktivität (mit SCRUM-Integration gekennzeichnete Aktivität) und den späteren SCRUM-Prozess (mit SCRUM gekennzeichnete Aktivität). Da der Product Owner in SCRUM auch für das Product Backlog zuständig ist und das Product Backlog von außen sichtbar ist, ist der Product Owner auf dieser Ebene ebenfalls sichtbar. Die SCRUM-Aktivität liefert als Ausgabe das Ausgangsprodukt P A, welches mit SCRUM und den entsprechenden SCRUM- Mechanismen erzeugt wird. Konkreter existieren zwei Schnittstellen. Die erste Schnittstelle sind die eingehenden Informationsflüsse (hier zwischen P E und Product Backlog beziehungsweise Product Owner). Die Informationen aus den Eingangsprodukten müssen in das Product Backlog übernommen werden, was in Kapitel erklärt wird. Die zweite Schnittstelle sind die ausgehenden Informationsflüsse, welche zum Erzeugen der ausgehenden Produkte beitragen, welche später für das V-Modell weiter verwendet werden können. 35

40 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Somit lässt sich aus dem identifizierten Informationsfluss des V-Modells eine Menge von Informationsflüssen auswählen, um diese als zu-ersetzende-aktivität darzustellen. Es gibt insgesamt fünf grundlegende Schnittstellenvarianten für die Auswahl der Informationsflüsse, die in der SCRUM-Aktivität enthalten sein sollen. Bei diesen Schnittstellenvarianten stellt sich die Frage, ob und wie SCRUM derart integriert werden kann, so dass eine Durchführung von SCRUM möglich ist. Hier werden nun die unterschiedlichen Schnittstellenvarianten erklärt und diese Frage für jede Schnittstellenvariante beantwortet Schnittstellenvariante 1: Elementarer Informationsfluss Die erste Schnittstellenvariante eines Informationsflusses wird in Abbildung 4.2 dargestellt. Hierbei handelt es sich um einen elementaren Informationsfluss ohne Verbindungen zu anderen Informationsflüssen. Dabei wird auf der linken Seite der Informationsfluss im V-Modell dargestellt. Der schwarze Rahmen symbolisiert dabei die Menge der Informationsflüsse, die für die SCRUM-Aktivität ausgewählt wurde. Auf der rechten Seite wird dargestellt, wie der Informationsfluss nach einer Integration von SCRUM aussieht. In diesem noch sehr einfachen Fall werden Informationen aus dem (Eingangs-)Produkt P E in das Product Backlog übernommen und das (Ausgangs-)Produkt P A ist das Ergebnis der Abläufe, die innerhalb der SCRUM-Aktivität durchgeführt werden. Abbildung 4.2: Elementarer Informationsfluss Würde tatsächlich eine derartige Ersetzung in einem Projekt durchführt werden, würde dies bedeuten, dass sich die Art und Weise des Informationsflusses ändern würde. Eingangs- und Ausgangsprodukte würden nicht mehr mittels der im V-Modell gängigen Methoden erstellt werden, sondern über die mit SCRUM gängigen Mechanismen. Die Integration von SCRUM bereitet bei dieser Schnittstellenvariante keine Probleme, wenn ausschließlich Informationsflüsse betrachtet werden. Informationen aus dem Eingangsprodukt werden an das Product Backlog übergeben und das Ausgangsprodukt wird nach der Durchführung von SCRUM weiter benutzt. 36

41 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Schnittstellenvariante 2: Sequentieller Informationsfluss Die zweite, in Abbildung 4.3 gezeigte, Schnittstellenvariante ähnelt der ersten Schnittstellenvariante. Der einzige Unterschied besteht darin, dass nun mehrere sequentielle Informationsflüsse ausgewählt werden. Für die Ersetzung der ausgewählten Informationsflüsse durch SCRUM hat dies nun den Vorteil, dass diese sequentiellen Zwischenprodukte weggelassen werden können. Abbildung 4.3: Sequentieller Informationsfluss Für die Integration von SCRUM auf Basis von Informationsflüssen bedeutet dies im Vergleich zur ersten Schnittstellenvariante jedoch keine Unterschiede. Nach wie vor gibt es keine Probleme, da Informationen des Eingangsprodukts wiederum an das Product Backlog überreicht werden und das Ausgangsprodukt nach der Durchführung von SCRUM weiter benutzt werden kann Schnittstellenvariante 3: Paralleler Informationsfluss Auch bei der dritten Schnittstellenvariante, dargestellt in Abbildung 4.4, gibt es keine weiteren auftretenden Probleme im Vergleich zu den ersten beiden Schnittstellenvarianten. Nun liegen parallele Informationsflüsse vor. Vom Eingangsprodukt fließen Informationen parallel in n weitere Produkte. Ausgehend von diesen Produkten fließen die Informationen anschließend in das Ausgangsprodukt. Wiederum ergeben sich aus Informationsflusssicht keine expliziten Probleme. Genau wie bei der sequentiellen Schnittstellenvariante (Kapitel 4.1.2) können Informationen des Eingangsprodukts dem Product Backlog übergeben werden und das Ausgangsprodukt als Ergebnis von SCRUM für die Weiterarbeit übernommen werden. 37

42 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Abbildung 4.4: Paralleler Informationsfluss Schnittstellenvariante 4: Informationsfluss mit mehreren Eingängen Bei der vierten Schnittstellenvariante in Abbildung 4.5 ändert sich nun erstmals etwas bei Informationsflüssen, die nicht Bestandteil der Menge von Informationsflüssen für die Auswahl für die SCRUM-Aktivität sind. In diesem Beispiel gibt es n Eingangsprodukte, von denen Informationen in ein weiteres Produkt P V fließen. Somit besitzt die SCRUM-Aktivität n eingehende Informationsflüsse. Abbildung 4.5: Informationsfluss mit mehreren Eingängen Anders als bei den ersten drei Schnittstellenvarianten müssen hier alle Informationen der Eingangsprodukte in das Produkt Backlog übernommen werden. Dies muss für jedes Produkt nacheinander oder parallel geschehen. Wie genau diese Übernahme funktioniert, wird in Kapitel beschrieben. Es werden also alle Informationen eingehender Produkte dem Backlog überreicht und das ausgehende Produkt wieder als Ergebnis der SCRUM-Aktivität entnommen. 38

43 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Schnittstellenvariante 5: Informationsfluss mit mehreren Ausgängen Die in Abbildung 4.6 gezeigte, fünfte Schnittstellenvariante ähnelt von der Idee her der vorherigen. Nun gibt es nicht mehrere eingehende Informationsflüsse, sondern mehrere ausgehende Informationsflüsse, also mehrere Ausgangsprodukte. Abbildung 4.6: Informationsfluss mit mehreren Ausgängen Soll SCRUM in das V-Modell integriert werden und sehen die zu ersetzenden Informationsflüsse wie in dieser Schnittstellenvariante aus, so müssen zwei Situationen unterschieden werden. In der ersten Situation sollen alle m Produkte P A1 bis P Am mit SCRUM erzeugt werden. Dies ist uneingeschränkt mit SCRUM möglich, da das Team entscheiden kann, wann welche Produkte erzeugt werden sollen. In der zweiten Situation sollen weniger Produkte von SCRUM erzeugt werden, als in der Abbildung auf der rechten Seite aufgelistet sind (j viele Produkte sollen erzeugt werden, j < m). Da das Produkt P V aber eingespart werden soll, fehlt die Grundlage für die Erzeugung der Produkte auf V-Modell-basierte Art, sobald SCRUM abgeschlossen wurde. Das V-Modell würde die Erzeugung der übrigen m j Produkte auf Basis von Informationen des Produkts P V verlangen. Das Produkt P V wurde aber nicht erzeugt. Um dieses Problem zu lösen und gleichzeitig von der Einsparung des Produkts P V zu profitieren, müssen die m j Produkte, die ursprünglich nicht mit SCRUM erzeugt werden sollten, zusätzlich mit SCRUM erzeugt werden. Somit fehlen in der V-Modellbasierten Entwicklung keine Produkte für die Erzeugung weiterer Produkte. Dies hat zur Folge, dass alle Abhängigkeiten bekannt sein müssen, damit eine Integration von SCRUM erfolgreich durchgeführt werden kann. In Kapitel 6.1 wird eine Anwendung vorgestellt, welche diese Abhängigkeiten ermittelt und somit sicherstellt, dass die Integration nicht durch fehlendes Wissen über die Abhängigkeiten fehlerhaft durchgeführt wird oder scheitert. 39

44 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells In der Praxis werden Kombinationen dieser fünf Schnittstellenvarianten vorzufinden sein, was in Kapitel 5.1 deutlich wird. Da es für jede Schnittstellenvariante eine Lösung gibt, wie SCRUM integriert werden kann, ist die Integration von SCRUM folglich im gesamten Informationsfluss möglich, sofern die Lösungsvorschläge befolgt werden und die Praktiken von SCRUM, wie im Nachfolgenden Kapitel 4.2 beschrieben, angepasst werden. Wichtig dabei ist grundlegend immer, dass die Ausgangsprodukte auf jeden Fall erzeugt werden, da das V-Modell mit diesen Produkten weiterarbeiten wird. 4.2 Anpassung von SCRUM Um möglichst viele Vorteile von SCRUM nutzen zu können, soll bei der Integration SCRUM so weit wie möglich nach Schwaber [BEEDLE. SCHWABER 2002] durchgeführt werden. Durch die Einbettung in das V-Modell ergeben sich allerdings einige Einschränkungen, für die SCRUM angepasst werden muss. Der gesamte Informationsfluss des Projekts nach der Integration von SCRUM funktioniert wie folgt. Zuerst werden Arbeitsschritte im V-Modell durchgeführt und Produkte erzeugt. Ist der Zeitpunkt erreicht, an dem SCRUM starten soll, so dienen einige der erzeugten Produkte als Eingabe für SCRUM. Die benötigten Informationen werden aus diesen Produkten hergeleitet und in das Product Backlog von SCRUM geschrieben. Anschließend wird SCRUM mit diesen Informationen durchgeführt. Dabei werden wiederum Produkte mit SCRUM erzeugt, die nach der agilen Entwicklung mit SCRUM für die Entwicklung gemäß V-Modell weiter verwendet werden. Damit dieser Ablauf funktioniert, müssen die Praktiken von SCRUM an einigen Stellen angepasst werden, was im Folgenden beschrieben werden soll Kunde In einem normalen SCRUM Projekt kommen die Anforderungen von einem Kunden, der seine Wünsche und Ziele vertritt und ein Unternehmen beauftragt, ein Produkt zu erstellen. Dieser Kunde muss nicht zwangsweise mit der Softwareentwicklung oder Software im Allgemeinen vertraut sein. Nun wird SCRUM aber in das V-Modell XT integriert. Es ist somit kein Projekt im ursprünglichen Sinne mehr, sondern Teil eines Projekts. Dabei lässt sich nicht einmal allgemein entscheiden, welche Ergebnisse durch den Einsatz von SCRUM erzielt werden sollen. Die Ergebnisse sind abhängig davon, an welcher Stelle SCRUM integriert werden soll. Folglich ist es möglich, dass ein Produkt erzeugt wird, welches für den Kunden nicht von Interesse ist oder in welches der Kunde keine Einblicke erhalten soll. In diesem Fall ist der Kunde, der ein Interesse am Endprodukt hat, nicht der Kunde, der in SCRUM zum Einsatz kommt, da die internen Produkte vom V-Modell und somit vom Unternehmen gefordert werden und nicht vom Kunden selbst. Somit werden die 40

45 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Personen zum Kunden, die ein Interesse am zu erstellenden Zwischenprodukt zeigen. In der Regel ist es das Team selbst oder das Management. Das Team möchte das Produkt erzeugen, um später auf Basis des Produkts mit dem V-Modell-basierten Prozess weiterarbeiten zu können. Das Management möchte das Produkt erstellen, damit der V-Modell-basierte Prozess reibungsfrei fortgesetzt werden kann. Wird ein Kunde tatsächlich benötigt, kann ein Teammitglied oder eine Person des Managements die Rolle des Kunden übernehmen und somit den Kunden für SCRUM simulieren. Dieser Kunde müsste sich gut mit den bisherigen Fortschritten auskennen oder das geforderte Produkt gut kennen. Alternativ kann das gesamte Team in speziellen Situationen die Rolle des Kunden übernehmen, was die Verantwortung auf das gesamte Team verteilt. Welche Situation dafür geeignet sind und welche Situationen auf gar keinen Fall dafür in Frage kommen, wird in Kapitel erklärt. In allen Fällen, in denen das Endprodukt oder Teile davon mit SCRUM entwickelt werden, ist es sinnvoll, den eigentlichen Kunden in diesen Prozess mit einzubeziehen, sollte er verfügbar sein und sich dazu bereit erklären. In diesem Fall kann SCRUM die agilen Prinzipien verfolgen, indem die Kundenzufriedenheit das höchste Ziel ist. Natürlich ist es möglich, dass es für Kunden, die die Entwicklung gemäß V-Modell gewohnt sind, schwer verständlich ist, warum sie nun während der Entwicklung anwesend sein sollen, insbesondere wenn die Integration von SCRUM intern geschieht und nach außen hin gar nicht sichtbar ist. Es soll also nicht verpflichtend sein, dass der Kunde im SCRUM Prozess anwesend ist, wäre aber von Vorteil SCRUM Master Der SCRUM Master muss zusätzlich zu seinen Aufgaben, die er von SCRUM vorgeschrieben bekommt, ein gutes Wissen über die Integration von SCRUM in das V- Modell XT besitzen, da er die erste Anlaufstelle bei Fragen und Problemen bezüglich der Integration ist. Zudem muss er die geänderten Mechanismen kennen, um seiner Aufgabe, das Team zu jeder Zeit so effizient es geht arbeiten zu lassen, gerecht zu werden. Der SCRUM Master muss einen Überblick über den gesamten, im V-Modell stattfindenden Informationsfluss besitzen, um dem Team vermitteln zu können, welche Produkte für SCRUM eine Rolle spielen und welche Produkte das Ziel von SCRUM sind. Er muss also Klarheit über Ausgangssituation und Ziel von SCRUM schaffen. Um diese Eigenschaften gut ausfüllen zu können, wäre es von Vorteil, wenn der SCRUM Master sowohl im Umgang mit dem V-Modell, als auch im Umgang mit SCRUM bereits Erfahrungen sammeln konnte. Sollte das Team eher unerfahren sein, sei es im Umgang mit dem V-Modell, als auch im Umgang mit SCRUM, kann der SCRUM Master seine Erfahrungen weitergeben und das Team leiten. Im Optimalfall sind die Erfahrungen des Teams allerdings zu gleichen Anteilen verteilt. Dies wird in Kapitel genauer beschrieben. 41

46 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Product Backlog Das Product Backlog soll die Informationen, die aus dem V-Modell nach SCRUM fließen, aufnehmen und für das Team zugänglich machen. Daher ist es sehr wichtig, genau zu betrachten, wie dies funktionieren soll. Die Informationen des Product Backlogs müssen für das Team zugänglich gemacht werden. Dabei muss zum einen darauf geachtet werden, dass das Team auf das Product Backlog zugreifen kann. Zum anderen muss der Product Owner darauf achten, dass das Team zu jeder Zeit weiß, welche Informationen und Produkte im Product Backlog enthalten sind. Dies würde sich beispielsweise dadurch bewerkstelligen lassen, dass der Informationsfluss in SCRUM hinein dem Team präsentiert wird und somit anschaulich dargestellt wird, welche Informationen welcher Produkte im Product Backlog verfügbar sind. Das SCRUM Team muss diese Informationen später verwenden können, um Aufgaben festzulegen und somit weitere Produkte zu erzeugen. Die Informationen aus den Produkten werden in das Product Backlog übernommen und liegen dort in einer Form vor, die für eine weitere Verarbeitung mit SCRUM geeignet ist. Im Folgenden wird beschrieben, wie genau das Übernehmen der Informationen ablaufen kann, wie die Informationen aus den Produkten gewonnen werden können und was eine gute Form der Informationen ist, um diese später in SCRUM problemlos zu verwenden. Als erste Idee bietet sich an, die Produkte als Ganzes direkt in das Product Backlog zu kopieren oder zu verschieben. Somit würden alle Informationen unverfälscht in das Product Backlog übernommen werden und es müsste keine gesonderte Arbeit aufgewendet werden. Allerdings können die Produkte des V-Modells sehr groß und umfangreich sein. In derart großen Dokumenten ist es schwierig, Informationen gezielt zu finden. Außerdem bleibt die Frage offen, wie Produkte priorisiert werden sollen. Soll jeder Satz einzeln priorisiert werden oder das Produkt als Ganzes? Falls es nur ein Produkt gibt, würde es in letzterem Fall nur eine einzige Priorität geben. Zudem würde dies bedeuten, dass alle Informationen des Produkts die gewählte Priorität bekommen. In der Regel sollten die Anforderungen deutlich feiner priorisiert werden. Diese Idee scheidet also bereits im Vorfeld aus. Daher müssen die Informationen der Produkte separat in das Product Backlog übernommen werden. Somit können sie priorisiert und schrittweise bearbeitet werden. Nun enthält das Product Backlog, wie in Kapitel 2.3 beschrieben, Anforderungen in Form von allgemeinsprachlichen Aussagen oder User Stories. Nicht alle Informationen, die in den Produkten des V-Modells stehen, sind Anforderungen. Folglich müssen die Informationen analysiert und umgewandelt werden, so dass Anforderungen entstehen, die in das Product Backlog übernommen und dort priorisiert werden können. Um die Informationen analysieren und umwandeln zu können, müssen die Produkte schrittweise abgearbeitet werden. Jedes Produkt muss erneut gelesen werden. Zudem muss für jede Information, die in dem Produkt enthalten ist, bewertet werden, ob diese Information in eine Anforderung überführt werden soll. Einleitender Text eines Produkts ist beispielsweise eine Information, die im Product Backlog in der Regel nicht als 42

47 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Anforderung wiedergefunden wird. Dabei werden in einigen Produkten des V-Modells bereits Anforderungen aufgelistet. Diese Anforderungen lassen sich leicht übernehmen, sofern sie zum Erstellen des Produkts, welches mit SCRUM erstellt werden soll, beitragen. Soll zum Beispiel die Systemarchitektur erstellt werden, sind Informationen des Pflichtenhefts, die für den Datenbankentwurf, aber nicht für die Systemarchitektur wichtig sind, vernachlässigbar. Schwieriger wird es, wenn Anforderungen nicht konkret genannt werden. In diesem Fall müssen die Anforderungen aus den Informationen hergeleitet werden. Um zu entscheiden, welche Informationen für das Herleiten von Anforderungen wichtig sind, muss zuerst das Produkt betrachtet werden, welches erstellt werden soll. Ist die Aufgabe, Software zu erstellen, so sehen die Anforderungen, wie in SCRUM üblich, softwarebezogen aus. Es können die bereits erwähnten Anforderungen gestellt werden. Sollte das gewünschte Produkt allerdings nicht Bestandteil der Software sein, müssen die Anforderungen anders formuliert werden. Anforderungen, die auf das Verhalten des Systems abzielen, spielen für die Erstellung der Systemarchitektur keine direkte Rolle, sondern kommen erst bei der Erstellung der SW-Komponenten und SW-Module zum Tragen. In diesem Fall müssen die Anforderungen derart formuliert werden, dass sie auf die Erstellung des Produkts hinarbeiten. Es muss also möglich sein, Aufgaben aus den Anforderungen herzuleiten. Diese Herleitung geschieht gemäß SCRUM im Sprint Planning Meeting. Die Herleitung der Anforderungen für ein Produkt muss durch Experten geschehen. Soll ein Produkt mit SCRUM erzeugt werden, dann gelingt dies in der Regel nur, wenn das Team mindestens ein Mitglied besitzt, welches sich mit dem Zielprodukt auskennt. Soll die Systemarchitektur erstellt werden, muss folglich mindestens ein Systemarchitekten im Team sein. Da das Team nach Annahme 3.2 aus Entwicklern des V-Modells besteht und das V-Modell in diesem Beispiel die Rolle des Systemarchitekten fordert, befindet sich ein solcher ebenfalls im SCRUM Team. Es gilt also nur darauf zu achten, dass eben diese Rolle auch an der Erstellung der Anforderungen mitwirkt. Wird im V-Modell XT in einem AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration der Graph betrachtet, der die erzeugenden Produktabhängigkeiten darstellt, also die Produktabhängigkeiten, die zum Informationsfluss beitragen, so fällt auf, dass der Graph azyklisch ist und die maximale Länge eines Pfades des Graphen vier beträgt. Das bedeutet, dass der Pfad von einem Produkt P 1 zu einem anderen Produkt P 4 über maximal zwei weitere Produkte P 2 und P 3 gehen kann. Die Kette der Produktabhängigkeiten ist also nicht beliebig lang. In diesem Projekt ist das Produkt P 1 in einem Pfad der Länge vier immer das Pflichtenheft. Es gibt kein anderes Produkt P 1, welches Bestandteil eines Pfades der Länge vier ist. Geht man nun davon aus, dass ein Produkt P 1 in das Produkt Backlog übernommen werden soll, um ein Produkt P 4 zu erzeugen, so können dabei maximal die Produkte P 2 und P 3 auf diesem Pfad übersprungen werden. In diesem Fall können maximal zwei Produkte auf diesem Pfad eingespart werden. Die Aufgabe an die Entwickler, Anforderungen aus einem beliebigen Produkt P 1 zu gewinnen, um ein beliebiges Produkt P i, i 2 f2; 3; 4g, zu erstellen, ist also nicht beliebig schwer. Es sollte also immer möglich sein, eindeutige Anforderungen aus dem Produkt P 1 für das Produkt P i zu gewinnen, 43

48 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells da das Produkt P i inhaltlich nahe am Produkt P 1 liegt. Das soll heißen, dass die Informationen, die im Produkt P 1 enthalten sind, immer ausreichen, um Anforderungen für die Erstellung des Produkts P i herzuleiten, sofern das Produkt P 1 ausreichend gut geschrieben wurde. Es müssen also keine Zwischenprodukte erstellt werden, um die Aufgabe der Erstellung des Produkts P i zu erleichtern. Die Anfangsprodukte P 1 eines Pfades sind im obigen Projekt immer Produkte, die Informationen für die Weiterverarbeitung bereitstellen. Im Falle der Pfadlänge vier ist das Produkt P 1, wie schon erwähnt, das Pflichtenheft. Im Falle der Pfadlänge drei, ist das Produkt P 1 entweder das Pflichtenheft, oder eines der Produkte Implementierungs-, Integrations- und Prüfkonzept System, die Systemarchitektur und Unterstützungssystemarchitektur. Es handelt sich also immer um Produkte, aus denen eindeutig hervorgeht, welche Aufgaben zu erledigen sind und welche Anforderungen an das zu erstellende Produkt gestellt werden. Das Herleiten von Anforderungen aus Produkten kann unter Umständen sehr lange dauern. Dieses Problem wird in Kapitel 4.4 genauer betrachtet. Die Erstellung von User Stories kann, beispielsweise wie in [COHN 2004] beschrieben, durchgeführt werden. In SCRUM wird besonders darauf geachtet, dass das Team möglichst ohne Komplikationen und Probleme arbeiten kann. Dadurch ist es wichtig, dass das Team auf sämtliche Produkte zugreifen kann, die es benötigt, insbesondere, wenn Sachlagen unklar sind. Die Arbeit von SCRUM sollte nicht eingeschränkt werden, indem Informationen aus Produkten nicht in das Product Backlog übernommen wurden. Existieren für das Product Backlog und SCRUM selbst mehr als ein Eingangsprodukt, so werden alle relevanten Informationen aus diesen Produkten gleichermaßen in das Product Backlog übernommen. Sind die Informationen im Product Backlog, können sie gemäß ihrer Relevanz priorisiert werden, sofern dies sinnvoll ist Product Owner Der Product Owner ist in gewisser Weise verantwortlich für das Product Backlog. Da das Product Backlog für eine Integration angepasst werden muss, muss sich auch die Rolle des Product Owners anpassen. Zusätzlich zu den bereits oben genannten, angepassten Aufgaben des Product Owners muss der Product Owner den Überblick behalten, welche Produkte für die Entwicklung mit SCRUM benötigt werden. Dies kann beispielsweise mit Hilfe des in dieser Arbeit zusätzlich erstellten Prototyps, welches in Kapitel 6.1 beschrieben wird, geschehen. Um zu entscheiden, welche Produkte entscheidend für eine Übernahme in das Product Backlog sind, muss der Product Owner die Informationsflüsse des V-Modells kennen und wissen, welche Produkte in einem Ersetzungsschritt mittels SCRUM benötigt werden. Zudem muss der Product Owner unpopuläre Entscheidungen treffen und diese auch gegen seine Mitarbeiter durchsetzen können. Dies wird dadurch schwierig, dass der 44

49 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Product Owner im V-Modell Prozess möglicherweise auf gleicher Ebene steht, wie seine Mitarbeiter. Durch die Rolle des Product Owners bekommt er jedoch eine gehobene Rolle, die ihm ermöglicht, eigenständig Entscheidungen zu treffen und durchzusetzen. Daher sollte die Rolle des Product Owners durch eine Person besetzt werden, die in der Lage ist, eigene Entscheidungen zu vertreten und durchzusetzen, sowie keine Scheu davor hat, unpopuläre Entscheidungen durchzuführen. Im Optimalfall sollte es eine Person sein, die bereits im V-Modell Prozess gezeigt hat, dass sie Verantwortung übernehmen kann und will und ein einigermaßen hohes Ansehen bei ihren Mitarbeitern hat und auch von ihnen respektiert wird. In diesem Fall fällt es den Mitarbeitern leichter, Entscheidungen von dieser Person als gut anzusehen oder zu respektieren. Die Rolle des Product Owners kann durch die Person besetzt werden, die der verantwortlichen Rolle bezüglich der Eingangsprodukte im V-Modell zugewiesen war. Auf diese Weise wird sichergestellt, dass der Product Owner die benötigte fachliche Kompetenz bezüglich der Produkte besitzt und sich somit auch mit den Informationen der Produkte auskennt. Sind mehrere Produkte Informationsquellen für das Product Backlog, deren verantwortliche Rollen durch unterschiedliche Personen übernommen wurden, so bietet es sich an, die Person auszuwählen, die sich am besten mit den mit SCRUM zu erstellenden Produkten auskennt. Im Optimalfall wäre diese Person im V-Modell der verantwortlichen Rolle des zu erzeugenden Produkts zugewiesen gewesen SCRUM Team Das SCRUM Team besteht, wie in Annahme 3.2 getroffen, aus Entwicklern des V- Modell-basierten Prozesses. Dies hat den Vorteil, dass sich die Entwickler zum einen bereits in ihrem Arbeitsgebiet auskennen und keine Einarbeitungszeit mehr benötigen. Zum anderen haben sie die Produkte, die als Eingabe für SCRUM existieren, selbst geschrieben und wissen somit sehr gut, welches Dokument Informationen an welcher Stelle beinhaltet. Dadurch fällt es leichter, sich in großen Dokumenten zu Recht zu finden. Außerdem bewirkt das Stolpern des Teams über ein eigenes Produkt, welches nicht ausreichend gut geschrieben wurde und der Informationsgewinn aus diesem Produkt somit sehr schwer fällt, einen hohen Lerneffekt. Das Team würde in diesem Fall selbst die Erfahrung machen, dass es wichtig ist, Produkte nach bestem Wissen und Gewissen so gut es geht zu erstellen. Diese Erfahrung ist deutlich einfacher aufzunehmen, als wenn ein anderes Team Anmerkungen über mangelnde Qualität eines Produkts machen würde. Allerdings kann es ebenfalls sein, dass die Entwickler des V-Modell-basierten Prozesses noch keine Erfahrungen mit SCRUM gesammelt haben. Das neu zusammengestellte Team muss sich also zuerst an die Arbeitsweise und die Konzepte von SCRUM gewöhnen. Einarbeitung und Eingewöhnung kosten in der Regel Zeit und erfordern Spielraum für Fehler und Fehleinschätzungen. In einem derartigen Fall kann es von großer Bedeutung sein, zumindest eine Person im Team zu haben, die bereits Erfahrungen mit SCRUM sammeln konnte. Im Optimalfall bekleidet diese Person die Rolle 45

50 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells des SCRUM Masters, wie oben beschrieben. Die Alternative, von Annahme 3.2 abzuweichen, kann, abhängig von der entsprechenden Firmenpolitik, dazu führen, dass lieber ein SCRUM erfahrenes Team zum Einsatz kommt, welches mit dem Projekt als solches noch keine Erfahrung gesammelt hat. Der Vorteil dieser Entscheidung ist, dass sich das Team mit den SCRUM Mechanismen auskennt und somit direkt und gezielt arbeiten kann, zumindest was die Arbeitsabläufe angeht. Ein Nachteil entsteht dadurch, dass das Team bezüglich der Informationen prinzipiell von Grund auf neu anfangen muss. Nach [STAPEL 2012] ist es für Softwareentwickler grundsätzlich schwieriger, Wissen aus einer neuen Domäne zu erlernen, als sich neue Methoden der Softwareentwicklung anzueignen. Daher ist es sinnvoller, das domänenerfahrene Team an SCRUM heranzuführen. Sollte dennoch die andere Möglichkeit bevorzugt werden, ist es in diesem Fall eine gute Idee, den Einsatz von SCRUM klassisch ablaufen zu lassen. Das bedeutet, dass ein Entwickler des V- Modell-basierten Prozesses die Rolle des Kunden übernimmt und dem Team beratend zur Seite steht und es in die bisher bearbeiteten Aufgaben und Entwicklungsschritte einführt. Das Team interpretiert seine Aufgaben so, dass es für einen externen Kunden ein Produkt erzeugen und die Wünsche des Kunden respektieren und befolgen soll. Ein Mittelweg zwischen den beiden Varianten bietet eine etwas weichere Lösung. Werden sowohl einige Entwickler des V-Modell-basierten Prozesses, als auch einige Entwickler, die sich bereits mit SCRUM auskennen, zusammen zu einem SCRUM Team geformt, so kann ein gegenseitiges Lernen stattfinden, wie es auch in SCRUM erwünscht ist. Die eine Partei kann den Umgang mit SCRUM erlernen, während die andere Partei leichteren Einstieg in die Struktur der bisherigen Arbeit des V-Modell- Prozesses findet. Über diesen Weg ist es möglich, ein relativ SCRUM-unerfahrenes Team in die Entwicklung mit SCRUM einzuführen. Diese Lösung lässt sich konsequent weiterdenken, indem auch zu gegebener Zeit die andere Hälfte des ursprünglichen Teams in die Mechanismen von SCRUM eingeführt wird. Dies kann beispielsweise durch die erste Hälfte des Teams geschehen. Dies muss zeitlich nicht zwangsweise im aktuellen Projekt geschehen, sondern kann auch langfristiger geplant und angesetzt werden. Dadurch ist es möglich, alle Mitarbeiter schrittweise an SCRUM heranzuführen, sofern es bereits Mitarbeiter gibt, die mit SCRUM Erfahrungen gemacht haben Daily SCRUM Meetings Das erste der beiden Daily SCRUM Meetings, in dem jedes Teammitglied zwei bis drei Minuten Zeit zu sprechen hat, sollte auch im Falle einer Integration von SCRUM in das V-Modell XT unangetastet bleiben. Es ist wichtig, dass dieses Meeting seine klare Struktur beibehält, um die Prinzipien die seitens SCRUM dahinter stehen, gleichermaßen fortzuführen. Sollten durch die Integration von SCRUM Fragen auftauchen, die besprochen werden müssten, so wäre es gut, diese Fragen im Anschluss stellen zu können. Das zweite Meeting wird also nicht nur dafür benötigt, Aspekte der Entwicklung weiter zu erörtern, sondern auch Aspekte der Entwicklung mit SCRUM zu klären. 46

51 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Im Folgenden werden einige Beispiele für Fragen genannt, die durch die Integration von SCRUM aufgeworfen werden können. Wie formulieren wir Aufgaben an Hand der in den Produkten gegebenen Informationen? Wie entscheiden wir, welche Informationen des Produkts für SCRUM wichtig sind? Wie funktioniert das Prinzip XY von SCRUM? Sollten sich die Fragen, die sich auf SCRUM beziehen, häufen, so kann es sinnvoll sein, ein eigenes, drittes Meeting anzusetzen, in dem ausschließlich Fragen erörtert werden, die sich auf Grund der Integration ergeben. Diese Fragen müssen nicht zwangsläufig die Mechaniken von SCRUM hinterfragen, sondern können sich auch auf die Schnittstellen zwischen dem V-Modell und SCRUM beziehen. In diesem Meeting sollten alle Fragen erlaubt sein, die sich auf die neu verursachten Probleme, Abläufe und Praktiken beziehen. Es sollten dabei, wie beim ersten Meeting, keine Architekturoder Implementierungsdetails besprochen werden. Zudem ist es sinnvoll, das gesonderte Meeting bezüglich SCRUM noch vor dem eigentlich zweiten Meeting durchzuführen. Insbesondere, wenn das Team noch keine großen Erfahrungen mit der Integration von SCRUM gemacht hat, können mehr Teammitglieder Interesse daran haben, Integrationsmechanismen zu hinterfragen, als genauer auf einige Architektur- oder Implementierungsdetails einzugehen. Sie müssten im Falle des vorgezogenen Meetings nicht lange warten, wenn sie am dritten Meeting nicht teilnehmen wollen. Dieser Aspekt muss von Unternehmen zu Unternehmen eigenständig entschieden werden. Unternehmen, die sehr erfahrene Mitarbeiter im Umgang mit SCRUM haben, können ebenso überlegen, das SCRUM Meeting an das Ende der Reihenfolge zu verschieben, da für diese Entwickler andere Fragen wichtiger sein könnten. Es wäre auch denkbar, dass nach jedem ersten Meeting geschaut wird, in welchem Bereich mehr Fragen gestellt werden. Gemessen an der Anzahl der Fragen werden die Meetings zeitlich eingeteilt. Probleme gibt es dabei, wenn der Anteil der Zuhörer des Raums, also Kunden, Benutzer und Management, sehr hoch ist und sich die Zuhörer auf einen zuvor geplanten Zeitplan verlassen müssen. In dem Fall sollte eine klare, zuvor geplante Zeiteinteilung eingehalten werden. Sollte ein drittes Meeting eingeführt werden, würde diese Entscheidung auch allen Zuhörern zu Gute kommen, die Interesse daran haben, mehr über SCRUM und die Integrationsprobleme zu lernen. Sie würden somit die Möglichkeit bekommen, gezielt zu diesem Thema Informationen zu erhalten und sich bereits zu diesem Zeitpunkt einiges Wissen aneignen können. Außerdem bekäme das Management einen klaren Eindruck, ob die Integration von SCRUM reibungslos oder problembehaftet verläuft und ob es sich lohnt, SCRUM weiterhin integriert im V-Modell durchführen zu lassen Sprint Planning Meeting Im Sprint Planning Meeting sind zwei separate Meetings vorgesehen. Im ersten Meeting trifft sich das Team mit Kunden, Management, Nutzern und dem Product Owner 47

52 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells und bespricht das weitere Vorgehen. Nun kann es sein, dass, wie oben besprochen, kein Kunde klar definiert ist oder ein Kunde durch ein Teammitglied oder das Team nicht repräsentiert wird. In diesem Fall sollten die Aufgaben des Kunde während des Meetings in jeder Hinsicht auf alle Beteiligten verteilt werden. Der SCRUM Master übernimmt an dieser Stelle die Moderation der Kundenwünsche- und Ideen, damit dieser Mechanismus beibehalten wird. Er muss somit oft Fragen stellen, was sich das Team vom anstehenden Sprint erwünscht, was in jedem Fall erarbeitet werden soll und was vorerst vernachlässigt werden kann. Er muss darauf achten, dass dieser Aspekt nicht zu kurz kommt. Endet das Meeting, muss sich jeder Entwickler bewusst sein, dass er für den Sprint nicht mehr die Rolle des Kunden inne hat. Andernfalls könnten die Entwickler in einen Rhythmus verfallen, in dem sie ausschließlich das programmieren, was sie selbst für richtig und gut erachten. Zwischen diesen Funktionen gedanklich umzuschalten erfordert sehr viel Disziplin. Zum einen wird somit mehr Verantwortung auf die Schultern des Teams gelegt, da das Team die zusätzlichen Aufgaben als Kunde hinreichend gut ausführen muss. Dies ist aber nicht unbedingt ein schlechter Aspekt, da es im eigenen Interesse des Teams ist, später ein gutes Produkt zu erzeugen, mit dem möglicherweise gut weitergearbeitet werden soll. Zudem weiß zu einem Zeitpunkt in mitten des Projekts das Team vermutlich am besten darüber Bescheid, was zu tun ist, wo es Schwierigkeiten geben kann und was benötigt wird, um weiter zu arbeiten. In den meisten Fällen kann die Rolle des Nutzers ebenfalls durch das Team abgedeckt werden. Ist das Ziel des SCRUM Sprints beispielsweise die Erstellung des Grobentwurfs, so sind die Nutzer des Grobentwurfs das Team selbst. Wird in dem Sprint allerdings ein Stück Software erzeugt, das später auch von anderen Personen benutzt wird, als von den Entwicklern selbst, so kann es ratsam sein, spätere Nutzer bei diesem Gespräch, ganz so, wie es SCRUM vorschlägt, dabei zu haben. In einigen Fällen ist dies nicht möglich. Dennoch gibt es Mittel und Wege an dieser Stelle Feedback von Benutzern einfließen zu lassen, indem beispielsweise Bewertungen älterer Produkte berücksichtigt werden. Dies sollte allerdings ohnehin durch das Management bereits zu früheren Zeitpunkten vorgeschlagen worden sein. An dieser Stelle sei noch einmal erwähnt, dass das Team die Rolle des Kunden nur aus der Not heraus übernimmt und nur solange, wie das Meeting andauert. Jeder Entwickler muss sich bewusst sein, keine eigenmächtigen Entscheidungen zu treffen. Jede Entscheidung muss durch den Kunden getroffen werden, was somit nur im Team gemeinsam möglich ist. Auf gar keinen Fall darf jeder Entwickler zum Kunden werden. Im zweiten Meeting beratschlagt das Team, wie die Umsetzung des Vorgenommenen aussehen kann. Dies kann wie in SCRUM gewohnt funktionieren. Auch in diesem Meeting kann es ratsam sein, den Ablauf von SCRUM bezüglich der Besonderheiten vor jedem Sprint anzusprechen. Wie bei den Daily SCRUM Meetings ist dies entweder direkt im zweiten Meeting möglich oder aber in einem dritten Meeting im Anschluss. 48

53 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Sprint Die Dauer eines Sprints beträgt in SCRUM in der Regel 30 Tage. Nach Annahme 3.3 ergibt sich, dass für die Erstellung eines Produkts und somit Durchführung einer Aktivität ein Sprint immer vollständig durchgeführt werden kann, sofern genauso viel Zeit mit SCRUM benötigt wird. Da die 30 Tage in SCRUM nicht verpflichtend angegeben werden, soll dies an dieser Stelle auch nicht getan werden. SCRUM rät davon ab, beim erstmaligen Einsatz von SCRUM die Dauer eines Sprints zu ändern. Sollte ein Unternehmen Erfahrungen mit SCRUM gesammelt haben, darf allerdings auch die Dauer angepasst werden. Diese Faustregel soll hier auch zum Tragen kommen. An den Zielen eines Sprints im integrierten SCRUM ändert sich nichts im Vergleich zu einem Sprint im ursprünglichen Sinne von SCRUM. Das wichtigste ist immer noch, die Ziele am Ende eines Sprints zu erreichen. Auch müssen die Aufgaben genauso verteilt sein, wie SCRUM dies vorgibt. Die Anzahl der Sprints kann, abhängig von der Dauer der Erzeugung der Ausgangsprodukte, variieren. Es müssen so viele Sprints durchgeführt werden, bis alle zu erzeugenden Produkte fertiggestellt worden sind. Dies kann sequentiell durch ein Team oder parallel durch mehrere Teams geschehen. Dazu sollten sogenannte SCRUM of SCRUMs benutzt werden, die in Kapitel genauer diskutiert werden Sprint Review Ebenso wie der Sprint kann das Sprint Review ebenfalls unangetastet bleiben. Das Ergebnis eines Sprints kann hierbei fertige oder unfertige Teile eines Produkts oder ein Produkt als Ganzes sein. Außerdem können auch Zwischenergebnisse das Ergebnis eines Sprints sein, die einen weiteren Sprint nach sich ziehen würden, um ein Produkt fertig zu stellen. Durch die Präsentation des Produkts dem Kunden gegenüber können Schwachstellen des Produkts besser identifiziert werden. Wenn das Team allerdings selber die Wünsche des Kunden vertritt, ist es schwer, diese Schwachstellen durch die Präsentation untereinander zu erkennen. In diesem Fall ist es wichtig, die Eigenschaften des Produkts besonders kritisch zu hinterfragen. Ebenso müssen die Teammitglieder an kniffligen Situationen, die während des Sprints entstanden sind, einhaken, um dort mögliche Schwachstellen zu identifizieren. Dieses Vorgehen erfordert ein hohes Maß an Selbstdisziplin, da das Team möglicherweise Probleme, die während des Sprints entstanden sind, nicht mehr aufgreifen möchte, um schnell zum nächsten Schritt voranzuschreiten. Außerdem ist es nicht selbstverständlich, dass jede Person mit der Kritik an seiner eigenen Leistung gut umgehen kann, insbesondere, wenn die Kritik vom eigenen Kollegen kommt. Kritik, die vom Kunden geäußert wird, kann in der Regel leichter akzeptiert werden. Auf diese negative Dynamik muss Acht gegeben werden. Im Zweifelsfall steht der SCRUM Master in der Verantwortung, kritische Punkte selbst anzusprechen, falls das Team diese nicht von alleine anspricht, um so eine Diskussion zu starten. 49

54 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells Das Sprint Review kann dafür genutzt werden, Vor- und Nachteile, die durch die Integration von SCRUM entstanden sind, aufzugreifen. Dadurch kann ersichtlich werden, welche Aspekte verbessert und welche fortgesetzt oder abgeschafft werden müssen. Auch hier gilt wieder, dass ein Unternehmen, welches bereits viele Erfahrungen mit der Integration von SCRUM in das V-Modell gemacht hat, auch hier auf eine gesonderte Betrachtung der Integration verzichten kann. 4.3 Vor- und Nachteile der Integration Durch die Tatsache, dass SCRUM in das V-Modell integriert werden soll, entstehen einige Vor- und Nachteile im Vergleich zu anderen, normalen SCRUM Projekten oder V-Modell-Projekten. Einige dieser Vor- und Nachteile sollen hier aufgezählt werden Vorteile Die allgemeine Bedingung, dass alle nach dem Tailoring übrig gebliebenen Produkte erzeugt werden müssen, wird in einem Projekt mit V-Modell und integriertem SCRUM außer Kraft gesetzt. Wird ein Bereich mit SCRUM durchgeführt, müssen nicht alle Produkte, die vom V-Modell in diesem Bereich gefordert werden, erzeugt werden. Je nach Einsatz von SCRUM können Produkte und somit Zeit eingespart werden. Durch die Reduktion der Anzahl der Produkte steigt auch die Flexibilität. Späte Änderungen können leichter eingearbeitet werden, da weniger Produkte geändert werden müssen. In der Regel hat sich das Team bereits vorher mit dem Projekt und den Aufgaben während des V-Modell-basierten Prozesses beschäftigt. Startet nun SCRUM, so sind einige Vorkenntnisse und Vorwissen bereits vorhanden. Das Team muss nicht mehr von Grund auf neu anfangen, sondern startet mit SCRUM in ein bekanntes Projekt. Dies bietet den Vorteil, dass sich insbesondere SCRUM-unerfahrene Entwickler leichter mit den Praktiken und Mechanismen von SCRUM vertraut machen können, da sie bereits Zeit hatten, sich mit der Domäne oder neuen Technologien vertraut zu machen Nachteile In besonders kritischen Projekten kann es möglich sein, dass die Einsparung von Produkten in manchen Fällen zu rechtlichen Problemen führen kann. Entsteht ein Schaden, steht das Unternehmen, welches das Endprodukt angefertigt hat, unter dem Zwang nachzuweisen, dass die Entwicklung korrekt abgelaufen und das Produkt so gut wie möglich fertiggestellt worden ist. In diesem Fall kann es sein, dass die Produkte, die durch den Einsatz von SCRUM eingespart werden konnten, nachdokumentiert werden müssen, um diese Sicherheit zu bieten. Je nach Startpunkt von SCRUM kann die Anzahl der Produkte, deren Informationen in das Product Backlog übernommen werden müssen, sehr groß sein. Somit wird vor 50

55 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells dem Start von SCRUM sehr viel Zeit benötigt, diese Informationen in das Product Backlog zu übernehmen. Tabelle 4.1 gibt eine grobe Übersicht über die Vor- und Nachteile der Integration von SCRUM in das V-Modell XT. Vorteile Zeitersparnis Flexibilitätsgewinn Nachteile Geringere Sicherheit Erhöhter Aufbereitungsaufwand Tabelle 4.1: Grobe Übersicht über Vor- und Nachteile der Integration von SCRUM in das V-Modell XT 4.4 Probleme bei der Integration von SCRUM Probleme bei der Gewinnung von Informationen aus den Produkten können in der Größe des Produkts liegen. Es ist sehr schwierig, gezielt Informationen in großen Produkten zu finden. Dies ist ein allgemeines Problem, mit dem sich das V-Modell prinzipiell auseinander setzen muss. Da die Produkte des V-Modells als Eingabe für SCRUM dienen, wird dieses Problem auch zu einem Problem für SCRUM. Hier entsteht ein Vorteil, wenn das Team aus Entwicklern besteht, die die Produkte des V-Modells zuvor selbst geschrieben haben. Zum einen wissen diese Entwickler selbst am Besten, an welcher Stelle welche Information im Produkt zu finden ist. Zum anderen können sie schon im Vorfeld die Verantwortung übernehmen, eine klare und übersichtliche Struktur für das Dokument zu schaffen. Gegebenenfalls kann bereits in den Schritten des V-Modells darauf geachtet werden, Informationen zu klassifizieren um somit ein leichteres Wiederfinden zu ermöglichen. Zum einen kann dies direkt im Dokument geschehen, indem Stellen, die für eine Weiterverarbeitung in Frage kommen, gekennzeichnet werden. Zum anderen könnte ein zweites Dokument geführt werden, welches diese Stellen festhält. In diesem Fall könnte es möglich sein, die Mitführung dieses Dokuments zu automatisieren, um Zeit zu sparen. Die Klassifizierung könnte zum Beispiel im Falle von Anforderungen zwischen funktionalen und nicht funktionalen Anforderungen unterscheiden und festhalten, an welcher Stelle welche Anforderungen aufgelistet werden, sofern diese Unterscheidung nicht schon im Produkt selbst vollzogen wird. Wird sich an die Vorlagen des V-Modells gehalten, wird diese Unterscheidung bereits durchgeführt. Die Übernahme von Informationen aus Produkten zu User Stories kann im Falle von großen Produkten sehr zeitintensiv sein. Dabei kann es möglich sein, dass die erhoffte Zeitersparnis durchaus geringer ausfällt. Auf der anderen Seite muss auch das V- Modell die Informationen aus Produkten filtern, um neue Produkte zu erstellen. Für die Übernahme der Informationen kann es mehrere Möglichkeiten geben (vergleiche Abbildung 4.7). Die erste Möglichkeit besteht darin, das gesamte Team zu Beginn 51

56 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells von SCRUM an der Übernahme arbeiten zu lassen, bis alle Eingangsprodukte bearbeitet wurden und alle nötigen Anforderungen in das Product Backlog übernommen wurden. Dadurch verzögert sich der Start des ersten Sprints. Allerdings liegen danach alle Anforderungen vor und der oder die Sprints können normal durchgeführt werden, ohne dass vor jedem Sprint Anforderungen aus dem Produkt gewonnen werden müssen. Dadurch ist es prinzipiell ausgeschlossen, dass Überraschungen während der Übernahme von Anforderungen auftreten können, weil das Produkt nicht vollständig gelesen wurde. Alle Anforderungen sind klar verarbeitet und das Gesamtbild der Anforderungen ist bekannt. Abbildung 4.7: Möglichkeiten zur Übernahme von Informationen in das Product Backlog Denkbar ist auch, dass das Team solange Anforderungen aus den Produkten herleitet, bis ausreichend viele Anforderungen für den ersten Sprint vorliegen. Dadurch kann das Team früh erste Ergebnisse erzielen und bereits Erfahrungen in der Erstellung des zu erzeugenden Produkts sammeln. Das Bild wird für das Team klarer und die Erstellung weiterer Anforderungen kann leichter fallen. Möglicherweise fließen Verbesserungsideen bereits in der späteren Erstellung von Anforderungen ein. Allerdings ist es auch möglich, dass wichtige Anforderungen zu spät zum Vorschein kommen und bereits erledigte Arbeit rückgängig gemacht werden muss. Bei dieser Möglichkeit gibt es für die weitere Herleitung der Anforderungen wiederum 52

57 4 Anpassung von SCRUM an die Informationsflüsse des V-Modells zwei Möglichkeiten. Zum einen kann das Team nach Abschluss eines Sprints an der Herleitung weiterer Anforderungen mitwirken. Damit würde der Ablauf von SCRUM in einem Wechsel zwischen Herleitung von Anforderungen und Sprint vollzogen werden. Hier würde sich die Zeitspanne zwischen zwei Sprints vergrößern, allerdings ist das Team über die selbst hergeleiteten Anforderungen gut informiert. Die zweite Möglichkeit besteht darin, eine eigene Rolle für die Herleitung von Anforderungen zu definieren. Die Person, die der Rolle zugewiesen wird, nutzt die Zeit der Sprints, um die restlichen Anforderungen aus den Produkten zu gewinnen. Da die Person, wie schon erwähnt, ein Experte für das zu erzeugende Produkt sein muss, muss genau dieser Experte der Rolle zugewiesen werden. Gibt es nur einen Experten im Team, ist der Experte somit erst nach der kompletten Herleitung der Anforderungen an der Erstellung des Produkts beteiligt. Somit geht seine Erfahrung in Bezug auf die Erstellung vorerst verloren. Außerdem können die weiteren Anforderungen für das Team unklar sein, wenn sie diese zum ersten Mal sehen, wodurch Klärungsbedarf bestehen kann. Die neu definierte Rolle muss also weiterhin die Aufgabe erfüllen, bei Fragen bezüglich der Anforderungen beratend zur Seite zu stehen, um diese Fragen zu klären. Sofern noch nicht genügend Anforderungen vorliegen, um den ersten Sprint zu starten, sollte das gesamte Team an der Herleitung der Anforderungen arbeiten, um Leerzyklen einzelner Mitarbeiter zu vermeiden. Außerdem bekommt so das gesamte Team ein Gefühl für die Aufgaben, die zu erledigen sind. Auf jeden Fall sollte aber der Experte an der Herleitung der Anforderungen mitwirken. Ist nur ein einziger Sprint angedacht, muss das Team alle Anforderungen vor diesem Sprint herleiten, um auch alle Anforderungen in diesem Sprint umzusetzen. 53

58 5 Integrationsvarianten von SCRUM in das V-Modell XT In Kapitel 3 wurden die Informationsflüsse im V-Modell und die Informationsfluss- Schnittstellen von SCRUM beschrieben, um mögliche Integrationspunkte zu finden. In Kapitel 4 wurde beschrieben, wie die Integration von SCRUM genau aussehen soll und welche Anpassungen vorgenommen werden müssen. In diesem Kapitel wird nun die Frage geklärt, an welchen Stellen im Informationsfluss eine Integration möglich und sinnvoll ist. Die Integration von SCRUM ist nicht an allen Stellen sinnvoll, auch wenn es prinzipiell möglich ist, jedes beliebige Produkt, wie in Kapitel 4.2 beschrieben, in das Product Backlog zu überführen und SCRUM so anzupassen, dass mit diesem Produkt als Eingabe gearbeitet werden kann. Allerdings wird SCRUM in der Regel in Bereichen der Systementwicklung eingesetzt. Daher wäre es unüblich, SCRUM für die Projektplanungsphase im V-Modell einzusetzen, um ausschließlich Dokumente mit SCRUM zu erzeugen, nur um die Systementwicklung anschließend ohne SCRUM durchzuführen. Um dies konkret zu benennen, wird Abbildung 5.1 herangezogen, welche die Entscheidungspunkte des V-Modells darstellt. Üblicherweise soll die Integration von SCRUM bei den Entscheidungspunkten geschehen, die ganz oder teilweise Bestandteil des V s sind. Die Integration von SCRUM wird in der Regel nicht ausschließlich zwischen dem ersten und dem letzten Entscheidungspunkt des V s stattfinden, sondern ist auch zwischen anderen Entscheidungspunkten innerhalb der Systementwicklung denkbar. Einig sinnvolle Varianten werden in Kapitel 5.1 vorgestellt. Abbildung 5.1: Übersicht über alle im V-Modell XT vorgesehenen Entscheidungspunkte [vmo] In Kapitel 4.1 wurde erklärt, wie SCRUM in einen Informationsfluss des V-Modells inte- 54

59 5 Integrationsvarianten von SCRUM in das V-Modell XT griert werden kann und was, abhängig von der vorliegenden Situation, zu berücksichtigen ist. Diese Integration berücksichtigt ausschließlich die Informationsflüsse, also die Produktabhängigkeiten des V-Modells. In Kapitel 5.1 soll nun geklärt werden, welche Aspekte zusätzlich zu beachten sind, um SCRUM konkret in den Gesamtablauf des V- Modells möglichst reibungslos einzubinden. In Kapitel 5.2 werden anschließend einige allgemeine Variationen angegeben, die sich auf die Integration von SCRUM beziehen und nicht auf Entscheidungspunkten basieren. 5.1 Integrationsvarianten auf Basis von Entscheidungspunkten In diesem Kapitel werden unterschiedliche Integrationsvarianten vorgestellt, in denen mögliche Bereiche beschrieben werden, die für die Integration von SCRUM in das V-Modell XT sinnvoll sind. Diese Bereiche müssen gewisse Kriterien erfüllen, um als geeignet angesehen werden zu können. Ein Bereich, der sich für die Integration von SCRUM eignet, muss sowohl zeitlich, als auch inhaltlich sinnvoll abgegrenzt sein, um eine konsistente Zusammenfassung einzelner Teile zu bieten und somit eine sinnvolle Integration zu ermöglichen. Definition 5.1 Ein Bereich ist zeitlich sinnvoll abgegrenzt, wenn alle Aufgaben, die in diesem Bereich anfallen, in angemessener Zeit abgeschlossen werden können. Definition 5.2 Ein Bereich ist inhaltlich sinnvoll abgegrenzt, wenn alle Aufgaben, die in diesem Bereich anfallen, auf das gleiche, übergeordnete Ziel zuarbeiten. Beide Definitionen lassen absichtlich viel Spielraum, da die Frage, ob eine Zeitspanne angemessen ist, von Unternehmen zu Unternehmen unterschiedlich ist. Die Entwicklung der Software für ein Flugzeug kann beispielsweise deutlich länger dauern, als die Entwicklung einer neuen Jahresversion eines Antivirenprogramms. Bereiche, die im ersten Fall angemessen sind, können unter Umständen die gesamte Projektdauer des Antivirenprogramms überschreiten. Dennoch bietet das V-Modell XT ein Mittel der Projektfortschrittskontrolle an, welches die Forderung erfüllt: die Entscheidungspunkte. Die Entscheidungspunkte wurden durch das V-Modell so definiert, dass sie zeitlich und auch inhaltlich sinnvoll abgegrenzt sind. Alle Aufgaben, die zwischen zwei Entscheidungspunkten anfallen, dienen dazu, in möglichst kurzer Zeit ein vorgegebenes Ziel zu erreichen und die Weiterarbeit nach Erreichen dieses Ziel zu ermöglichen. Entscheidungspunkte müssen so gewählt werden, dass die Zeit bis zum Erreichen und Überschreiten des Entscheidungspunkts angemessen ist. Die Aufgaben, die zwischen zwei Entscheidungspunkten anfallen, dienen dazu, das Ziel des Entscheidungspunkts zu erreichen. Somit bieten sich die Entscheidungspunkte als Abgrenzung für die Bereiche des V-Modells an. 55

60 5 Integrationsvarianten von SCRUM in das V-Modell XT Nun wird der Informationsfluss des V-Modells, dessen Herleitung in Kapitel 3.4 beschrieben wird, zusammen mit den Entscheidungspunkten des V-Modells betrachtet. In Abbildung 5.2 werden die Entscheidungspunkte für ein AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration, die für die Systementwicklung eine Rolle spielen, in Kombination mit den Informationsflüssen der Produkte dargestellt. Zur Vereinfachung werden nur die Produkte, Entscheidungspunkte und Informationsflüsse eingezeichnet und die Aktivitäten und Rollen an dieser Stelle nicht betrachtet. Zum einen werden die Produkte von anderen Produkten erzeugt, zum anderen werden die Produkte von Entscheidungspunkten gefordert. Die Abbildung beschränkt sich vereinfachend auf die reine Entwicklung von Software ohne Hardware und ohne Unterstützungssystem oder Externe Produkte. Abbildung 5.2: Entscheidungspunkte für ein AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration, sowie die von ihnen geforderten Produkte inklusive vereinfachtem Informationsfluss Produkte, die in der Abbildung blau umrandet sind, sind Produkte, die von Entscheidungspunkten explizit gefordert werden. Produkte, die in der Abbildung schwarz umrandet sind, sind Produkte, die von keinen Entscheidungspunkten gefordert werden, aber dennoch von geforderten Produkten erzeugt werden. Die Produkte System, Segment, SW-Einheit, SW-Komponente und SW-Modul hängen hierarchisch voneinander ab. Ein System besteht aus einem oder mehre- 56

61 5 Integrationsvarianten von SCRUM in das V-Modell XT ren Segmenten, welche wiederum aus einem oder mehreren SW-Einheiten bestehen. Dies geht bis zum SW-Modul, welches das hierarchisch tiefste Stück Software darstellt. Aus V-Modell-Sicht fließen Informationen in die SW-Module und SW-Komponenten. Somit fließen indirekt auch Informationen in die SW-Einheit, Segmente und das System. Um diese Tatsache zu visualisieren, wird in der Abbildung die hierarchische Beziehung der Produkte mit UML dargestellt. Das Produkt Prüfspezifikation Systemelement ist auf der linken Seite eingezeichnet. Dies soll symbolisieren, dass es gleichermaßen von den drei Entscheidungspunkten System spezifiziert, System entworfen und Feinentwurf abgeschlossen gefordert wird. Analog ist das Produkt Prüfprotokoll Systemelement auf der rechten Seite eingezeichnet, da es von den Entscheidungspunkten Lieferung durchgeführt, System integriert und Systemelemente realisiert gefordert wird. Die Produkte Projektfortschrittsentscheidung, Projektplan, Projektstatusbericht und QS-Bericht werden in ausnahmslos allen in dieser Abbildung abgebildeten Entscheidungspunkten gefordert. Mit Ausnahme des Projektplans, welcher keine in der Abbildung aufgelisteten Produkte erzeugt, erzeugen sie keine weiteren Produkte des V-Modells. Zudem werden sie von Entscheidungspunkten gefordert, die vor den in der Abbildung dargestellten Entscheidungspunkten liegen und müssen somit schon zu einer früheren Phase des Projekts erstellt werden. Daher können sie in dieser Abbildung vernachlässigt werden. In der Abbildung wurden zwei Namen von Produkten auf Grund ihrer Länge abgekürzt. Die Abkürzung IIPS steht für das Produkt Implementierungs-, Integrations- und Prüfkonzept System und die Abkürzung IIPSW steht für das Produkt Implementierungs-, Integrations- und Prüfkonzept SW. Des weiteren ist zu beachten, dass die Produkte QS-Handbuch und Projekthandbuch schon von einem früheren Entscheidungspunkt gefordert werden und daher schon zuvor erstellt worden sind. Deswegen werden in der Abbildung nur Produkte betrachtet, die von den abgebildeten Entscheidungspunkten gefordert werden. Bevor nun konkret angegeben werden kann, welche Bereiche mit SCRUM durchgeführt werden, wird zuerst die folgende Annahme getroffen. Annahme 5.1 Die Durchführung von SCRUM soll immer zwischen ganzen Entscheidungspunkten durchgeführt werden. Endet SCRUM zwischen zwei Entscheidungspunkten, ohne alle Produkte des nachfolgenden Entscheidungspunktes zu erstellen, so müssen die restlichen Produkte über die V-Modell-basierte Methode erstellt werden, damit der nachfolgende Entscheidungspunkt passiert werden kann. Werden diese Produkte nicht erzeugt, kann auch der Entscheidungspunkt laut V-Modell nicht passiert werden. Werden allerdings alle Produkte erzeugt, die von dem nachfolgenden Entscheidungspunkt gefordert würden, sofern die Entwicklung V-Modell-basiert ablaufen würde, so könnte der Entscheidungspunkt passiert werden. Daher ist es sinnvoll, SCRUM immer bei beziehungsweise kurz nach oder vor einem Entscheidungspunkt enden zu lassen. Dies wird in Kapitel aus- 57

62 5 Integrationsvarianten von SCRUM in das V-Modell XT führlicher diskutiert. Beginnt SCRUM zwischen zwei Entscheidungspunkten, so ist es möglich, dass Produkte bereits auf V-Modell-basierte Art erstellt worden sind. Diese Vorgehensweise ist prinzipiell möglich, da diese Produkte als Eingabe für SCRUM dienen können, sofern dies gefordert wird. Der Nachteil in dieser Methode besteht darin, dass durch das V- Modell Einschränkungen an die Reihenfolge der Erstellung von Produkten gestellt werden. So könnte beispielsweise die Systemspezifikation nicht erstellt werden, solange es keine Systemarchitektur gibt. In SCRUM wäre es denkbar, die Systemarchitektur nicht als Dokument fertigzustellen und direkt zur Systemspezifikation überzugehen. Daher ist es sinnvoll, SCRUM direkt nach Entscheidungspunkten beginnen zu lassen. Genauere Überlegungen in diese Richtung werden in Kapitel angestellt. Aus Abbildung 5.2 lassen sich nun einzelne Integrationsvarianten für die Integration von SCRUM gewinnen, welche unterschiedliche Bereiche beschreiben, die mit SCRUM durchgeführt werden sollen. Dabei wird in den Kapiteln bis für jede Variante angegeben, wann sie eingesetzt werden sollte und welche Konsequenzen dies hat. Der Bereich, der mit SCRUM durchgeführt werden soll, wird dabei mit einem roten Rahmen gekennzeichnet. Abbildung 5.3 zeigt ein Beispiel für einen solchen Rahmen. Jede Variante beginnt direkt nach einem Entscheidungspunkt und endet unmittelbar vor oder nach einem der folgenden Entscheidungspunkte. In der Abbildung 5.3 ist Entscheidungspunkt B der erste Entscheidungspunkt des Bereichs. Somit beginnt SCRUM direkt nachdem Entscheidungspunkt A überschritten wurde. SCRUM endet kurz vor oder nach Entscheidungspunkt C (vergleiche Kapitel 5.2.2). Das bedeutet, dass alle Produkte, die in Entscheidungspunkt C gefordert werden, mit SCRUM erstellt werden müssen. Abbildung 5.3: Kennzeichnung des mit SCRUM durchzuführenden Bereichs Variante 1: SCRUM für Systementwicklung Die erste Variante für die Integration von SCRUM besteht darin, SCRUM für die Systementwicklung einzusetzen. Es soll also das gesamte System mit SCRUM entwickelt werden. Dies umfasst den Entwurf, die Realisierung und die Integration des Systems. In Abbildung 5.4 sind die Entscheidungspunkte und Produkte rot markiert, dessen Auf- 58

63 5 Integrationsvarianten von SCRUM in das V-Modell XT gaben mit SCRUM durchgeführt werden sollen. Die Produkte SW-Komponente und SW-Modul werden nicht von Entscheidungspunkten gefordert, sind aber dennoch im roten Bereich enthalten. Dies liegt daran, die Erstellung der SW-Einheiten und somit der Segmente und des Systems ohne die beiden Produkte wenig sinnvoll wäre. SCRUM startet direkt nach dem Entscheidungspunkt System spezifiziert. Es sind also bereits das Pflichtenheft, sowie die Produkte Prüfspezifikation Dokument und Prüfspezifikation Systemelement vorhanden. Alle eingehenden Flüsse in die SCRUM- Integrations-Aktivität, kommen vom Pflichtenheft. Daher werden die Informationen des Pflichtenhefts in das Product Backlog übernommen. Weitere Informationen von anderen Produkten müssen nicht in das Product Backlog übernommen werden. Abbildung 5.4: Durch die erste Variante markierter Bereich in einem AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration Mit SCRUM sollen die Produkte System und Segment erstellt werden. Daher sind diese das Ergebnis von SCRUM. Allerdings müssen nach Kapitel 4.1 alle Produkte erstellt werden, die nach V-Modell von Produkten erzeugt worden wären, welche innerhalb des Bereichs liegen, welcher nun mit SCRUM durchgeführt wird. Dies betrifft die Produkte Prüfspezifikation Systemelement, Make-or-Buy Entscheidung, Prüfprozedur Systemelement und Prüfprotokoll Systemelement. Das Ziel ist es, das gesamte System mit SCRUM zu erzeugen, wozu auch die Durchführung der Tests gehört. Aus diesem Grund sollte die Auswahl des Bereichs erweitert 59

64 5 Integrationsvarianten von SCRUM in das V-Modell XT werden. Die rote, gestrichelte Linie in Abbildung 5.4 markiert die erweiterte Auswahl. Die Produkte Prüfspezifikation Systemelement und Prüfprozedur Systemelement wurden in den erweiterten Bereich aufgenommen. Dadurch müssen Informationen aus dem Produkt Projekthandbuch ebenfalls in das Product Backlog fließen. Die Makeor-Buy Entscheidung muss in dieser Variante erzeugt werden. Allerdings wäre es auch denkbar, diese in den Bereich mit aufzunehmen, da sie keine weiteren Produkte erzeugt und auch von keinem Entscheidungspunkt gefordert wird. Das Produkt Prüfprotokoll Systemelement wird in folgenden Entscheidungspunkten gefordert und muss daher auf jeden Fall erzeugt werden, auch wenn es in den erweiterten Bereich mit aufgenommen werden würde. Abbildung 5.5 zeigt die Informationsflüsse nach der Integration von SCRUM. Die schwarz dargestellten Produkte sind die Produkte, die als Ziel erstellt werden müssen. Die blau dargestellten Produkte müssen zusätzlich auf Grund der Charakteristik des V-Modells erstellt werden. Abbildung 5.5: Aus Abbildung 5.4 resultierende Informationsflüsse nach der Integration von SCRUM Durch den Vergleich der Abbildungen 5.4 und 5.5 wird ersichtlich, dass die Produkte Implementierungs-, Integrations- und Prüfkonzept System, Systemarchitektur, 60

65 5 Integrationsvarianten von SCRUM in das V-Modell XT Systemspezifikation, Prüfprozedur Systemelement, Implementierungs-, Integrations- und Prüfkonzept SW, SW-Architektur, SW-Spezifikation, SW-Einheit, SW- Komponente und SW-Modul, also zehn an der Zahl, eingespart werden können. Zudem kann die Änderung des Produkts Prüfspezifikation Systemelement gespart werden. Vorteile Diese Variante bietet den Vorteil viel Zeit einsparen zu können, indem viele Produkte eingespart werden können. Die vom V-Modell geforderten Produkte (speziell die Dokumentation dieser) ist sehr zeitaufwendig und wird somit durch SCRUM gespart. Außerdem können die bereits genannten Vorteile von SCRUM in Bezug auf die Systementwicklung zu einem hohen Anteil genutzt werden, da in dieser Variante ein hoher Prozentsatz der Systementwicklung mit SCRUM durchgeführt wird. Besonders zu erwähnen ist die hohe Flexibilität dieser Variante. Auf späte Änderungen im Pflichtenheft oder von anderer Stelle kann leicht und schnell reagiert werden und führt lediglich, wenn überhaupt, zu geringen Problemen. Als Eingabe für das Product Backlog dient in dieser Variante nur das Pflichtenheft. Es müssen also nur die Informationen des Pflichtenhefts in das Product Backlog übernommen werden. Je nach Größe des Pflichtenhefts kann dies kürzer oder länger dauern. Nachteile Allerdings besitzt diese Variante auch Nachteile. In einigen Fällen, beispielsweise wenn das Leben von Anwendern betroffen sein kann, wie zum Beispiel in der Luftfahrt und Automobilindustrie, müssen Dokumente angefertigt werden, um im Falle des Versagens eines Endprodukts nachweisen zu können, dass die Systementwicklung fehlerfrei vorgenommen wurde. Dieser Nachweis geschieht über formale Dokumente, also Produkte, die vom V-Modell gefordert werden. In solchen Fällen müssen einige Produkte nach Abschluss von SCRUM nachdokumentiert oder während der Durchführung von SCRUM erzeugt werden, sofern die Dokumente, die mit SCRUM erzeugt werden, nicht als ausreichende, rechtliche Grundlage betrachtet werden können. Dies ist allerdings ein allgemeiner Kritikpunkt an SCRUM, welcher nicht durch die Integration von SCRUM zum Tragen kommt. Dennoch wird er umso höher bewertet, je mehr Bereiche mit SCRUM durchgeführt werden Variante 2: SCRUM für Komponentenentwicklung Die zweite Variante ähnelt der ersten Variante mit der Ausnahme, dass nun nicht das gesamte System, sondern lediglich SW-Einheiten mit SCRUM erstellt werden sollen. Dies umfasst in diesem Fall den Feinentwurf und die Realisierung der Systemelemente. 61

66 5 Integrationsvarianten von SCRUM in das V-Modell XT In Abbildung 5.6 sind wieder die Entscheidungspunkte und Produkte rot umrandet, dessen Aufgaben mit SCRUM durchgeführt werden sollen. SCRUM beginnt unmittelbar nach dem Entscheidungspunkt System entworfen. Das bedeutet, dass die Produkte Implementierungs-, Integrations- und Prüfkonzept System, Systemarchitektur und Systemspezifikation vorhanden sind. Da die ersten beiden Produkte Produkte erstellen würden, die sich im ausgewählten Bereich befinden, werden ihre Informationen in das Product Backlog übernommen. Abbildung 5.6: Durch die zweite Variante markierter Bereich in einem AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration Das Ziel von SCRUM ist in dieser Variante die Erstellung der SW-Einheiten. Diese sind also Ausgabe von SCRUM. Erneut müssen weitere Produkte erstellt oder verändert werden, die von nun wegfallenden Produkten im V-Modell erstellt worden wären. Namentlich sind dies die Produkte Prüfspezifikation Systemelement, SW- Komponente, SW-Modul, Prüfprozedur Systemelement, Make-or-Buy Entscheidung und Prüfprotokoll Systemelement. Die Prüfspezifikation Systemelement wird in den erweiterten Bereich gekennzeichnet durch die rote, gestrichelte Linie aufgenommen, da auch in dieser Variante die SW-Einheit mit SCRUM getestet werden soll. Dies hat wiederum zur Folge, dass Informationen aus dem Projekthandbuch in das Product Backlog aufgenommen werden müssen. 62

67 5 Integrationsvarianten von SCRUM in das V-Modell XT Allerdings muss das Produkt Prüfprotokoll Systemelement erstellt werden, da dieses in später folgenden Entscheidungspunkten gefordert wird. Die Informationsflüsse nach der Integration von SCRUM werden in Abbildung 5.7 dargestellt. Abbildung 5.7: Aus Abbildung 5.6 resultierende Informationsflüsse nach der Integration von SCRUM Auch hier wird durch einen Vergleich der Abbildungen 5.6 und 5.7 deutlich, dass die Produkte Implementierungs-, Integrations- und Prüfkonzept SW, SW-Architektur, SW-Spezifikation, SW-Komponente und SW-Modul eingespart werden konnten. Im Gegensatz zur ersten Variante sind dies allerdings nur noch fünf Produkte. Wie in Variante 1 kann auch die Änderung des Produkts Prüfspezifikation Systemelement gespart werden. Vor- und Nachteile Die Vor- und Nachteile dieser Variante sind analog zur ersten Variante aufzulisten. Da in dieser Variante der SCRUM-Anteil nicht ganz so hoch ist, sind folglich sowohl die Vor- als auch die Nachteile nicht so groß. Die Zeitersparnis durch das Einsparen von Produkten des V-Modells fällt nicht so hoch aus, wie bei der ersten Variante, da weniger Bereiche mit SCRUM durchgeführt wer- 63

68 5 Integrationsvarianten von SCRUM in das V-Modell XT den und somit weniger Produkte eingespart werden können. Das Product Backlog ist auf Informationen aus den beiden Produkten Systemarchitektur und Implementierungs-, Integrations- und Prüfkonzept System angewiesen. Die Gewinnung dieser Informationen kann recht schnell von statten gehen, was allerdings von ihrer Größe abhängt. Prinzipiell fallen die relevanten Informationen dieser Produkte und die Produktgröße insgesamt aber geringer aus, als die Größe des Pflichtenhefts, wodurch die Zeit für die Übernahme von Informationen aus Produkten im Vergleich zur ersten Variante geringer ausfällt. Die Flexibilität sinkt ebenfalls, da bereits einige Entscheidungen im Vorfeld getroffen wurden. Diese Entscheidungen zu ändern oder rückgängig zu machen kostet verhältnismäßig viel Zeit und Geld. Auf der anderen Seite ist die Sicherheit aus rechtlicher Sicht höher, da mehr Produkte gemäß V-Modell, wie in Variante 1 erwähnt, erstellt werden müssen. Der Anteil der Nachdokumentation kann somit geringer ausfallen Variante 3: SCRUM für Entwurf In der dritten Variante wird SCRUM nur für die Entwicklung des Entwurfs verwendet. Die Realisierung, Integration und Tests werden anschließend gemäß V-Modell durchgeführt. Es wird sich später zeigen, dass durch die in Kapitel 4.1 getroffenen Entscheidungen diese Variante für die Anwendung nicht zu gebrauchen ist, da die Produkte, die im Entwurf angefertigt werden, fast alle direkt mit den zu realisierenden Produkten der nachfolgenden Entscheidungspunkte zusammenhängen. Die rote Markierung in Abbildung 5.8 kennzeichnet den Bereich, der mit SCRUM durchgeführt werden soll. Der Bereich beginnt, wie in Variante 1, unmittelbar nach Überschreiten des Entscheidungspunkts System spezifiziert. Es sind die Produkte Prüfspezifikation Dokument und Prüfspezifikation Systemelement, sowie das Pflichtenheft vorhanden, dessen Informationen mit der Begründung aus Variante 1 in das Product Backlog fließen. Das Ziel von SCRUM ist die Erstellung der Produkte Implementierungs-, Integrationsund Prüfkonzept SW, SW-Architektur und SW-Spezifikation, mit deren Hilfe später das System realisiert werden soll. Diese Produkte sind somit das Erzeugnis von SCRUM. Nun verdeutlicht Abbildung 5.8 allerdings, dass viele später zu erzeugende Produkte von den Produkten Systemarchitektur und Implementierungs-, Integrations- und Prüfkonzept System abhängen. Gemäß Kapitel 4.1 müssen diese Produkte somit alle erzeugt werden. Allerdings werden diese Produkte erst in viel später folgenden Entscheidungspunkten benötigt. Würden die Produkte Segment und SW-Einheit bereits zu diesem Zeitpunkt erzeugt, würde dies auch bedeuten, dass die Produkte SW- Komponente und SW-Modul jetzt erzeugt werden sollten, da sie Bestandteile der SW-Einheit sind. Somit würde den folgenden Arbeitsschritten des V-Modells sehr weit voraus gegriffen und sogar kurzfristig ein Entscheidungspunkt übersprungen werden, um das Produkt Segment zu erzeugen. Auf jeden Fall wäre eine Systemrealisierung die Folge, welche eigentlich noch nicht vorgenommen werden sollte. 64

69 5 Integrationsvarianten von SCRUM in das V-Modell XT Abbildung 5.8: Durch die dritte Variante markierter Bereich in einem AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration Um dieses Problem zu lösen, könnte außerhalb der in Kapitel 4.1 gemachten Aussagen, die Produkte Systemarchitektur und Implementierungs-, Integrations- und Prüfkonzept System erzeugt werden. Allerdings würde zum einen die Prüfung der Produkte durch einen Entscheidungspunkt, und somit durch ein Gremium, fehlen. Zum anderen wären somit die Vorteile im Vergleich zum V-Modell-basierten Prozess gering. Es wäre daher sinnvoll, den Entwurf mit dem V-Modell zu erstellen, sofern die Realsierung, Integration und Tests auch mit dem V-Modell durchgeführt werden sollen Variante 4: SCRUM für Realisierung, Integration und Test In der vierten Variante wird SCRUM für die Realisierung, Integration und Durchführung von Tests eingesetzt. Der Entwurf wurde bereits gemäß V-Modell erstellt und nun soll das System bis zur Lieferung erstellt und getestet werden. Abbildung 5.9 stellt den ausgewählten Bereich in einer roten Markierung dar. Der Bereich umfasst die Entscheidungspunkte Systemelemente realisiert und System integriert. Informationen für das Product Backlog werden aus dem Pflichtenheft und den bereits erstellten Produkten Systemarchitektur, Implementierungs-, Integrations- und 65

70 5 Integrationsvarianten von SCRUM in das V-Modell XT Prüfkonzept System, SW-Architektur, Implementierungs-, Integrations- und Prüfkonzept SW und Projekthandbuch hergeleitet. Abbildung 5.9: Durch die vierte Variante markierter Bereich in einem AG/AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration Das Ziel dieser Variante ist die Erstellung des Systems. Wie in Variante 1 sind auch hier die Ausgabeprodukte von SCRUM das System und das Segment. Hinzu kommt das Produkt Prüfprotokoll Systemelement. Da alle im Bereich enthaltenen Produkte keine weiteren Produkte erzeugen, muss dies auch nicht durch SCRUM geschehen. Somit ergeben sich die in Abbildung 5.10 dargestellten Informationsflüsse nach der Integration von SCRUM. Es werden also die Produkte SW-Einheit, SW-Komponente und SW-Modul eingespart. Vorteile Die Vorteile der vierten Variante bestehen in einer geringen Zeitersparnis während der Realisierung, Integration und Durchführung von Tests. Immerhin kann dieses auf Basis agiler Methoden durchgeführt werden, was einige Vorteile der agilen Entwicklung und Entwicklung mit SCRUM mit sich bringt. Die Produkte, die für die Realisierung des Entwurfs gefordert werden, liegen bereits vor. Dies bietet eine gute Rechtsgrund- 66

71 5 Integrationsvarianten von SCRUM in das V-Modell XT lage im Falle fehlerhafter Endprodukte. In dieser Variante wird dieser Vorteil mit den Vorteilen der Realisierung mit Hilfe agiler Methoden verbunden. Abbildung 5.10: Aus Abbildung 5.9 resultierende Informationsflüsse nach der Integration von SCRUM Nachteile Dies zieht allerdings den Nachteil der sinkenden Flexibilität mit sich. Sollen späte Änderungen vorgenommen werden, müsse diese in den entsprechenden, zuvor erstellten Produkten der Entwurfsphase geändert werden. Oft sind hier auch kleine Änderungen, die erst in der Realisierung erkannt und nötig geworden sind, schwerer durchzuführen, als in den ersten beiden Varianten. Ein weiterer Nachteil ist die große Anzahl Produkte, dessen Informationen in das Pro- 67

72 5 Integrationsvarianten von SCRUM in das V-Modell XT duct Backlog übernommen werden müssen. Zusätzlich zu Informationen aus dem möglicherweise sehr großen Pflichtenheft müssen Informationen aus fünf weiteren Produkten in das Product Backlog einfließen. Die Aufbereitung dieser Produkte kann also sehr viel Zeit in Anspruch nehmen. 5.2 Allgemeine Variationen Im Folgenden werden Variationen angegeben, die unter anderem unabhängig von den Entscheidungspunkten aus Kapitel 5.1 betrachtet werden. Zum einen betrifft dies allgemeine Varianten, die unabhängig vom Projektfortschritt durchzuführen sind. Zum anderen werden Varianten vollständigkeitshalber aufgeführt, die in einem Projekt nicht durchgeführt werden sollten Anzahl der eingesetzten Teams Insbesondere für größere Projekte wird in SCRUM nicht nur ein einziges Team eingesetzt. Um den kompletten Umfang großer Projekte in angemessener Zeit bewältigen zu können, müssen mehr als neun Personen für SCRUM eingesetzt werden. Dies kann auch für die Integration von SCRUM gewünscht sein. Sollten mehr als neun Personen zum Einsatz kommen, ist es, wie SCRUM vorgibt, wichtig, dass die Teamgröße nicht über neun Teammitglieder hinaus geht. Es müssen also mehrere Teams gebildet werden. Die Koordination der Teams läuft über das sogenannte, in SCRUM vorgeschlagene, SCRUM of SCRUMs. Dabei trifft sich jeweils ein Repräsentant pro Team nach einem SCRUM Meeting des Teams mit den anderen Repräsentanten der anderen Teams, welche ein eigenes SCRUM-Meeting auf höherer Ebene durchführen. Der Repräsentant kehrt anschließend zu seinem Team zurück und gibt die erhaltenen Informationen weiter, sofern dies notwendig ist. In der Regel sollten die Entwickler, die V-Modell-basiert entwickelt haben, auf diese Teams aufgeteilt werden. Probleme dabei gibt es, wenn mehr Entwickler für SCRUM eingesetzt werden sollen, als zuvor beschäftigt waren. Solange aber nicht mehr als neun Mal so viele Entwickler für SCRUM eingesetzt werden sollen, können die bisherigen Entwickler auf die Teams aufgeteilt werden, so dass jedes Team einen Entwickler mit an Bord hat, der sich mit den bisherigen Prozessen auskennt Endpunkt der Integration von SCRUM für Entscheidungspunkte Wird SCRUM gemäß Kapitel 5.1 zwischen Entscheidungspunkten durchgeführt, so bleibt die Frage offen, ob SCRUM kurz vor einem Entscheidungspunkt oder kurz nach einem Entscheidungspunkt enden soll. Beide Varianten haben ihre eigenen Vor- und Nachteile. 68

73 5 Integrationsvarianten von SCRUM in das V-Modell XT Endet SCRUM kurz vor einem Entscheidungspunkt, so steht die nachfolgende Prüfung der Produkte, die durch den Entscheidungspunkt gefordert werden, noch an. Die Produkte müssen somit korrekt mit SCRUM erstellt worden sein, um eine Prüfung erfolgreich durchzustehen. Produkte, die der vom V-Modell geforderten Qualität nicht entsprechen, werden somit identifiziert und verbessert, was die Qualität der von SCRUM gelieferten Produkte sicherstellt. Allerdings erzielt SCRUM in der Regel qualitativ hochwertige Ergebnisse. SCRUM sollte eigene Mechanismen durchführen, um die Qualität der Arbeit und der Produkte sicherzustellen. Eine erneute Überprüfung der Produkte führt in gewisser Hinsicht zu keinem neuen Wissensgewinn. Endet SCRUM kurz hinter einem Entscheidungspunkt, so entfällt die vom V-Modell geforderte Prüfung durch den Entscheidungspunkt. Die Entwicklung kann weiter gehen, ohne dass eine zeitaufwändige Prüfung durch das Management durchgeführt werden muss Integration von SCRUM ohne Entscheidungspunkte In Kapitel 5.1 wurde vorgeschlagen, SCRUM genau zwischen Entscheidungspunkten durchzuführen, also den Bereich direkt hinter Absolvieren eines Entscheidungspunktes anzusetzen und kurz vor oder nach einem anderen Entscheidungspunkt enden zu lassen. Denkbar wäre es auch, den Start- und Endpunkt von SCRUM unabhängig von den Entscheidungspunkten zu wählen. Allerdings ist dabei zu berücksichtigen, dass die Entscheidungspunkte vor und nach der Durchführung von SCRUM dennoch im V-Modell eine Rolle spielen. Wird der Startpunkt nicht unmittelbar nach einem Entscheidungspunkt gewählt, so bedeutet dies, dass zwischen dem letzten Entscheidungspunkt und SCRUM bereits an Produkten gearbeitet worden ist. Es kann möglich sein, dass die Produkte noch nicht fertig gestellt worden sind. Damit die bisherige Arbeit, die in das Produkt eingeflossen ist, nicht umsonst war, muss SCRUM entweder mit dem unfertigen Produkt weiter arbeiten und versuchen, es fertig zu stellen oder aber die Informationen des Produkts in das Product Backlog übernehmen und somit mit den so gewonnen Informationen weiter arbeiten. Die erste Möglichkeit würde SCRUM in seiner Funktionsweise einschränken. Zudem bliebe die Frage offen, warum das Produkt nicht mit dem V-Modell fertig gestellt wurde. Die zweite Möglichkeit würde wiederum viel Zeit in Anspruch nehmen, um die Informationen aufzubereiten. Zudem würde das Produkt nicht fertiggestellt werden, wodurch einige Arbeit, die zuvor in die Erstellung des Produkts investiert wurde, umsonst gewesen wäre Integration von SCRUM für einzelne Informationsflüsse Eine weitere Variation besteht darin, Bereiche bestehend aus einzelnen Informationsflüssen zwischen Produkten mit SCRUM durchzuführen. Dies wird in der Regel dadurch problematisch, dass die meisten Informationsflüsse während der Systement- 69

74 5 Integrationsvarianten von SCRUM in das V-Modell XT wicklung zwischen sehr vielen Produkten fließen. In Abbildung 5.11 wird ein kleines Beispiel aus der Gesamtabbildung 5.2 gegeben, an dem dieser Punkt erläutert werden soll. Abbildung 5.11: Kleiner Ausschnitt aus Abbildung 5.2 mit ausgewähltem Bereich Die gesamte Architektur des Systems soll mit Hilfe von SCRUM erstellt werden. In Abbildung 5.11 wird der Bereich daher so gewählt, dass das Produkt SW-Architektur erzeugt wird und das Produkt Systemarchitektur eingespart werden kann. Nun müssen aber auf Grund dieser Einsparung und der Überlegungen aus Kapitel 4.1 die Produkte Systemspezifikation, Prüfspezifikation Systemelement, IIPSW, SW-Spezifikation, Prüfprozedur Systemelement und Make-or-Buy Entscheidung dennoch erzeugt werden. Zusätzlich werden als Eingang für SCRUM Informationen aus dem Produkt IIPS benötigt, die zu den zusätzlichen Eingangsinformationen hinzukommen. Im Endeffekt können somit keine Produkte eingespart werden. SCRUM müsste zudem sehr viele Produkte erzeugen, bevor wieder zum V-Modell-basierten Entwicklungsprozess zurückgekehrt werden kann, obwohl ursprünglich nur ein einziges Produkt mit SCRUM erzeugt werden sollte. Als Fazit ist es im Allgemeinen sehr schwierig, einzelne Informationsflüsse zwischen Produkten mit SCRUM zu ersetzen und zu erstellen. Es ist sinnvoller, SCRUM für größere Bereiche einzusetzen Nachdokumentation Werden durch die Entwicklung mit SCRUM Produkte eingespart, deren Erstellung im späteren Verlauf des Projekts aber unerlässlich sind, so müssen diese Produkte nachdokumentiert also nachträglich erstellt werden. Dies kann beispielsweise der Fall 70

75 5 Integrationsvarianten von SCRUM in das V-Modell XT sein, wenn ein Produkt durch Gründe rechtlicher Sicherheit vorhanden sein muss. Ein abschließender Testbericht, der alle durchgeführten Tests auflistet und begründet, warum diese Tests durchgeführt werden müssen, kann ein Beispiel dafür sein. Genauso können Begründungen von Designentscheidungen oder eine Auswahl einer Technologie schriftlich gefordert werden. Zudem gehen Informationen, die in den Gedächtnissen der Entwickler gespeichert und nicht dokumentiert sind im Verlaufe der Zeit verloren. Bereits zum Ende eines Projekts kann es schwierig sein, sich an Entscheidungen zu erinnern, die zu Beginn eines Projekts getroffen wurden. Noch schlimmer sieht es aus, wenn sich Entwickler an Projekte erinnern müssen, die Jahre in der Vergangenheit liegen. Oft wurden seit diesem Projekt andere Projekte durchgeführt, die damals getroffene Entscheidungen verdrängen. Werden nach längerer Zeit detaillierte Informationen benötigt, ist es für Entwickler fast schon unmöglich, sich im Detail an das Projekt und die Entscheidungen zu erinnern. Dabei stellt sich die Frage, ob gut und sauber dokumentierte Erzeugnisse von SCRUM diese Produkte ersetzen können. Die Antwort auf diese Frage fällt von Unternehmen zu Unternehmen unterschiedlich aus. Daher sollen an dieser Stelle möglichst effektive Formen der Nachdokumentation vorgestellt werden. Der einfachste Versuch, die fehlenden Produkte nachträglich zu erzeugen, führt über die in SCRUM entstandene Dokumentation. So werden beispielsweise Entscheidungen bezüglich der Erstellung von Code in diesem Code als Kommentare festgehalten. Sind diese Kommentare sauber und logisch erstellt worden, können sie durchaus als Dokumentation angesehen werden. Um diesen Aspekt zu nutzen, müssen alle Entwickler hoch diszipliniert ihren Code kommentieren. Sollten die Kommentare allein nicht ausreichen und ist eine Aufbereitung dieser Kommentare notwendig, so können sie dennoch erheblich dazu beitragen, die Aufbereitung zu beschleunigen. Frühere Entscheidungen sind mit Hilfe der Kommentare leichter ins Gedächtnis zu rufen. Entwickler können sich so unter Umständen vollständig an bereits vergessene Informationen erinnern. Zudem können große Teile der Kommentare aufbereitet und übernommen werden, wodurch das Produkt nicht von Grund auf neu geschrieben werden muss. Reichen Kommentare als Dokumentation oder Informationsquelle nicht aus, kann ein Schritt weiter gegangen werden, indem eine entsprechende Rolle allein für die Aufgabe der Dokumentation geschaffen wird. Die Person, die diese Rolle bekleidet, hat während der gesamten Durchführung von SCRUM ausschließlich die Aufgabe, Entscheidungen und Vorgänge zu dokumentieren, die bezüglich der kritischen, fehlenden Produkte benötigt werden. Anschließend oder auch während dieser Aufgabe kann sie aus diesen Dokumentationen das Produkt erstellen, welches später in vergleichsweise guter Qualität vorliegt. Somit entsteht der Vorteil, dass die benötigten Produkte, die der Absicherung dienen, direkt während der Entwicklung geschrieben werden. Die Entwickler müssen sich somit nicht nachträglich mit der Erstellung von Produkte beschäftigen. Da die kritischen Produkte ohnehin erstellt werden müssen, wird bei dieser Methode keine zusätzliche 71

76 5 Integrationsvarianten von SCRUM in das V-Modell XT Zeit im Vergleich zu der Nachdokumentation am Ende der Entwicklungsphase benötigt. Der Nachteil bei dieser Variante ist, dass entweder ein zusätzlicher Mitarbeiter eingestellt werden muss oder aber ein Teammitglied diese Rolle bekleidet und somit für die eigentlich anstehende Arbeit nicht mehr zur Verfügung steht. Ein weiteres, großes Problem besteht darin, dass die dokumentierende Rolle nicht immer Entscheidungen, die Entwickler während ihrer Arbeit treffen, mitbekommt. Also müssen Informationen, wie weiter oben bereits gesagt, wieder aus Kommentaren gewonnen werden. Allerdings kann im Falle von Unklarheiten der entsprechende Entwickler direkt gefragt werden, welcher die Informationen noch frisch im Gedächtnis vorliegen hat. Es muss in diesem Fall also nachgefragt werden, warum Entwickler Entscheidungen getroffen haben, was diese vom Arbeiten abhält. Dies befreit die Entwickler somit nicht von ihrer Aufgabe, Code sauber zu kommentieren, da die Kommentare möglicherweise in Produkte einfließen. Selbst wenn dies nicht der Fall ist, sollte Code aus vielen anderen Gründen kommentiert werden. 72

77 6 Implementierung 6.1 Prototypische Entwicklung zur Ermittlung und Darstellung von Produktabhängigkeiten des V-Modells Für die Herleitung von Informationsflüssen in Kapitel 3 werden die Produktabhängigkeiten des V-Modells herangezogen. Das V-Modell gibt dabei an, welche Produktabhängigkeiten zwischen Produkten existieren. Allerdings besitzt das V-Modell sehr viele Produkte und somit auch sehr viele Produktabhängigkeiten. Um eine Übersicht über alle Produkte und ihre Abhängigkeiten zu bekommen, ist eine textuelle Darstellung, wie sie im V-Modell gegeben wird, ungeeignet. Eine grafische Übersicht über Produkte und ihre Produktabhängigkeiten ist wünschenswert, um einen Informationsfluss zu erkennen und einen Überblick über alle voneinander abhängigen Produkte zu bekommen. Zudem muss es möglich sein, kleinere Mengen von Produkten auszuwählen, damit Teilbereiche der gesamten Produktabhängigkeiten gezielt betrachtet werden können. Somit können ausschließlich Produkte, die zum Betrachtungszeitpunkt von Interesse sind, in den Fokus gerückt und betrachtet werden, um sich auf diese zu konzentrieren. Der entwickelte und im Folgenden beschriebene Prototyp zur Ermittlung und Darstellung von Produktabhängigkeiten des V-Modells wird genau diesen Forderungen gerecht. Zudem wird er benötigt, um alle Produkte bei der Planung der Integration von SCRUM zu berücksichtigen. Wird SCRUM für einen Teilbereich ausgewählt, so kann visuell angezeigt werden, welche Produkte von der Ersetzung betroffen sind. Somit ist schnell ersichtlich, ob Zwischenprodukte innerhalb des Bereichs erzeugt werden müssen. Mit Hilfe des Prototypen wird also das Risiko, dass Produkte übersehen und nicht erzeugt werden, minimiert Funktionsweise Um die Produktabhängigkeiten des V-Modells zu gewinnen, werden HTML-Seiten des V-Modells geparst. Die HTML-Seiten müssen mit dem Projektassistenten des V- Modells [vmo] gewonnen werden. Dies geschieht, indem ein Tailoring des durchzuführenden Projekts mit Hilfe des Projektassistenten durchgeführt wird. Das getailorte Projekt kann anschließend mit dem Assistenten in HTML-Format exportiert werden. Dafür müssen dort die Teile 3 und 5 der Dokumentation exportiert werden. Anschließend müssen die exportierten HTML-Seiten in die entsprechenden Ordner des Prototypen kopiert werden. Teil 3 beinhaltet Informationen über die Ent- 73

78 6 Implementierung scheidungspunkte und muss in den Ordner HTML_Decision_Gates kopiert werden. Teil 5 hingegen beinhaltet Informationen über die zu erzeugenden Produkte und muss folglich in den Ordner HTML_Products kopiert werden. Anschließend verfügt der Prototyp über alle benötigten Informationen aus dem V- Modell. Das Startmenü ist in Abbildung 6.1 dargestellt, in dem weitere Einstellungsmöglichkeiten vorgenommen werden können, welche die Aufgaben und damit resultierende Anzeige des Prototypen vorgibt. Abbildung 6.1: Hauptmenü des Prototypen zur Darstellung von Produktabhängigkeiten Der Prototyp kann sowohl erzeugende Produktabhängigkeiten, als auch inhaltliche Produktabhängigkeiten darstellen. Welche dieser Produktabhängigkeiten angezeigt werden soll, wird über die Kategorie Modus der Abhängigkeiten bestimmt. Die Einstellungsmöglichkeiten Erzeugende Abhängigkeiten und Erzeugte Abhängigkeiten unterscheiden sich durch die Leserichtung des Prototypen. Bei der ersten Variante wird die Richtung ausgehend vom erzeugenden Produkt hin zum erzeugten Produkt gelesen, bei der zweiten Variante wird die Richtung andersherum gelesen. Abbildungen 6.2 stellt beispielhaft dar, wie die Ausgabe für erzeugende und inhaltliche Produktabhängigkeiten aussieht. Da der Graph, welcher die Produkte und ihre Abhängigkeiten beinhaltet, sehr groß 74

79 6 Implementierung Abbildung 6.2: Kleines Beispiel für erzeugende (links) und inhaltliche (rechts) Abhängigkeiten aus dem V-Modell werden kann, können zusammengehörige Produkte zusammengefasst werden, um Platz zu sparen. Diese Funktion ist in der Kategorie Strukturierung zu aktivieren. Ein Beispiel wird in Abbildung 6.3 gegeben. Als zusammengehörig lassen sich die hierarchisch zusammengehörigen Produkte des Systems ( System, Segment, SW- Einheit, SW-Komponenten, SW-Modul ), der Architektur ( Systemarchitektur, SW- Architektur ) und der Spezifikation ( Systemspezifikation, SW-Spezifikation ) betrachten. Dies sind die Produkte, die durch strukturelle Produktabhängigkeiten miteinander verbunden sind. Abbildung 6.3: Kleines Beispiel für das Zusammenfassen von Produkten zur besseren Übersicht Der Prototyp bietet die Möglichkeit, anzeigen zu lassen, von welchen Entscheidungspunkten die angezeigten Produkte gefordert werden. Zudem lassen sich die Aktivitäten visualisieren, die zur Erstellung des Produkts durchgeführt werden, sowie die Rollen, die an dem Produkt mitwirken oder verantwortlich für das Produkt sind. Diese Funktionen können in der Kategorie Zusätzliche Anzeigen hinzugeschaltet werden. Standardmäßig werden alle Produkte und ihre Abhängigkeiten ungefiltert angezeigt. Allerdings kann es wünschenswert sein, nur einige der Produkte visualisieren zu las- 75

80 6 Implementierung sen. Dafür bietet der Prototyp eine Filterfunktion, die die angezeigten Produkte auf eine ausgewählte Menge beschränkt. Welche Produkte angezeigt werden sollen, lässt sich über das in Abbildung 6.4 dargestellte Menü, welches über den Button Produkte erreichbar ist, einstellen. Abbildung 6.4: Auswahlmenü des Prototypen zur Darstellung von Produktabhängigkeiten für Produkte des V-Modells. In dieses Menü kann über den Button Produkte aus Abbildung 6.1 gelangt werden. Nach der Generierung der dot-datei (vergleiche Kapitel 6.1.2) über den Button Generieren wird der Benutzer über die fehlerfreie Erstellung dieser Datei am unteren Bildschirmrand informiert. Zeitgleich wird ein Bild in PNG-Format erstellt, welches den Graphen beinhaltet. Die Erzeugung dieses Bildes kann je nach Rechenleistung des verwendeten Computers etwas Zeit in Anspruch nehmen. Dies ist in derartigen Fällen der Größe des zu visualisierenden Graphen geschuldet. Abschließend kann der Graph durch Klicken des Buttons Visualisieren angezeigt werden. 76

81 6 Implementierung Der Prototyp bietet die Möglichkeit, weitere Einstellungen vorzunehmen. Die Einstellungsmöglichkeiten reichen von der Wahl des Bildanzeigeprogramms über diverse Anpassung bis hin zu der Farbe der Pfeile des Graphen. Da diese Einstellungen in der Regel selten verwendet werden, gibt es dafür keine grafische Oberfläche. Stattdessen können die Änderungen über die im Ordner config vorhandene Konfigurationsdatei vorgenommen werden Technische Realisierung Wie in Kapitel bereits erwähnt, parst der Prototyp HTML-Seiten, die vom V- Modell-Projektassistenten erstellt wurden. Das Parsen der HTML-Seiten wird mit Hilfe der Java-Bibliothek jsoup [jso] durchgeführt. jsoup bietet Funktionen an, um eine HTML-Datei zu parsen und mit Java auf die geparsten Elemente zuzugreifen. Diese Elemente werden verwendet, um Informationen über Produkte, Produktabhängigkeiten, Entscheidungspunkte, Aktivitäten und Rollen zu gewinnen. Anschließend werden diese Informationen aufbereitet und in ein dot-format exportiert. Dieses Format kann von Graph Visualization [gra] gelesen und zu einem gerichteten Graphen verarbeitet werden, welcher im PNG-Format gespeichert und angezeigt werden kann. Für den abgebildeten Baum im Produktauswahlmenü wird das JIDE Common Layer von JIDE Software [jid] verwendet, welches die Möglichkeit bietet, einen Baum zusammen mit Checkboxes einzufügen und zu verwenden. Über diesen Baum geschieht die Selektion von Produkten (vergleiche Abbildung 6.4). 6.2 Leitfaden zur Integration von SCRUM in das V-Modell XT Zusätzlich zu den Ergebnissen dieser Arbeit soll ein Leitfaden erstellt werden, der diese Ergebnisse zusammenfasst und visuell anzeigt. Der Leitfaden dient der groben Entscheidungshilfe, welche Position für eine Integration von SCRUM am Besten für ein Unternehmen geeignet ist. Er nimmt dem Benutzer die Aufgabe ab, jede Variante zu prüfen und anschließend entscheiden zu müssen, welche Variante die passendste ist. Die Details zur Umsetzung der Variante müssen allerdings in der Arbeit selbst nachgelesen werden. Um bewerten zu können, welche Variante für den Benutzer am besten geeignet ist, werden die in Tabelle 4.1 angegebenen Vor- und Nachteile als Bewertungskriterien herangezogen. Das Bewertungsmenü des Leitfadens ist in Abbildung 6.5 abgebildet. Der Benutzer muss für jedes Kriterium angeben, wie wichtig ihm dieses ist. Zusätzlich wird nach der Größe des Projekts gefragt, da diese Frage für jedes durchzuführende Projekt relevant ist. Sind alle Kriterien bewertet worden, wird die Auswertung dieser Bewertung vorgenommen. Dazu wird jeder Vor- und Nachteil der Varianten 1 (Kapitel 5.1.1),2 (Kapitel 5.1.2) und 4 (Kapitel 5.1.4) gewichtet. Die Gewichtung fließt in die Gesamtbewertung der je- 77

82 6 Implementierung Abbildung 6.5: Hauptmenü des Leitfadens zur Integration von SCRUM in das V-Modell XT weiligen Variante ein, sofern das Kriterium als wichtig erachtet wurde. Wie genau die Gewichtung ausgewählt wurde, wird in Kapitel erklärt. Mit Hilfe des Buttons Weiter lassen sich die Varianten mit der besten Bewertung anzeigen (Abbildung 6.6). In einigen Fällen können zwei Varianten die gleiche Bewertung bekommen haben. Wenn dem so ist, werden beide Varianten vorgeschlagen. Für jede Variante wird angegeben, welches gewünschte Kriterium des Benutzers umgesetzt wird und welches nicht. Ein Kriterium wird komplett umgesetzt, wenn es als unwichtig beurteilt wurde oder die Variante bezüglich des Kriteriums Vorteile besitzt. Ein Kriterium wird teilweise umgesetzt, wenn die Variante bezüglich des Kriteriums geringe Vorteile besitzt. Nicht umgesetzt wird hingegen ein Kriterium, wenn die Variante bezüglich dieses Kriteriums Nachteile besitzt. Ob eine Variante bezüglich eines Kriteriums gut oder schlecht dasteht, hängt von der Art des Kriteriums und dem Vergleich zwischen ihr und den anderen Varianten ab. Kriterien, die aus Vorteilen entstanden sind, müssen möglichst hoch erfüllt sein, Kriterien, die aus Nachteilen entstanden sind hingegen möglichst gering. Die folgenden Kriterien stehen dem Benutzer zur Bewertung zu Verfügung. 78

83 6 Implementierung Abbildung 6.6: Vorschlag geeigneter Varianten. In dieses Menü kann über den Button Weiter aus Abbildung 6.5 gelangt werden. Zeitersparnis Eine Variante ist gut, wenn sie eine hohe Zeitersparnis mit sich bringt. Flexibilitätsgewinn Eine Variante ist gut, wenn sie eine hohe Flexibilität aufweist. Geringere Sicherheit Eine Variante ist gut, wenn sie wenig Sicherheitsverlust in Kauf nimmt. Erhöhter Aufbereitungsaufwand Eine Variante ist gut, wenn sie wenig Aufbereitungsaufwand bedarf. Wie gut oder schlecht eine Variante im Vergleich zu anderen Varianten ist, kann den Kapiteln 5.1.1, und entnommen werden. Zudem stellt der Leitfaden das der Variante zugehörige Bild dar, damit grundlegend ersichtlich ist, um welche Variante es sich handelt, sowie die Kapitelnummer dieser Arbeit, wo diese Variante weiter erläutert wird. Bei Bedarf kann die Variante somit leicht gefunden und Informationen nachgelesen werden. Im Falle von größeren Projekten, wird eine Anmerkung ausgegeben, dass die in Kapitel beschriebenen Hinweise bezüglich der Projektgröße berücksichtigt werden sollten. 79

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center Ihr starker IT-Partner. Heute und morgen PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr PRINCE2 TAG 2011 Peter Morwinski, Leiter Technologie Center INHALT PRINCE2 und V-Modell XT Einleitung

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr

Projektmanagement V-Modell XT-konform gestalten

Projektmanagement V-Modell XT-konform gestalten Projektmanagement V-Modell XT-konform gestalten PMI Munich Chapter Meeting 20. März 2007 Dr. Marc Sihling 2007 4Soft GmbH Agenda Überblick V-Modell XT Projektinitialisierung Tailoring Rollenbelegung Projektplanung

Mehr

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de Über mich Martin Lippert Senior IT-Berater bei akquinet it-agile GmbH martin.lippert@akquinet.de

Mehr

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Scrum. Eine Einführung

Scrum. Eine Einführung Scrum Eine Einführung Scrum-Charakteristika einfache Regeln wenige Rollen Pragmatismus statt Dogmatik iteratives Vorgehen Scrum auf einer Seite erklärt 3 Rollen für direkt am Prozeß beteiligte 1) Product

Mehr

2 Einführung in das V-Modell XT

2 Einführung in das V-Modell XT Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 2 Einführung in das V-Modell XT V-Modell XT Anwendung im Projekt

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile.

Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile. Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile.de Unser Hintergrund Agile Softwareentwicklung/Schulung/Beratung

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Software Engineering. 2. V-Modell XT

Software Engineering. 2. V-Modell XT Software Engineering 2. V-Modell XT Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication Software-Dokumentation im agilen Umfeld Marion Bröer, parson communication parson communication Software- und Prozessdokumentation Wissensmanagement Wikis und XML-basierte Dokumentation Schulungen und

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

Agile Software Development with Scrum

Agile Software Development with Scrum Agile Software Development with Scrum (Schwaber/Beedle, Prentice Hall, 2002) Ein Lesebericht von Robert Hagedorn und Dr. Juho Mäkiö Was ist eigentlich Scrum und wie kann es erfolgreich in der Systementwicklung

Mehr

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1 V-Modell Dipl. Wirtsch. Ing. Alexander Werth Software Engineering 11-1 Was ist das V-Modell? Das V im V-Modell steht für Vorgehensmodell. Umfangreiches Dokument. Softwaretool zur Unterstützung. Vorgabe

Mehr

6 Vorgehensbausteine.

6 Vorgehensbausteine. <Datum> <Organisation> <Veranstaltungsort> <Vortragender> <Organisation> Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 6 Vorgehensbausteine 1.2.1 Copyright V-Modell XT Das

Mehr

XP, Scrum, Crystal, FDD:

XP, Scrum, Crystal, FDD: XP, Scrum, Crystal, FDD: Welche agile Methode passt zu uns? Henning Wolf Christoph Kemp Was ist Agilität? Teil 1: Das agile Manifest We are uncovering better ways of developing software by doing it and

Mehr

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Extreme Programming Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Stand: 11.06.2007 LINEAS Gruppe - Zahlen und Fakten LINEAS Gruppe Branche Software- und

Mehr

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Unternehmensberatung H&D GmbH AFCEA Mittagsforum M. Sc. Dipl. Ing. (FH) Matthias Brechmann Agenda Unternehmensberatung H&D GmbH Anforderungen

Mehr

Agile Softwareentwicklung mit SCRUM

Agile Softwareentwicklung mit SCRUM Agile Softwareentwicklung mit SCRUM PMI MUC 01. März 2010 Referent: Gerhard Held mehr als 35 Berufsjahre in der Softwareentwicklung im Projektmanagement und verwandten Themen... Gründe für das Scheitern

Mehr

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm Agile Embedded Projekte mit Scrum & Kanban Embedded Computing Conference 2012 Urs Böhm Der Ingenieur Urs Böhm Dipl.-Ingenieur Elektrotechnik Projektingenieur VDI Certified ScrumMaster urs.boehm@noser.com

Mehr

Vorgehensmodell versus Prozessmodell 1(2) Vorgehensmodell versus Prozessmodell 2(2) Inhalt. Phasenmodell 2(7) Phasenmodell 1(7)

Vorgehensmodell versus Prozessmodell 1(2) Vorgehensmodell versus Prozessmodell 2(2) Inhalt. Phasenmodell 2(7) Phasenmodell 1(7) Vorlesung: Softwaretechnik I IV. Prozessmodelle Teil 1 Prof. Dr. Jens Grabowski Tel. 39 172022 Email grabowski@cs.uni-goettingen.de Vorgehensmodell versus Prozessmodell 1(2) Vorgehensmodelle geben Projektleitern/Entwicklern

Mehr

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs IT-Projektmanagement bei basecom Manuel Wortmann, Patrick Rolefs Vorstellrunde Mein Name ist, ich bin Jahre alt und mache meine Ausbildung bei. Übersicht wir sprechen internet Wasserfall - schön linear

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Das Who s Who der agilen Methoden Golo Roden

Das Who s Who der agilen Methoden Golo Roden Das Who s Who der agilen Methoden Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Christoph Redl Quelle der Fragen: http://www.informatik-forum.at/showthread.php?t=54097 1 SCRUM Prinzip + Vorteile

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

Softwaretechnik Prozessmodelle

Softwaretechnik Prozessmodelle Softwaretechnik Prozessmodelle Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin Celine: They enjoy the goal but not the process. But the reality of it is that the true work of improving things

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

ZuuL - Entwicklung eines Adventures

ZuuL - Entwicklung eines Adventures ZuuL - Entwicklung eines Adventures im Rahmen der Uni-Tage 2009 Team 120 Universität Hamburg 16./17. November 2009 Team 120 (Universität Hamburg) ZuuL - Entwicklung eines Adventures 16.11.09 1 / 21 Übersicht

Mehr

Das neue V-Modell XT. Methodik, Anwendung, Nutzen

Das neue V-Modell XT. Methodik, Anwendung, Nutzen Das neue V-Modell XT Methodik, Anwendung, Nutzen Wolfgang Kranz EADS Deutschland GmbH Defence Electronics 85716 Unterschleißheim Landshuterstr. 26 Tel. +49 89 3179-2786, Fax -2528 mobil: +49 172 8488200

Mehr

Das neue V-Modell XT. Methodik, Anwendung, Nutzen

Das neue V-Modell XT. Methodik, Anwendung, Nutzen Das neue V-Modell XT Methodik, Anwendung, Nutzen Wolfgang Kranz EADS Deutschland GmbH Defence Electronics 85716 Unterschleißheim Landshuterstr. 26 Tel. +49 89 3179-2786, Fax -2528 mobil: +49 172 8488200

Mehr

Agile Methoden vs. Testen

Agile Methoden vs. Testen Agile Methoden vs. Testen cc gmbh Bernhard Moritz CC GmbH TAV 27, AK Testmanagement, 6.6.2008 Bernhard Moritz Flachstraße 13 65197 Wiesbaden Telefon 0611 94204-0 Telefax 0611 94204-44 Bernhard.Moritz@cc-gmbh.de

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

Vorgehen im Softwareentwicklungsprozess

Vorgehen im Softwareentwicklungsprozess Der Softwareentwicklungsprozess Für die Entwicklung von Software, namentlich für große Projekte, ist ein systematisches Vorgehen notwendig. Dieses Vorgehen, der Softwareentwicklungprozess, wird strukturiert

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

m.e.d. concept methode erfolg datenverarbeitung V-Modell XT im Überblick 2 V-Modell XT Einführung - Analyse und Roadmap 3

m.e.d. concept methode erfolg datenverarbeitung V-Modell XT im Überblick 2 V-Modell XT Einführung - Analyse und Roadmap 3 Projektmanagement Kompetenztraining V-Modell XT Das V-Modell XT ist urheberrechtlich geschützt, Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten m.e.d. concept methode erfolg datenverarbeitung

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski 1. Was heißt Agil 2. Scrum? Grundbegriffe 3. Wer benutzt Scrum 4. Vorteile & Nachteile von

Mehr

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de Scrum Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher MCP und CCD > Autor, Sprecher

Mehr

Scrum Einführung. SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik

Scrum Einführung. SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik Scrum Einführung Do, Hoang Viet(do@mi.fu-berlin.de) Freie Universität Berlin, SoSe 2013 Rollen Product Owner Definiert die Ziele Product

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Scrum E I N F Ü H R U N G

Scrum E I N F Ü H R U N G Scrum EINFÜHRUNG Was ist Scrum? Agiles Vorgehensmodell Grundüberzeugungen Erste Tendenzen Mitte der 80er Jahre Grundidee: Entwickeln in Inkrementen Parallelen zur Lean Production Agiles Manifest Jeff Sutherland

Mehr

ANECON. Business Process meets Agile Software Development. DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung

ANECON. Business Process meets Agile Software Development. DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung ANECON Business Process meets Agile Software Development DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003 Agile Software Entwicklung mit Raffael Schweitzer 18. November 2003 Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche Erfolgsfaktoren Fazit Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

Starke vs. Schwache Prozesse. Seminarvortrag

Starke vs. Schwache Prozesse. Seminarvortrag Starke vs. Schwache Prozesse Seminarvortrag 1 / 16 Gliederung des Vortrags Starke vs. Schwache Prozesse 1. Hintergrund 2. Begrifflichkeiten 3. Vergleich agiler und plangesteuerter Prozesse (Orientierung

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl SCRUM Scrum in der Software Entwicklung von Ernst Fastl Agenda 1. Die Entstehung von Scrum 2. Überblick über den Prozess 3. Rollen 4. Meetings 5. Artefakte 6. Fragen & Antworten Agenda 1. Die Entstehung

Mehr

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

Wahlpflichtmodul Projekt I Softwareprojekt I

Wahlpflichtmodul Projekt I Softwareprojekt I Wahlpflichtmodul Projekt I Softwareprojekt I Dipl. Inf. Andrea Meyer SCRUM in Detail Dipl. Inf. Andrea Meyer WIEDERHOLUNG 4 Prinzipien von SCRUM Zerlegung Transparenz Anpassung Überprüfung WIEDERHOLUNG

Mehr

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Bernhard Fischer Fischer Consulting GmbH MedConf 2011 Luzern Folie 1 Wozu brauchen wir Requirements? MedConf 2011 Luzern Folie 2 Der Anforderungszoo

Mehr

Vertragsrecht in agilen Softwareprojekten. Prof. Ursula Sury, RA

Vertragsrecht in agilen Softwareprojekten. Prof. Ursula Sury, RA Vertragsrecht in agilen Softwareprojekten Prof. Ursula Sury, RA 1 Agenda Die zentrale Frage/ Grundelemente des Softwarevertrags Ablauf der Softwareentwicklung Ziele der agilen Software Besonderheiten der

Mehr

Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement. Bachelorarbeit

Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement. Bachelorarbeit Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA PM WBS Sprint Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA Über den Vortragenden IT-Leiter der Austrian Gaming Industries (Novomatic Group of Companies) MBA in

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 Sabotage in Scrum dem Prozess erfolglos ins Knie schiessen Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 1 Überblick Sabotage? Wer kann sabotieren? Was kann sabotiert werden? Wieviel

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

READY-STEADY-DONE! Der Product Owner are you READY for agile?!

READY-STEADY-DONE! Der Product Owner are you READY for agile?! READY-STEADY-DONE! Der Product Owner are you READY for agile?! Susanne Mühlbauer HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Neue Ideen sind

Mehr