Die relative Kosteneffizienz einer (Akzeptanz-) testgetriebenen Entwicklung

Ich möchte wissen, wie sich die Ressourcenplanung insgesamt auf ein Softwareprojekt auswirkt, bei dem die Anforderungen und das Design des Projekts durch automatisierte Abnahmetests und Komponententests im Gegensatz zu einem eher "traditionellen" Ansatz bei der Softwareentwicklung bestimmt werden.

Wie wirkt sich Ihrer Erfahrung nach die Gesamtwirkung auf den Ressourcenbedarf für die Fertigstellung eines Softwareprojekts im Rahmen von TDD im Gegensatz zu "traditionelleren" Entwicklungsmethoden aus? Für mich ist es selbstverständlich, dass die Qualität zunimmt und die Unsicherheit abnimmt, da die Tests früher durchgeführt werden. Es scheint jedoch, als würde die Durchführung von Tests im Vorfeld mehr Entwicklerstunden erfordern. Wie stark steigt der Entwicklungsaufwand oder sinkt er tatsächlich aufgrund der Beseitigung von Fehlern im Vorfeld?

Wie viel mehr Aufwand verlangt der Kunde? Müssen sie ihre Beziehung zum Projekt ändern, insbesondere wenn sie es gewohnt sind, im Vorfeld große Designs zu entwerfen? Erhöht sich der Arbeitsaufwand des Kunden insgesamt oder verringert er sich tatsächlich?

Ich würde mir vorstellen, dass Zeitschätzungen in einem iterativen TDD-Prozess zu Beginn eines TDD-Projekts sehr vage sind (da es keinen Softwareentwicklungsplan gibt). Gibt es einen Punkt, sagen wir 20% in einem Projekt, an dem das Vertrauen genug steigt, dass dem Kunden schließlich eine mehr oder weniger stabile Zeit- und Geldschätzung zur Verfügung gestellt werden kann?

Hinweis: Ich suche hier nicht nach subjektiven Meinungen oder Theorien, bitte spekulieren Sie nicht. Ich suche mehr nach realer Erfahrung in TDD.

Zunächst ist festzustellen, dass TDD die Qualität der Software (aus Sicht des Benutzers) nicht unbedingt erhöht. Es ist keine Silberkugel. Es ist kein Allheilmittel. Das Verringern der Anzahl von Fehlern ist nicht der Grund, warum wir TDD machen.

TDD wird hauptsächlich durchgeführt, weil es zu besserem Code führt. Insbesondere führt TDD zu Code, der einfacher zu ändern ist .

Ob Sie TDD verwenden möchten oder nicht, hängt mehr von Ihren Projektzielen ab. Wird dies ein kurzfristiges Beratungsprojekt sein? Müssen Sie das Projekt nach dem Go-Live unterstützen? Ist es ein triviales Projekt? In diesen Fällen lohnt sich der zusätzliche Aufwand möglicherweise nicht.

Ich habe jedoch die Erfahrung gemacht, dass das Wertversprechen für TDD exponentiell zunimmt, wenn der Zeit- und Ressourcenaufwand für ein Projekt linear zunimmt.

Gute Unit-Tests bieten folgende Vorteile:

1. Unit-Tests warnen Entwickler vor unbeabsichtigten Nebenwirkungen.
2. Unit-Tests ermöglichen die schnelle Entwicklung neuer Funktionen auf alten, ausgereiften Systemen.
3. Unit-Tests ermöglichen neuen Entwicklern ein schnelleres und genaueres Verständnis des Codes.

Ein Nebeneffekt von TDD sind möglicherweise weniger Fehler, aber nach meiner Erfahrung werden die meisten Fehler (insbesondere die schlimmsten) in der Regel durch unklare oder schlechte Anforderungen verursacht oder würden nicht unbedingt in der ersten Runde der Komponententests behandelt.

Zusammenfassen:

Die Entwicklung in Version 1 ist möglicherweise langsamer. Die Entwicklung auf Version 2-10 wird schneller sein.

Es gibt ein Kapitel in Making Software über testgetriebene Entwicklung, in dem das hier diskutierte Papier zitiert wird .

Fallstudien wurden mit drei Entwicklerteams bei Microsoft und einem bei IBM durchgeführt, die TDD übernommen haben. Die Ergebnisse der Fallstudien zeigen, dass die Fehlerdichte vor der Freigabe der vier Produkte im Vergleich zu ähnlichen Projekten, bei denen die TDD-Praxis nicht angewendet wurde, zwischen 40% und 90% abnahm. Subjektiv konnten die Teams nach der Einführung von TDD eine Verlängerung der anfänglichen Entwicklungszeit um 15–35% verzeichnen.

Ob diese Ergebnisse für Ihren Fall verallgemeinerbar sind, ist natürlich etwas, das Befürworter von TDD argumentieren, und Kritiker von TDD argumentieren, ist unwahr.

Ich habe keine Forschungsarbeiten oder Statistiken, aber ich werde meine Erfahrungen aus der Arbeit in einem Team / einer Organisation, die in der Vergangenheit nur eine geringe bis durchschnittliche Abdeckung durch Unit-Tests und keine End-to-End-Tests aufwiesen, schrittweise wiedergeben Bewegen Sie die Messlatte dorthin, wo wir jetzt sind, mit mehr ATDD-Ansatz (aber ironischerweise nicht mit herkömmlichem TDD).

Dies ist insbesondere die Art und Weise, in der Projektzeitpläne abgespielt wurden (und weiterhin für andere Teams / Produkte in derselben Organisation abgespielt werden):

• Bis zu 4 Wochen Analyse und Implementierung
• 2 Wochen Regressionstest, Fehlerbehebung, Stabilisierung und Release-Vorbereitung
• 1-2 Wochen nach der Behebung bekannter Mängel
• 2-3 Wochen Code-Bereinigung und Probleme / Support nach der Produktion (unbekannte Fehler / ungeplante Ausfälle)

Dies scheint ein lächerlicher Aufwand zu sein, ist jedoch tatsächlich sehr verbreitet. In vielen Organisationen wird dies nur häufig durch fehlende oder ineffektive Qualitätssicherung maskiert. Wir haben gute Tester und eine Kultur intensiver Tests, so dass diese Probleme frühzeitig erkannt und (meistens) im Voraus behoben werden, anstatt sich über einen Zeitraum von vielen Monaten / Jahren langsam zu entwickeln. 55-65% Wartungsaufwand ist geringer als die allgemein akzeptierte Norm von 80% der Zeit auf dem Debuggen ausgegeben werden - was sinnvoll erscheint, weil wir hatten einige Unit - Tests und funktionsübergreifende Teams (einschließlich QA).

Während der ersten Veröffentlichung unseres neuesten Produkts durch unser Team hatten wir begonnen, Abnahmetests nachzurüsten, aber sie waren nicht ganz auf dem neuesten Stand und wir mussten uns immer noch auf viele manuelle Tests verlassen. Die Veröffentlichung war etwas weniger schmerzhaft als andere, IMO teilweise aufgrund unserer willkürlichen Akzeptanztests und auch teilweise aufgrund unserer sehr hohen Abdeckung durch Komponententests im Vergleich zu anderen Projekten. Dennoch haben wir fast zwei Wochen für die Regression / Stabilisierung und zwei Wochen für die Nachbearbeitung aufgewendet.

Im Gegensatz dazu hatte jede Veröffentlichung seit dieser ersten Veröffentlichung frühe Akzeptanzkriterien und Akzeptanztests, und unsere aktuellen Iterationen sehen folgendermaßen aus:

• 8 Tage Analyse und Implementierung
• 2 Tage Stabilisierung
• 0-2 Tage kombinierter Support und Bereinigung nach der Produktion

Mit anderen Worten, wir sind von 55-65% des Wartungsaufwands auf 20-30% des Wartungsaufwands gestiegen. Gleiches Team, gleiches Produkt, der Hauptunterschied ist die fortschreitende Verbesserung und Straffung unserer Abnahmetests.

Die Kosten für die Wartung betragen pro Sprint 3-5 Tage für einen QA-Analysten und 1-2 Tage für einen Entwickler. Unser Team besteht aus 4 Entwicklern und 2 QA-Analysten. (Ohne UX, Projektmanagement usw.) Das sind maximal 7 von 60 Manntagen. Dies wird auf einen Implementierungsaufwand von 15% aufgerundet die sichere Seite.

Wir verbringen 15% jeder Veröffentlichungsperiode damit, automatisierte Abnahmetests zu entwickeln. Dabei können wir 70% jeder Veröffentlichung reduzieren, indem wir Regressionstests durchführen und Fehler vor und nach der Produktion beheben.

Sie haben vielleicht bemerkt, dass die zweite Zeitachse viel genauer und auch viel kürzer ist als die erste. Dies wurde durch die Akzeptanzkriterien und Akzeptanztests im Vorfeld ermöglicht, da dies die "Definition von erledigt" erheblich vereinfacht und es uns ermöglicht, viel sicherer auf die Stabilität einer Veröffentlichung zu vertrauen. Kein anderes Team hat (bis jetzt) ​​einen zweiwöchentlichen Release-Zeitplan erhalten, außer vielleicht bei relativ einfachen Wartungs-Releases (nur Bugfixes usw.).

Ein weiterer interessanter Nebeneffekt ist, dass wir unseren Release-Zeitplan an die Geschäftsanforderungen anpassen konnten. Einmal mussten wir es auf ungefähr 3 Wochen verlängern, um es mit einem anderen Release zu vereinbaren, und konnten dies tun, während wir mehr Funktionalität lieferten, ohne zusätzliche Zeit für Tests oder Stabilisierung aufzuwenden. Ein anderes Mal mussten wir es aufgrund von Feiertagen und Ressourcenkonflikten auf ungefähr 1½ Wochen verkürzen. wir mussten weniger entwicklungsarbeit leisten, konnten aber erwartungsgemäß entsprechend weniger zeit für tests und stabilisierungen aufwenden, ohne neue mängel einzuführen.

Aus meiner Erfahrung heraus sind Abnahmetests, insbesondere wenn sie sehr früh in einem Projekt oder Sprint durchgeführt werden und die vom Product Owner festgelegten Abnahmekriterien eingehalten werden, eine der besten Investitionen, die Sie tätigen können. Im Gegensatz zu herkömmlichen TDD, die richtig andere Menschen konzentrierten mehr darauf hin , auf der Schaffung von prüfbaren Code als fehlerfreien Code - ATDD tut wirklich Hilfe Fang Mängel viel schneller; Es ist das organisatorische Äquivalent zu einer Armee von Testern, die jeden Tag einen vollständigen Regressionstest durchführt, aber viel billiger.

Hilft Ihnen ATDD bei längerfristigen Projekten im RUP- oder (ugh) Waterfall-Stil, die 3 Monate oder länger dauern? Ich denke, die Jury ist immer noch nicht damit einverstanden. Nach meiner Erfahrung sind die größten und hässlichsten Risiken bei langfristigen Projekten unrealistische Fristen und sich ändernde Anforderungen. Unrealistische Fristen führen dazu, dass Benutzer Verknüpfungen verwenden, einschließlich Testverknüpfungen, und signifikante Änderungen an den Anforderungen machen wahrscheinlich eine große Anzahl von Tests ungültig, sodass sie neu geschrieben werden müssen und möglicherweise den Implementierungsaufwand erhöhen.

Ich bin mir ziemlich sicher, dass ATDD eine fantastische Auszahlung für agile Modelle oder für Teams hat, die nicht offiziell agil sind, aber sehr häufige Veröffentlichungspläne haben. Ich habe es noch nie bei einem Langzeitprojekt ausprobiert, hauptsächlich, weil ich noch nie von einer Organisation gehört habe, die bereit ist, es bei einem solchen Projekt auszuprobieren. Fügen Sie daher hier den Standard-Haftungsausschluss ein. YMMV und das alles.

PS In unserem Fall ist kein zusätzlicher Aufwand für den "Kunden" erforderlich, aber wir haben einen engagierten, hauptberuflichen Product Owner, der die Akzeptanzkriterien tatsächlich schreibt. Wenn Sie im Bereich "Consultingware" tätig sind, könnte es meiner Meinung nach viel schwieriger sein, die Endbenutzer dazu zu bringen, nützliche Akzeptanzkriterien zu schreiben. Ein Product Owner / Product Manager scheint ein ziemlich wesentliches Element für ATDD zu sein, und obwohl ich wieder nur aus eigener Erfahrung sprechen kann, habe ich noch nie davon gehört, dass ATDD erfolgreich praktiziert wird, ohne dass jemand diese Rolle übernimmt.

Ressourcenanforderungen

Wie wirkt sich Ihrer Erfahrung nach die Gesamtwirkung auf den Ressourcenbedarf für die Fertigstellung eines Softwareprojekts im Rahmen von TDD im Gegensatz zu "traditionelleren" Entwicklungsmethoden aus?

Meiner Erfahrung nach werden die Kosten für Vorabprüfungen sofort gesenkt, indem zunächst klare Akzeptanzkriterien festgelegt und dann in den Test geschrieben werden. Ich habe festgestellt, dass nicht nur die Kosten für die Vorabprüfung gesenkt werden, sondern auch die Gesamtentwicklung insgesamt beschleunigt wird. Obwohl diese Geschwindigkeitsverbesserungen möglicherweise durch eine schlechte Projektdefinition oder sich ändernde Anforderungen zunichte gemacht werden. Wir sind jedoch immer noch in der Lage, ohne gravierende Auswirkungen auf diese Art von Änderungen zu reagieren. In den folgenden Fällen reduziert ATDD den Entwickleraufwand bei der Überprüfung des korrekten Systemverhaltens mithilfe der automatisierten Testsuite erheblich:

• große refactors
• Plattform- / Paket-Upgrades
• Plattformmigration
• Toolchain-Upgrades

Dies setzt ein Team voraus, das mit den Abläufen und Praktiken vertraut ist.

Einbeziehung der Kunden

Wie viel mehr Aufwand verlangt der Kunde?

Sie müssen ständig viel mehr einbezogen werden. Ich habe eine enorme Reduzierung der Anfangsinvestitionen gesehen, aber eine noch viel größere Nachfrage. Ich habe nicht gemessen, aber ich bin mir ziemlich sicher, dass dies eine größere Zeitinvestition für den Kunden darstellt.

Ich habe jedoch festgestellt, dass sich die Kundenbeziehung nach etwa fünf Demos, bei denen die Software langsam Gestalt annimmt, erheblich verbessert. Das zeitliche Engagement des Kunden nimmt mit der Zeit etwas ab, da ein Rapport entwickelt wird, an den sich jeder gewöhnt und an die damit verbundenen Erwartungen.

Projektschätzung

Ich würde mir vorstellen, dass Zeitschätzungen in einem iterativen TDD-Prozess zu Beginn eines TDD-Projekts sehr vage sind (da es keinen Softwareentwicklungsplan gibt).

Ich habe festgestellt, dass dies in der Regel eine Frage ist, wie gut die Frage definiert ist und ob der / die technische (n) Lead (s) in der Lage ist (einschließlich Kartenschätzung), das Projekt auszuwerten. Vorausgesetzt, das Projekt ist gut durchdacht und Sie haben einen angemessenen Geschwindigkeitsdurchschnitt und eine angemessene Standardabweichung. Wir haben festgestellt, dass es einfach ist, eine anständige Schätzung zu erhalten. Je größer das Projekt ist, desto größer ist natürlich die Unsicherheit, weshalb ich ein großes Projekt in der Regel in ein kleines Projekt aufspalte, mit dem Versprechen, es später fortzusetzen. Dies ist viel einfacher, wenn Sie eine Beziehung zum Kunden hergestellt haben.

Beispielsweise:

Die "Sprints" meines Teams dauern eine Woche und wir haben einen laufenden Durchschnitt und Standard. Abweichung der letzten 14 Wochen. Wenn das Projekt 120 Punkte hat, haben wir einen Mittelwert von 25 und einen Standardwert. Eine Abweichung von 6, die den Abschluss eines Projekts schätzt, ist:

Project Total / (Mean Velocity - (2 * Std. Deviation) = 95% Time Estimate
120           / (25            - (2 * 6             ) = 9.2 weeks

Wir verwenden die 2 Std. Faustregel für die Abweichung unserer 95% -Konfidenzschätzung. In der Praxis schließen wir das Projekt in der Regel unter dem ersten Standard ab. Abweichung, aber über unseren Durchschnitt. Dies ist normalerweise auf Verbesserungen, Änderungen usw. zurückzuführen.

Das Erfordernis von Tests im Vorfeld scheint mehr Entwicklerstunden zu erfordern. Wie stark steigt der Entwicklungsaufwand oder sinkt er tatsächlich aufgrund der Beseitigung von Fehlern im Vorfeld?

Das stimmt eigentlich nicht. Wenn Ihre Entwickler Komponententests schreiben (und das sollten sie), sollte die Zeit ungefähr gleich oder besser sein. Ich sagte es besser, da Ihr Code vollständig getestet wird und sie nur den Code schreiben müssen, um die Anforderungen zu erfüllen.

Das Problem bei Entwicklern ist, dass sie dazu neigen, auch Dinge zu implementieren, die nicht erforderlich sind, um die Software so allgemein wie möglich zu gestalten.

Wie viel mehr Aufwand verlangt der Kunde? Müssen sie ihre Beziehung zum Projekt ändern, insbesondere wenn sie es gewohnt sind, im Vorfeld große Designs zu entwerfen? Erhöht sich der Arbeitsaufwand des Kunden insgesamt oder verringert er sich tatsächlich?

Das sollte keine Rolle spielen. Wer die Anforderungen erfüllt, sollte es so gut wie möglich machen.

Wenn Sie eine agile Entwicklungsweise verfolgen, bedeutet dies nicht, dass Sie im Vorfeld viel Design haben. Je besser jedoch die Anforderungen, die Architektur und das Design sind, desto höher ist die Codequalität und desto kürzer ist die Zeit bis zur Fertigstellung der Software.

Deshalb, wenn sie BDUF machen möchten, lassen Sie sie es machen. Dies erleichtert Ihnen das Leben als Entwickler.