Aufrufe
vor 1 Jahr

01 | 2017 public

  • Text
  • Digitale
  • Microservices
  • Verwaltung
  • Hypervisor
  • Umgebungen
  • Informationstechnologie
  • Digitalen
  • Nutzung
  • Projekt
  • Zeit
Gesellschaft und digitale Transformation

Story Points 14,00 12,00

Story Points 14,00 12,00 10,00 8,00 6,00 4,00 Geschwindigkeit pro Iteration Median untere Grenze (90% Konfidenz) obere Grenze (90% Konfidenz) STUFE 2: INTEGRIERTES UMFANGS- UND ZEITMANAGEMENT Auf der nächsten Stufe wird dem Restaufwandsdiagramm eine Trendlinie für den geplanten Restaufwand hinzugefügt. Spätestens nach fünf Iterationen sollte so viel Erfahrung vorhanden sein, um eine Abschätzung über den voraussichtlichen Fertigstellungstermin und dessen Eintrittswahrscheinlichkeit treffen zu können. Auftretende Schätzungenauigkeiten werden im Verlauf der Iterationen kleiner. 2,00 0,00 8. Mai 15. Mai 22. Mai 29. Mai Abbildung 5: Abarbeitungsgeschwindigkeit in Story Points pro Iterationen 5. Juni verhält. Ist der Zuwachs der Änderungen größer als die Abarbeitungsgeschwindigkeit, verschiebt sich das Projektende potenziell ins Unendliche (siehe Abbildung 3) – ein Indikator dafür, dass Funktionalität in die nächste Version verschoben werden beziehungsweise, dass sie sich auf das Notwendige beschränken muss. Abarbeitungsgeschwindigkeit Die Abarbeitungsgeschwindigkeit wird über die unterschiedlichen Iterationen nicht gleich sein, auch wenn die Geschwindigkeit über die Teamstärke und die wirkliche Arbeitszeit (ohne Krankheiten, Urlaube, ungeplante Einsätze in anderen Projekten ...) normiert wird. In Abbildung 5 hat die Geschwindigkeit in den letzten Iterationen abgenommen. Hier ist ein genauerer Blick auf die möglichen Ursachen und gegebenenfalls ein direktes Eingreifen angezeigt. Hat das Team in den ersten beiden Iterationen die Architektur vernachlässigt (also eine technische Schuld angehäuft)? Gibt es Hindernisse für das Team? Ist ein weiteres Absinken zu erwarten? Bearbeitungsstatus der Anforderungen Für einen Überblick über den Bearbeitungsstatus der Anforderungen muss der Bearbeitungsfortschritt der einzelnen Anforderungen gemessen werden. Das folgende Diagramm (siehe Abbildung 4) stellt den Fortschritt als Diagramm dar. Es zeigt den Fertigstellungsgrad der Anforderungen in Relation zur Anforderung mit dem größten Aufwand (im Beispiel: „offene Stellen“). So kann man sich schnell einen Eindruck verschaffen, welche Teilsysteme wie weit fertiggestellt sind und für eine Vorführung infrage kommen. Aus den verschiedenen historischen Abarbeitungsgeschwindigkeiten kann ein unterer und ein oberer Schätzwert für die zu erwartende Geschwindigkeit abgeleitet werden. Ziel ist, eine Vorhersage treffen zu können, wie viel Arbeit das Team in einer geplanten Anzahl von Iterationen erledigen kann. Hier ist es besser, statt einen bestimmten Wert zu nennen (zum Beispiel 8 Story Points pro Iteration), die Geschwindigkeit als Bandbreite von Werten zu betrachten, also zum Beispiel: „Aufgrund unserer historischen Daten sind wir zu 90 Prozent sicher, dass die Geschwindigkeit für die noch verbliebenen Iterationen in diesem Aufwand in Story Points 120 100 80 60 40 20 Restaufwand untere Grenze (90% Konfidenz) obere Grenze (90% Konfidenz) 0 2. Mai 16. Mai 30. Mai 13. Juni 27. Juni 11. Juli 25. Juli 8. August 22. August Abbildung 6: Projektion des voraussichtlichen Endtermins 22 | .public 01-17 | Management

Projekt zwischen 5 und 12 liegen werden.“ Um die Bandbreite der Geschwindigkeit zu errechnen, werden die Daten aus mindestens fünf Iterationen benötigt. Man geht von einer Normalverteilung aus und legt in diese Verteilung ein Konfidenzintervall (auch Vertrauensbereich, Vertrauensintervall oder Erwartungsbereich genannt) hinein. Ein Vorteil gegenüber einer Punktschätzung ist, dass man neben dem Konfidenzintervall direkt die Signifikanz, das heißt die Wahrscheinlichkeit ablesen kann, innerhalb einer gewissen Schwelle zu bleiben. Zeitmanagement Mit den Ergebnissen der Geschwindigkeitsmessung kann das Instrument der Restaufwandsschätzung um eine Aussage des Intervalls der Fertigstellung angereichert werden (siehe Abbildung 6). Im Diagramm mit den Restaufwänden kann eine Abschätzung über den noch verbleibenden Zeitbedarf aufgezeichnet werden. Vom Zeitpunkt der letzten Restaufwandsschätzung trägt man die untere und obere Grenze sowie den Median auf und erhält in diesem Beispiel als Enddatum im besten Fall den 11. Juli, für den Median den 8. August und im ungünstigsten Fall (mit 90 Prozent Konfidenz) den 29. August. Im Diagramm wird ein linearer Verlauf des geplanten Restaufwands angezeigt. Im Gegensatz zu klassischen Projektmethoden mit ihrem typischen S-Verlauf im Aufwand (wenige Mitarbeiter in Analyse und Design, viele Mitarbeiter in Programmierung und Test und wenig Personal beim Einsatz) kann bei agilen Methoden von einem konstanten Team ausgegangen werden. Sollte das nicht der Fall sein, so muss die Trendlinie entsprechend angepasst werden. STUFE 3: INTEGRIERTES UMFANGS-, ZEIT- UND KOSTENMANAGEMENT Zusätzlich zur Aufwandsmessung kann das noch dem Projekt zur Verfügung stehende Budget gemessen werden. Dieses Budget kann in einem Diagramm neben dem Restaufwand aufgetragen werden (Abbildung 7, graue Trendlinie „Restbudget“). Bei Software-Entwicklungsprojekten wird der Löwenanteil der Kosten durch Personalkosten verursacht, die entweder direkt aus den Buchhaltungssystemen oder aus Stundenzetteln (und den Stundensätzen) der Entwickler ermittelt werden können. Die Messung des Budgets ist insbesondere dann hilfreich, wenn die Entwickler immer wieder zu „Noteinsätzen“ in anderen Projekten abgerufen werden. Abbildung 7 zeigt, dass die Restbudget-Trendlinie unter die Trendlinie des geplanten Restaufwands gefallen ist, das heißt, dass bisher mehr Budget verbraucht wurde als geplant. Kommt es zu keiner Änderung im Trend, wird das Budget vor der Fertigstellung aufgebraucht sein. Aufwand in Story Points 120 100 80 60 40 20 Abbildung 7: Restaufwand mit Zeit- und Kostendarstellung FAZIT Restaufwand geplanter Restaufwand Restbudget 0 1. Mai 1. Juni 1. Juli Viele Organisationen versuchen, sofort ein aufwendiges Reporting für agile Projekte einzuführen. Das führt zu hohen Kosten am Anfang und bringt wenig Nutzen. Andere Organisationen erledigen die Projektbudgetierung und -buchhaltung ad hoc: Sie führen zwar auch eine Zeitplanung durch, können die verschiedenen Controlling-Informationen aber nicht zusammenzuführen. Wieder andere Organisationen beherrschen den Projektumfang nicht. Einfach, weil sie ihn nicht messen. So haben sie kein solides Fundament für das Kosten- und Zeitmanagement. Die im Artikel beschriebenen drei Stufen sind ein guter Weg, in agilen Projekten ein „angemessenes“ Projektcontrolling einzuführen. Jede Stufe dieses skalierbaren Ansatzes liefert objektive Messungen, die der Steuerung, Berichterstattung und Zusammenarbeit helfen. Jede Stufe ermöglicht einen zunehmend besseren Überblick – auch wenn sie einen größeren Controlling-Aufwand bedeutet. Die Beherrschung jeder Stufe in der beschriebenen Reihenfolge heißt auch, die Fähigkeit zur Leistungsmessung durch praktische Erfahrung schrittweise aufzubauen. So entsteht nicht nur das Produkt, sondern auch das agile Cockpit in Iterationen.• Ansprechpartner – Uwe Koblitz Lead Project Manager Public Sector Solutions Consulting 120 100 80 60 40 20 0 Budget in T€ Management | .public 01-17 | 23

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2016 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum