boxing modell
Transcription
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