Vergleich verschiedener Verfahren der agilen Softwareentwicklung

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Düsseldorf
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Prof._Dr._Uwe_Kern
Typ: Fallstudienarbeit
Themengebiet: Agile Softwareentwicklung
Autor(en): Mario Mainz , Florian Bosten, Adam Cholewa
Studienzeitmodell: Abendstudium
Semesterbezeichnung: SS11
Studiensemester: 2
Bearbeitungsstatus: begutachtet
Prüfungstermin:
Abgabetermin:


Inhaltsverzeichnis

1 Abkürzungsverzeichnis

Abkürzung Bedeutung
XP Extreme Programming
FDD Feature Driven Development

2 Abbildungsverzeichnis

Abb.-Nr. Abbildung
1Bleek (2008), Abb. 1: Projektablauf Scrum
2Wells (2010), Abb. 2: XP: Projektablauf
3Wells (2010), Abb. 3: XP: Iterationen
4Bleek (2008), Abb. 4: Projektablauf Feature Driven Development

3 Einleitung

Agile Softwareentwicklungsmethoden sind im Trend und kommen in immer mehr Firmen zur Anwendung. Ein Grund dafür ist die Flexibilität und der geringe bürokratische Aufwand gegenüber klassischen Verfahren. Es gibt jedoch eine Vielzahl von agilen Prozessen, welche sich unterschiedlich gut für verschiedene Projekttypen eignen und unterschiedlich schwer zu erlernen sind. Ziel dieser Fallstudie ist es, die Unterschiede sowie Vor- und Nachteile von verschiedenen Prozessen der agilen Softwareentwicklung aufzudecken und übersichtlich darzustellen. Um die konkreten agilen Prozesse erläutern und vergleichen zu können, müssen zuerst die Grundlagen und Werte der agilen Softwareentwicklung erklärt werden.

4 Agile Softwareentwicklung

4.1 Das agile Manifest

Ziel der agilen Softwareentwicklung ist es, einen Entwicklungsprozess agil, also flexibel und einfach zu machen. Der Fokus soll dabei auf technischen und sozialen Problemen während der Entwicklung liegen und ist damit ein Gegenstück zu klassischen Verfahren. Im Februar 2001 wurde das agile Manifest formuliert, welches die Grundlage für einen agilen Prozess bildet[1]. Die fünf Werte Kommunikation, Einfachheit, Feedback, Mut und Respekt bilden das Fundament und sind die agilen Werte[2]. Darauf basierend bilden Prinzipien die Handlungsgrundsätze. Agile Methoden bilden Verfahren während der Softwareentwicklung und die Zusammenfassung aller Methoden beschreibt den agilen Prozess.

4.2 Werte der agilen Softwareentwicklung

Die Modelle der agilen Softwareentwicklung basieren auf Werten. Diese haben einen ähnlichen Anspruch wie die Werte unseres moralischen Handelns. So wie die Gesellschaft sich an diesen Werten orientiert, so sollen auch alle Beteiligten eines Projektes nach diesen Werten handeln.

4.2.1 Kommunikation

In der agilen Softwareentwicklung hat direkte Kommunikation zwischen allen Projektbeteiligten einen sehr hohen Stellenwert. Dabei geht es nicht um möglichst viel Kommunikation, sondern um eine direkte und ehrliche Kommunikation, d. h. es soll im Optimalfall direkt miteinander gesprochen werden ohne dabei unangenehme Themen auszulassen[3].

4.2.2 Einfachheit

Der Wert Einfachheit bezieht sich auf die technische Umsetzung der Software und die Organisation. Die technischen Lösungen sollen so einfach wie möglich gehalten werden, da diese so leichter zu warten, zu erweitern und zu verstehen sind. Nach Möglichkeit soll ein Großteil der Verwaltung von Kunden und Entwickler erledigt werden, damit kein unnötiger Aufwand entsteht[4].

4.2.3 Feedback

Feedback wird benötigt, damit die Entwickler wissen, ob Ihre Arbeit den Anforderungen des Kunden genügt. In der agilen Softwareentwicklung werden bei vielen Methoden frühe und häufige Feedbacks angestrebt, um Ungleichheiten in Spezifikation und Umsetzung rechtzeitig zu erkennen[5].

4.2.4 Mut

Das Projektteam benötigt viel Mut, um die Werte, Prinzipien und Praktiken umzusetzen. Außerdem braucht es Mut, die vom Wert Kommunikation geforderte direkte und ehrliche Kommunikation umzusetzen[6].

4.2.5 Respekt

Ein respektvoller Umgang miteinander darf nie vergessen werden, da dies den ehrlichen und angstfreien Umgang miteinander fördert[7].

4.3 Prinzipien der agilen Softwareentwicklung

Viele Modelle der agilen Softwareentwicklung nutzen sogenannte Prinzipien, um die abstrakten Werte in die richtigen Bahnen zu lenken. Ohne Prinzipien wäre es beispielsweise möglich, den Wert "Kommunikation" so auszulegen, dass täglich ein vierstündiges Treffen abgehalten wird, um diesen Wert zu würdigen. Da dies aber nicht die Intention der Modelle ist, führen die meisten Modelle Prinzipien ein, um dies klarer zu definieren. Die Prinzipien bilden somit den Übergang zwischen den abstrakten Werten und den praxisorientierten Praktiken[8][9].

4.4 Praktiken der agilen Softwareentwicklung

Praktiken sind Arbeitsschritte und Methoden, die jeden Tag aufs Neue vom Projektteam angewandt werden. Ohne Werte würden die Praktiken zu einem lästigen Pflichtprogramm verkommen und den Sinn verfehlen. Mit ihnen zusammen manifestieren sie das, was getan werden muss, um das Projektziel im Sinne des Modells zu erreichen[10].

5 Agile Prozesse

5.1 Scrum

5.1.1 Allgemein

Bei Scrum handelt es sich um einen agilen Prozess, welcher sich an das Management eines Projektes richtet. Es wird zwar ein Projektablauf angegeben, jedoch werden keine Aussagen getroffen, wie die Programmierer die Software entwickeln sollen oder ob es sich beim Gegenstand des Entwicklungsprozesses überhaupt um Software handelt[11].

5.1.2 Rollen

Es gibt verschiedene Rollen, die während eines Projektes besetzt werden. Die drei wesentlichen Rollen in einem Scrum-Projekt sind: Product Owner, Scrum Master und das Team[11].

  • Product Owner
    Der Product Owner vertritt in einem Scrum-Projekt den Kunden und die Anwender in dem er Anforderungen formuliert, priorisiert und auswählt[11].

  • Scrum Master
    Der Scrum Master hat die Aufgabe, Product Owner und Team bei der Durchführung des Projektes und der Einhaltung des Scrum-Prozesses zu unterstützen. Er hilft außerdem bei konkreten Problemen. Der Scrum Master sollte nicht gleichzeitig Mitglied des Teams sein, da er sonst seiner Rolle als Vermittler nicht gerecht werden kann[11].

  • Team
    Das Team beschreibt in Softwareentwicklungsprojekten hauptsächlich die Softwareentwickler. Diese arbeiten eigenverantwortlich an der Umsetzung der Anforderungen. Welche Anforderungen in welcher Zeit erledigt werden, besprechen Sie zusammen mit dem Product Owner[11].

5.1.3 Projektablauf

Bleek (2008), Abb. 1: Projektablauf Scrum
Bleek (2008), Abb. 1: Projektablauf Scrum
5.1.3.1 Anforderungen

Anforderungen können von jedem Projektbeteiligten erstellt werden. Sie werden im so genannten Product Backlog festgehalten, welches alle Anforderungen enthält. Die hier gesammelten Anforderungen sind aber für das Team noch nicht relevant. Aus der großen Menge Anforderungen aus dem Product Backlog wählt der Product Owner eine geringere Menge für das Sprint Backlog aus[12].

Das Sprint Backlog enthält die Anforderungen für einen einzelnen Entwicklungszyklus. Ein Entwicklungszyklus wird in Scrum auch Sprint genannt. Der Product Owner entscheidet zwar, welche Anforderungen in das Sprint Backlog kommen, muss die Menge der Anforderungen jedoch mit dem Team absprechen, welches auch den Aufwand der Anforderungen bewertet[12].

5.1.3.2 Umsetzung

Die Vereinbarung, welche Anforderungen im nächsten Sprint umgesetzt werden, geschieht beim Sprint-Planning-Meeting. Anschließend kann der Sprint gestartet werden. Während eines Sprints arbeitet das Team frei von äußeren Einflüssen das Sprint Backlog ab. Im Laufe eines Sprints dürfen keine neuen oder geänderten Anforderungen ergänzt werden. Das Team handelt eigenverantwortlich und organisiert sich selbst. Weder Product Owner noch Scrum Master leiten das Team[13]. Die Abstimmung innerhalb des Teams findet im so genannten Daily Scrum statt. Das Daily Scrum ist ein Meeting, welches täglich zur selben Zeit am selben Ort stattfindet und maximal 15 Minuten dauern soll. Im Rahmen des Meetings soll jedes Teammitglied der Reihe nach drei Fragen beantworten:

  • Was habe ich seit dem letzten Daily Scrum getan?
  • Was werde ich bis zum nächsten Daily Scrum tun?
  • Was behindert mich?

Der Scrum Master ist bei den Daily Scrums anwesend und kontrolliert die Einhaltung dieser Regeln, damit das Daily Scrum auch wirklich nur 15 Minuten dauert. Verständnisfragen zu den Aussagen sind erlaubt, jedoch keine Diskussionen. Diese können anschließend an das Daily Scrum im Kreis der Betroffenen geklärt werden, um unbetroffene Mitglieder nicht unnötig festzuhalten[14].

5.1.3.3 Review

Am Ende eines jeden Sprints präsentiert das Team dem Product Owner das Ergebnis beim so genannten Sprint-Review. Hier ergeben sich eventuell neue oder geänderte Anforderungen, welche zunächst im Product Backlog aufgenommen werden. Sollten Anforderungen aus dem Sprint Backlog nicht innerhalb des Sprints erledigt worden sein, so wandern diese zurück in das Product Backlog. Das Team soll in solchen Fällen nun wissen, dass es den Aufwand der Anforderung oder seine eigene Geschwindigkeit falsch eingeschätzt hat. Der Sprint-Review soll so einen Lerneffekt erzeugen, durch den aus den Ereignissen des letzten Sprints über wertvolle Erfahrungen für alle zukünftigen Sprints reflektiert werden soll. Nachdem über die Ergebnisse des Sprints reflektiert wurde, beginnt in der Regel unmittelbar danach das nächste Sprint-Planning-Meeting[14].

5.1.4 Prinzipien

Bei der Einführung von Scrum sollten folgende vier Prinzipien umgesetzt werden[15].

  • Selbstorganisation
    Das Team führt den Sprint eigenständig durch und entscheidet selbst wie es arbeitet[16].

  • Pull-Prinzip
    Ausschließlich das Team entscheidet, wie viele Aufgaben aus dem Product Backlog es in einem Sprint umsetzt[16].

  • Timeboxing
    Zeiten werden bei Scrum klar definiert. Jedes Meeting und jeder Sprint hat eine klar vorgegebene Dauer, welche nicht geändert werden darf[16].

  • Nutzbare Business-Funktionalität
    Am Ende jedes Sprints muss eine funktionierende, den Standards, Richtlinien und Vorgaben des Auftraggebers gerecht werdende Software ausgeliefert werden[15].

5.2 Extreme Programming

5.2.1 Allgemein

XP (Extreme Programming) ist eine Praktikermethode, die versucht die Best Practices der Softwareentwicklung in ein Modell zu bringen. Entwickelt und maßgeblich geprägt wurde XP von Kent Beck, welcher auch einige Bücher darüber verfasste. Wichtig ist, dass die nachfolgenden Rollen, Prinzipien, Praktiken und Begleitpraktiken nicht verpflichtend sind, sondern dem jeweiligen Projekt angepasst werden, je nachdem wie es notwendig erscheint[17].

5.2.2 Rollen

Die Rollen in einem XP-Team sind nicht auf einzelne Personen festgelegt. Jeder führt die Tätigkeit aus, für die er am besten geeignet ist[18].

  • Coach
    Der Coach ist der Lehrer des Teams. Er hält die Mitglieder dazu an die Werte, Prinzipien und Praktiken einzuhalten Je erfahrener und besser das Team wird, desto unwichtiger ist diese Rolle[19].

  • Tester
    Die Tester kreieren mit den Anforderungen des Kunden die automatischen Tests für die Anwendung. Dabei werden vor allem kritische Stellen in den Fokus genommen[20].

  • Interaction Designer
    Interaction Designer unterstützen den Dialog zwischen Entwickler und Benutzer, indem sie die Benutzergeschichten zusammen mit dem Kunden erstellen und deren Verwirklichung kontrollieren[21].

  • Architekt
    Architekten sind für die innere Struktur eines Systems zuständig. Sie suchen nach großen Strukturverbesserungen und führen diese durch[22].

  • Projektmanager
    Der Projektmanager organisiert die Kommunikation zwischen XP-Team und Kunden. Weiterhin überwacht er den Fortschritt und plant weitere Schritte[23].

  • Geschäftsführung
    Die Geschäftsführung hat jederzeit das Recht, die Leistung des Teams einzusehen und Erklärungen zu fordern, da diese das Projektrisiko mitträgt[24].

  • Technischer Schreiber
    Der technische Schreiber beschreibt die Funktionen eines Systems für die Benutzer. Er steht dabei auch im Dialog mit den Nutzern, um ihre Erfahrungen aufzunehmen und sie in das Produkt einzuführen[25].

  • Anwender
    Anwender erstellen die Benutzergeschichten und damit die Anforderungen an das System. Der besondere Wert eines idealen Anwenders zeichnet sich dadurch aus, dass er Kontakt zu einem breiten Anwenderspektrum hat und sich mit ähnlichen Systemen auskennt[26].

  • Entwickler
    Die Entwickler programmieren das System und die Tests und übersetzen dabei die Benutzergeschichten in Programmfunktionen[27].

5.2.3 Projektablauf

Ein XP Projekt beginnt wie jedes Projekt damit, dass ein Projektteam zusammengestellt wird. Hierbei wird beispielsweise schon das Prinzip der Vielfalt, welches im weiteren Verlauf beschrieben wird, angewendet. Abbildung 2 verdeutlicht den weiteren Projektablauf. Der Anwender gibt in Form von Benutzergeschichten seine Anforderungen an das Team. Der Architekt macht einen ersten Entwurf. Dann werden die Releases geplant. Fortgefahren wird mit den Iterationen, die in Abbildung drei näher beschrieben sind. Das aktuellste Release wird danach noch einmal eingehend getestet und dabei erkannte Fehler behoben. Dieses Release wird dann an den Anwender gegeben.

Wells (2010), Abb. 2: XP: Projektablauf Wells (2010), Abb. 3: XP: Iterationen

5.2.4 Prinzipien

  • Menschlichkeit
    Dieses Prinzip bildet den Zusammenhang zwischen Privatleben und Arbeit. Gemeint ist damit, dass ein Teammitglied nicht um seinen Arbeitsplatz fürchten muss, in der Gesellschaft akzeptiert wird, sich mit dem Team identifizieren können muss und sein Privatleben durch das Projekt keinen Schaden annimmt. Sollte das nicht der Fall sein, kann der Mitarbeiter nicht effizient arbeiten[28].

  • Wirtschaftlichkeit
    Bei der Arbeit für das Projekt muss sichergestellt sein, dass die Tätigkeiten auch der Wirtschaftlichkeit des Projektes dienen[29].

  • Gegenseitiger Vorteil
    Jede Tätigkeit soll allen Beteiligten zu einem Vorteil verhelfen[30].

  • Selbstähnlichkeit
    Entwicklungsprozesse, die sich bewährt haben, sollen auch wiederkehrend eingesetzt werden[31].

  • Verbesserungen
    Es soll eine tägliche Verbesserung in der Arbeitsweise stattfinden. Es nützt nichts, darauf zu warten, dass die perfekte Arbeitsweise offenbart wird. Jeder muss sich von seinem Startpunkt ausgehend täglich verbessern[32].

  • Vielfalt
    Ein Team muss aus Personen mit verschiedenen Fähigkeiten zusammengestellt werden, damit gewährleistet ist, dass beispielsweise ein Problem von verschiedenen Perspektiven aus betrachtet wird[33].

  • Besinnung
    Das Team muss über die eigene Arbeitsweise und ihre Hintergründe nachdenken, Fehler analysieren und sich dadurch verbessern[34].

  • Fluss
    Ergebnisse des Projektes sollen in kleinen Paketen und in kleinen Zeitintervallen abgeschlossen werden[35].

  • Gelegenheit
    Probleme im Entwicklungsprozess sind als Chancen etwas zu ändern zu verstehen. Probleme sind nicht nur zu überstehen, sondern als Lektion aufzufassen, so dass sie zu einer nachhaltigen Verbesserung führen[36].

  • Redundanz
    An vielen Stellen sind in XP bewusst redundante Techniken zu verwenden, um Fehler zu vermeiden. So ist es möglich, dass ein Defekt, der bei einer Praktik nicht entdeckt wird, bei einer weiteren redundanten Praktik erkannt und behoben wird[37].

  • Fehlschlag
    Wenn nicht klar ist, welcher Weg zum Ziel führt, sollen alle Wege versucht werden. Selbst wenn alle Lösungsvorschläge fehlschlagen, wird ein Lerneffekt erzielt. So ist es oftmals sinnvoll das Risiko des Fehlschlags in Kauf zu nehmen, um ein Ziel zu erreichen[38].

  • Qualität
    Die Arbeit sollte immer in der größtmöglichen Qualität erledigt werden[39].

  • Babyschritte
    Änderungen sollen in kleinen Schritten passieren, so können Fehler frühzeitig erkannt werden. Außerdem kann das Projekt besser gesteuert werden, wenn frühzeitig erkannt werden kann, dass es in die falsche Richtung weiterentwickelt wird[40].

  • Akzeptierte Verantwortung
    Verantwortung muss von den Teammitgliedern selbstständig übernommen werden. Wenn ein Teammitglied einmal Verantwortung für eine Sache übernommen hat, ist es vom Anfang bis zum Ende zuständig dafür[41].

5.2.5 Praktiken

5.2.5.1 Primärpraktiken

Die Primärpraktiken führen zu einer sofortigen Verbesserung des Entwicklungsprozesses mit XP. Sie sind vom Grunde her für jedes Projekt geeignet[10].

  • Räumliches Zusammensitzen
    Das Entwicklungsteam sollte gemeinsam in einem Raum sitzen. Dabei muss darauf geachtet werden, dass genügend Privatsphäre gewahrt bleibt[42].

  • Vollständiges Team
    Ein Team widmet sich nur einem bestimmten Auftrag. Es ist nicht empfehlenswert, Teammitglieder gleichzeitig in verschiedenen Projekten einzusetzen und dabei ihre Arbeitszeit aufzuteilen, da zu viel Zeit dabei verloren geht, sich in das jeweilige Projekt neu einzudenken[43].

  • Informativer Arbeitsplatz
    Die Arbeit am Projekt soll sich am Arbeitsplatz widerspiegeln. Empfehlenswert sind hier Flipcharts, worauf aktuelle Probleme aufgeschrieben werden[44].

  • Energiegeladene Arbeit
    Die Teammitglieder dürfen sich nicht im Projekt aufreiben. Jeder sollte nur solange arbeiten, wie er auch effizient arbeiten kann[45].

  • Programmieren in Paaren
    Es soll zu zweit an einem Arbeitsplatz programmiert werden. Das hilft bei Blockaden und erinnert an das Einhalten der anderen Praktiken[46].

  • Benutzergeschichten
    In Benutzergeschichten werden die Anforderungen aus Sicht des Benutzers dargelegt[47].

  • Wochenzyklus
    In einem Wochenzyklus soll ein Meeting arrangiert werden, bei dem die Arbeitsschritte der nächsten Woche geplant werden[48].

  • Quartalszyklus
    Einmal pro Quartal soll ein größeres Meeting stattfinden, bei dem das letzte Quartal reflektiert wird und das nächste Quartal geplant wird. Im Vordergrund stehen hierbei große Ziele und Probleme[49].

  • Freiraum
    Es ist sinnvoll im Arbeitsplan Freiräume zu schaffen, damit Fehlschätzungen ausgeglichen werden können. Sollte am Ende einer Woche noch Arbeitszeit übrig sein, so kann diese für andere Anforderungen genutzt werden, die vielleicht noch nicht verlangt waren[50].

  • Zehn-Minuten-Build
    Alle zehn Minuten soll automatisch ein Build des gesamten Systems hergestellt und alle Tests durchlaufen werden[51].

  • Kontinuierliche Integration
    Das ständige Integrieren von Änderungen ist effizienter als das Integrieren großer Änderungen in einem Schritt[52].

  • Test-getriebene Entwicklung
    Bevor programmiert wird, muss ein automatischer Test kreiert werden, der funktionieren soll, wenn die Anforderung programmiert worden ist[53].

  • Inkrementeller Entwurf
    Der Entwurf der Software soll täglich an die aktuellen Anforderungen angepasst und so verbessert werden[54].

5.2.5.2 Begleitpraktiken

Diese Praktiken dienen dazu die Effekte der Primärpraktiken zu verstärken. Wenn eine der Begleitpraktiken sinnvoll erscheint, kann diese durchaus ausprobiert werden, jedoch muss man sich im Klaren darüber sein, dass die Primärpraktiken dafür die Grundvoraussetzung bilden[10].

  • Echte Kundenbeteiligung
    Der Kunde soll in das Team integriert werden[55].

  • Inkrementeller Einsatz
    Ein bestehendes System sollte schrittweise von einem neuen System abgelöst werden[56].

  • Teamkontinuität
    Gut funktionierende Teams sollten nach Möglichkeit nicht geteilt werden[57].

  • Schrumpfendes Team
    Sobald ein Teammitglied überflüssig geworden ist, kann es in anderen Projekten eingesetzt werden[58].

  • Ursachenanalyse
    Beim Entfernen eines Fehlers soll nicht nur der Fehler selbst, sondern auch die Ursache des Fehlers behoben werden, damit das Team einen Fehler dieser Art nicht noch einmal macht[59].

  • Gemeinsamer Quelltext
    Jedes Teammitglied kann jeden Teil des Quelltextes zu jeder Zeit editieren[60].

  • Quelltext und Tests
    Lediglich der Quelltext und die Tests, die noch wichtig für die Gegenwart oder die Zukunft sind, sollen gewartet und behalten werden[61].

  • Eine Quelltextbasis
    Es gibt nur eine Quelltextbasis mit der entwickelt wird. Private Datenbestände sollten nur für wenige Stunden gehalten werden[62].

  • Täglicher Einsatz
    Jeden Tag sollte die neue Software in die Auslieferung gelangen.[63]

  • Vertrag mit verhandelbarem Umfang
    Verträge sollten so abgeschlossen werden, dass genügend Raum für optionale Anforderungen vorhanden ist. Dabei ist zu differenzieren, welche Anforderungen unbedingt in dem gegebenen Zeitrahmen verwirklicht werden müssen und welche auch noch später angefügt werden können[64].

  • Zahlung pro Benutzung
    Den Kunden pro Benutzung zahlen zu lassen, garantiert dem Team eine bessere Rückmeldung über ihre Leistung. So kann es schneller auf etwaige Umsatzeinbrüche reagieren[65].

5.3 Feature Driven Development

5.3.1 Allgemein

FDD (Feature Driven Development) ist eine Methode zur Softwareentwicklung, bei der die zu entwickelnden Features einer Software im Vordergrund stehen. Sie unterscheidet sich vor allem darin von anderen Methoden, dass sie primär an Festpreisprojekte mit fixiertem Umfang adressiert ist[66].

5.3.2 Rollen

  • Chefarchitekt
    Die Aufgabe des Chefarchitekten ist es, ständig den Überblick über die Gesamtarchitektur der Software und der fachlichen Kernmodelle zu behalten. Er hat eine moderierende Rolle, da er zum Beispiel Unterstützung leistet, wenn Kunde und Entwickler zusammen ein Modell entwickeln. Bei kleineren Projekten muss der Chefarchitekt auch die Aufgaben des Chefprogrammierers übernehmen, da diese Rolle nur bei größeren Projekten besetzt wird[67].

  • Chefprogrammierer
    Bei größeren Projekten werden einzelne Entwicklerteams jeweils von einem Chefprogrammierer geführt. Deren Aufgabe ist es, die Feature-Listen zu erstellen, die einzelnen Features zu planen und diese zu entwerfen bzw. zu modellieren. Außerdem kann ein Chefprogrammierer eine Geschäftstätigkeit "besitzen" und somit für diese die Verantwortung tragen [68].

  • Projektleiter
    Der Projektleiter koordiniert die Ressourcenverteilung und Terminierung des Projektes und hat mit dem eigentlichen Prozess der Softwareentwicklung nur wenig Berührung[69].

  • Fachexperte
    Die Rolle des Fachexperten wird normalerweise durch den Kunden selbst erfüllt. Dieser hat das nötige Wissen und die nötigen Fähigkeiten in dem Kernbereich, in dem sich die zu entwickelnde Software ansiedelt. Da die Entwickler dieses Wissen oftmals nicht selbst haben, werden sie für Rückfragen gebraucht und in den Entwurfs- bzw. Modellierungsprozess mit einbezogen[70].

  • Entwickler
    Die Entwickler sind die eigentlichen Programmierer der Software. Sie sind hauptsächlich am Entwurfs- und Konstruktionsprozess beteiligt, wobei sie den Entwurf zusammen mit den Fachexperten und unter Leitung eines Chefprogrammierers oder des Chefarchitekten durchführen. Außerdem werden bei der Planung den bekannten Kernklassen Entwickler als Besitzer zugeordnet, welche dann für diese die Verantwortung tragen[68].

5.3.3 Projektablauf

Bleek (2008), Abb. 2: Projektablauf Feature Driven Development
Bleek (2008), Abb. 2: Projektablauf Feature Driven Development
5.3.3.1 Allgemein

Die Entwicklung bei FDD wird anhand eines Feature Plans organisiert. In jedem Projekt werden zur Umsetzung die folgenden fünf Teilschritte durchlaufen:

  • Erstelle das Gesamtmodell
  • Erstelle die Feature Liste
  • Plane je Feature
  • Entwirf je Feature
  • Entwickle je Feature

Im Folgenden werden diese Teilschritte ausführlicher erörtert[71].

5.3.3.2 Erstelle das Gesamtmodell

In diesem Schritt wird der Gesamtumfang und Inhalt des zu entwickelnden Systems von Fachexperten und Entwicklern zusammen definiert. Der Chefarchitekt führt die beiden Gruppen bei diesem Prozess. Die gemeinsame Arbeit von Chefprogrammierern und Kunden am Modell der Software löst einen wechselseitigen Lernprozess aus, durch den das fachliche Wissen in einer leicht verständlichen, ggf. grafischen Art und Weise festgehalten wird[72].

5.3.3.3 Erstelle die Feature Liste

In diesem Teilprozess werden die im vorherigen Teilprozess definierten Systembereiche von den Chefprogrammierern in Features formuliert. Diese Formulierung folgt einem dreistufigen Schema: Fachgebiete bestehen aus Geschäftstätigkeiten, die durch Schritte ausgeführt werden. Die Schritte entsprechen dann den Features. Die Fachgebiete sind meistens sehr schnell festgelegt, da sie nur sehr grob einen Funktionsbereich einer Software beschreiben. Geschäftstätigkeiten beschreiben die in den Fachgebieten enthaltenen Aufgabengebiete. So kann z. B. ein Fachgebiet "Verkauf" sein und eine darin enthaltene Geschäftstätigkeit z. B. Angebotserstellung. Die konkreten Features werden anschließend nach dem Schema "<Aktion> <Ergebnis> <Objekt>" aufgeschrieben, z. B. "Berechne Gesamtsumme der Verkäufe". Die Realisierung jedes Features darf maximal zwei Wochen benötigen. Das Ergebnis dieses Teilprozesses ist eine kategorisierte Feature-Liste, deren Kategorien von den Fachexperten aus Phase 1 stammen[73].

5.3.3.4 Plane je Feature

In diesem Prozess definieren Projektleiter, Entwicklungsleiter und Chefprogrammierer die Reihenfolge der Realisierung von Features. Kriterien bei der Bestimmung der Reihenfolge sind die Abhängigkeiten zwischen Features, die Komplexität der Features und die Auslastung des Entwicklerteams. Aufgrund dieser Reihenfolge werden anschließend die Fertigstellungstermine für die Geschäftstätigkeiten festgelegt. Jeder der Geschäftstätigkeiten wird ein Chefprogrammierer als Besitzer zugeordnet. Für die schon bekannten Kernklassen werden Entwickler als Besitzer festgelegt[74].

5.3.3.5 Entwirf je Feature

Auf Basis des Klassenbesitzes werden die Features nun von den Chefprogrammierern den Entwicklerteams zugewiesen. Diese erstellen zuerst Sequenzdiagramme der Features, welche vom Chefprogrammierer zur Verfeinerung der Klassenmodelle genutzt werden. Anschließend schreiben die Entwickler die ersten Klassen- und Methodenrümpfe, welche dann inspiziert werden. Treten fachliche Unklarheiten auf, werden die Fachexperten zur Klärung hinzugezogen[74].

5.3.3.6 Entwickle je Feature

Dieser Teilprozess beinhaltet nun die endgültige Implementierung der im vierten Teilprozess vorbereiteten Features. Zusätzlich finden Komponententests und Quelltextinspektionen zur Qualitätssicherung statt[74].

5.3.4 Best Practices

Best Practices sind Erfolgsmethoden und bezeichnen Praktiken oder Vorgehensweisen im Unternehmen um einen gewissen Standard einzurichten und zu halten.

  • Domain Object Modelling
    Modellierung der Software

  • Developing by Feature
    Korrekte Definition der Features -> <Aktion> <Ergebnis> <Objekt>

  • Class Ownership
    Jede Klasse hat einen Besitzer

  • Feature Teams
    Features in Teams entwickeln

  • Inspections
    Code und Design muss vom Chefprogrammieren genehmigt werden

  • Configuration Management
    Versionskontrolle von Code, Dokumente, etc.

  • Regular Build Schedule
    Regelmäßig eine laufende Version erstellen

  • Visibility of Results
    Fortschritt des Projekts erkennbar machen

6 Unterschiede agile Prozesse

6.1 Kriterien

6.1.1 Projekttyp

Betrachtet man den Projekttyp bei agilen Prozessen, so stellen sich bei allen Prozessen wesentliche Unterschiede heraus. Das Gesamtmodell von FDD ist ein Festpreisprojekt mit einem vereinbarten Funktionsumfang und Fertigstellungsdatum[66]. Dadurch ermöglicht es eine übersichtliche Auflistung aller Features, welche Teil des Vertrages sind und somit die Kennzahlen Budget und Zeit vorgeben. Beim Modell XP entfällt eine komplette Auflistung aller Anforderungen. Es baut darauf auf, dass mit dem Kunden ein Vertrag mit einem festen Budget und mit einem verhandelbarem Umfang von Features vereinbart wird[75]. Innerhalb des Budget- und Zeitrahmens wird das Projekt umgesetzt, wobei so viele Features entwickelt werden, wie machbar sind. Hier kann die Situation auftreten, dass eventuell benötigte Features nicht entwickelt und ausgeliefert werden, sondern erst einen Folgeauftrag benötigen. Bei Scrum liegt der Unterschied darin, dass dieser Prozess einen allgemeinen Managementrahmen für beliebige Projekte bildet[11]. Somit soll Scrum nicht nur für Softwareprojekte genutzt werden können, sondern auch für anderweitige Projekte. Desweiteren gibt es bei Scrum kein von Beginn an festgesetztes Fertigstellungsdatum. Die Entwickler geben lediglich an, wie viele Einheiten sie pro Iteration entwickeln können und bestimmen dadurch das Zeitmanagement der Entwicklung[76]. Somit hat Scrum, wie auch XP einen auf den Kunden zugeschnittenen Funktionsumfang, der immer wieder angepasst werden kann.

6.1.2 Rollen

Scrum, XP und FDD enthalten alle zunächst weitgehend ähnliche Rollen. So existiert in jedem agilen Prozess eine moderierende Rolle, nämlich der Chefarchitekt in FDD, der XP Coach und der Scrum Master. Die Kundenanforderungen werden in XP durch den Kunden[77], den Product Owner bei Scrum[11] oder die Fachexperten in FDD vertreten[72]. Weiterhin gibt es Entwickler (XP und FDD) und ein Team (Scrum), welche für die Umsetzung zuständig sind. Ein Unterschied liegt in der zusätzlichen Rolle des Projektmanagers in FDD und in XP. Dieser ist für Projektmanagementaufgaben verantwortlich wie z. B. die Ressourcenverteilung und das Zeitmanagement[78][79]. Bei Scrum wird das Zeitmanagement auf den Product Owner und das Team verteilt, indem Ersterer für den Release-Plan und Zweiteres für das Sprint Backlog verantwortlich ist. Das Team entscheidet selbstständig und ohne Einflüsse von außen über den Aufwand eines Features und die Anzahl der zu bearbeitenden Features in einem Sprint[76].

Für den Bereich Qualitätsmanagement wird die Rolle des Testers explizit nur in XP und FDD benannt[78][80]. Beide Prozesse sehen den Tester als einen Fachexperten auf seinem Gebiet, welcher ausschließlich das Produkt nach Qualitätsmerkmalen prüft und verifiziert. Bei Scrum wird das Testen der Rolle "Team" zugesprochen und wird von den Entwicklern ausgeübt.

Bei FDD werden neben den benötigten Rollen Chefarchitekt, Fachexperte und Entwickler noch eine Vielzahl von zusätzlichen und unterstützenden Rollen angeboten. Der Deployer bereitet z. B. die Datenübernahmen von Altsystemen vor und der Tester verifiziert die Software. Für die Entwicklung des Benutzerhandbuchs ist der Scriber zuständig. Während der Release-Manager den Fortschritt des Projekts kontrolliert, organisiert der Build-Manager die Zusammenführung der einzelnen Teilprogramme. Die Rolle Domänenexperte stellt den Kunden oder Anwender dar, welcher sein Wissen über die zu entwickelte Software an die Programmierer weitergibt. Für technisches Know-How ist der Programmiersprachen-Guru zuständig und für die Hardware- und Software der Systemadministrator. Der Toolsmith entwickelt kleinere Tools für die tägliche Arbeit. Neben dem bereits erwähnten Chefarchitekten gibt es die Managerrollen Projektmanager und Entwicklungsmanager. Der Projektmanager ist für die Finanzen, Zeitplan und Ressourcen verantwortlich. Der Entwicklungsmanager plant mit dem Produktmanager die Ressourcenverteilung für die Entwickler. Für die Programmierung setzt FDD unbedingt die Rolle des Klassenbesitzers voraus. Bei mehreren Teams werden Chefprogrammierer eingesetzt[81].

Während FDD auf eine detaillierte und strukturierte Rollenverteilung setzt, setzen Scrum und XP auf Einfachheit und Übersichtlichkeit, indem nur eine benötigte und kleine Anzahl von Rollen definiert werden. Scrum bietet neben den bereits erwähnten und unbedingt vorhandenen Rollen Product Owner, Scrum Master und Team noch die zusätzlichen Rollen Kunde, Anwender. Der Kunde ist der Geldgeber des Projektes und wird im Scrum-Prozess durch den Product Owner vertreten[82]. Dadurch findet eine Schwächung des Kunden statt, da der Product Owner nicht vom Kunden selbst gestellt wird, sondern vom Unternehmen, welches das Projekt umsetzt bzw. die Projektverantwortlichkeit hat. Der Anwender ist der typische Benutzer der Software[82]. In XP müssen die Rollen Kunde, Entwickler und XP-Coach vorhanden sein. Weitere unterstützende Rollen sind der Projektmanager, Tester, Architekt, Interaction Designer und technischer Schreiber.

Eine Gemeinsamkeit bilden der Interaction Designer und der technische Schreiber in XP mit dem Scriber in FDD. Diese zusätzliche Rolle soll für den Kunden eine Unterstützung und gleichzeitig verantwortlich für die Beschreibung der Features sein.

Anzumerken ist, dass die Rolle eines übergeordneten Managers, eines Produktmanagers, Entwicklungsmanagers und Systemadministrators in jedem agilen Prozess vorkommen kann, nur mit unterschiedlichen Rechten und Funktionen versehen sein kann. Das sind sogenannte zusätzliche Rollen, die ein Unternehmen bereits haben kann, aber nicht haben muss.

Eine genaue Unterscheidung der wichtigen Rolle "Kunde" und "Entwickler" findet in den nachfolgenden Abschnitten statt.

6.1.3 Kunde

Bei XP gilt, dass der Kunde durch Erstellung der Anforderungen einen hohen Verantwortungsgrad hat. Zudem bestimmt der Kunde die Reihenfolge der Features, in der sie entwickelt werden[77]. Während der Entwicklungsphase steht der Kunde den Entwicklern direkt zur Verfügung und nimmt mit seinem Feedback Einfluss auf die Entwicklung[77]. Bei einer wöchentlichen Iteration kann sich der Kunde zudem vom Fortschritt überzeugen lassen und Einfluss auf die Entwicklung der nachfolgenden Iteration nehmen. Der XP-Kunde ist somit stetig am Projektablauf involviert, was von Vorteil, aber auch ein von Nachteil sein kann.

Der Scrum-Kunde ist der Auftraggeber oder Käufer des Projekts. Er arbeitet mit dem Product Owner zusammen, hat jedoch wenig Einfluss auf die Entwicklung und meist keinen Kontakt zum Entwicklerteam. Der Product Owner übernimmt stattdessen die Formulierung, Priorisierung und Festlegung der Reihenfolge der Features. In einem Softwareentwicklungsprojekt vertritt er somit den Kunden und die Anwender[11]. Während eines Projekts hat der Kunde meist wenige Informationen zum Fortschritt der Entwicklung, da Scrum einen Product Backlog verwendet, welcher nach und nach mit Features gefüllt wird. Die Auswahl der Features wird vom Product Owner in Abhängigkeit vom Entwicklerteam getroffen, wodurch dem Kunden nicht ersichtlich wird, welche Features in welchem Zeitraum entwickelt werden[12]. Auch ein Fertigstellungsdatum der Software ist evtl. zu Beginn eines Projekts dem Kunden nicht bekannt. Scrum ist somit ein Gegensatz zu XP und zielt auf eine geringe Beteiligung des Kunden hin. Die Verantwortung liegt bei Team und Product Owner, weniger beim Kunden.

FDD verfolgt wie Scrum zu Beginn eine enge, und mit weiterem Projektverlauf eine geringere Zusammenarbeit mit dem Kunden. Es wird innerhalb von zwei bis drei Wochen mit dem Kunden, den Entwicklern und dem Chefarchitekten ein Gesamtmodell mit einer Liste aller Features, Kosten und Aufwandseinschätzungen des Projekts entwickelt[83]. Aus diesem Grund muss man bei FDD davon ausgehen, dass der Kunde nach der Entwicklung des Gesamtmodells einen Überblick über das Projekt und somit einen konkreten Kenntnisstand hat[84]. Somit entfällt während der Entwicklungsphase ein intensiver Kontakt zum Kunden. Während des Projekts ist die Kommunikation mit den Verantwortlichen wie z. B. den Entwicklern erlaubt, aber nur noch in Einzelfällen relevant, weil in FDD davon ausgegangen wird, dass die Entwicklungsphase schon einen recht detaillierten Informationsstand hat[85]. Ein weiterer Unterschied in FDD ist die Priorisierung der Features. Dies übernimmt im Gegensatz zu Scrum und XP nicht der Kunde, sondern der Projektleiter mit dem Entwicklungsleiter und dem Chefprogrammierer[74].

6.1.4 Moderierende Rolle

Eine Gemeinsamkeit bei Scrum, FDD und XP ist, dass jeder dieser Prozesse eine moderierende Rolle definiert. So gibt es in FDD den Chefarchitekten, welcher die Gesamtverantwortung für ein Projekt hat. In Scrum übernimmt der Scrum Master die Teamintegration und ist für das Verständnis des Prozesses zuständig. XP benennt dazu den XP Coach.

Ein Unterschied ist der Vorgesetztenstatus. So ist der Scrum Master kein direkter Vorgesetzter[86]. Auch der XP Coach ist nicht als direkter Vorgesetzter zu sehen, da die Hauptaufgaben der Entwicklung und die Verantwortung für ein Projekt beim Team liegen. Der Chefarchitekt in FDD ist dagegen als ein Vorgesetzter definiert.

Ein weiterer Unterschied ist der Aufgabenbereich der moderierenden Rollen. Der Chefarchitekt ist der Planer des Projekts und nimmt somit am Aufbau und am Projekt teil[66]. Scrum Master und XP Coach sind ebenfalls in das Projekt eingebunden, jedoch als Unterstützung und nicht als Entwickler oder mit Planungsfunktionen vorgesehen. Ihre Hauptaufgabe liegt darin, die einzelnen Entwickler in die Rolle des jeweiligen agilen Prozesses einzubinden[86][87].

6.1.5 Entwickler / Team

Die Verantwortlichkeit und der Aufwand der Entwicklerteams für ein Projekt sind bei den agilen Prozessen unterschiedlich geregelt. Scrum verfolgt die Strategie, dass die Entwickler im Gegensatz zu XP ohne Störung entwickeln können. Das Team handelt eigenverantwortlich, organisiert sich selbst und hat mit dem Scrum Master oder Product Owner keinen direkten Vorgesetzten. Der Scrum Master hat keine weisungsbefugte Funktion, ist jedoch dafür zuständig, dass der Scrum-Prozess eingehalten wird[86]. Die Entwickler sind zu Beginn eines Projekts an den Anforderungen beteiligt und arbeiten anschließend und ungestört von äußeren Einflüssen im Team den Sprint Backlog ab. Zusätzliche Features bzw. Change Requests werden nicht im Laufe eines Sprints ergänzt[14]. Kunden, Anwender und Product Owner haben deshalb während der Entwicklungsphase nur bedingt Kontakt mit den Entwicklern. Der Scrum Masters kann Teil des Teams sein und bietet Hilfestellung bei auftauchenden Problemen. Die Aufwandseinschätzungen übernehmen die Entwickler selbst, wodurch sie in der Lage sind, den Zeitraum für ein Projekt selbst zu bestimmen[76]. Zudem findet täglich ein 15 minütiges Scrum-Meeting unter Aufsicht des Scrum Masters statt. Jedes Teammitglied erläutert kurz, was es bisher entwickelt hat, was seine Probleme waren und was seine Ziele bis zum nächsten Meeting sind[66]. Der Quellcode kann von jedem Entwickler genutzt werden.

In FDD erfolgt nach der Planung des Gesamtmodells eine Zuteilung der Features vom Chefarchitekt bzw. Chefprogrammierer an die Entwickler, wobei Klassenbesitzer festgelegt werden können. Jede Klasse hat einen Klassenbesitzer, welcher als Einziger das Recht hat, den Quellcode zu verändern. Chefarchitekt und Chefprogrammierer sind als Vorgesetzte zu betrachtetn und geben ihre Anweisungen an die Entwickler weiter, wodurch den Entwicklern Verantwortung entnommen wird. FDD ist somit ein agiler Prozess, der für Entwickler eine feste Struktur bei der Entwicklung und einen festen Zeitplan bedeutet. Scrum und XP sind aufgrund des Projektablaufs mehr variabel gestaltet. Einen Coach gibt es in FDD nicht. Eine Zusammenarbeit mit dem Kunden besteht wie bei Scrum nur im Vorfeld bei der Planung des Projekts. Im Anschluss ist die Kommunikation nur noch im Ausnahmefall gestattet[85].

Bei XP ist der Aufgabenbereich im Gegensatz zu Scrum und FDD umfangreicher, weshalb der Entwickler den wichtigsten Part darstellt. Er entwickelt eigenverantwortlich, macht die Builds und die Aufwandseinschätzungen, ist für das Design verantwortlich und übernimmt die direkte Kommunikation mit dem Kunden[75]. Auch die Tests werden vom Entwickler ausgeführt, wenn keine zusätzliche Rolle „Tester“ vorgesehen ist. Der XP-Entwickler benötigt somit zusätzlich zum Fachwissen auch soziale Kompetenzen wie Kommunikations-, Konflikt- und Kritikfähigkeit. Alle Projektmitglieder sollen zudem 100% ihrer Arbeitszeit in einem Projekt verbringen, wodurch Teamkontinuität gewährleistet werden soll[88]. Wie in Scrum, kann der Quellcode von jedem Entwickler genutzt werden. Der XP Coach unterstützt neue Entwickler im Team. Der XP-Entwickler handelt somit wie der Scrum-Entwickler eigenverantwortlich, hat jedoch aufgrund der Zusammenarbeit mit dem Kunden einen größeren Verantwortungsgrad.

6.1.6 Projektablauf

Da Scrum sich nicht implizit auf Softwareentwicklung bezieht, ist der Projektablauf allgemein zu verstehen. Scrum sieht einen Product Backlog vor, welcher zunächst alle Anforderungen sammelt. Anschließend werden bestimmte Anforderungen vom Product Owner für einen Sprint Backlog ausgewählt. Die Sprints sind immer gleich und können bis zu 30 Tage dauern. Während eines Sprints entwickelt dann das Team die Features und am Ende des Sprints werden diese Features dem Product Owner präsentiert. Anschließend wird der nächste Sprint geöffnet. Dieser Zyklus wiederholt sich, bis das Projekt abgeschlossen ist.

Einen ähnlichen Ablauf bietet XP, jedoch mit dem Unterschied, dass der Kunde mehr eingebunden wird. Der Kunde wählt grob Anforderungen aus, die im ersten Release vorhanden sein sollen. Ein Release dauert bei XP je nach Aufwand bis zu 3 Monate. Anschließend schätzen die Entwickler die Features ein und geben dem Kunden ein Feedback. Der Kunde wählt nun anhand der Schätzungen die Features genauer aus und entscheidet, mit welchen Anforderungen begonnen werden soll. Dabei wählt er immer eine Iteration von einer Woche für die Entwicklung aus. Der Wochenrhythmus wird bis zum Release-Ende eingehalten. Nach jeder Iteration findet eine Präsentation für den Kunden statt, wodurch aufgrund des Kunden-Feedbacks die nächste Iteration geplant werden kann.

Der Projektablauf setzt somit in XP mehr auf die Kompetenz und Einbindung des Kunden als bei Scrum oder FDD. Zudem muss das Team geübt sein, einen hohen Wissensschatz besitzen sowie über soziale Kompetenzen verfügen, da die Entwickler regelmäßig mit dem Kunden zusammenarbeiten und eigenverantwortlich arbeiten ohne einen direkten Chefprogrammierer zu haben. Der Verantwortungsgrad der Entwickler bei Scrum und FDD ist vergleichsweise niedriger.

FDD geht im Vergleich zu Scrum oder XP einen anderen Weg. Bei FDD findet eine konkrete Planung statt, einschließlich einer Komplettanforderung aller Features zu Beginn eines Projekts, auch wenn diese noch nicht detailliert sind. FDD besteht aus einem Feature-Plan, welcher wiederum aus fünf Teilprozessen besteht. Im ersten Teilprozess wird unter der Leitung des Chefarchitekten sowie mit den Fachexperten und Entwicklern ein Gesamtmodell erstellt. In dem Gesamtmodell ist zunächst nur der zu entwickelte Inhalt und Umfang enthalten. Aus dem Gesamtmodell kann dann im zweiten Teilprozess eine detaillierte Feature-Liste erstellt werden. Der dritte Teilprozess enthält die Reihenfolge, in der die Features realisiert werden sollen. Im vierten Teilprozess werden je Feature die Klassen- und Methodenrümpfe entworfen, welche anschließend im letzten Teilprozess in ein fertiges Feature programmiert werden. Man geht bei einer Gesamtprojektlänge von sechs Monaten davon aus, dass die Phasen eins und zwei ca. zwei bis drei Wochen in Anspruch nehmen. Die Entwicklung des Klassenrumpfs sowie des Features selbst dauert ca. zwei Wochen. Während in FDD jede Klasse einen Besitzer enthält (Class-Ownership), werden bei Scrum oder XP keine derartigen Zuständigkeiten verteilt. Der Quellcode liegt im Zuständigkeitsbereich des gesamten Teams (Collective-Ownership).

Die drei agilen Prozesse haben genaue zeitliche Vorgaben und somit einen Entwicklungsrhythmus. Der Unterschied liegt jedoch darin, dass FDD von Beginn an alle Anforderungen kennt, auch wenn nicht detailliert. Somit lässt sich auch ein Gesamtmodell für ein Projekt erstellen und ein Fertigstellungsdatum für den Kunden ermitteln. Bei Scrum und XP wird dagegen in einem Zyklus dynamisch entschieden, welche Anforderungen als nächstes entwickelt werden. Dadurch besteht die Möglichkeit, auch neue Anforderungen mit aufzunehmen, was in FDD nicht so einfach ist, da Fertigstellungsdatum und Budget in Gefahr wären. Scrum und XP sind somit dynamischer aufgebaut.

Weitere Unterschiede finden sich in der Iteration und in der Planung der Anzahl der zu entwickelnden Features wieder. Während bei FDD je Feature geplant und entwickelt wird, werden bei Scrum und XP mehrere Features / Themenbereiche gleichzeitig freigegeben und entwickelt. FDD sieht je Komplexität eine Entwicklungszeit von bis zu zwei Wochen pro Feature vor[84]. Dagegen arbeitet Scrum mehrere Features oder Themenbereiche in einem Zeitraum bis zu 30 Tagen ab[89].

Die Iteration in XP ist in einem Wochenrhythmus und Quartalsrhytmus aufgeteilt[90]. Je nach Aufwand dauert ein Release bis zu drei Monate. Eine Woche ist genug Zeit für Planung, Entwicklung und Kunden-Feedback. Scrum verwendet einen Rhythmus zwischen einer Woche und 30 Tagen.

6.1.7 Anforderungen / Features

XP bietet die Möglichkeit, dass Anforderungen in Form von Benutzergeschichten (engl. User-Story) festgehalten werden. Eine Geschichte ist eine kurze Beschreibungsform, welche die Funktionsanforderungen aus der Sicht des Anwenders wiedergibt. Dabei ist zu beachten, dass eine Beschreibung so aufgebaut sein muss, dass sie innerhalb einer Iteration von den Entwicklern abgearbeitet werden kann[91]. In XP wird jedoch nicht näher spezifiziert, ob der Kunde oder der Entwickler für die Geschichten-Entwicklung zuständig ist[90]. Geht man davon aus, dass Anforderungen auch ohne Benutzergeschichten spezifiziert werden können, so hat der Kunde die Verantwortlichkeit für die Erstellung und Priorisierung[77].

Der Interaction Designer sowie der technische Schreiber helfen in XP dem Kunden und Anwender bei der Erstellung der Benutzergeschichten bzw. bei der Beschreibung der Features. In FDD übernimmt dies der Scriber. Diese Rollen sind zusätzliche Rollen und sind bei Scrum nicht vorgesehen.

Beim Scrum-Prozess werden die Features von allen Projektbeteiligten wie z. B. den Entwicklern, andere Entwicklerteams, Product Owner und Anwender erstellt, wodurch mehr Personen Verantwortung übernehmen als in XP. Der Anwender soll dabei mit seinem Fachwissen eine wichtige Unterstützung und Hilfe sein[92]. Angeführt vom Product Owner, stellt dieser zunächst sein Ziel vor. Anschließend werden aus den ungenauen Product Backlog Items von den Teammitgliedern detaillierte Anforderungen aufgeschrieben. Das Aufschreiben der Anforderungen soll den Teammitgliedern ein besseres Verständnis über das eigene Produkt liefern[93]. Eine Priorisierung ist dabei nicht zwingend erforderlich[12].

Bei FDD werden die Anforderungen zunächst allgemein und in grober Form mit den Fachexperten, Entwicklern und unter der Leitung des Chefarchitekten definiert[72]. In kleineren Gruppen wird anschließend näher auf einzelne Bereiche eingegangen. Ziel ist es, zunächst ein Gesamtmodell zu entwickeln. In einem zweiten Prozess werden die Anforderungen vom Chefprogrammierer detailliert und im Schema <Aktion> <Ergebnis> <Objekt> aufgeschrieben[73]. Im dritten Teilprozess wird vom Projektleiter, Entwicklungsleiter und Chefprogrammierer die Priorisierung festgelegt[72].

FDD verfolgt einen gezielten und strukturierten Ablauf. Kunden und Anwender werden nur zu Beginn mit einbezogen. Die endgültige Definition der Anforderungen und die Priorisierung übernehmen die Projektverantwortlichen. Im Gegensatz dazu setzt XP auf den Kunden. Scrum ist der agile Prozess, der sich zwischen XP und FDD befindet. Kunden, Anwender, Entwickler und weitere Teammitglieder werden in den Prozess der Anforderungserstellung mit einbezogen.

Alle drei Prozesse verwenden für die Spezifikation von Anforderungen kein Pflichtenheft, sondern eine spezielle Beschreibungsform. So verwendet XP Benutzergeschichten, Scrum kurzgefasste Product Backlog Items und FDD das Schema <Aktion> <Ergebnis> <Objekt>.

6.1.8 Aufwandsschätzungen

Sowohl bei Scrum als auch bei XP und FDD übernehmen die Entwickler die Aufwandseinschätzungen. Bei XP wählt zunächst der Kunde aus, welche Features für die kommende Iteration entwickelt werden sollen und die Entwickler schätzen dann den Aufwand[77]. Bei Scrum wählt der Product Owner die zu entwickelnden Anforderungen für einen Sprint aus, ist dabei aber von den Schätzungen der Entwickler abhängig[12]. FDD nennt zwar nicht inplizit, wer die Aufwandsschätzungen machen soll, jedoch kann man davon ausgehen, dass es im zweiten Schritt "Erstelle die Feature-Liste" vom Entwickler erfolgt bzw. Chefprogrammierer oder Chefarchitekt führen eine Kontrolle durch.

6.1.9 Meetings

Bei Scrum sind folgende Meetings vorgesehen:

  • Daily Scrum – Koordinieren und Feedback
  • Sprint Planning Meeting 1 – Anforderungen klären
  • Sprint Planning Meeting 2 – Design und Planung
  • Estimation Meeting – Vorausplanen und Schätzen
  • Sprint Review – Resultate präsentieren
  • Sprint-Retrospektive – sich ständig verbessern

Scrum ist ein Prozess, der aus der Zusammenarbeit aller Projektbeteiligten besteht. So werden direkt im Sprint Planning Meeting 1 vor dem Entwicklungsstart die Product Backlog Items definiert und das Ziel für den ersten Sprint erarbeitet. Anwesend sind neben dem Product Owner und Scrum Master auch die Anwender und die Entwickler[82]. Sprint Planning Meeting 2, Estimation Meeting, Sprint Review und Daily Scrum sind Meetings, die sich auf das eigentliche Projekt beziehen, während das Sprint-Retrospektive ein Meeting zur Verbesserung des Arbeitsprozesses ist[94]. Eine Besonderheit hat das Daily-Scrum-Meeting. Es findet täglich innerhalb von 15 Minuten statt und dient der Ermittlung von Problemen, die während der Entwicklung passieren können.

Auch in XP wird ein tägliches Meeting, das Stand-up-Meeting, dazu eingesetzt, um sich über das Projekt, den Fortschritt und die Problematiken zu informieren. In jeder Iteration (Wochenzyklus) wird kurz der aktuelle Projektstatus besprochen und die Anforderungen für die nächste Iteration ausgewählt.

In FDD ist der im ersten Prozess angewendete Modellierungsworkshop als Meeting anzusehen. Im Modellierungsworkshop wird mit dem Kunden, Fachexperten und Chefarchitekten ein Gesamtmodell erstellt[72]. Ein tägliches Meeting wie bei XP oder Scrum ist nicht vorgesehen.

6.1.10 Werte, Prinzipien und Praktiken

Jeder agile Prozess baut auf die fünf Werte Kommunikation, Einfachheit, Feedback, Mut und Respekt. Neben den Werten empfehlen alle agilen Prozesse noch Zusätzliches für den eigenen Entwicklungsverlauf. XP bietet sogenannte Prinzipien für eine bessere Entscheidungshilfe im Projekt[95]. Jedes Teammitglied soll die Prinzipien verstehen und ausleben können. Dadurch soll ein harmonisches Miteinander im Team aufgebaut und Entscheidungen besser getroffen werden. Jedoch werden bei XP nicht alle Prinzipien für ein Projekt vorausgesetzt, sondern nur diejenigen, die tatsächlich benötigt werden[95]. Desweiteren definiert XP für die Umsetzung noch 13 Primärpraktiken[96]. Sind die Primärpraktiken vom Team verstanden und werden diese umgesetzt, so werden von den erfahrenen Teammitgliedern 11 Begleitpraktiken verlangt[97]. Durch die hohe Anzahl an Praktiken und Prinzipien ist XP für Entwickler wesentlich anspruchsvoller. Neben einem guten technischen Wissensstand werden auch soziale Kompetenzen gefordert.

In XP übernimmt der XP Coach die Aufgabe, den Entwicklern die Werte, Prinzipien und Praktiken näher zu bringen und dafür zu sorgen, dass diese auch eingehalten werden. Eine Ähnliche Rolle hat bei Scrum der Scrum Master. Seine Rolle ist ebenfalls so zu verstehen, dass er die Integration aller Projektbeteiligten fördert, jedoch mit dem Unterschied, dass der Scrum Master mit 4 Prinzipien Vergleichsweise weniger verwalten muss als der Coach bei XP. Im Vergleich zu diesem erwartet der Scrum Master jedoch, dass alle diese Prinzipien auch eingehalten und umgesetzt werden.[98] Bei XP wird hier eher an das aktuelle Projekt angepasst.

Eine Ausnahme bei den agilen Prozessen stellt FDD dar. Dieses erwähnt zwar Best Practices, jedoch sind es keine Prinzipien, sondern es ist eher als ein Mix aus notwendigen Arbeitsschritten und Praktiken zu sehen. XP bezieht sich hier auf den Charakter der Entwickler um z. B. die Menschlichkeit im Team zu fördern oder Fehlschläge zu akzeptieren. Erst darauf folgen die Praktiken. FDD und Scrum beziehen sich direkt auf die Praktiken und somit als ersten Schritt auf das Projekt.

Wie Scrum setzt auch FDD durch seinen Projektablauf voraus, dass die Best Practices möglichst eingehalten werden. So ist z. B. Domain Object Modelling notwendig, um ein Gesamtmodell des Projekts zu generieren. Class Ownership muss angewendet werden, da FDD auf Klassenprogrammierung setzt. Visibility of Results oder Regular Build Schedule sind dagegen mögliche Varianten, die eingehalten werden können, aber nicht immer zwingend sind.

6.1.11 Release

Bei XP hat ein Release einen möglichen Zyklus von einem Quartal[96]. Es handelt sich dabei um einen Erfahrungswert von Kent Beck. Die Kontrolle, ob das Lieferungsdatum und damit das Release eingehalten werden kann, übernimmt der Projektmanager, der je nach Quelle und Verfasser auch Terminmanager bezeichnet wird[78]. Zudem fordert die Begleitpraktik "Tägliche Ausbreitung" die tägliche Verteilung des Systemstandes an die Anwender. Ziel dieser Praktik ist es, die Qualität der Software zu verbessern[75].

Die Release Planung bei Scrum findet im Estimation Meeting unter der Leitung des Product Owners statt[99]. Im Meeting wird ein Release Plan erstellt bzw. aktualisiert, der für einen Sprint alle Backlog Items enthält, die geliefert werden können[100]. Zudem findet eine Kontrolle statt, ob der Release Plan realisierbar ist. Da Scrum eine Iteration von bis zu 30 Tagen hat, wird ein Release auch in diesem Zeitraum erstellt.

Einen wesentlichen Unterschied bietet FDD, indem es als einziger Prozess eine Rolle anbietet, den Release Manager, welcher das Release überwacht und plant[80].

6.2 Gesamtüberblick

Agiler Prozess Scrum XP FDD
Projekttyp Allgemein ausgerichtet, nicht nur für Softwareentwicklung, Fertigstellungsdatum offen (Entwickler bestimmen Zeitmanagement) Budget bekannt, Zeit bekannt, Features offen Budget bekannt, Zeit bekannt, Features bekannt, Festpreisprojekt
Iteration Bis zu 30 Tage Wochen und Quartalszyklus Entwurf und Entwicklung je Feature ca. 2 Wochen
Moderierende Rolle Scrum Master XP Coach Chefarchitekt
Kunden-Rollen Kunde und Product Owner (übernimmt die Rolle und Aufgaben des Kunden) Anwender Fachexperte
Entwickler Rollen Team bestehend aus Entwicklern Entwickler Entwickler, ggf. Chefprogrammierer
Zusätzliche Rollen Projektmanager, Technischer Schreiber, Architekt, Interaction Designer Deployer, Scriber, Release-Manager, Build-Manager, Domänenexperte, Programmiersprachen-Guru, Projektmanager
Qualitätsmanagement Entwickler Tester Tester
Erstellung der Feature-Liste Kunde, Product Owner, Entwickler, alle Features ins Product Backlog Kunde, Entwickler Kunde, Entwickler, Chefarchitekt
Priorisierung der Anforderungen Product Owner Kunde Projektleiter, Entwicklungsleiter und Chefprogrammierer
Verantwortung des Kunden Arbeitet mit dem Product Owner an der Erstellung und Beschreibung der Features. Erstellung der Feature-Liste, Beschreibung und Priorisierung der Features, Durchgehende Beratung Erstellung der Feature-Liste, Beschreibung der Features
Verantwortung der Entwickler Erstellung der Feature-Liste und Entwicklung der Features, kein Vorgesetzter, arbeiten eigenverantwortlich und organisieren sich selbst Erstellung der Feature-Liste und Entwicklung der Features, Tests, Builds, Design, Hauptansprechpartner des Kunden, arbeiten eigenverantwortlich und selbst organisierend, kein Vorgesetzter Erstellung der Feature-Liste und Entwicklung der Features
Schätzungen Entwickler Entwickler Entwickler, Chefprogrammierer, Chefarchitekt
Werte Grundwerte + weitere projektspezifische Prinzipien Grundwerte + weitere projektspezifische Prinzipien / Praktiken Grundwerte + weitere projektspezifische Best Practices

6.3 Bewertung

Die Bewertung der agilen Prozesse findet einerseits unter wirtschaftlichen Kriterien statt und geht den Fragen eines Unternehmens nach. Kritikpunkte sind:

  • Lassen sich mit den agilen Prozessen Gewinne einbringen?
  • Lässt sich ein bestehendes System durch einen agilen Prozess ersetzen?
  • Was sind die Problematiken des agilen Prozesses im Bezug auf den Kunden?

Außerdem werden die wesentlichen Unterschiede der agilen Prozesse untereinander verglichen.

6.3.1 Vorteile

Der Vorteil aller agilen Prozesse liegt zuerst einmal - wie der Name schon andeutet - in der Agilität. Agile Prozesse setzen auf Einfachheit anstatt auf Bürokratie. Sie fordern zum Beispiel kein Pflichtenheft für die Definition der Anforderungen, was den Aufwand für die Erstellung der Anforderungen drastisch reduziert. Durch die gering gehaltene Bürokratie und die Einfachheit können agile Prozesse besonders schnell auf Änderungen reagieren und sich anpassen. Gelingt es Unternehmen und Kunden also, auf diese Bürokratie zu verzichten, ohne dass durch Interessenskonflikte Schäden oder Kosten entstehen, kann man durch die eingesparte Arbeit den Erfolg und Gewinn deutlich erhöhen. Dies erfordert gerade zu Anfangs allerdings auch eine hohe Disziplin. Die Vorteile der einzelnen Prozesse untereinander werden im folgenden näher beleuchtet.

FDD ist ein agiler Prozess der besonders gut für Festpreisprojekte geeignet ist. Dies liegt daran, dass FDD alle Features schon von Beginn an aufnimmt, Modelle für deren Umsetzung im Voraus erstellt und der Aufwand zu Beginn geschätzt wird. Bevor angefangen wird die Software zu entwickeln, sind fast alle Architektur- und Designfragen geklärt. Vorausgesetzt, dass die Schätzungen annähernd präzise sind, kann also ein relativ genaues Fertigstellungsdatum prognostiziert werden. Dies und die Struktur eines Festpreisprojektes sind für viele Kunden in der Softwareentwicklung eine grundsätzliche Voraussetzung, da sie sich ungern auf einen nicht festgelegten Preis oder ein unbekanntes Fertigstellungsdatum einlassen. Zusätzlich eignet sich FDD am besten für den Einstieg in agile Softwareentwicklung. Dies liegt vornehmlich daran, dass der Prozess größere Ähnlichkeiten mit klassischen Methoden aufweist als andere agile Prozesse. FDD bietet also die beste Planbarkeit durch die Definition im Voraus und kann bei richtigen Einsatz die Projektkosten reduzieren, da es durch den schlanken und klaren Prozess das Potenzial hat viel Arbeit und Organisation einzusparen.

Der agile Prozess XP zeichnet sich durch direkte Einbindung vom Kunden, nicht definiertem Funktionsumfang und starke Anpassungsfähigkeit aus. Die direkte Einbindung des Kunden wirkt sich vor allem deshalb positiv auf die Qualität der zu erstellenden Software aus, weil hierdurch sowohl die spezifischen Wünsche des Kunden am besten verstanden und umgesetzt werden, als auch die fachlichen Anforderungen an die Software, mit denen die Entwickler nicht immer vertraut sind, am besten erläutert werden können. Der nicht definierte Funktionsumfang gibt dem Projekt Sicherheit, da bei großen Komplikationen nicht das Softwareentwicklungsunternehmen mit den entstandenen Kosten alleine dasteht. Die große Anpassungsfähigkeit erreicht XP dadurch, dass alle im Prozess genannten Prinzipien und Praktiken optional sind und nur zum Einsatz kommen sollen, wenn dies auch wirklich sinnvoll ist. Bei Projekten, in denen viel Know-How vom Kunden für die Umsetzung erforderlich ist, hat XP das Potenzial durch die direkte Einbindung des Kunden viel Aufwand für Absprache und Erläuterungen zwischen Anwender und Entwickler einzusparen. Hierdurch sinken wiederum die Projektkosten.

Mit Scrum kann man ebenfalls viele unterschiedliche Anforderungen an den Prozess erfüllen. Dies hat jedoch einen anderen Grund. Scrum definiert lediglich einen Prozess für das Management eines Projektes. Es ist zwar vorgegeben, wie mit Anforderungen umgegangen wird und wann welche Meetings gehalten werden etc., es gibt jedoch keine Vorgaben für die konkrete Umsetzung der Softwareentwicklung wie z. B. den Einsatz von Unit Tests oder Code Reviews. Somit ist Scrum auch zum Teil an die Bedürfnisse und Gewohnheiten des Teams anpassbar. Außerdem ist es hierdurch nicht nur für Softwareentwicklungsprojekte geeignet. Hinzu kommt, dass das Team in Scrum das eigene Zeitmanagement selbst in die Hand nimmt. Dies macht vor allem deswegen Sinn, weil die Entwickler die Personen sind, welche am besten wissen, wie viel Zeit sie benötigen und wie viel Arbeit sie in einem Sprint schaffen können. Der Vorteil ist somit, wie auch bei XP, dass eine Software entwickelt werden kann, die genau auf den Kunden zugeschnitten ist, da auch Neuanforderungen mitaufgenommen werden können.

6.3.2 Nachteile

Betrachtet man alle agilen Prozesse unter einem wirtschaftlichen Aspekt, so haben alle drei Prozesse zunächst ein grundsätzliches Integrationsproblem in Unternehmen mit bereits bestehenden Arbeitsprozessen. FDD ist in seiner Grundstruktur ein Festpreisprojekt und somit für Softwareprojekte eine meist ungeeignete Lösung. In einem Festpreisprojekt sind die Kosten, Dauer und Umfang der Features von Beginn an geklärt. Damit die Dauer eines Projekts ermittelt werden kann, müssen in einem Softwareprojekt alle Features geschätzt werden und es muss ebenso von Beginn an die Anzahl der Features bekannt sein. In Abhängigkeit der Kennzahl Zeit lassen sich die Kosten und somit der Gewinn ermitteln. Das Kernproblem der Softwareentwicklung sind aber die Schätzungen. Features lassen sich nicht schätzen, was für ein Festpreisprojekt bei einer Fehlkalkulation verheerende Folgen hat. Wird die Zeit zu kurz eingeschätzt, explodieren die Kosten und das Projekt macht Verlust. Ein zweites Problem beträgt die Anzahl der Features selbst. Kein Entwickler und kein Kunde kann immer mit Sicherheit bei einem Projekt mit einer hohen Komplexität, besonders bei Großprojekten, voraussagen, was alles benötigt wird. Oft ist es so, dass während der Entwicklung noch Zusätzliches benötigt wird oder das Änderungen an den Spezifikationen gemacht werden müssen, weil sie unvollständig oder falsch sind. Das kostet Zeit. Und diese Zeit hat ein Festpreisprojekt und damit der agile Prozess FDD nicht. FDD ist wirtschaftlich ein Risiko und beinhaltet, dass, wenn mehr Aufwand zu leisten ist als geschätzt, mehr Kosten generiert werden und somit der Gewinn ins Minus geraten kann. Darunter leidet auch der Entwicklungsprozess. XP und Scrum haben im Vergleich dazu diese Problematik nicht.

Etwas besser, aber ebenfalls mit einem Grundproblem, befindet sich in dieser Reihenfolge XP. Dieses hat zunächst die positive Eigenschaft, dass es ein Projekt ist, dessen Umfang an Aufwendungen nicht definiert ist. Das Problem von XP zeigt sich in der Verantwortung der projektbeteiligten Personen. So lastet die komplette Verantwortung auf den Kunden und den Entwicklern. Letzterer sollte technisches Fachwissen, Sorgfalt, analytisches und logisches Denken mitbringen und ein Profi in seinem Bereich sein. Der Kernbereich des Entwicklers ist die Programmierung und das kann das Problem darstellen. Nicht jeder Entwickler ist zugleich ein Consultant. Ein Consultant zeichnet sich durch Verhandlungsgeschick, gute sprachliche Kommunikation und Durchsetzungsvermögen aus. Als Beispiel bieten Großunternehmen heutzutage den eigenen Consultants Zielprovisionen an. Projekte sind teuer und langwierig. Wird ein Projekt schneller entwickelt als vorausgesetzt oder schafft der Consultant es, die Kosten für ein Projekt um einen gewissen Prozentsatz zu verringern, so erhält er eine Provision. Das Problem im Zwei-Parteien-System XP sind somit Interessenskonflikte. Der Kunde wird versuchen seine Vorstellungen - und die bestehen aus einem monetären Wert - durchzusetzen. Mit dem Recht auf Priorisierung und mit der Zusammenarbeit mit dem Entwickler hat er einige Möglichkeiten. Der Entwickler wird versuchen, das Projekt abzuschließen, hat jedoch mit der Tatsache, dass nicht alle Anforderungen fertiggestellt werden müssen, auch seine Möglichkeiten. Ein weiteres Problem ist die Kompetenz des Entwicklers und des Kunden. Der Kunde ist oft mit technischen Angelegenheiten überfordert, weiß oft nicht, welche Anforderungen er genau will und ist mit projektbezogenen Schätzungen aufgrund der hohen Komplexität ebenso überlastet. Auch wenn viele Consultants heutzutage technisches Grundwissen haben, so ist das keine Selbstverständlichkeit. Der Entwickler kann mit der Menge der Anforderungen überfordert werden. So arbeitet er mit dem Kunden zusammen, macht die Entwicklung, die Tests, die Builds, die Releases, das Design, die Aufwandseinschätzungen und die Erstellung der Anforderungen. Es ist also nicht der typische Entwickler gefragt, der täglich acht Stunden programmiert, sondern es ist jemand gefragt, der sich und sein Produkt verkaufen kann. Er muss soziale Kompetenzen und viel Disziplin mitbringen, damit er sich während der Zusammenarbeit mit dem Kunden behaupten kann und innerhalb des eigenen Teams zur Harmonie beiträgt. Aufgrund der vielen unterschiedlichen Aufgabenteile müssen organisatorische Fähigkeiten vorhanden sein. Dieser untypische Entwickler ist gefordert. XP lässt sich also nicht ohne Weiteres in ein bestehendes System von Entwicklern und vorhandenen Projektabläufen integrieren. Über die Frage des wirtschaftlichen Erfolgs entscheidet der Kunde bzw. der Entwickler. Der Stärkere von beiden wird sich durchsetzen. Ob ein Unternehmen einen hohen Kundeneinfluss akzeptiert, ist eine weitere Frage, die sich ein Unternehmen stellen muss. Das Problem des Kundeneinflusses kann zudem den eigenen Entwicklungsprozess im Unternehmen gefährden. Zukünftige Neulinge werden es außerdem schwer haben, XP zu verstehen und richtig anzuwenden, da es allein aufgrund der vielen bzw. von Projekt zu Projekt unterschiedlich eingesetzten Prinzipien und Praktiken schwer ist, diesen Prozess von Beginn an zu verstehen. Außerdem hat XP keinen Vorgesetzten und lässt sich dadurch in Unternehmen, die explizit einen Vorgesetzten für Projekte verlangen, nicht ohne Änderungen in der Unternehmensstruktur integrieren. Den Vorteil bei dieser Problematik hat der agile Prozess FDD. FDD hat mit dem Chefarchitekten einen Vorgesetzten, der Interessenskonflikte lösen kann.

Der agile Prozess Scrum legt das Zeitmanagement der Entwicklung u. a. auf die Entwickler, wodurch ein Vorteil gegenüber FDD entsteht. Die Machtverhältnisse liegen ebenfalls beim Unternehmen, wodurch der Vorteil gegenüber XP ersichtlich wird. Die Problematik wird erst erkenntlich, wenn man die Rolle Team näher betrachtet. So besitzt diese Rolle, wie zuvor bei XP erwähnt, keinen Vorgesetzten, sondern baut allein auf die Verantwortung der Entwickler auf. Weder Scrum-Master noch Product Owner haben eine Vorgesetztenfunktion. Das setzt Eigenverantwortlichkeit, Kompromisse, Teamfähigkeit und die Fähigkeit, sich selbst zu organisieren voraus[101]. Dominate Persönlichkeiten können das Team und das Ziel gefährden. Mit einem gut aufgebauten und erfahrungsreichen Team ist es zwar möglich, Projekte umzusetzen, jedoch bestehen überall potenzielle Gefahrenquellen. Die Frage, die sich ein Unternehmen stellen muss, ist, ob das Unternehmen in Deutschland bereit ist und das Vertrauen hat, ein Großprojekt in die Hände einiger Mitarbeiter zu übertragen, ohne direkten Einfluss auf den Arbeitsprozess zu haben. Betrachtet man heutige Unternehmen in Deutschland, so gibt es meistens eine strukturierte Mitarbeiterhierarchie mit Verantwortlichen und Abteilungsleitern. Ein Gedanke dabei ist die Kontrolle. Scrum ist somit ein agiler Prozess, der nicht in jede Unternehmenspolitik passt.

Alle drei Prozesse haben außerdem den Nachteil, dass sie kein Pflichtenheft fordern. Ein Pflichtenheft umfasst den kompletten Umfang des Werks und ist zugleich für den Kunden und für ein Unternehmen die Argumentationsbasis, weshalb ein Pflichtenheft auch oft Teil eines Vertrags ist. Der Entwickler hat zudem einen Überblick über bevorstehende Arbeiten und detailliert beschriebene Anforderungen, die er für die Entwicklung benötigt. Storys, Story Cards oder ähnliche Kurzschreibweisen reichen oftmals nicht aus, um einen komplexen Sachverhalt zu erläutern, sondern führen zu unterschiedlichen Interpretationsansichten und damit zu Fehlentwicklungen, unvollständigen Entwicklungen oder einem Entwicklungsstopp.

7 Fazit

Nach eingehender Betrachtung der drei Verfahren der agilen Softwareentwicklung wird ersichtlich, dass agile Softwareentwicklung keineswegs eine Modeerscheinung ist, die in naher Zukunft wieder vom Markt verschwinden wird. Andererseits hat auch die klassische Softwareentwicklung ihre Daseinsberechtigung und wird sicher nicht durch die agilen Modelle vom Markt verschwinden.

Ebenso lässt sich kein "bestes" Verfahren der agilen Softwareentwicklung küren, da jedes Vorzüge und Nachteile hat. Weiterhin ist zu bedenken, dass die Verfahren für unterschiedliche Arten von Projekten geeignet sind. So ist FDD besonders für Festpreisprojekte geeignet, XP für Projekte mit verhandelbarem Umfang und Scrum kann an die Projektbedingungen angepasst werden, da es einen Managementrahmen bietet. Letztendlich hängt der Erfolg des Projektes jedoch nicht davon ab, das "richtige" Modell gewählt zu haben, sondern es ist wichtig, die Verfahren an seine Unternehmensziele anzupassen. Dass hebt z. B. XP mit der Auswahl der Praktiken hervor. Diese "Anpassung" ist das Grundelement der agilen Softwareentwicklung und wenn diese nicht betrieben wird, wird man mit keinem der Modelle Erfolg haben. Tendenziell ist FDD als Einstieg in die agile Softwareentwicklung zu empfehlen, da der Vertragsrahmen den Standards entspricht und das Prinzip der Entwicklung auch nicht so fern von den klassischen Methoden ist. XP eignet sich hervorragend für Projekte im Bereich der Webentwicklung, wo es kurze Entwicklungszyklen gibt und der Kunde schnell Ergebnisse sehen möchte. Scrum ist der Alleskönner unter den agilen Verfahren, da es einen Managementrahmen bietet und somit auch für Projekte außerhalb der Softwareentwicklung geeignet ist.

8 Fußnoten

  1. ↑ Vgl. Bleek et al. (2008), Seite 13
  2. ↑ Vgl. Bleek et al. (2008), Seite 13ff
  3. ↑ Vgl. Bleek et al. (2008), Seite 10 f.
  4. ↑ Vgl. Bleek et al. (2008), Seite 11
  5. ↑ Vgl. Bleek et al. (2008), Seite 12
  6. ↑ Vgl. Ludewig et al. (2010), Seite 222
  7. ↑ Vgl. Beck et al. (November 2004), Chapter 4: Respect
  8. ↑ Vgl. Ludewig et al. (2010), Seite 222ff
  9. ↑ Vgl. Beck et al. (November 2004), Chapter 5
  10. ↑ 10,0 10,1 10,2 Vgl. Beck et al. (November 2004), Chapter 6
  11. ↑ 11,0 11,1 11,2 11,3 11,4 11,5 11,6 11,7 Vgl. Bleek et al. (2008), Seite 149
  12. ↑ 12,0 12,1 12,2 12,3 12,4 Vgl. Bleek et al. (2008), Seite 150
  13. ↑ Vgl. Bleek et al. (2008), Seite 150 f.
  14. ↑ 14,0 14,1 14,2 Vgl. Bleek et al. (2008), Seite 151
  15. ↑ 15,0 15,1 Vgl. Gloger (2011), Seite 23
  16. ↑ 16,0 16,1 16,2 Vgl. Gloger (2011), Seite 157
  17. ↑ Vgl. Beck et al. (November 2004), Chapter 2
  18. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Roles
  19. ↑ Vgl. Beck (2003), S.73f
  20. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Testers
  21. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Interaction Designer
  22. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Archtitects
  23. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Project Managers
  24. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Executives
  25. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Technical Writers
  26. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Users
  27. ↑ Vgl. Beck et al. (November 2004), Chapter 10: Programmers
  28. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Humanity
  29. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Economics
  30. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Mutual Benefit
  31. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Self-Similarity
  32. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Improvement
  33. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Diversity
  34. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Reflection
  35. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Flow
  36. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Opportunity
  37. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Redundancy
  38. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Failure
  39. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Quality
  40. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Baby Steps
  41. ↑ Vgl. Beck et al. (November 2004), Chapter 5: Accepted Responsibility
  42. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Sit Together
  43. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Whole Team
  44. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Informative Workspace
  45. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Energized Word
  46. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Pair Programming
  47. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Stories
  48. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Week Cycle
  49. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Quarterly Cycle
  50. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Slack
  51. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Ten-Minute Build
  52. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Continuous Integration
  53. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Test-First Programming
  54. ↑ Vgl. Beck et al. (November 2004), Chapter 7: Incremental Design
  55. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Real Costumer Involvement
  56. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Incremental Deployment
  57. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Team Continuity
  58. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Shrinking Teams
  59. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Root-Cause Analysis
  60. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Shared Code
  61. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Code and Tests
  62. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Single Code Database
  63. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Daily Deployment
  64. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Negotiated Scope Contract
  65. ↑ Vgl. Beck et al. (November 2004), Chapter 9: Pay-Per-Use
  66. ↑ 66,0 66,1 66,2 66,3 Vgl. Bleek et al. (2008), Seite 152
  67. ↑ Vgl. Roock et al. (2008), Seite 1 f.
  68. ↑ 68,0 68,1 Vgl. Roock et al. (2008), Seite 1 ff.
  69. ↑ Vgl. Hoß (2008), Seite 13
  70. ↑ Vgl. Bleek et al. (2008), Seite 165
  71. ↑ Vgl. Bleek et al. (2008), Seite 152 f.
  72. ↑ 72,0 72,1 72,2 72,3 72,4 Vgl. Bleek et al. (2008), Seite 153
  73. ↑ 73,0 73,1 Vgl. Bleek et al. (2008), Seite 153 f.
  74. ↑ 74,0 74,1 74,2 74,3 Vgl. Bleek et al. (2008), Seite 154
  75. ↑ 75,0 75,1 75,2 Vgl. Bleek et al. (2008), Seite 147
  76. ↑ 76,0 76,1 76,2 Vgl. Gloger (2009), Seite 54
  77. ↑ 77,0 77,1 77,2 77,3 77,4 Vgl. Bleek et al. (2008), Seite 148
  78. ↑ 78,0 78,1 78,2 Vgl. Beck et al. (2004), Seite 144
  79. ↑ Vgl. Götzenauer et al. (2009), Seite 73
  80. ↑ 80,0 80,1 Vgl. Götzenauer et al. (2009), Seite 74
  81. ↑ Vgl. Götzenauer et al. (2009), Seite 73f
  82. ↑ 82,0 82,1 82,2 Vgl. Gloger (2009), Seite 13
  83. ↑ Vgl. Bleek et al. (2008), Seite 153ff
  84. ↑ 84,0 84,1 Vgl. Bleek et al. (2008), Seite 155
  85. ↑ 85,0 85,1 Vgl. Bleek et al. (2008), Seite 156
  86. ↑ 86,0 86,1 86,2 Vgl. Gloger (2009), Seite 12
  87. ↑ Vgl. Beck et al. (2004), Seite 73f
  88. ↑ Vgl. Bleek et al. (2008), Seite 145
  89. ↑ Vgl. Bleek et al. (2008), Seite 152
  90. ↑ 90,0 90,1 Vgl. Bleek et al. (2008), Seite 142
  91. ↑ Vgl. Buhl (2004), Seite 18
  92. ↑ Vgl. Gloger (2009), Seite 160
  93. ↑ Vgl. Gloger (2009), Seite 161
  94. ↑ Vgl. Gloger (2009), Seite 13f
  95. ↑ 95,0 95,1 Vgl. Bleek et al. (2008), Seite 138
  96. ↑ 96,0 96,1 Vgl. Bleek et al. (2008), Seite 141
  97. ↑ Vgl. Bleek et al. (2008), Seite 144
  98. ↑ Vgl. Gloger (2009), Seite 230
  99. ↑ Vgl. Gloger (2009), Seite 14
  100. ↑ Vgl. Gloger (2009), Seite 15
  101. ↑ Vgl. Ludewig et al. (2010), Seite 233

9 Literaturverzeichnis

Verweis Literatur / Quelle
Buhl (2004) Buhl, Axel: Grundkurs Software-Projektmanagement: Einführung in das Management objektorientierter Projekte, Hanser Fachbuchverlag, Februar 2004
Beck (2004) Beck, Kent: Extreme Programming. Das Manifest, Addison-Wesley, 2004
Beck et al. (November 2004) Beck, Kent; Andres Cynthia: Extreme Programming Explained: Embrace Change, Second Edition, Addison-Wesley, November 2004
Bleek et al. (2008) Bleek, Wolf-Gideon; Wolf, Henning: Agile Softwareentwicklung: Werte, Konzepte und Methoden, 1. Auflage, dpunkt Verlag, März 2008
Gloger (2009) Gloger, Boris: Scrum: Produkte zuverlässig und schnell entwickeln, 2. aktualisierte Auflage, Hanser Fachbuch, Juli 2009
Götzenauer (2009) Götzenauer, Jürgen: Agile Methoden in der Softwareentwicklung: Vergleich und Evaluierung, Grin Verlag, Juni 2009
Ludewig et al. (2010) Ludewig, Jochen; Lichter, Horst: Software Engineering, 2. Auflage, dpunkt Verlag, März 2010
Von „http://winfwiki.wi-fom.de/index.php/Vergleich_verschiedener_Verfahren_der_agilen_Softwareentwicklung“
Persönliche Werkzeuge