PROJEKTMANAGEMENT, Kapitel8services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel08.pdfZiele Stake- holder werden vertreten durch behindert tritt ein mit bewirkt Qualität Projektleiter

So#waretechnik

Prof. Dr. Wolfgang Schramm

PROJEKTMANAGEMENT Kapitel 8

1

Übersicht

1.  Einführung in das SoAware Engineering

2.  SoAwareprozesse 3.  Anforderungsanalyse und -‐

SpezifikaLon 4.  SoAwareentwurf 5.  Programmierung 6.  SoAware-‐Qualitätssicherung und –

Prüfung 7.  KonfiguraLonsverwaltung 8.  Projektmanagement

2

Diskussion

1.  Welche sinnvollen Reihenfolgen der folgenden AkLvitäten gibt es: a)  Terminplanung b)  Reihenfolgeplanung c)  Aufwandsplanung d)  Aufgabenplanung

2.  Welche Inhalte gehören zu einem Arbeitspaket? 3.  Warum unterscheidet man zwischen Aufwand und Dauer? 4.  Wie läuA eine Schätzklausur ab?

3

Ziele

¨  Sie kennen den Nutzen von Projektplanung.

¨  Sie kennen grundlegende Aufgaben der Projektplanung und des Risikomanagements.

4

Kapitelübersicht

1.  Einführung & Begriffe 2.  Aufgaben-‐ & Reihenfolgeplanung 3.  Aufwandsplanung 4.  Personal-‐ & Terminplanung 5.  DokumentaLon 6.  Risikomanagement

5

Magisches Viereck (1)

Funktions- umfang

Zeit Kosten

Qualität

6


7


Funktions- umfang

Zeit Kosten

Qualität

„Fläche konstant“ ≈ Produktivität

8

Aufgaben des Projektleiters

führen

motivieren informieren

Ziele setzen Aktivitäten festlegen

Rollen, Strukturen, Informationsfluss

festlegen

Personal auswählen, entlassen,

weiterbilden…

für Ziele begeistern, verhandeln, delegieren, entscheiden

Status wissen, Risiken erkennen,

umplanen

9

Prozessgruppen des Projektmanagements

Start Initiating

•  Projektziel

•  Projektleiter

Planung Planning

•  Phasen und Meilensteine •  Strukturplan, Netzplan

•  Aufwand, Terminschätzung

•  Personal

Ausführung Executing

•  Risikomanagement •  Qualitätssicherung

•  Teamführung

•  Information

Abschluss Closing

•  Ergebnisabnahme •  Erfahrungssicherung

Steuerung Controlling

•  Istdatenerfassung •  Soll-Ist-Vergleich

•  Fortschritt

•  Planabweichung

10

Kapitelübersicht


11

Projekt-‐Strukturplan (1)

o  DefiniLon ¤  alle zur Erreichung des Projektzieles notwendigen Aufgaben ¤  dargestellt in einer hierarchischen Anordnung

o  Abkürzung ¤  PSP ¤  WBS (work breakdown structure)

12

Projekt-‐Strukturplan (2)

o  Zweck ¤  Zerlegung des Projektes in überschaubare Einheiten

n  Auflistung aller TäLgkeiten Beispiele: n  Anforderungen erheben n  Modul implemenLeren n  Aufgaben planen n  Produkt freigeben

¤  Grundlage aller weiterer n  Planung n  Projektmanagement-‐AkLvitäten

13

Beispiel Projekt-‐Strukturplan

14

Arbeitspaket (1)

o  DefiniLon ¤  DIN 69901:

n  Kleinste, nicht mehr sinnvoll zu unterteilende Verantwortungseinheit ¤  Alle im PSP nicht weiter unterteilten Aufgaben, d.h. Bläier des PSP

o  Abkürzung ¤  AP ¤  WP (work package)

15

Arbeitspaket (2)

o  Zweck ¤  Festlegen von Arbeitsschriien mit

n  …klar umrissenem Ergebnis n  abgeschlossen n  überprülar

n  …klarer Verantwortung n  …festlegbarem Aufwand und Terminen

n  Beispiel: Umfang eines AP bei kleinen Projekten 1-‐2 Tage für 1-‐2 Personen

16

Beispiel Arbeitspaket (Blai)

17

Beispiel Arbeitspakete (Tabelle)

Nr Name / Beschr. Ergebnis Auf-wand

Ver-antw.

Be-teiligt

An- merk.

1 Anforderungen klären

Fragen listen, mit Kunden klären

Entwurf Pflichten-heft

15ph Ute Udo, Uwe

…

2 GUI-Prototyp erstellen

Klick-bares HTML, mit Kunden ab-sprechen

Abge-stimmter Prototyp

20ph Otto Olga, Ove

So ausführlich wie nötig!

Name = Substantiv + Verb

Produkt + Qualität „Anmerkungen“

für alles weitere

Kommt später

18

Beispiel Projekt-‐Strukturplan (2)

19

Ablaufplan (Reihenfolge der AP)

A

D

C

B

E

Beziehungen: -  Z nach X (Bsp.: D nach B) -  Z nach X und Y (Bsp.: E nach C und D) -  X und Y nach Z (Bsp.: B und C nach A) -  X und Z gleichzeitig (Bsp.: B und C parallel)

20

Beispiel für Ablaufplan (AP Reihenfolge)

Erheben von Anforderungen

Erstellen der Architektur

Erstellen von Testfällen für Akzeptanztest

Feststellen der Infrastruktur

Erstellen des Grobdesigns

21

Kapitelübersicht


22

Aufwand (1)

o  Zweck ¤  Arbeitsaufwand für AP/Projekt besLmmen

o  Maße ¤  PJ – Personenjahre

py -‐ person year ¤  PM – Personenmonat

pm -‐ person month ¤  PT – Personentage

pd -‐ person day

Daumenregel: Aufwand = #Personen x Dauer

Aufwand in Personentagen Dauer in Tagen

23

Aufwand (2)

o  Vorsicht ¤  Personentag = Arbeitszeit für Projekt ¤  Mitarbeiter/in

n  Arbeitet an Projekt n  Arbeitet an anderen Projekten n  Nimmt teil an Firmenereignissen

(z.B. Abteilungstreffen) n  Bildet sich weiter n  Hat Urlaub n  Ist krank …

¤  Umrechnung n  1 PJ = 250 PT ? n  1 PJ = 200 PT ?

Oft: Personentage „netto“

(nur Projektarbeit) Personenjahre „brutto“

(Projektarbeit, Urlaub, Abteilungstreffen, etc.)

24

Aufwandsschätzung – Methoden (1)

o  Expertenschätzung ¤  Befragung erfahrener Mitarbeiter/innen ¤  Vorgehen

n  Schätzklausur/Delphimethode n  Dreipunktschätzung n  Informelle Expertenschätzung

o  Erweiterungen ¤  DekomposiLon (Aufwand = Summe der Teilaufwände) ¤  Mengen (Aufwand = c*Einzelaufwand, Bsp. 10 Bildmasken) ¤  Analogie (Aufwand = Aufwand eines früheren Projekts) ¤  RelaLon (Aufwand = a*Phase1 + b*Phase2)

25

Aufwandsschätzung – Methoden (2)

o  FuncLon Points ¤  Größenmaß ¤  Basiert auf E/A-‐OperaLon + Einflussfaktoren ¤  Durchführung durch akkrediLerte FP-‐Zähler ¤  Umrechnung FPàAufwand: prozess-‐spezifische Faktoren

o  Parametrische Schätzverfahren (COCOMO) ¤  Aufwandsmaß ¤  Eingabe: Größe (z.B. LoC) ¤  Basiert auf mathemaLschen Modellen

(abgeleitet von realen Projekten)

26

Expertenschätzung: Schätzklausur (1)

o  Zweck ¤  Schätzen des Aufwands durch Experten

•  Vorbereitung l  Teilnehmer:

ð Projektintern und –extern ð  3 – 7 Teilnehmer

l  Moderierte Sitzung ð Moderator bestimmen (kann auch mitstimmen)

l  Unterlagen bereitstellen/lesen ð AP-Beschreibungen ð Randbedingungen

² Zeit, Kosten ² Projektmitarbeiter/innen ² Besonderheiten

„Delphi-Methode“

27

Expertenschätzung: Schätzklausur (2)

o  Durchführung ¤  Gegebenenfalls:

Auswahl von TäLgkeiten und Schätzverfahren ¤  Für jedes AP:

n  Anonyme, schriAliche Schätzung n  Zusammenstellen der Einzelschätzungen, Miielwert-‐ / Median-‐Bildung

n  Ggf. Verwerfen der Extremwerte n  Diskussion der Ergebnisse (insbesondere bei starken Abweichungen)

n  Ggf. Korrektur der Einzelschätzungen, Neuschätzung

¤  Schätzen der Genauigkeit der Schätzung ¤  Protokollieren der Ergebnisse

genauer ist: „ausdiskutieren“

28

Kapitelübersicht


29

Personal/Dauer eines AP (1)

Maier 7PT 50% 14T Schmidt 8PT 100% 8T Müller 2PT 20% 10T

17PT 14T Berechnung

Alternative Berechnung

�

� �

�

30

Personal/Dauer eines AP (2)

� Wer arbeitet am AP? Wie viel arbeitet eine Person am AP? ¤  Kriterien à Minimieren der Dauer

à Nutzen spezieller Kompetenzen à Verbessern der Qualität (4-‐Augen-‐Prinzip)

� Wie viel Zeit hat eine Person für das AP? ¤  Kriterien à Aufwand dieser Person

à Parallelarbeit dieser Person à Arbeit dieser Person an anderen Projekten

� Wie lange arbeitet die Person an dem AP? ¤  Berechnung à DauerPerson = AufwandPerson / PE

� Wie lange dauert das AP? ¤  Berechnung à DauerAP = MAX (∀Personen: DauerPerson)

31

Beispiel Arbeitspakete (Tabelle)

Nr Name / Beschr. Ergebnis Auf-wand

Ver-antw.

Be-teiligt

An- merk.

1 Anforderungen klären

Fragen listen, mit Kunden klären

Entwurf PH

15ph Ute Udo, Uwe

…

2 GUI-Prototyp erstellen

Klickbares HTML, mit Kunden ab-sprechen

Abge-stimmter Prototyp

20ph Otto Olga, Ove

wer? wie aufwändig?

War schon dran

32

Terminberechung mit CPM: Gegeben

Menge von AP mit ¤  Dauer (à Knoteneintrag) ¤  Vorgänger, Nachfolger (à Netzplan)

Genau ein Anfangs-‐AP AP0, genau ein Ende-‐AP APZ

Knoteneinträge für ein AP ¤  AP = AP-‐Nummer ¤  Dau = Dau (z.B. in PT) ¤  Puf = Puffer ¤  FAT = frühester Anfangstermin

FET = frühester Endtermin ¤  SAT = spätester Anfangstermin

SET = spätester Endtermin

(nur AP und Dau mit Wert, die anderen Einträge werden errechnet)

Netzplan

AP Dau Puf FAT SAT

FET SET

33

Terminberechung mit CPM: Gesucht

1.  Frühester FerLgstellungstermin „Vorwärtsrechnung“

(FAT0 = FAT von AP0 usw.) ¤  Beginn beim ersten AP ¤  AP0:

¤  APi (i≠0): APn, … APm Vorgänger von APi

2.  Spätester Stariermin „Rückwärtsrechung“ ¤  Beginn bei letztem AP ¤  APZ:

¤  APi (i≠Z): APn, … APm Nachfolger von APi

iii

ki

DauFATFET

)FET(FAT

+=

==

n

mkmax

00

0

DauFETFAT

=

= 0

iii

ki

DauSETSAT

)SAT(SET

−=

==

m

nkmin

ZZ

ZZ

FATSATFETSET

=

=

3.  Puffer „Rückwärtsrechung“ l  Für jedes APi:

iii FETSETDau −=

34

CPM: Vorwärtsrechnung

AP3 3

AP1 5 0

„wann ist das Projekt frühestens fertig?“ „wann kann ein AP frühestens starten?“

AP2 4

5

AP Dau Puf FAT SAT

FET SET

AP4

5

10

AP5 2

5

15

15

12

Beziehung zwischen AP: immer Ende-Anfang

5

5 5

5

5

9 9 9 9 9

15

12

17

35

CPM: Rückwärtsrechnung

AP3 3

AP1 5 0

„wann ist das Projekt frühestens fertig?“ „wann kann ein AP frühestens starten?“

AP2 4

5

AP Dau Puf FAT SAT

FET SET

AP4

5

10

AP5 2

5

15

Beziehung zwischen AP: immer Ende-Anfang

5

5

9 9

15

12

17 17 15

15

15

5

12 12 8

5 0

36

CPM: Pufferzeiten / KriLscher Pfad

AP3 3

AP1 5 0

„welche AP können Termin-neutral verschoben werden?“

AP2 4

5

AP Dau Puf FAT SAT

FET SET

AP4

5

10

AP5 2

5

15

5

5

9 9

15

12

17 17 15

15

15

5

12 12 8

5 0

0 0

3 3 3

0

0

„bei welchen AP wirken Verschiebungen sich auf das Projekt aus?“

Kritischer Pfad Definition:

Folge von AP ohne Puffer

ACHTUNG: falls Schätzung ungenau kann sich bei Neu-Schätzung der Pfad ändern!

37

Kapitelübersicht


38

Projekthandbuch (1)

o  DefiniLon ¤  Sammlung ALLER InformaLonen

für das Projektmanagement

o  Abkürzung ¤  ./.

o  Synonym ¤  Projekt-‐

management-‐ plan „Virtuelles“ Buch

langfristig konstante Information: im Dokument

kurzfristig sich verändernde Information: Verweis

39

Projekthandbuch (2)

o  Ziel ¤  Jederzeit Überblick über Projekt und Projektstatus

n  „root“ für alle relevante Info und Doku

n  Übersicht über aktuelle Info

n  Überblick für Neueinsteiger

40

Projekthandbuch nach IEEE 1058

1.  Overview

2.  Reference

3.  Definitions

4.  Project organization

5.  Managerial process plans

6.  Technical process plans

7.  Supporting process plans

8.  Additional plans

Team (Telefon, EMail, …) Rollen Kunde

Planung (wo sind die Unterlagen?)

Kontrolle Risikomanagement

Prozess (Scrum) Anpassungen

(wer ist Product Owner?)

Konfigurationsmgmt. Qualitätsmgmt.

Infrastruktur

41

Gani-‐Chart -‐ Beispiel: MS Project

Meilenstein Vorgang / Aktivität

„Sammel- vorgang“ Abhängigkeit

Grobplanung Feinplanung

42

Kapitelübersicht


43

Warum Risikomanagement?

Risikomanagement ¤  … hilA mögliche Probleme frühzeiLg zu erkennen ¤  … hilA mögliche Chancen zu nutzen ¤  … ermöglicht begrenzte Ressourcen effekLv zu nutzen

¤  Frühes Erkennen möglicher Probleme n  ermöglicht Beheben von Fehlern

n  die früh erkannt günsLg zu beheben sind n  die in späteren Phasen hohe Kosten verursachen

¤  Frühes Erkennen günsLger Gelegenheiten n  ermöglicht deren Nutzen

n  um Kosten zu sparen/Freiräume zu schaffen

44

Risiko

Wahrschein- lichkeit Schaden

Risiko

Ziele

Stake- holder

werden vertreten durch

behindert

bewirkt tritt ein mit

Projektleiter Team

Öffentlichkeit

Kompetenzen Neue Technologie

typische Ziele Zeit

Kosten Funktionalität

Qualität

typische Stakeholder

Kunde Abteilungsleiter Oberes Mgmt.

45

Risikomanagement-‐Prozess

Mandat &Ziele

Identifi- kation

Über- wachung

Analyse Maß-

nahmen- durchf.

Maß- nahmenplanung

Er- fahrungs-

sich.

Proj.- Manage-

ment

46

Mandat/Ziele

o  Mandat ¤  Wie läuA Risikomanagement ab

n  Wann sind Sitzungen? n  Welche Methoden werden eingesetzt? n  Wie wird dokumenLert?

o  Ziele n  Welche Ziele wollen wir erreichen n  Schaden = negaLver Einfluss auf Ziel

n  Beispiel Termin fix à 2 Wochen Verzug = großer Schaden Termin nicht so wichLg à 2 Wochen Verzug = kleiner Schaden

47

IdenLfikaLon

o  Erstellen einer Liste von „Roh-‐Risiken“ ¤  Brainstorming ¤  Checklisten

Cluster Id Risk Design skills 1 Not enough people are familiar with OOA and

OOD 2 Developers are required to learn the new

technology 3 Bad design due to missing OO experience

Java skills 4 Not enough time for Java training 5 Newbies in Java develop poor code

Performance 6 Performance not acceptable 9 Performance inadequate

10 Poor performance -> no customer acceptance ... ...

48

Analyse -‐ Beschreibung

o  Risk Statement ¤  Risikobeschreibung mit bedingter Aussage

n  WENN-‐Teil: aktuelle SituaLon, mögliches Ergebnis

n  DANN-‐Teil: Auswirkungen auf die Ziele

Beispiel WENN die GUI mit JSF erstellt werden muss und wir keine JSF-‐Erfahrung haben, DANN wird die GUI zu spät ferLg und wird nicht die Anforderungen an ein modernes GUI erfüllen

49

Analyse -‐ Bewertung

o  Ranking ¤  …bzgl. Wahrscheinlichkeit P ¤  …bzgl. Schaden L

n  Vorgehen 1.  Erstelle eine nach

Wahrscheinlichkeit geordnete Liste von 5 (prototypischen) Risiken

2.  Ordne weitere Risiken in diese Liste ein 3.  Den Risiken wird damit ein Rang bzgl. P und L zugeordnet

o  Pareto-Ranking

o  TOP-5-Liste H 5

C 4 B E F 3

G 2 D A 1

Loss

5 4 3 2 1 Probability Rank

Poor quality code 4 Poor performance/optimize 5

Poor performance/accept it 3

Poor performace/reimpl.C++ 2

Prototype not adequate 1

Prototypical Risks P

50

Maßnahmenplanung

o  Todo-‐Liste erstellen ¤  Maßnahmen

n  Risiko vermeiden z.B. externen Architekt hinzuziehen n  Risiko vermindern z.B. mit Kunden sprechen n  Nozallplan z.B. alternaLve Bibliothek auswählen

¤  Brainstorming, Bewertung/Auswahl

Lfd. Nr. Risiko Wer Was Bis wann Ergebnis

Risiko, gegen das die Maßnahme helfen soll

Auswirkungen auf das Risiko

51

Überwachung

o  Überwachungsfragen ¤  Bzgl. Risiken

n  Hat sich die Projektsituation geändert? Haben wir einen Meilenstein erreicht?

n  Ggf. Identifikation, Analyse

¤  Bzgl. Maßnahmen n  Wie ist der Status der Maßnahmen? n  Wirken die Maßnahmen?

n  Ggf. Maßnahmen(neu)planung n  Ggf. ein Risiko schließen

Risk Monitoring is one of the most important .

risk management activities .

52

photography: woodleywonderworks http://www.flickr.com/photos/wwworks/2350106729

art work: Peter Kaiser

F R A G E N

53

Nachgefragt

o  Erklären Sie ¤  Warum ist es sinnvoll, Ziele / Planwerte zu quanLfizieren? ¤  Warum ist normalerweise eine Verfeinerung von Zielen sinnvoll?

o  Überlegen Sie, wann/bei welcher Gelegenheit und wie Sie ein Burn-‐Down-‐Chart präsenLeren würden ¤  Was würden Sie erklären? ¤  Was für Fragen erwarten Sie? ¤  Lassen sich alle Fragen anhand des Charts beantworten?

Falls Fragen offen bleiben: Welches Material häien Sie (als Projektleiter) gerne, um sie zu beantworten?

54

Ziele

¨  Sie kennen den Nutzen von Projektkontrolle.

¨  Sie kennen grundlegende Aufgaben der Projektkontrolle.

55

Kapitelübersicht

1.  Einführung 2.  Monitoring 3.  Statusbericht

57

Vorgehen

nach Hans W. Wieczorrek, Peter Mertens: Management von IT-Projekten, Springer, 2011

58

Vorgehen – Beispiel Termin

o  Setzen von Zielen Endtermin 30-‐Nov-‐2013 o  Verfeinern der Ziele Endtermin o  QuanLfizierung 30-‐Nov-‐2013 o  Messen der Zielerreichung 15-‐Dez-‐2013 o  Feststellung der Abweichung +14 Tage o  Abweichungsanalyse erhöhter techn. Aufwand o  Durchführen von Maßnahmen nicht mehr möglich

Aufgabe der Projektkontrolle: Abweichungen vom Plan so früh erkennen, dass Umplanung möglich

keine Verfeinerung

59

Vorgehen – Beispiel Arbeitspaket

o  Setzen des Ziels Endtermin 30-‐Nov-‐2013 o  Verfeinern des Zieles Arbeitspakete o  QuanLfizierung Aufwand: 24ph o  Messen der Zielerreichung Ist: 20ph; Rest: 16ph o  Feststellung der Abweichung +12ph o  Abweichungsanalyse erhöhter techn. Aufwand o  Durchführen von Maßnahmen -‐ Wahl der alternaLven

Techn. -‐ Streichen einer Kann-‐Anf. -‐ Hinzufügen von

Mitarbeitern

Handlungsoptionen (ggf. Kunden fragen!)

60

o  Aufwand/Termin o  Qualität o  Kosten o  Mitarbeiterfähigkeiten/-‐moLvaLon o  Produktscope/Anforderungsänderungen o  ProjekLnfrastruktur o  etc.

Was wird kontrolliert?

im Folgenden näher betrachtet

61

Wann wird kontrolliert

o  Monitoring ¤  Der Projektleiter weiß jederzeit, wie das Projekt bzgl. der

beobachteten Kriterien steht ¤  Z.B. Aufwand

tägliches Erfassen des Ist/Rest-‐Aufwands Ist-‐Aufwand: tatsächlich erbrachter Aufwand Rest-‐Aufwand: noch zu erbringender Aufwand (Plan-‐Aufwand: iniLal geplanter Aufwand)

o  Statusbericht ¤  Der Projektleiter berichtet regelmäßig über den Status ¤  Z.B. wöchentlicher Statusbericht

über die vergangene Woche, den vergangenen Sprint, die kommende Woche/den kommenden Sprint

62

Kapitelübersicht


63

Aufwands-‐Monitoring

o  Idee ¤  Es exisLert realisLsche Planung à Plan-‐Wert

n  AP: Aufwand; Zeitraum (Beginn-‐Ende oder Intervall) ¤  Es wird der FerLgstellungsgrad der AP regelmäßig abgefragt

à Ist-‐Wert ¤  Es werden Plan-‐ und Ist-‐Wert verglichen

o  FerLgstellunggrad feststellen (AlternaLven) ¤  0,1 (ein AP ist ferLg oder nicht) ¤  FerLgstellung in % schätzen ¤  FerLgstellunggrad a priori definieren

Idee 10%, Entwurf 30%, Prüfung 15%, FerLgstellung 20%, Freigabe 15% ¤  Schätzen, wie viel Aufwand noch zu erbringen ist à Rest-‐Wert

AP: Arbeitspaket

64

Burn-‐Down-‐Chart (1)

o  Zweck ¤  Aufwands-‐Monitoring

o  Idee ¤  für eine festgelegte Zeitspanne („Sprint“, z.B. 2 oder 4 Wochen)

n  Verfügbarer Aufwand = #Personen × Dauer (Tage) × h pro Tag n  Menge von AP festlegen, wobei gilt

verfügbarer Aufwand = Σ Aufwand aller AP

¤  Täglich für alle in Arbeit befindlichen AP Rest-‐Aufwand (neu) schätzen n  Verfügbaren Aufwand aktualisieren n  Aufwand für AP aktualisieren

n  Noch nicht Begonnene: Plan-‐Wert n  Begonnene: Rest-‐Wert n  FerLggestellte: 0 ph

65

Einleitung ■■■ Monitoring ■■■ Statusbericht

0

50

100

150

200

250

300

350

0 1 2 3 4 5 6 7 8 9 10 11

pers

on h

ours

days

Burn Down Chart Project Y

ph planned ph available

5 Personen à 6h = 30ph pro Tag

Day 0

68


0

50

100

150

200

250

300

350

0 1 2 3 4 5 6 7 8 9 10 11

pers

on h

ours

days



Day 1

69


0

50

100

150

200

250

300

350

0 1 2 3 4 5 6 7 8 9 10 11

pers

on h

ours

days



Day 3

Weniger geschafft als geplant. Umplanen!

70


0

50

100

150

200

250

300

350

0 1 2 3 4 5 6 7 8 9 10 11

pers

on h

ours

days



Umgeplant AP gestrichen aus

diesem Sprint

Day 3

nach Umplanung

71


0

50

100

150

200

250

300

350

0 1 2 3 4 5 6 7 8 9 10 11

pers

on h

ours

days



Day 6

Mehr geschafft als geplant.

Umplanen!

72


0

50

100

150

200

250

300

350

0 1 2 3 4 5 6 7 8 9 10 11

pers

on h

ours

days



Day 6

nach Umplanung

Umgeplant AP hinzugefügt in

diesem Sprint

73


0

50

100

150

200

250

300

350

0 1 2 3 4 5 6 7 8 9 10 11

pers

on h

ours

days



Day 10

74

Qualitäts-‐Monitoring

o  Idee 1 (SpezifikaLonen, ggf. Code) ¤  Es exisLert Planung von

n  Produkten und n  Reviews

¤  Reviews stellen Qualität fest

o  Idee 2 (ausführbarer Code) ¤  Es exisLert Planung von

n  Modulen n  Tests

¤  Es wird überprüA n  Wie viele Tests wurden (erfolgreich) ausgeführt? n  Wie viele Fehler wurden gefunden?

Testfortschritt

Fehlerkurve

75

76

77

Kapitelübersicht


78

Projektberichte

o  Projektreport à Kunde (extern) ¤  ProduktorienLert ¤  FortschriisorienLert ¤  LösungsorienLert

o  Projektstatus à Management (intern) ¤  PlaneinhaltungsorienLert ¤  Problem-‐/RisikoorienLert ¤  QualitätsorienLert

o  Projektreview à Board (extern/intern) ¤  Projektreport

+ Projektstatus ¤  Abhängig vom Board

kurz (1 Seite) schriftlich

kurz (5 Min) mündlich ev. schriftl. Kurzfassung

länger (30 Min – 1 Tag) mündlich und schriftlich

Inhalt, Format, Name, Dauer, hängen

vom Adres- saten

ab!


80

Plan/Ist/Aktualisiert (1)

0

20

40

60

80

100

120

140

plan

ist

aktualisiert

¨  Aufwandszahlen ¤  beziehen sich auf Intervall ¤  z.B. Sprint, nächster Meilenstein

¨  plan ¤  iniLal geplanter Aufwand ¤  wird nicht verändert

¨  ist ¤  aktuell verbrauchter Aufwand

¨  aktualisiert(er Plan) ¤  neu geschätzter Aufwand

„PIA“

ph


81


0

20

40

60

80

100

120

140

plan

ist

aktualisiert

¨  Miie des Intervalls ¤  Halbe Zeit = halber Aufwand ¤  „aktualisiert“

n  nicht begonnene AP: „plan“-‐Aufwand

n  ferLggestellte AP: „ist“-‐Aufwand

n  AP in Arbeit: „ist“-‐Aufwand + Restaufwand

¤  Hier: „aktualisiert“ = „plan“ n  Keine Abweichung vom Plan

ph

„PIA“


82


0

20

40

60

80

100

120

140

160

plan

ist

aktualisiert

¨  Miie des Intervalls ¤  Halbe Zeit = halber Aufwand ¤  „Hier: „aktualisiert“ > „plan“

n  mehr Aufwand erforderlich als geplant

n  eine Umplanung hat noch nicht staigefunden

ph

„PIA“


83


0

20

40

60

80

100

120

140

160

180

200

plan

ist

aktualisiert

¨  Miie des Intervalls ¤  Halbe Zeit = halber Aufwand ¤  „Hier: „aktualisiert“ > „plan“

n  mehr Aufwand erforderlich als geplant

n  eine Umplanung staigefunden: es wurden AP gestrichen

n  „aktualisiert“ enthält alle AP aus „plan“, d.h. es ist erkennbar, dass umgeplant wurde

ph

„PIA“

gestrichen


84


0

20

40

60

80

100

120

140

plan

ist

aktualisiert

¨  Ende des Intervalls ¤  Volle Zeit = voller Aufwand ¤  „ist“ = „aktualisiert“ ¤  „aktualisiert“


¤  Hier: „aktualisiert“ < „plan“ n  Arbeit wurde ein wenig schneller als geplant erledigt

n  „aktualisiert“ enthält alle geplanten AP, d.h. alle geplante Arbeit wurde erledigt

ph

„PIA“


85


0

20

40

60

80

100

120

140

160

180

200

plan

ist

aktualisiert

¨  Ende des Intervalls ¤  Volle Zeit = voller Aufwand ¤  „aktualisiert“


n  offene AP: „plan“-‐Aufwand

¤  hier: „aktualisiert“ > „plan“ n  es wurden AP gestrichen

¤  hier: „ist“ > „plan“ n  es wurden Überstunden gemacht

ph

„PIA“

gestrichen


86

90%-‐Syndrom

Geleisteter Aufwand [PW]

Geschätzter Fertigstellungs-

grad [%]

Quelle: Boehm, Software Engineering Economics, 1981

Wenn 50% des Aufwands

erbracht sind,

wird der Fertigstellungs- grad auf über

90% geschätzt


87

Projektampel

o  Darstellung des Projektstatus ¤  in Ordnung Projekt wie geplant durchführbar ¤  gefährdet Zusatzmaßnahmen erforderlich ¤  Änderung nöLg Projekt nicht unverändert durchführbar

o  WichLg ¤  Klare Kriterien: Wann grün/gelb/rot?

Projekt-interne

Maßnahmen

Projekt-externe

Maßnahmen


88

Gliederung Projektstatusbericht

o  AdministraLva (Projektname, -‐Nummer, Teamleiter, Phase, ...)

o  Planeinhaltung Aufwand/Termin Vollständigkeit/Qualität Gründe für Verzögerung/Veränderung

o  Team MoLvaLon, Fähigkeiten

o  Besondere Ereignisse z.B. Kunde o  Probleme/Risiken o  Vorschläge für Change Requests/Handlungsbedarf o  Zusammenfassender Projektstatus

Ampel

PIA


kurz (5 Minuten)!

89

Projektstatusbericht: Planeinhaltung (1)

o  Aufwand ¤  PIA-‐Diagramm zeigt Status bzgl. Aufwand ¤  weitere Erläuterungen nöLg, falls

n  Abweichungen vom Planwert exisLeren n  Abweichungen durch Krankheit o.ä. zu erwarten sind

o  Termin à siehe Aufwand (bei unverändertem Team)


90

Projektstatusbericht: Planeinhaltung (2)

o  Qualität ¤  Status bzgl. Qualität durch

n  Review-‐Ergebnisse n  Abgleich mit Zielen

n  Beispiel: Wenn für eine Machbarkeitsstudie ein nachprülares Ziel (z.B. „Schreiben auf einem Web-‐Server durch App“) formuliert wurde, kann eindeuLg geklärt werden, ob sie mit der gewünschten Qualität ferLggestellt ist

n  Teszortschrii, Fehlerkurve à siehe Monitoring


91

Projektstatusbericht: Team, besondere Ereignisse

o  Team ¤  je ein Satz zu

n  wie gut ist die MoLvaLon? n  sind die erforderlichen Fähigkeiten und Kenntnisse (z.B. Protokoll, Sprache, Framework, Methode) im Team vorhanden?

¤  falls Defizite bestehen n  welche Maßnahmen wurden ergriffen?

o  Besondere Ereignisse ¤  Erreichen von Meilensteinen

Beispiel: PflichtenheA unterschrieben

¤  Kundenkontakt n  Rückmeldung, Änderungswünsche


92

Projektstatusbericht: Probleme/Risiken, Handlungsbedarf

o  Probleme/Risiken ¤  Probleme „es ist bereits passiert“ ¤  Top-‐Risiken „es könnte passieren“ ¤  Maßnahmen

o  Vorschläge für Change Requests/Handlungsbedarf ¤  Änderungen, die nicht im Verantwortungsbereich des Projekts liegen

Beispiel: Verstärken des Teams

o  Zusammenfassender Projektstatus ¤  Ampel


94

Weitere Darstellungen: Meilensteintrendanalyse

20-Jan

31-Jan

5-Jan

25-Mrz

10-Apr

5-Ja

n

Pla

nter

min

e

Berichtszeitpunkte

Initiale Planung


95


20-Jan

31-Jan

5-Jan

25-Mrz

10-Apr

5-Ja

n

23-J

an

Pla

nter

min

e

Berichtszeitpunkte

Initiale Planung

Umplanung (Verzögerung)


96


20-Jan

31-Jan

5-Jan

25-Mrz

10-Apr

5-Ja

n

23-J

an

8-Fe

b

Pla

nter

min

e

Berichtszeitpunkte

Initiale Planung



97


20-Jan

31-Jan

5-Jan

25-Mrz

10-Apr

5-Ja

n

23-J

an

8-Fe

b

26-F

eb

Pla

nter

min

e

Berichtszeitpunkte

Meilenstein erreicht

(später als initial geplant)

Initiale Planung



26-Feb

98

Weitere Darstellungen: Earned Value Analyse

t

€

Plankosten

Berichts- zeitpunkt

Terminabweichung (später als geplant) Kostenabweichung

(teurer als geplant)

Arbeitswert

Istkosten

geplantes Ende

geplante Kosten

erwartete Kosten-

abweichung erwartete Termin-

abweichung

aktualisierte geplante Kosten

aktualisiertes geplantes Ende


99

photography: woodleywonderworks http://www.flickr.com/photos/wwworks/2350106729

art work: Peter Kaiser

F R A G E N Einleitung ■■■ Monitoring ■■■ Statusbericht

Documents

PROJEKTMANAGEMENT, Kapitel8services.informatik.hs-mannheim.de/~schramm/see/files/Kapitel08.pdfZiele Stake- holder werden vertreten durch behindert tritt ein mit bewirkt Qualität Projektleiter