Montag, 16. Juli 2018

Produktivitätsteigerung als Folge von "Investitionen", nicht als Folge von dem Einsatz irgendwelchen (agilen) Methoden


Aus dem Buch: Der Termin
Tom DeMarco (1997)

»Im Prinzip ist Prozessverbesserung eine gute Sache. Sie bedeutet, dass Sie Ihren Job immer besser machen. Aber ich bin wenig begeistert von Programmen wie dem CMM-Ansatz, die sich Prozessverbesserung auf ihre Fahne schreiben. Sie werden leicht zum Selbstzweck.«

»So etwas wie eine schnelle Lösung gibt es in unserer Branche nicht. Es gibt keine Möglichkeit, die Produktivität kurzfristig zu steigern. Die Produktivität, die Sie heute erreichen, ist das direkte Ergebnis der langfristigen Investitionen, die vor Ihrer Zeit getätigt wurden. Und auch Sie können die Produktivität nur beeinflussen, wenn Sie Ihrerseits eine langfristige Investition tätigen, die Ihren Nachfolgern zugute kommt.«

Soll man glauben (dürfen), dass man Produktivitätssteigerungen durch Einsatz von "agilen" Methoden erzielen kann?

Ich finde den Text im Buch ganz gut, denn einerseits halte ich auch sehr wenig von CMM und andererseits scheint mir die Erklärung mit der Investition sehr "bodenständig". So etwas fehlt heute in der IT-Industrie.

Auf jeden Fall finde ich die Aussage im Buch sehr interessant.

Donnerstag, 5. Juli 2018

Kann man Produktivität schätzen? - Und, wichtiger eigentlich: Bringt das was?


Die Bücher von Tom DeMarco sind, irgendwie zeitlos, ein Lesevergnügen 1. Klasse für alle Projektbeteiligten :-)

Vom Buch: Wien wartet auf Dich!
Tom DeMarco, Timothy Lister, Peter Hruschka
Seite 27ff:

Lawrence und Jeffery wollten die Produktivitätseffekte verschiedener Schätzverfahren ermitteln. Ihr Ziel war es, den alten Glauben zu bestätigen oder zu widerlegen, wonach Entwickler (in diesem Fall Programmierer) härter arbeiten, wenn sie ihre eigenen Schätzungen einhalten wollen. Für jedes der 103 Projekte entwickelten Lawrence und Jeffery eine gewichtete Metrik für die Produktivität. Dann teilten sie ihre gesammelten Daten in Gruppen ein, gegliedert nach der Art, wie die ursprünglichen Schätzungen zustande kamen.
[...]
Systemanalytiker sind die besseren Schätzexperten; besser als die Programmierer und besser als die Manager. Sie verstehen typischerweise die Arbeit bis ins Detail, sind aber nicht von dem natürlichen Optimismus der Personen befallen, die die Arbeit durchführen müssen, und auch nicht von den politischen oder budgetären Randbedingungen des Chefs beeinflusst.
[...]
Schlechte Schätzungen und hoffnungslos enge Terminpläne schwächen die Energie von Entwicklern. Capers Jones, der für seine Metrikstudien über Entwicklungsmodelle bekannt ist, hat es folgendermaßen ausgedrückt: "Wenn der Terminplan eines Projekts von Grund auf unrealistisch und unvernünftig ist, so dass selbst mit einer Menge von Überstunden nichts erreicht werden kann, wird das Projektteam zornig und frustriert... und die Moral sinkt auf den Nullpunkt." (Capers Jones, Programming Productivity (New York, McGrawHill, 1986), S. 213)

Dabei spielt es fast keine Rolle, ob die von Grund auf unrealistischen und unvernünftigen Termine vom Chef oder von den Entwicklern stammen.

Das überraschendste Ergebnis der Studie von Lawrence und Jeffery aus dem Jahre 1985 stand ganz am Schluss, als sie die Produktivität der 24 Projekte untersuchten, für die es überhaupt keine Schätzungen gab. Diese Projekte wiesen eine viel höhere Produktivität auf.

[Siehe Tabelle im o.g. Buch. Inhalt: Produktivität ohne Schätzung = 50% mehr als die Schätzung der Programmierer.]

Die Projekte, bei denen der Chef keinerlei Druck bezüglich des Fertigstellungstermins ausübte ("Weckt mich auf, wenn ihr fertig seid!"), wiesen die höchste Produktivität auf.

Mein Fazit: Nun muss ich unbedingt als Systemanalytiker zwar schätzen, der PM muss die Entwickler aber sich selbst überlassen.

Heute was gelernt!

Wie auch immer, bei Projekten sind Schätzungen sehr wichtig, denn es wäre wirklich irrsinnig etwas anzufangen ohne klare Vorstellungen von Zeit und Kosten zu haben. Doch das Mikroschätzen der "agilen Methoden" ist, meiner Meinung nach, overkilled, demnach auch die Einteilung in starren, unflexiblen, "Time Boxen" ("Agilität" lässt gerade ganz lieb grüßen...). Viel besser natürlich: FlePA.

Aber wenn Sie es doch nicht sein lassen können, dann machen Sie es zumindest so richtig wie möglich: SAvAP.