7 Projektplanung – Ablauforganisation, Vorgehensmodelle Flashcards

Question

V-Modell XT ## Footnote Projektdurchführungsstrategien und Entscheidungspunkte (2) 1. Was ist ein Entscheidungspunkt und wozu dient er? 2. Was geben Projektdurchführungsstrategie und Entscheidungspunkte im Projektverlauf vor?

Answer 1

1. Entscheidungspunkt (Meilenstein) definiert einen im **Projektplan festzulegenden Zeitpunkt**, an dem eine „**Fortschrittsentscheidung**“ (GO/NOGO) getroffen wird und legt eine **Menge von Produkten** (Artefakte) fest, die zum **Entscheidungspunkt** (Meilenstein) fertig gestellt sein müssen, damit auf dieser Basis die **Fortschrittsentscheidung** getroffen werden kann. 2. Projektdurchführungsstrategien und Entscheidungspunkte geben die **Reihenfolge der Produktfertigstellung** und somit die grundlegende **Struktur des Projektverlaufs** vor.

Answer 2

Produkte (Artefakte) stehen im Mittelpunkt, sie sind DIE Projektergebnisse. AG und AN werden klar getrennt. Detaillierte Projektplanung und -steuerung wird auf der Basis der Bearbeitung und Fertigstellung von Produkten durchgeführt. Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im Projekt eine der Rolle zugeordnete Person. Produktqualität ist überprüfbar durch definierte Anforderungen an das Produkt und explizite Beschreibungen der Abhängigkeiten zu anderen Produkten.

Answer 3

**Geplant** (Eingangszustand aller Produkte) ... ist in der **Planung** vorgesehen; dies ist der **Eingangszustand** für alle Produkte. **In Bearbeitung** ... befindet sich im "privaten" Entwicklungsbereich des Entwicklers oder unter Kontrolle des Entwicklers innerhalb der Produktbibliothek. **Vorgelegt** ... ist aus der Sicht des Erstellers **fertig** und wird unter **Konfigurationsverwaltung** genommen und einer **QS-Prüfung** unterzogen; falls **von QS abgelehnt**, geht es wieder in den Zustand **„In Bearbeitung"**, andernfalls rückt es in den Zustand "**akzeptiert**" vor. Vom Zustand "vorgelegt" ab kann der Ersteller nur unter Fortschreibung der Versionsangabe Modifikationen durchführen. **Akzeptiert** ... wurde in QS überprüft und **freigegeben** und **darf nur mehr innerhalb einer neuen Version geändert werden.** Zustandswechsel werden durch **Aktivitäten** ausgelöst. Für jedes Artefakt ist somit festgelegt, wer (Rolle) es wie (Aktivität) in einen bestimmten Zustand versetzen darf

Answer 4

Vorteile + Sehr gut ausgearbeitet und umfassend + Generisch mit Möglichkeiten des Tailoring + Ermöglicht eine standardisierte Abwicklung + Ausführliche Produktvorlagen Nachteile - Hauptsächlich für große Systeme gedacht - Nicht vollständig methodenneutral - Bei kleineren Projekten z.T. hoher Einführungsaufwand

Answer 5

1. **Individuelle Menschen und deren Interaktionen** ist wichtiger als Prozesse und deren Tools. 2. **Laufende Software** ist wichtiger als umfangreiche Dokumentation. 3. **Kollaboration mit Kunden** (AG) ist wichtiger als ein riesen Auftragsplan 4. **Schnelles reagieren auf Änderungen** ist wichtig als nur einem Plan zu folgen Alles ist wichtig, aber **linken Werte werden höher priorisiert.** Mit agiler Entwicklung kann **schneller lauffähige Software** entwickelt werden. Und das ist **nur möglich, wenn man gut mit den Menschen zusammenarbeiten** kann. Aufgrund dessen wurde das Manifesto der agilen Softwareentwicklung gemacht. **70%** arbeiten in der Softwareentwicklung agil!

Answer 6

Zum Millenium (2000) von Kent Beck publiziert. Unter Begriff “Agile Prozesse“ zusammengefasst. Stark **auf die Aktivitäten der Implementation konzentriertes Vorgehen**, das mit einigen Prinzipien und Methoden des klassischen Software Engineering bricht. Evolutionäre Vorgehensweise **Keine umfassende Anforderungsermittlung** und **kein Entwurf** im eigentlichen Sinn. Entwicklung in **sehr kleinen Schritten** (Iterationen) Ergebnisse sind jeweils **geringfügig erweiterte, lauffähige Softwareversionen** (sog. Releases), die **stets vom Anwender abgenommen** werden. Basieren auf bestimmten Techniken (Praktiken) Wichtig: **Praktiken in ihrer Gesamtheit einsetzen**, da sie sich **gegenseitig unterstützen.** **Weglassen** einzelner Praktiken **stellt das gesamte Vorgehen in Frage!** Keine der Praktiken ist wirklich neu —**neu ist aber die Kombination und die “extreme“ Interpretation der Praktiken** im XP. Urmodell agiler Prozesse und gleichzeitig dazu ist Scrum als agiles Rahmenwerk entstanden.

Answer 7

Für kleine Projekte mit **max 15** Entwickler. Beteiligte\* müssen sich XP-Praktiken verschreiben. AG und Entwickler müssen sich über **problematische Vertragsgestaltung** im Klaren sein. Wegen **kurzer Planungszeiträume** und da sich **Systemanforderungen erst im Projekt ergeben**, kann **_kein_ Vertrag** abgeschlossen werden, **der allen Beteiligten Planungssicherheit gibt**. AG muss **qualifizierten Mitarbeiter als Anwendervertreter** für Projektteam abstellen. Zu Schulungszwecke Paare aus erfahrenem und Anfänger zusammenstellen. Wichtig: Intensive **Kommunikation**! Am besten einsetzbar, wenn **Entwickler an einem Ort konzentriert sind und gleichen Arbeitszeiten** haben! Entwickler brauchen **sehr gute und breite Qualifikation**, da sie laufend in anderen Paaren und andere Aktivitäten eingesetzt werden.

Answer 8

… **in EU weit verbreitetes agiles Vorgehensmodell mit einfacher Struktur und drei klar definierten Rollen.** **Anforderungen**\* **jederzeit von allen definierbar** und werden **vom PO im** **_Product Backlog_** **gesammelt**. **Umsetzung wird im Product Backlog Burndown** dokumentiert. **Sprint** (Iteration ca 2-4 Wochen) Ausgewählte **Anforderungen werden umgesetzt und tagesgenau im _Sprint Backlog_ Burndown dokumentiert.** **Product Owner** Zuständig für **Formulierung, Auswahl und Priorisierung** der **Anforderungen** **Vertritt** **Kunden und Anwender** **Team (überwiegend Entwickler)** **Setzen eigenverantwortlich Anforderungen um**, aber handeln mit **PO** aus, **welche** Anforderungen **wann umgesetzt** werden. **Scrum Master** (sollte nicht Teammitglied sein) **Unterstützt** Team **bei der Durchführung** des Projektes **Achtet auf Einhaltung des Prozesses** und **hilft bei konkreten Problemen** **Moderiert alle Meetings** \*(epics/features, verfeinert durch user stories) Mit Scrum kann man nicht nur Software entwickeln, sondern auch Hardware, Autos und andere Produkte. Bsp. Praktikum: Aufgabenstellungen sind Product Backlog.

Answer 9

Es beginnt mit **User Stories,** die im **_Product Backlog_** sind. Ein **Teil des Product Backlog** kommt **in das _Sprint Backlog_**. Mit dem **_Sprint Backlog_** geht es dann in das **_Sprint Planning_**. Jeden Tag wird ein **_Daily Scrum_** gemacht, d.h. man trifft sich morgens und jeder berichtet, was geschehen ist, was man heute machen möchte und was einen daran hindern könnte. Und danach geht es in die **_Daily Work_**. Irgendwann kommt es zu einem (**releasefähigem**) **Produktinkrement**, welches danach **im _Sprint Review_ angeschaut** wird. Damit kann man im **_Product Backlog_** schauen, **was bereits schon erledigt** ist. Am **_Sprint Review_** und an der **_Daily Work_** kann man erkennen, wie weit das **_Sprint Backlog_** abgearbeitet ist. Die Probleme, die im **_Daily Scrum_** angesprochen wurden werden in der **_Sprint Retrospective_** gelöst.

7 Projektplanung – Ablauforganisation, Vorgehensmodelle Flashcards

(36 cards)