Commentaires

1. Le mercredi 29 octobre 2008 à 09:39, par perrick

Le roulement test/code se fait sur qq minutes (qq heures grand maximum). On est bien loin des jours dédiés à l'un puis à l'autre. Idem pour le remaniement, c'est mieux de le faire en boucle très proche : tout est le plus frais. Et le feedback est immédiat. Par contre ce qu'il faut plannifier, c'est la rétrospective et ses questions sur "ce qu'on a raté", "ce qu'on a réussi" et "ce qu'on veut mieux faire". C'est vraiment à partir de ces 3 points là qu'on peut avancer chaque semaine. Le développement agile c'est juste cela : faire mieux ensuite (et donc ne pas se figer dans un process dès le début).

2. Le samedi 1 novembre 2008 à 14:24, par GeoBarTeam

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 ingéré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 paire de L’Extreem-Programming.
Il se déroule de la façon suivante :
1) On écrit un test représentant la nouvelle partie de fonctionnalité a implémenter - le test doit être atomaire – il ne devrait tester qu’une condition et un composant a la fois.
2) On roule tous les tests – uniquement le dernier test peu rater !
3) On écrit le code qui fait passer le test sans trop se posé de question - le bute c’est de faire passer le test le plu rapidement possible.
4) Une fois que tous les tests réussissent on intègre son code dans le source contrôler.
5) On Refactor jusqu'à se qu’on a éliminé toute forme de duplication.
6) On exécute tous les tests – si un ou plusieurs tests rates on corrige ou on rollback le code pour revenir au point 5.
7) On intègre le code refactoré dans le source contrôleur.
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 peu introduire la pratique de Refactoring sans disposer de Unit Test. Remanier du code sans avoir des test pour vérifier qu’on ne casse rien est dangereux !

Personnellement je te conseillerais de ne pas introduire trop de pratiques a 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 se qui permet d’implémenter de nouvelles fonctionnalités sans « upfront-design ». Les pratiques agiles présupposes aussi une grande confiance du client. Cette confiance ne peu s’établir que si vous êtes capable de produire des fonctionnalités a ritme contant sans trop de défaut 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

Se 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 toutes l’équipe. Tu doit 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, tout équipe est différentes et donc les pratiques doivent être adaptés. « 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 a une phase de chaos – cette phase est nécessaire car l’on apprend que de ces propres erreurs. Il te faudra résister a 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, si tu désires je peu aussi te procurer le contenu d’un cours que j’ai donné récemment sur le TDD – hélas je ne dispose qu’une version en Anglais et pour C#/Java.

Bonne chance.

3. Le dimanche 2 novembre 2008 à 15:45, par Xavier

GeoBarTeam, y a-t'il un rss pour ton blog? J'ai essayé de poster un commentaire mais un bug m'en a empêché.

Ajouter un commentaire

Nom ou pseudo :

Email (facultatif) :

Site Web (facultatif) :

Commentaire :

Le code HTML sera affiché comme du texte.

Se souvenir de mes informations