In der Vorlesung Projektmanagement hört man folgendes: Die Produktivität eines Softwareentwicklungsteams ist konstant. Will man mehr leisten, in kürzerer Zeit leisten, zu geringeren Kosten leisten oder in höherer Qualität leisten, leiden die jeweils anderen Aspekte. Es ist unmöglich alle diese Punkte gleichermaßen zu verbessern.
Der Zusammenhang lässt sich mit dem so genannten Teufelsquadrat nach Sneed visualisieren. Der blaue Bereich in der Mitte der Grafik ist die Produktivität des Teams. Zieht man nun an einer oder mehreren Ecken, so drückt man gleichzeitig die anderen Ecken ein. Die Fläche in der Mitte – die Produktivität – bleibt immer konstant.
Das ist sehr anschaulich und auch intuitiv verständlich. Aber ist es auch richtig? Gerade letztens habe ich bei Martin Fowler etwas Interessantes dazu gelesen.
Fowler spricht bei dem oben erläuterten Zusammenhang von der Tadable Quality Hypothesis. Er weist dabei auf einen wichtigen Punkt hin: Die Qualitätsecke lässt sich nicht so einfach gegen die anderen Ecken aufwiegen.
Fowler zitiert Kent Beck, der Qualität in interne und externe Qualität unterteilt. Externe Qualitätsmerkmale sind dabei diejenigen, um die es dem User letztendlich geht. Usability ist ein klassisches Beispiel dafür, aber auch Sicherheit, Zuverlässigkeit und Performance zählen dazu. Für diese Qualitätsattribute gilt die Tradable Quality Hypothesis. Man kann recht einfach darauf verzichten, sich weitere Gedanken zu machen, wie man ein Feature leichter benutzbar machen könnte, man kann auf die Implementierung von Sicherheitsfeatures, Caches und redundanten Systemteilen verzichten und Security Audits und Optimierungen auslassen. Inwieweit das eine gute Idee ist, ist eine andere Frage, aber es ist möglich.
Anders sieht es mit den internen Qualitätsmerkmalen aus. Interne Qualitätsmerkmale sind solche, um die es hauptsächlich dem Entwickler geht. Also Änderbarkeit, Wartbarkeit, Testbarkeit, u.ä. Hier kann man nicht einfach so sparen und damit an Zeit gewinnen und die Kosten senken. Im Gegenteil: Spart man an interner Qualität wird das über kurz oder lang mehr Zeit und Geld kosten, weil die Softwarewartung viel mehr Zeit beansprucht, deutlich mehr Bugs zu fixen sind, diese nicht frühzeitig erkannt und daher verschleppt werden. Ebenso wird die Implementierung neuer Features zeitaufwändiger werden.
Eigentlich ist das vollkommen einsichtig, aber dennoch wird das – so Fowler – wohl oft nicht bedacht:
Martin Fowler
I commonly come across developers who are frustrated because „management want more features, they don’t care about quality“. I’m always sad when I hear this, because when I hear this I know that the developers, management and their customers have already lost.
Permalink
Ich denke schon, dass man die interne und die externe Qualität miteinander vergleichen kann. In beiden Fällen zahlt der Auftraggeber die schlechtere Produktqualität. Im einen Fall mit potenziell geringerem Nutzen, im anderen mit höheren Wartungs- und Weiterentwicklungskosten.
Und es liegt nicht im Ermessen der Entwickler, ob sie das tun wollen, sondern in dem des Auftraggebers/Entscheiders. Lediglich sind ihm die Konsequenzen klar vor Augen zu führen. Scrum-Teams sehen das etwas anderes, aber wer die Musik bezahlt, der bestimmt, was gespielt wird 😉
Für IT-Projekte ist es aber wesentlich, dass man überhaupt das Modell des Teufelsquadrats hernimmt und nicht das magische Dreieck, denn dort wird Leistung und Qualität miteinander vermischt und man kann sie nicht mehr sauber getrennt managen. Siehe auch http://cio-blog.de/den-teufel-bei-den-hoernern-gepackt-projektsteuerung-nach-harry-m-sneed.
Gruß
Peter
Permalink
Hallo Peter,
danke für den Kommentar. Und ebenso auch Danke für den Link. Das „PMI-Modell“ kannte ich noch gar nicht. Wobei ich da ja nichts verpasst zu haben scheine.
Grundgedanke des Teufelsquadrats ist, dass die vier Steuerungsgrößen im Groben negativ korreliert sind. Wenn ich an einer Ecke ziehe, müssen die anderen irgendwie nachgeben. Wenn ich eine Ecke reindrücke, kann ich an jeder beliebigen anderen ziehen.
In der Regel funktioniert das ganz gut. Nur bei interner Qualität wird es etwas schwieriger. Möchte man zu Lasten der internen Qualität das Projekt schneller abschließen, geht das bis zu einem gewissen Grade noch. Das hat natürlich Nachteile, denen man sich bewusst sein muss und die man einem Entscheider bewusst machen muss. Völlig klar.
Angenommen, man ist sich dessen bewusst und die Entscheider sind gewillt, die Nachteile zu tragen, so geht das trotzdem nur bis zu einem gewissen Punkt gut. Senkt man die interne Qualität weiter, hat dies auf einmal keine positiven, sondern vielmehr negative Auswirkungen auf die Zeitgröße.
Das Ganze ist abhängig von der Größe des Projekts. Ist es klein, wird von einer Reduktion der Qualität „nur“ die Wartbarkeit in Mitleidenschaft gezogen. Je größer das Projekt ist, desto eher bekommt man die negativen Auswirkungen aber schon zur Entwicklungszeit zu spüren. Das hat zur Folge, dass das Projekt nicht trotz, sondern wegen der Qualitätsreduktion länger dauert, mehr kostet, etc. Deshalb denke ich schon, dass interne Qualität keine vollkommen beliebig steuerbare Größe ist. Qualität ist komplizierter als das Teufelsquadrat abbilden kann.
Aus ähnlichen Gründen heißt die vierte Achse im Teufelsquadrat nicht „Anzahl Mitarbeiter“ sondern „Kosten“. Die Anzahl der Mitarbeiter ist ab einem gewissen Punkt nicht mehr negativ mit der Zeit (oder eher Entwicklungsgeschwindigkeit) korreliert. Brooks‘ Law: „Adding manpower to a late project makes it later“.
Deshalb funktioniert das Teufelsquadrat mit einer Mitarbeiter-„Ecke“ nicht mehr. Mit der Kostenecke sind dann noch weitere Entscheidungen bzw. Möglichkeiten abgedeckt (make or buy, Tooleinsatz, Einsatz von erfahreneren, teureren Entwicklern, etc.). Außerdem entsteht nicht so schnell der Eindruck, man könnte einfach die doppelte Anzahl Entwickler draufwerfen und damit die Entwicklungszeit entsprechend verringern. Man kann mehr Geld in die Hand nehmen und muss dann aber sehen, wie man es sinnvoll einsetzt.
Ebenso kann man die Qualität reduzieren. Aber genauso wenig, wie beliebiges Geldausgeben hilft, wird beliebige Qualitätsreduktion den gewünschten Effekt haben. Und genau hier sehe ich einen Unterschied in interner und externer Qualität.
Viele Grüße
Christian
Permalink
Hallo Christian,
Deine Argumentation ist schlüssig. Und wie Du selbst anführst, trifft sie nicht nur bei der internen Qualität zu, sondern lässt sich auf alle 4 Dimensionen anwenden: wenn die Verwerfung im Projekt so groß ist, dass die anderen Dimensionen über ein bestimmtes Maß hinaus korrigiert werden müssen, dann hilft das Modell nicht weiter. Das ist der Punkt, wo eine grundlegende Sanierung, wahrscheinlich ein Neuanfang fällig ist. Und wo man wahrscheinlich auch über die Rahmenbedingungen sprechen muss. Denn die meisten Probleme sind nicht gottgegeben, sondern hausgemacht.
Und was für die interne Qualität richtigerweise gilt, gilt natürlich auch für die externe Qualität und den Leistungsumfang: nämlich dass es eine Untergrenze gibt, die man nicht unterschreiten darf, weil das Projektergebnis sonst nicht mehr brauchbar ist.
Gruß
Peter
Permalink
Hm… du machst mich nachdenklich. Gilt die selbe Problematik wirklich in allen Dimensionen? Klar wird dem Auftraggeber irgendwann die Rahmenbedingungen bezüglich Zeit, Kosten, Funktionsumfang, sowie externe bzw. interne Qualität nicht mehr gefallen, sodass das Projekt daran letztendlich scheitern wird. Das ist das eine und das gilt für jede der genannten Größen. Das stimmt.
Für die interne Qualität gilt darüber hinaus, dass schon ab einem früheren Punkt eine Reduktion nicht mehr in größeren Freiheiten bezüglich der anderen Größen resultiert. Das Projekt muss daran (noch) nicht scheitern, aber das Teufelsquadrat bildet diesen Zusammenhang nicht ab.
Für die anderen Größen sehe ich das genannte Problem momentan nicht. Bei „Anzahl Mitarbeiter“ wäre die Problematik, wie erläutert, gegeben. Aber die Kostenachse hat durch den größeren Abstraktionsgrad die Problematik nicht oder nur bedingt.
Hast du Beispiele dafür, wie eine Reduktion von Funktionalität oder externer Qualität bzw. eine Erhöhung der Kosten oder Entwicklungszeit sich wirklich negativ auf die anderen Größen auswirken?
Viele Grüße
Christian
Permalink
Da hab ich mich wohl nicht sauber ausgedrückt. Zunächst habe ich 2 unterschiedliche Sachverhalte geschildert:
1. Ab einer bestimmten Größe der Verwerfung (oder des Problems) sind die Auswirkungen auf die anderen Dimensionen so groß, dass uns das Modell nicht mehr weiterhilft. Wenn ich z.B. mitten im Projekt die Restlaufzeit halbieren will, dann ist das halt nicht darstellbar. Und das Problem fängt schon bei weit weniger als Halbierung an. Dieser Sachverhalt, dass eine Einflussnahme nur bis zu einer bestimmten Obergrenze gehen darf, gilt für alle Dimensionen.
2. Für die Dimensionen Qualität und Funktionalität gilt zusätzlich, dass sie feste Untergrenzen besitzen. Wird eine der Untergrenzen unterschritten, dann ist das Ergebnis unbrauchbar. Sei es, weil es nicht mehr gewartet werden kann (innere Qualität), weil es nicht den Anforderungen oder der Stabilität entspricht (äußere Qualität) oder sei es, weil maßgebliche Funktionen fehlen (Funktionalität).
Hoffe, das hilft als Erläuterung …
Gruß
Peter