it-swarm-eu.dev

Können Sie agil sein, ohne TDD (Test Driven Development) zu machen?

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

44
CraigTP

Ja, ja, ja, millionenfach ja.

Agilität ist eine Philosophie, TDD ist 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 ausführlich erklären werden, sind nicht TDD - aber diese sind immer noch im Wesentlichen mit dem Test zuerst verbunden, so dass Betrug wäre.

Sagen wir also Folgendes: Sie können agil sein, ohne die Entwicklung "zuerst testen" durchzuführen (sehen Sie sich die Funktionsweise von Scrum an - nirgends gibt es Einzelheiten darüber, wie Sie Code schreiben). Schauen Sie sich ein Kanban-Board an, schauen Sie sich alle möglichen agilen Methoden an.

Möchten Sie Unit-Tests? Natürlich aus allen möglichen Gründen - und Sie könnten durchaus argumentieren, dass Sie ohne Unit-Tests nicht agil sein können (obwohl ich vermute, dass dies möglich ist) -, aber Sie müssen sie nicht zuerst schreiben, um zu sein agil.

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


Es scheint, dass andere (mit einem mehr SOLID rep) 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 zu machen, ist es schwierig. Ohne TDD ist die Iterationsrate von ...

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

50
Murph

"Agil sein" bedeutet einfach, sich an die Werte und Prinzipien des agiles Manifest zu halten. In diesem Dokument wird weder TDD noch Unit-Tests erwähnt.

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

Ich würde es aber nicht empfehlen ...

19
Martin Wickman

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 Methode, ein Prozess. In der Tat ein Prozess, der möglicherweise in agilen Entwicklungsprozessen verwendet werden könnte, aber nichts weiter. Ich denke, dass TDD jetzt vielleicht auf dem neuesten Stand der Technik ist, wenn man agil ist. Aber ich denke, dass das Konzept der Agilität immer noch Bestand haben wird, selbst wenn TDD möglicherweise durch andere Praktiken ersetzt wurde.

Ich würde es so zusammenfassen:

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

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

11
FabianB

Ich sage

Nein.

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 Arten von "agil", dass es durchaus möglich ist, dass einer 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. Jedoch Ich behaupte, dass das Agile Manifest eine Reihe von Prinzipien ist, keine Entwicklungsmethode. Ich sehe keinen Sinn darin, "oh ja, ich bin agil" zu sagen, ohne die Praktiken umzusetzen, die die Vorteile bringen. Bestimmtes:

Arbeitssoftware ist das wichtigste 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 einzuhalten.

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

EDIT 2: Ja, technisch können Sie die Tests danach schreiben; aber ich betrachte test-first/TDD immer noch als grundlegend. Nicht weil man ohne es nicht "agil" sein kann, sondern weil man damit mehr agil sein wird. Test-First/Test-Driven ist ein weitaus effizienterer Ansatz als Test-Later/Test-Afterthought. 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 diese Vorstellung, dass man "agil" sein könnte, ohne tatsächlich es zu tun. Und "es zu tun" (wie oben gezeigt) erfordert so ziemlich TDD.

5
Steven A. Lowe

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

Eines der Prinzipien von 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 denken es war so). Da Agile jedoch 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.

Daher 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. Aber TDD hilft bei einem anderen Aspekt, es verhindert Überproduktion.

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

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

Wenn Sie das TDD-Prinzip korrekt befolgen, kann eine einzelne Codezeile nicht existieren, bevor ein Test diese Codezeile vorschreibt (ich persönlich kann einen trivialen Code ohne Test schreiben). Wenn Sie mit dem Schreiben des Abnahmetests beginnen, implementieren Sie nur genau das, was benötigt wird, um die erforderlichen Funktionen bereitzustellen.

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

Arbeitssoftware ist das wichtigste Maß für den Fortschritt

2
Pete

Streng genommen sind Sie agil, indem Sie sich an das agiles 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 nach ihrer Entwicklung schreiben. Normalerweise ist es jedoch einfacher und effektiver, dies auf TDD-Weise zu tun.

2
Alb

Können Sie agil sein, ohne TDD (Test Driven Development) zu machen?

Kurze Antwort: Ja.

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

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

Lean 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, in dem Sie sich befinden, kann dies jedoch von Vorteil sein oder auch nicht.

Lassen Sie uns über die Lieferkette für einen großen namenlosen Einzelhändler in AK nachdenken. 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 für jedes Jahr, in dem er weniger als 10 LKWs in der Flotte hat, einen jährlichen Bonus von 1 Million US-Dollar erhält? Er wird die Flotte sofort auf 9 Lastwagen zerhacken. In diesem "schrecklichen" Szenario erhöht dies die Menge der im Lager gelagerten Waren (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 Anforderungsausdruckmechanismus. Das System MUSS diese Einschränkungen erfüllen. Meinetwegen. TDD kann das Anforderungsverhalten von Use Case Drive Development oder das Anforderungsverhalten von User Story Driven Development ersetzen. Es hat den "lehnenden" Vorteil, die Arbeitslasten "Unit Test" und "Requirements" zu kombinieren. Es ist von Vorteil, wenn die Gesamtarbeitsbelastung reduziert wird. Dies ist nicht der Fall, wenn die Arbeitsbelastung der gesamten Lieferkette erhöht wird (korrigieren wir die Qualität).

Und so fragten Sie: Können Sie agil sein, ohne TDD (Test Driven Development) zu machen?

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

Um einen Lieblingsautor zu zitieren ... J.R.R. Tolkien

Herr der Ringe. Gemeinschaft der Ringe. S. 94 "Und es wird auch gesagt", antwortete Frodo, "geh nicht zu den Elfen um Rat, denn sie werden beide nein und ja."

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

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

PS - Ich poste 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

1
M Kevin McHugh

Im Vergleich zum Engineering einer Burg.

Agiles Schloss

Wenn Sie mit Agile ein Schloss bauen würden. Sie würden Teile schreiben, die bestimmte Funktionen haben, und den Benutzer dazu 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 Dungeonbewahrer kommunizieren, testen Sie das Fundament, das das Land und der Dungeon bieten. 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 würden die Küche bauen und die Köche sie sich ansehen lassen. Und während dieses Prozesses 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 Sie das Schloss endlich fertiggestellt haben, finden Sie heraus, dass die Gefangenen entkommen sind. Jetzt müssen Sie zurück in den Kerker gehen und herausfinden, dass Sie dickere Stangen benötigen, aber die Türen sind nicht tief genug, um die Stangen zu halten, und die Scharniere unterstützen keine größeren Türen.

TDD Schloss

Mit TDD tauchen Sie mit den Gefangenen auf und sehen, ob sie fliehen. Dann schreiben Sie die Gefängniszellen, bis sie nicht mehr entkommen können. Dann würden Sie den Code umgestalten, nicht benötigte Zellen sauber entfernen und Balken entfernen, die sich an der falschen Stelle befinden, und erneut testen. Gefangene konnten nicht entkommen. Sie müssen nicht mit dem Gefängniswärter kommunizieren. Und Sie könnten das gesamte Schloss liefern, wenn Sie alles fertig haben. Zu diesem Zeitpunkt sagt der Gefängniswärter, dass der Dungeon mehr Zellen benötigt, und jetzt müssen Sie mehr von der Grundlage ausgraben.

Agiles TDD-Schloss

Wenn Sie Agile und TDD kombinieren. Sie würden sehen, ob die Gefangenen entkommen sind, und dann den Gefängniswärter fragen, was benötigt wird. Er sagt, du brauchst mehr Zellen. Sie würden sich zufällige Leute schnappen, um sich als Gefangene auszugeben und zu sehen, ob sie fliehen. Wenn nicht, dann zeigst du es dem Gefängniswärter und er ist zufrieden damit. Dann fangen Sie 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 sich das Produkt an dem Punkt entwickelt, an dem es am einfachsten anzupassen ist. Es geht darum, stabile Zusätze freizugeben, die vom Gesamtdesign getrennt sind.

TDD löst das Problem der Vorwegnahme von Fehlern. Erkennen und Korrigieren von Fehlern an einem Punkt im Prozess, an dem sie am einfachsten zu beheben sind. Dabei werden stabile entkoppelte Codeeinheiten getestet, die vom Gesamtdesign getrennt sind.

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

Anmerkungen

  • Unit-Tests allein bedeuten nicht, dass Sie TDD verwenden. TDD bedeutet, den Test vor dem produzierten Gerät durchzuführen und den Test während der Entwicklung zu 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 zu erfüllen, Menschen gegenüber Prozessen zu bevorzugen.
  • Per Definition von TDD und Agile. Ihre Unit-Tests regeln nicht lieferbare Einheiten, sodass TDD schneller als Agile läuft. Wenn Sie beide verwenden, 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. Das Gerät kann auch dann von Bedeutung sein, wenn es 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 scheitern an TDD, indem Sie den Komponententest nicht bestehen. Erstellen von Code, der die Funktion nicht korrekt erzeugt.
1
Lee Louviere

Agile zwingt Sie, bei jeder Iteration Zeitplan- und Qualitätsrisiken zu berücksichtigen und zu mindern. d.h. TDD muss nicht als agil angesehen werden.

TDD ist jedoch eine hervorragende Technik zur Minderung von Qualitätsrisiken, insbesondere für ein Projekt 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 in späteren Iterationen zu enormen Kosteneinsparungen, da Qualitätsrisiken kontinuierlich gemindert werden. d.h. TDD wird empfohlen.

0
Jay Godse