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 viel kostet die Softwareüberarbeitung?
Ein besonderes Problem bei der Überarbeitung von Software ist, dass die Überarbeitung von vorhandenem Code langsamer oder weniger produktiv ist als die ursprüngliche Entwicklung des Codes. Mit anderen Worten: Das erste Schreiben von Code ist schneller, als ihn zu schreiben und später zu ändern.
Durch die Verwendung eines Standardansatzes zur Softwaremessung und Produktivität können wir die Produktivität von Softwareteams beim ersten Build und bei der Nacharbeit verfolgen. Typische Build-Raten von Entwicklern 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 Nacharbeiten erforderlich sind, entsteht Ihnen der Aufwand, die Arbeit zunächst durchzuführen (1 Tag für 1 CFP) und sie anschließend (weitere 1,5 Tage pro CFP) zu ändern. Somit betragen die Gesamtkosten 2,5 Arbeitstage anstatt 1.
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:
- Klar
- Prägnant
- Benutzerorientiert
- Testbar
- Messbar
- Konsistent
- Vollständig
- Einzigartig
- Wertvoll
- 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.
Zusammenfassung und Schlussfolgerung
Überarbeitungen machen bis zu die Hälfte aller Arbeiten an Softwareprojekten aus. Dies hat sich im Laufe der Jahre nicht wesentlich verringert. Die Hauptursache für die meisten Nacharbeiten ist eine schlechte Kommunikation, die durch unzureichende Disziplin und Sorgfalt bei der Umsetzung der Anforderungen verursacht wird. Es gibt viele Gründe, warum Teams sich nicht mehr darum bemühen, die Anforderungen zu verbessern. Der größte Teil dieser Nacharbeit ist vermeidbar, insbesondere jetzt mithilfe von Tools wie ScopeMaster, mit denen Sie Probleme mit Anforderungen schneller, früher und gründlicher als manuelle Maßnahmen finden und beheben können.
Geschrieben von Colin Hammond, 35 Jahre IT-Erfahrung und Gründer von ScopeMaster.