En route vers l'agilité, SCRUM et XP : retour d'expérience

Dans les méthodes agiles, le client est un acteur du projet : il a un rôle indispensable et fait partie intégrante de l'équipe projet (dans SCRUM on parle de Product Owner).
Sa participation au projet lui permet d'exprimer au plus juste ses besoins et de vérifier très rapidement la bonne orientation de l'équipe. De manière générale, un logiciel qui répond au mieux aux besoins du client est synonyme d'une grande satisfaction.
A contrario un projet classique fonctionne avec un effet tunnel qui conduit souvent à des mauvaises surprises, où chaque ajustement se traduit par de grandes manœuvres et des retards dans les livraisons. De plus, le besoin client évoluant tout au long du projet, ce fonctionnement est difficile adapter.**

Les méthodes agiles essaient de concilier le besoin client et l'épanouissement de l'équipe projet. Dans beaucoup de projets, on a un client exigeant à qui on ne fournit pas les bons outils pour exprimer son besoin et faire évoluer son produit. Du coup, on a souvent un chef de projet qui doit s'adapter aux évolutions du besoin client et une équipe de développement qui subit les chiffrages et le planning du chef de projet et dans tout ça, il reste très peu de place pour la qualité, pour l'amélioration et finalement pour l'épanouissement de l'équipe dans son travail, condition sine qua non à une haute capacité de production.

** Attention, je ne dis pas que toutes les méthodes non agiles entraînent ces désagréments, il existe d'autres méthodologies qui fonctionnent.

J'ai beaucoup parlé, précédemment, d'amélioration continue, quand on cherche à bonifier les processus et la qualité des développements, on est à la quête des bonnes pratiques, des bons outils et des bons processus. Les méthodes agiles n'imposent rien pour la plupart, mais offrent un cadre qui permet à l'équipe de répondre aux mieux aux exigences du projet. SCRUM, par exemple, offre un certain nombre de réunions qui ont pour but d'améliorer la qualité des développements (je pense aux mêlées quotidiennes et surtout à la rétrospective de SPRINT).
Il y a aussi XP, qui par le biais du Refactoring, ou encore de Pair Programming et de Revue de code, permet d'améliorer continuellement le code, mais aussi un partage et un enrichissement des connaissances de l'équipe.

J'avais l'envie, je connaissais des pratiques, mais je n'avais pas de ligne de conduite.
Une vision globale de ces pratiques me faisait défaut, comment les intégrer et les orchestrer dans un projet ?

Il a suffi d'un livre pour que j'y voie un peu plus clair.
Il m'a permis :

• de mettre en place ces méthodes ;
• de pouvoir assembler les petits bouts d'expériences acquises ;
• d'avoir une vue d'ensemble et donc de structurer ma pensée.

Ce livre offre une expérience accessible et détaillée du déroulement d'un projet Agile, il est aussi disponible en version française :

Livre : Scrum et XP depuis les tranchées

Il ne suffit pas de s'intéresser aux méthodes agiles si on n'a pas l'occasion de les pratiquer dans son projet (ça crée même une certaine frustration). Cependant, il est difficile de l'intégrer dans un projet sans une opportunité ou une contrainte.
L'opportunité a été de pouvoir mettre en place une équipe projet et la liberté d'utiliser la méthode pour piloter l'équipe. Donc à force de motivation et à défaut du vécu, j'ai essayé de mettre en place SCRUM et XP dans mon projet.
Au départ il me fallait rapidement fixer des éléments et des outils pour pouvoir démarrer, donc pas le temps de flâner, il me fallait déjà digérer ma nouvelle casquette de SCRUM Master et fédérer tout le monde derrière cette méthode.

Le point clé qui a rendu possible mon action est le soutien de mon client. La présence et la participation du client de manière régulière sont quelques-unes des conditions pour la réussite de la mise en place d'une transformation agile. Dans SCRUM le client est représenté par le Product Owner qui initialise le backlog de produit et assiste à différentes réunions dont la plus importante est la réunion SPRINT planning.
Dans mon cas, mon client est plutôt moteur dans ces actions, car d'une part les méthodes agiles étaient dans l'air du temps et d'autre part un début d'implémentation était déjà présent. Souvent il est plus simple de parler de qualité à un client qui a vécu l'échec et des difficultés de construire, maintenir et faire évoluer un projet : Scrum permet l'expression de l'équipe en rendant autonome chaque membre et il garantit la présence du client pour répondre aux objectifs de chaque équipe projet, à savoir être productif en répondant au mieux au besoin du client.

Pour commencer à appliquer Scrum, il faut d'abord fédérer le client et l'équipe à la cause du projet. L'implication du client se fait dès le départ dans la phase préliminaire appelée SPRINT 0, même si elle ne correspond pas à un vrai SPRINT, c'est la phase qui permet d'initialiser la méthodologie. Dans cette phase on prépare ce qui est nécessaire au lancement des sprints dans de bonnes conditions, comme par exemple élaborer le backlog de produit, dates de releases…

Dans mon projet la complexité était plus importante pour installer SCRUM puisque le projet était déjà lancé et une première version avait déjà été livrée. Nous avions déjà en place un système pour référencer les tâches en cours (Jira), nous avons donc complété notre liste de tâches pour qu'elle joue le rôle de backlog de produit avec au moins le contenu des trois sprints suivants et nous avons programmé le contenu de deux premières releases.

Le Product Owner est un acteur clé dans Scrum, il joue le rôle du client dans l'équipe Scrum, c'est à ses besoins que le produit doit répondre.
Concrètement, cela se traduit par une liste de tâches priorisées dont le Product Owner est le responsable : c'est ce qu'on appelle le Product Backlog. Chacune des entrées dans le Product Backlog est une histoire complétée par des critères d'acceptation.
Le Product Owner doit être présent tout au long du projet et dans chacun des sprints, sa présence est obligatoire pour la réunion de lancement de Sprint et il doit être présent si l'équipe à besoin de précisions sur une user story pendant le sprint.
Dans notre cas le client était déjà le responsable du produit et c'était déjà à lui de remplir et prioriser les histoires. Il nous fallait simplement ajuster son rôle dans l'équipe. Il est essentiel que le PO soit derrière l'équipe et participe activement au projet, un PO trop absent ou un PO qui ne maintient pas un Product Backlog peut-être un frein pour l'équipe.

Le Scrum Master est le garant de l'agilité dans l'équipe, c'est le facilitateur celui qui anime et veille à la bonne pratique de Scrum. Ce n'est pas un chef de projet, il doit être à l'écoute et s'effacer quand il faut pour que l'équipe puisse acquérir son autonomie, il doit aussi empêcher les éléments externes de polluer l'équipe dont il doit garantir la sérénité et les bons échanges avec le client.
Le Scrum Master doit guider l'équipe vers l'amélioration continue sans imposer, les qualités humaines et relationnelles d'un Scrum Master sont très importantes, car il doit favoriser l'échange et la confiance, il doit motiver et mener l'équipe vers les objectifs.

Tâches
Le Scrum Master prépare et anime l'ensemble des réunions Scrum :

- Sprint Planning - Lancement de Sprint ;
- Stand up - Mêlée quotidienne ;
- Sprint Review - Démonstration du Sprint ;
- rétrospective.

Il doit aussi intervenir pour lever les obstacles et gérer les conflits et enfin favoriser la transparence envers le management.

La team, ce sont les autres membres de l'équipe SCRUM : développeurs, testeurs, analystes ou encore concepteurs…
Chaque membre peut participer aux principes SCRUM. Au fil du temps, la présence et le rôle du SCRUM Master tant à disparaître, c'est à l'équipe de s'autogérer, dans l'idéal…

Nous utilisions Jira pour définir les tâches sur lesquelles nous allions travailler avant de nous mettre à SCRUM, on s'est servi de cette base comme backlog initial, il fallait reprioriser les tâches.
Le backlog de produit vit tout au long du projet, les users stories y sont inscrites avec un titre, une description, une priorité ; plus la prise en compte de cette fonctionnalité est proche et plus le niveau de granularité de sa description doit être affiné.

User Story what is it ?
Les users stories sont le standard quant à l'expression du besoin client dans SCRUM, où notre liste des fonctionnalités (backlog de produit) est une liste d'users stories.

Une User Story est en général présentée sous cette forme :

- « En tant qu'utilisateur je peux m'identifier afin d'administrer mon compte » ;
- « En tant que comptable je peux calculer le reste à payer ».

Elle permet de décrire en une ou deux phrases une fonctionnalité qui représente l'apport de la tâche du point de vue de l'utilisateur, elle est complétée par les critères d'acceptation qui sont sous cette forme :

- « Vérifier que l'utilisateur connecté est un comptable » ;
- « Vérifier que le comptable connecté est le gestionnaire du portefeuille du département concerné » ;
- « Vérifier que la somme du reste à payer ne fait pas dépasser le budget initial sinon lever une alerte ».

Une autre façon d'écrire des critères d'acceptation serait la suivante :

« Étant donné un utilisateur connecté ayant le rôle de comptable dans le département du projet ouvert, quand celui-ci calcule les prévisions des prochaines échéances, alors une alerte est levée si ces prévisions font dépasser le budget initial ».

Bien sûr, au préalable, il faut veiller à ce que les users stories ne soient pas de taille trop importante et ne pas hésiter à les découper en users stories de plus petites tailles.

Comment le représenter ?

Les items que forment un backlog de produit, sont une liste priorisée de users stories, on leur donne une importance (un chiffre compris entre 1 et 100), une description, une estimation et comment le démontrer (d'autres colonnes peuvent être utilisées).
Nous utilisons l'outil Jira, mais un simple fichier Excel peut amplement suffire. Il existe par ailleurs des outils permettant une gestion du backlog de produit et toutes les phases SCRUM (ex. : Ice Scrum).

Cette réunion est peut-être la réunion la plus importante du sprint, elle est la garante du bon déroulement du sprint et la présence de tous les membres de l'équipe est requise (Scrum Master, PO et l'équipe de développement). Pendant cette réunion, on produit le backlog de sprint. Une estimation des tâches permettra de déterminer ce que va comprendre notre sprint selon la vélocité, autrement dit notre indicateur de capacité de productivité, qui est calculé selon le résultat des sprints précédents (une moyenne).

Déroulement de cette réunion
Il est très important de contrôler la durée de cette réunion qui peut vite s'éterniser, la durée habituelle qu'on préconise est de 3 h. Je me suis inspiré de SCRUM et de KANBAN, pour établir le format de cette réunion, j'ai défini une liste des points à traiter pendant cette réunion sur des Post-it :

- introduction et rappels des principes (5 min) ; - définir le but du sprint (10 min) ; - description des stories candidates (30 min) ; - estimation des stories et découpage en stories plus petites si nécessaire (60 min) ; - découpage en tâches (30 min) ; - définir les critères d'acceptation (40 min) ; - conclusion (5 min).

Elles sont ensuite affichées sur un tableau avec les colonnes DEFINI - EN COURS - FINI.

La méthode que nous utilisons pour l'estimation est le planning poker : chaque membre estime une tâche en jours idéaux ou en points de complexité (nous avons fait le choix des jours idéaux). S'il y a des écarts importants, un débat suivi d'une réestimation permet souvent de se mettre d'accord.

Le problème des jours idéaux : cette notion est bien utile pour l'estimation, car plus facile à représenter que les points de complexité, mais attention à la confusion qu'elle peut provoquer en l'assimilant aux jours réels de réalisation.
Il faut que cette définition soit claire pour tout le monde, surtout pour le management.

Le problème des users stories pas assez détaillées : pour rendre plus explicite une user story, les critères d'acceptation peuvent éclaircir le besoin.
Le problème des users stories trop grosses : si une user story est de taille trop importante, il faut la découper en users stories plus petites.
Quel backlog pour la réunion : le backlog doit contenir toutes les users stories identifiées pour le projet, elles doivent être dans l'idéal décrites et priorisées avant la réunion de lancement, si tel n'est pas le cas il faut veiller au moins à avoir une bonne visibilité pour les deux prochains sprints.
Comment gérer les stories techniques : le plus important est de définir une ligne de conduite et de s'y tenir, nous avons choisi d'intégrer si nécessaire et s'il n'est pas possible de les inclure dans des users stories, les stories techniques dans le backlog de produit.
Comment gérer les bogues : là aussi le plus important est de définir la ligne de conduite, nous avons fait le choix d'une réserve liée à la résolution des bogues par sprint (environ 10 à 15 % de la capacité de production).

Une fois que nous avons défini le backlog de sprint, nous pouvons initialiser le tableau des tâches qui va nous permettre d'identifier le reste à faire du sprint, dont le Burndown chart de sprint constitue le meilleur indicateur de suivi.
Nous avons adopté un format semblable à celui préconisé dans « SCRUM et XP depuis les tranchées » :

Le tableau des tâches a été placé en plein milieu de la salle où est installée l'équipe de développement de sorte qu'il soit accessible et visible par tous.

Voici le nôtre :

Au départ je me suis inspiré du radiateur d'informations tiré du livre « SCRUM et XP depuis les tranchées » et au fur et à mesure on l'a customisé en rajoutant une partie « expression libre » en quelque sorte, dans laquelle on reporte les pratiques qu'on doit mettre en place et quelques recommandations.

Devant notre tableau des tâches, nous faisons quotidiennement une mini réunion de 15 min maximum avec un focus sur ce qu'on a fait la veille et ce qu'on fait aujourd'hui. Chacun peut parler des problèmes qu'il rencontre… Il est essentiel que tout le monde soit conscient que c'est la meilleure occasion de relever des problèmes et qu'il n'est pas obligatoire d'attendre la rétrospective pour les aborder.
L'heure de la mêlée a été fixée à 10 h par l'équipe.

Ci-dessous, les problématiques qu'on peut rencontrer en général pour cette réunion.

Et si on ne la faisait qu'un jour sur deux ou si on arrêtait de la faire ?
Pour éviter que ces questions se posent, il faut sensibiliser l'équipe à l'importance de cette réunion, la cohésion qu'elle apporte d'une part et la connaissance commune de l'avancement du sprint (problèmes rencontrés, etc.) d'autre part. Si tout de même elles sont amenées à apparaître, il faut essayer d'analyser l'origine et de modifier le format, par exemple, en mettant à jour le backlog de sprint pendant la mêlée (c'est le meilleur moment pour maintenir le radiateur d'informations).

Attention que ça ne soit pas une réunion de reporting ?
Un des symptômes classiques serait que l'équipe s'adresse au Scrum Master et non à l'équipe, il faut que le Scrum Master sache s'effacer pour laisser l'équipe s'autogérer.

Attention aux poulets :D

Leur présence est tolérée lors de la mêlée, mais ils ne doivent pas prendre la parole et c'est au Scrum Master d'y veiller.


Problèmes, mais quels problèmes ?
C'est difficile d'anticiper les problèmes et de faire réfléchir et faire parler l'équipe de ses problèmes avant qu'il soit trop tard. J'ai eu quelques difficultés à faire adopter qu'on privilégie la communication des problèmes lors de la mêlée, mais c'est essentiel pour pouvoir anticiper l'aide dont on va avoir besoin et donc le retard qu'on va avoir. Mais faire prendre conscience et indiquer les vertus de cette pratique commence à bénéficier à l'équipe.

Cette partie n'est pas une pratique de Scrum, mais comme la constitution de l'équipe s'est faite en même temps que l'intégration de la méthode Scrum à notre projet, je voulais parler de l'apport des pratiques agiles pour faciliter leurs intégrations.
La communication et les échanges sont d'une grande importance dans Scrum, ils facilitent donc le partage des connaissances techniques et fonctionnelles de l'application. Ce qui a contribué à la bonne intégration des nouveaux sont les réunions et la participation de toute l'équipe à celles-ci que ce soit la mêlée quotidienne, la réunion de lancement de sprint, la rétrospective ou encore du pair Programming, ou enfin la revue de code. On dit souvent dans SCRUM que les personnes et les interactions sont plus importantes que les processus et les outils… Le fait de donner la chance à une personne d'être autonome au sein de l'équipe peut la libérer et lui permettre de mieux s'exprimer, pour finalement augmenter la valeur ajoutée de chacun et constituer un collectif fort. Ce processus a montré dans notre équipe son intérêt dés l'arrivée des nouveaux.

La rétrospective de sprint est une autre réunion très importante de SCRUM : elle ne doit pas être négligée ou prise à la légère, elle est la garante de l'amélioration des processus et l'adhésion de l'équipe à la méthodologie.
Cette réunion est l'occasion que l'équipe s'exprime quant à ce qui ne marche pas, mais attention à ce que ça ne se transforme pas en lettre au père Noël. Le but de la réunion est de définir des axes d'améliorations et des directives concrètes qui doivent être mis en place, d'ailleurs la rétrospective suivante doit vérifier la considération de ces améliorations.
Il existe plusieurs exercices et indicateurs pour juger un sprint, sans oublier qu'une rétrospective de rétrospective peut être aussi pertinente.


En général sont présents à cette réunion l'équipe, le Scrum Master et le Product Owner.
Nous procédons d'habitude avec déjà un état des lieux de notre backlog de sprint, voire les tâches qu'on a terminées ou pas.
Par la suite nous essayons de recueillir le ressenti de chacun sur le sprint (une sorte de prise de température). Commence alors un échange sur ce qui a marché ou moins bien marché durant le sprint, on construit alors sur le mur une liste de Post-it que le Scrum Master va compléter avec des propos de chacun. Une fois que l'équipe n'a plus de nouvelles directives et actions à proposer commence alors une séance de vote sur les directives qui seront considérées pendant les sprints suivants, chaque personne dispose de quatre points qu'il distribue librement sur les différents Post-it (la première fois on l'a fait oralement chacun son tour, mais nous avons vite remarqué que les personnes suivantes pouvaient être influencées par les votes), donc chacun dans son coin distribue ces points ensuite le Scrum Mmaster relève les Post-it avec les poids les plus forts, l'équipe s'engage donc à respecter dorénavant ces directives.
Ceci n'étant qu'une façon de procéder, nous avons expérimenté plusieurs autres modèles tout en essayant de diversifier les exercices pour obtenir le meilleur ressenti et les meilleures pratiques d'amélioration (ex. : dérouler le film du sprint, ou encore la description de chaque personne par les autres points positifs / points négatifs…).

Pour clore la réunion, nous faisons une petite rétrospective de rétrospective, pour savoir ce qu'on peut améliorer dans les prochaines réunions et recueillir le ressenti sur une nouvelle pratique de rétrospective par exemple et pour finir on note la réunion (une note sur 5).


Pourquoi cette foutue review (démo) ?


Au départ, je me suis dit que l'intérêt dans un premier temps de la démo était limité puisqu’aucune autre équipe ni aucun responsable n'étaient encore venus assister à nos réunions. L'équipe connaissait déjà ce qui a été fait donc une démo n'était pas requise… Fier de mon raisonnement, je me suis permis au premier sprint de ne pas faire de review à sa fin et c'était bien le seul sprint sans, on s'est vite rendu compte qu'on avait beaucoup trop de tâches finies à 99 % et le dernier 1 % était bien trop néfaste pour le sous-estimer, alors oui la review est très importante et il ne faut pas minimiser l'effet positif qu'elle a sur l'équipe (de voir le fruit de leur travail et de le démontrer) et sur le projet (avoir un produit fini à 100 % à la fin du sprint).

Comment transformer l'essai ?

Parfois il est suffisant d'identifier un problème pour commencer à le résoudre… Mais souvent il faut déterminer des axes d'amélioration, qu'on traduit en tâches ou en choix de méthodes à mettre en place.
Un des constats est que parfois la traduction de la rétrospective en une amélioration n'est pas aisée et certains points votés ne sont toujours pas efficacement mis en place. Il n'est pas toujours évident d'identifier un cadre à la mise en place d'une amélioration, si une intervention n'est que ponctuelle, il est suffisant de la prendre en compte dans un sprint (ex. : notre serveur de sources n'est pas performant, il est suffisant d'avoir une tâche de migration dans un sprint pour l'améliorer…).
Donc pour éviter que des points d'amélioration qui ont été retenus ne soient délaissés par l'équipe, on a mis en place un système de responsable de point d'amélioration pour ça on mise sur le volontariat, cette personne doit proposer un cadre et des actions concrètes à mettre en place pour faciliter la vie de l'équipe tout en collaborant avec le reste de l'équipe.
Le meilleur moment pour le faire ? Entre la rétrospective et la réunion de lancement, il est intéressant de laisser un temps de battement pour faire ce qu'on n'a pu traiter pendant le sprint.

Il existe plusieurs types de Burndown chart, celui du produit ou encore de tous les sprints d'une release et celui du sprint courant, je vais parler surtout de celui qui représente le sprint courant.

Le Burndown est un graphique qui est mis à jour quotidiennement, il représente le reste à faire sur le sprint, on le calcule avec le poids de toutes les tâches non incluses dans la colonne « terminé ».
Il est possible que ça soit le Scrum Master qui le mette à jour, mais ça peut être intéressant que l'équipe y participe.

Voici notre meilleur démarrage de sprint :

- la ligne noire représente la progression idéale ;
- les points rouges sont notre progression réelle ;
- si on est au-dessus, c'est qu'on prend du retard et qu'il est indispensable de réagir en conséquence (voir avec le Product Owner pour supprimer des tâches) ;
- si on est en dessous c'est qu'on a mal estimé les tâches, ou peut être qu'on est en phase d'amélioration de la productivité (voir avec le Product Owner pour ajouter des tâches).

L'intégration continue (IC) permet d'améliorer et d'accélérer le processus d'intégration, elle nécessite l'utilisation d'un système de gestion de versions tel que CVS, Subversion ou encore GIT. On peut citer :

- Cruise Control qui est l'outil pionnier de l'IC, il reste aujourd'hui encore très présent ;
- Hudson qui est un outil très en vogue actuellement, la simplicité de sa configuration en fait un sacré client face à l'historique Cruise Control ;
- TeamCity est très simple à mettre en place, mais il est dit aussi qu'il est moins complet que ses concurrents.

IV-B-1-a. Notre choix▲

IV-B-1-b. Une amélioration continue▲

IV-B-2-a. Tests unitaires et TDD▲

Les tests unitaires sont incontournables dans une approche XP, garants de l'antirégression et de l'amélioration du code par refactoring, ils sont devenus fondamentaux quant aux bonnes pratiques de développement et la tendance dans les différentes communautés tend à le confirmer.


Nunit est devenu un standard dans la communauté .NET tout comme l'est Junit dans la communauté Java.


- Quelques recommandations pour les tests unitaires :

• vérifier que tous les tests sont toujours verts, la maintenance des tests unitaires est un vrai défi, il faut détecter et corriger au plus vite un test qui échoue (par intégration continue par exemple) ;
  
  
• un seul concept par test, le nom d'un test unitaire doit être explicite quant à ce qu'il teste (une ambiguïté de nom peut être causée par un cumul de concepts) ;
• un test doit être indépendant, il ne doit pas dépendre du résultat d'un autre test ;
  
• le test doit être autovalidant, son résultat doit être binaire, permettant d'identifier le bon fonctionnement ou pas ;
  
• il doit être reproductible, indépendamment du contexte/environnement ;
  
  
• si on ne teste pas la base de données (la couche d'accès aux données), nous devons être indépendants de celle-ci en utilisant par exemple les mocks (Rhino-mock a été notre choix) ;
  
  
• la qualité du code des tests unitaires est presque aussi importante que la qualité du code de production (du moins au niveau de la lisibilité). Des tests non maintenables et difficilement évolutifs peuvent devenir contre-productifs.
  

- Test Driven Development (TDD)

TDD est une pratique des tests unitaires poussés à l'extrême, elle recommande ni plus ni moins que de n'écrire aucune nouvelle ligne de code sans le test unitaire qui la couvre, donc finalement d'écrie le test unitaire avant d'écrire le code source d'un logiciel.


Voici les trois étapes essentielles :

• écrire un test unitaire qui échoue ;
  
• écrire le code qui permet de passer le test ;
  
• et enfin refactoriser le code.
  

Quand j'ai découvert la démarche TDD, je me suis dit que c'était un processus assez complexe à mettre en place et qu'il pouvait être très coûteux (souvent on entend les détracteurs dire que la plupart des tests écrits ne serviront jamais). Mais ceci est un mauvais argument, TDD doit être une des pratiques les plus structurantes des pratiques XP, d'une part c'est une des seules pratiques qui nous donne la certitude d'obtenir une bonne couverture du code par le test et de lutter contre le délaissement des tests unitaires en fin de développement à cause du manque de temps et d'autre part il donne la confiance nécessaire aux développeurs pour remanier le code et faire des modifications, même de dernière minute.

Un meilleur Design ?

La pratique du TDD chasse également le mauvais design. Comme il est particulièrement difficile de tester un mauvais code, l'écriture régulière des tests nous oblige à refactoriser notre code de façon à mieux l'isoler et mieux le tester.

Le TDD implique un changement de mentalité, le pratiquer demande une certaine rigueur. Au départ, c'est déroutant et il faut un certain temps pour l'assimiler. Souvent au départ le rejet est fort on ne se rend pas toujours compte de la difficulté. Il faut préparer son monde, car intégrer TDD dans son développement n'est pas toujours simple, multiples sont les premières interrogations : quels scénarios de tests choisir ? Comment tester des méthodes avec un accès à la base ? Comment tester l'IHM ? Mon code est il bien couvert ? Bref tellement de questions sans réponses évidentes. Mais une fois qu'on pratique le TDD on obtient rapidement un retour positif, il suffit de repasser dans un code testé et de le modifier pour comprendre l'intérêt de cette méthode (une simple exécution des tests permet de vérifier que le fonctionnement initial n'a pas été altéré).

IV-B-2-b. Test de recette et TDR▲

Voici une autre pratique XP qu'on essaie régulièrement d'utiliser. La première difficulté n'est pas de convaincre de son utilité, mais surtout de trouver sur quelles tâches il est opportun d'utiliser le développement en binôme. La plupart des gens sont d'accord quant à son apport dans une équipe, elle permet de partager les connaissances d'une équipe, d'augmenter la qualité des développements et aussi à l'équipe d'avoir une responsabilité commune du code.

Ce que nous essayons de faire est de définir sur certaines tâches complexes des parties en binôme, sans la rendre systématique nous voulons essayer d'utiliser régulièrement cette pratique dans notre équipe.

La revue de code permet une meilleure détection d'erreurs ou bogues cachés, elle a des avantages certains, mais il est aussi difficile de la mettre en place de manière systématique.
Les tests peuvent être partagés de la sorte : on écrit des tests de méthodes qu'on n'a pas forcément créées ou encore on peut les inclure dans des phases de Refactoring.

Le Refactoring est une pratique qui est implicitement présente dans d'autres comme TDD, la revue de code… C'est celle qui doit être systématiquement utilisée pour améliorer le code des méthodes qu'on développe ou qu'on modifie, elle est un gage de la viabilité de l'application, d'où l'importance d'avoir une grande couverture de code par le test étant donné la difficulté de remanier un code non couvert par crainte des régressions.
Cette notion est souvent difficile à mettre en place sur le code existant (Legacy code) à cause de la dette technique qu'on a accumulée, on a souvent peur de tout casser à cause d'un code n'ayant pas de couverture de tests ou encore de peur qu'on entre dans des modifications sans fin, alors on évite le problème, on s'engage dans des sentiers battus et la dette technique de notre code augmente sans cesse.
Mais plus on continue sur ce chemin, plus on rend notre code impropre, difficile à maintenir et peu évolutif… Le temps qu'on a évité de perdre nous sera décompté à chaque fois qu'on empruntera la voie de ce code. Il ne nous reste qu'à espérer de ne plus repasser par ce chemin !
La solution serait de prendre la bonne décision : celle du Refactoring. Il est parfois utile et intéressant d'interrompre les nouveaux développements pour refactoriser le code, mais ceci implique qu'on cesse d'apporter de la valeur, un choix difficile, mais parfois inéluctable.
Par ailleurs pour les nouveaux développements il faut refactoriser systématiquement (si vous pratiquez le TDD alors ça doit être déjà le cas), comme si votre premier code n'était qu'un brouillon et un brouillon est souvent très perfectible.
Alors il faut prendre le temps de le relire, de nettoyer les imperfections et de tendre vers du code propre.