Est-il possible de s’appeler correctement (ou votre équipe) "Agile" si vous ne faites pas de TDD (Test Driven Development)?

Oui, oui, oui, un million de fois oui.

Agile est une philosophie, TDD est une méthodologie spécifique.

Si je voulais être vraiment pointilleux, je pourrais simplement souligner qu'il existe de nombreuses variantes de xDD - ce que leurs défenseurs vont expliquer en profondeur ne sont pas des TDD - mais celles-ci sont toujours liées de manière substantielle au premier test, ce qui constituerait une tricherie.

Alors disons ceci - vous pouvez être agile sans faire de "test d'abord" le développement (regardez le fonctionnement de Scrum - nulle part, il n'y a de détails sur la façon dont vous écrivez du code). Regardez un tableau kanban, regardez toutes sortes de méthodologies agiles.

Voulez-vous des tests unitaires? Bien sûr, pour toutes sortes de raisons - et vous pourriez bien argumenter que vous ne pouvez pas être agile sans tests unitaires (bien que je suppose que vous pouvez l'être) - mais vous n'avez pas à les écrire d'abord pour être agile.

Et enfin, il est également vrai que vous pouvez faire Test d'abord sans être des arguments agiles et solides pour effectuer le test d'abord, quelle que soit votre philosophie de développement globale.

Il semble que d'autres (avec un représentant plus solide) ont un avis similaire ...

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

@unclebobmartin: http://t.co/huxAP5cS Bien qu'il ne soit pas impossible de faire de l'agilité sans TDD et OOD, c'est difficile. Sans TDD, le taux d'itération de ...

(Le lien dans le tweet est la réponse complète sur LinkedIn)

"Être agile" signifie simplement adhérer aux valeurs et aux principes du manifeste agile . Rien dans ce document ne mentionne TDD, ni même des tests unitaires à ce sujet.

Alors oui, vous pouvez être agile sans TDD ou tests unitaires.

Je ne le recommanderais pas cependant ...

Oui ,

Regardez l'une des valeurs agiles:

Individus et interactions sur les processus et les outils

Cela devrait déjà y répondre. TDD est une certaine méthodologie, un processus. En effet, un processus qui pourrait éventuellement être utilisé dans des processus de développement agiles, mais rien de plus. Je pense que TDD est peut-être à la pointe de la technologie lorsqu'il est agile. Mais je pense que le concept d’agilité pourra encore durer, même si le TDD a peut-être été remplacé par d’autres pratiques.

Je résumerais ça comme:

• Aujourd'hui, TDD est un standard de facto pour être agile

• Il peut y avoir moyen d'être agile sans TDD

je dis

Non [en quelque sorte]

Si vous revenez à la source originale http://en.wikipedia.org/wiki/Extreme_Programming TDD est fondamental pour le processus; les tests remplacent les spécifications des exigences et les cas d'utilisation de la cascade, servent de documentation vivante et d'exemples de fonctionnement, etc. Ils sont indispensables.

Cependant, il y a tellement de goûts «agiles» qui flottent maintenant qu'il est tout à fait possible que l'un d'eux évite TDD

EDIT: @ L'interprétation de Murph de la question semble être la préférée. Zut j'ai même voté, c'est une bonne réponse. Cependant , je maintiens que le Manifeste Agile est un ensemble de principes et non une méthodologie de développement. Je ne vois pas l'utilité de dire "ah oui, je suis agile" sans mettre en œuvre les pratiques qui apportent des avantages. En particulier:

Le logiciel de travail est la principale mesure de progrès.

et

Les processus agiles favorisent le développement durable. Les sponsors, les développeurs et les utilisateurs devraient être en mesure de maintenir indéfiniment un rythme constant.

Pour moi, ces deux principes impliquent sinon besoin de TDD - du moins je ne connais pas d'autre moyen de les réaliser sans cela!

EDIT 2: oui, techniquement, vous pouvez écrire les tests ultérieurement; mais je considère toujours test-first / TDD comme fondamental. Non pas parce que vous ne pouvez pas "être agile" sans cela, mais parce que vous serez plus agile avec cela. Le test d'abord / basé sur le test est une approche bien plus efficace que le test plus tardif / le test d'après coup. Les descriptions de test sont les exigences . Ne les remets pas à plus tard ;-)

EDIT 3: J'ai enfin compris ce qui me dérangeait tant dans la réponse très bien écrite de Murph. C'est cette notion que l'on pourrait "être agile" sans le faire réellement . Et "le faire" (comme indiqué ci-dessus) nécessite à peu près TDD.

Strictement, vous êtes agile en adhérant au manifeste agile . En pratique, une base de code n'est pas agile à moins d'avoir une bonne couverture de test. Vous pouvez faire TDD et écrire les tests avant / pendant le développement de la fonctionnalité ou écrire des tests pour la fonctionnalité après son développement. Cependant, il est généralement plus facile et plus efficace de le faire selon la méthode TDD.

Vous pouvez être agile, mais il y a probablement place à amélioration.

L'un des principes de l'agile est que vous devez être capable de réagir au changement. Cela signifie que vous ne savez pas à l'avance ce que vous devez construire. Si vous suiviez un processus en cascade, vous sauriez x mois à l'avance exactement ce que vous devez construire, et vous pouvez concevoir des composants logiciels individuels pour qu'ils participent chacun à un programme plus vaste, atteignant le produit final (au moins, vous pensez que c'était ainsi). Mais comme Agile vous demande de ne pas savoir quel est le produit final, vous ne savez jamais à quoi sert votre code, mais surtout quand il sera modifié.

Par conséquent, vous avez besoin d'une suite de tests complète pour vous assurer que les fonctionnalités que vous avez déjà créées continuent de fonctionner à mesure que la base de code est modifiée.

Mais ce n’est pas en soi un TDD. Si vous écrivez les tests après avoir écrit le code, ce n'est pas TDD. Mais TDD aide avec un autre aspect, il empêche la surproduction.

Au sein de ma propre équipe agile, les développeurs écrivent du code qui, à leur avis, deviendrait utile plus tard dans le projet. Si le développement de la cascade avait été bon, cela aurait probablement fonctionné, car ils apportaient un soutien à quelque chose dans le plan du projet pour les x prochains mois.

Mais si vous suivez les principes agiles, vous ne devriez pas écrire ce code, car vous ne savez pas si cela sera même nécessaire. Le film prévu pour la semaine prochaine peut être soudainement reporté à une date indéterminée.

Si vous suivez correctement le principe TDD, une seule ligne de code ne peut pas exister avant qu'un test ne dicte cette ligne de code (personnellement, je peux écrire du code trivial sans test), et si vous commencez par écrire le test d'acceptation, vous ne mettez en œuvre que exactement ce qui est nécessaire pour fournir les fonctionnalités requises.

TDD aide donc à éviter la surproduction, permettant à l’équipe d’être aussi efficace que possible, ce qui est également un principe fondamental de l’agilité.

Un logiciel fonctionnel est la principale mesure de progrès

Pouvez-vous être agile sans TDD (développement piloté par les tests)?

Réponse courte: oui.

Réponse plus longue: Il existe déjà de très bonnes réponses à cette question et de très bonnes références. Je ne vais pas essayer de débattre de ces points.

D'après mon expérience, Agile consiste à sélectionner le niveau de rationalité approprié pour le projet en question. Qu'est-ce que je veux dire par maigreur? Et pourquoi est-ce que je l'amène dans cette réponse?

Lean ne veut pas dire éliminer tout le possible de votre méthode. Comme l’a noté un de nos collègues, il n’est pas nécessaire d’inclure le test TDD ou le test unitaire dans vos comportements. Cependant, dans le contexte du projet dans lequel vous vous trouvez, cela peut être bénéfique ou non.

Pensons à la chaîne d'approvisionnement d'un grand détaillant non identifié situé en AK. Il y a le consommateur. Ils vont dans le magasin. Le magasin reçoit divers produits par camion. Les camions acheminent vraisemblablement ces produits dans un entrepôt. L'entrepôt est rempli par des expéditions de divers fabricants. Les fabricants ont eux-mêmes des chaînes d'approvisionnement complètes.

Que se passe-t-il lorsque le directeur général des expéditions dans la chaîne d'approvisionnement ci-dessus se fait dire qu'il recevra un bonus annuel d'un million de dollars pour chaque année qu'il compte moins de 10 camions dans son parc? Il va immédiatement couper la flotte à 9 camions. Dans ce scénario "terrible", cela augmentera la quantité de marchandises stockées dans l'entrepôt (augmentant les coûts dans ce nœud). Et, cela "affamera" les devantures des magasins.

Ainsi, la chaîne d'approvisionnement dans son ensemble en pâtit si l'optimisation locale est autorisée sans tenir compte de l'ensemble.

Retour à TDD et UT. TDD est un mécanisme d'expression des exigences. Le système DOIT respecter ces contraintes. C'est suffisant. TDD peut remplacer le comportement des exigences de Use Case Drive Development ou le comportement des exigences de User Story Driven Development. Il présente l’avantage "penchant" de combiner les charges de travail des tests unitaires et des exigences. C'est un avantage si la charge de travail globale est réduite. Ce n'est pas le cas si la charge de travail de l'ensemble de la chaîne d'approvisionnement est augmentée (corrigeons la qualité).

Et oui, vous avez demandé: pouvez-vous être agile sans TDD (développement piloté par les tests)?

Sûr que vous pouvez. Une question différente, et peut-être meilleure, est la suivante: - Si j'applique le TDD à ce projet, cela aura-t-il pour résultat une livraison de logiciels plus efficace ou moins efficace?

Pour citer un auteur favori ... JRR Tolkien

Le Seigneur des Anneaux. Communauté des anneaux. Pg 94 'Et il est également dit', répondit Frodon, 'n'allez pas chercher un conseil auprès des elfes, car ils voudront à la fois non et oui.'

Donc, à la fin, ça dépend. Vous devez répondre à la question. Quel chemin vous mènera le plus efficacement à vos objectifs souhaités.

À TDD ou non à TDD. Cela reste la question. :-)

PS - Je republie cette réponse sur un autre site aussi. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

Comparant à l'ingénierie d'un château.

Château Agile

Si vous deviez créer un château en utilisant Agile. Vous écririez des parties qui ont des fonctions spécifiques et encouragez l'utilisateur à utiliser les parties fonctionnelles, en adaptant la conception future aux réactions de l'utilisateur. Donc, vous construisez le donjon et communiquez avec le gardien du donjon, vous testez les bases fournies par le terrain et le donjon. Vous construirez les garde-corps et demanderez aux veilleurs de nuit si c'est bon. Vous construiriez les murs et demanderiez aux soldats de tester la valeur défensive. Vous construisez la cuisine et faites vérifier par les cuisiniers. Et pendant ce processus, chaque partie à ce jour fonctionnerait en plus de la structure actuelle. Ainsi, lorsque vous aurez terminé le cachot, vous pourrez déplacer les prisonniers. Et ainsi de suite. Mais lorsque vous avez enfin terminé le château, vous découvrez que les prisonniers se sont échappés.

TDD Castle

Avec TDD, vous vous présentez avec les prisonniers et voyez s'ils s'échappent. Ensuite, vous écrivez les cellules de la prison jusqu'à ce qu'elles ne puissent plus s'échapper. Ensuite, vous reformuleriez le code en supprimant proprement les cellules inutiles, les barres au mauvais emplacement et en effectuant un nouveau test. Les prisonniers ne se sont pas échappés. Vous n'avez pas à communiquer avec le geôlier. Et vous pouvez livrer le château en entier une fois que vous avez terminé. À ce stade, le geôlier dit que le cachot a besoin de plus de cellules, et maintenant vous devez déterrer plus de fondations.

Château TDD Agile

Si vous combinez Agile et TDD. Vous verriez si les prisonniers se sont échappés, puis demandez au geôlier ce qui est nécessaire. Il dit que vous avez besoin de plus de cellules. Vous iriez chercher des gens au hasard pour faire semblant d'être des prisonniers et voir s'ils s'échappaient. Si ce n'est pas le cas, vous le montrez au geôlier et il en est satisfait. Ensuite, vous commencez à construire les parapets.

Conclusion

Donc, les deux résolvent des problèmes différents. Agile aide à changer les exigences en fonction de la découverte des besoins des utilisateurs lorsqu'ils voient le produit se développer au moment où le processus est le plus facile à adapter. Il s’agit de libérer des ajouts stables séparés de la conception générale.

TDD résout le problème de l'anticipation des échecs. Détection et correction des échecs lorsqu’ils se produisent à un point du processus où il est plus facile de réparer. Cela implique de tester des unités de code découplées stables, séparées de la conception globale.

Il est facile de voir TDD comme une extension de Agile, car ils suivent tous deux le même modèle, les progrès dirigés par les unités et la révision. La différence est que les unités dans Agile fonctionnent à l’extérieur jusqu’à présent dans son ensemble, alors que les unités dans TDD fonctionnent comme une partie et peuvent ne pas produire un produit qui fonctionne pour une révision externe. Et les deux processus régissent des besoins différents (facilité d'utilisation vs exactitude). Étant donné que les deux fonctionnent au cours d’un processus de développement en unités, les deux processus d’examen peuvent se dérouler à des moments similaires, le TDD étant divisé plus finement.

Remarques

• Avoir des tests unitaires seuls ne signifie pas que vous utilisez TDD. TDD signifie avoir le test avant l'unité produite et l'utiliser à mesure que vous développez pour confirmer l'unité. Les tests unitaires sans TDD peuvent être utilisés pour vous assurer de ne pas invalider les fonctionnalités précédemment créées.
• Avoir des sprints et autres réunions ne vous rend pas agile. Les objectifs du manifeste vous rendent agile. Vous pouvez diviser les objectifs en cas de chute d'eau en sprints avec des unités de travail, sans respecter l'engagement pris de favoriser les personnes avant les processus.
• Par définition, TDD et Agile. Vos tests unitaires régiront les unités non livrables et TDD fonctionnera donc plus vite que Agile. Et si vous utilisez les deux, vos cycles Agiles contiendront un ou plusieurs cycles TDD (si chaque unité est testée).
• D'après ce que j'ai compris: vous échouez dans l'agilité en ne développant pas une unité livrable / significative pour l'utilisateur. L'unité peut être utile même si elle accélère le produit. Mais comment Agile explique-t-il la refactorisation pour faciliter la maintenance? Je n'ai pas assez couvert pour répondre à cela.
• Vous échouez à TDD en échouant au test unitaire. Produire du code qui ne produit pas la fonctionnalité correctement.

Agile vous oblige à gérer et à atténuer les risques liés au calendrier et à la qualité à chaque itération. c'est-à-dire que TDD n'est pas nécessaire pour être considéré comme agile .

Cependant, le TDD est une technique formidable pour atténuer les risques liés à la qualité, en particulier pour un projet comportant un grand nombre d'itérations ou de personnes. Dans un tel projet, TDD ajoutera un certain risque de planification dans les premières itérations, car vous devez également écrire des scénarios de test. Cependant, TDD permet de réaliser d’énormes économies lors des itérations ultérieures, car il limite en permanence les risques pour la qualité. ie TDD est recommandé.