Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03466.jsonl.gz/1065

Fixed Scope und Fixed Time Vorhaben führen zu minderer Qualität. Mindere Qualität hat Konsequenzen. Dieser Blogbeitrag beschreibt den Preis, der bezahlt werden muss.
Als Beispiel dient ein «Fixed Time - Fixed Scope» Vorhaben eines Kunden, welches in diesem Blogbeitrag bereits umschrieben wurde.
Das Projektmanagement-Dreieck beschreibt den Zusammenhang von Projektgrössen und hat je nach Blickwinkel vermeintlich andere Kanten respektive Projektparameter. Die Aussage ist, dass man maximal zwei der Projektparameter festlegen kann, und der dritte Parameter entsprechend veränderbar ist. Bei der Software-Entwicklung hat sich gezeigt, dass häufig die Kanten fachlicher Scope (fachlicher Umfang der Software), Time (der Zeitpunkt, wann die Software geliefert werden soll) und technische Qualität (die technischen Qualitäten, die die Software aufweist: Anzahl Bugs, Anzahl Shortcuts, Anzahl alte Technologien in der Lösung etc.) sinnvolle Parameter sind.
Auch bei «Fixed Time - Fixed Scope» Vorhaben startet man normalerweise mit dem guten Vorsatz, auf die entwickelte Code-Qualität zu achten. Je näher eine Deadline rückt, desto mehr ist man gezwungen, Shortcuts in der Entwicklung zu nehmen. Jedoch ist, wie der Name schon sagt, der Scope fix und wird nicht verkleinert. Stattdessen wird zwangsläufig mindere Code-Qualität geliefert. Denn dies ist der einzige Parameter, den man noch verändern kann.
Deadlines mit fixem Scope sind meistens das Symptom von externen Abhängigkeiten. Versprechen, die jemandem ausserhalb des Teams gegeben wurden, wann dieses oder jenes fertig sein wird. Beim porträtierten Kunden-Team ist dies beipielsweise ein Versprechen, welches die Marketing-Abteilung einforderte, welcher Scope zu welcher Zeit geliefert wird, damit TV-Werbeslots eingeplant und Werbefilme gedreht werden konnten. Damit nun diese Kosten nicht unnötig ausgegeben werden, wird die rechtzeitige Lieferung des benötigten Scopes eingefordert. Es ist also eine nachvollziehbare wirtschaftliche Forderung, um nicht unnütz Geld auszugeben.
Diese kostenbewusste Forderung geht nun jedoch Hand in Hand mit möglichen neuen Kosten, die dadurch verursacht werden: Die erhöhten Betriebs- und Weiterentwicklungs-Kosten durch mindere Qualität. Denn wie vorher ausgeführt, geht man mit der Forderung nach Deadlines mit fixem Scope zwangsläufig das Risiko ein, Code-Qualitätseinbussen zu verursachen. Man muss also die Kosten beider Medaillenseiten kennen, um einen fundierten Entscheid fällen zu können.
The bitterness of poor quality remains long after the sweetness of low prices is forgotten.
(Benjamin Franklin)
Meistens wird kein bewusster Entscheid dazu gefällt. Auch beim porträtierten Kunden-Team war dies nicht anders. Kein Entscheidungsträger entschied also bewusst, dass geringere Code-Qualität geliefert werden soll, sondern nur, dass die Deadline gehalten werden muss, damit die Marketing-Kosten nicht explodieren.
Die folgende Tatsache verdeutlicht das schwerwiegende Problem minderer Code-Qualität: Betrachtet man die Kosten im Lifecycle einer Software, dann sind nicht die initialen Entwicklungskosten vor dem GoLive der grosse Brocken, sondern alles, was danach kommt. Laut Wikipedia entsprechen die Software-Wartungskosten 80-90% der Total Costs of Ownership und nur 10-20% machen somit die initialen Investitionen aus. (Ich gehe davon aus, dass diese IT-Kosten die TV-/Marketing-Kosten deutlich übersteigen. Dieses Bewusstsein muss entwickelt werden.)
Mindere Code-Qualität führt zu längerer Time-to-Market und im Extremfall kann mindere Code-Qualität ganze Softwareentwicklungsteams lahmlegen.
Die Software Maintenance Trap stellt sich ein.
Einige Entwickler laufen davon. Andere Entwickler bleiben bei ihrem Job und «überleben» die Mitarbeitenden-Fluktuationen im Team. Sie sind gezwungen, sich im Code-Dschungel zurecht zu finden. Sie häufen sich ein sehr spezifisches Knowhow an, das nur mangelhaft dokumentiert ist und nicht so einfach transferiert werden kann, weil sie alleine sind und nicht gezwungen sind zu dokumentieren. Neue Mitarbeitende einzuarbeiten, wird schwierig. Nun sind wir definitiv in der Maintenance-Trap angekommen, die dann schnell 10 Jahre andauert, bevor eine Neuentwicklung die alte, schwierig wartbare Software ablöst. Weiterentwicklungen sind kaum mehr umsetzbar oder nur mit einem enormen Kraftakt.
Um nicht in diese Maintenance-Trap zu fallen, und damit ein Team nach Abschluss eines Vorhabens ein neues Vorhaben umsetzen kann, muss die Qualität stets sehr hoch sein!
Das porträtierte Kunden-Team musste auch Shortcuts nehmen, um die Deadline zu halten. Man hat sich jedoch fest vorgenommen, nach der Deadline die Code-Qualität in einem dedizierten Sprint zu verbessern. Sofern nicht die nächste Deadline ansteht.
Das Gute an der oben beschriebenen Argumentationskette: Jede Qualitäts-/Deadline-Entscheidung kann aufs Neue eine Chance sein, das Richtige zu tun.
Was sind eure Erfahrungen in der Softwareentwicklung mit Fixed Time - Fixed Scope Settings?
Möchtest du mehr über die Zusammenhänge im SDLC erfahren? Möchtest du gemeinsam deine Vorhaben challengen und durchleuchten?