Dans un projet de développement informatique traditionnel, une personne a tendance à écrire des programmes entiers pour implémenter certaines fonctionnalités. Un développeur a tendance à posséder le code qu'elle écrit.

Ce n'est pas le cas avec un projet Agile. Les projets agiles élaborent des solutions incrémentielles au fil du temps. Il est très possible, et probablement probable, qu'un composant écrit pour prendre en charge une fonctionnalité spécifique ait besoin d'être mis à jour ultérieurement avec l'introduction d'un autre cas d'utilisation avec une fonctionnalité associée.

Sur un projet Agile, lorsque le deuxième développeur travaille sur un module sur lequel un autre développeur a travaillé précédemment, il reste quelques choses à faire. Premièrement, le deuxième développeur doit examiner et comprendre le travail du développeur précédent. Deuxièmement, le deuxième développeur doit insérer du code nouveau et révisé pour prendre en charge la nouvelle fonctionnalité.

Lorsque le deuxième développeur passe en revue le code, il est possible qu'il ait des idées pour le rendre plus efficace ou plus facile à gérer. Dans un projet traditionnel, on a tendance à laisser ce code inefficace en place. L’idée est que «si le code n’est pas cassé, ne le corrigez pas». Par conséquent, le code antérieur qui semble fonctionner a tendance à être isolé, de sorte que les nouveaux changements n’ont aucune incidence sur lui. Cette approche aboutit généralement à un code qui devient très «fragile» avec le temps. "Fragile" signifie que les développeurs ne comprennent pas le fonctionnement du code et que des erreurs sont introduites chaque fois que cet ancien code est touché.

Les projets agiles adoptent le point de vue opposé. Si un second développeur a de meilleures idées sur la manière dont un composant est codé, le second développeur prend le temps de mettre à jour le code. Cette révision et cette modification constantes du code sont appelées «refactoring». Le refactoring est la pratique constante de mettre à jour le code antérieur afin qu'il soit amélioré, mieux documenté et optimisé.

Le refactoring peut prendre plus de temps pour écrire et tester pendant l'itération en cours. Le plus grand danger de toucher à l'ancien code est toujours que vous allez casser quelque chose qui fonctionne aujourd'hui. Toutefois, sur les projets Agiles, ce risque est minimisé par des tests automatisés et rigoureux, de sorte que toute nouvelle erreur puisse être rapidement découverte et corrigée. Tout impact à court terme est compensé par la fourniture continue de meilleurs codes tout au long du projet. Le code sera plus propre, plus efficace, plus flexible, mieux documenté et beaucoup plus facile à gérer à long terme. Le résultat est la capacité des équipes agiles à maintenir des solutions plus flexibles et efficaces tout au long de la vie du produit. par Danielle Smallwood, TenStep Tom Mochal