Softwareentwickler, Freiburg im Breisgau

1 Einleitung

1.1 Ausgangslage

Im Unternehmensumfeld haben sich standardisierte wie auch angepasste Vorgehensmodelle längst etabliert. Die fortschreitende Forschung und Entwicklung solcher Modelle, die Verbreitung des Wissens hierüber mittels Vorträgen und Fachliteratur sowie der Austausch von Projektmanagern untereinander haben den Vorgehensmodellen in den vergangenen Jahren seit der sehr prominenten Manifestierung einiger dieser Modelle ihre Aufmerksamkeit auf sich gezogen und eine Verbreitung und Evaluation vorangetrieben.

1.2 Aufbau dieser Arbeit

Das Kapitel „Grundlagen und Begriffe“ liefert die zum Verständnis dieser Arbeit notwendigen Kenntnisse, um den Einstieg ins Themenumfeld Vorgehens- und Prozessmodelle zu finden.

In der Analyse wird auf Grundlagen von Studien ermittelt, welche Vorgehensmodelle in Deutschland verbreitet sind. Außerdem werden Trends und Gründe für den Einsatz bestimmter Arten von Vorgehensmodellen ermittelt.

Im Kapitel „Vorgehensmodelle im Einzelnen“ werden die vier in Deutschland am stärksten vertretenen Modelle erläutert.

Im letzten Kapitel wird die Arbeit durch das Fazit zusammengefasst und abgeschlossen.

2 Grundlagen und Begriffe

2.1 Vorgehensmodell

Vorgehensmodelle, im Englischen auch als Life Cycle Models bezeichnet, betrachten den Software-Entwicklungsprozess von außen und machen (in fast allen Fällen) auch Vorgaben über den Softwareentwicklungsprozess. Daher werden die Begriffe Vorgehensmodell und Prozessmodell im Deutschen fast immer synonym verwendet.

Vorgehensmodelle legen fest, welche Ergebnisse wie[1] zu erreichen sind, bis wann sie fertig sein sollen und wer dafür verantwortlich ist;[2] sie machen häufig Vorgaben über den Entwicklungsprozess, sie enthalten also Prozessmodelle. Als Ausnahme sei das V-Modell 97 genannt, bei dem diese Lücke in der Dokumentation in der Version XT geschlossen wurde.[3]

Vorgehensmodelle verlangen nach den drei Domänen: Produkt, Rolle und Aktivität. Sie kommen dabei nicht ohne den Einsatz von Artefakten innerhalb ihrer Prozesse aus. Vorgehensmodelle sind Zusammenstellungen von auf Werten basierenden Zielen, welche durch mindestens eine Technik erreicht werden.[4]

2.2 Prozessmodell

Prozessmodelle dienen der modellhaften Beschreibung des Ablaufs bestimmter Software-Entwicklungsprojekte und demzufolge auch seiner Phasen.[5] Häufig werden Prozessmodelle sprachlich mit Vorgehensmodellen gleichgesetzt, weil letztere erstere enthalten.

2.3 Vorgehensmodelle im Allgemeinen

Vorgehensmodelle sind Hilfsmittel, die die Erfolgswahrscheinlichkeit eines Projekts verbessern sollen.[6] Moderne Modelle setzen bereits in dem Moment ein, da ein Projekt vorgeschlagen wird. Vorgehensmodelle, im Englischen auch Life Cycle Models, also Lebenszyklusmodelle genannt, begleiten ein Projekt bis zu dessen Abschluss.

Diese Modelle legen Abläufe, Regeln, Iterationen, Kommunikationsregeln, Schnittstellen,  und Zwischenergebnisse fest. Für den Projekterfolg ist die Einhaltung von Kosten, aber auch die Lieferung einer bestimmten (hohen) Qualität unabdingbar.[7] Damit das magische Dreieck vollständig wird, ist auch der Zeitpunkt der Projektauslieferung einzuhalten. So helfen Vorgehensmodelle, Pläne festzulegen und geben sogar feste Zyklen vor.

2.3.1 Leicht- und schwergewichtige Prozesse

Als leichtgewichtig werden solche Prozessmodelle bezeichnet, die keine ausführliche Spezifikation des Projekts verlangen. Dies ist besonders sinnvoll, wenn diese Detailtiefe in einem Projekt schlichtweg noch nicht bekannt ist. Darüber hinaus kommen diese Modelle ohne tiefergehende Dokumentation der Software aus. Dies kommt dem Projektteam insofern zugute, als dass es sich auf die Entwicklung konzentrieren kann.[8]

Leichtgewichtige Prozessmodelle finden häufig in kleinen Teams Anwendung. Sie erlauben eine informelle und damit schnelle Kommunikation untereinander und mit dem Projektkunden.

Die als schwergewichtig bezeichneten Prozessmodelle gehen davon aus, dass die Projektdetails bereits zu Beginn größtenteils oder komplett bekannt sind. In  Projekten mit variablen Anforderungen verhalten sich diese Modelle besonders schwerfällig.

„Schwergewichtige Prozessmodelle zeichnen sich durch eine sehr formale, dokumentengestützte Vorgehensweise aus“.[9] der Gesamtprozess ist ausführlich dokumentiert, ebenso ausführlich müssen seine einzelnen Phasen dokumentiert werden.

In anderen Quellen finden sich für schwergewichtige Prozesse auch Bezeichnungen wie reichhaltig (rich) oder umfassend.[10] Ihnen stehen agile Prozesse gegenüber.

2.4 Methoden

2.4.1 Recherche

Als primäre Methode für die Informationsermittlung für die Analyse dieser Arbeit wird die Recherche genutzt. Hierbei dienen Bücher über Vorgehensmodelle der Beschaffung theoretischen Wissens. Darin enthaltene Berichte sowie Studien aus anderen Quellen dienen der Einordnung und der Bewertung dieser Modelle für bestimmte Einsätze.

Große Bedeutung kommt den Studien IOSE-W² und 3ProcSurvey zu, die in den Jahren 2006 respektive 2012 und 2013 zunächst 65 und später 50 Unternehmen aus der Softwarebranche in unterschiedlichen Größen (von unter 20 bis hin zu 2000 Mitarbeitern) befragt wurden. Diese Studien sind wegen der geringen Teilnehmerzahlen aber nicht als repräsentativ anzusehen[11] und dienen lediglich der Ableitung von Aussagen über Tendenzen.

3 Analyse

3.1 Gemischtes Vorkommen von Vorgehensmodellen

In der Mehrheit der Unternehmen der Softwarebranche kommen gleich mehrere Vorgehensmodelle zum Einsatz. Dies ist auf unterschiedliche Tatsachen zurückzuführen. So ist die Verwendung mehrerer Modelle auf die unterschiedlichen Bereichen der Unternehmen zurückzuführen (26%), es herrschen Vorgaben darüber, welches Vorgehensmodell in Abhängigkeit vom Projekttyp einzusetzen ist (28%), es wird innerhalb des Projekts entschieden (22%) oder die Projektteams können selbst entscheiden, welches Modell zum Einsatz kommt (6,5%). In 17%, also acht der befragten Unternehmen wird durchgängig nur ein Vorgehensmodell eingesetzt.[12]

Bereits diese Aufstellung zeigt, dass der Einsatz von Vorgehensmodellen geplant, vorausbestimmt oder evaluiert werden muss. Seitens der Unternehmensführung wird der Einsatz bestimmter Modelle verlangt oder der Weg für den Einsatz anderer Verfahren freigegeben.

3.2 Verbreitung von Vorgehensmodellen in Deutschland

Studien und Untersuchungen wie IOSE-W² (2006) oder der 3ProcSurvey (2012/2013) lassen gut erkennen, dass vor allem ein Vorgehensmodell/eine Methode deutlich an Bedeutung gewonnen hat: 2013 wurde Scrum in 29% aller befragten Unternehmen eingesetzt. 2006 war das am meisten genutzte Modell RUP, der Rational Unified Process.

Tabelle 1: Anteil der im 3ProcSurvey ermittelten in Deutschland eingesetzten Vorgehensmodelle. Mehrfachnennung war möglich. Eigene Arbeit. Zahlen nach Kuhrmann 2015, S. 39.

Nachdem RUP in den Untersuchungen von 2012 und 2013 nur noch einen Anteil von 6,5% aufwies, lässt sich die Aussage treffen, dass andere Methoden, darunter auch das V-Modell XT, aber insbesondere Scrum zugunsten von RUP aufgeholt haben. Vorgehensmodelle, die ebenfalls an Bedeutung gewonnen haben, in der Gegenüberstellung der beiden Studien aber als „andere“ auftauchen, sind Kanban („Kanban für die Softwareentwicklung“) und Extreme Programming.

Abbildung 1: Verteilung der eingesetzten Vorgehensmodelle laut IOSE-W² (2006) und 3ProcSurvec (2012/2013)[13].

Diese Tendenz zeigt ferner auf, dass eine starke Neigung zu den agilen und leichtgewichtigen[14] Vorgehensweisen besteht, wohingegen schwergewichtige (auch als „rich“ klassifizierte Modelle) wie RUP und V-Modell XT den neueren Untersuchungen zufolge insgesamt schwächer vertreten sind. Als einer der Vertreter der agilen Methoden wird Scrum in der Praxis zum „Überflieger“. Andere agile Methoden wie Crystal oder Feature Driven Development erfahren nur eine Veränderung der Nutzung: FDD verlor zwischen 2006 und 2012/2013 ca. 2,3%; Crystal nahm um gerade einmal 0,6% zu.

Abbildung 2: Tendenzen in der Verwendung verschiedener Vorgehensmodelle.

Den sehr niedrigen Werte mit ebenfalls niedrigen Veränderungen (etwa für Crystal) sollte allerdings keine große Bedeutung zugeteilt werden, weil beide Studien aufgrund der geringen Teilnehmerzahlen nicht repräsentativ sind.

Als bemerkenswerter Wandel ist festzuhalten, dass die beiden 7 Jahre auseinanderliegenden Studien offenlegen, dass sich der Einsatz von Vorgehensmodellen fast durchgängig etabliert hat. Ohne Vorgehensmodell arbeiteten den Ergebnissen des 3ProcSurvey zufolge nur noch 2,2% der Unternehmen.[15] Im Jahr 2006 waren das laut IOSE-W² noch 4,5%.[16] Zwar ist auch diese Zahl nicht repräsentativ, allerdings steht die Differenz für die Einführung von Vorgehensmodellen in immerhin 7 Unternehmen.

3.3 Tailoring oder der Bedarf, Modelle anzupassen

Die wenigsten Unternehmen setzen Vorgehensmodelle genau so ein, wie es von deren Erdenkern gedacht war. Modelle werden auf die Bedürfnisse des Unternehmen zugschnitten. Dieses Tailoring ist bei dem V-Modell (XT) sogar fester Teil des Einführungsprozesses.

Beim Tailoring werden Modelle mit Werkzeugen ausgestattet, Vorlagen für Dokumentation und Kommunikation definiert und die Integration von Ressourcen festgelegt.[17]

3.4 Einsatz und Anforderungen

Insbesondere die reichhaltigen Vorgehensmodelle werden häufig mit agilen Modellen kombiniert. Dabei werden die reichhaltigen Modelle, etwa V-Modell (XT) oder RUP auf der organisatorischen Ebene eingesetzt. Auf Abteilungs- oder sogar erst auf Projektebene kommen dabei agile Modelle zum Einsatz.

Gründe für die unterschiedlichen Einsatzorte und -ebenen sind:

• Schwergewichtige Modelle eignen sich für große Strukturen, also ganze Unternehmen oder große Abteilungen. Schnelle Änderungen in Vorhaben dürfen nicht unvermittelt passieren. Die hier eingesetzten Modelle stellen sicher, dass der Informationsfluss gesichert und Änderungen dokumentiert werden.
• Agile Methoden sind für kleine Teams erdacht worden und erlauben einen schnellen Informationsaustausch zwischen den Teammitgliedern ohne aufwendige Dokumentation. Die Entwicklung der Software oder sogar nur von Komponenten steht im Vordergrund und das oberste Ziel ist ein funktionierendes (Zwischen)-Produkt. Der Einsatz auf Projektebene macht die Arbeit flexibel und man kann schnell auf geänderte Anforderungen reagieren.

4 Vorgehensmodelle im Einzelnen

4.1 Extreme Programming

Extreme Programming ist eine von Kent Beck 1997 erprobte und 2000 beschrieben leichtgewichtige Vorgehensweise für die Entwicklung von Softwareprodukten, deren Anforderungen sich in sehr kurzen Intervallen ändern. Extreme Programming setzt auf die sogenannten Fünf Werte auf:

1. Sie wird im Allgemeinen als entscheidende Komponente betrachtet, weil erst durch Kommunikation im Team, also durch die interne Kommunikation, alle Mitglieder über abweichende Projektziele informiert werden können. Komplexer verhält es sich mit der externen Kommunikation, die den Kunden mit einbezieht. Eine häufig berührte Hemmschwelle seitens des Entwicklerteams ist die Angst davor, dem Kunden zu viele Einblicke in interne Abläufe zu gewähren. Die Praxis zeigt, dass das Gegenteil der Fall ist und Transparenz auf Kundenseite sehr geschätzt wird. Die externe Kommunikation ist deshalb besonders wichtig, weil es auf schnellen Informationsfluss in Projekten mit schnell wechselnden Anforderungen ankommt.[18]
2. Im Extreme Programmingzählt das „Hier und Jetzt“. Lösungen werden in der Form erarbeitet, wie sie zum Zeitpunkt der Bearbeitung benötigt werden. Auf eventuell wechselnde Anforderungen in der Zukunft wird keine Rücksicht genommen. Konkret gesprochen kann Extreme Programming verlangen, dass die Komplexität von Software ihrem Einsatzzweck gerecht werden muss. Das bedeutet in vielen Fällen, dass etwa eine Klasse, auf die wenige Male zugegriffen wird, keine vollständige Abdeckung aller eventuell benötigten Methoden erfüllen muss.[19]
3. Rückmeldung. Rückmeldung oder Feedback durch das System entsteht beispielsweise durch Tests, die im Anschluss an ein Teilprojekt gefahren werden. Feedback kann aber auch die Rückmeldung des Kunden bedeuten, etwa wenn nach Herausgabe des Lastenhefts das Pflichtenheft angelegt wird. Dann muss der Kunde dieses gegenprüfen. Extreme Programmingverlangt auch die Lieferung von Zwischenständen in kurzen Abständen, anhand derer der Kunde Feedback über die Auffassung mit seinem Lastenheft gelieferten Aufgaben geben kann.[20]
4. Schnell wechselnde Anforderungen und kurze Entwicklungsintervalle führen fast immer dazu, dass bisherige Arbeiten komplett aufgegeben und neu erstellt werden müssen. Fast jeder, der etwas geschaffen hat, tut sich schwer, seine Arbeit wegzuwerfen. Mut ist allein schon deshalb nötig, weil es oftmals wirtschaftlicher ist, alte Lösungen aufzugeben und neue, auf die Anforderungen zugeschnittene Lösungen umzusetzen. Mut ist auch eine Voraussetzung für die drei zuvor genannten Werte.[21]
5. Weil erst durch Respekt füreinander das Team gut funktionieren kann und auch Respekt gegenüber dem Kunden aufgebracht werden muss, damit das Projektsolide und langfristig betrieben werden kann, gehört er zu einem der wichtigsten Werte, die ein erfolgreiches Projekt ermöglichen.[22]

Neben den Fünf Werten setzt Extreme Programming noch fünf Regelgruppen fest, die konkrete Vorgaben zur Entwicklung der einer Software machen: Planung, Verwaltung, Entwurf, Entwicklung und Test.

Das Projekt beginnt mit der Planung. Die Anforderungen des Kunden werden festgehalten und daraufhin entwickelt.           Das Projekt wird in kurze Iterationsphasen unterteilt, in deren Anschluss Releases herausgegeben werden. Diese Releases dürften auch nur aus kleine Änderungen bestehen.[23]

Verwaltung bezeichnet die Regulation der Prozesse, notwendig sind, um Extreme Programming am Laufen zu halten. Dazu gehört, den Teammitgliedern abwechslungsreiche Arbeit zuzuteilen, sich regelmäßig zu besprechen und das Vorgehensmodell bei einem Fehlschlag zu „reparieren“. Verbesserungen am Prozess sollen nicht als negativ betrachtet werden, sondern als eine Chance, diesen langlebiger und effizienter zu machen.[24]^, [25]

Die wichtigste Regel für den Entwurf ist, nichts zu implementieren, was nicht gefordert ist. Dies spart Zeit und vermeidet die unnötige Entwicklung „in die Zukunft“ für Softwarebestandteile, die der Kunde später möglicherweise gar nicht mehr wünscht. Diese Regel knüpft an den Wert der Einfachheit an.

Die Regeln für die Entwicklung sollen die Qualität der so schnell entwickelten Software sichern. Dazu gehört, dass immer nur paarweise (Pair Programming) entwickelt werden soll.[26] Das Programmiererpaar soll sich mit nur einer Implementierung befassen. Vor der Entwicklung müssen jedoch die Unit Tests geschrieben werden, damit beim Testen überprüft werden kann, ob die entwickelte Software die geforderten Funktionalitäten erfüllt. Die Abdeckung durch Unit Tests muss vollständig sein und es darf kein Release ohne erfolgreichen Test verabschiedet werden.[27]

4.2 Software-Kanban

Das Wort Kanban kommt aus dem Japanischen かんばん und kann mit Signalkarte übersetzt werden. Kanban entstand ursprünglich beim KFZ-Hersteller Toyota für den Einsatz in der Fertigung. Dem Prinzip liegt die Verwendung von Karten zugrunde, die den Bedarf für die Produktion bestimmter Produkte oder Zwischenprodukte in angegebenen Mengen signalisieren.

Kanban für die Softwareentwicklung wurde von seinem Begründer David Anderson 2007 vorgestellt. Kanban für die Softwareentwicklung, kurz Software-Kanban, wird zu den leichtgewichtigen Vorgehensmodellen gezählt. Es setzt nicht auf den hohen Organisationsebenen an, sondern beschränkt sich auf die Fertigung, hier die Entwicklung von Software.

Software-Kanban versucht die Anzahl paralleler Arbeitsprozesse zu verringern und somit Engpässe zu vermeiden – oder drohende Engpässe frühzeitig zu signalisieren. Kanban soll also einen gleichmäßig fortschreitenden Geschäftsprozess absichern, weil erst abgeschlossene Prozesse, die das Ende der Wertschöpfungskette erreicht haben, einen Geschäftswert aufweisen. Mit der Vermeidung von Engpässen durch eine hohen Anzahl paralleler Arbeiten können Prozesse früher an dieses Ziel geführt werden.[28]

David Anderson fasste Kanban so zusammen:

“Value first, then flow, then waste reduction/elimination.”
(„Zuerst die Bewertung, dann der Fluss, dann Verminderung des Ballasts.“)

Die Bewertung ermittelt den Geschäftswert der Arbeit aus der Sicht des Auftraggebers. Der Wert steht bei Kanban im Vordergrund; Arbeit ohne Geschäftswert ist nicht erstrebenswert.

Der Fluss, der Arbeitsfortschritt, wird auf der Seite des Auftragnehmers gemessen. Der Fluss sollte gleichmäßig sein, darf aber zugunsten von Arbeiten mit höherem Geschäftswert aufgegeben werden.  Der Fluss kann durch die Auswertung von Messgrößen wie Work in Progress, Durchlaufzeiten und der mittleren Abschlussrate[29] überprüft werden.[30]

Als Ballast werden solche Störfaktoren bezeichnet, die den gleichmäßigen Arbeitsfluss verhindern.

Die Ziele von Kanban gehen jedoch weit über die Regulierung von Produktionsabläufen hinaus. So legt Kanban vier Prinzipien fest, in deren Kern es darum geht, sich „in kleinen Schritten, also evolutionär“ zu verbessern.[31] Diese vier Prinzipien sind:

1. Den Status quo schätzen. Auf den aktuellen Standpunkt des Unternehmens soll aufgesetzt werden, um es weiter zu verbessern.[32]
2. Kleine Schritte gehen. Das Team muss sich darüber im Klaren sein, dass keine große und schnell herbeigeführte Veränderung erwirkt werden soll. Vielmehr muss Einigkeit darüber bestehen, dass in kleinen Stufen vorangeschritten wird. Kleine Schritte werden eher akzeptiert und führen eher zu besseren Ergebnissen.[33]
3. Rollen beibehalten. Zu Beginn bestehende Rollen, Zuständigkeiten und Verantwortlichkeiten der Teammitglieder sollen im Laufe der Entwicklung nur behutsam verändert werden.
4. Entscheidungskompetenz auf allen Ebenen. Kanban verfolgt die Idee, Teammitgliedern Kompetenzen zuzusprechen. Es ermutigt Teams aber auch Individuen, selbst Entscheidungen zu fällen. Dies geht Hand in Hand mit situativer Führung, wenn also ein Mitarbeiter von sich aus eine Aufgabe übernimmt.[34]

Kanban gesteht den Teammitgliedern hohe Kompetenzen aber auch Individualität zu.

Markant für Kanban sind in der Industrie die Signalkarten. In der Softwareentwicklung taucht fast immer nur das Kanban-Board auf. Es besteht in der Regel aus den sechs Spalten Backlog, Eingeplant, In Entwicklung, Test, Auslieferung und Produktiv. Die Spalten spiegeln also den Lebenszyklus einer Softwarekomponente von ihrer Idee bis hin zur Auslieferung wieder.

Abbildung 3: Kanban-Board mit fünf Spalten (ohne Backlog).[35]

Die von Kanban angestrebte Transparenz wird durch die Sichtbarkeit eingeplanter Arbeiten erreicht. Engpässe werden schnell sichtbar, wenn die Spalte Entwicklung keinen freien Platz mehr hat.

4.3 V-Modell XT

Unter den vier am häufigsten genutzten Vorgehensmodellen ist das V-Modell XT das einzige schwergewichtige Modell. Anders als die agilen Spitzenreiter handelt es sich bei der V-Modell-Familie um Vorgehensmodelle, die für den Einsatz auf der organisatorischen Ebene vorgesehen sind und einen hohen Grad an. Das V-Modell, in seiner neusten Fassung als V-Modell XT bezeichnet, wurde ursprünglich für IT-Projekte des Bundes erdacht und ist seit dem Februar 2005 für alle IT-Projekte der deutschen Bundesbehörden verpflichtend einzusetzen.[36]

Das V-Modell XT ist ein „Vorgehensmodell für Vorgehensmodelle“[37] und damit ein Metamodell, das den Einsatz einer Vielzahl an Werkzeugen und die Integration anderer Vorgehensmodelle, beispielsweise agiler Modelle, ermöglicht. Es standardisiert Vorgehen und regelt die Zusammenarbeit zwischen Unternehmen und Behörden. Die V-Modell-Familie ist für den gesamten Lebenszyklus einer Software vorgesehen und verfolgt folgende Ziele:[38]

1. Minimierung von Risiken. Hierfür werden Vorgehensweisen vorgegeben und Rollen Verantwortlicher Instanzen festgelegt. Das Modell steht für Planungstransparenz und erlaubt daher eine frühzeitige Erkennung von Abweichungen im Terminplan.
2. Qualitätssicherung. Das V-Modell will mit standardisierten Prozessen, definierten Zwischenergebnissen und vereinheitlichter Produktinhalte bessere Überprüfbarkeit und die Erreichung einer erhöhten Qualität bewirken.
3. Kosteneindämmung. Die Anwendung eines standardisierten Vorgehensmodells erlaubt eine gute Einsicht in Entwicklung, Betrieb und Wartung eines Systems.
4. Verbesserung der Projektfähigkeit. Damit das Vorgehensmodell im Unternehmen gut eingesetzt werden kann, ist eine Zuschneidung (Tailoring) auf die Unternehmensstrukturen und -bedürfnisse notwendig. Diese Anpassung soll den langfristigen Einsatz des Modells möglich machen und das Unternehmen von dessen Vorteilen profitieren lassen.
5. Verbesserung der Kommunikation. Durch einheitliche Beschreibungen der relevanten Bestandteile wird ein einheitliches Verständnis bei Auftraggebern und -nehmern geschaffen. Dies beugt Missverständnissen und somit Hemmungen in der Projektumsetzung vor.

Bevor das V-Modell XT eingesetzt werden kann, muss es auf die Projektbedingungen zugeschnitten werden. Dieser Schritt ist maßgeblich entscheidend für den Erfolg durch den Einsatz des V-Modells. Unterstützung hierbei bietet eine Software, der V-Modell XT-Projektassistent.

Abbildung 4: V-Modell XT-Projektassistent als Hilfe beim Tailoring.[39]

Die Buchstaben „XT“ im Namen des Modells stehen übrigens für „Extreme Tailoring“, also „extremes Zurechtschneiden“.

Um die Qualität der zu entwickelnden Software zu sichern, setzt das V-Modell XT darauf, Rollen, Befugnisse, Kompetenzen und eine Aufbauorganisation festzulegen.[40] Hierbei muss auch die Hierarchische Gliederung erfasst werden.

In der Prozessorganisation werden die Zuordnungen von Rollen zu Aktivitäten, Berichtswege und die Beistellung von Finanz-, Sachmitteln und Wissen erfasst.[41]

4.4 Scrum

Scrum ist eines der leichtgewichtigen und somit agilen Vorgehensmodelle, das häufig mit anderen Entwicklungsmethoden einhergeht, weil es selbst, anders als etwa Software-Kanban oder Extreme Programming, keine Vorgaben zur Softwareentwicklung macht.

Der Name Scrum leitet sich vom englischen Wort für „Gedränge“ ab. Die Betitelung hat ihren Ursprung in einem Artikel in einem Fachmagazin, der das Verfahren mit einer Situation beim Rugbyspiel verglich.[42] Der Vergleich mit den Teamspielern wurde gewählt, weil bei Scrum kleine Teams, in denen jedes Mitglied im Wesentlichen alle Fähigkeiten hat, gute Software schneller als große Teams entwickeln kann.[43]

Scrum verlangt drei verschiedene Rollen: den Scrum Master, den Product Owner und den Entwickler. Die Größe des Scrum-Teams sollte sich auf sieben Personen belaufen.

Der Scrum Master ist Teil des Scrum-Teams, nicht aber des Entwicklungsteams. Er organisiert die Rahmenbedingungen.[44] Als Führungskraft ohne disziplinarische Verantwortung sorgt er für die Implementierung des Vorgehensmodells Scrum und ermöglicht es dem Team, ungestört zu arbeiten.[45]

Der Product Owner steuert das Scrum-Team aus fachlicher Sicht.[46] Er fällt Entscheidungen über die zu bearbeitenden Aufgabenpakete, legt aber nicht fest, wie entwickelt werden soll.[47] Er strebt die Umsetzung des Projektziels an und trägt die Verantwortung für die Wirtschaftlichkeit des Projekts. Der Product Owner pflegt das Product Backlog, die Einzelaufgaben des Projekts, und priorisiert diese nach Notwendigkeit.[48]

Das Entwicklerteam besteht aus Personen, von denen jedes Mitglied mehrere Aufgaben im Projekt übernehmen kann. Die Teammitglieder haben also selten ihre Spezialgebiete, sondern es wird angestrebt, dass sich jeder durch alle Bereiche bewegen kann. Das Team organisiert seine Aufgaben selbst, sie werden also nicht zugewiesen.[49] Durch das selbstständige Arbeiten wird die Leistungsfähigkeit des Teams erhöht.

Zu Beginn eines Projekts versammelt sich das Team zu einer Abschätzung. Hierbei werden Teilaufgaben beim Planning Poker in absolut messbarer Zeit, häufiger aber in Story Points geschätzt. Die schätzenden Teammitglieder sollen sich dabei nicht von anderen beeinflussen lassen. Als Ergebnis für eine Schätzung dient der Mittelwert aller Schätzungen. Bei großen Abweichungen kann sich das Team besprechen und die Schätzung wiederholen. Zum markantesten „Ritual“ von Scrum gehören die jeden Tag stattfindenden Besprechungen, Daily Scrum oder einfach nur Dailies genannt. In diesen kurzen Besprechungen erstatten die Entwickler vor dem gesamten Team Bericht über ihren Arbeitsfortschritt.

Scrum läuft in sogenannten Sprints ab. Dies sind feste Intervalle, an deren Ende ein Zwischenergebnis geliefert werden soll. Gängig ist eine Sprintdauer von einer Arbeitswoche, sodass ein Sprint vor dem Wochenende abgeschlossen werden kann.

5 Fazit

Die vorliegenden Studien zur Untersuchung der Anteile verschiedener Vorgehensmodelle in deutschen Unternehmen ließen bereits trotz der niedrigen Anzahl an Teilnehmern erkennen, dass ein deutlicher Trend hin zu den agilen Vorgehensmodellen und Entwicklungsmethoden  im Gange ist. Unter den am stärksten  vertretenen Vorgehensmodellen ist das V-Modell XT das  einzige als Metamodell taugliche, das die Integration anderer Modelle geradezu vorsieht.

Maßgeblich für den großen Zuspruch, die agile Methoden, insbesondere Scrum erfahren, ist die relativ einfache Integration und die damit erzielbaren Ergebnisse, weil besonders das  am stärksten vertretene Vorgehensmodell in Einzelfällen  Verbesserungen der Leistungsfähigkeit in Höhe von mehreren hundert Prozent[50] zur Folge hatte.

Scrum ist wohl auch deshalb so erfolgreich, weil es klare Vorgaben zum Projektmanagement, aber keine zur eigentlichen Softwareentwicklung macht. Vervollständigt werden kann Scrum in diesem Punkt zum Beispiel durch Software-Kanban. Die Kombination der beiden Vorgehensweisen  gibt Entwicklern relativ viele Freiheiten und führt dadurch sogar zu einer höheren Motivation im Team. Hinzu kommen die Rollen von Scrum Master und Product Owner, die keine Einmischung in die Arbeit des Entwicklerteams vorsehen und lediglich Vorgaben zur Zielerreichung  machen.

Abschließend lässt sich die Aussage treffen, dass Software-Unternehmen in Deutschland auch in Zukunft noch stärker auf leichtgewichtige Vorgehensmodelle setzen  werden und schwergewichtige Modelle, die für große Unternehmen geeignet sind, als Metamodelle dienen werden.

---

Einzelnachweise. Das vollständige Verzeichnis finden Sie hier.

[1] Scrum überlässt das Wie dem Entwickler.

[2] Friedrich et al. 2009, S. 1

[3] Hanser 2010, S. 3

[4] Epping 2011, S. 18

[5] Hanser 2010, S. 1

[6] Höhn 2008, S. 3

[7] Höhn 2008, S. 4

[8] Hanser 2010, S. 3

[9] Hanser 2010, S. 2-3

[10] Friedrich et al. 2009, S. 1

[11] Marco Kuhrmann 2015, S. 35

[12] Zahlen nach Marco Kuhrmann 2015, S. 37, vgl.: „Aufschlüsselung der Verwendung von Vorgehensmodellen in den befragten Unternehmen“ im Anhang.

[13] Marco Kuhrmann 2015, S. 44

[14] Martin Fowler 2003, S. 30

[15] Marco Kuhrmann 2015, S. 39

[16] Marco Kuhrmann 2015, S. 36

[17] Kuhrmann et al. 2011, S. 6

[18] Hanser 2010, S. 14

[19] Hanser 2010, S. 14

[20] Hanser 2010, S. 15

[21] Hanser 2010, S. 16

[22] Hanser 2010, S. 16-17

[23] extremeprogramming.com und

[24] Hanser 2010, S. 27

[25] extremeprogramming.com

[26] extremeprogramming.com

[27] extremeprogramming.com

[28] Epping 2011, S. 25

[29] Auch „Average Completion Rate“.

[30] Epping 2011, S. 105

[31] Arne Roock 2015, S. 322

[32] Arne Roock 2015, S. 322

[33] Arne Roock 2015, S. 323

[34] Arne Roock 2015, S. 324

[35] Epping 2011, S. 122

[36] Höhn 2008, S. ix

[37] Höhn 2008, S. 1

[38] Höhn 2008, S. 4

[39] Höhn 2008, S. 16

[40] Höhn 2008, S. 56

[41] Höhn 2008, S. 56

[42] Takeuchi und Nonaka 1986

[43] agilemanifesto.org

[44] Boris Gloger 2010, S. 196

[45] Boris Gloger 2010, S. 197

[46] Boris Gloger 2010, S. 196

[47] Boris Gloger 2010, S. 196

[48] Boris Gloger 2010, S. 198

[49] Boris Gloger 2010, S. 196

[50] Boris Gloger 2010, S. 196