7 Projektplanung – Ablauforganisation, Vorgehensmodelle

Question 1

!!! System-Lebenszyklus

nach ISO/IEC/IEEE TR 24748-1:2010

Answer 1

Produkt-Lebenszyklus

1. (Weiter)Entwicklung
2. Wartung
3. Außerbetriebnahme

Es werden drei große Bereiche unterschieden:
1. Entwicklung (Development): Produkt wird entwickelt

2. Wartung (Maintenance): Produkt ist in Produktion und wird noch gewartet

3. Außerbetriebnahme (Closedown): Beginnt mit Abkündigung des Produktes

Concept & Initial Development: Bei der Produktentwicklung haben wir zu Beginn ein Konzept (bspw. über Lean Canvas) und starten damit in das Initial Development.

Sobald das Produkt soweit entwickelt ist, dass man es liefern kann (supply). Jenach Vorgehensmodell ist das MVP schon ein sehr weit entwickeltes Produkt oder erst eines mit anfänglicher Funktionalität.

Production: Software ist beim Kunden. Währenddessen werden noch Änderungen vorgenommen. Nach vielen Jahren kann es sein, dass die Software soweit gewachsen ist, mit vielen Anbauten, sodass sie nicht mehr gut weiterzupflegen ist, woraufhin es in die Phase “Utilization” geht.

Utilization: Software ist noch in Gebrauch, wird aber nicht mehr weiterentwickelt (außer Service Patches).

Support: Wenn das Projekt abgemeldet wird, geht es in die “Support” Phase, in der es nur noch Security Patches gibt.

Retirement: Wenn die Firma das Produkt nicht mehr weiternutzt, geht das Projekt in Rente. (wenn es auf Server läuft, wird es auch abgeschaltet).

In PM kümmern wir uns nur um die erste Phase. Alles andere ist Software- und IT-Management.

Es werden drei große Bereiche unterschieden:
Entwicklung (Development): Produkt wird entwickelt

Wartung (Maintenance): Produkt ist in Produktion und wird noch gewartet

Außerbetriebnahme (Closedown): Beginnt mit Abkündigung des Produktes

Question 2

Software-Entwicklungsprozesse

(ISO/IEC/IEEE 12207-2017)

Wozu dient es bzw. was gibt es an?

Answer 2

Prozesse geben an, WAS bei professioneller Softwareentwicklung getan werden muss.

Hier sind die Prozesse, die für den Software-Lebenszyklus wichtig sind.

Man muss nicht alles tun, was in den Normen steht, aber man sollte wissen, warum man etwas nicht tut.

Man sollte von allem wissen, um sich dann bewusst entscheiden zu können, was man macht.

Question 3

Projekt-Lebenszyklus

Welche Aktivitäten/Ereignisse/Produkte

gehören zum Projekt-Lebenszyklus?

Answer 3

1. Projektinitiierung und -planung
2. Projektdurchführung, Meilensteine und Releases
3. Projektabschluss

Achtung: Projekt- und Produktlebenszyklus nicht verwechseln. Wenn das Projekt abgeschlossen ist, kann das Produkt noch weiterleben!

Wartung gehört nicht zum Projekt. Entweder neue Aufgabe oder neues Projekt.

Question 4

!!! Projektinitiierung

Was sind Ausgangspunkte für die Projektinitiierung?

Was wird bei der Projektinitiierung getan?

Answer 4

Ausgangspunkte können sein z.B.

Business Process Reengineering, Unternehmensmodellierung,

Verbesserungsvorschläge von der Anwenderseite,…

Erstellung kurzer Projektvorschläge (evtl. Formblatt, Lean Canvas).

Was sind die Projektziele? Worin liegt der Nutzen?

Wer sind die Stakeholder? Auf welcher Hardware/Software-Basis könnte das System laufen? Welche Rahmenbedingungen sind zu beachten?

Question 5

Projektauswahl

Was wird gemacht?

Welche Mitglieder treffen die Vorauswahl?

Was ist das Ziel der Projektvorauswahl?

Answer 5

Vorauswahl: Projektausschuss entscheidet, was im Unternehmen weitergemacht werden soll.

Mitglieder aus Fachabteilungen, Top-Management, IT-Abteilung
Neben den Projektvorschlägen jeweils kurze Stellungnahme der IT-Abteilung.

Ziel ist die Erstellung eines Rankings (→PM: Entscheidungstechniken)
Für vorselektierte Projekte wird dann eine Voruntersuchung durchgeführt. → Danach oft erneute Auswahlrunde der engeren Wahl.

Question 6

Projektlebenszyklus: Initiale Projektorganisation

Welche 2 Modelle sollte das Projektteam hierbei erarbeiten?

_{^{*i.d.R. nur 2 Leute: PO und jmd. der}}

_{^{erfahren ist mit Aufbauorganisationen}}

Answer 6

s3gt_translate_tooltip_mini { display: none !important; }

Zielmodell (Projektskizze/Lean Canvas) verfeinern

Projektziele werden genauer festgelegt

Nach Möglichkeit: Ableitung der Projektziele aus den Unternehmenszielen.

Aufbau einer Zielhierarchie: von strategischen Zielen zu operativen Zielen. Zielmodell kann später verwendet werden, um Entscheidungen zu treffen und zu hinterfragen.

Organisationsmodell skizzieren (→ Aufbauorganisation)

Welche organisatorischen Einheiten sind von dem Projekt betroffen und auf welcher Weise sind sie betroffen?

Wer ist ggf. Ansprechpartner?

Wie wird die Projektbeteiligung organisiert?

Question 7

Projekt-Lebenszyklus: Projektplanung

Nenne die Aktivitäten der Projektplanung

Welche Ergebnisse/Artefakte werden hier erstellt?

Answer 7

1. Aktivitäten
2. Projektaufbau festegen
3. Arbeitspakete (Aps) definieren (Work Breakdown Structure, WBS)
4. Aufwandsschätzung (präzisieren)
5. Ablauf festlegen
6. Ressourcen planen
7. Kosten berechnen
8. Projektplan optimieren
9. Projektplan fortschreiben
10. Ergebnisse/Artefakte

Aufbauplan (Organigramm)

Ablaufplan

Zeitplan & Meilensteinplan

Ressourcen- & Kostenplan

Question 8

Projektlebenszyklus: Kick-Off Meeting

mit allen Beteiligten

Answer 8

Projektziele für alle transparent machen

Commitment des Managements zeigen

Projektziele werden für alle transparent gemacht.

Der initiale Projektplan wird vermittelt und die Teambildung initiiert.

Bei _Matrix-Organisatione_n Führungsverantwortlichkeit offenlegen

Question 9

!!! Projektlebenszyklus: Meilenstein

Was ist ein Meilenstein?

Answer 9

s3gt_translate_tooltip_mini { display: none !important; }

Meilensteine = Termin + Ergebnis

… kennzeichnen den Beginn und das Ende des Projektes, den Abschluss jedes Arbeitspakets und meist auch den Abschluss einer Gruppe von Vorgängen innerhalb einer Phase.

… typische Zeitpunkte für

–die Konsolidierung der Projektdokumentation

–die Fortschreibung der Pläne

–Reviews und QS-Aktivitäten

–Projektpräsentationen

… sollten im Projektplan definiert sein

_{DIN 69900-1:1987 Projektwirtschaft –Netzplantechnik Teil 1: Begriffe}

Meilenstein (milestone): Ereignis von besonderer Bedeutung.

Question 10

Projektlebenszyklus:

Manche Meilensteine führen zu einem Release

1. Was ist ein Release?
2. Was beinhaltet ein Release?
3. Was beginnt mit dem Release?

Answer 10

s3gt_translate_tooltip_mini { display: none !important; }

1. Produkt wird in den Einsatz gebracht (geht in Produktion).

_{^{Kann bspw. in AppStore geladen werden.}}

2. Beinhaltet…

…Rechtzeitige Schulung der Anwender

…Bereitstellung der Hard-und Basissoftware am Einsatzort

…Fertigstellung und Distribution der Dokumentation

…Ggf. Bereitstellung einer Hotline

…Rufbereitschaft für Probleme in den ersten Einsatztagen

3. Mit dem Release beginnt die Wartungsphase (changerequests-> maintenance)
   * Wenn es noch nicht fertig ist sind 2 Dinge nötig:*
   * Wir müssen das Produkt weiterentwickeln und warten!*
   * In großen Projekten wird dann ein Maintenance-Team und ein Projekt-Team gebildet, die eng miteinander arbeiten.*

Question 11

!!! Projektlebenszyklus: Projektabschluss

1. Was sollte beim Projektabschluss getan werden?
2. Beim Projektabschluss beginnt die Wartungsphase. Welche Fragen ergeben sich dabei?
3. Was bedeutet der Projektabschluss für Projektmitarbeiter?

Answer 11

1. Kosten-und Wirtschaftlichkeitsnachrechnung

Projektabschluss institutionalisieren (Abschlussfeier!)

^{Ein Projekt ist nur dann wirklich gescheitert, wenn keiner etwas gelernt hat!}

2. Beginn der Wartungsphase

– Ist das System ordentlich dokumentiert?

– Sind alle Projektergebnisse und -daten archiviert?

– Wer ist zuständig für Fehlerbeseitigungen?

– Wer ist zuständig für Erweiterungswünsche?

3. Unsicherheit für die Projektmitarbeiter

Wie geht es mit mir in der Firma weiter und was ist meine nächste Aufgabe?

Question 12

Prozessmodellierung

Welchen Ursprung haben sie?

Wozu dienen Vorgehens-und Prozessmodelle?

Welche Darstellungsarten gibt es für Prozessmodelle?

Answer 12

Ursprung: Softwarekrise in den 60ern

Vorgehens-und Prozessmodelle zur Einsparung von Planungsarbeit

SW-Entwicklung sollte plan-und kontrollierbar werden

Strukturierung von Projekten

Gesamtaufgabe wird hierarchisch in Teilaktivitäten zergliedert.

Darstellung

häufig zerlegungsorientiert als Baum / Hierarchie

oder ablauforientiert als Graph (Knoten = Aktivitäten; Kanten = Abhängigkeiten)

Ergebnis soll wohldefiniert, überschaubar und mit klaren Schnittstellen zu anderen Aktivitäten sein!

Wasserfallmodell war eines der ersten Modelle.

Das muss präziser werden! Vor allem bei großen Projekten.

Question 13

1. Was sind die Elemente von Entwicklungsprozessen (Prozess-Metamodell)?
2. Zeichne das Prozess-Metamodell

Answer 13

Ziele geben an, warum etwas ausgeführt wird.

Aktivitäten spezifizieren, was ausgeführt wird.

Rollen zeigen, wer etwas ausführt bzw. ausführen kann/darf.

Phasen beschreiben wann was ausgeführt wird.

Techniken geben an, wie etwas ausgeführt wird.

Artefakte beschreiben Daten, also womit etwas ausgeführt wird.

Question 14

Prozessmodellierung Aktivität

Beschreibe die Grafik

Answer 14

Aktivität hat Eingaben (Vorbedingung. D.h. Artefakte die benötigt werden, um Aktivität zu starten) und Ausgaben (Artefakte)

Question 15

Vorgehensmodelle: Wasserfallmodell

1. Nenne Eigenschaften und
2. Probleme dieses Modells

Answer 15

1.

Zeitorientiert

Phase = Rolle = Aktivität (Kästchen sagen vieles in einem)

Sequenziell - monolithisch

2. Probleme:
   - Fehler zu spät entdeckt

• Risiken ans Ende geschoben
• Anforderungsdrift nicht behandelbar
• Produkt erst am Entwicklungsende

Bsp. Analyse und Definition machen die Anforderungsermittler

Monolithisch

-> man macht Analyse und Definition für das Gesamtprodukt.

Damals oft 1-2 Jahre nur Anforderungsermittlung.

#s3gt_translate_tooltip_mini { display: none !important; }

Question 16

Vorgehensmodelle: Iteriertes Wasserfallmodell

1. Nenne Eigenschaften und
2. Probleme dieses Modells

Answer 16

1.

Zeitorientiert

Phase = Rolle = Aktivität

Iterativ - monolithisch

2. Probleme:
   - Risiken ans Ende geschoben

• Anforderungsdrift nicht behandelbar
• Produkt erst am Entwicklungsende

Dass Problem, dass Fehler zu spät entdeckt werden, gibt es durch die Iteration nicht mehr im Vgl. zum “normalen” Wasserfallmodell.

Um Usabilitytests früh zu machen wird Prototyping hinzugefügt.

Question 17

Vorgehensmodell: Spiralmodell

1. Nenne Eigenschaften und
2. Probleme dieses Modells

Answer 17

1.

Produktorientiert

Phase _^ungleich Rolle _^ungleich Aktivität

Iterativ - monolithisch

2. Probleme:
   - Schlecht planbar

• Produkt erst am Entwicklungsende

Aufgewickeltes Wasserfallmodell. Zeit läuft spiralförmig.

Aber mit eingebautem Projektmanagement (planen, delegieren, bewerten, ausführen und prüfen…)

#s3gt_translate_tooltip_mini { display: none !important; }

Question 18

Vorgehensmodell: (Rational) Unified Process

1. Nenne Eigenschaften und
2. Probleme dieses Modells

Answer 18

1.

Produktorientiert

Phase Rolle Aktivität

Iterativ - inkrementell (Produkt wächst schrittweise)

Man kann sich einen kleinen Teil des Produktes anschauen und diesen dann erweitern. Dann kommt man zu iterativ inkrementellen Modellen, wie dem Rational Unified Process.

Aktivitäten werden überlappend ausgeführt. Nach jeder Iteration wird ein Produkt ausgeliefert.

Question 19

V-Modell XT

1. Was ist das V-Modell XT und worauf basiert es?
2. Wann war das erste Release und
3. welches Modell hat es derzeit abgelöst?
4. was ist die aktuelle Version?

(Gutes Prozessmodell! Im Unified Process

findet sich auch das V-Modell XT wieder.)

Answer 19

1. Flexibles Modell des Bundes und der Länder zum Planen und Durchführen von System-bzw. Software-Entwicklungsprojekten.

Basiert auf aufeinander aufbauenden Vorgehensbausteinen.

2. Erstes Release: Februar 2005 (Apache Lizenz V. 2.0);
3. löste das bis dahin geltende V-Modell 97 ab
4. Aktuell (Stand 2020): Version 2.3

V-Modell XT ist auch iterativ - inkrementell!

“V-Modell” heißt es, weil die Testphase und Auslieferung, die beim Wasserfallmodell ganz unten rechts ist, ist beim V-Modell nach oben gezogen und unterteilt worden in Komponenten- Integrations, Abnahmetest, sodass man dann ein V gemacht hat.

*Produkte stehen im Zentrum des V-Modell XT

Question 20

V-Modell XT

Was beschreibt ein Vorgehensbaustein?

Was ist Tailoring?

Answer 20

s3gt_translate_tooltip_mini { display: none !important; }

Vorgehensbaustein: beschreibt alle inhaltlich zusammengehörigen Produkte, Aktivitäten und Rollen.

Tailoring: Projektspezifische Anpassung des V-Modell XT (XT = Extreme Tailoring). Tailoring liefert Vorgehensbausteine.

Diese prüfenden QS-Produkte & die bearbeitenden Aktivitäten sind im V-Modell XT nicht mehr im Submodell QS -Qualitätssicherung, sondern direkt im Vorgehensbaustein SE –Systementwicklung enthalten.

Question 21

V-Modell XT

Was sind Produkte und an was sind sie geknüpft?

Answer 21

Produkte* (Artefakte) stehen beim V-Modell XT im Vordergrund und sind durch inhaltliche & erzeugende Produktabhängigkeiten verknüpft:

Bsp: Prüfspezifikation & Prüfung(-sdurchführung) eines Systemelements werden direkt mit zugehörigen Produktabhängigkeit erzeugt.

D.h., das Erzeugen eines Software-Komponente erzeugt gleichzeitig die zugehörigen Prüfaktivitäten.

Diese prüfenden QS-Produkte & die bearbeitenden Aktivitäten sind im V-Modell XT nicht mehr im Submodell QS -Qualitätssicherung, sondern direkt im Vorgehensbaustein SE –Systementwicklung enthalten.

#s3gt_translate_tooltip_mini { display: none !important; }

Question 22

V-Modell XT

Erläuter die vorgehensbaustein-

übergreifende Strukturierung.

Answer 22

Vgl. Prozessmodell

Aktivitäten erzeugen Produkte (Artefakte)

Für Produkte ist jmd. verantwortlich, der eine bestimmte Rolle spielt.

Produkte behandeln bestimmte Entwicklungsthemen.

Aktivität ist unterteilt in Teilaktivitäten.

Teilaktivitäten bearbeiten die Themen und tragen damit zum Produkt bei.

Produkte können in Gruppen zusammengefasst werden. Aktivitäten können in Aktivitätsgruppen zusammengefasst werden.

Question 23

V-Modell XT

Zeichne das Strukturmodell

Answer 23

Wichtig:

Produktorientiert!!!

Produkt ungleich Rolle ungleich Aktivität

Reihenfolge nur über Abhängigkeiten

Question 24

V-Modell XT

Projektdurchführungsstrategien und Entscheidungspunkte (1)

Was definiert die Projektdurchführungsstrategie

und was beinhaltet sie?

Answer 24

Projektdurchführungsstrategie

definiert Reihenfolge der zu erreichenden Projektfortschrittsstufen bzw. relevanter Entscheidungspunkte (Meilensteine) und

beinhaltet die die Entwicklungsstrategie*.

*Inkrementelle Entwicklung, komponentenbasierte

Entwicklung oder prototypische (bzw. agile) Entwicklung

Question 25

V-Modell XT

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 25

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.

Question 26

V-Modell XT

Ziel- und Ergebnisorientierte Vorgehensweise

______ (_______) stehen im Mittelpunkt, sie sind DIE Projektergebnisse.

__ und __ werden klar getrennt.

Detaillierte Projektplanung und -steuerung wird auf der Basis der Bearbeitung und Fertigstellung von _______ durchgeführt.

Für jedes ______ ist eindeutig eine ____ verantwortlich und im Projekt eine der Rolle zugeordnete Person.

Produktqualität ist überprüfbar durch definierte ________ an das ______ und explizite Beschreibungen der Abhängigkeiten zu anderen _________.

Answer 26

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.

Question 27

V-Modell XT Zustände von Artefakten

1. Zeichne die Zustandsgrafik von Produkten
2. Erläutere die 4 Zustände von Produkten (Artefakte)
3. Wodurch werden Zustandswechsel ausgelöst?

Answer 27

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

Question 28

Einordnung des V-Modell XT

Answer 28

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

Question 29

Manifesto for Agile Software Development

Nenne die 4 agilen Werte (Manifesto…)

Answer 29

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!

Question 30

Agile Vorgehensweise mit XP (eXtreme Programming)

Answer 30

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.

Question 31

Was sind die Voraussetzungen für XP?

Answer 31

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.

Question 32

1. Was ist Scrum?
2. Erläutere die Rollen in Scrum.

Answer 32

… 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.

Question 33

Scrum: Rollen, Produkte, Prozess

Answer 33

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.