En effet planifier des séances de Refactoring (remaniement) et de Unit-Testing n’a pas beaucoup de sens. Ces deux activités doivent être intégrées au processus de création du code. Ce processus de programmation s’appelle TDD (Test-Driven Developement), il a été élaboré par Kent Beck le père de L’Extreme-Programming.

Il se déroule de la façon suivante :

1. ) On écrit un test représentant la nouvelle partie de fonctionnalité à implémenter - le test doit être atomique – il ne devrait tester qu’une condition et un composant a la fois.
2. ) On exécute tous les tests – uniquement le dernier test peu rater !
3. ) On écrit le code qui fait passer le test sans trop se poser de question - le but c’est de faire passer le test le plus rapidement possible.
4. ) Une fois que tous les tests réussissent, on intègre son code dans le source controller.
5. ) On Refactor jusqu'à ce qu’on aie éliminé toute forme de duplication.
6. ) On exécute tous les tests – si un ou plusieurs tests échoue on corrige ou on rollback le code pour revenir au point 5.
7. ) On intègre le code refactoré dans le source controller.
8. ) On retourne au point (1)

En se qui concerne l’introduction de pratiques Agile, il faut tenir comptes que certaines pratiques sont dépendantes l’une de l’autre. Ainsi on ne peut introduire la pratique du Refactoring sans disposer de Unit Test. Remanier du code sans avoir des tests pour vérifier qu’on ne casse rien est dangereux !

Personnellement je te conseillerais de ne pas introduire trop de pratiques à la fois et de commencer avec les pratiques qui amélioreront la malléabilité et la qualité du code.

Le développement itératif se fonde sur la supposition que le code et malléable cad qu’il contient peu d’interdépendance. C’est ce qui permet d’implémenter de nouvelles fonctionnalités sans « upfront-design ».

Les pratiques agiles présupposent aussi une grande confiance du client. Cette confiance ne peut s’établir que si vous êtes capable de produire des fonctionnalités a rythme contant sans trop de défauts et que vous prouvez que vous êtes flexible. Pour moi les trois pratiques sur lesquelles reposent toutes les autres sont :

1. ) Le Unit-Testing
2. ) Le Refactoring
3. ) Le Pair-programming

Ce sont hélas aussi les plus difficile a introduire. C’est pourquoi je te suggère de les étudier en profondeur. Pour cela tu as deux possibilités :

• Tu les étudies toi-même en lisant des blogs, livres et surtout en pratiquant toi-même tous les jours. Ensuite tu fait des séance de pair programming avec comme bute d’apprendre a chacun le unit-testing & le refactoring. Tu procède donc par incubation : tu incube d’abord une personne qui te semble la plu apte et tu fais en sorte que le virus se propage.
• Tu te fait aider par un coach.

Une dernières chose et pas des moindres : introduire les pratiques & valeurs Agiles se fait avec toute l’équipe. Tu dois avant tout t’assurer que l’équipe est convaincue que l’Agile peu les aider. Pour cela chacun doit recevoir l’occasion de participer. Il n’y a pas de recette miracle, toute équipe est différente et donc les pratiques doivent être adaptées. « Les rétrospectives » est un moyen très efficace pour cela. Cette pratique cimente l’équipe et permet de s’améliorer constamment. Néanmoins l’Agile est comme cuisiner il faut d’abord apprendre et pratiquer les bases avant de pouvoir improviser !

De toute façon attend toi à une phase de chaos – cette phase est nécessaire car l’on apprend que de ses propres erreurs. Il te faudra résister à cette phase mais je peux t’assurer que si vous percevrez l’équipe ne voudra pas retourner en arrières !

J’ai publié plusieurs articles concernant le unit testing sur mon blog.

Bonne chance.