Developpez.com

Plus de 2 000 forums
et jusqu'à 5 000 nouveaux messages par jour

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

Voici un parcours initiatique vers les méthodes agiles, l'apprentissage d'une quête de l'excellence et de l'amélioration continue, une série d'épreuves pour devenir meilleur … 7 commentaires Donner une note à l'article (5)

Article lu   fois.

Les deux auteurs

Profil Pro

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

The power of Scrum
The power of Scrum By Radwane HASSEN

Cet article n'est ni plus ni moins que ma feuille de route, voici comment j'ai commencé à m'intéresser à l'agilité et surtout comment j'ai procédé pour l'intégrer dans mes développements et dans mon équipe. Un jour peut être, je parlerai de la réussite ou de l'échec que fut cette expérience, mais le parcours initiatique est tellement enrichissant qu'il me fallait le partager.

Je vais décrire ce qui m'a intéressé en premier lieu dans les méthodes agiles, puisque on a d'une part une philosophie d'amélioration continue, qui permet l'implication de l'équipe, et ceci en opposition à une approche où une personne décide à la place de toutes les autres et d'autre part, on a la vision d'une méthode qui s'appuie sur des pratiques pour les utiliser et non pas les subir, ce qui m'a conduit à adopter cette démarche d'ouverture et d'évolution des processus qui ne sont pas gelés dans le temps mais qui évoluent avec les besoins du projet.
La philosophie en itération, découper un projet pour le construire et le voir évoluer, constitue une des bases de cette méthodologie, elle permet au client de voir et de participer à la construction du logiciel, tout en permettant de mieux estimer l'avancement des développements, de pouvoir à chaque fin d'itération faire une rétrospective, améliorer les processus et injecter des nouvelles pratiques pour les optimiser.
On se trouve enfin face à un processus vertueux d'amélioration avec des retours fréquents du client et un produit fini à chaque fin d'itération.

II. La révolution agile

II.A. Philosophie agile

II.A.1. Un client satisfait et des développeurs épanouis

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 au final 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.

II.A.2. Un processus d'amélioration continue

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.

II.B. Les méthodes agiles

Il existe une multitude de méthodes agiles. Ce document traitera essentiellement de Scrum et XP mais on pourrait citer :

Lean http://fr.wikipedia.org/wiki/Lean ;
Rup Rational Unifeted Process, méthode itérative proposée par IBM : http://en.wikipedia.org/wiki/RUP ;
FDD Feature Driven Development, une méthode orientée sur la valeur métier : http://www.featuredrivendevelopment.com/ ;
DSDM : http://fr.wikipedia.org/wiki/Dynamic_systems_development_method ;
Crystal Clear : http://fr.wikipedia.org/wiki/Crystal_clear.

Les méthodes agiles ont vu le jour à partir des années 90, la définition moderne est tirée du manifeste agile qui est l'œuvre de 17 experts reconnus du monde de développement : http://fr.wikipedia.org/wiki/Manifeste_agile.

III. SCRUM dans mon projet

III.A. Comment SCRUM est devenu ma voie

En recherchant à m'améliorer, je me suis mis à m'intéresser aux meilleures pratiques de développement existantes. J'ai commencé à regarder les Design Pattern et les outils facilitant le développement, le test et les livraisons dans un esprit Usine Logicielle en naviguant entre les différentes communautés ALT.NET, XP... Petit à petit ma sensibilité envers ces pratiques m'a poussé à mieux connaître ce type de méthodologie.
J'avais des envies, comme tout développeur, d'améliorer mon quotidien, de ne plus me plaindre du client qui nous met la pression, de pouvoir travailler sur la qualité et de maîtriser les éléments pour produire dans des meilleures conditions.

III.A-1. Le livre qui m'a sensibilisé

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 suffit 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

III.A-2. Une opportunité

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.

III.B. Introduire SCRUM dans un projet existant

III.B.1. Le soutien du client

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.

III.B.2. De la motivation à la mobilisation - SPRINT 0

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.

III.C. Les rôles

III.C.1. Product Owner

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.

III.C.2. Scrum Master

Le rôle du Scrum Master

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.

III.C.3. Team

La team, se 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...

III.D. Des pratiques et des outils

Vue globale Scrum

III.D.1. Backlog de produit

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 re-prioriser 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 quand à 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ées 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).

III.D.2. Réunion de lancement de SPRINT

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 mn) ; - définir le but du sprint (10 mn) ; - description des stories candidates (30 mn) ; - estimation des stories et découpage en stories plus petites si nécessaire (60mn) ; - découpage en tâches (30 mn) ; - définir les critères d'acceptation (40 mn) ; - conclusion (5 mn).

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 fais le choix des jours idéaux). S'il y a des écarts importants, un débat suivi d'une ré-estimation permettent 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).

III.D.3. Mise en place du tableau de tâches

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" :
Radiateur d'informations © Image tirée du livre "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 notre :

Notre radiateur d'informations

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.

III.D.4. Mêlée quotidienne

Devant notre tableau des tâches nous faisons quotidiennement une mini réunion de 15 mn 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 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

Restaurant Œufs au lard

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.


III.D-5. Intégration des nouveaux arrivants

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 au final 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.


III.D-6. Rétrospective de SPRINT

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, voir 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 quatres 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 dis que l'intérêt dans un premier temps de la démo était limité puisque aucune autre équipe ni aucun responsable n'était 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.

III-E. Artifacts

III-E-1. Burndown chart

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 : Notre meilleure 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).


IV. XP le complément idéal

IV.A. Un processus qualité

L'eXtreme Programming (XP) est une méthode complète (il serait dommage de la réduire à de simples pratiques d'ingénieries) qui répond aussi à des problématiques de planning et d'organisation. Cette pratique est totalement compatible avec ce que propose SCRUM et offre une recherche de l'excellence dans le développement.
Dans XP la quête de la qualité du code source est continuelle. On peut citer par exemple les tests unitaires en général et la démarche Test Driven Development (TDD) en particulier. Cette quête doit être mesurable et vérifiable à tout instant, ce que permet de faire l'intégration continue.
Mais l'XP pousse aussi à ce que nos développements répondent au mieux aux besoins fonctionnels du client. On peut citer la démarche TDR (Test Driven Requierements), qui pousse à ce qu'on exprime par des scénarios de tests les besoins du client de sorte qu'on puisse à tout moment vérifier que le logiciel prend l'orientation donnée par le client.



IV.B. Quelles pratiques mettre en place

IV.B-1. Intégration continue




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

Cette étape a été très importante, car c'est une base nécessaire au montage d'outils efficaces pour l'ensemble des pratiques d'automatisation.

Pour notre part, comme outil de gestion de versions nous utilisions au départ CVS, mais nous avons vite réfléchi à une alternative car cet outil est devenu vraiment archaïque. Réflexion faite, nous sommes passés depuis à SVN.
Pour l'IC proprement dite nous utilisons Cruise Control.NET avec un script Nant pour la build, nous l'avons choisi car c'est l'outil que l'équipe de développement connaît le mieux.
Mais dans le futur, il nous faudra étudier les autres outils pour voir s'il n'est pas préférable d'en changer.


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

L'intégration continue contribue grandement à la simplification du processus d'amélioration. Elle donne à l'équipe la liberté de changer et d'améliorer la qualité logicielle en garantissant la détection des problèmes aussitôt qu'ils apparaissent, à condition de commiter les changements régulièrement (plusieurs fois par jour).
Bien que les tests unitaires ne soient pas obligatoires quant à la mise en place de l'IC, ils sont très importants pour le processus d'amélioration car outre les problèmes d'intégration, les tests lancés par le serveur d'IC permettent d'anticiper les bogues et les régressions.


IV.B-2. Tests

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

TDD oblige de concevoir avant de coder

Les tests unitaires sont incontournables dans une approche XP, garants de l'anti-ré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 tendent à 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 auto-validant, 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 et 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 au final 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



Les tests unitaires permettent de vérifier qu'il n y a pas d'erreur dans le code mais ils ne vérifient aucunement que le code répond aux besoins du client, c'est à ce manquement que répond le test fonctionnel.


Fitnesse est l'outil le plus connu pour les tests fonctionnels.
Dans une approche BDD (Behavior Driven Developpement) il existe Greenpepper, qui permet de définir dans un wiki des tests sous la forme GIVEN WHEN THEN.
Il y a des outils comme Robot Framework qui permettent la mise en place de ce type de tests en ayant la possibilité de choisir l'outil d'écriture de tests (par exemple avec Selenium), permettant de bénéficier d'une approche TDR et en effectuant les tests d'interface.


- Test Driven Requierement (TDR)


TDR est un peu le TDD pour les tests fonctionnels : une spécification à travers des tests de recette. Avoir la possibilité de tester la bonne compréhension des besoins à travers des tests automatisés est une approche qui me paraît très intéressante, j'ai pu échanger et lire sur ce sujet et mon intérêt pour cette approche c'est développé progressivement. Nous mettons actuellement en place les critères d'acceptation sous le format "Étant donné - Quand - Alors (GIVEN WHEN THEN)" : des scénarios qu'on peut utiliser dans une approche TDR avec le formalisme BDD. Actuellement, nous sommes en train d'étudier Robot Framework et la possibilité de l'intégrer dans notre projet.

IV.B-3. Pair programming

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 quand à 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.

IV.B-4. Revue de code



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.

IV.B-5. 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é, 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.

V. Les commandements



Il est intéressant d'avoir une liste de bonnes pratiques pour l'équipe, qui mélange des pratiques de management et des pratiques d'ingénierie. Voici une liste d'exemples non exhaustive :

- vous pouvez violer n'importe laquelle de ces règles, mais assurez-vous qu'il y a une bonne raison et documentez-là ;

- tous les matins, nos équipes de développement, feront un point qu'on nommera selon la méthode SCRUM, "mêlée quotidienne", dans laquelle on fera un point sur l'état de notre SPRINT (itération) à travers le backlog de sprint, avec un focus sur la ou les tâches faites le jour précédent, la ou les tâches du jour et les éventuels problèmes rencontrés ;

- le backlog de sprint est une liste de tâches sélectionnées pour le SPRINT ;

- le sprint est défini lors de la réunion de lancement de sprint, qui se déroule entre la date de fin du sprint précédent (après une réunion de Rétrospective de sprint) et avant la date du nouveau sprint. Le support de cette réunion est le backlog de produit. Seront présents dans cette réunion, l'équipe de développement, le Scrum master et le chef de produit ;

- le backlog est une liste d'histoires (tâches) priorisées définie par le chef de produit (AMOA - MOA dans notre cas).

- un sprint a une durée définie au préalable, à la fin de celle-ci seront livrées toutes les histoires (tâches) terminées - Comprendre fin du développement, testées et validées en recette (done-done) ;

- utilisez les conventions de codage de Microsoft par défaut comme, par exemple, vérifier votre code avec FxCop ;

- nos développements doivent être en amélioration continue, la qualité est la première priorité. Refactoring, Test Unitaire pour tout nouveau développement et à défaut jeux de tests pour toute méthode non automatisable, Test de Recette ;

- ne jamais, jamais, jamais, attraper des exceptions sans les relancer ou enregistrer la pile d'appel dans un journal ;

- évitez les abréviations, mais vous pouvez utiliser les sigles bien connus comme ADO ;

- les méthodes qui retournent des collections ou des tableaux ne devraient pas retourner null. Retournez des collections et des tableaux vides à la place de null ;

- les méthodes et les classes doivent être courtes et doivent avoir des noms significatifs ;

VI. Conclusion



En quoi les méthodes agiles ont-elles amélioré mon quotidien ? C'est à cette question que je vais essayer de répondre dans ma petite conclusion.

D'abord elles m'ont permis d'instaurer en tant que Scrum Master, une certaine rigueur qu'apporte Scrum et en tant que développeur un certain plaisir à améliorer mon quotidien et la qualité de mes développements, une sorte de quête du meilleur. Et puis d'être responsable et autonome sur mes choix quant à mes tâches et mes choix techniques, et ensuite une reconnaissance des efforts dans la réussite d'un sprint et d'accepter l'échec pour mieux rebondir et m'améliorer. J'ai parlé au départ d'une philosophie, les méthodes agiles font accepter le changement et l'organise, on cherche toujours ce qui peut être mieux fait et ce que la communauté propose de nouveau, pour moi cela était une revisite de ce que peut être mon quotidien, non pas être dirigé par un chef de projet, ni encore subir les assauts d'un client, ni me plaindre d'un code d'une qualité déplorable. La réponse est celle de l'équipe dans laquelle le client est partie prenante, où il est mieux compris et comprend mieux. On reconnaît qu'on est imparfait et on l'assume, écrire un bon code en une fois est une utopie, il est nécessaire d'améliorer l'essai où la première version est comme un brouillon, feriez-vous les mêmes erreurs si on vous demandait de refaire le projet ? Certainement pas, alors identifier un problème, c'est déjà une première étape vers l'amélioration et la seconde est d'essayer de le corriger, dans un mode en itérations (Sprint), chaque fin de Sprint constitue une chance unique de revoir ce qui a été fait et de pouvoir rectifier le titre.

Avant d'avoir introduit Scrum et XP dans le projet, on a toujours eu envie d'améliorer plein de choses, on a eu souvent ce genre de phrase "cela aurait été génial d'avoir des tests automatisés", "Il faut qu'on améliore le processus de livraisons"...
Et avant d'avoir une approche totalement agile, les modifications étaient difficilement visibles, mais depuis nous avons mis l'intégration continue, des tests unitaires et automatisés, la génération de package de livraisons et il nous reste encore énormément de choses à faire.

Et vous qu'attendez vous pour devenir Agile ?

VII. Bibliographie

VIII. Remerciements

Je tiens à remercier Blade159 et jacques_jean pour leur relecture, Maximilian et Ricky81 pour leur soutien et à tous pour les idées qui ont permis l'amélioration de cet article.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2009 Radwane HASSEN. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.