Überarbeitung von Softwareprojekten

Software-Überarbeitung erklärt

Software-Überarbeitung ist die Folgearbeit, die aus der Änderung von Anforderungen, Designs, Code und Tests entsteht, nachdem einige Arbeiten bereits begonnen haben. Bei den meisten Softwareunternehmen macht dies 30-50% aller Aktivitäten aus. Fehlerbehebungen schließen wir generell aus der Kategorie Software-Nacharbeit aus. Nacharbeit beschreibt im Allgemeinen die zusätzliche Arbeit, die eine Folge einer „Anforderungsänderung“ ist.

Software-Überarbeitung – gut oder schlecht

Einige Überarbeitungen können als positiver Indikator dafür gewertet werden, dass das Feedback der Benutzer zu Veränderungen in Richtung des Bedarfs führt. Dies ist gerechtfertigt, wenn die Änderungen unvorhersehbar waren. Der typische Nacharbeitsaufwand bei Softwareprojekten liegt jedoch hartnäckig bei etwa 30-501 TP3T des gesamten Aufwands. Dadurch kostet die Bereitstellung von Software für die meisten Unternehmen wesentlich mehr, als sie sollte.

Wie Software-Überarbeitungen die Kosten in die Höhe schnellen lassen

Ein besonderes Problem bei der Softwareüberarbeitung besteht darin, dass sie langsamer oder weniger produktiv ist als die ursprüngliche Entwicklung. Mit anderen Worten: Das erste Schreiben von Code ist schneller, als diesen Code zu ändern, um etwas anderes zu tun. Mithilfe eines Standardansatzes zur Softwaremessung und -produktivität können wir die Produktivität von Softwareteams bei der ersten Erstellung und bei der Überarbeitung verfolgen. Typische Entwickler-Build-Raten liegen bei etwa 1 KOSMISCHER Funktionspunkt (CFP) pro Tag (typischer Bereich: 0,7–2 CFP/Tag), während die Produktivität bei Nacharbeiten mit 0,75 CFP pro Tag geringer ist.

Wenn eine Nacharbeit erforderlich ist, entsteht für Sie der Aufwand, die Arbeit zunächst durchzuführen (1 Tag für 1 CFP) und sie dann (weitere 1,5 Tage pro CFP) zu ändern. Die Gesamtkosten betragen also 2,5 Tage statt 1 Tag.

Diese einfache Erklärung zeigt, wie bescheidene IT-Projekte zu einer budgetbedingten Katastrophe werden können. Durch die frühzeitige Verfolgung der Anforderungsqualität wird die Wahrscheinlichkeit einer Katastrophe vorhersehbar. Darüber hinaus können frühere Nacharbeiten erheblich reduziert werden, wenn der Anforderungsqualität mehr Aufmerksamkeit geschenkt wird.

Die Hauptursachen für Nacharbeiten

Wenn uns bewusst wird, dass eine Funktion, die wir erstellen oder erstellt haben, nicht richtig ist, muss eine Entscheidung darüber getroffen werden, ob wir sie falsch belassen oder korrigieren. Je später im Entwicklungslebenszyklus diese Entdeckung gemacht wird, desto mehr Nacharbeit, Unterbrechungen und Verzögerungen werden verursacht. Dabei spielt es keine Rolle, ob die Anforderung das Ergebnis eines Gesprächs, einer schriftlichen User Story oder eines ausführlicheren schriftlichen Dokuments ist. Die Unrichtigkeit oder Missverständnisse sind wahrscheinlich die Ursache für die Nacharbeit. Möglicherweise wurde die ursprüngliche Anforderung missverstanden, falsch interpretiert oder falsch kommuniziert, was auf eine schlechte Kommunikation hinausläuft. Schlechte Kommunikation wird manchmal als „sich ändernde Anforderungen“ abgetan oder falsch dargestellt, obwohl dies in Wirklichkeit nicht der Fall war.

Die meisten Veränderungen sind nicht echt

Sehr selten erleben wir während eines Projekts eine echte unerwartete Änderung der Geschäftsbedingungen, die zu geänderten Anforderungen führt. Die meisten Anforderungen sind jedoch bereits bekannt oder erkennbar. Ebenso sind die meisten Architekturentscheidungen, die zur Erfüllung dieser Anforderungen erforderlich waren, (im Voraus) erkennbar. Manchmal sagt der Benutzer: „Wir wissen nicht, was wir brauchen, bis wir es sehen.“ Um diese Anforderungen zu ermitteln, müssen zusätzliche Erhebungstechniken wie Prototyping eingesetzt werden.

Die überwiegende Mehrheit der „Anforderungsänderungen“ und damit Nacharbeiten werden durch mangelhafte oder unvollständige Anforderungsarbeit verursacht.

Einige anforderungsbezogene Grundursachen für Nacharbeiten (eine unvollständige Liste):

• Schlecht formulierte Anforderungen
• Bekannte, aber nicht angegebene Anforderungen (Auslassungen)
• Inkonsistenzen über eine Reihe von Anforderungen hinweg.
• Nicht deklarierte Anforderungen, die durch Prototyping hätten entdeckt werden können (d. h. der Benutzer muss zuerst etwas sehen)
• Nicht deklarierte Anforderungen, die durch Analyse hätten entdeckt werden können
• Verwirrung zwischen Geschäftszielen, funktionalen Anforderungen und Akzeptanzkriterien. (schlechte Artikulation).
• Verwirrung zwischen funktional, nicht funktional, Einschränkungen und Aufgaben.
• Und vielleicht der einzig legitime Grund für eine Überarbeitung: unerkennbare, unbekannte Anforderungen

Nacharbeit bleibt auf hohen Ebenen weit verbreitet – Begründung

Die meisten Studien zeigen, dass 30-50% des gesamten Aufwands für Softwareprojekte für Nacharbeiten aufgewendet werden. Es gibt mehrere Gründe, warum die Nacharbeitsquote weiterhin hoch ist. Einige der Gründe werden selten diskutiert, da es sich dabei möglicherweise um unbequeme Wahrheiten handelt.

Inkonsistente Anforderungen und Qualitätsstandards

Die Branche kann sich nicht darauf einigen, was gute Anforderungen ausmacht. Eine Organisation, die versucht, die Qualität von Anforderungen zu fördern, ist das IIBA. Für die meisten Menschen gibt es keine formalen Standards für die Schreibanforderungen und die Qualität ist im Allgemeinen niedrig.

Wichtige Kommunikation vermeiden

Die meisten Entwickler schreiben gerne Code, sie sind oft introvertiert und keine guten Kommunikatoren. Die menschliche Interaktion fällt ihnen möglicherweise nicht so leicht und sie geben sich lieber mit Nacharbeiten zufrieden, als mit anspruchsvollen Anforderungsgesprächen im Vorfeld.

Entwicklerteams bezeichnen Nacharbeiten oft als „Refactoring-Code“. Sie könnten schlechte Anforderungen berücksichtigen und die Ausrede verwenden: „Wir sind agil und lernen, während wir gehen.“ Oder sie könnten sagen, dass die Benutzer nicht wussten, was sie wollten, bis wir es ihnen zeigten. Ersteres ist eine Ausrede dafür, „nicht zu lernen, bevor wir gehen“; Letzteres ist ein Problem, das mit Prototyping kostengünstiger gelöst werden kann.

Keine Verantwortung für gute User Stories

Die User Stories sind die tragende Säule der Kommunikation eines agilen Teams darüber, was gebaut werden soll. Doch wer ist für die User Stories verantwortlich? Wer ist dafür verantwortlich, sicherzustellen, dass sie einen ganzheitlichen Bedarfskatalog korrekt beschreiben, der wertvolle Fähigkeiten hervorbringt? Verschiedene Teams geben unterschiedliche Antworten, manche sagen der Product Owner, andere sagen das gesamte Team. Mangelnde klare Verantwortlichkeiten können zu qualitativ minderwertigen User Stories führen, was wiederum zu Missverständnissen und Nacharbeiten führt. Wer ist für die Qualität der User Stories verantwortlich? Auch auf diese Fragen erhalten wir widersprüchliche Antworten. Die Überprüfung der Klarheit einer User Story ist eine mühsame Arbeit, an der mindestens drei Teammitglieder (die drei Amigos) beteiligt sind. Es ist eine zeitaufwändige und ziemlich langweilige Arbeit, die oft, wenn überhaupt, spontan geschieht. Im Idealfall wird der Bedarf an diesen Sitzungen durch die gemeinsame Unterbringung des Teams reduziert. Bei Remote-Arbeit ist eine Co-Location praktisch unmöglich. In manchen Fällen ist der Product Owner ein Stellvertreter des echten Benutzers und ein echter Fachexperte. Alle führen zu geringeren Qualitätsanforderungen.

Verträge, die den Nacharbeitsaufwand erhöhen

Wenn Softwareentwicklung ausgelagert wird. Das Unternehmen, an das die Arbeit ausgelagert wird, wird in der Regel auf Tagessatzbasis bezahlt. Je mehr Tage gearbeitet wurden, desto mehr Tage wurden ihnen in Rechnung gestellt. Es mag einige vertragliche Merkmale geben, die oberflächlich betrachtet zu effizientem Arbeiten ermutigen, aber diesen mangelt es in der Regel an Zähnen. Letztendlich liegt es in der Regel im Interesse der beauftragten Organisation, ein hohes Maß an Nacharbeit vorzunehmen. Und so sehen wir bei vertraglichen Aufträgen oft die schlechtesten Anforderungen. Meiner Erfahrung nach gibt es eine Farce über effiziente Arbeit, in Wirklichkeit werden die meisten Auftragnehmer dazu angeregt, das Projekt in die Länge zu ziehen und mehr Manntage zu verkaufen. Bei schlechten Anforderungen ist die Nacharbeit hoch und mehr abrechenbare Stunden sind unvermeidlich. Seien Sie vorsichtig, wenn Sie vertraglich vereinbarte Softwareentwicklung kaufen.

Kulturelle Ursachen der Nacharbeit

Wenn eine Anforderung unklar ist, sollte das Team ihr Verständnis überprüfen, bevor es mit der Arbeit beginnt. Eventuelle Missverständnisse führen wahrscheinlich zu Nacharbeiten. In manchen Kulturen ist das Hinterfragen der Kundenanforderungen ein unangenehmes Gespräch, das der Kunde lieber vermeiden möchte. Stattdessen kann das Team anhand von Annahmen arbeiten und diese Annahmen weiterentwickeln. Dies ist besonders häufig bei ausgelagerten Verträgen der Fall. Wenn die Anforderungen in einer Sprache verfasst sind, die nicht die Muttersprache aller Teammitglieder ist, ist die Wahrscheinlichkeit von Missverständnissen (und damit von Überarbeitungen) sehr hoch.

Reduzierung der Nacharbeit

Beobachten und quantifizieren Sie das Problem

Fragen Sie sich am Ende jedes Sprints, wie viel Arbeit wir gerade geleistet haben, nämlich Nacharbeit im Vergleich zu neuer Arbeit. Stellen Sie dann die Frage, wie wir das hätten vermeiden können. Erfassen Sie abschließend den Mehraufwand (also die Kosten), der dadurch entstanden ist, dass Sie die Arbeit mehr als einmal erledigen mussten.

Machen Sie sich Standards zum Schreiben guter Anforderungen zu eigen

Unsere empfohlene Liste von Qualitätsmerkmalen lautet:

1. Klar
2. Prägnant
3. Benutzerorientiert
4. Testbar
5. Messbar
6. Konsistent
7. Vollständig
8. Einzigartig
9. Wertvoll
10. Designfrei

Mit Ausnahme von #9 in dieser Liste prüft ScopeMaster Ihre Anforderungen automatisch auf die Einhaltung dieser Qualitätsmerkmale, sodass Sie diese nicht manuell überprüfen müssen. (Wir empfehlen die INVEST-Liste nicht, da sie nicht alle oben genannten Merkmale abdeckt, die wir für wichtig erachtet haben.)

Verwenden Sie Tools, die die Anforderungen verbessern

OK, also haben wir ScopeMaster genau für diesen Zweck entwickelt. Mit ScopeMaster können Sie 9/10 der oben aufgeführten gängigen Qualitätstypen aufdecken und auflösen, und zwar etwa zehnmal schneller als bei manueller Vorgehensweise. Kurz gesagt: Sie können mit einer drastischen Reduzierung der Nacharbeit rechnen, wenn Sie ScopeMaster verwenden, der Sie bei der Bewertung und Verfeinerung Ihrer Anforderungen unterstützt. Es gibt andere Tools von QVScribe und sogar IBM Doors, aber diese kratzen nur an der Oberfläche dessen, was ScopeMaster leistet.

Schreiben Sie Verträge, die Anreize für geringe Nacharbeit bieten

Es gibt mehrere Möglichkeiten, dieses Problem anzugehen. Erstens muss man sich genau darüber im Klaren sein, dass es sich um ein Problem handelt. Denken Sie daran, dass die meisten Nacharbeiten vermeidbar sind. Wir verfügen über ein Paket an Vertragsempfehlungen, die Ihnen dabei helfen können, Ihre ausgelagerten Entwicklungsverträge so zu gestalten, dass die Wahrscheinlichkeit von Nacharbeiten minimiert wird.

Nacharbeit quantifizieren

Wir haben gesehen, dass Nacharbeiten aufgrund schlechter Anforderungen zu einer Aufwandssteigerung von 1x auf 2,5x führen. Dies ist eigentlich eine bescheidene Schätzung, denn wenn Sie die Richtung ändern, kann sich die Unterbrechung eines Codeblocks negativ auf andere Teile der Codebasis auswirken und noch mehr Nacharbeit erfordern.

Fehler vorhersagen – Zahlen nutzen, um Nacharbeit zu reduzieren

In Studien wurden Daten zur Entstehung und Beseitigung von Mängeln erhoben. Diese haben gezeigt, dass Fehlerpotenziale in jedem der wichtigsten Artefakte der Softwareentwicklung auftreten: Anforderungen, Design, Code, Tests. Die Konsequenz ist, dass wir das Fehlerpotenzial jedes einzelnen kennen und daher wissen, wie viele Fehler wir beseitigen müssen, bis wir eine zufriedenstellende Qualität erreichen. Auch hier wissen wir anhand der Standarddimensionierung, dass das typische Fehlerpotenzial etwa 5 Fehler pro CFP beträgt, von denen 1 wahrscheinlich in den Anforderungen liegt. Wir wissen auch, dass die durchschnittliche Größe einer User Story 5,5 CFP beträgt und wir daher ein Anforderungsdefektpotenzial von 5,5 pro User Story haben. Das bedeutet, dass diese 5.5-Mängel bestehen bleiben und später zu Nacharbeiten werden, wenn wir nicht proaktiv vorgehen. Tools wie ScopeMaster können etwa 50% der Fehler in Anforderungen finden, also 2-3 pro User Story. Dadurch wird die wahrscheinliche Ursache für Nacharbeiten halbiert.

Geschrieben von Colin Hammond, 35 Jahre IT-Erfahrung und Gründer von ScopeMaster.