Produktivität in Softwareentwicklungsprojekten

Keine Kommentare

Kaum eine Technologie hat die Produktivität sämtlicher Wirtschaftszweige so maßgeblich steigern können, wie die Informationstechnologie. Wie würde sich die Produktivität  z.B. einer Bank oder einer Versicherung verändern, wenn Sie ab morgen ohne IT auskommen müsste?

Die Informationstechnologie wiederum lebt von der Innovation in der Softwareentwicklung. Wie aber verhält es sich mit der Produktivität in der Softwareentwicklung? Mir ist keine andere Branche bekannt, bei der der Begriff der Produktivität so viele Missverständnisse hervorbringt und unausgeprägt behandelt wird, wie in der Softwareentwicklung.

In diesem Blogeintrag möchte ich den Begriff Produktivität im Zusammenhang mit Softwareentwicklungsprojekten und deren Kenngrößen genauer betrachten.

Ist ein Projekt erfolgreich wenn es  „In Time“, „In Budget“ und „In Scope“ entwickelt wurde? Möglicherweise. Wenn es nach den Statistiken der Standish Group geht, ist man ja schon froh wenn diese drei Ziele überhaupt erreicht werden. In deren Chaos Report von 2009 schaffen dies nur rund ein Drittel aller Projekte. Ich frage mich wie viele der gescheiterten Projekte (laut Chaos Report 24%), auf Grund zu niedriger Produktivität gescheitert sind. Für alle erfolgreichen Projekte stellt sich die Frage: Wie geht es noch besser?  Dieser Frage wird nur in wenigen Fällen oder gar nicht nachgegangen. Schließlich unterliegt auch die Anwendungsentwicklung einem ständigen Wettbewerbsdruck. Wie kann nun durch die Verwendung von bestimmten Methoden, Technologien oder Praktiken die Produktivität von Softwareentwicklungen verbessert werden?

Wenn man die Veränderungen in den letzten Jahren in der IT verfolgt hat, könnte man meinen, es wird alle paar Jahre eine neue Sau durchs Dorf getrieben. Wie viel effizienter sind die Unternehmen eigentlich durch SOA geworden? Und durch Kanban können laut diesem Artikel Teams, die bisher nach der Methode Scrum gearbeitet haben, noch mal um 300% produktiver werden. Mich irritieren solche Aussagen und ich stelle mir die Frage, wie solche Angaben messbar belegt werden können.

Produktivität lässt sich durch das Verhältnis von Output zu Input berechnen. Der Input eines Softwareprojekts wird häufig durch den Aufwand (z.B. in Personentagen) oder auch den Kosten bestimmt. Wie aber lässt sich der Output darstellen?

Bei Softwareprodukten ist die Anzahl von Lines of Code (LOC) sehr naheliegend. Wobei diese Messgröße bei näherer Betrachtung keinen Sinn ergibt. Von der verwendeten Sprache über verwendete Tools bis hin zum Programmierstil ergeben sich bei Erhebung der Messgröße signifikante Unterschiede, so dass eine projektübergreifender Verwendung von LOC-Metriken  für den Output ungeeignet ist.

Eine andere Möglichkeit zur Darstellung des Outputs ist die Erhebung von fachlich funktionalem Umfang. Die populärste Methode ist die nach ISO/IEC 20926:2009 standardisierte Function Point Methode. Dabei wird aus Anwendersicht der Softwareumfang nach definierten Regeln in Punkten gemessen. Ausführliche Beschreibungen zur Function Point Analyse können im Buch von [Poensgen & Bock] nachgelesen werden.  Abstriche bei der Messgenauigkeit müssen auch hier hingenommen werden, wenn man z.B. allein die nicht funktionalen Anforderungen in Projekten betrachtet.

Auch wenn dies keine allumfassende Bewertung der LOC-Metriken oder der Function-Point Methode sowie weiteren Messmöglicheiten darstellt, so kann man doch leicht schlussfolgern, dass eine Messung des Outputs von Softwareprojekten nur ungenau möglich ist.

Selbst unter der Annahme einer akkuraten Messung mittels Function Points, stellen sich weitere Fragen. Hier ein Beispiel: Team A liefert nach 6 Monaten Entwicklungszeit ein Softwareprodukt mit 60FP’s aus. In der gleichen Zeit liefert Team B (Teamgrößen sind gleich) ein Softwareprodukt mit 30FP’s aus. Team A ist also doppelt so produktiv wie Team B. Was wäre wenn das System von Team A nur 30% nutzenbringende Funktionalität für den Kunden beinhaltet?

Ist die Produktivität also eher eine Kenngröße die abhängig vom Business Value ist?

 

Harry Sneed beschreibt  in seinem Buch den von ihm benannten Teufelsquadranten. Dabei stellt die zwischen den Kenngrößen Qualität, Leistungsumfang, Zeit und Kosten gebildete Fläche die Produktivität dar. Demnach wirkt sich eine Verschiebung der Fläche zu einer Kenngröße, direkt auf die anderen Kenngrößen aus. Andersherum kann eine Produktivitätssteigerung eine positive Auswirkung auf potentiell jeder der vier Kenngrößen haben. Sind z.B. der Zeitrahmen und die Kosten fest vorgegeben, kann bei höherer Produktivität sowohl eine bessere Qualität als auch eingrößerer Leistungsumfang ausgeliefert werden.

 

 

 

 
Produktivitätssteigerung bedeutet also, die wichtigen Kenngrößen eines Projektes verbessern zu können, und beschränkt sich nicht allein auf Umfang und Kosten.

Im Artikel „Agiler Festpreis“ beschreibt Mirko Novakovic, dass in agilen Projekten nicht allein die „plangetriebenen“ Kenngrößen von Bedeutung sind, sondern „wertgetriebene“ Kenngrößen eine entscheidende Rolle einnehmen.

Wie auch schon im obigen Beispiel mit Team A und Team B erwähnt, nimmt auch der Geschäftswert im Zusammenhang mit Produktivität Einfluss auf den Projekterfolg. Nun liegt es nahe, den Teufelsquadranten um die Kenngröße „Geschäftswert“ zu einem Teufelspentagon zu erweitern, allerdings wirkt sich der Geschäftswert nicht in unmittelbar auf die bisher beschriebenen Kenngrößen aus.

Eine Erklärung dafür ist, dass eine „plangetriebene“ Produktivität durch die Faktoren Zeit, Qualität, Kosten und Umfang beeinflusst werden. Das Hauptaugenmerk bei der Optimierung der plangetriebenen Produktivität liegt auf dem Entwicklungsprozess. Eine „wertgetriebene“ Produktivität betrachtet den erhaltenen Geschäftswert im Verhältnis zum eingebrachten Kapital und hat nicht zwingend direkten Einfluss auf alle plangetriebenen Kenngrößen. Mit anderen Worten: Ein Team das stringent nach einem Business Value priorisiertem Backlog arbeitet, kann trotzdem einen sehr niedrigen Durchsatz haben und schlechte Qualität ausliefern. Für die Berechnung des Business Value wird meistens die NPV-Rechnung (Net Present Value: Kapitalwert oder Barwert) eingesetzt. Welche Auswirkung eine Verbesserung der wertgetriebenen Produktivität auf den NPV besitzt, wird sehr anschaulich im Blog „Der Business Case für Agilität“ beschrieben.

Plakativ lässt sich sagen, die wertgetriebene Produktivität umschreibt die Effektivität einer SW-Entwicklungsabteilung (an den richtigen Dingen arbeiten), wobei die plangetriebene Produktivität die Effizienz einer SW-Entwicklungsabteilung ausdrückt (die Dinge richtig tun).

In diesem Artikel habe ich erstmal eine Begriffseinordnung dargestellt. In einem Folgeartikel möchte ich auf die entscheidenden Produktivitätsfaktoren und Produktivitätshebel eingehen. Also die Stellschrauben für die Optimierung im Softwareentwicklungsprozess. Weiterhin werde ich auf die Messung der Produktivität eingehen.

Jörg Spiegelhoff

Jörg Spiegelhoff ist seit 2010 bei der codecentric am Standort Solingen. In seiner 20-jährigen IT-Laufbahn hat er in den Rollen Produkt-/Projektmanager, Agile Coach und IT-Leiter in verschiedenen Branchen und mit unterschiedlichen Technologien Erfahrungen sammeln können. Aktueller Schwerpunkt seiner Arbeit ist es, die Partnerschaft mit Atlassian auszubauen und Unternehmen beim Einsatz des Produktportfolios zu unterstützen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Weitere Inhalte zu Agile Management

Agile Management

Unbequeme Wahrheiten

Agile Management

Planlos agil

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.