Agile Softwareentwicklung: Zeitpläne einhalten

Allen Software-Projekten ist ein unanfechtbarer Kompromiss auferlegt, der als das Eiserne Kreuz (engl. Iron Cross) des Projektmanagements bezeichnet wird. Gut, schnell, preiswert, erledigt: Wählen Sie drei dieser Attribute aus – das vierte ist nicht verfügbar. Ein Projekt kann gut, schnell und preiswert sein, wird dann aber nicht erledigt. Ein Projekt kann auch erledigt, preiswert und schnell sein, dann ist es jedoch nicht gut.

Anhand der vom Projekt gelieferten Daten können Manager feststellen, wie gut, wie schnell und wie preiswert ein Projekt sein sollte und inwieweit es als erledigt betrachtet werden kann. Die Manager erreichen das, indem sie Änderungen am Umfang des Projekts, am Zeitplan, bei der Anzahl der Mitarbeiter und bei der Qualität vornehmen.

Ändern des Zeitplans

Fangen wir mit dem Zeitplan an. Wir fragen die Auftraggeber, ob wir den Termin vom 1. November auf den 1. März verschieben können. Solche Konversationen verlaufen für gewöhnlich nicht sehr angenehm. Denn Sie wissen ja, dass das ursprüngliche Datum aus guten geschäftlichen Gründen gewählt wurde, die sich vermutlich nicht geändert haben. Eine Verschiebung des Projekts bedeutet deshalb häufig eine erhebliche Beeinträchtigung irgendeiner Art.
Es kommt aber auch vor, dass Unternehmen das Datum aus praktischen Gründen auswählen. So könnte es beispielsweise sein, dass im November eine Messe stattfindet, auf der das neue Projekt vorgestellt werden soll. Aber möglicherweise findet im März ebenfalls eine Messe statt, die genauso gut geeignet wäre. Noch stehen wir ja erst am Anfang des Projekts und haben nur einige wenige Iterationen durchgeführt. Wir wollen den Auftraggebern mitteilen, dass wir das Projekt erst im März fertigstellen können, bevor sie einen Stand auf der Messe im November buchen.

Zusätzliche Mitarbeiter

Im Allgemeinen sind Unternehmen schlicht und einfach nicht bereit, den Zeitplan zu ändern. Das Datum wurde aus guten geschäftlichen Gründen ausgewählt, die nach wie vor bestehen. Versuchen wir also, zusätzliche Mitarbeiter zu beschäftigen. Wie jedermann weiß, kommen wir zweimal so schnell voran, wenn wir die Mitarbeiterzahl verdoppeln. Tatsächlich ist genau das Gegenteil der Fall. Brooks Gesetz besagt: Das Hinzufügen von Arbeitskräften zu einem ins Hintertreffen geratenen Projekt verzögert es zusätzlich.

Aus: Clean Agile (Robert S. Martin): Der tatsächliche Effekt zusätzlicher Mitarbeiter

Was tatsächlich geschieht, ist in der Abbildung dargestellt. Das Team arbeitet zunächst mit einer gewissen Produktivität, dann kommen neue Mitarbeiter hinzu. Die Produktivität sinkt einige Wochen lang drastisch, weil die neuen Mitarbeiter den alten das Leben zur Hölle machen. Irgendwann haben sich die neuen Mitarbeiter hoffentlich so gut eingearbeitet, dass sie tatsächlich einen Beitrag leisten. Die Manager setzen darauf, dass die Summe der Flächen unter bzw. über der Kurve insgesamt einen positiven Wert ergibt. Natürlich sind ausreichend Zeit und genügend Verbesserungen erforderlich, um den anfänglichen Verlust wieder wettzumachen. Ein weiterer Faktor ist natürlich, dass zusätzliche Mitarbeiter teuer sind. Oftmals erlaubt das Budget es nicht, zusätzliche Mitarbeiter zu beschäftigen. Nehmen wir hier einmal an, dass keine zusätzlichen Mitarbeiter beschäftigt werden können. Dann wird sich die Qualität ändern.

Sinkende Qualität

Wie jedermann weiß, kommt man schneller voran, wenn man Mist abliefert. Deshalb wird das Schreiben von Tests eingestellt, es finden keine Code-Reviews mehr statt, der ganze Refactoring-Quatsch wird unterlassen und es wird nur noch wie besessen programmiert. Auch 80 Stunden pro Woche, wenn es erforderlich ist. Hauptsache, es wird programmiert! Sie können sich natürlich denken, dass ich Ihnen nun sage, dass es zwecklos ist.

Durch das Abliefern von Mist kommt man nicht schneller voran, sondern langsamer. Das ist die Lektion, die man lernt, wenn man 20 oder 30 Jahre als Programmierer tätig war. So etwas wie »quick and dirty« gibt es nicht. Alles, was »dirty« ist, verlangsamt das Vorankommen. Es gibt nur eine Möglichkeit, schnell voranzukommen, nämlich ordentliche Arbeit zu leisten.
Wir werden den Regler für die Qualität also von 10 auf 11 stellen. Wenn wir den Zeitplan verkürzen wollen, steht nur die Option zur Verfügung, die Qualität zu erhöhen.

Ändern des Umfangs

Es verbleibt also noch eine letzte Sache, die geändert werden kann. Vielleicht, nur vielleicht, müssen ja gar nicht alle geplanten Features bis zum 1. November erledigt sein. Fragen wir doch mal die Auftraggeber.

»Wenn Sie alle diese Features benötigen, wird es bis März dauern. Wenn Sie unbedingt schon im November etwas vorstellen möchten, müssen Sie auf einige Features verzichten.«
»Wir können auf keines der Features verzichten. Wir brauchen sie alle! Und zwar
am 1. November.«
»Oh, das haben Sie falsch verstanden. Wenn Sie alle Features benötigen, werden
wir für die Implementierung bis zum März brauchen.«
»Wir benötigen alle Features, und zwar am 1. November!«

Diese Debatte wird sich noch eine Weile hinziehen, weil keiner nachgeben will. Die Auftraggeber mögen moralisch im Recht sein, aber die Programmierer verfügen über die Daten. Und in einem rational handelnden Unternehmen behalten die Daten die Oberhand.

Wenn es sich so verhält, werden die Auftraggeber sich früher oder später fügen müssen und den Zeitplan in Augenschein nehmen. Sie werden dann der Reihe nach die Features identifizieren, die sie nicht unbedingt bis zum November brauchen. Das ist zwar ärgerlich, aber hat ein rational handelndes Unternehmen eine andere Wahl? Also wird der Zeitplan dementsprechend angepasst. Einige der geplanten Features werden verschoben.

Implementierung nach Geschäftswert

Ab sofort fragen wir die Auftraggeber am Anfang einer neuen Iteration, welche Features als Nächstes implementiert werden sollen. Die Features sind zwar teilweise voneinander abhängig, aber wir sind schließlich Programmierer und wissen mit Abhängigkeiten umzugehen. Irgendwie werden wir es schon schaffen, die Features in der vom Auftraggeber gewünschten Reihenfolge zu implementieren.


Dieser Artikel ist ein Auszug aus dem Buch „Clean Agile – Die Essenz der agilen Softwareentwicklung“ von Robert C. Martin. Alle Infos zum Buch, das Inhaltsverzeichnis und eine kostenlose Leseprobe findet ihr bei uns im Shop.

Kommentar verfassen