Pouvez-vous être Agile sans faire de TDD (développement piloté par les tests)?
Est-il possible de s'appeler correctement (ou votre équipe) "Agile" si vous ne faites pas 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 - que leurs défenseurs expliqueront en profondeur sont pas TDD - mais ceux-ci sont toujours substantiellement liés au test en premier, ce serait donc de la triche.
Disons donc ceci - vous pouvez être agile sans faire de développement "testez d'abord" (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, vous le faites, pour toutes sortes de raisons - et vous pourriez bien faire valoir que vous ne pouvez pas être agile sans tests unitaires (bien que je soupçonne 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 le test en premier sans être des arguments Agiles et solides pour faire le test en premier, quelle que soit votre philosophie de développement globale.
Il semble que d'autres (avec un plus SOLID rep) ont une opinion similaire ...
http://www.Twitter.com/unclebobmartin/status/208621409663070208
@unclebobmartin: http://t.co/huxAP5cS Bien qu'il ne soit pas impossible de faire de l'Agile sans TDD et OOD, c'est difficile. Sans TDD, le taux d'itération de ...
(Le lien dans le Tweet est vers 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 d'ailleurs.
Alors oui, vous pouvez être agile sans faire de tests TDD ou unitaires.
Je ne le recommanderais cependant pas ...
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 agile, mais rien de plus. Je pense que le TDD est peut-être à la pointe de la technologie maintenant lorsqu'il est agile. Mais je pense que le concept d'agile pourra encore durer, même si peut-être le TDD a été remplacé par d'autres pratiques.
Je résumerais comme:
Aujourd'hui TDD est un standard de facto pour être agile
Il peut y avoir des façons d'être agile sans TDD
Je dis
Non [en quelque sorte]
Si vous revenez à la source d'origine 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 saveurs différentes d'agile flottant maintenant qu'il est tout à fait possible que l'une d'elles évite TDD
EDIT: @ L'interprétation de la question par Murph semble être la préférée. Heck, j'ai même voté contre, c'est une bonne réponse. Cependant, je maintiens ma position selon laquelle le Manifeste Agile est un ensemble de principes, pas une méthodologie de développement. Je ne vois aucune utilité à dire "oh oui je suis agile" sans réellement mettre en œuvre les pratiques qui apportent les bénéfices. En particulier:
Un logiciel de travail est la principale mesure du progrès.
et
Les processus agiles favorisent le développement durable. Les sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment.
Pour moi, ces deux principes impliquent sinon nécessitent TDD - du moins je ne connais pas d'autre moyen de les réaliser sans lui!
EDIT 2: oui, techniquement, vous pouvez écrire les tests par la suite; mais je considère toujours le test en premier/TDD comme fondamental. Non pas parce que vous ne pouvez pas "être agile" sans cela, mais parce que vous serez plus agile avec lui. Le test d'abord/piloté par le test est une approche beaucoup plus efficace que le test ultérieur/le test après coup. Les descriptions des tests sont les exigences. Ne les remettez pas à plus tard ;-)
EDIT 3: J'ai finalement compris ce qui me dérange tellement dans la réponse très bien écrite de Murph. C'est cette notion que l'on pourrait "être Agile" sans réellement le faire. Et "le faire" (comme indiqué ci-dessus) nécessite à peu près TDD.
Vous pouvez être agile, mais il y a probablement matière à amélioration.
L'un des principes de l'agilité est que vous devez être en mesure 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 dont vous avez besoin pour construire, et vous pourriez concevoir des composants logiciels individuels afin qu'ils participent chacun à un schéma plus large, atteignant le produit final (au moins, vous penseriez que c'était ainsi). Mais comme l'agile dicte que vous ne savez pas quel est le produit final, vous ne savez jamais à quoi servira votre code, et plus important encore, 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à construites continuent de fonctionner lorsque la base de code est modifiée.
Mais ce n'est pas en soi 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.
Dans ma propre équipe agile, j'ai eu du mal avec les développeurs qui écrivent du code qui, selon eux, deviendrait utile plus tard dans le projet. Si cela avait été le développement d'une cascade, cela serait probablement OK, car ils ajoutaient du soutien pour quelque chose dans le plan de projet pour les x prochains mois.
Mais si vous suivez les principes agiles, vous ne devriez pas écrire ce code, car vous n'avez aucune idée si cela sera même nécessaire. La fonctionnalité qui était prévue pour la semaine prochaine peut soudainement être reportée indéfiniment.
Si vous suivez correctement le principe TDD, alors 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 tester), et si vous commencez par écrire le test d'acceptation, alors vous implémentez uniquement exactement ce qui est nécessaire pour fournir les fonctionnalités requises.
Ainsi, TDD permet d'éviter la surproduction, permettant à l'équipe d'être aussi efficace que possible, ce qui est également un principe de base agile.
Un logiciel fonctionnel est la principale mesure du progrès
Strictement, vous êtes agile en adhérant au manifeste agile . En pratique, une base de code n'est agile que si elle a 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 de la manière TDD.
Pouvez-vous être Agile sans faire de 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 n'essaierai pas de débattre de ces points.
D'après mon expérience, Agile consiste à choisir le bon niveau de Lean-ness pour le projet en cours. Qu'est-ce que je veux dire par Lean-ness? Et, pourquoi dois-je l'inclure dans cette réponse?
Lean ne signifie pas couper tout ce qui est possible hors de votre méthode. Comme l'un de nos collègues l'a noté, vous n'avez pas à inclure le TDD ou le test unitaire dans vos comportements. Cependant, dans le contexte du projet que vous vous trouvez, cela peut être bénéfique ou non.
Pensons à la chaîne d'approvisionnement d'un grand détaillant anonyme situé à AK. Il y a le consommateur. Ils entrent dans le magasin. Le magasin reçoit divers produits par camion. On suppose que les camions achètent 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 entières.
Que se passe-t-il lorsque le directeur général de l'expédition dans la chaîne d'approvisionnement ci-dessus est informé qu'il recevra une prime annuelle de 1 million de dollars pour chaque année où il a moins de 10 camions dans la flotte? Il coupera immédiatement la flotte à 9 camions. Dans ce scénario "horrible", cela augmentera la quantité de marchandises stockées dans l'entrepôt (augmentant le coût dans ce nœud). Et, cela "affamera" les devantures de magasins.
Ainsi, la chaîne d'approvisionnement globale souffre si l'optimisation locale est autorisée sans tenir compte de l'ensemble.
Revenons à TDD et UT. TDD est un mécanisme d'expression des exigences. Le système DOIT fonctionner avec 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 a l'avantage de s'appuyer sur la combinaison des charges de travail de test unitaire et d'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 globale de la chaîne d'approvisionnement augmente (fixons la qualité).
Et donc, vous avez demandé: pouvez-vous être agile sans faire de TDD (développement piloté par les tests)?
Sûr que vous pouvez. Une question différente, et peut-être meilleure, est: - Si j'applique TDD à ce projet, cela se traduira-t-il par une livraison globale plus efficace des logiciels ou moins efficace?
Pour citer un auteur préféré ... J.R.R. Tolkien
Le Seigneur des Anneaux. Communauté des anneaux. Pg 94 'Et il est aussi dit', répondit Frodon, 'N'allez pas voir les elfes pour conseil, car ils seront tous les deux non et oui.'
Donc, en fin de compte, ... cela dépend. Vous devez répondre à la question. Quel chemin vous mènera le plus efficacement à vos objectifs souhaités.
Vers TDD ou non vers TDD. Cela reste la question. :-)
PS - Je republie également cette réponse sur un autre site. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en
Comparé à l'ingénierie d'un château.
Château Agile
Si vous deviez concevoir un château en utilisant Agile. Vous écririez des parties qui ont des fonctions spécifiques et encourageriez l'utilisateur à utiliser les parties fonctionnelles, en ajustant la conception future aux réactions de l'utilisateur. Donc, vous construisez le donjon et communiquez avec le gardien du donjon, vous testez les fondations fournies par le terrain et le donjon. Vous construisez les parapets et demandez aux veilleurs si c'est bon. Vous construisez les murs et demandez aux soldats de tester la valeur défensive. Vous construisez la cuisine et demandez aux cuisiniers de l'examiner. Et pendant ce processus, chaque pièce à ce jour fonctionnerait en plus de la structure actuelle. Donc, lorsque vous avez terminé le donjon, vous pouvez emmener les prisonniers. Et ainsi de suite. Mais quand vous avez enfin terminé le château, vous découvrez que les prisonniers se sont évadés. Maintenant, vous devez retourner dans le donjon et découvrir que vous avez besoin de barres plus épaisses, mais les portes ne sont pas assez profondes pour contenir les barres et les charnières ne supportent pas les portes plus grandes.
Château TDD
Avec TDD, vous vous présentez avec les prisonniers et voyez s'ils s'échappent. Ensuite, vous écrivez les cellules de prison jusqu'à ce qu'elles ne puissent pas s'échapper. Ensuite, vous refactorisez le code en supprimant proprement les cellules inutiles et en supprimant les barres qui sont au mauvais endroit, puis testez à nouveau. Les prisonniers ne se sont pas échappés. Vous n'êtes pas obligé de communiquer avec le geôlier. Et vous pourriez livrer tout le château une fois que vous aurez terminé. À ce stade, le geôlier dit que le donjon a besoin de plus de cellules, et maintenant vous devez creuser 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 dont vous avez besoin. Il dit que vous avez besoin de plus de cellules. Vous iriez chercher des gens au hasard pour faire semblant d'être prisonniers et voir s'ils s'échappent. S'ils ne le font pas, vous le montrez au geôlier, et il en est content. Ensuite, vous commencez à construire les parapets.
Conclusion
Donc, les deux résolvent des problèmes différents. Agile aide à faire évoluer les exigences en fonction de la découverte des besoins des utilisateurs lorsqu'ils voient le produit se développer au point du processus où il est le plus facile de s'adapter. Il s'agit de publier des ajouts stables, séparés de la conception globale.
TDD résout le problème de l'anticipation des pannes. Découvrir et corriger l'échec tel qu'il se produit à un moment du processus où il est plus facile de le corriger. Cela implique de tester des unités de code découplées stables, dissociées de la conception globale.
Il est facile de voir TDD comme une extension d'Agile, car ils suivent tous les deux le même modèle, la progression et la révision pilotées par l'unité. La différence est que les unités dans Agile fonctionnent de manière externe à ce jour dans leur ensemble, tandis que les unités dans TDD fonctionnent comme une partie, et peuvent ne pas produire un produit fonctionnel pour un examen externe. Et les deux processus régissent des besoins différents (utilisabilité vs exactitude). Étant donné que les deux fonctionnent sur un processus de développement en unités, les deux processus d'examen peuvent se produire à des points similaires, le TDD étant plus finement divisé.
Remarques
- Avoir des tests unitaires seuls ne signifie pas que vous utilisez TDD. TDD signifie avoir le test avant l'unité produite et utiliser le test au fur et à mesure que vous développez pour confirmer l'unité. Les tests unitaires sans TDD peuvent être utilisés pour s'assurer que vous n'invalidez pas les fonctionnalités précédemment construites.
- Avoir des sprints et d'autres réunions ne vous rend pas agile. Les objectifs du manifeste vous rendent agile. Vous pouvez diviser les objectifs de cascade en sprints avec des unités de travail, sans respecter l'engagement de favoriser les gens par rapport aux processus.
- Par définition de TDD et Agile. Vos tests unitaires régiront les unités non livrables, et donc TDD sera plus rapide qu'Agile. Et si vous utilisez les deux, vos cycles Agile contiendront un ou plusieurs cycles TDD (si chaque unité est testée).
- D'après ce que je comprends: vous échouez Agile en échouant à développer une unité livrable/significative pour l'utilisateur. L'unité peut être significative même si elle accélère le produit. Mais comment Agile explique-t-il le refactoring pour une maintenance plus facile? Je ne l'ai pas suffisamment couvert pour répondre à cela.
- Vous échouez TDD en échouant au test unitaire. Produire du code qui ne produit pas correctement la fonctionnalité.
Agile vous oblige à gérer et à atténuer les risques de calendrier et de qualité à chaque itération. c'est-à-dire TDD n'est pas nécessaire pour être considéré comme Agile.
Cependant, TDD est une technique formidable pour atténuer les risques de qualité, en particulier pour un projet avec 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 cas de test. Cependant, TDD permet de réaliser d'énormes économies de coûts dans les versions ultérieures car il atténue en permanence les risques liés à la qualité. c'est-à-dire TDD est recommandé.