Kapitel 3

Vorgehensmodelle dienen dazu, die Steuerung und Strukturierung von Projekten zu vereinheitlichen; ein standardisierter Projektablauf erspart Arbeit.

Ein Vorgehensmodell enthält die folgenden Elemente:

• Projektphasen

• Aktivitäten

• Meilensteine

• Standards, Richtlinien, Methoden und Werkezuge

• Stagewise Modell: nur vorwärts gerichtete Pfeile. Die einzelnen Phasen sind streng sequenziell zu durchlaufen

• Wasserfallmodell: zwischen zwei aufeinander folgende Phasen sind Rückkopplungen erlaubt. Höhere Flexibilität, ohne aber kostenintensive Überarbeitung über mehrere Projektphasen zuzulassen

• V-Modell: Es wird verstärkt Wert auf das Thema Qualitätssicherung gelegt „Geplanter, systematischer Prozess mit dem Ziel sicherzustellen, dass ein Arbeitsprodukt seinen Anforderungen entspricht.“

• Agile (Extreme) Programmierung: Das Lösen einer Programmieraufgabe rückt in den Vordergrund

  Annahme, dass das mit der Realisierung betraute Entwicklerteam anfangs nicht über alle Informationen verfügt

  Basiert auf Iterationen – Kunde hat jederzeit die Möglichkeit, auf das Projekt einzuwirken

  
  

  Key Roles: SCRUM

  Zentrale Artefakte von SCRUM:

  o Product Backlog

  o Sprint Backlog

  o Increment

  Ereignisse von SCRUM:

  o Sprint planning

  o Daily scrum

  o Sprint review

  o Sprint retrospective

1. Stagewise Modell

2. Wasserfallmodell

3. V-Modell

4. Agile (Extreme) Programmierung

Vorteile:

• einfach verständlich

• kontrollierbarer Prozessablauf durch Meilensteine und Dokumentation am Ende jeder Phase

• organisatorisch gut beherrschbar

• wenig Managementaufwand

Nachteile:

• durch streng dokumentationsorientiertes Vorgehen Gefahr, dass Dokumente wichtiger als Projektziel/-inhalt werden

• Risiken werden erst in späterer Phase erkannt (keine frühen Feedback-Möglichkeiten)

• spätere Veränderung und Detaillierung von Anforderungen bleiben unberücksichtigt

• Anwender und Management sehen System erst nach Fertigstellung

• Test beginnt erst, wenn Entwicklung abgeschlossen

Empfehlung: Nur einsetzen, wenn am Anfang gleichzeitig alle Anforderungen bekannt sind und sich im Laufe des Projektes nicht ändern (selten der Fall). Z.B. bei kleinen Projekten oder bei Weiterentwicklungen.

Vorteile:

• detaillierte Darstellung von Systemerstellung, Qualitätssicherung, Konfigurationsmanagement und Projektmanagement

• Vorgabe von definierten Aktivitäten, Rollen, Produkten und Methoden

• Unterstützung von parallelen Aktivitäten (nicht sequentiell)

• Möglichkeit des “Tailoring” des Prozesses auf projektspezifische Erfordernisse

• standardisierte Abwicklung von Projekt- zur Systemerstellung

• fordert Qualitätsbewusstsein (Definition Zielqualität, Überprüfung durch QS)

Nachteile:

• hohe Komplexität, hohe Kosten bei der Einführung

• bei kleineren und mittleren Projekten; unnötige Bürokratie bspl. Dokumentation & Vorgehensweise

• ohne Case-Unterstützung nur schwer handhabbar

Empfehlung: inbesondere für große Projekte gut geeignet

1. Projektinitiierung und -planung -> Projektstrukturplan und Projektorganisation

2. Ist-Analyse -> Stärken-/Schwächen-Profil

3. Soll-Konzept -> Ausgestaltetes Soll-Konzept

4. Umsetzung und Abschluss -> Realisierung

Product Backlog:

Sortierte Liste mit allen wichtigen Informationen für das Produkt

Der Product Owner ist verantwortlich für die Liste

Sprint Backlog:

Das Sprint Backlog ist die Menge der Product Backlog Items, die für den Sprint ausgewählt wurden, um ein Sprint Goal zu realisieren.

Das Sprint Backlog ist ein gut sichtbares Echtzeit-Bild der Arbeit, die das Entwicklungsteam während des Sprints zu erledigen plant.

Es gehört ausschließlich dem Entwicklungsteam.

Increment

Das Inkrement ist die Summe aller Product Backlog Items, die während eines Sprints fertiggestellt werden.

Das Inkrement muss in einem brauchbaren Zustand sein, unabhängig davon, ob der Product Owner beschließt, es freizugeben.

Sprint Planning:

Erstellen das Sprint Backlog und identifizieren das Sprint Goal, zu dem sich das gesamte Scrum Team im Laufe des Sprints verpflichtet.

Daily Scrum:

Bietet dem Scrum Team die Möglichkeit, Fortschritte zu besprechen, tägliche Verpflichtungen bekannt zu geben und Hindernisse zu identifizieren, die vom Scrum Master ausgeräumt werden sollten.

Anwesende: Scrum Master und Entwicklungsteam. Product Owner und externe Stakeholder sind optional.

Sprint Review:

Präsentieren die im Laufe des Sprints geleistete Arbeit. Feedback von den Stakeholdern einholen, um das Produkt zu überprüfen und anzupassen.

Teilnehmer: gesamtes Scrum-Team sowie Stakeholder und Kunden

Sprint Retrospective:

Ermöglicht es dem Team, sich selbst zu überprüfen und Verbesserungen für den nächsten Sprint zu planen.

Teilnehmende: Scrum Master und das Entwicklungsteam. Der Product Owner ist optional, wird aber empfohlen.

Traditionelles Vorgehen:

• Stabile Anforderungen, vorab definiert

• Möglichst wenig Veränderung

• Lieferung eines Gesamtergebnisses am Ende des Projektes

• Stakeholder-Beteiligung zu den Meilensteinen

  
  

Agiles Vorgehen

• Dynamische Anforderungen, häufig vereinfacht

• Fortlaufende Anpassungen

• Lieferung häufiger Zwischenergebnisse für Feedback und Kundennutzen

• Fortlaufende Einbindung. wesentlicher Stakeholder

Hybrid: Kombination aus sequenziell, parallel oder integriert

• Anwendung verschiedener Modelle nacheinander in zeitlicher Abfolge der Projektphasen

• Klassisches Vorgehen innerhalb der angewandten Modelle

Vorteile:

• Hohe Prozessstabilität

• Vereinfachte Abgrenzung von Methoden und Rollen

• Keine Überschneidungen verschiedener Modelle

Nachteile:

• Keine Lösung für Phasen mit gleichermaßen traditionellen und agilen Voraussetzungen

• Ggf. Verlängerung der Projektdauer

• Ggf. Konflikte durch unterschiedliche Denk- und Handlungsweisen

In sich geschlossene Teilmodelle

Keine Beeinflussung in der laufenden Durchführung

Standards als Orientierungshilfe

-> Projektphasen mit verschiedenen Voraussetzungen

-> Konzentration auf Erlernen der verschiedenen Vorgehensweisen

-> Einführung neuer Arbeitsweisen als ganzheitliche Modelle

• Anwendung verschiedener Modelle gleichzeitig, getrennt nach Teilprojekten

• Klassiches Vorgehen innerhalb der angewandten Modelle

Vorteile:

• hohe Prozesstabilität

• vereinfachte Abgrenzung von Methoden und Rollen

• Zusammenarbeit mit anders arbeitenden Organisationsbereichen möglich

Nachteile:

• keine Lösung für Teilprojekte mit gleichermaßen traditionellen und agilen Voraussetzungen

• Gefahr von Spannungen im Projektablauf und einem unstimmigen Gesamtergebnis bei mangelhafter Synchronisation

• Ggf. Rollenkonflikte

In sich geschlossene Teilmodelle

Keine direkte Beeinflussung in der Durchführung

Standards als Orientierungshilfe

Erhöhter Koordinationsaufwand

-> Teilprojekte mit verschiedenen Voraussetzungen

-> Geübt in Koordination und ggf. Ressourcenmanagement

-> Einführung neuer Arbeitsweisen, aber auch Zusammenarbeit mit anderen Teams

• Anwendung verschiedener Modelle entlang des Projektlebenszyklus situativ angemessen

• modernes Vorgehen innerhalb der angewandten Modelle

Vorteile:

• Umgang mit gleichermaßen traditionellen und agilen Voraussetzungen möglich

• Flexibilität in der Vorgehensweise

• individuell anpassbar, d.h. maßgeschneiderte Vorgehensweise

Nachteile:

• Gefahr von Lücken, Widersprüchen und Inkonsistenzen

• bei übertriebener Kombination Entstehung von überhöhter Komplexität und Fehleranfälligkeit

• Gefahr von Verlust der Prozessstabilität

• Ggf. Rollenkonflikte

Kein Vorgehen nach geschlossenen Standards

Individualisierung und Optimierung von Modellen

Hoher Koordinationsbedarf

-> Phasen und Teilprojekte mit durchmischten Anforderungen

-> Geübt in Koordination

-> Erfahren in verschiedenen Arbeitsweisen, aber auch Einführung von nach und nach neuen Elementen

Je schwieriger die Umsetzung von Änderungen ist, desto weniger eignet sich ein agiles Vorgehen

Aber auch Baubranche ist von VUKA Projektwelt betroffen und erfordert angepasste PM Modelle

-> Sequenziell - SCRUM und Wasserfallmodell

Stabilisierung der Anforderungen in der Planungsphase durch agile und interative Objektmodelle

Umsetzung von Bestandteilen mit noch volatilen Anforderungen so spät wie möglich

Vorteile

• Technisch: Kombination aus „Continuous Delivery“ mit agilen Entwicklungsmethoden

• Reduktion der Komplexität durch Kürzung des „Software Development Life Cycles“

• Kulturell: Grundsätzlich zufriedenere Mitarbeiter, produktivere Teams und mehr individuelles Engagement

• Wirtschaftlich: Schnellere Bereitstellung neuer Funktionalitäten, stabilere Anwendungen, effizientere Prozesse und mehr Innovation (→ schneller auf dem Markt (Wettbewerbsvorteil))

• Gemeinsamer Nutzen von Entwicklungs-, Test- und Betriebsumgebung führt zu Kostenersparnissen (Cloud- Infrastruktur)

Nachteile

• Erfordert eine übergreifende Sicht von Programmierern, Testern, Architekten und Service Administratoren (Ops)

• Umstellung auf flache Hierarchien

• Umstellung auf pragmatisches Vorgehen (Bürokratismus bremst agile Methoden)

• Z. T. werden nicht ganz ausgereifte Produkte geliefert, die noch „Continuous Improved“ werden