K3_einführung in die SE.pdf

Manfred Broy Marco Kuhrmann Einführung in die Softwaretechnik Vorgehensmodelle in der Softwareentwicklung 3 Zusammenfassung Die Entwicklung von Software erfolgt im Rahmen von Projekten. Projekte be...

Manfred Broy Marco Kuhrmann Einführung in die Softwaretechnik Vorgehensmodelle in der Softwareentwicklung 3 Zusammenfassung Die Entwicklung von Software erfolgt im Rahmen von Projekten. Projekte benötig- ten eine angemessene Vorgehensweise. Wir sprechen von Vorgehensmodellen. Diese beschreiben die Aufbauorganisation sowie die Ablauforganisation eines Projektes. In der Aufbauorganisation wird die Teamstruktur festgelegt und in der Ablauforganisation der Prozess für die einzelnen Schritte zur Durchführung der Entwicklung. Darüber hin- aus sind geeignete Methoden für die Durchführung der geplanten Arbeitsschritte und zur Erarbeitung der Zwischenergebnisse, den Artefakten, zu wählen. Der Zusammenhang zwischen den Artefakten wird in einem sogenannten Artefaktmodell festgelegt. Wesent- liche Artefakte sind der Programmcode für das Softwaresystem, aber auch die Beschrei- bung der Anforderungen an das Softwaresystem, seine Architektur, seiner Qualitätseigen- schaften oder der zu verwendenden Testfälle. Die Wahl des Vorgehensmodells bestimmt in weiten Teilen wesentliche Faktoren der Softwareentwicklung wie die Kosten, den Zeit- aufwand und die erreichte Qualität. Vorgehensmodelle sind ein wesentliches Bindeglied zwischen Fragen der Organisation und des Managements und der technischen Durchfüh- rung von Softwareprojekten. Dieses Kapitel führt die grundlegenden Vorgehensmodelle und Rollen in Projekten ein und erläutert traditionelle und agile Vorgehensmodelle im Kontext der Softwareentwicklung. 3.1 Was ist ein Vorgehensmodell? Eine der Kernaufgaben in der Software- und Systementwicklung ist die Festlegung des projektspezifischen Vorgehens – eines sogenannten Vorgehensmodells. Die Festlegung ori- entiert sich an den Besonderheiten eines Projekts und muss einen stabilen Rahmen für das Projekt sicherstellen. © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2021 83 M. Broy und M. Kuhrmann, Einführung in die Softwaretechnik, Xpert.press, https://doi.org/10.1007/978-3-662-50263-1_3 84 3 Vorgehensmodelle in der Softwareentwicklung Vorgehensmodelle sind das Bindeglied zwischen den Aufgaben der Projektorganisation und des Managements und den methodischen und technischen Aufgaben der Software- und Systementwicklung. Sie strukturieren das Vorgehen und die Zuständigkeit für die spezifi- schen Aufgaben. Sie machen die Struktur von Projekten greifbar, vergleichbar und bewert- bar und sind somit ein wesentliches Erfolgskriterium für die erfolgreiche Durchführung von Projekten. Sie bilden die Grundlage für die Projektplanung und die Projektdurchführung. In hinreichend großen Unternehmen ist der Einsatz eines unternehmensweiten Vorgehensmo- dells oft verpflichtend, um die Software- und Systementwicklung koordiniert und struktu- riert durchzuführen. Auch Projekte, die bestimmte Domänen adressieren, etwa Automotive Software, Avionics, Space, Defense, Medical Devices oder Robotik, setzen die Anwendung von spezifischen, oft standardisierten Vorgehensmodellen unter Gesichtspunkten der „Com- pliance“ voraus. Nach verwenden wir für Vorgehensmodelle folgende Definition 3.1: Definition 3.1 (Vorgehensmodell) Ein Vorgehensmodell beschreibt systematische, orga- nisatorische, ingenieurmäßige und quantifizierbare Vorgehensweisen, um Aufgaben einer bestimmten Klasse wiederholbar zu lösen. Ein Vorgehensmodell beschreibt auch die Schnittstellen des Projekts zur Organisation, in die das Projekt eingebettet ist. Es ein Instrument zur Integration von Methoden und Praktiken, die für die Lösung eng umgrenzter Teilaufgaben verwendet werden, zum Beispiel für das Requirements Engineering oder das Testen. Im Kern strukturieren Vorgehensmodelle und die mit ihnen kombinierten Methoden und Praktiken ein Projekt und machen Vorgaben und Festlegungen hinsichtlich der Aufbau- und der Ablauforganisation [16, S. 31 ff.]: Aufbauorganisation Ein Vorgehensmodell beschreibt den Aufbau des Projektteams und zugehörige Aufgabenprofile über Rollen. Weiterhin werden Artefakt- modelle festgelegt, welche eine Ordnungsstruktur für Arbeitsergeb- nisse und ihre Abhängigkeiten zueinander beschreiben. Ablauforganisation Der grundsätzliche Arbeitsprozess, seine groben Aufgabenfelder, sowie Entwicklungsschritte in unterschiedlichen Detaillierungsgra- den werden beschrieben. Dies umfasst im Kern den technischen Ent- wicklungsprozess des Aufbaus/der Entwicklung des Systems unter Berücksichtigung der relevanten Kernaufgaben. Abb. 3.1 zeigt einen grundsätzlichen Rahmen, welche Vorgehensmodelle allgemein über sogenannte W-Fragen charakterisiert. In der Aufbauorganisation können diese W-Fragen der Form „Wer macht Was und Wie wird dabei vorgegangen?“ gestellt werden. Solche 3.2 Grundlegende Vorgehensmodelle und Prozessbeschreibungen 85 Womit? Was? Wer? Ph a se as Artefakt-/ Ph e Rollen- Produkt- modell modell Ablaufmodell Phas (Quasi-)Standards, ase Werkzeuge, etc. Ph e modell Phase Wie? Wann? Abb. 3.1 Bestandteile eines Vorgehensmodells nach Fragen lassen sich zum Beispiel wie folgt beantworten: „Der Tester erstellt Unit Tests zum Test der Software.“ Damit wird durch das Vorgehensmodell festgelegt: wer (Rolle: Tester) macht was (Artefakt: Unit Test); als Aktivität wird im Beispiel „erstellt“ verwendet. Was sich genau hinter „erstellt“ verbirgt, ist durch die Beschreibungen der zu nutzenden Metho- den im Vorgehensmodell zu definieren, etwa durch Aktivitätslisten. Die Ablauforganisation ergänzt hierzu die Frage nach dem Wann, also wann wird die Aktivität durchgeführt und wann muss das Ergebnis dieser Aktivität vorliegen. In einem Vorgehensmodells werden Gliederungseinheiten definiert, die Aufgaben in einem Projekt zusammenfassen und es so strukturieren. 3.2 Grundlegende Vorgehensmodelle und Prozessbeschreibungen Es gibt eine Vielzahl an unterschiedlichen Vorgehensmodellen, die jeweils spezifisch auf unterschiedliche Aufgaben oder Anwendungsdomänen ausgerichtet sind, spezifisch auf Unternehmen oder Projekttypen zugeschnitten sind, oder als generischer Standard formu- liert sind. Je nach Lesart, etwa der Festlegung, was ist ein Vorgehensmodell, was ist eine Methode, was ist eine Praktik und vieles mehr, gibt es mehrere Dutzend oder sogar deutlich über 100 unterschiedliche Modelle unterschiedlichster Größe – nicht eingerechnet sind die unternehmensspezifischen Vorgehensmodelle, welche etwa in großen Unternehmen für alle durchgeführten Projekte bindend sind. Alle Vorgehensmodelle differieren in ihren Eigen- schaften, jedoch basieren sie in der Regel auf einigen wenigen Grundkonzepten und entspre- chen einem der im Folgenden vorgestellten grundlegenden Vorgehensmodelle (siehe auch Chroust ). Ausgehend von diesen Grundformen werden Vorgehensmodelle üblicherweise für kon- krete Projekte angepasst [20, 31]. Die Auswahl und Anpassung eines Vorgehensmodells 86 3 Vorgehensmodelle in der Softwareentwicklung für ein konkretes Projekt ist eine nicht ganz einfache Aufgabe1. Oft erfolgt diese Aus- wahl und Anpassung auch nicht statisch, sondern dynamisch und abhängig vom Projekt- verlauf. Unterschiedliche Studien [30, 34, 39, 67] belegen die Vielfalt und zeigen deut- lich einen Trend zu sogenannten hybriden Ansätzen [37, 38], in denen traditionelle Vorge- hensweisen zunehmend mit agilen Methoden angereichert werden. Unabhängig von Unter- nehmensgröße, Industriesektor und Projektgegenstand entwickeln Firmen – in der Regel erfahrungs- und situationsbasiert – Vorgehensmodelle, in denen traditionelle Vorgehens- weisen und Elemente der agilen Softwareentwicklung miteinander kombiniert werden. Darüber hinaus scheinen auch regionale Besonderheiten eine Rolle zu spielen, zum Bei- spiel durch die Vorgabe eines Standardvorgehensmodells auf der nationalen Ebene [39, 64]. Beispielhaft sei hier die in Deutschland übliche Kombination des V-Modell XT mit Scrum genannt. Das V-Modell XT (siehe Abschn. 3.3) liefert hierbei den organisatorischen Rahmen und beschreibt Projekte sowie deren Schnittstellen zur umgebenden Organisa- tion auf einer grundsätzlichen Ebene (zum Beispiel Anforderungsanalyse, Vertragsgestal- tung, Auftraggeber/Auftragnehmer-Kommunikation oder Abnahme), während Scrum (siehe Abschn. 3.4), oftmals in Verbindung mit spezifischen agilen Praktiken, die Grundlage für das konkrete Vorgehen in der Softwareentwicklung legt. Hinweis Vorgehensmodelle in ihren unterschiedlichen Ausprägungen werden aus der Perspek- tive der Projektorganisation und des Managements umfassend in [16, Kap. 4] disku- tiert. Als Ankerpunkt für die Diskussion aus der Perspektive der Softwareentwicklung konzentrieren wir uns auf die „Standardkonfiguration“ gemäß und führen kurz in das V-Modell XT und Scrum ein. Diese beiden Ansätze bilden gleichzeitig die prozessbezogene Grundlage für die weiteren Kapitel dieses Buchs. 3.2.1 Phasenorientierte Modelle und sequenzielles Vorgehen Das Phasenmodell wird auch als der „klassische“ Ansatz zur Software- und Systement- wicklung angesehen. Der bekannteste Vertreter dieser Klasse von Vorgehensmodellen ist das „Wasserfallmodell“ (Abb. 3.2), welches einer streng sequenziellen Vorgehensweise mit klar abgegrenzten Phasen entspricht. Jede Phase wird als ein umfassender Arbeitsschritt verstanden und mit einem definier- ten Ergebnis abgeschlossen, welches in einem Meilenstein geprüft und im Anschluss als Eingabe an die folgende Phase übergeben wird. Ergebnisse fließen quasi aus einer Phase 1 In bestimmten Unternehmen und Anwendungsgebieten sind Vorgehensmodelle verbindlich vorge- schrieben und gar nicht oder nur in begrenztem Umfang anpassbar. Auch ist es möglich, dass ein bestimmtes Rahmenvorgehen bereits durch einen Auftraggeber vertraglich fixiert wurde. Auch in so einer Situation sind Abweichungen von definierten Vorgehen nur eingeschränkt möglich. 3.2 Grundlegende Vorgehensmodelle und Prozessbeschreibungen 87 System Requirements Software Requirements Analysis Program Design Coding System Feasibility Testing & Integration Validation SW Plans & Requirements Operations Validation Product Design Verification Detail Design Verification Code Unit Test Integration Verification Implementation System Test Operation & Maintenance Revalidation Abb. 3.2 Wasserfallmodell nach Royce (oben) und Boehm (unten) nach in die folgende Phase, weshalb Boehm dieses Vorgehen als Wasserfall bezeichnet hat. Bezüglich des Wasserfallmodells sind zunächst noch zwei häufige Irrtümer auszuräumen: 1. Royce ist nicht der Erfinder des Wasserfallmodells. Vielmehr kritisiert er diese Vorgehensweise der Systementwicklung selbst: „I believe in this concept, but the imple- mentation described above is risky and invites failure. […] In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.“ 2. Landläufig wird das Wasserfallmodell in Reinkultur als strikt sequenzielles Vorgehen angesehen. Typischerweise sind zwischen den einzelnen Phasen jedoch Rückkopplungen vorgesehen – jedoch nur zwischen unmittelbar benachbarten Phasen. Philosophie Die grundlegende Philosophie des Wasserfallmodells ist die Organisation eines Projekts durch Aufteilung des Entwicklungsprozesses in Phasen anhand der Schwer- punkte der Entwicklungsaufgaben. Die folgenden Phasen werden im klassischen Wasser- fallmodell verwendet: Analyse und Anforderungserhebung Architekturentwurf Implementierung Verifikation und Integration Betrieb und Wartung 88 3 Vorgehensmodelle in der Softwareentwicklung Jede dieser Phasen bündelt dabei eine Reihe von Aktivitäten, welche vollständig und in der richtigen Reihenfolge durchzuführen sind. Am Ende liegen jeweils fertiggestellte Ergeb- nisse vor, etwa eine Architekturspezifikation. Da jedes Ergebnis wiederum Eingabe für Folgeaktivitäten ist, müssen die entsprechenden erzeugenden Aktivitäten stets vollständig durchlaufen werden. Dies reduziert die Möglichkeiten, Aktivitäten parallel auszuführen. Auswirkungen auf die Entwicklung Die streng sequenzielle Vorgehensweise hat prä- gende Auswirkungen auf die gesamte Systementwicklung. So soll dabei ein Architektur- entwurf erst erfolgen, wenn die Anforderungen an das System vollständig beschrieben sind. Dies allein stellt in Projekten bereits eine große Herausforderung dar und berücksichtigt dabei nicht Lerneffekte im Projekt und Änderungen an Anforderungen aus den unterschied- lichsten Gründen (siehe Kap. 5). Ähnliches gilt für die Implementierung, welche erst begin- nen darf, wenn das System vollständig entworfen wurde. Fällt bei der Implementierung auf, dass die Architektur nicht trägt, ist mindestens der Architekturentwurf zu wiederho- len, im schlimmsten Fall sogar die Anforderungsanalyse, sollte sich herausstellen, dass eine Architekturentscheidung auf Grundlage einer falschen Anforderung getroffen wurde. Somit eignet sich ein phasenorientiertes Vorgehensmodell in der Regel nur für risikoarme Projekte, in denen die Anforderungen und die gewünschte Lösung von Anfang an vergleichs- weise klar sind und bei denen mit nur wenigen Änderungen während des Projektverlaufs zu rechnen ist. Das V-Modell… Auch das V-Modell XT (siehe Abschn. 3.3) kann im Kern den phasenorientierten Modellen zugeordnet werden. Im (klassischen) V-Modell sind die Phasen weiterhin vorhanden, jedoch werden sie nach Entwurfs- bzw. Dekompositionsaktivitäten und Integrationsaktivitäten getrennt visualisiert. Hierbei werden die Ebenen der Dekom- position und der Integration einander gegenübergestellt, womit die erforderlichen qualitätssichernden Maßnahmen besonders hervorgehoben werden – es entsteht das berühmte und namensgebende „V“. Das V-Modell bildet heute die Grundlage für viele Vorgehensmodelle und auch für Normen und Standards, etwa in der Entwicklung von Software für das Automobil (ISO/IEC 26262:2018; ). Bewertung Vorteilhaft an phasenorientierten Vorgehensweisen ist die einfache Struktur, die es gestattet, Projekte übersichtlich zu organisieren und zu kontrollieren. Dieser Vorteil kann aber in das Gegenteil umschlagen, wenn Flexibilität im Projekt erforderlich ist. Risikoreich bei Einsatz eines phasenorientierten Vorgehensmodells sind Änderungen zur Projektlaufzeit. Insbesondere bei Änderungen, welche in Aufgaben aus den frühen Phasen auftreten, sind die Auswirkungen auf späte Phasen weitreichend. Auch die Rückkopplung 3.2 Grundlegende Vorgehensmodelle und Prozessbeschreibungen 89 von Problemen aus den späten Phasen zurück in die frühen Phasen ist schwierig. Während die Überwachung des Projektfortschritts aus Sicht der Projektleitung formal einfach ist, ist die Kontrolle der Entwicklungsrisiken und die Reaktion auf eingetretene Risiken schwierig. Darüber hinaus können einzelne kleine Probleme das gesamte Projekt verzögern. Folgende Nachteile des Wasserfallmodells sind besonders zu berücksichtigen: Planungs- und Entwicklungsfehler werden oft zu spät bemerkt. Risiken werden (zu) spät erkannt. Umplanungen sind kostspielig und schwer zu bewerkstelligen. Rückkopplungen, insbesondere aus der Entwicklung, finden (zu) spät statt. Ein Teil dieser Risiken kann durch eine umfangreiche und kontinuierliche Qualitätssiche- rung abgefedert werden. Phasenorientierte Vorgehensmodelle sind häufig die Grundlage für hybride Vorgehensmodelle [37, 63]. Sie stellen eine einfache Schnittstelle zwischen Projek- ten und den durchführenden Organisationen dar, die auf der einen Seite dem Management handhabbare Instrumente zum Projektmanagement bereitstellt und bieten den Projek- ten andererseits einen stabilen Rahmen, in den situationsangemessen spezifische Methoden und Praktiken eingefügt werden können. Anmerkung Grundsätzlich gilt: Projekte laufen selten genau so ab wie geplant. Bei- spielsweise ändern sich Anforderungen typischerweise während der Projektdurchführung. Deshalb sollten bei der Nutzung phasenorientierter Vorgehensmodelle zumindest zeitliche Puffer eingeplant werden. 3.2.2 Iteratives und inkrementelles Vorgehen Beim Aufbau von nicht Wasserfall-artigen Vorgehensmodellen gibt es zwei grundlegende Konzepte, die üblicherweise miteinander kombiniert werden: das inkrementelle und das iterative Vorgehen. Beim iterativen Vorgehen gibt es eine Reihe von Standardaktivitäten, welche in jeder Iteration wiederholt durchlaufen werden, etwa Code-Build-Test. Beim inkrementellen Vor- gehen wird zunächst ein eingeschränkter Systemkern mit begrenztem Funktionsumfang realisiert. Dieser Kern wird im weiteren Projektverlauf stufenweise ausgebaut und vervoll- ständigt. Dadurch werden Entwicklungsrisiken begrenzt, da schnell lauffähige Systemstände entwickelt und überprüft werden können. Insbesondere hat diese Vorgehensweise die fol- genden Anforderungen und Auswirkungen auf die Software- und Systementwicklung: Architekturen müssen hinreichend modular ausgelegt werden, damit eine schrittweise Realisierung und gegebenenfalls eine Umorganisation (Refactoring, siehe Kap. 13.2.3.4) 90 3 Vorgehensmodelle in der Softwareentwicklung möglich sind. Dies stellt hohe Anforderungen an den Entwurf von Komponenten und Schnittstellen. Die realisierten Systemteile (Module, Komponenten und ganze Teilsysteme) müssen kon- tinuierlich integrierbar und bis zu einem gewissen Grad ablauffähig sein. Gegebenenfalls sind Stellvertreter- bzw. Dummy-Objekte bereitzustellen, damit die Ablauffähigkeit in den frühen Phasen der Entwicklung hergestellt werden kann (siehe Kap. 12.3.2). Die einzelnen Systemteile sind jeweils mit automatisierbaren Tests zu flankieren, welche im Build-Prozess ausgeführt werden. Durch die wiederholte Integration des wachsenden Systems in den einzelnen Iterationen werden diese Tests ebenfalls wiederholt ausge- führt, sodass Qualitätsprobleme frühzeitig identifiziert werden können. Dies erfordert eine passende Entwicklungsumgebung mit entsprechender Werkzeugausstattung. In extremen Ansätzen, insbesondere im Bereich des Continuous Integration und des Conti- nuous Deployment (siehe Kap. 12.4), werden Inkremente täglich oder sogar mehrmals am Tag erstellt [28, 33]. Hinweis Es ist nicht zwingend, dass iteratives und inkrementelles Vorgehen miteinander kombi- niert werden. Beispiele für ein nicht iteratives aber inkrementelles Vorgehen findet sich bei einer Feature-basierten Entwicklung, in der für jedes einzelne Feature individuelle Entwicklungsansätze und Vorgehen verwendet werden. Auch ein Vorgehen, in dem zunächst ein allgemeiner Architekturrahmen angefertigt wird, in den dann schrittweise Komponenten hineinrealisiert werden ist ein inkrementelles – jedoch nicht zwingend iteratives Vorgehen. Das Spiralmodell Das Spiralmodell von Boehm ist einer der bekanntesten frühen Vertreter des iterativ/inkrementellen Vorgehens. Es verfolgt das Ziel Projektrisiken durch die Erstellung von evolvierenden Prototypen (siehe Abschn. 3.2.3) zu minimieren. Abb. 3.3 illustriert das Grundkonzept des Spiralmodells in seinen vier Schritten: Schritt 1 (Analyse) Im ersten Schritt werden die Rahmenbedingungen, Ziele, Anfor- derungen und Lösungsalternativen beschrieben und zwecks Eva- luation zur Umsetzung freigegeben. Schritt 2 (Evaluierung) Die Evaluierung der verschiedenen Lösungsalternativen wird im zweiten Schritt durchgeführt. Die Evaluierung dient primär der Identifikation von Risiken und zur Erarbeitung von Strategien zu deren Minderung bzw. Vermeidung. 3.2 Grundlegende Vorgehensmodelle und Prozessbeschreibungen 91 Schritt 3 (Realisierung) Abhängig von den identifizierten Risiken wird im dritten Schritt ein adäquates Realisierungsvorgehen ausgewählt und die Reali- sierung wird durchgeführt. Schritt 4 (Planung) Im vierten Schritt erfolgt ein Review der vorangegangenen Schritte und die Planung der nächsten Iteration. Diese vier Schritte werden durch die Quadranten in Abb. 3.3 visualisiert. Durch die iterative Vorgehensweise wird pro Iteration eine Reihe von Aktivitäten durchgeführt. Da Iterationen aufeinander aufbauen (inkrementelle Entwicklung), „wachsen“ die entwickelten Prototypen über die Zeit. Die Ergebnisse der Zyklen, etwa Anforderungen oder Architekturen, werden in jeder Iteration verfeinert. Der Projektfortschritt wird durch eine Linie durch die Quadranten markiert, welche das typische und namensgebende Spiralmuster erzeugt. Durch die Konzen- tration auf die Entwicklung von Prototypen und die kontinuierliche Evaluation unterstützt das Spiralmodell Lernkurven im Projekt. Ferner dienen die kontinuierlichen Evaluierungen der Minimierung des Risikos von Fehlentwicklungen und somit auch der Begrenzung von Projektkosten. Hervorzuheben ist auch, dass das Spiralmodell das konkrete Vorgehen zur Realisierung von Prototypen nicht vorgibt. Im dritten Schritt kann daher ein beliebiges, dem zu lösen- den Problem und dem Restrisiko angemessenes Vorgehen ausgewählt werden. Dies hat Kosten Schritt 1: Schritt 2: Analyse Evaluierung Alternativen planen und beschreiben Evaluierung, Risiken f ur ntw e f in ur Fe w Evaluierung, Prototyp e nt Risiken umsetzen r ob e... G el Prototyp Zustimmung durch Zi umsetzen...... Pl an... Fortschritt en Pl Umsetzung Feintentwurf an en Codierung Integration Test Schritt 4: Implemen- Schritt 3: Planung tierung Realisierung Abb. 3.3 Konzept des Spiralmodells nach 92 3 Vorgehensmodelle in der Softwareentwicklung zur Folge, dass sich die Vorgehensweisen zwischen den einzelnen Iterationen unterschei- den können, etwa eine agile und prototyporientierte Vorgehensweise zur Exploration von Lösungsoptionen oder eine eher Wasserfall-artige Vorgehensweise zur Stabilisierung von Teilsystemen. Die Option, unterschiedliche Entwicklungsstränge zu realisieren wird insbesondere durch die Planungsphase im vierten Schritt ermöglicht. Hier kann beispielsweise in einem Strang ein klares und ausreichend evaluiertes Teilsystem „fertig implementiert“ werden, während in einem anderen Strang noch unklare Anforderungen durch Prototypen realisiert und evaluiert werden können. Für jeden Entwicklungsstrang sieht das Spiralmodell hierbei eine eigene Spirale vor. Hinweis Es ist zu beachten, in welchem Kontext und Verständnis man das Spiralmodell als Vor- gehensmodell für ein Projekt verwendet. Das Spiralmodell kann einerseits als Organi- sationsmodell für Projekte aus der Sicht der Projektorganisation und des Managements eingesetzt werden. So nutzt beispielsweise Scrum das Spiralmodell als Organi- sationsschablone. Das Spiralmodell kann aber auch das technische Vorgehen in den einzelnen Schritten unterstützen, etwa durch die genaue Festlegung der Methoden und Praktiken, welche in den einzelnen Aufgaben einer Iteration angewendet werden. 3.2.3 Prototyping Bei der Entwicklung neuartiger Anwendungen in Domänen und für Aufgaben, für die noch wenige Erfahrungen vorliegen, oder die Anforderungen zu Beginn noch nicht abschlie- ßend vorliegen, können Prototypen schon in der Anforderungsanalyse (siehe beispielsweise Kap. 7.3.1 und 7.3.2) ein hilfreiches Werkzeug sein. Die systematische Erstellung eines Prototyps im Rahmen der Problemerfassung, der Fixierung der Anforderungen und der schrittweisen Annäherung an das Zielsystem hat eine Reihe von Vorteilen: Die Aufgabenstellung wird insbesondere für den Kunden greifbarer Kritische, risikoreiche Gesichtspunkte werden eher identifiziert und geklärt Prototypen liefern eine Grundlage für die weiteren Entwicklungsschritte Beim Einsatz von Prototypen ist darauf zu achten, dass von vornherein festgelegt wird, ob der Prototyp als reines Explorations- oder Demonstrationsobjekt dient, oder später in einem inkrementellen Entwicklungsansatz zur schrittweisen Weiterentwicklung verwendet werden soll. 3.2 Grundlegende Vorgehensmodelle und Prozessbeschreibungen 93 Achtung Prototypen erwecken beim Auftraggeber und beim Management leicht den Ein- druck, dass die Aufgabenstellung bereits weitgehend gelöst wäre, und führen deshalb zu unangemessenem Druck auf Fertigstellung und Freigabe. Daher ist es wichtig, zwischen experimentellen und evolutionären Prototypen zu unterscheiden. Experimentelle Prototy- pen dienen der Demonstration und der Evaluation von Lösungsoptionen. Üblicherweise werden die Prototypen nach durchgeführter Evaluation verworfen und nicht weiterentwi- ckelt. Evolutionäre Prototypen sind hingegen feste Bestandteile des Entwicklungsprozesses. Diese Prototypen wachsen über die Zeit und werden im Sinne eines iterativen und inkremen- tellen Vorgehens schlussendlich zum finalen System ausgebaut. Oft werden hierzu Techniken des Refactorings eingesetzt. Prototypen lassen sich zur Simulation einsetzen, um gewisse Erkenntnisse (Auslastung der Komponenten, Antwortzeiten, Engpässe) über das angestrebte System zu gewinnen. Beson- ders hilfreich sind Prototypen zur Darstellung der Anforderungen im Hinblick auf die Benut- zungsschnittstelle. Dies betrifft sowohl Fragen der Ästhetik sowie der Ergonomie. Beson- ders hilfreich können Prototypen auch in der Entscheidungsfindung sein. Oftmals stehen die Anforderungen an ein System nicht von Anfang an fest, sodass es erforderlich ist, den Lösungsraum entsprechend einzugrenzen und unter möglicherweise mehreren Lösungs- optionen diejenige zu wählen, die das betrachtete Problem am besten löst. Dazu können unterschiedliche Prototypen erstellt und verglichen werden (experimentelles Prototyping; Chroust ). Es entstehen Vorteile für alle Beteiligten, da Entwickler die Anforderun- gen verstehen und umsetzen müssen und Kunden schließlich die Umsetzungen bewerten müssen. Missverständnisse, fehlende oder gar falsche Anforderungen können so frühzei- tig aufgedeckt werden. Somit leisten Prototypen einen Beitrag zur Risikominimierung von Projekten, zum Beispiel durch frühzeitige Einbindung der Anwender und damit auch der Schaffung von Akzeptanz eines Softwaresystems. Abb. 3.4 zeigt die beiden Muster, nach denen Prototypen erstellt werden können. Ein hori- zontaler Prototyp realisiert einen ausgewählten Ausschnitt eines Systems meist aus Sicht des Nutzers. Üblich sind sogenannte GUI-Prototypen entweder als ausführbares Programm oder als „Mock-Up“, welche schnell einen Entwurf der Benutzungsschnittstelle realisieren und somit Anwendern frühzeitig ein Gefühl für das System vermitteln. Im Rahmen der Anforderungsanalyse können damit beispielsweise Anforderungen hinsichtlich der Benut- zungsschnittstelle überprüft, angepasst oder ausgebaut werden. Die oft auch als „Durchstich“ bezeichneten vertikalen Prototypen dienen dazu, ausgewählte Eigenschaften oder Teile eines Systems zu prüfen. Dazu wird der entsprechende Teil des Systems vollständig über alle Schichten der Architektur (Benutzungsschnittstelle bis zur Datenhaltung) realisiert und dem Anwender zur Verfügung gestellt. Diese Art Prototyp dient im Wesentlichen dazu, die prin- zipielle Realisierbarkeit einer Anforderung oder einer Lösungsidee zu demonstrieren und einen Lösungsansatz zu erproben. Durch den Einsatz moderner Entwicklungsumgebungen, können Prototypen heutzutage schnell erstellt werden, etwa für Benutzungsschnittstellen oder Datenmodelle. Dies wird oft auch als Rapid Prototyping bezeichnet. 94 3 Vorgehensmodelle in der Softwareentwicklung Vertikaler Prototyp Horizontaler Prototyp Anwendungslogik Sonst. Netzwerk Daten Nachbarsysteme Systemsoftware (Betriebssystem etc.) Abb. 3.4 Horizontale und vertikale Prototypen nach Balzer Grundsätzlich eignen sich Prototypen für verschiedene Zwecke, anhand derer sie sich klassifizieren lassen. Die gebräuchlichen Arten von Prototypen sind: Demonstratoren finden hauptsächlich in der Projektakquise und in den frühen Phasen eines Projekts Anwendung. Sie zeigen grob die Richtung einer potenzi- ellen Entwicklung auf und demonstrieren die Umsetzbarkeit und auch Umsetzungsalternativen von Anforderungen. Üblicherweise sind solche Prototypen noch „weit“ von der finalen Realisierung entfernt. Labormuster dienen der technischen Untersuchung bestimmter Fragestellungen, etwa der Tragfähigkeit einer gewählten Architektur. Pilotsysteme sind umfangreiche Prototypen, die bereits große Teile des finalen Sys- tems beinhalten. Anders als bei Labormustern sind bei der Evaluierung von Pilotsystemen bereits die Anwender mit eingebunden. Üblicherweise sind Pilotsysteme Prototypen von hohem Reifegrades, die das Bindeglied zwischen „Wegwerf-Prototypen“ und dem finalen System darstellen. 3.2.4 Agile Vorgehensweisen Unter agilen Methoden in der Softwareentwicklung versteht man eine starke Konzentration auf die Entwicklung von Code. Sie stellen schwergewichtigen, plan-getriebenen Vorgehens- weisen mit hohem Regelungs- und Organisationsaufwand (kritischer Vorwurf: „Software- bürokratie“) einen leichtgewichtigen Ansatz mit höherer Flexibilität gegenüberstellen. In den letzten Jahrzehnten haben sich viele agile Vorgehensweisen und darauf zugeschnittene Methoden entwickelt. Die bekanntesten sind das eXtreme Programming (XP) nach Beck und Scrum nach Schwaber [58, 59]. Ziel der agilen Softwareentwicklung ist es, die Software- und Systementwicklung flexibler und schlanker zu machen. Je nach Kontext kann das Teil- bereiche der Entwicklung oder den gesamten Entwicklungsprozess betreffen. Beherrschend 3.2 Grundlegende Vorgehensmodelle und Prozessbeschreibungen 95 ist der Wunsch, sich vollständig auf Projektziele und die Dynamik im Projektteam sowie den Code zu konzentrieren Zentrale Bestandteile der agilen Methoden sind frühes Einsteigen in die Codierung, starke Einbeziehung der Nutzer, beständiges Testen und die Weiterentwicklung der Architektur. Wir sprechen von Code-zentriertem Vorgehen. Maßgebliches Ziel dabei ist eine schnelle Rückkopplung auf Basis ausführbaren Codes. Die Werte agiler Vorgehensweisen wur- den im „Agilen Manifest2“ niedergeschrieben. Werte beschreiben die grundlegende Philo- sophie der agilen Entwicklung, und zwar: Individuals and interactions over processes and tools (Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge) Zwar sind wohldefinierte Entwicklungsprozesse und Entwicklungswerkzeuge wichtig, wesentlicher sind jedoch die Qualifikation und die Motivation der Teammitglieder und eine effiziente Kommunikation zwischen ihnen. Working software over comprehensive documentation (Funktionierende Programme sind wichtiger als ausführliche Dokumentation) Gut geschriebene und ausführliche Doku- mentation kann zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die funktionsfähige Software. Customer collaboration over contract negotiation (Die stetige Abstimmung mit dem Kunden ist wichtiger als die detaillierte Leistungsbeschreibung in Verträgen) Statt sich an ursprünglich formulierten und möglicherweise überholten Leistungsbeschreibungen in Verträgen festzuhalten, steht vielmehr die fortwährende konstruktive und vertrauensvolle Abstimmung mit dem Kunden im Mittelpunkt. Responding to change over following a plan (Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans) Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können. Bei den Festlegungen ist Folgendes zu beachten: Die Aussage A over B bedeutet aus- drücklich nicht, dass auf B verzichtet werden kann, sondern das A einen höheren Stellenwert als B haben sollte. So ist es ein Missverstehen agiler Ansätze, wenn mit Verweis auf Agi- lität argumentiert wird, dass in einem Projekt keine Dokumentation erstellt wurde. Ergänzt werden diese agilen Werte durch sogenannte Prinzipien, wie Zweckmäßigkeit, Kundennähe oder dass der Code „allen“ (im Projekt) gehört. In jedem Fall lässt Agilität viel Spielraum. Genau betrachtet definieren agile Vorgehensweisen Methoden und Praktiken, die als Baukasten in Projekten kombiniert und angewendet werden können [63, 67]. Tab. 3.1 listet einige prominente Vertreter solcher Praktiken und Methoden auf. Solche Elemente agi- len Vorgehens kann man durchaus auch in großen Projekten und insbesondere in den als schwergewichtig und plangetrieben bezeichneten Vorgehensmodellen mit einbringen. So 2 Manifesto for Agile Software Development: https://agilemanifesto.org 96 3 Vorgehensmodelle in der Softwareentwicklung ist das Test-driven Development (siehe Kap. 12.2.6) zum Beispiel eine breit akzeptierte Methode, die beispielsweise auch im Rational Unified Process oder im V-Modell XT Anwendung finden kann. Schein und Sein… Der Begriff des agilen Vorgehens, der in der Softwareentwicklung stark auf Code- zentriertes Vorgehen und eine Scrum-artige Projektorganisation abhebt, hat sich ver- selbstständigt. Es wird von der agilen Organisation und den agilen Unternehmen gesprochen. Gemeint ist eine hohe Geschwindigkeit im Vorgehen, bei Entscheidun- gen und hohe Flexibilität beim Ändern von Festlegungen und Vorgehensweisen. Die Tab. 3.1 zeigt nur einige der wichtigsten Methoden und Praktiken, insbesondere solche, auf die wir im Folgenden noch im Detail eingehen. Viele weitere Methoden und Praktiken existieren und werden als konkrete Arbeitstechniken in Projekten eingesetzt und in verschiedenster Form miteinander kombiniert. Eine sehr verbreitete Kombination ist der Ansatz „Scrumban“, den wir in Abschn. 3.4.6 behandeln. Agiles Vorgehen betont Kompetenz und Verantwortung des Teams Agile Methoden betonen die unmittelbare Arbeit am Code, die Rolle des Teams und der Verantwortung der im Team tätigen Personen. Insbesondere das verbreitete Scrum (siehe Abschn. 3.4) schafft eine Projektorganisation, die extrem auf das Team fokussiert ist. Vorausgesetzt wird dabei, dass die Teammitglieder eine hohe Kompetenz, insbesondere im Bereich der Programmierung aber auch in der Anwendungsdomäne haben, dass der Product Owner (siehe Abschn. 3.5) ein gutes Verständnis für die Anforderungen des Systems hat, dass die Kunden in den Pro- zess eingebunden werden und dass im Projektteam hohes Verantwortungsgefühl und hohe Motivation vorliegen. Dies funktioniert zwangsläufig besonders gut bei Entwicklungsauf- gaben, die von kleineren Teams bewältigt werden können (etwa einer Größe von zehn oder weniger Teammitgliedern) und die in einem überschaubaren Zeitraum umgesetzt werden können. Stets muss ein hohes Vertrauen in das Team vorausgesetzt werden können, da man dem Team große Freiheiten lässt, wenig Vorgaben macht, auch das Team wenig zusätzlich kontrolliert und dabei darauf vertraut, dass das Team in der Lage ist, ein gutes Ergebnis zu produzieren. Dieses Vorgehen stößt an Grenzen, wenn die Projekte groß werden, wenn gerade im Rahmen von Verträgen Anforderungen zu Beginn sehr genau abgestimmt werden müssen oder wenn durch Regulierung etwa durch Vorgaben im Falle funktionaler Sicherheit in hohem Maß Dokumentation zwingend erforderlich ist. Dann müssen agile Ansätze wie Scrum erweitert werden, um den spezifischen Anforderungen eines Projektes gerecht zu werden. 3.2 Grundlegende Vorgehensmodelle und Prozessbeschreibungen 97 Tab. 3.1 Ausgewählte agile Methoden und Praktiken Methode/Praktik Erläuterung Refactoring Kontinuierliche Restrukturierung von Code, ohne Änderung der Funk- tion. Umfasst unter anderem das Entfernen von Coderedundanzen (Klo- nen), Umbenennen von Bezeichnern und weitere Maßnahmen zur Ver- besserung der Lesbarkeit und Änderbarkeit [25, 48]. Weiterführende Informationen sind in Kap. 13.2.3.4 zu finden Pair Programming Zwei Entwickler arbeiten gemeinsam an einem Programm: Ein Ent- wickler codiert, der andere führt ein kontinuierliches Review durch; die Rollen wechseln mehrmals pro Tag. Weitere Information sind in Kap. 11.3.4 zu finden DevOps DevOps ist ein Entwicklungsansatz, der durch die Verschränkung von Entwicklung (Development) und Betrieb (Operations) eine Beschleu- nigung und Qualitätssteigerung in Projekten zum Ziel hat. Ein Ziel ist es insbesondere eine schnelle und reibungslose Auslieferung und den Betrieb von Software zu realisieren, weshalb Experten aus dem Betrieb in das Entwicklungsprojekt mit eingebunden werden und umgekehrt. Für DevOps-Ansätze werden verschiedene Methoden und Praktiken kombiniert. Weiterführende Informationen sind in Kap. 12.4.2 zu fin- den Test-driven Development Der Codierungsprozess orientiert sich an zuvor definierten Testfällen. (TDD) Code wird nur in einem Umfang erstellt, der genügt, die Testfälle erfolgreich zu durchlaufen. Weiterführende Informationen sind in Kap. 12.2.6 zu finden Behavior-driven Während der Anforderungsanalyse werden die Anforderungen, Ziele Development usw. in einer spezifischen Textform festgehalten, welche eine spä- (BDD) tere Ausführung manueller oder automatisierter Tests unterstützt (siehe Kap. 7.4.1). Im Fokus von BDD steht die enge Zusammenarbeit von Analytikern und Qualitätssicherern mit dem Entwicklungsteam. Durch ein Szenario-basiertes Textformat für die Beschreibung der Anforde- rungen soll die Gebrauchssprache in den Anwendungsdomänen auf Softwarekonzepte erleichtert werden. BDD kann einfach mit automa- tisierten Tests verknüpft werden (siehe Kap. 12.2.5) Collective Code Collective Code Ownership sagt aus, dass der Code dem gesamten Team Ownership gehört. Dies hat insbesondere zur Konsequenz, dass jeder Entwickler in der Lage sein muss, Probleme im Code zu beheben, da auch alle Entwickler im Team Verantwortung für die Qualität des Systems tragen. Ein ausgereiftes Versionskontrollsystem ist als Werkzeugunterstützung unverzichtbar (siehe Kap. 11.5) 98 3 Vorgehensmodelle in der Softwareentwicklung 3.3 Das V-Modell XT Das V-Modell XT ist eine Weiterentwicklung des V-Modell 97. Durch weitgehende Anpassungsmechanismen [40, 41] zielt das V-Modell XT auf die Erhöhung der Flexibilität bei gleichzeitiger Beibehaltung klarer Strukturen für die Aufbau- und Ablauforganisation ab. Das V-Modell XT ist ein modulares Vorgehensmodell, in dem Prozessinhalte und Abläufe in kombinierbaren Bausteinen organisiert sind. Zentral sind die Ergebnisse (Artefakte), die in einem Projekt erstellt werden – die sogenannten V-Modell-Produkte. Diese Artefaktori- entierung (Produktorientierung) sorgt dafür, dass Ergebnisse im Zentrum stehen und die spezifischen, individuellen und oft kleinteiligen Arbeitsprozesse in den Hintergrund tre- ten. Für alle Projektaktivitäten sind prüfbare Artefakte als Ergebnisse definiert, zu denen die Anforderungen an die erwartete Qualität formuliert werden können. Infolge gibt das V- Modell XT eine Zielergebnisstruktur vor, etwa ein Softwaresystem, das nach verschiedenen, projektspezifischen Vorgehensweisen entwickelt werden kann. 3.3.1 Rollen im V-Modell XT Das V-Modell XT beschreibt in der hier verwendeten Version 2.2 des Referenzmodells nicht weniger als 38 Rollen. Diese sind klassifiziert nach: Organisationsrollen Eine Organisationsrolle besteht in einer Organisation unabhängig von einem konkreten Projekt. Organisationsrollen nehmen üblicherweise eine projektübergreifende, institutionalisierte Verantwortung wahr, zum Beispiel ein Datenschutzbeauftragter, sind jedoch in Projekten an verschiedenen Entscheidungsprozessen zu beteiligten. Das V-Modell XT beschreibt insgesamt 6 Organisationsrollen. Projektrollen Eine Projektrolle arbeitet inhaltlich am Projekt mit und existiert nur während des Projekts, zum Beispiel Projektleiter, Systemarchitekt, SW-Entwickler oder Prüfer. Projektrollen übernehmen Verantwor- tung für die Erstellung von V-Modell-Produkte oder wirken bei deren Erstellung mit. Insgesamt beschreibt das V-Modell XT 32 unter- schiedliche Projektrollen. Damit verfügt das V-Modell XT über ein sehr detailliertes Rollenmodell, in welchem die unterschiedlichen Aufgaben und Kompetenzprofile, die für ein breites Spektrum an Projek- ten erforderlich sind, beschrieben werden. Im Rollenmodell des V-Modell XT wird darüber hinaus detailliert festgelegt, welche Rolle für welches V-Modell-Produkt verantwortlich ist. Durch die klare Festlegung, dass für ein V-Modell-Produkt immer nur genau eine Rolle verantwortlich sein kann, wird poten- ziellen Interessens- und Zuständigkeitskonflikten vorgebeugt. Dies ist insbesondere dann 3.3 Das V-Modell XT 99 hilfreich, wenn Rollen in „Personalunion“ besetzt werden, also wenn ein Projektmitarbeiter mehrere Rollen innehat (zum Beispiel SW-Entwickler und Prüfer). 3.3.2 V-Modell XT Produkte für die Systementwicklung Das V-Modell XT adressiert die Entwicklung komplexer IT-Systeme. Damit nimmt die Sys- tementwicklung einen zentralen Punkt ein. Daher enthält das V-Modell XT Beschreibungen und Definitionen für eine Vielzahl an Artefakten, die für die Systementwicklung relevant sind. Man beachte, dass das V-Modell XT den Anspruch erhebt als Standard des Bundes eine möglichst große Anzahl von Projektsituationen abzudecken. Dementsprechend ist das Artefaktmodell des V-Modell XT umfangreich, jedoch sind nicht immer alle Teile für alle Projekte erforderlich. Abb. 3.5 stellt die wesentlichen V-Modell-Produkte für die Sys- tementwicklung dar. Die V-Modell-Produkte aus dem Bereich Systementwicklung decken die folgenden Aspekte ab: Beschreibung eines Gesamtsystems bestehend aus Hard- und Softwareanteilen, inklusive der Integrationskonzepte (Implementierungs-, Integrations- und Prüfkonzept; IIPK) für die Einzelteile des Systems Beschreibung von Hardware- und Softwareeinheiten, welche in einem Projekt entwickelt werden, inklusive der Angabe von Verfeinerungsschritten (Dekomposition) Beschreibung von sogenannten Externen Einheiten, also solchen Einheiten, welche von externen Zulieferern in das Projekt geliefert und integriert werden Für jedes in Abb. 3.5 gezeigte V-Modell-Produkt gibt es entsprechende Artefakte für die Qualitätssicherung, etwa für ein Systemelement, zu dem es unterschiedliche Prüfartefakte gibt: Prüfspezifikation Systemelement, Prüfprotokoll Systemelement und Prüfprozedur Sys- temelement. Durch die Integrationskonzepte werden dann die Verbindungen zwischen den Entwicklungs- und den Prüfartefakten hergestellt. Hinweis Durch den Umfang des V-Modell XT ist der Einstieg oft eine Herausforderung. Hier hat es sich bewährt, den Einstieg in die Prozessdokumentation über den alphabeti- schen Produktindex in der V-Modell-Referenz Produkte zu suchen. Durch die starke Fokussierung auf Produkte sind alle wesentlichen Inhalte, Strukturen und Abhängig- keiten von hier aus durch eine entsprechende Verlinkung der Prozesselemente leicht zu erreichen. 100 3 Vorgehensmodelle in der Softwareentwicklung System Segment System- System- System- architektur spezifikation spezifikation Datenbank- Altsystem- entwurf analyse Software-Einheit Migrations- IIPK konzept System Software-Komponente Software- Software- architektur spezifikation Anwenderaufgabenanalyse Software- spezifikation IIPK Datenbank- Software entwurf Mensch-Maschine-Schnittstelle (Styleguide) Software-Modul Hardware-Einheit (analog zur Softwareeinheit, ohne DB-Entwurf) Software- Fertigprodukte spezifikation Externe Einheit Externes Software-Modul Funktionssicherheitsanalyse Make-or-Buy Ext.-Einheit Make-or-Buy Entscheidung Spezifikation Entscheidung Erweiterung der Vorgaben: - zur Informationssicherheit - zum Datenschutz - zum IT-Betrieb Externes-Software-Modul Sicherheitskonzeption Fertigprodukte Spezifikation Software-Anteil) Fertigprodukte Abb. 3.5 Überblick über die V-Modell-Produkte für die Systementwicklung (weiß: Produkte der Spezifikation und des Entwurfs, grau: Produkte der Qualitätssicherung) 3.3.3 Vorgehensweisen im V-Modell XT Die Ergebnisstruktur des V-Modell XT ist zunächst unabhängig vom konkreten Vorgehen in der Entwicklung. Die Verbindung wird über das Konzept des Entscheidungspunkts hergestellt. Definition 3.2 (Entscheidungspunkt) In einem Entscheidungspunkt wird über das Errei- chen einer Projektfortschrittsstufe entschieden. Diese Entscheidung wird auf Basis der zum Entscheidungspunkt vorzulegenden, fertig gestellten Produkte getroffen. Durch Projektdurchführungsstrategien werden die Entscheidungspunkte in eine Reihen- folge gebracht, die festlegt, zu welchem Zeitpunkt im Projekt ein Artefakt fertiggestellt werden muss. Dadurch wird sichergestellt, dass Artefakte in jedem Fall erstellt werden, jedoch werden Freiräume im Hinblick auf die Reihenfolge und die Wahl der zur Erstellung verwendeten Methoden und Praktiken geschaffen. 3.3 Das V-Modell XT 101 Iterationen und Inkremente Lastenheft (Anforderungen) Anforderungen Abnahme Lieferung (von AN) Anforderungsbewertung festgelegt erteilt Verifikation und Validierung (V&V) Pflichtenheft Gesamtsystem Lieferung Lieferung (Gesamtsystementwurf) entworfen (V&V) Systemarchitektur System Systemspezifikation System System entworfen integriert Externe Einheit IIPK System (V&V) Logistische Externe-Einheit-Spezifikation Unterstützungsdoku. HW-/SW-Architektur Einheit(en) Einheit(en) HW-/SW-Einheit(en) HW-/SW-Spezifikation entworfen realisiert IIPK HW-/SW (V&V) Abb. 3.6 Grundlegende Vorgehensweise im V-Modell XT mit den Produkten des Systementwurfs 3.3.3.1 Grundstruktur Das V-Modell XT setzt mehrere Konzepte der grundlegenden Vorgehensmodelle um. Es folgt im Grundablauf (Abb. 3.6) dem klassischen V-Modell, wobei die Entscheidungspunkte keinen Phasenabschluss, sondern ein sogenanntes Quality Gate bilden, zu dem bestimmte Ergebnisse fertiggestellt und qualitätsgesichert vorliegen müssen. Planungstechnisch stehen alle Entscheidungspunkte in einer Ende-Ende-Beziehung. Damit kann grundsätzlich mit allen Arbeiten frühestmöglich und überlappend begonnen werden, solange die geforderten Ergebnisse zum gesetzten Termin vorliegen. Die vom klassischen V-Modell übernommene Grundstruktur erlaubt es weiterhin, die Entwurfs- und Integrationsschritte gegenüberzustel- len und somit die erforderlichen Maßnahmen zur Qualitätssicherung im Projekt zu plat- zieren. Schlussendlich ist der Entwicklungszyklus im V-Modell XT iterativ-inkrementell ausgelegt, das „V“ wird also mehrfach durchlaufen und pro Iteration wächst das System. Wie im Spiralmodell können die Arbeiten parallelisiert werden, sodass faktisch mehrere „V‘s“ gleichzeitig durchlaufen werden. 3.3.3.2 Projektdurchführungsstrategien Während Abb. 3.6 den Grundablauf und seine Struktur darstellt, fasst Abb. 3.7 die für dieses Buch besonders relevanten, grundlegenden Strategien zur Systementwicklung für Auftragnehmer- (AN) und Auftraggeber-/Auftragnehmer-Projekte (AG/AN) zusammen. Diese beiden grundlegenden Vorgehensweisen bilden das konkrete Vorgehen in einem Projekt über das Vertragsverhältnis ab: Ein Auftragnehmer-Projekt entsteht durch die Beauf- tragung durch einen Auftraggeber, während ein Auftraggeber-/Auftragnehmer-Projekt kein explizites Vertragsverhältnis voraussetzt (vgl. [16, Kap. 2.3.1.1]). Entsprechend unterschei- det sich der Grundablauf: Im ersten Fall ist eine explizite Angebots- und Beauftragungsphase Bestandteil des Projekts. Hervorzuheben sind in der Abb. 3.7 die beiden Einschuboptionen für Entwicklungsstrategien. Eine Entwicklungsstrategie legt die wesentliche Ausgestaltung im Sinne von Meilensteinreihenfolgen im Projekt fest. Abb. 3.8 zeigt die Inkrementelle 102 3 Vorgehensmodelle in der Softwareentwicklung Projekt Projekt Projekt genehmigt initialisiert abgeschlossen Angebot Beauftragung Abnahme Anforderungen Abnahme abgegeben erhalten erhalten festgelegt Iteration : Entwicklungsstrategie Iteration : Entwicklungsstrategie geplant geplant Abb. 3.7 Grundlegende Ablauforganisation für AN- und AG-/AN-Projekte im V-Modell XT Inkrementelle Systementwicklung: Entwicklungsstrategie Gesamtsystem Lieferung entworfen S 1..* 1..* J System System entworfen integriert 1..* S * : Unterauftrag * J 1..* Einheit(en) Einheit(en) entworfen realisiert * S 1 1 J * : Unterauftrag Unterauftrag: Unterauftrag Ausschreibung Beauftragung Abnahme freigegeben erteilt Spezifischer, optionaler Ablauf im Projekt - hier: sollten Komponenten durch Unterauftragnehmer erledigt Iteration Projektfortschritt werden, wird hier ein Teil eines AG- geplant Projekts ausgeplant Abb. 3.8 Die inkrementelle Systementwicklung als exemplarische Entwicklungsstrategie im V- Modell XT (ergänzt um einen Ablauf zur Unterbeauftragung von Entwicklungsaufgaben) Systementwicklung als exemplarische Ausprägung und zeigt außerdem wie sich Unterauf- träge in einen solchen Entwicklungsprozess einbinden lassen. Alle diese Elemente sind im V-Modell XT in den sogenannten Ablaufbausteinen gekapselt und können in einem Projekt weitgehend frei miteinander kombiniert werden [26, 40]. So ist es beispielsweise möglich, zwischen den Iterationen die Entwicklungsstrategie zu wechseln. Auch wenn mehrere Entwicklungsstränge parallel ablaufen, ist es möglich, jeden Strang mit 3.3 Das V-Modell XT 103 einer anderen Entwicklungsstrategie durchzuführen. Standardmäßig bietet das V-Modell XT für die AN- und die AG/AN-Projekttypen die folgenden Entwicklungsstrategien, die jeweils um Unteraufträge erweitert werden können, an: Inkrementelle Systementwicklung (Abb. 3.8) Komponentenbasierte Systementwicklung Prototypische Systementwicklung Wartung und Pflege Dies verleiht bereits dem V-Modell XT Referenzmodell eine breite Anwendbarkeit und hohe Flexibilität. Im Rahmen einer organisationsspezifischen Anpassung [40, 41] können diese Entwicklungsstrategien angepasst werden und es können darüber hinaus noch weitere, eigene Entwicklungsstrategien hinzugefügt werden. 3.3.3.3 Projektschnittstellen Als Besonderheit bietet das V-Modell XT eine enge Integration von Auftraggebern und Auftragnehmern über die Auftraggeber-/Auftragnehmerschnittstelle (AG/AN-Schnittstelle). Diese Schnittstelle wird aus einer Menge von Entscheidungspunkten gebildet, welche Auf- traggeber und Auftragnehmer in ihren jeweiligen Projektdurchführungsstrategien durchlau- fen müssen. Die zu diesen Entscheidungspunkten vorzulegenden V-Modell-Produkte sind dann Gegenstand des Austauschs zwischen den Projekten, es wird also über die Entschei- dungspunkte festgelegt, wer an wen Ergebnisse zu liefern hat und in welchem Umfang. Die Entscheidungspunkte der AG/AN-Schnittstelle sind in der Projektplanung aufein- ander abgestimmt und realisieren einen „Produktfluss“ zwischen den Projektpartnern, etwa Software, die an den Auftraggeber geliefert wird, und Fehlermeldungen oder Änderungsfor- derungen, die an den Auftragnehmer übergegeben werden. Abb. 3.9 visualisiert die AG/AN- Schnittstelle. Diese Schnittstelle findet immer dann Anwendung, wenn ein Auftraggeber ein Projekt an einen Auftragnehmer beauftragt, bzw. wenn ein Auftragnehmer einen Unterauf- trag vergibt. Ferner stellt die AG/AN-Schnittstelle Transparenz her. Die auszutauschen- den Ergebnisse sind benannt und spezifiziert, während die konkreten Methoden und Prak- tiken, mit denen die Ergebnisse im jeweiligen (Unter-)Projekt erstellt wurden, irrelevant sind, sofern dies durch bestimmte Anforderungen, etwa Zertifizierungs- oder Compliance- Anforderungen, nicht anders festgelegt ist. Anmerkung Auch wenn das V-Modell XT durch die Projektdurchführungsstrategien flexi- ble Vorgehensweisen anbietet, gibt es doch einen Unterschied zu agilen Vorgehensweisen: das V-Modell XT ist planungsintensiver, da stets das Gesamtprojekt im Blick behalten werden muss. Im Gegensatz dazu finden sich beim agilen Vorgehen in der Regel Vorgehensweisen, bei denen die Planung nur auf die jeweils anstehende Iteration beschränkt ist. Ein Beispiel hierfür ist Scrum, welches im nächsten Abschnitt besprochen wird. 104 3 Vorgehensmodelle in der Softwareentwicklung Ausschreibung Beauftragung Iteration Abnahme Projekt AG-Projekt freigegeben erteilt geplant erteilt abgeschlossen Projektfortschritt abschlussbericht Ausschreibung t Lieferung bo Projekt- Vertrag ge An Abstimmung u. Koordination Angebot Beauftragung Abnahme Projekt AN-Projekt abgegeben erhalten erhalten abgeschlossen Iteration Gesamtsystem geplant Lieferung entworfen Abb. 3.9 Auftraggeber-/Auftragnehmerschnittstelle im V-Modell XT 3.4 Scrum Scrum [58, 59] ist ein verbreitetes Vorgehensmodell, das der Idee des „Lean Production“ [42, 62] entstammt. In Scrum organisieren sich Projektteams weitgehend selbstständig anhand von Ritualen (wie Daily Scrum oder Retrospectives). Eine der Grundannahmen von Scrum ist, dass Projekte komplex und reich an Unsicherheiten sind und sich somit nicht von Anfang an detailliert ausplanen lassen. Scrum-Teams definieren daher zunächst einen groben Rah- men, in dem sie sich selbstorganisierend bewegen. 3.4.1 Rollen in Scrum Scrum besitzt kein detailliert ausgeprägtes Rollenmodell, wie der Rational Unified Pro- cess (RUP; ) oder das V-Modell XT (siehe Abschn. 3.3.1). Vielmehr verteilt Scrum die Aufgaben im Projekt auf lediglich drei Rollen: Product Owner Entwicklungsteam Scrum Master Die Verantwortung für das Ergebnis übernimmt der Product Owner. Er wählt die umzu- setzenden Anforderungen aus einem Product Backlog aus, priorisiert diese und sorgt für die Erreichung der gesetzten fachlichen Ziele. Zur Definition der Ziele werden meist User Stories (siehe Kap. 7.4.1) verwendet, wobei auch andere Techniken erlaubt sind. Die Implementierung wird durch das Entwicklungsteam durchgeführt, das selbstorga- nisierend innerhalb einer Time Box (sogenannte Sprints) bestimmt, welche Elemente des Product Backlogs umgesetzt werden. Das Entwicklungsteam besteht idealerweise aus 3–9 3.4 Scrum 105 Personen. Es schätzt die Aufwände der einzelnen Backlog-Elemente ab und beginnt mit der Implementierung der für den nächsten Sprint machbaren Elemente. Dazu wird vor dem Beginn des Sprints ein weiteres Planungstreffen durchgeführt, bei dem die höchstpriorisier- ten Elemente des Backlogs und konkrete Aufgaben aufgeteilt werden. Das Entwicklungs- team hat das Recht, eine Auswahl zu treffen, verpflichtet sich dafür aber auch, dass durch die Auswahl gesetzte Ziel zu erreichen. Man spricht hierbei von einem „Commitment“. Der Scrum Master ist dafür zuständig, dass der Scrum-Prozess im Projekt umgesetzt wird. Er sorgt dafür, dass das Entwicklungsteam produktiv arbeiten kann. Der Scrum Master ist kein Mitglied des Entwicklungsteams. Er hat keine Weisungsbefugnisse im Projekt und mischt sich nicht in die Kommunikation zwischen Entwicklungsteam und Product Owner ein. Allerdings hat er die Pflicht, darauf zu achten, dass sich das Entwicklungsteam ohne Einflussnahme des Product Owners selbst organisieren kann. Der Scrum Master ist somit eine Art Mentor. 3.4.2 Scrum Artefakte und Prozess Genau wie beim Rollenmodell ist Scrum auch hinsichtlich der Vorgaben zu Artefakten und zum Prozessmodell sehr schmal. Im Wesentlichen fokussiert Scrum das gesamte Projekt auf die in Tab. 3.2 aufgeführten Artefakte Product Backlog, Sprint Backlog und das Release. Das Product Backlog enthält alle Anforderungen an die zu realisierende Software (Fea- tures). Es muss zu Beginn eines Projekts nicht vollständig sein und kann mit dem Wissens- zuwachs im Projekt fortgeschrieben werden, also um neue Anforderungen ergänzt werden. Diese werden regelmäßig priorisiert und bewertet. Hoch priorisierte Features werden in das Tab. 3.2 Scrum Artefakte Artefakt Beschreibung Product Backlog Enthält alle (bis zum jeweiligen Zeitpunkt) bekannten Anforderungen an die die Software. Wird durch den Product Owner erstellt und gepflegt Sprint Backlog Wird durch das Projektteam erstellt und spiegelt durch eine Auswahl der Inhalte des Product Backlog die Zielvorgaben für einen Sprint wieder. Während eines Sprints wird das Sprint Backlog nicht um neue Einträge erweitert Release Jeder Sprint schließt mit einem lieferfähigen Release ab, welches in der Regel durch den Kunden geprüft wird. Man beachte, dass in der offizi- ellen Scrum Guide der Begriff Product Increment verwendet wird. Ein Inkrement ist in als „Summe aller Einträge im Product Backlog“ beschrieben, welche fertiggestellt und potenziell nutzbar sein sollen. Um hier jedoch Konsistenz mit den Begrifflichkeiten für die Kernaufgaben in Softwareentwicklungsprojekten (siehe Kap. 1.3) zu erhalten, verwenden wir einfach den Begriff Release 106 3 Vorgehensmodelle in der Softwareentwicklung Sprint (max. 30 Tage) Product Scrum Team Owner Master Sprint Backlog Daily Scrum Product (1x Tag) Dokumentation Backlog erstellen Release/ Product Sprint Increment Abnahmetest Planning und Freigabe Product Grobdesign Design Meeting Backlog erstellen Review Sprint erstellen Meeting Sprint Review Retrospective Meeting Optional Abb. 3.10 Der Scrum Prozess (vereinfacht nach ) Sprint Backlog übernommen. Das Sprint Backlog enthält alle Aufgaben, die das Entwick- lungsteam im anstehenden Sprint eingeplant hat. Der Erfüllungsgrad der Aufgaben wird täglich in einem Burndown-Chart dargestellt, welcher die verbleibende Arbeit visualisiert. Der Sprint ist das zentrale Element des Scrum-Prozessmodells (Abb. 3.10). Er kennzeich- net eine Iteration in Form einer Time Box (Scrum sieht hierfür maximal 30 Kalendertage pro Sprint vor ). Time Boxing zielt auf einen fixierten Fertigstellungstermin für gegebene Aufgaben, zu dessen Einhaltung falls nötig inhaltliche Abstriche in Kauf genommen werden. Jeden Tag wird ein Daily Scrum durchgeführt. Dieses Ritual dient dazu, dass im Rahmen eines kurzen Projekttreffens jeder im Projektteam berichtet, was sein aktueller Arbeitsstatus ist, was er bis zum nächsten Daily Scrum bearbeiten will und wo er möglicherweise Pro- bleme im Projekt hat, die der Scrum Master lösen muss. Ziel ist es, dass möglichst jeder im Projekt über den aktuellen Status informiert ist. Konkret sind im Daily Scrum die folgenden Fragen von jedem Teammitglied zu beantworten: 1. Was habe ich seit gestern getan, um das Sprint-Ziel zu erreichen? 2. Was mache ich bis morgen, um das Sprint-Ziel zu erreichen? 3. Was behindert mich bei meiner Arbeit? Nach jedem Sprint soll eine lauffähige Version der Software (Release) vorliegen, die mit dem Kunden in einem Review geprüft wird. Änderungsforderungen, die der Kunde im Rahmen des Reviews aufstellt, werden wieder in das Product Backlog eingepflegt. Ebenfalls am Ende eines Sprints ist das Projektteam dazu aufgerufen, in eine Retrospektive zu gehen und den zurückliegenden Projektabschnitt zu bewerten. Die Erfahrungen werden im nächsten Sprint berücksichtigt und an den Scrum Master zurückgemeldet, wenn Probleme zu beseitigen sind. 3.4 Scrum 107 Anmerkung Scrum ist ein reines Vorgehensmodell, das nicht explizit auf Softwareentwick- lung ausgerichtet ist. Prinzipiell lässt sich jede Entwicklungsaufgabe nach Scrum gestalten. Im Gegensatz zum Wasserfallmodell oder zum V-Modell, wo konkrete inhaltliche Aufga- ben der Softwareentwicklung explizit erwähnt werden, wird in Scrum nichts dazu gesagt. So könnte man ein Scrum-artiges, Sprint-orientiertes Vorgehen letztlich auch im Wasserfall ein- setzen, wobei man allerdings Einbußen in der Flexibilität hinnehmen müsste. Zusätzlich zur Wahl von Scrum als Organisations- und Vorgehensmodell ist deshalb stets ein methodisches Vorgehen festzulegen [63, 69]. 3.4.3 Anforderungen an die Organisation Scrum erfordert hohe Eigenverantwortung im Projektteam und für die einzelnen Mitarbeiter. Das Unternehmen muss einen hohen Reifegrad besitzen und Techniken wie automatische Testverfahren (siehe Kap. 12.2.5) und Refactoring (siehe Kap. 13.2.3.4) beherrschen. Die Mitarbeiter müssen in modernen Programmiertechniken ausgebildet sein, um in den kurzen Iterationen des Projekts auch Ergebnisse produzieren zu können. Weiterhin ist der Erfolg von Scrum von einem sozial ausgewogenen Team abhängig. Dominante Einzelcharaktere oder Animositäten stören das selbstorganisierende Team und wirken sich negativ auf die Produktivität aus. 3.4.4 Scrum in der Praxis Wie eingangs bereits dargestellt, werden die unterschiedlichen Ansätze und Vorgehenswei- sen zur Software- und Systementwicklung nur selten Wort-für-Wort umgesetzt. Diebold et al. zeigen beispielsweise in einer Interviewstudie, dass kein einziger der Befragten Scrum exakt dem Wortlaut aus entsprechend umsetzt. Abweichungen ergeben sich etwa aus den Rahmenbedingungen des Projekts, etwa dass der Kunde nicht verfügbar ist (On- Site Customer), oder dass das Team eine abweichende Vorgehensweise als sinnvoller und effizienter ansieht. Ein wesentlicher Grund für die Modifikationen von Scrum in konkreten Projekten und von agilen Methoden im Allgemeinen ist insbesondere die problematische Skalierung. Agile Methoden sind üblicherweise auf kleinere Teams ausgerichtet. Umfang- reiche Softwaresysteme werden aber häufig durch mehrere, große und auch verteilte Teams entwickelt. Lous et al. identifizierten 45 Kernprobleme, von denen die meisten die Skalierung von Scrum in einem großen, verteilten Projektkontext betreffen. Da Scrum im Kern eine allgemeine Projektmanagementmethode ist, ist die Notwendigkeit der Kombination mit weiteren Methoden und Praktiken, insbesondere solche für die eigent- liche Entwicklung, wenig überraschend. In Tell et al. wurden Analysen durchgeführt, welche Methoden und Praktiken üblicherweise mit Scrum kombiniert werden. Abb. 3.11 zeigt einen solchen „Methoden-Cluster“, der die wesentlichen Methoden und Praktiken 108 3 Vorgehensmodelle in der Softwareentwicklung Basis-Methoden Standard-Praktiken Optionale Praktiken Iteration/Sprint Scrum Release Planning Planning Code Review Backlog Kanban User Stories Management Coding Standards DevOps Daily Standup Prototyping Iteration/Sprint Retrospectives Reviews Design Reviews Refactoring Continuous Automated Unit Integration Testing End-to-End Testing Abb. 3.11 Exemplarischer Methoden-Cluster für eine Scrum-Kanban-DevOps-basierte Methode enthält, mit denen Scrum in der Praxis angereichert wird. Den Grundstock bildet hierbei eine Scrum-Kanban-DevOps-Kombination. Nach Tell et al. werden diese Basis-Methoden durch zwei Standard-Praktiken komplettiert. Die verbleibenden 13 Praktiken werden in der Regel in unterschiedlichen Kombinationen hinzugenommen. Bestimmte Praktiken bedingen sich hierbei auch. So erfordert DevOps (siehe Kap. 12.4.2) beispielsweise einen Continuous- Integration Prozess, welcher wiederum ein automatisiertes Testen benötigt. Weitere Prak- tiken werden üblicherweise bereits im Rahmen einer bestimmten Methode implementiert, können jedoch auch für sich alleinstehend in anderen Methoden verwendet werden. So ist der Daily Standup integraler Bestandteil von Scrum, jedoch kann eine solche Praktik durchaus auch in anderen Entwicklungsmethoden implementiert werden, etwa im V-Modell XT. 3.4.5 Skalierung von Scrum Wie oben dargestellt, haben Lous et al. die Skalierung von Scrum als besondere Her- ausforderung identifiziert. Skalierung betrifft hier zumindest zwei Dimensionen: einmal das Vergrößern des Projektteams und weiterhin das Aufsetzen von (global) verteilten Projekt- teams. Beide Herausforderungen können hierbei gemeinsam auftreten, etwa in einem großen Projekt, welches verteilt über den Globus durchgeführt wird. 3.4 Scrum 109 Botschafter (Ambassadors) Scrum of Scrums (Regelmäßig, z.B. 1x pro Woche) Product Team Owner = Scrum Master Scrum Team A Scrum Team B Scrum Team C DS DS DS Daily Scrum (1x pro Tag) Abb. 3.12 Organisationsstruktur eines Projekts nach Scrum-of-Scrums 3.4.5.1 Scrum-of-Scrums Bei der Größenskalierung von Scrum ist es zunächst naheliegend, dass bei der Bearbeitung größerer Projekte, die deutlich mehr als 10 Entwickler, etwa 100 oder gar 1000 Entwick- ler benötigen, die Entwicklungsmannschaften in Teams der Größe zerlegt werden, wie sie Scrum vorsieht. Dann bleibt aber die Aufgabe, zehn, zwanzig oder gar hundert Scrum-Teams zu koordinieren und sicherzustellen, dass die einzelnen, verteilten Teams zu „einem Team“ zusammengefügt werden können. Das erfordert zusätzliche Überlegungen hinsichtlich der Projektorganisation und der Handhabung der Schnittstellen zwischen den einzelnen Scrum- Teams. Ein pragmatischer Ansatz hierfür ist das sogenannte Scrum-of-Scrums (SoS3 ; ). Abb. 3.12 zeigt die schematische Organisationsstruktur eines Projekts, das nach Scrum- of-Scrums organisiert ist. Jedes Scrum-Team entsendet einen Botschafter, der in einem zusätzlichen Treffen den Status des eigenen Teams berichtet. Damit soll erreicht werden, dass die Arbeiten in den unterschiedlichen Teams synchronisiert werden. Grundsätzlich ist der Scrum-of-Scrum ähnlich organisiert wie der Daily Scrum (siehe Abschn. 3.4.2). Jeder Botschafter beantwortet hier Fragen, die jedoch an den Zweck des Treffens angepasst sind: 1. Was hat mein Team geschafft, seit wir uns das letzte Mal getroffen haben? 2. Was wird mein Team bis zum nächsten Treffen erledigen? 3 Weitere Informationen der Agile Alliance unter https://www.agilealliance.org/ (Glossar, Abruf: 2019-11-24) zu entnehmen. 110 3 Vorgehensmodelle in der Softwareentwicklung 3. Welche Hindernisse behindern mein Team bei der Arbeit? 4. Könnte eine Tätigkeit meines Teams ein anderes Team beeinflussen oder behindern?4 Achtung Bei der Umsetzung des Scrum-of-Scrums ist Vorsicht geboten! Grundsätzlich kann ein Scrum-of-Scrums auch wiederholt auf eine große Organisation angewendet wer- den. Jedes Team entsendet einen Botschafter, aus den Botschaftern können in der nächsten Ebene wieder Botschafter ausgewählt und entsendet werden – und so weiter. Es entsteht somit eine sehr komplexe Kommunikationsstruktur im Projekt. Neben den langen Kommunikati- onswegen muss dann auch bedacht werden, dass die Botschafter ihre Botschaft übermitteln und die Erkenntnisse wieder rückkoppeln müssen. Hier kann es schnell zu Informations- verfälschungen oder sogar zu Informationsverlust kommen. Weiterhin geht die schnelle und direkte Kommunikation damit über kurz oder lang verloren. Kritisch ist dann auch die Koordination der Scrum-Teams über die Botschafter, wenn Konflikte auftreten oder keine brauchbare konsolidierte Dokumentation existiert. 3.4.5.2 Large-Scale Scrum Ein weiterer, strukturierter Ansatz in diesem Zusammenhang ist Large-Scale Scrum (LeSS; ). Dieses Skalierungsframework wird gekennzeichnet durch den Satz: „LeSS is Scrum applied to many teams working together on one product“, aber wie man bereits aus dieser Kennzeichnung sieht, gehört mehr dazu, als eine große Entwicklungsorganisation in eine Reihe von Scrum-Teams zu zerlegen. Man muss im Sinne von LeSS eine Reihe von Scrum- Teams so organisieren, dass sie auch übergreifend und koordiniert an einem Projekt arbeiten können (Abb. 3.13). Ein wesentlicher Punkt dabei ist, nach welchen Gesichtspunkten man die Entwicklung organisiert. Dabei wird häufig Feature-orientiert gearbeitet, sodass jedes einzelne Team bestimmte funktionale Features, kurz gesagt Kundenfunktionen, umsetzt. LeSS führt für größere Projekte zusätzlich zu Scrum eine Reihe von Prinzipien und Regeln ein. Es sagt aber von sich selbst, dass diese Regeln minimalistisch sind und die Frage nicht beantworten, wie LeSS tatsächlich angewandt werden soll. Sie sollen nur die Basis für das Vorgehen sein, das dann von den Beteiligten noch an die spezifische Situation angepasst werden muss. Die Entwicklungsaufgaben sind stark auf die Themen der Koordination und des Conti- nuous Delivery (siehe Kap. 12.4.1.2) abgestimmt. Zusätzlich werden sogenannte Commu- nities geschaffen, wie die Test Community und die Design/Architecture Community. Diese sind darauf ausgerichtet, die Arbeit zwischen den Teams zu koordinieren. Dazu gibt es ein Overall Product Backlog, in der die Verantwortlichen aus den einzelnen Teams gemein- sam das Gesamt-Backlog festlegen. Am Ende jedes Sprints finden Team Retrospectives im 4 Diese Frage ist eine Erweiterung des „Standard“ Scrum-Prozesses , welche durch den Scrum-of- Scrums hinzugefügt wurde, um die besonderen Anforderungen einer Multi-Team-Projektumgebung zu adressieren. 3.4 Scrum 111 Area Product Owner Area Product Owner Sprint (max. 30 Tage) Area Team Product Scrum Backlog Master Sprint Backlog Sprint Team (max. 30 Tage) Scrum Master Sprint Backlog Team Sprint Scrum Master (max. 30 Tage) Product Area Owner Product Owner Sprint Backlog Daily Scrum (1x Tag) Product Area Sprint Sprint Backlog Product Planning Planning Release/ Backlog Product Meeting Meeting Increment (Teil 1) (Teil 2) Sprint Sprint Review Retrospective Meeting Gemeinsame Sprint Retrospective Abb. 3.13 Skalierung von Scrum mit Large-Scale Scrum (LeSS, vereinfachte Darstellung) Rahmen von Multi Team Design Workshops statt, in denen auf den abgeschlossenen Sprint zurückgeblickt wird. In LeSS, wie allgemein in Scrum, steht letztlich die Frage der Teamorganisation und der Rollen im Team sehr stark im Vordergrund. Es wird wenig über Dokumentation gesagt. Will man Scrum-nahe Vorgehensweisen in großen Projekten einsetzen, in denen Fragen der Qualität, der Architektur und der Korrektheit und eben auch der funktionalen Sicherheit sehr 112 3 Vorgehensmodelle in der Softwareentwicklung stark im Vordergrund stehen, so ist es dringend erforderlich, genauer festzulegen, welche Art von Dokumentation erstellt werden soll, deren Erstellung im konsequenten Fall natürlich auch den Prinzipien von Scrum unterworfen wird. Dazu ist aber genau zu überlegen, in welchem Umfang, wer dafür verantwortlich ist, dass die Dokumentation erstellt wird und dass sichergestellt wird, dass die Dokumentation den Stand des Projektes korrekt wiedergibt. Entscheidend ist dabei auch die Frage, welche Rolle die Dokumentation für die aktive Arbeit spielt, da dann Backlogs und Dokumentation auf einander abgestimmt werden müssen. LeSS geht also über Scrum hinaus und adressiert typische Aufgaben der Softwareentwicklung wie Architektur, Integration und Dokumentation. Skalierungsframeworks für Agile Methoden LeSS ist nur eines der verfügbaren Skalierungsframeworks für agile Vorgehenswei- sen. Weitere Beispiele sind der fast schon „klassische“ Scrum-of-Scrums , das Scaled Agile Framework (SAFe; ), Disciplined Agile Delivery (DAD; ) oder Nexus. Solche Skalierungsframeworks sind jedoch kritisch zu betrachten. Ins- besondere agile „Puristen“ sehen bereits durch die Anwendung solcher Frameworks die agilen Prinzipien verletzt. So fällt beispielsweise beim SAFe die Komplexität des Frameworks sofort auf, was die Frage aufwirft, inwiefern solche Ansätze überhaupt noch als agil anzusehen sind. Wie bei allen Vorgehensmodellen gilt es daher auch bei der Skalierung agiler Vorgehensweisen Augenmaß zu halten und den Fokus auf die für die aktuelle Situation angemessene Vorgehensweisen zu legen. 3.4.6 Scrumban Abschließend wollen wir noch auf eine Methode eingehen, welche sich in letzter Zeit immer größerer Beliebtheit erfreut: Scrumban [35, 42, 56]. In Scrumban werden Scrum und Kan- ban miteinander kombiniert. Obwohl Scrum eine Projektmanagementmethode ist, welche im Wesentlichen Rituale für ein Team formalisiert und grundlegende Abläufe vorgibt, fehlen für viele Aufgaben konkrete Vorgaben, insbesondere den tatsächlichen Arbeitsprozess des Teams betreffend. Das Management der Aufgaben in einem nach Scrum organisierten Pro- jekt wird in Scrumban durch Kanban übernommen, welches im Folgenden kurz eingeführt wird. 3.4.6.1 Kanban Kanban entstammt ursprünglich der Produktionsprozesssteuerung der Toyota Motor Corporation und orientiert sich ausschließlich am tatsächlichen Verbrauch von Mate- rialien. Ursprünglich war Kanban dazu gedacht, eine Reduktion der lokalen Lagerbestände von Vorprodukten in der Produktion der nächsten Integrationsstufe zu erreichen. Für die 3.4 Scrum 113 Softwareentwicklung wurde Kanban adaptiert und insbesondere auf die Reduktion von Ver- schwendungen („Reduction of Waste“), einem Prinzip aus dem Lean Development (eben- falls Toyota; [53, 70]), hin optimiert. In diesem Zusammenhang werden mit Kanban zwei Kernziele verfolgt: 1. Modelliere den Prozess so, dass er den tatsächlichen Arbeitsprozess akkurat wiedergibt. 2. Optimiere „Work-in-Progress“ (WiP), um zu viele parallel bearbeitete Arbeitspakete zu verhindern. Kanban selbst verfügt weder über ein Prozess-, Rollen- oder Artefaktmodell. Vielmehr ist Kanban eine einfache Methode zur Organisation und Optimierung des Workflows. Daher sind Scrum und Kanban gut miteinander integrierbar. Scrum gibt den groben Rahmen vor und Kanban expliziert den tatsächlichen Workflow und hilft dabei, für jeden Schritt im Workflow passenden Methoden und Praktiken auszuwählen. In Scrumban werden sogenannte Kanban-Boards eingesetzt, welche eine Arbeit nach dem Pull-Prinzip ermöglichen. Diese Kanban-Boards werden in den folgenden Schritten entwickelt: 1. Analysiere und Visualisiere den Workflow. 2. Limitiere den „Work-in-Progress“ (WiP). 3. Minimiere die Durchlaufzeit für die einzelnen Arbeitsschritte im Workflow. Im ersten Schritt wird aus den einzelnen Arbeitsschritten üblicherweise eine Tabelle erstellt, in der jede Spalte einem Arbeitsschritt entspricht. Für jeden Arbeitsschritt wird im Folgen- den ein sogenanntes „WiP-Limit“ festgelegt. Dieses bestimmt die maximale Anzahl von Vorgängen, die in einem Arbeitsschritt parallel bearbeitet werden dürfen (in Abb. 3.14 dür- fen beispielsweise nur vier Aufgaben gleichzeitig in Bearbeitung sein). In der täglichen Anwendung wird für jedes Arbeitspaket eine Karte erstellt und an das Kanban-Board gehef- tet. Will ein Mitarbeiter an einer Aufgabe arbeiten, nimmt er die entsprechende Karte, schreibt seinen Namen darauf und verschiebt sie in den entsprechenden Arbeitsschritt, etwa von Design nach Development. Dies ist immer möglich, solange die WiP-Limits eingehal- ten werden. Da Mitarbeiter die Arbeit selbst an sich „ziehen“, wird diese Arbeitsweise auch als Pull-Prinzip bezeichnet. Über das Projekt werden dann die einzelnen Arbeitsschritte kontinuierlich gemessen, um die Durchlaufzeit zu optimieren. Abb. 3.14 Beispiel eines Design (4) Development (4) Test (2) Done Kanban-Boards für einen einfachen 4-stufigen Prozess mit WiP-Limits 114 3 Vorgehensmodelle in der Softwareentwicklung Design (4) Development (4) Test (2) Done und Verfeinerung der Entwicklungsschritte Product Sprint Design (4) Development (4) Test (2) Done Backlog Backlog (4) In Design Design Done In Development Development Done In Test Test Done Verfeinerung 2. Stufe: Anpassung der WiP-Limits und Product Sprint Design (8) Development (10) Test (8) Done Backlog Backlog (8) In Design Design Done In Development Development Done In Test Test Done Priority Lane Group 1 Feature Group 2 Feature Abb. 3.15 Adaption eines Kanban-Boards für Scrum und stufenweise Verfeinerung für Projekte 3.4.6.2 Scrum-Kanban Integration Auf Basis dieses Instruments erfolgt auch die Integration mit Scrum. Hierzu kann das Kanban-Board wie in Abb. 3.15 gezeigt durch ein Backlog erweitert werden. Zusätzlich kann der Prozess in der benötigten Detaillierungsstufe modelliert werden. Auch die Abbildung von Teilprojekten ist möglich. Rituale sind wichtig… Obwohl Kanban-Boards häufig digital als softwarebasiertes Planungs- und Kontroll- instrument verwendet werden, ist es doch oft üblich, ein reales, physisches Board im Büro zu haben. Viele Projektteams nutzen dieses Board als „rituellen“ Gegenstand im Projekt, zum Beispiel als Unterstützung für ein Stand-Up Meeting. 3.5 Rollen und Verantwortlichkeiten 115 3.5 Rollen und Verantwortlichkeiten Die unterschiedlichen Vorgehensweisen erfordern natürlich ganz unterschiedliche Rollen (Definition 3.3; ) in den Entwicklungsteams. Kann man beispielsweise beim phase- norientierten Vorgehen (siehe Abschn. 3.2.1) eine relativ strikte Trennung zwischen Ver- antwortlichen für die Anforderungsspezifikation, den Architekturentwurf, die Implementie- rung, das Testern und die Integration vornehmen, so ist es bei agilen Vorgehensweisen (siehe Abschn. 3.2.4) erforderlich, dass diese Aufgaben so organisiert werden, dass die Teammit- glieder in der Lage sind, beispielsweise detaillierte Anforderungen in der Codierung selbst zu identifizieren und umzusetzen. Dementsprechend haben agile Vorgehensweisen ganz andere Rollenkonzepte und Rollenmodelle als phasenorientierte Vorgehensweisen. Definition 3.3 (Rolle) Der Begriff Rolle bezeichnet eine bestimmte Funktion, die eine Person oder Organisationseinheit wahrnimmt. Eine Rolle definiert ein Aufgaben- und ein Fähigkeitsprofil. Rollen werden von Einzelpersonen, Teams oder Organisationseinheiten ausgeübt. Eine Rolle bezeichnet die Menge aller Fähigkeiten, Kenntnisse und Verhaltens- weisen, die eine Person benötigt, um eine bestimmte Aufgabe wahrzunehmen. Bei einer Softwareentwicklung sind zwei Rollen besonders wichtig: Der Projektleiter verantwortet die Projektdurchführung. Der Product Owner verantwortet die Funktionalität und Qualität des Produkts. In den unterschiedlichen Vorgehensmodellen sind diese Rollen oft unterschiedlich geschnit- ten, manchmal in einer Person zusammengeführt, manchmal deutlich getrennt. 3.5.1 Der Product Owner Der Begriff des Product Owners wird heute sehr stark mit der Organisation einer Software- entwicklung nach Scrum (siehe Abschn. 3.4) verbunden. Hier hat der Product Owner eine genau festgelegte Rolle und Aufgabe: Er wird als Schnittstelle zwischen dem Projektteam und dem Kunden definiert und stellt sicher, dass der Kunde und seine Anforderungen und Interessen angemessen im Projekt vertreten sind. In nicht-agilen Projekten wird der Product Owner oft mit dem klassischen Projekt- leiter gleichgesetzt, was jedoch nicht angemessen ist. Der Projektleiter nimmt in erster Linie Managementaufgaben wahr und stellt sicher, dass das beauftragte System in der gesetzten Zeit, mit der geforderten Funktionalität und im gegebenen Kostenrahmen an den Kunden geliefert wird. Die Aufgaben des Projektleiters umfassen somit schwerpunktmäßig Organisations- und Controlling-Aspekte. Der Product Owner hingegen hat nach Scrum eine klar umrissene Aufgabe – das Management des Product Backlogs. Er kommuniziert Inhalte 116 3 Vorgehensmodelle in der Softwareentwicklung des Backlogs an das Team und stellt sicher, dass mit jedem Sprint ein Wert im Sinne des Kunden geschaffen wird. Das heißt, dass der Product Owner in erster Linie das Manage- ment des Produkts zur Aufgabe hat – nicht das Management des Teams, welches sich selbst organisiert und die Verantwortung für den Entwicklungsprozess hat. Es ist aber wichtig zu unterstreichen, dass die Aufgabe des Product Owners natürlich in jeder Art von Softwareentwicklung und Vorgehensweise von entscheidender Bedeutung ist. Es handelt sich hier um die Frage, wer die wesentlichen Entscheidungen im Hinblick auf die Anforderungen eines Systems trifft und verantwortet (siehe Kap. 5). Da in Scrum iterativ gearbeitet wird und die Anforderungen Schritt für Schritt ermittelt und entschieden werden, hat der Product Owner über den gesamten Entwicklungsprozess eine aktive Rolle. Werden Anforderungen explizit erstellt, so ist die Aufgabe des Product Owners stark konzentriert in der Phase der Anforderungsanalyse und er hat hier die Verantwortung für die wesentlichen Entscheidungen in der Festlegung der Anforderungen zu tragen. Achtung Aus Sicht der Anforderungsanalyse ist der Product Owner von enormer Wichtig- keit, da er als „Proxy“ der Stakeholder im Projekt agiert und sicherstellen muss, dass das realisierte System dem entspricht, was der Kunde braucht und erw