Portfoliomanagement und agile Programmierung

Als Kent Beck zum ersten Mal die Prinzipien der agilen Programmierung formulierte, führte er die größte Veränderung in der Softwaremethodik der letzten zwanzig Jahre an, und damit vielleicht aller Zeiten in einer so jungen Kunst. Da ich nicht hoffen kann, seine Darstellung der synergetischen Prinzipien von Extreme Programming zu übertreffen, möchte ich erklären, wie die agile Programmierung mit dem Portfoliomanagement zusammenhängt und insbesondere mit der kritischen Notwendigkeit, Führungskräften Transparenz über den Status eines Softwareprojekts zu geben. Hier finden Sie weitere Informationen über Portfoliomanagement und agile Programmierung.

Wie Pat Durbin und Terry Doerscher in Kapitel 2 ihres neuen Buches Taming Change with Portfolio Management unter der Überschrift "The Elusive Nature of Knowledge Work" schreiben:

Wissensarbeit ist schwierig zu planen, abzuschätzen und abzuschließen. Im Gegensatz zu physischen Arbeiten wie dem Bau oder der Montage von Komponenten sind wissensbasierte Aktivitäten oft einmalige Unternehmungen, für die es keinen direkten historischen Vergleich gibt. Auch bei der wissensbasierten Arbeit gibt es keine erkennbaren Indikatoren für den Fortschritt.

Das Konzept von Velocity in Extreme Programming oder Agile Programming ist ein Versuch, einen erkennbaren Indikator für den Fortschritt von Softwareprojekten zu schaffen.  Er beantwortet eine einfache, aber entscheidende Frage für einen Geschäftsführer eines Softwareunternehmens:

Wie weit sind wir mit der Arbeit?

Damit lässt sich die interessantere Frage beantworten:

Was ist der beste Kompromiss zwischen dem, was wir wollen (unsere Nachfrage) und dem, was wir in einem bestimmten Zeitraum tun können (unsere Kapazität)?

Velocity ist die Menge an Arbeit, die ein Team in einem festen, aber sich wiederholenden Zeitraum, dem Sprint, erledigt. Bei Planview verwenden wir zweiwöchige Sprints. Die Komplexität der Programmieraufgaben, Stories genannt, ist jedoch sehr unterschiedlich, so dass Sie die Aufgaben nicht einfach zusammenzählen können. Vielmehr messen Sie die Komplexität einer abgeschlossenen Aufgabe in einem abstrakten Maß. Bei Planview nennen wir diese Maßnahme Story Points, aber Sie können sie auch "Complexitrons" nennen oder was immer Sie wollen. Jede Aufgabe muss konsequent in diesen Story Points veranschlagt werden.

Wenn Sie die Anzahl der Story Points messen, die ein bestimmtes Team in mehreren Sprints abgeschlossen hat, haben Sie das beste Maß, um vorherzusagen, wie viel Arbeit im nächsten Sprint von diesem Team erfolgreich abgeschlossen werden wird. Wenn Sie alle Aufgaben in Story Points schätzen, können Sie mit ziemlicher Genauigkeit vorhersagen, wann das Projekt abgeschlossen sein wird. Für eine Führungskraft, einen Portfoliomanager oder einen Projektmanager ermöglicht diese Transparenz eine gute Entscheidungsfindung.

Die Erfahrung hat uns jedoch gelehrt, dass es einige subtile Schlüssel zu Schätzung, Story Points und Geschwindigkeit gibt:

• Das gesamte Team ist an der Schätzung beteiligt.
• Die Einschätzung einer Geschichte darf sich niemals ändern, wenn sie einmal beschlossen ist. Die Zeit mag zeigen, dass die Schätzung falsch ist, aber die Schätzung zu ändern ist so, als würde man einem Schuldner sagen, dass er ohne Grund doppelt so viel schuldet wie vorher vereinbart.
• Eine Geschichte kann in kleinere Geschichten aufgeteilt werden, aber die Story Points, wie Geld, Energie und Schwung, müssen erhalten bleiben.
• Schnell gemachte Schätzungen, die sich auf die unaussprechlichen Gedanken eines erfahrenen Programmierers stützen, sind in etwa so gut wie detaillierte Schätzungen.
• Erwarten Sie, dass die Geschwindigkeit in einem bestimmten Sprint um etwa 40% um einen Durchschnittswert aus mehreren Sprints schwankt.
• Das Schreiben von Geschichten ist eine Kunst, aber es ist keine schwarze Kunst. Ein Team und sein Produktmanager sollten in der Lage sein, 15 vernünftige Geschichten in einer Stunde zu schreiben. Perfektion ist nicht besser als "gut genug". Lassen Sie nicht zu, dass das Perfekte zum Feind des Guten wird.
• Wenn sich die Programmierer nicht einig sind, lösen Sie die Unstimmigkeiten durch Konsens und Diskussion.
• "Erledigt" bedeutet "Freigegeben". Eine Aufgabe ist erst dann erledigt, wenn sie freigegeben werden kann. Sie sind vielleicht nicht bereit, auch nur eine einzige Geschichte zu liefern, aber wenn diese Geschichte nicht die Qualität hat, die Ihre Kunden verlangen, zählt sie einfach nicht

Ähnliche Beiträge

Produktportfolio-Management Produktportfolio-Management im digitalen Zeitalter [Webinar] 1. September 2017

Produktportfolio-Management Jetzt ist es offiziell! Gartners Meinung zur Konvergenz von Produktportfolio-Management und Product Lifecycle Management 8. März 2017

Produktportfolio-Management, Visionen und Trends Die 2018 Umfrage zum Produktportfolio-Management wirft ein Licht auf die Top-Performer [Video] 19. Juni 2018