Ist es möglich, sich (oder Ihr Team) korrekt als "agil" zu bezeichnen, wenn Sie kein TDD (Test-Driven Development) durchführen?

Ja, ja, ja, millionenfach ja.

Agilität ist eine Philosophie, TDD eine spezifische Methodik.

Wenn ich wirklich wählerisch sein wollte, könnte ich einfach darauf hinweisen, dass es einige Variationen von xDD gibt - die ihre Befürworter im Detail nicht als TDD erklären werden -, aber diese sind immer noch im Wesentlichen mit dem Test zuerst verbunden, so dass betrogen werden würde.

Lassen Sie uns Folgendes sagen: Sie können agil sein, ohne die Entwicklung "zuerst testen" zu müssen (sehen Sie sich die Funktionsweise von Scrum an - nirgendwo gibt es Details zum Schreiben von Code). Schauen Sie sich ein Kanbantableau an, schauen Sie sich alle möglichen agilen Methoden an.

Möchten Sie Unit-Tests? Natürlich tust du das aus allen möglichen Gründen - und du kannst durchaus argumentieren, dass du ohne Unit-Tests nicht agil sein kannst (obwohl ich vermute, dass du es sein kannst) -, aber du musst sie nicht erst schreiben, um zu sein agil.

Und schließlich ist es genauso wahr, dass Sie Test First machen könnten , ohne agil zu sein, und starke Argumente dafür, Test First zu machen, unabhängig von Ihrer allgemeinen Entwicklungsphilosophie.

Es scheint, dass andere (mit einem festeren Repräsentanten) eine ähnliche Meinung haben ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Obwohl es nicht unmöglich ist, Agile ohne TDD und OOD auszuführen, ist es schwierig. Ohne TDD ist die Iterationsrate von ...

(Der Link im Tweet führt zur vollständigen Antwort auf LinkedIn.)

"Agil sein" bedeutet einfach, sich an die Werte und Prinzipien des agilen Manifests zu halten . Nichts in diesem Dokument erwähnt TDD oder sogar diesbezügliche Komponententests.

Ja, Sie können agil sein, ohne TDD oder Unit-Tests durchzuführen.

Ich würde es aber nicht empfehlen ...

Ja ,

Schauen Sie sich einen der agilen Werte an:

Individuen und Interaktionen über Prozesse und Werkzeuge

Das sollte es schon beantworten. TDD ist eine bestimmte Methodik, ein Prozess. In der Tat ein Prozess, der möglicherweise in agilen Entwicklungsprozessen eingesetzt werden könnte, aber nicht mehr. Ich denke, dass TDD jetzt vielleicht auf dem neuesten Stand der Technik ist, wenn man agil ist. Ich denke jedoch, dass das Konzept der Agilität auch dann Bestand haben wird, wenn TDD möglicherweise durch andere Praktiken ersetzt wurde.

Ich würde es wie folgt zusammenfassen:

• Heute ist TDD ein Defacto-Standard für Agilität

• Es kann Möglichkeiten geben, ohne TDD agil zu sein

ich sage

Nein [irgendwie]

Wenn Sie zur ursprünglichen Quelle zurückkehren: http://en.wikipedia.org/wiki/Extreme_Programming TDD ist für den Prozess von grundlegender Bedeutung. Die Tests ersetzen die Anforderungsspezifikationen und Anwendungsfälle von Wasserfällen, dienen als lebende Dokumentation und Funktionsbeispiele usw. Sie sind unverzichtbar.

Es gibt jedoch so viele verschiedene Geschmacksrichtungen von "agil", dass es durchaus möglich ist, dass eine von ihnen TDD meidet

EDIT: @ Murphs Interpretation der Frage scheint die bevorzugte zu sein. Ich habe es sogar positiv bewertet, es ist eine gute Antwort. Allerdings habe ich meine Position halten , dass das Agile Manifest eine Reihe von Grundsätzen, nicht eine Entwicklungsmethodik. Ich sehe keinen Sinn darin, "oh ja, ich bin agil" zu sagen, ohne tatsächlich die Praktiken zu implementieren, die die Vorteile bringen. Speziell:

Arbeitssoftware ist das primäre Maß für den Fortschritt.

und

Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.

Für mich implizieren diese beiden Prinzipien, dass TDD nicht erforderlich ist - zumindest kenne ich keinen anderen Weg, um sie ohne TDD zu erreichen!

EDIT 2: ja, technisch kann man die tests nachträglich schreiben; aber ich halte test-first / TDD immer noch für grundlegend. Nicht , weil man kann nicht „agil“ ohne sie, sondern weil Sie wird mehr agile mit ihm. Test-First / Test-Driven ist ein weitaus effizienterer Ansatz als Test-Later / Test-After-Thought. Die Testbeschreibungen sind die Anforderungen . Verschiebe sie erst später ;-)

EDIT 3: Ich habe endlich herausgefunden, was mich an Murphs sehr gut geschriebener Antwort so sehr stört. Es ist die Vorstellung, dass man "agil" sein könnte, ohne es tatsächlich zu tun . Und "es zu tun" (wie oben gezeigt) erfordert TDD.

Streng genommen sind Sie agil, wenn Sie sich an das agile Manifest halten . In der Praxis ist eine Codebasis nur dann agil, wenn sie eine gute Testabdeckung aufweist. Sie können TDD durchführen und die Tests vor / während der Entwicklung der Funktionalität schreiben oder Tests für die Funktionalität schreiben, nachdem diese entwickelt wurde. Normalerweise ist es jedoch einfacher und effektiver, es auf TDD-Weise zu tun.

Sie können agil sein, aber es gibt wahrscheinlich Raum für Verbesserungen.

Eines der Prinzipien in Agile ist, dass Sie in der Lage sein müssen, auf Veränderungen zu reagieren. Dies bedeutet, dass Sie nicht im Voraus wissen, was Sie bauen müssen. Wenn Sie einem Wasserfallprozess folgen würden, würden Sie x Monate im Voraus genau wissen, was Sie erstellen müssen, und Sie könnten einzelne Softwarekomponenten so entwerfen, dass sie jeweils an einem größeren Schema teilnehmen und das Endprodukt erreichen (zumindest würden Sie das glauben) es war so). Aber da Agile vorschreibt, dass Sie nicht wissen, was das Endprodukt ist, wissen Sie nie, wofür Ihr Code verwendet wird, und was noch wichtiger ist, wann er geändert wird.

Aus diesem Grund benötigen Sie eine gründliche Testsuite, um sicherzustellen, dass die bereits erstellten Funktionen weiterhin funktionieren, wenn die Codebasis geändert wird.

Aber das selbst ist kein TDD. Wenn Sie die Tests schreiben, nachdem Sie den Code geschrieben haben, handelt es sich nicht um TDD. TDD hilft jedoch bei einem anderen Aspekt: ​​Es verhindert Überproduktion.

In meinem eigenen agilen Team hatte ich Probleme damit, Code zu schreiben, von dem sie glauben, dass er später im Projekt nützlich sein wird. Wäre dies eine Wasserfallentwicklung gewesen, wäre dies wahrscheinlich in Ordnung, da sie für die nächsten x Monate Unterstützung für etwas im Projektplan hinzufügten.

Wenn Sie jedoch den agilen Grundsätzen folgen, sollten Sie diesen Code nicht schreiben, da Sie keine Ahnung haben, ob dies überhaupt erforderlich sein wird. Das für nächste Woche geplante Feature kann plötzlich auf unbestimmte Zeit verschoben werden.

Wenn Sie das TDD-Prinzip korrekt befolgen, kann es keine einzige Codezeile geben, bevor ein Test diese Codezeile diktiert (ich persönlich kann einen einfachen Code schreiben, ohne zu testen), und wenn Sie mit dem Schreiben des Abnahmetests beginnen, implementieren Sie nur genau das, was für die Bereitstellung der erforderlichen Funktionen erforderlich ist.

TDD hilft also, Überproduktion zu vermeiden und das Team so effektiv wie möglich zu machen. Dies ist auch ein zentrales agiles Prinzip.

Arbeitssoftware ist das primäre Maß für den Fortschritt

Können Sie agil sein, ohne TDD (testgetriebene Entwicklung) durchzuführen?

Kurze Antwort: Ja.

Längere Antwort: Es gibt bereits viele wirklich gute Antworten auf diese Frage und sehr gute Referenzen. Ich werde nicht versuchen, diese Punkte zu diskutieren.

Meiner Erfahrung nach geht es bei Agile darum, das richtige Maß an Lean-Ness für das jeweilige Projekt auszuwählen. Was meine ich mit Magerkeit? Und warum bringe ich es in diese Antwort ein?

Mager bedeutet nicht, alles Mögliche aus Ihrer Methode herauszuschneiden. Wie einer unserer Kollegen feststellte, müssen Sie TDD oder Unit Test nicht in Ihr Verhalten einbeziehen. Im Projektkontext kann dies jedoch von Vorteil sein oder auch nicht.

Denken wir an die Lieferkette eines großen, namenlosen Einzelhändlers in AK. Da ist der Verbraucher. Sie gehen in den Laden. Das Geschäft erhält verschiedene Produkte per LKW. Vermutlich beziehen die Lastwagen diese Produkte aus einem Lager. Das Lager wird mit Sendungen verschiedener Hersteller gefüllt. Die Hersteller wiederum haben selbst ganze Lieferketten.

Was passiert, wenn dem General Manager für den Versand in der oben genannten Lieferkette mitgeteilt wird, dass er einen jährlichen Bonus von 1 Million US-Dollar für jedes Jahr erhält, in dem er weniger als 10 Lastwagen in der Flotte hat? Er wird die Flotte sofort auf 9 LKWs zerhacken. In diesem "schrecklichen" Szenario wird dadurch die Menge der im Lager gelagerten Waren erhöht (was die Kosten in diesem Knoten erhöht). Und es wird die Ladenfronten "verhungern".

Die gesamte Lieferkette leidet also, wenn eine lokale Optimierung ohne Berücksichtigung des Ganzen zulässig ist.

Zurück zu TDD und UT. TDD ist ein Anforderungsausdrucksmechanismus. Das System MUSS diese Einschränkungen erfüllen. Fair genug. TDD kann das Anforderungsverhalten von Use Case Drive Development oder das Anforderungsverhalten von User Story Driven Development ersetzen. Es hat den "Vorteil", dass es die Arbeitslasten von Unit Test und Requirements kombiniert. Es ist von Vorteil, wenn die Gesamtarbeitsbelastung reduziert wird. Dies ist nicht der Fall, wenn die Arbeitslast der gesamten Lieferkette erhöht wird (lassen Sie uns die Qualität korrigieren).

Und so fragten Sie: Können Sie agil sein, ohne TDD (testgetriebene Entwicklung) durchzuführen?

Sicher kannst du. Eine andere und vielleicht bessere Frage ist: - Wenn ich TDD auf dieses Projekt anwende, führt dies zu einer insgesamt effizienteren Lieferung von Software oder zu einer weniger effizienten Lieferung?

Um einen Lieblingsautor zu zitieren ... JRR Tolkien

Herr der Ringe. Gemeinschaft der Ringe. Pg 94 'Und es wird auch gesagt', antwortete Frodo, 'Geh nicht zu den Elfen um Rat, denn sie werden beide Nein und Ja.'

Am Ende kommt es also darauf an. Sie müssen die Frage beantworten. Welcher Weg führt Sie am effizientesten zu den gewünschten Zielen?

Zu TDD oder nicht zu TDD. Das bleibt die Frage. :-)

PS - Ich reposte diese Antwort auch auf einer anderen Seite. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=de

Im Vergleich zur Konstruktion eines Schlosses.

Agiles Schloss

Wenn Sie mit Agile ein Schloss bauen würden. Sie würden Teile schreiben, die bestimmte Funktionen haben und den Benutzer ermutigen, die Funktionsteile zu verwenden, und das zukünftige Design an die Reaktionen des Benutzers anpassen. Wenn Sie also den Dungeon bauen und mit dem Dungeonwärter kommunizieren, testen Sie das Fundament, das das Land und der Dungeon zur Verfügung stellen. Sie würden die Brüstungen bauen und die Nachtwächter fragen, ob es gut ist. Sie würden die Mauern bauen und die Soldaten den Verteidigungswert testen lassen. Sie bauen die Küche und lassen sie von den Köchen untersuchen. Dabei würde jedes bisherige Teil zusätzlich zur aktuellen Struktur funktionieren. Wenn Sie den Kerker beendet haben, können Sie die Gefangenen einziehen. Und so weiter. Aber wenn du das Schloss fertig hast, findest du heraus, dass die Gefangenen geflohen sind.

TDD Schloss

Mit TDD tauchst du bei den Gefangenen auf und siehst nach, ob sie fliehen. Dann schreiben Sie die Gefängniszellen, bis sie nicht mehr entkommen können. Dann würden Sie den Code überarbeiten, um nicht benötigte Zellen und Balken an der falschen Stelle zu entfernen, und erneut testen. Gefangene sind nicht geflohen. Sie müssen nicht mit dem Gefängniswärter kommunizieren. Und du könntest das gesamte Schloss ausliefern, wenn du alles fertig hast. An diesem Punkt sagt der Gefängniswärter, dass der Dungeon mehr Zellen benötigt und Sie nun mehr Fundament ausgraben müssen.

Agiles TDD Schloss

Wenn Sie Agile und TDD kombinieren. Sie würden sehen, ob die Gefangenen geflohen sind, und dann den Gefängniswärter fragen, was gebraucht wird. Er sagt, Sie brauchen mehr Zellen. Sie würden sich zufällige Leute schnappen, um sich als Gefangene auszugeben und zu sehen, ob sie entkommen. Wenn nicht, dann zeigst du es dem Gefängniswärter und er ist glücklich damit. Dann fängst du an, die Brüstungen zu bauen.

Fazit

Beide lösen also unterschiedliche Probleme. Agile hilft bei der Änderung von Anforderungen basierend auf der Ermittlung der Benutzeranforderungen, da das Produkt zu dem Zeitpunkt entwickelt wird, an dem es am einfachsten anzupassen ist. Es geht darum, stabile Ergänzungen freizugeben, die vom Gesamtdesign abweichen.

TDD löst das Problem, einen Ausfall zu antizipieren. Erkennen und Korrigieren von Fehlern, wenn diese an einem Punkt auftreten, an dem sie am einfachsten zu beheben sind. Dabei werden stabile entkoppelte Codeeinheiten getestet, die vom Gesamtentwurf getrennt sind.

Es ist leicht, TDD als Erweiterung von Agile zu sehen, da beide dem gleichen Muster, dem einheitlichen Fortschritt und der gleichen Überprüfung folgen. Der Unterschied besteht darin, dass die Einheiten in Agile als Ganzes extern funktionieren, wohingegen die Einheiten in TDD als Teil funktionieren und möglicherweise kein funktionsfähiges Produkt für eine externe Überprüfung produzieren. Und beide Prozesse regeln unterschiedliche Bedürfnisse (Usability vs. Korrektheit). Da beide über einen Entwicklungsprozess in Einheiten funktionieren, können beide Überprüfungsprozesse an ähnlichen Punkten stattfinden, wobei die TDD feiner aufgeteilt ist.

Anmerkungen

• Unit-Tests allein bedeuten nicht, dass Sie TDD verwenden. TDD bedeutet, dass Sie den Test vor dem produzierten Gerät durchführen und den Test bei der Entwicklung verwenden, um das Gerät zu bestätigen. Unit-Tests ohne TDD können verwendet werden, um sicherzustellen, dass zuvor erstellte Funktionen nicht ungültig werden.
• Sprints und andere Meetings machen dich nicht agil. Die Ziele des Manifests machen Sie agil. Sie können Wasserfallziele mit Arbeitseinheiten in Sprints aufteilen, ohne die Verpflichtung einzuhalten, Menschen gegenüber Prozessen zu bevorzugen.
• Per Definition von TDD und Agile. Ihre Komponententests gelten für nicht lieferbare Einheiten, sodass TDD schneller als Agile ausgeführt wird. Und wenn Sie beide einsetzen, enthalten Ihre Agile-Zyklen einen oder mehrere TDD-Zyklen (wenn jede Einheit getestet wird).
• Soweit ich weiß: Sie scheitern an Agile, indem Sie dem Benutzer keine lieferbare / aussagekräftige Einheit entwickeln. Die Einheit kann auch dann sinnvoll sein, wenn sie das Produkt beschleunigt. Aber wie erklärt Agile das Refactoring für eine einfachere Wartung? Ich habe es nicht genug behandelt, um darauf zu antworten.
• Sie können TDD nicht bestehen, indem Sie den Komponententest nicht bestehen. Erstellen von Code, der die Funktion nicht korrekt erstellt.

Agile zwingt Sie, bei jeder Iteration Zeitplan- und Qualitätsrisiken zu berücksichtigen und zu mindern. Das heißt, TDD muss nicht als agil betrachtet werden .

TDD ist jedoch eine großartige Technik zur Minderung von Qualitätsrisiken, insbesondere bei Projekten mit einer großen Anzahl von Iterationen oder Personen. In einem solchen Projekt fügt TDD in frühen Iterationen ein gewisses Zeitplanrisiko hinzu, da Sie auch Testfälle schreiben müssen. TDD führt jedoch zu enormen Kosteneinsparungen bei späteren Iterationen, da Qualitätsrisiken kontinuierlich gemindert werden. dh TDD wird empfohlen.