Was man nicht messen kann,...

Transkript

1 Was man nicht messen kann, kann man nicht kontrollieren. von Tom DeMarco 1. Auflage Was man nicht messen kann,... DeMarco schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Thematische Gliederung: Software Engineering mitp/bhv 2008 Verlag C.H. Beck im Internet: ISBN

2 1 Unter Kontrolle Was man nicht messen kann, kann man nicht kontrollieren. In den meisten Fachgebieten nimmt man eine enge Verbindung von Messung und Kontrolle als gegeben an. Aber ich fürchte, dass dieser Gedanke für viele Manager in der Software-Entwicklung neu ist. Diese sonst sehr rational bestimmten Männer und Frauen gehen mit sehr vagen Vorstellungen von Kontrolle durchs Leben, obwohl sie nie etwas messen. Dieses Buch behandelt in erster Linie Messmethoden. Es will Ihnen darlegen, wie man Softwareprojekte so organisieren kann, dass sie messbar sind, was gemessen werden soll und wie die gemessenen Daten zu einer aussagekräftigen Steuerung des Software-Entwicklungsprozesses herangezogen werden können. Das Problem der Kontrolle ist sehr heikel. Fast alle Manager von Softwareprojekten würden bei der Andeutung, sie hätten die Kontrolle über ihr Projekt verloren, innehalten. Lassen Sie mich diese Aussage persönlicher formulieren: Sie wären wohl sehr verärgert, wenn jemand behaupten würde, Sie hätten die Kontrolle über Ihr Projekt verloren. Natürlich haben Sie Ihr Projekt unter Kontrolle. Es ist ja Ihre Aufgabe, als Manager dafür zu sorgen, dass alles läuft. Und natürlich tun Sie Ihren Job und Sie machen ihn gut. Aber es gibt einige Besorgnis erregende Fakten, die wir betrachten sollten: 29

3 Kapitel 1 Unter Kontrolle Fünfzehn Prozent aller Softwareprojekte liefern nie ein Ergebnis; das heißt, sie verfehlen das ursprünglich gesetzte Ziel vollkommen. Kosten- und Zeitüberschreitungen von hundert bis zweihundert Prozent sind bei Softwareprojekten üblich. Der Manager eines Projekts, das überhaupt kein Ergebnis liefert oder das Budget und den Termin um hundert Prozent oder mehr überschreitet, hinterlässt natürlich den Eindruck, als habe er es nicht unter Kontrolle gehabt. Aber als diese Projekte in dem Stadium waren, in dem sich Ihres gerade befindet, glaubten die Manager, sie hätten es unter Kontrolle. Welche Überraschungen hielt die Zukunft für sie bereit? Wird es auch für Sie ähnliche Überraschungen geben? Wenn Sie sich auf einem Schlachtfeld wiederfinden und an den herumliegenden Leichen vorbeigehen, müssen Sie sich fragen:»welche Erfahrungen, die mir noch fehlen, mussten diese Manager am Ende machen?«1.1 Der Stand der Technik im Softwaremanagement Ich glaube, dass der Softwaremanager von heute sich auf so einem Schlachtfeld bewegt. Zu viele Softwareprojekte erreichen in wichtigen Punkten ihr Ziel nicht, so dass der»erfolg«eines Projekts nachträglich neu definiert werden muss, damit niemand den Mut verliert. Softwareprojekte werden zuweilen als erfolgreich bezeichnet, wenn die Überschreitungen unter dreißig Prozent gehalten werden können oder der Anwender nur ein Viertel des Ergebnisses reklamiert. Software-Entwickler neigen oft dazu, solche Projekte als gelungen einzustufen, aber die Mitglieder unserer Anwendergemeinde sind weniger nachsichtig. Sie erkennen die vorhandenen Fehler. In meinem ersten Buch (von Natur aus langweilige Leute schreiben oft so etwas) habe ich die Kluft, die sich zwischen Anwendern und Entwicklern auftut, diskutiert und mögliche Gründe dafür genannt sowie Gegenmaßnahmen vorgeschlagen [DeMarco, 1978]. Ich befürwortete verschiedene Möglichkeiten, die Kommunikation mit den Leuten auf der anderen Seite der Kluft fruchtbarer zu gestalten, Möglichkeiten, 30

4 Was man nicht messen kann... die ich immer noch gutheiße und praktiziere. Aber das Problem der Anwender-Entwickler-Kluft ist nicht ausschließlich kommunikativer Art. Einer der wichtigsten Gründe dafür, dass die Anwendergemeinde Software-Entwicklern misstraut und sie nicht gerade schätzt, liegt in der Auftragsausführung: Anwender sind daran gewöhnt, gesteckte Ziele in ihren Fachbereichen mit einer Konsequenz zu erreichen, die man im Softwarebereich nicht kennt. Ein Bauingenieur, der Software in Auftrag gibt, neigt dazu, das Ergebnis nach denselben Kriterien zu beurteilen, die seine Kunden seiner Konstruktionsarbeit zugrunde legen. Ein Konstruktionsauftrag wird bereits dann als Debakel betrachtet, wenn es zu Überschreitungen von mehr als sechs Prozent kommt. Wenn man diesen Maßstab zugrunde legt, gab es erschreckend wenig erfolgreiche Softwareprojekte. 1.2 Die Anatomie des Scheitern eines Projekts Viele Softwareprojekte gehen daneben, aber wir Software-Entwickler sind keine solchen Hohlköpfe, dass einzig und allein unsere Inkompetenz dafür verantwortlich zu machen wäre. Softwaremanager sind nicht weniger befähigt, ihre Leute zu führen und ihre Fachbereiche zu organisieren, als Manager anderer Fachbereiche. In den Jahren, als ich Softwareprojekte überwachte, habe ich viele Totalausfälle erlebt, die keinesfalls auf mangelnde Kompetenz und Motivation zurückgeführt werden können. Ich kannte Projektmanager, die mit Eigenschaften, die ich mit gutem Management verbinde, hervorragend ausgestattet waren: starke Motivierung der Projektmitarbeiter klares Auffassen der Problematik guter Zugriff auf relevante Technologien geschicktes Vorgehen in firmenpolitischen Belangen Dennoch scheiterten ihre Projekte. Warum? Sie waren im Entwurf nicht schlecht und in der Codierung nicht langsam und hatten auch keine allzu hohe Fehlerrate. In den meisten Fällen gelang es ihnen einfach nicht, die ursprünglichen Erwartungen zu erfüllen. Ich bin 31

5 Kapitel 1 Unter Kontrolle überzeugt, dass die meisten Projektausfälle in diese Kategorie fallen und mit Fehlern des Projekt-Teams überhaupt nichts zu tun haben. Vielmehr liegt das Scheitern in überzogenen und unvernünftigen Erwartungen begründet. Die traurige Konsequenz dieser überzogenen Erwartungen ist, dass die Projekte ohne Rücksicht auf Qualität und Quantität der tatsächlich geleisteten Arbeit zu Fehlschlägen erklärt werden. 1.3 Was es heißt,»ein Softwareprojekt unter Kontrolle zu haben«man hat ein Projekt dann unter Kontrolle, wenn man während des Verlaufs gewährleisten kann, dass die Abweichungen vom eingeschlagenen Weg so minimal wie möglich gehalten werden. Das am besten kontrollierte Projekt ist nicht notwendigerweise das, bei dem das beste oder das umfangreichste Ergebnis herauskommt, sondern es ist das Projekt, das den Vorhersagen am nächsten kommt. Wenn es Abweichungen von den ursprünglichen Zielen eines Projekts gibt, sind diese aber im zweiten Fall geringer und kündigen sich früh an. Der Wert eines guten Projektmanagers zeigt sich vor allem darin, wie gut er die Kontrolle behält. Das führt zu folgendem Paradoxon: Wenn der Manager A vom Anfang bis zum Ende ein mittelmäßiges Produkt plant und ein entsprechendes Ergebnis vorlegt, während Manager B große Wunder vorhersagt, die dann vielleicht etwas kleiner ausfallen, dann ist A ein besserer Manager als B. Über diese Schlussfolgerung bin ich nicht sehr glücklich, aber sie scheint der Realität zu entsprechen. Das reibungslose Funktionieren eines jeden, wenn auch noch so kleinen Unternehmens hängt weitaus stärker von der Tatsache ab, dass man die Projekte unter Kontrolle hat, als von gelegentlichen Wundern. Natürlich müssen sich diese beiden Aspekte nicht gegenseitig ausschließen. Die Kontrolle zu behalten, heißt zu gewährleisten, dass die Ergebnisse den Erwartungen entsprechen. Das erfordert zwei Dinge: 1. Man muss das Projekt so organisieren, dass die Ausführung auf oder über einem vernünftigen und akzeptablen Qualitätsstandard bleibt. 32

6 Was man nicht messen kann Man muss sicherstellen, dass gesetzte Erwartungen nicht über die Möglichkeiten dieses Qualitätsstandards hinausgehen. Keine dieser beiden Forderungen allein ist eine Garantie für eine erfolgreiche Kontrolle. Aber wo kommt dieser»vernünftige und akzeptable Qualitätsstandard«her? Wie können wir so einen Qualitätsstandard eingrenzen? Wie können wir die Ausführung über die Projektdauer hinweg in vernünftigen Bahnen halten? Welche Maßnahmen können wir ergreifen, um Abweichungen während des Projektverlaufs möglichst früh erkennen zu können? Diese Fragen sind nicht leicht zu beantworten. Jeder Versuch, darauf eine Antwort zu finden, führt uns in den Bereich der Messung. 1.4 Der Sinn des Messens»Ich hoffe, Sie können mir bei meiner Schätzung helfen. Ich bin nun mal ein schlechter Schätzer.Wie schlecht?einfach furchtbar schlecht.«der Manager, der um Hilfe bat, hatte zuvor mit einer seiner Schätzungen ein Fiasko erlebt. Aber als er unter Druck geraten war, konnte er den Umfang seiner Probleme nicht angeben. Er hatte auch nicht festgehalten, wie viel Zeit und Geld bisher auf das Projekt verwendet worden waren. Und auf seine ursprünglichen Schätzungen, nun, da konnte er nicht zurückgreifen, sie waren im Durcheinander verloren gegangen. Schätzen ist ein komplexes Unterfangen, und die Gründe, die für unsere schlechten Schätzungen verantwortlich sind, sind vielfältig. (Mehr darüber in Kapitel 2.) Aber wenn die Probleme unseres Managers auch so trivial gewesen wären, dass er sich nur bei einem einzigen Faktor verschätzt hätte, so hätte er doch nichts daraus gelernt. Da er das Ergebnis keiner Messung unterzog und nicht mit der ursprünglichen Schätzung verglich, versäumte er seine einzige Chance, etwas dazuzulernen. 33

7 Kapitel 1 Unter Kontrolle Ihre einzige Chance, die für Schätzungen notwendigen Fähigkeiten auszubauen, versäumen Softwaremanager am laufenden Band. Man hat beispielsweise fast noch nie gehört, dass über ein Softwareprojekt auch nach dem Abschluss Buch geführt wurde. Abgesehen von wirklich erfolgreichen Projekten stiehlt sich am Ende jeder davon, ohne von den tatsächlich entstandenen Kosten Notiz zu nehmen. Schätzungen für das nächste Projekt werden angegangen, als habe es das vorherige niemals gegeben, und niemand lernt aus vergangenen Fehlern. Wenn Manager in der Luftfahrtindustrie genauso ungezwungen mit der Analyse ihrer Fehler (Abstürze) umgingen, wäre die Öffentlichkeit empört. Aber auf unserem Gebiet ist das Ignorieren der Lektionen, die uns vergangene Projekte erteilen, die Regel. Natürlich sollte es nicht so sein. Eigentlich sollten wir über den Trümmern unserer Fehlplanungen brüten, sie analysieren und nach neuen Methoden suchen, und so vorgehen wie die Crash-Experten in der Luftfahrtindustrie. Der einzige unverzeihliche Fehler ist derjenige, dass man Fehler, die in der Vergangenheit gemacht wurden, wiederholt. Dieser Grundsatz trifft besonders auf das Schätzen zu. Aus einer schlechten Schätzung nichts zu lernen, ist unverzeihlich. Wir können etwas lernen aus dem»post mortem«, das ein genauso notwendiger Teil eines Projekts ist, wie es die Analyse, der Entwurf und das Codieren sind. Aber das ist nicht genug. Auf dem Schlachtfeld eines mühsam zu Ende gebrachten oder abgebrochenen Projekts sind wir möglicherweise nicht einmal in der Lage, die fundamentale Frage»Wo sind Zeit und Geld geblieben?«zu beantworten. Wir müssen Methoden einführen, die es uns erlauben, während des Projektverlaufs genau zu messen und Buch zu führen, um sicherzustellen, dass am Ende alle entscheidenden Daten zur Verfügung stehen. Dieses Messen und Buchführen bezeichne ich als das Messsystem. Die Bedeutung des Messens für die Erweiterung der Fähigkeit, etwas richtig einzuschätzen, habe ich bereits betont. Aber auch der Ausbau anderer für ein Projekt wichtiger Fertigkeiten könnte gleichermaßen von sorgfältigen Messungen profitieren. Das Messsystem sollte Antworten auf Fragen wie die folgenden liefern: Wie gut war unser Entwurf? (Unsere Spezifikation? Unsere Testversion? Unser Code?) Half 34

8 Was man nicht messen kann... oder schadete uns die neue Methode XY? Wie viel Zeit und Arbeitsaufwand wurden nutzlos vergeudet, und warum? Zahlten sich unsere Investitionen in die Fortbildung aus? Jeder Teilaspekt eines Projekts, der Kontrolle erfordert, erfordert gleichermaßen eine Messung. Kontrolle ist ohne Feedback nicht möglich. Deshalb kann man nicht kontrollieren, was man nicht messen kann. Wenn Sie sich mit diesem Gedanken, einem Grundprinzip dieses Buchs, anfreunden können, sollten Sie zwei Schlussfolgerungen bedenken: Inwieweit man etwas unter Kontrolle hat, hängt von der Messgenauigkeit ab. Alles, was man überhaupt nicht misst, entzieht sich der Kontrolle. Um die Kontrolle über den Software-Entwicklungsprozess zu behalten, müssen Methoden zum sorgfältigen und effektiven Messen eingeführt werden. Wenn man nicht misst, gibt es nur einen einzigen Grund zu glauben, man behalte die Kontrolle: unverbesserlicher Optimismus. 1.5 Die Zielsetzung dieses Buchs Die Zielsetzung dieses Buchs ist es, Ihnen zu helfen, in Ihrem Unternehmen eine Messfunktion einzuführen und anzuwenden. Wenn Sie sie anwenden, können Sie erwarten, folgende Früchte zu ernten: bessere Kontrolle über Softwareprojekte; weniger und geringere Überschreitungen; frühzeitigere Erkennung von Fehlern genauere Anfangsschätzungen besseres Management für die gesteckten Erwartungen mehr Freiraum, den Software-Entwicklungsprozess zu verbessern und ihm den letzten Schliff zu geben bessere Beziehungen zu Ihren Kunden Messen bedeutet immer, vergangene Prozesse aufzuzeichnen. Unsere Messungen dienen uns fast immer dazu, künftige Auswirkungen quantitativ vorherzusagen. Dennoch wissen wir, dass die Vergangenheit nicht die Zukunft bestimmen kann. Dieses Paradoxon ist keine 35

9 Kapitel 1 Unter Kontrolle Eigentümlichkeit dieses Buchs, sondern liegt jeder Anwendung der Wissenschaft der Statistik zugrunde. Statistiken können nicht vorhersagen, aber sie können Entwicklungen andeuten. Sie können ein gewisses Maß an Vertrauen in die Wahrscheinlichkeit vermitteln, dass ein Ereignis in der Zukunft eine Funktion von Messungen von ähnlichen Ereignissen in der Vergangenheit ist. Der erste Beweis, den ich dafür anführe, dass dieses Buch seine Ziele erreichen kann, ist die Existenz der Statistik. Messungen und statistische Schlussfolgerungen werden auf vielen Gebieten benutzt, um die Ausführung künftiger Projekte zu planen. Im Bauwesen setzt sich die Schätzfunktion zum Beispiel aus rein statistischen Daten zusammen, die aus vergangenen Aufträgen stammen. Ein Schätzer aus dem Baugewerbe arbeitet mit einem Leistungsverzeichnis oder Schätzhandbuch, gefüllt mit Tabellen. Für ein paar Euro kann man ein Leistungsverzeichnis für Holzkonstruktionen erstehen. Wenn es ein solches Buch für Softwareschätzungen gäbe, hätten Sie gut daran getan, es anstelle dessen zu kaufen, das Sie gerade lesen. Dennoch ist ein Softwareschätzbuch nicht außer Reichweite des Möglichen. Schon heute werden viele Aufgaben bei der Software-Entwicklung (besonders jene am Ende des Entwicklungszyklus) mit Methoden geplant, die den Leistungsverzeichnissen nachempfunden sind. Firmen, die vor zwei Jahren begannen, Messsysteme zu implementieren, bringen jetzt substanziell bessere Schätzungen zustande, die auf sorgfältig zusammengetragenen lokalen Erfahrungswerten beruhen. 36