boxing modell

Übung zur Vorlesung Projektorganisation und
Management in der Software-Entwicklung
Wintersemester 2009/2010
Prof. Dr. Dr. h.c. M. Broy
Dr. M. Kuhrmann, Dr. H. Ehler, G. Kalus, D. Méndez F., W. Schwitzer
11.01.2010
Technische Universität München
Fakultät für Informatik
Übungsblatt 10: Time Boxing und Projektstatusbericht
Aufgabe 22: Time Boxing
Gegeben ist folgender Projektplan:
Vorgang
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
Aufwand in
Function Points
10
20
15
10
15
10
20
10
15
5
10
20
10
15
5
Vorgänger
A
B
D
B, E
F
H
I
K
L
M
N
Ihre Firma hat ein ähnliches Projekt schon einmal vor zwei Jahren durchgeführt. Sie haben die
Produktivität Ihrer Mitarbeiter damals protokolliert. Dabei hat sich ergeben, dass im Schnitt ein Entwickler
in dem Projekt pro Tag Aufwände im Umfang von 0,3 Function Points geschafft hat. An dem neuen Projekt
arbeitet jedoch ein anderes Entwicklerteam, bestehend aus fünf Mitarbeitern.
Sie beschließen, aufgrund der hohen Änderungsrate der Anforderungen iterativ zu planen und Time Boxing
zu verwenden.
a)
Diskutieren Sie die Vor- und Nachteile von Time Boxing.
Vorteile:
•
Konstante, gleichverteilte Fortschrittskontrolle gewährleistet
•
Meilensteine können nicht verschoben werden
•
Es kann leichter mit Zeitbeschränkung umgegangen werden
Nachteile:
b)
•
Entwickler können sich daran gewöhnen den Umfang von Meilensteinen zu reduzieren.
•
Qualität kann geringer sein.
Zusätzlich zu einer hohen erwarteten Änderungsrate der Anforderungen gibt es weitere
Voraussetzungen in Projekten, die für oder gegen den Einsatz von Time Boxing sprechen. Diskutieren
Sie je ein Beispiel.
1

Pro Time Boxing:
Der Zeitpunkt der Auslieferung der ersten (bzw. nächsten) stabilen Version ist wichtiger als
der volle Funktionsumfang der Version.

Contra Time Boxing:
Kunden akzeptieren einige Bedingungen für den Einsatz von Time Boxing nicht als
Vertragsgrundlage. Dies kann zum Beispiel die variable Qualität am Ende der geplanten
Projektlaufzeit sein. In Verbindung von Time Boxing mit agilem Vorgehen kann zum Beispiel
die Bereitstellung eines lokalen Ansprechpartners durch den Kunden für eine enge
Rückkopplung zwischen Entwicklerteam und Kunde problematisch sein.
c)
Definieren Sie eine geeignete Länge für Ihre Time Boxes. Begründen Sie ihre Wahl.
Eine geeignete Zeitspanne für eine Time Box wäre beispielsweise ein Monat. Der Zeitraum darf nicht
zu lang gewählt werden, damit das Kriterium der Kurzfristigkeit gewährleistet ist. Typische
Zeitspannen beim Time Boxing sind 1-6 Wochen.
Der Gesamtarbeitsaufwand umfasst 190 Function Points. Pro Monat (mit 20 Personentagen pro
Personenmonat) schaffen fünf Entwickler nach den Schätzungen aus dem alten Projekt 0,3 * 5 * 20 =
30 Function Points. Das Projekt könnte somit in sieben Time Boxes ablaufen. Die letzte Time Box ist
kürzer.
d)
Planen sie Arbeitspakete jeweils für die nächste Time Box. Überprüfen Sie am Ende der Iteration, wie
viel Arbeit tatsächlich erledigt wurde und planen Sie für die nächste Iteration entsprechend.
Versuchen Sie Erklärungen für die veränderliche Produktivität Ihrer Mitarbeiter zu finden. Die
Produktivität Ihres Gesamtteams entwickelt sich während des Projektes wie folgt:

1 FP pro Tag während der ersten vier Wochen

1,5 FPs pro Tag in den Wochen 5-12

2 FPs pro Tag ab Woche 13
Pro Iteration planen wir 4 Wochen ein. Zu Beginn liegt unsere Produktivitätsschätzung bei 30 FP pro
Iteration (siehe Teilaufgabe c).
1. Für die erste Iteration planen wir die Arbeitspakete A und B ein. Die Entwickler schaffen jedoch B
nur zur Hälfte. Es bleibt für B ein Restaufwand von 10 FPs. Die Abweichung in der Produktivität lässt
sich beispielsweise darauf zurückführen, dass die Entwickler sich noch einarbeiten müssen oder die
Kommunikation im Team noch nicht rund läuft.
2. Wir gehen weiterhin von 30 FPs pro Monat aus, da die Gründe für die Abweichung in der
Produktivität überwunden sind. Für die zweite Iteration planen wir den Rest von B erneut ein, weil
nach Rücksprache mit dem Auftraggeber auf den fehlenden Funktionsumfang von B nicht verzichtet
werden kann und eine Verzögerung um ca. 7 Tage noch als akzeptabel angesehen wird. Außerdem
werden D und H eingeplant. Diesmal stimmt die Schätzung.
3. In der dritten Iteration werden C und E eingeplant und realisiert.
4. In der vierten Iteration planen wir F und G ein. Die Entwickler werden früher fertig als geplant.
5. In der fünften Iteration planen wir I, J und K ein. Die Entwickler werden wieder früher fertig.
6. Wir passen unsere Abschätzung der Produktivität an und gehen fortan von 40 FPs pro Iteration
aus. In der fünften Iteration werden L, M und ein Teil von N eingeplant und realisiert.
7. Für die letzte Time Box sehen wir nur eine Woche vor, in der der Rest von N und O abgearbeitet
werden.
Die Leerläufe lassen sich vermeiden, wenn man mehrere Iterationen voraus plant. In dem Fall können
die Entwickler mit den Arbeitspaketen der nächsten Iteration beginnen. In der Praxis plant man in der
Regel Releases die aus mehreren Iterationen bestehen. Jedem Release sind eine Reihe von
Anforderungen bzw. Vorgängen zugeordnet. Wird man in einer Iteration früher fertig, so werden
Arbeitspakete aus späteren Iterationen vorgezogen.
2
Die schwankende Produktivität lässt sich beispielsweise dadurch erklären, dass die Entwickler sich mit
der Aufgabe, ihren Teamkollegen und der Projektinfrastruktur erst vertraut machen müssen.
Insbesondere zu Beginn sollte man mit Abweichungen rechnen. Eine Zunahme der Produktivität gegen
Ende des Projekts, wie sie in dieser Aufgabe gegeben ist, tritt nicht unbedingt ein.
Aufgabe 23: Projektstatusbericht
Der Projektstatusbericht ist ein wichtiges Instrument, um den Projektzustand und –fortschritt im Auge zu
behalten und an diesen alle Projektbeteiligten zu kommunizieren.
a)
Diskutieren Sie, welche Informationen im Projektstatusbericht enthalten sein sollten.
b)
Vergleichen Sie Ihre Ergebnisse mit der Vorlage für Projektstatusberichte des V-Modell XT
(siehe http://ftp.tu-clausthal.de/pub/institute/informatik/v-modell-xt/Releases/1.3/Produktvorlagen%20ORG.zip und dort
im Unterverzeichnis Berichtswesen)
Das V-Modell XT gibt für Projektstatusberichte folgende Schablone vor:
1 Einleitung
Der Projektfortschritt muss regelmäßig überprüft werden, damit gegebenenfalls steuernd eingegriffen
werden kann. Der Projektstatusbericht ist das zentrale Dokument zur Beurteilung des Projektfortschritts.
Er enthält Aussagen zum aktuellen Fertigungsstand, zur Stabilität und Qualität der Projektergebnisse, zur
Risikoeinschätzung und zur Abweichung von der ursprünglichen Planung. Bei Bedarf wird in ihm die
Planung aktualisiert.
Verantwortlich für den Projektstatusbericht ist der Projektleiter. Er erstellt ihn in Zusammenarbeit mit den
anderen Schlüsselrollen des Projekts. Anzahl, Häufigkeit und Verteiler des Projektstatusberichtes entsprechen den Vorgaben des Projekthandbuchs. Der Projektstatusbericht wird sowohl zur projektinternen
als auch -externen Berichterstattung eingesetzt.
...hier Ihren Text einfügen...
2 Managementübersicht
Stellt kurz und prägnant die aktuellen Kennzahlen zum Projektfortschritt dar und notwendige Maßnahmen
zur Steuerung des Projektes vor.
...hier Ihren Text einfügen...
3 Projektergebnisse
Dieses Thema enthält einen Überblick über die im Berichtszeitraum fertig gestellten Ergebnisse und
durchgeführten Arbeiten. Konnten Ergebnisse nicht wie geplant fertig gestellt werden, so ist dies ebenfalls
hier festzuhalten. Die im Projekthandbuch festgelegten KM-Auswertungen können hierbei eine
entsprechende Informationsquelle sein.
...hier Ihren Text einfügen...
4 Problem- und Änderungsstatistik
In diesem Thema wird entsprechend den Vorgaben des Projekthandbuchs die Problem- und
Änderungsstatistik dargestellt, zum Beispiel Anzahl und Umfang der Problemmeldungen und
Änderungsanträge und die Anzahl der bereits fertig gestellten und wieder veränderten Produkte. Sowohl
die Änderungsstatusliste als auch die im Projekthandbuch festgelegten KM-Auswertungen können hierbei
entsprechende Informationsquellen sein.
...hier Ihren Text einfügen...
5 Qualitätsbewertung
3
Die Qualitätsbewertung beinhaltet eine Zusammenfassung des QS-Berichtes.
...hier Ihren Text einfügen...
6 Aktuelle Risiken und Risikomaßnahmen
Die Bewertung der aktuellen Risiken und die notwendigen anstehenden und bereits eingeleiteten
Maßnahmen werden zusammenfassend dargestellt.
...hier Ihren Text einfügen...
7 Planungsabweichungen
Die Abweichungen zwischen den Soll- und Istwerten, zum Beispiel hinsichtlich Fertigstellungsgrades,
Terminsituation, Qualität und Kosten werden dargestellt.
...hier Ihren Text einfügen...
8 Planung für den nächsten Berichtszeitraum
Die Planung für den nächsten Berichtszeitraum, insbesondere auch die aufgrund der
Planungsabweichungen notwendigen Planungsänderungen werden zusammenfassend dargestellt.
Darüber hinaus können hier auch Entscheidungsvorlagen für die Berichtsempfänger vorgestellt und dann
entsprechend verabschiedet werden (zum Beispiel eine gravierende Projektsteuerungsmaßnahme, die im
Rahmen einer Projektfortschrittsentscheidung beschlossen und eingeleitet werden muss).
...hier Ihren Text einfügen...
9 Gesamtprojektfortschritt
Der Gesamtprojektfortschritt ist eine Verdichtung der wichtigsten Projektfortschrittswerte der einzelnen
Teilprojekte für das Gesamtprojekt. Die Projektfortschrittswerte der Teilprojekte enthalten Aussagen zum
aktuellen Fertigungsstand, zur Stabilität und Qualität der Projektergebnisse, zur Risikoeinschätzung und
zur Abweichung von der ursprünglichen Planung.
Wichtig für die Darstellung des Gesamtprojektfortschritts ist ein gemeinsamer Berichtszeitpunkt für alle
Teilprojekte, zu dem aus Vergleichsgründen alle Projektfortschrittswerte ermittelt sein müssen.
Ein wichtiges Ergebnis ist der kritische Pfad des Gesamtprojektes, der sich aus der Aggregation der
Projektfortschrittswerte aller Teilprojekte ergibt.
...hier Ihren Text einfügen...
4