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.

Freitag, 29. Juni 2018

Agile: Das Laetrile für den Projekt Manager?

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


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


Laetrile ist eine farblose Flüssigkeit, die aus dem weichen Inneren von Aprikosenkernen herausgepresst wird. In Schweden kann man diese Flüssigkeit in Lebensmittelgeschäften ungefähr für denselben Preis wie Mandelaroma kaufen. Man benutzt sie beim Backen so wie andere Extrakte. In Mexiko wird diese Flüssigkeit für 50 Dollar pro Tropfen als "Heilmittel" für die tödliche Geißel Krebs verkauft. Natürlich heilt sie gar nichts. Alle Anzeichen deuten darauf hin, dass alles nur grausamer Betrug ist. Aber da sonst niemand den Todeskandidaten irgendetwas anbieten kann, werden die Versprechungen der Laetrile-Quacksalber ernst genommen, ganz egal wie schändlich diese sind.
Personen, die extrem verzweifelt sind, prüfen Behauptungen nicht allzu kritisch nach.
Manche Manager sind in einer ähnlich "extrem verzweifelten" Lage und diese Verzweiflung macht sie zu einfachen Opfern für vielerlei technische Laetrile, die vorgeben, die Produktivität zu steigern. Nur selten gibt es Belege für die Wirksamkeit der offerierten Versprechungen. Aber auch sie verzichten auf Belege, weil ihre Not so groß ist.


Das  ganze 6. Kapitel: "Laetrile" ist sehr lesenswert!!!

Kommentare hierzu halte ich für überflüssig.

Abhilfe "De Luxe": FlePA .

Abhilfe für den normalen, praktischen Fall: SAvAP .



Donnerstag, 21. Juni 2018

Wenn Sie es schon nicht sein lassen können, so gestalten Sie es aber bitte so gut wie möglich

Seit dem Jahr 2009 arbeite ich mit agilen Teams und schon davor hatte ich mich mit den Kerngedanken des "Agilismus" auseinander gesetzt.

Die Theorie um die agilen Methoden ist wirklich hübsch, besagt etwas von Frieden, Freude, Eierkuchen...
Grundlage der agilen Methoden ist ein "Manifesto" und ornamentiert wird sie (die Grundlage) durch die bekannten (und berüchtigten) "12 Prinzipien".

Was ich davon halte habe ich schon früher dargelegt.

Dennoch habe ich in der letzten Zeit die Gelegenheit gehabt und ausgenutzt noch mehr dazu zu lernen.


7 Jahre Arbeit im "agilen Umfeld"


Mit mehr als 7 Jahren Arbeit in agilen Teams bei verschiedenen Firmen muss ich doch zugestehen, dass ich mich teilweise geirrt habe.

So z.B. sind die agilen Entwicklungsmethoden keine Totgeburt wie ich meinte: scheinbar wachsen sie und gedeihen wider besseres Wissen... sogar bei echt großen Firmen!

Ungefähr die Hälfte der in agilen Teams involvierten Mitarbeiter scheinen agile Ansätze zu mögen, die andere Hälfte aber nicht. Geteilte Meinungen also. Sowohl die eine als auch die andere Methode hat Vor- und Nachteile, wie es eigentlich auch zu erwarten war.

Aus den mir vorliegenden Studien bezüglich das Ergebnis (Aufwand/Leistung Verhältnis) der Agilen (ACHTUNG! Gemeint sind nicht die subjektiven Meinungen von Teilnehmer an Fragebogen oder von Internet-Quizzen, sondern erhobenen Zahlen), scheinen sie sich mit den planungslastigen Methoden (BDUF: Big Design Up Front) in der Waage zu halten: Weder die eine noch die andere Vorgehensweise kristallisiert sich eindeutig als Sieger heraus (1). Hier ist aber eine verlässliche Aussage eher unmöglich, denn ein Vergleich ist nicht unter wirklichkeitsnahen Bedingungen realisierbar.

Was folgere ich daraus?
Nun:

1. Die Agilen sind da und werden aller Anschein nach nicht so schnell wieder verschwinden (m.a.W. es wird eine -lange- Weile dauern, bevor man sie wieder ersetzt, unabhängig von guten oder schlechten Ergebnissen, unabhängig vom Vorhandensein besserer Methoden).

2. Die Agilen sind nicht besser oder schlechter als die BDUF-Methoden, sondern ziemlich gleichwertig. Doch das Management möchte sicherlich die Agilen beibehalten, denn dadurch sind sie von einem (guten) Brocken Arbeit entlastet (dies, werter Leser, gilt zu berücksichtigen).

3. Historisch gesehen hat sich das klassische Projekt Management (BDUF) über eine (sehr) lange Zeitspanne entwickelt; die agilen Methoden aber sind ein relativ neuer, noch sehr junger Ansatz (2). Als solches sind sie einerseits für Fehlentwicklungen und Missverständnissen recht anfällig (da noch unzureichend untersucht), andererseits sind sie aber aus eben denselben Gründen besonders verbesserungsbedürftig.


Als Analytiker bin ich an Zahlen, Analysen und Ergebnissen sehr interessiert.
Aus Erfahrung, meiner kritischen Haltung gegenüber der Agilen und meinen Drang, Prozesse zu verbessern (siehe z.B. mein "Kaizen destilliert": http://amtrs.de/downl/Kaizen_Destilliert.pdf), entstand folglich die:


Strukturierte Analyse von agilen Prozessen (SAvAP)


Ziel und Zweck von SAvAP (wie der Name schon sagt) ist es, die agilen Methoden vom Nimbus des Esoterischen, vom Dogmatischen aus dem Manifesto und den 12 Prinzipien zu befreien und sie zu verständlichen, produktiven und an einer (Ihrer) Umgebung (sei es Team, Abteilung oder Firma) angepassten Methoden zu entwickeln.

Doch dem kurzen Sinn langer Rede ist hier zu lesen: http://amtrs.de/savap.htm

_______________________________________________________________

Was für Erfahrungen haben Sie mit agilen Methoden?

Halten Sie „agil“ oder „klassisch“ für besser?

Hätten Sie vielleicht sogar Vergleichszahlen zwischen beiden Ansätze?

Und was meinen Sie; sind die agilen Methoden wesentlich oder unwesentlich zu verbessern?

_______________________________________________________________


(1) "One of the greatest tragedies in life is the murder of a beautiful theory by a gang of brutal facts." Benjamin Franklin

(2) FlePA (siehe http://amtrs.de/flepa.htm) ist sicherlich die Zukunft, aber, wie weiter oben angemerkt (1. Punkt); es wird ziemlich lange dauern bis dieser Ansatz Einzug in der gegenwärtigen Projekt Management Disziplin findet. Bis dahin müssen wir alle wohl oder übel mit den Agilen Vorlieb nehmen.


und...

Heute ist der längste Tag des Jahres !!!


Dienstag, 13. Februar 2018

Vergleich "Agile" vs. "nicht Agile"

Ich kann mir sehr schwer vorstellen, dass Scrum oder "Agile" (wirklich) besser als einer klassischen Methode funktioniert.

Deswegen suche ich harte Vergleiche; Vergleiche die auf Fakten basieren.

Folgende Punkte möchte ich vergleichen:

1. Produktivität

2. Zufriedenheit der Projekt-Teilnehmer
2.1. Anzahl der Projekt-Teilnehmer, die ein nicht-Agiles Projekt in einer gegebenen Zeit verlassen haben, und
2.2. Anzahl der Projekt-Teilnehmer, die ein Agiles Projekt in einer gegebenen Zeit verlassen haben.

3. Last but not least, der Wunde Punkt der SW-Entwicklung; Bugs!
3.1. Anzahl Bug pro Zeiteinheit (oder TLOC oder Funktionspunkte)
3.2. Kritikalität der Bugs pro Zeiteinheit (Anzahl Bug pro Zeiteinheit und Kritikalität)
3.3. Durchschnittliche Verweildauer eines Bugs (wie lange braucht man, es zu beheben)
3.4. Durchschnittliche Verweildauer der Bugs nach Kritikalität (wie lange braucht man, Bugs nach Kritikalität zu beheben)




Es gibt leider leider noch mehrere wichtigen Punkte zu vergleichen...
Stoff für mehrere Arbeiten!

Hier mein Schreiben zu diesem "Vergleich": Bitte runterladen.

Auf Kommentare und weiterführende Infos bin ich sehr gespannt ;-)