Verschwendung von Softwareprojekten und wie man sie reduziert

Die Verschwendung von Softwareprojekten verursacht Kosten $1bn pro Tag in Unternehmen und Regierungen auf der ganzen Welt, die völlig unnötige Arbeit leisten.

Jeden Tag verschwenden Softwareteams auf der ganzen Welt 30-60% ihrer Zeit (und der Zeit und des Geldes des Arbeitgebers) aufgrund ineffizienter Praktiken. Der Großteil dieser Abfälle ist vermeidbar. Zu jedem Zeitpunkt kann jedes Mitglied des Teams nützliche Arbeit leisten, aber Die Arbeit, die sie leisten, hätte vermieden werden können. In den meisten Fällen ist den Managern nicht bewusst, dass dies geschieht.

Dieser Artikel wirft einen Blick auf einige der Hauptursachen für Verschwendung bei der Softwarearbeit. Schauen wir uns zunächst die Aktivitäten von Softwareteams an, die verschwenderisch sind. Jeder, der an einem Softwareprojekt gearbeitet hat, wird mehrere davon erlebt haben.

Aufwand und Zeit werden von Softwareteams oft verschwendet:

1. Überarbeitung schlecht gestalteter Funktionen aus früheren Sprints,
2. Verstehen und Überarbeiten von schlecht strukturiertem Code anderer Entwickler in früheren Sprints,
3. Beseitigung von Missverständnissen, weil der Autor der Anforderung nicht dafür gesorgt hat, dass die Anforderungen so klar waren, dass alle Leser (Benutzer, Architekten, Entwickler, Tester) zu einem gemeinsamen Verständnis gelangen würden,
4. Nacharbeiten durchführen, weil der Autor der Anforderung falsch verstanden hat, was tatsächlich benötigt wurde,
5. Schreiben manueller oder automatisierter Tests anhand von Anforderungen, die sich später als falsch herausstellen,
6. Ändern oder Entfernen von fehlerhaftem Code, weil die Anforderungen unzureichend waren,
7. Nacharbeit oder Mehrarbeit, weil eine schlechte Datenstruktur gewählt wurde, vielleicht weil die Anforderungen inkonsistent waren,
8. Umsetzung von Anforderungen mit niedriger Priorität, da ein vollständigeres Bild des vollständigen Anforderungssatzes nicht berücksichtigt wurde oder nicht verfügbar war.
9. Überarbeitung des Codes aufgrund inkonsistenter und unstrukturierter Sprachverwendung in Anforderungen,
10. Beheben und erneutes Testen von Fehlern, die vermeidbar wären, wenn die Anforderungen und Designs klarer gewesen wären,
11. Verfassen unangemessener detaillierter Akzeptanzkriterien für Anforderungen, denen eine grundlegende Beschreibung fehlt,
12. Aufgabenwechsel aufgrund von Nacharbeiten aufgrund schlechter Anforderungen oder Designs. (das Gegenteil von „Mach es gut und mach es einmal“)
13. Teilnahme an (Story-Point-)Schätzungsgesprächen, bei denen es hauptsächlich darum geht, die Bedeutung der Anforderungen herauszufinden, da die Anforderungen unklar sind,
14. Arbeiten an Projekten, die später abgebrochen werden, weil das Projekt das Budget und den Zeitplan überschritten hat, weil die Kenntnisse über den Gesamtumfang zu Beginn unzureichend oder unvollständig waren

Es wird viel über Lean-Praktiken von Softwareteams gesprochen, bei denen es vor allem um die Vermeidung von Verschwendung geht. Dennoch findet man nur selten Teams, die die tatsächliche Quelle und das Ausmaß der Verschwendung sorgfältig untersuchen, ihre Auswirkungen auf den Fortschritt ermitteln und entscheiden, wie sie in Zukunft vermieden werden könnten. Die meisten Teams unternehmen einige oder viele der oben genannten verschwenderischen Aktivitäten. Die kumulierte Auswirkung beträgt durchschnittlich etwa 40–501 TP3T der gesamten von Softwareteams geleisteten Arbeit. Und das meiste davon ist vermeidbar.

Verschwendeter Aufwand in der Wissensarbeit

Verschwendeter Wissensaufwand kommt häufig vor und ist erheblich. Beispielsweise ist die Änderung von Code, der bereits stabil ist, sehr kostspielig, da dieser und alle ihn umgebenden Funktionen noch einmal überdacht und getestet werden müssen. Der erneute Test ist erforderlich, um sicherzustellen, dass die Änderung keine nachteiligen Auswirkungen hat. Eine einzeilige Codeänderung kann das erneute Testen von Tausenden Zeilen zugehörigen Codes erfordern. Testgetriebene Entwicklung (TDD) ist eine Technik, die hilft, dieses Problem zu lindern, aber sie verhindert das Problem nicht und erkennt auch nicht alle möglichen Fehler.

Bei Projekten mit größeren Teams ist die Arbeit einer Person von der vorherigen Arbeit einer anderen Person abhängig. Bevor ein Entwickler eine Änderung an einem Code vornimmt, muss er verstehen, was sein/ihr Vorgänger geschrieben hat, dann herausfinden, wo er sonst noch verwendet wurde, und dann kann er schließlich damit beginnen, die gewünschten Änderungen vorzunehmen. Gleiches gilt für Anforderungen, Konstruktionen und Tests. Der vor der Änderung Lernen kann Stunden oder sogar Tage dauern.  Eine scheinbar geringfügige Änderung kann unverhältnismäßig teuer werden.  

Das Springen von einem Codeteil zum nächsten erfordert einen Kontextwechsel. Damit Wissen gut funktioniert, müssen wir uns konzentrieren und Kontextwechsel vermeiden. Das Beheben von Fehlern erfordert mehr Kontextwechsel als das Schreiben des Codes. Der Kontextwechsel ist völlig verschwenderisch. Die Kombination aus Umlernen und Kontextwechsel erklärt in gewisser Weise, wie eine kleine Codeänderung außerordentlich teuer sein kann. Idealerweise möchten wir eine Methode nach dem Sprint, in dem sie erstellt wurde, so selten wie möglich ändern. 

Messen Teams echten Abfall?

Im Allgemeinen nein, das tun sie nicht. Das ist richtig, $1Bn pro Tag werden von Unternehmen und Regierungen auf der ganzen Welt verschwendet und nur sehr wenige messen dies. Diese Verschwendung lässt sich nicht auf magische Weise reduzieren oder verschwinden, es ist proaktives Handeln erforderlich.

Eine Ursachenanalyse kann hilfreich sein, um herauszufinden, wo, warum und wie viel Abfall anfällt. Bevor wir über eine anstehende Softwarearbeit nachdenken, die eine Änderung oder Korrektur des vorhandenen Codes erfordert, sollten wir uns einige wichtige Fragen stellen. Hier ist eine nicht erschöpfende Liste:

• Hätte diese Anforderung oder Änderung vorhergesehen oder vernünftigerweise vorhergesehen werden können?
• Wie hätten wir das früher wissen können, sodass wir es hätten vermeiden können, vorhandenen Code ändern zu müssen? Hätte diese Änderung ganz vermieden werden können?
• Wie viel zusätzlicher Aufwand und längere Dauer entsteht, wenn diese Änderung jetzt vorgenommen wird, im Vergleich dazu, wenn wir sie beim ersten Schreiben des Codes berücksichtigt hätten?
• Wie viel zusätzlicher Zeit- und Arbeitsaufwand wird aufgrund dieser Änderung für Regressionstests aufgewendet?
• Welche Folgewirkung hat es, wenn wir diese Änderung jetzt vornehmen, im Vergleich dazu, wenn wir sie früher vorgenommen hätten?
• Führt diese Änderung zu neuen Leistungs- oder Sicherheitsrisiken für zuvor bereitgestellten Code (führt sie zu einem Bad-Fix)?
• Wird diese Änderung in eindeutigen Worten ausgedrückt, so dass jeder Leser sie verstehen kann?

Die häufigste Grundursache

Die Hauptursache für den Großteil dieser Verschwendung ist schlechte Arbeit in den frühen Phasen des Software-Lebenszyklus. Schlechte Anforderungsarbeit, übereilte Architekturentscheidungen, schlampige Lösungsoptionen oder Entwurfsarbeit.

Die meisten Softwareteams berücksichtigen selten die tatsächlichen Auswirkungen von Anforderungsmängeln auf ihre Produktivität und die dadurch verursachte Verschwendung. Darüber hinaus übersehen sie möglicherweise die Kosten schlechter Designentscheidungen erst lange nach der Implementierung des Designs. Dies wird als get bezeichnet Technische Schulden.

Unklare Anforderungen, die mit einem schlechten und unflexiblen Design umgesetzt werden, können zu außerordentlichen Nacharbeitskosten führen. Diese Nacharbeitskosten können dann sogar noch höher ausfallen, wenn dadurch andere damit verbundene und nicht damit verbundene Arbeiten verzögert werden. In einigen Fällen, und bei größeren Projekten recht häufig, können schlechte Anforderungen und schlechte frühe Entwurfsentscheidungen dazu führen, dass ein ganzes Projekt verworfen wird.

Spät entdeckte Anforderungsmängel sind in der Regel die kostspieligste Art von Fehlern, die es zu beheben gilt.

Weltweit werden jährlich etwa $720Milliarden für die Arbeit an Unternehmenssoftware ausgegeben. Etwa die Hälfte davon sind Nacharbeiten, die vermeidbar sind und durch schlechte Anforderungen, schlechte Designentscheidungen und die Folgen beider verursacht werden. Weltweit sind das etwa 1 TP4T360 Mrd. pro Jahr oder etwa 1 TP4T1 Mrd. pro Tag.

Was ist mit Agile?

Agile beseitigt nicht die Verschwendung, die wir hier beschrieben haben. Der Hauptvorteil agiler Softwareentwicklungsmethoden ist eine schnelle Feedbackschleife zwischen Benutzern und Entwicklern. Wir sehen, dass die Einführung von Agile in vielen Fällen einen Rückgang der Qualität und Sorgfalt der Anforderungen und anderer Vorcodierungsarbeiten mit sich bringt. Unternehmen haben es eilig, neue softwarebasierte Funktionen bereitzustellen. Diejenigen, die an der Arbeit beteiligt sind, präsentieren einen „Adapt as we go“-Ansatz, der attraktiv erscheint. Wenn sie gut umgesetzt werden, tragen agile Praktiken zwar dazu bei, dass der Kunde das bekommt, was er möchte, aber wenn sie mit einer schlampigen Arbeit bei der Vorcodierung einhergehen, führt dies zu einem erheblichen Maß an Nacharbeit während des Projekts und einer erhöhten Verschwendung von Aufwand.

Daten aus Tausenden von Projekten zeigen, dass vor dem Codieren etwa genauso viele Fehler auftreten wie während des Codierens.[ich] Dies wird als Defektpotential bezeichnet. 16% – 35% aller Produktionsmängel werden durch mangelhafte oder unvollständige Anforderungen verursacht.[ii]

Nur wenige Softwareteams berücksichtigen sorgfältig, dass Anforderungen und Designfehler die Hauptursache für so viel verschwendeten Aufwand sind. Sie können sich erst weiterentwickeln, wenn Sie eine Vorstellung von den Anforderungen haben. Mit anderen Worten: Die Entwicklung folgt den Anforderungen. Eine schlecht recherchierte oder schlecht formulierte Anforderung kann dazu führen, dass ein ganzes Team tage- oder wochenlang verschwendete Arbeit leistet. Oftmals wird diese Art von Verschwendung als „Lernen“ oder „sich entwickelnde Benutzeranforderungen“ abgeschrieben, obwohl dies in Wirklichkeit weder das eine noch das andere ist, sondern eine Arbeit, die nicht den Standards entspricht. Es kann mehrere Gründe dafür geben, dass die Anforderungen schlecht funktionieren. Ein Grund dafür ist, dass viele Organisationen nicht sicherstellen, dass die Mitarbeiter, die die Anforderungen schreiben, ausreichend geschult und erfahren sind, um qualitativ hochwertige Anforderungsarbeit zu leisten. Ein weiterer Grund besteht darin, dass es in der Branche wenig Einigkeit und Konsens darüber gibt, was eine gute Anforderung ausmacht.

Andere häufige Ursachen für die Verschwendung von Softwareprojekten

Wir haben schlechte Vorarbeit und Kontextwechsel als Hauptursachen für Verschwendung genannt, einige weitere häufige Ursachen sind:

• Verschwendung durch schlechte Führung,
• Verschwendung durch niedrige Qualifikationsniveaus, was zu mehr Nacharbeit und Fehlern führt
• Abfall aus folgenden Prozessen, die scheinbar einen Mehrwert bieten, dies aber nicht tun,
• keine guten Prozesse befolgen, die zwar einen Mehrwert schaffen, aber vielleicht unmodern sind,
• Verschwendung von Kommunikationsaufwand aufgrund übermäßiger Teamgröße,

Softwareanforderungen sind oft von schlechter Qualität

Softwareanforderungen und User Stories sind oft von schlechter Qualität. Möglicherweise ist der Autor nicht ausreichend kompetent oder erfahren. Möglicherweise haben sie keinen Zugriff auf die Informationen, die sie benötigen. Das Problem bei fast allen Anforderungen besteht darin, dass sie in uneingeschränkter natürlicher Sprache verfasst sind. Den Autoren mangelt es in der Regel an einer formalen Schulung zu den Qualitätsanforderungen beim Schreiben. Uneingeschränkte natürliche Sprache ist nicht das ideale Mittel zur Kommunikation von Softwareanforderungen, wird aber von uns am häufigsten verwendet. Die meisten Organisationen verwalten die Anforderungsqualität nicht.

Bei Scopemaster haben wir über 300.000 Anforderungen aus Hunderten von Softwareprojekten in verschiedenen Ländern und Branchen analysiert. Was wir herausgefunden haben, ist Folgendes:

• Im Durchschnitt besteht eine Anforderung (oder User Story) aus 12 Wörtern (ohne Akzeptanzkriterien). Und im Durchschnitt entspricht jedes Wort 125 Codierungswörtern oder zu schreibenden Token. Somit können wir sagen, dass ein Fehler in einem einzelnen Wort einer Anforderung dazu führen kann, dass 125 Codierungswörter neu geschrieben werden müssen. Diese Zahlen sollten nicht als Grundlage für Schätzungen verwendet werden, sondern zeigen an, wie wichtig jedes Wort einer Anforderung ist.
• Im Durchschnitt sehen wir bei jeder Anforderung 4–8 Probleme. Diese Probleme sind unterschiedlich schwerwiegend, aber wenn sie nicht frühzeitig behoben werden, kann oder wird jedes einzelne davon einen Softwarefehler verursachen.

Zu den häufigsten Anforderungsmängeln gehören:

• Nicht benutzerorientiert
• Inkonsistent
• Unklar
• Nicht testbar
• Unermesslich
• Übermäßiger technischer Inhalt
• Dupliziert
• Fehlen
• Nicht wertvoll
• Zu ausführlich

Die meisten Leser werden eine schriftliche Anforderung anders interpretieren. Wenn der Interpretationsunterschied nicht trivial ist, führt er wahrscheinlich zu einem Softwarefehler. Wenn dieser Fehler erst später entdeckt wird, kann es sein, dass viele Arbeiten durchgeführt wurden, die noch einmal durchgeführt werden müssen, um ihn zu beheben. Es ist wirklich wichtig, es gleich beim ersten Mal richtig zu machen oder Fehler frühzeitig zu erkennen.

Qualitätsmerkmale guter Softwareanforderungen

Es gibt unterschiedliche Quellen und Meinungen darüber, was eine gute Qualitätsanforderung ausmacht. Es gibt großartige Arbeit von der IEEE und sie greifen dieses Thema regelmäßig auf. Es gibt eine allgemein akzeptierte, wenn auch unserer Ansicht nach mangelhafte Liste von Attributen, die häufig von verschiedenen agilen Trainern gefördert werden und in der INVEST-Pneumonie zusammengefasst sind.

Hier ist unsere Liste der Anforderungsqualitätsmerkmale.

Die Überprüfung jeder Anforderung, die alle oben genannten Punkte erfüllt, ist ziemlich mühsam, aber notwendig, wenn Sie Verschwendung minimieren möchten. Glücklicherweise können Tools wie ScopeMaster jetzt den Löwenanteil dieser Anforderungsqualitätssicherung für Sie übernehmen.

Andere Formen der Verschwendung von Softwareprojekten

Vielen Dank an Todd Sedano für sein sehr hilfreiches Bild oben in diesem Artikel, das die häufigsten Formen der Verschwendung von Softwareprojekten zeigt. Wir haben die ersten drei nun ausführlicher behandelt, da sie die Hauptursachen für Projektverschwendung sind. Schauen wir uns die anderen an:

Unnötig komplexe Lösungen

Technische Schulden, komplexe Integrationen, Sprachmischungen, komplexe Geschäftsregeln und schlechte Softwarearchitekturen führen alle zu übermäßig komplexen Lösungen, die zu Zeitverschwendung bei der Nacharbeit, der Entdeckung der Funktionsweise von Systemen und der Sicherstellung führen, dass die Einführung von Änderungen keine unerwünschten Ergebnisse hervorruft. Das heißt, gute Architektur führt zu effizienter Flexibilität.

Fremde kognitive Belastung

Softwareprojektverschwendung wird manchmal dadurch verursacht, dass Entwickler und Designer zusätzliche Ablenkungen und Einschränkungen erhalten. Erfolgreiche Projekte schützen Entwickler, Tester und Designer vor allem, worüber sie sich keine Sorgen machen müssen.

Psychische Belastung

Diese Verschwendungsursache ist in der Regel seltener oder wird durch äußeren Druck oder in einigen seltenen Fällen durch sehr schlechtes Management verursacht.

Wissensverlust

In großen oder komplexen Systemumgebungen trägt die Kontinuität des Personals dazu bei, Wissen zu behalten. Wenn Experten ausscheiden, kann es Wochen oder Monate dauern, bis man gelernt hat, mit dem Niveau der ausscheidenden Mitarbeiter Schritt zu halten.

Multitasking/Warten

Softwareprojekte verschwenden Zeit und Mühe mit dem Wechseln von Aufgaben (ein Ergebnis von Multitasking). Es kann oft 20 bis 50 Minuten dauern, bis ein Entwickler wieder da ist, wo er war, bevor eine Ablenkung seinen Gedankengang unterbricht.

Ineffektive Kommunikation

Wir haben dies weitgehend mit mangelhaften Anforderungen abgedeckt. Aber manchmal wird auch andere Projektkommunikation schlecht gehandhabt, beispielsweise wenn Führungskräfte keine klaren Anweisungen geben, was für das Unternehmen wichtig ist.

Verschwendung vermeiden

Um diese Verschwendung zu vermeiden, müssen wir lediglich die Anforderungen und das Design verbessern. Ist das so einfach? Ja.

Wenn Sie bessere Anforderungen schreiben, die allen Lesern klar und konsistent kommunizieren, und dann ausreichend Zeit darauf verwenden, sicherzustellen, dass Designoptionen sorgfältig geprüft, Designs überprüft und optimiert werden, bevor sie programmiert werden, werden gute Dinge passieren und die Verschwendung wird minimal sein.

Selten wird ausreichend Wert auf die Qualität der Anforderungen gelegt. Darüber hinaus untergraben viele agile Ansätze, Frameworks und Trends bewährte, effiziente Methoden zur Bereitstellung hochwertiger Software auf Anhieb. Anforderungen an Qualität und Designqualität dürfen gemessen, verfolgt und verbessert werden, was jedoch selten der Fall ist.

Teams benötigen Hilfe, um dieses Problem zu lösen

Gute Anforderungen zu formulieren ist nicht einfach, es erfordert Schulung und Erfahrung. Viele Teams haben einen Product Owner, der entweder ein Fachexperte oder ein erfahrener BA ist. Er kennt sich vielleicht mit dem Geschäft aus, weiß aber nicht, wie man gute Qualitätsanforderungen formuliert. Hier sind einige Gründe, warum dieses Problem weitgehend ungelöst bleibt:

1. Es gibt wenig Lohn dafür, die Qualität der Anforderungen in Frage zu stellen

2. Wenn die Anforderung schlecht ist und Sie es zweimal bauen müssen, werden Sie mehr bezahlt

3. Anforderungsautoren verfügen selten über genaue Kenntnisse der Benutzeranforderungen, bestehender Systeme und darüber, wie man gute Anforderungen schreibt.

4. Anforderungsautoren sind oft die Entwickler, die Entwicklungsaufgaben mit viel Fachjargon aufschreiben, also keine leicht verständlichen Benutzeranforderungen, die für alle verständlich sind.

5. Teams beschränken die Formulierung der Anforderungen selten auf das, was zu einem durchgängig klaren gemeinsamen Verständnis führt.

6. Das Team setzt auf Diskussionen als Mittel zur Klärung von Missverständnissen. Die Gespräche bleiben oft undokumentiert.

7. Die Meinungen darüber, was eine gute Qualität der Anforderungen ausmacht, gehen weit auseinander.

2022 und Automatisierung/KI kommt zur Rettung

Es entstehen Tools, die bei der Qualitätssicherung (QS) von Anforderungen helfen können. Anbieter von Anforderungsmanagement-Tools arbeiten an neuen Funktionen, um einige Aspekte der Anforderungs-QS zu unterstützen. Beispiele hierfür sind IBM Doors, Jama Connect, Visuresolutions und ScopeMaster. Unser eigenes Werkzeug ScopeMaster ist das fortschrittlichste verfügbare Tool, das die in diesem Dokument beschriebenen Probleme behebt. Es automatisiert die Anforderungs-QA früh im Software-Lebenszyklus. Es ist wie ein statischer Anforderungsanalysator; Es tut was für Anforderungen SonarQube funktioniert für Code.

ScopeMaster und einige andere Tools nutzen Natural Language Processing und andere Analysetechniken, um Anforderungen zu interpretieren und zu testen. ScopeMaster unterstützt den Anforderungsautor bei der Verbesserung der Qualität der Anforderungen mit einer Geschwindigkeit und Gründlichkeit, die bisher nicht möglich war. (ScopeMaster führt durchschnittlich 100.000 Tests für einen Satz von 100 User Stories in 4 Minuten durch.) ScopeMaster findet typischerweise 2–4 Fehler pro Anforderung in nur wenigen Sekunden.

ScopeMaster findet etwa die Hälfte aller latenten Mängel in einem Anforderungssatz. Die Fehlerarten decken 9 der 10 oben aufgeführten Qualitätsmerkmale ab. Dies kann Teams dabei helfen, die Qualität einer Reihe von Anforderungen sehr schnell auf einen viel höheren Standard zu heben und so dazu beizutragen, dieses Problem von $360Bn pro Jahr zu lindern.

Abschluss

Wenn Sie an Softwareprojekten in einem Unternehmens- oder Regierungssektor beteiligt sind, verschwenden Sie möglicherweise bis zu 501 TP3T Ihres Budgets für vermeidbare Arbeit. Die Hauptursache für einen Großteil dieser Verschwendung sind unzureichende Anforderungen und Systemdesignarbeiten. Zu erkennen, dass ein Problem vorliegt und dass dies wahrscheinlich die Grundursache ist, ist der erste Schritt zur Lösung des Problems. Der nächste Schritt besteht darin, eine Qualitätsverbesserungsinitiative einzuführen, die den Beginn des Entwicklungslebenszyklus anspricht: Ziele, Anforderungen, Architektur und Design. Beginnen Sie mit der Messung von Anforderungsfehlern und deren Auswirkungen auf Ihren Fortschritt. Erkennen Sie Fehlerpotenziale und leiten Sie Initiativen ein, um diese Fehler so früh wie möglich zu finden und zu beheben. Tools wie ScopeMaster verändern die Softwaresicherheit grundlegend.

Geschrieben von Colin Hammond, 37-jähriger IT-Veteran und Gründer von ScopeMaster.

[ich] Fehlerquellen Fehler pro Funktionspunkt Anforderungsfehler 0,75 Architekturfehler 0,15 Designfehler 1,00 Codefehler 1,25 Dokumentfehler 0,20 Fehler durch schlechte Behebung 0,15 Gesamtfehlerpotenzial 3,65

https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf

[ii] Capers Jones und Accenture, Januar 2021

Economics of Software Quality, von C Jones und Olivier Bonsignour.