Lecture de : Kanban pour l’IT

kanban

Kanban pour l’IT est un livre écrit par Laurent Morisseau. Il nous explique comment la méthode Kanban va nous permettre d’améliorer nos processus de développement. Dans une première partie, Laurent nous explique les concepts de Kanban. Dans la seconde partie du livre, Laurent met un place une équipe et une société fictive pour avoir un fil conducteur sur la mise en place de la méthode Kanban. On y voit les difficultés rencontrées ainsi que les bonnes pratiques a adopté. Cela permet également de rentrer dans le noyau de la méthode Kanban.

 

Introduction

Avant de parler des concepts de la méthode Kanban, je vais, comme Laurent l’a fait dans son livre, définir les mots de vocabulaire que je vais utilisé.

  • Kanban : Avec un K majuscule est utilisé pour désigner la méthode Kanban.
  • kanban : Avec un k minuscule désigne les outils de visualisation utilisé de la méthode Kanban.

Les concepts de Kanban

Objectif du Kanban

L’objectif de Kanban de réduire voir éliminer les situations de surcharge de travail et de gérer les flux de demandes variables. C’est donc un moyen d’équilibrer notre chaîne de processus pour l’accomplissement d’un projet. En d’autres mots, Kanban à pour objectif de trouver un équilibre entre la demande et la capacité d’un système kanban.

Capacité d’un système Kanban

La capacité d’un système Kanban est constitué de 3 indicateurs:

  1. Le débit du système : c’est le nombre moyen d’éléments produits par unité de temps(exemple : 10 éléments par semaine).
  2. le temps de traversé : c’est le temps moyen d’un élément passe dans le processus de réalisation(de la demande à la livraison).
  3. la performance à la date d’échéance : c’est le pourcentage d’éléments livrés à la date d’échéance par rapport au nombre total d’éléments.

Les fondations

Kanban repose sur trois piliers :

  1. Commencer par ce que vous faîtes maintenant
  2. Respecter le processus actuel, les rôles et responsabilités
  3. S’engager à changer de manière incrémentale et évolutive

Le premier pilier s’explique par le fait qu’un changement trop rapide entraîne de la résistance de la part  des membres de l’équipe. En contrepartie, Kanban peut ne pas donner des résultats immédiats. Le deuxième pilier signifie que Kanban s’applique dans un processus déjà existant(cycle en V, Scrum…). Enfin, le troisième pilier préconise l’évolution par petit pas, l’objectif étant de s’approprier une culture d’amélioration continue.

Les 5 pratiques

  1. Visualiser : La visualisation est une pratique simple mais essentielle. Elle se met en oeuvre par différents outils comme le tableau kanban ou les cartes kanban. Elle permet à tout l’équipe de visualiser l’état du projet.
  2. Limiter le travail en cours : Pour chaque activité de réalisation du projet, on va limiter le nombre d’éléments de travail. Ces limites doivent être équilibrée afin d’avoir un flux de travail fluide. Dans la pratique , on passera d’un système de réalisation à flux poussé à un système de réalisation à flux tiré.
  3. Gérer le flux de travail : Il faut être en capacité de pouvoir gérer les éléments en manipulant les indicateurs de capacité du système.
  4. Rendre explicites les règles de gestion du processus : Nos différentes activités sont soumis à un ensemble de règles et de caractéristiques. Il faut rendre explicites ces règles afin que toute l’équipe les visualise, les comprenne et les améliore.
  5. S’améliorer de manière collaborative : Les blocages mise en évidence par les différentes pratiques Kanban permettent d’augmenter les discussions entre les membres de l’équipe. Cela contribue au commencement de la démarche d’amélioration. Cette démarche d’amélioration s’appuie alors sur des modèles externes(Lean, théorie des contraintes, théorie des files d’attente, etc..) visant à comprendre et résoudre ces blocages.

 

Un développement en flux tiré

Afin d’appliquer la méthode Kanban, il faut pour cela mettre en place un flux de travail. Laurent suit les deux axiomes suivant définis par Corey Ladas pour définir le développement en flux :

  1. Il est possible de diviser le travail en petits incréments apportant de la valeur et pouvant être planifiés indépendamment les uns des autres.
  2. Il est possible de développer n’importe quel incrément apportant de la valeur dans un flux continu, des exigences au déploiement en production. Autrement dit, toutes les activités liées à un incrément peuvent être réalisées et s’enchaîner les unes après les autres.

Une fois  cette étape effectué, la seconde consiste en avoir un flux tiré. Contrairement à un flux poussé qui consiste à produire un travail sur la base de prédictions, le flux tiré consiste à ne travailler que sur le remplacement de ce qui a été consommé.

Le modèle PDSA

Kanban s’appuie également sur le modèle PDSA(Plan, Do, Study, Act) qui est une variante du modèle PDCA(Plan, Do, Check, Act).

  • La phase plan(Concevoir) sert à définir le modèle et les hypothèses que l’on souhaite mettre en place.
  • La phase do(Mettre en oeuvre) est la réalisation du modèle.
  • La phase Study(Etudier) est la phase d’étude du système, on s’appuie sur les résultats obtenus ainsi que sur différents modèles de pensée : théorie des files d’attentes, théorie des contraintes, maîtrise des statistiques et gaspillage du Lean.
  • La phase Act(Améliorer) utilise la phase d’étude pour améliorer son système. Puis repars sur un nouveau cycle PDSA.

Schéma : 

Kanban

Conclusion

L’article ne résume que les concepts de Kanban, c’est à dire la première partie du livre. Dans la suite de celui-ci, Laurent Morisseau nous décrit le noyau de la méthode Kanban au travers du suivis d’une équipe dans la mise en place de la méthode. On aborde plus profondément les concepts en effectuant un cycle PDSA. Il y a plusieurs choses à retenir :

  • Le Kanban a pour but d’améliorer notre processus en se fixant un objectif sur un des indicateurs du système. Faire du Kanban sans objectif n’est pas la bonne approche.
  • Le Kanban ne résout pas les problèmes rencontrés, il se charge simplement de les mettre en évidence
  • Le Kanban n’est pas une méthode agile, elle peut très bien s’appliquer dans un contexte de cycle en V. Cependant, il est vrai qu’elle amène dans sa pratique à plus d’agilité. L’utilisation du Kanban dans un contexte Scrum est appelé ScrumBan.

Lecture de : Scrum

scrum

Je viens de lire le livre Scrum: Le guide pratique de la méthode agile la plus populaire. Ecrit par Claude Aubry, celui-ci nous explique les rouages de la méthode Scrum. Le livre se découpe en 3 parties : les pratiques de Scrum, les pratiques complémentaires et la mise en place de Scrum.

Introduction

Un peu d’histoire

Jeff Sutherland a créé le processus Scrum en 1993. Il a tiré le terme « Scrum » d’une analogie mise en avant dans une étude réalisée en 1986 par Takeuchi et Nonaka, publiée dans le Harvard Business Review. Dans cette étude, Takeuchi et Nonaka comparaient les équipes à haut rendement et inter-fonctionnelles à la mêlée utilisés par les équipes de rugby. Ken Schwaber formalisa ce processus pour l’industrie du logiciel du monde entier dans le premier document publié sur Scrum au OOPSLA de 1995. Depuis lors, Scrum est devenu l’une des principales méthodes de développement agile, utilisé par les 500 plus grandes entreprises mondiales. source

Une méthode Agile

Scrum s’inscrit dans les méthodes agiles parce qu’elle respecte le manifeste Agile suivant  :

L’importance est donnée:

  • aux individus et aux interactions plus qu’aux processus et aux outils
  • à des logiciels immédiatement disponibles plus qu’à une documentation exhaustive
  • à la collaboration avec le client plus qu’à la négociation contractuelle
  • à la réactivité face au changement plus qu’au respect d’un plan

Les pratiques de Scrum

Les rôles

Le Product Owner

Le product Owner est responsable du produit.

  • Il donne la vision du produit, c’est à dire l’objectif du produit, la position du produit ainsi que la liste des fonctionnalités essentielles. Il doit s’assurer que tout les membres du projets partagent cette vision.
  • Il définit le contenu du produit :  il est responsable du backlog de produit et définit les priorités de développement. Il s’implique donc dans les tests d’acceptations.
  • Il planifie la vie du produit : il constitue les objectifs d’une release et prend les décisions sur son contenu ainsi que sur la date de mise en production.

L’objectif du Product Owner (PO) est de s’assurer que le produit apporte de la valeur aux utilisateurs.

 

Le ScrumMaster

Le ScrumMaster est responsable du déroulement de la méthode Scrum.

  • Il veille à la mise en application de Scrum(en animant les différents cérémonials par exemple).
  • Il encourage l’équipe à apprendre et à progresser dans les pratiques d’ingénierie.
  • Il aide à éliminer les obstacles freinant l’avancement du sprint.
  • Il incite l’équipe à être autonome et responsable.

L’objectif du ScrumMaster est que l’équipe arrive à un état où elle n’est plus besoin de lui.

 

L’équipe auto-organisée

L’équipe est responsable de la réalisation du produit. Le PO et le ScrumMaster font partis de cette équipe.

  • Elle définit la façon dont elle organise ses travaux sans autorité de la part du ScrumMaster ou du ProductOwner.
  • Chaque membre apporte son expertise, partage sa connaissance afin de créer une équipe multifonctionnelle.
  • Elle veille à posséder toutes les compétences nécessaires.

L’objectif de l’équipe est de réaliser un produit de qualité dans l’environnement de travail qu’elle a défini.

 

Les artefacts

Les artefacts sont les éléments physiques dont l’équipe se sert pour développer le produit.

Backlog de produit  : Il contient la liste des fonctionnalités des produits détaillées en stories. Ces fonctionnalités sont priorisées.

Plan de release : Il présente les sprints à venir ainsi que leurs contenus.Il est orienté vers le client(ils doivent pouvoir le comprendre) et est mise à jour régulièrement.

Plan de sprint : Il présente la liste des tâches à effectuer. Ces tâches sont définis, associé à une story et estimé (en heures ou en “point”, c’est optionnel).

Burndown chart de sprint : C’est un graphique représentant ce qu’il reste à faire dans le sprint. Il sert à montrer l’avancement réel du sprint et permet l’ajustement du plan de sprint.

Burndown char de release : C’est un graphique représentant ce qu’il reste à faire dans la release. Il sert à montrer l’avancement réel et apporte une aide à l’estimation de l’état du produit à la fin de la release. Il permet d’ajuster le plan de release.

Les cérémonials

Scrum est une méthode Agile itérative. Certaines étapes du produit reviennent donc régulièrement :

Release : C’est une version du produit réalisée par une série de 3-4 sprint.

Sprint : C’est une itération d’une durée de 2 à 4 semaines dans laquelle sont réalisées des tâches.

Planification de release : Processus permettant de définir le contenu d’une release (ou version). Elle est composée de plusieurs réunions étalées sur la réalisation de la release. Toute l’équipe y participe. Le PO doit au préalable établir et priorisé les différentes fonctionnalités.

Planification de sprint : Processsus permettant de définir les tâches(liées à des stories) prise dans le backlog qui vont être effectué pendant le sprint. Toute l’équipe y participe.

Scrum quotidien : C’est une réunion quotidienne(appelé scrum), elle appartient à l’équipe et doit lui permettre de s’auto-organiser. Ce n’est pas un compte rendu fait au ScrumMaster ou au ProductOwner. Lors de cette réunion, chaque membre de l’équipe doit répondre à ces trois questions :

  1. Qu’ai je fais depuis le dernier scrum ?
  2. Que vais-je faire jusqu’au prochain scrum?
  3. Quels sont les obstacles qui me freinent dans mon travail?

Ces trois questions ont pour objectif de présenter ce qui a été fait, prévoir ce qui va être fait et identifier les obstacles afin d’actualiser le plan de sprint ainsi que le burndown chart de sprint. Il ne s’agit en aucun cas d’évaluer les membres de l’équipe!

Revue de sprint : C’est une démonstration du produit en cours de développement faite à toutes les personnes concernées ou intéressées par le produit. Elle a lieu le dernier jour du sprint. La démonstration ne contient que les fonctionnalités finis du produit. Son objectif est de collecter un feedback sur le produit, d’actualiser le backlog de produit(par des évolutions ou des corrections) et d’ajuster le plan de release.

Rétrospective : C’est la réunion qui clôture le sprint. C’est un moment de réflexion collective qui a pour but :

  • de capitaliser sur les pratiques qui ont marché.
  • d’éviter de refaire les mêmes erreurs.
  • partager différents points de vue.
  • permettre au processus de s’adapter aux nouvelles avancées dans la technologie utilisée pour développer.

Le résultat de cette rétrospective est un regroupement d’actions divisé en 4 catégories :

  1. celles dirigées vers les personnes.
  2. celles sur leur façon d’appliquer les pratiques Scrum.
  3. celles orientées outils à installer ou à adapter.
  4. celles axées sur l’amélioration de la qualité.

Signification de fini : La définition de fini doit être définis au départ du projet (et actualisé si besoin). Elle permet de motiver l’équipe, diminuer les ambiguïtés et obtenir plus de performance et de transparence. Il y a trois définitions de fini : Une pour une story, une autre pour un sprint et une dernière pour une release.

 

Schéma globale de Scrum :

VueGlobaleScrum

Les pratiques complémentaires

Claude Aubry nous explique dans cette partie des pratiques complémentaires à Scrum permettant de faciliter son utilisation comme par exemple la création du backlog ou bien la mise en place d’indicateurs. Ces pratiques concerne le PO, le ScrumMaster et l’équipe.

De la vision aux stories

Avant de devenir une série de stories, le produit est avant tout une vision. Celle-ci possède un but, c’est à dire l’objectif du produit. Elle prend en compte les besoins des utilisateurs et développe une présentation de la solution à ces besoins tout en prenant compte des contraintes imposées au développement. Il est bien sûr possible d’avoir plusieurs visions selon la dimension du projet. On peut avoir une vision globale du produit puis des visions par release(ou version).

On découpe cette vision en une liste de fonctionnalités (ou features). Ces fonctionnalités sont des services fourni par le produit, observable de l’extérieur, qui répondent à un besoin et dont la description se situe à un niveau tel que toutes les parties prenantes du projet comprennent facilement ce dont il s’agit.

Une fois cette liste de fonctionnalités obtenu, elle est décomposée en “stories”. Ces stories possèdent un nom, une description, un identifiant(la fonctionnalité à laquelle elle appartienne). Il existe 3 type de stories :

  • User story : Elle définit un comportement visible pour les utilisateurs et leur apporte de la valeur ou de l’utilité.
  • Story technique : Elle définit un comportement invisible pour les utilisateurs mais visible par l’équipe de développement. Elle est nécessaire au développement de certaines user stories.
  • Défaut : Elle définit un comportement  qui enlève de la valeur au produit. Elles sont souvent créées lors des feedbacks.

De la story aux tests d’acceptation

Une fois une story définis, il est important de lui définir des tests d’acceptations. Ces tests permettent de savoir précisément lorsque la story est finis et d’être sûr de n’avoir rien oublié. Le Product Owner participe donc grandement à la création de ces tests. Le nombre de ces tests doit être inférieur à 8. Dans le cas contraire, la story est sans doute trop grosse et le Product Owner doit avoir la possibilité de la décomposer.

Lorsque plusieurs stories sont liées, on met alors un scénario en place qui permet d’effectuer les tests dans un certains ordre.

L’équipe doit être capable de refuser une story lors de la plannification de sprint lorsque celle-ci ne possède pas les conditions requises pour déterminer son état de finition.

Estimations, mesures et indicateurs

L’indicateur principal de la méthode Scrum est le burndown Chart. Celui-ci est représenté grâce à la récupération de mesure et permet de faire des estimations. Dans cette partie, Claude Aubry nous liste des mesures qu’ils séparent en 4 catégories :

  1. Les mesures quotidiennes
    • Le nombre d’heures restant pour finir les  tâches du sprint
    • Le nombre de tâches restant à finir
    • etc…
  2. Les mesures à chaque sprint
    • La capacité estimé au début du sprint
    • La vélocité réelle du sprint
    • L’utilité ajoutée pendant le sprint
    • etc…
  3. Les mesures à chaque release
    • identique à celle du sprint mais à l’échelle d’une release
  4. Autres
    • Nombre d’obstacles rencontrés et non éliminés
    • Ressource consommé
    • etc…

Ces mesures  permettent de créer des indicateurs(sous forme graphique par exemple) et ainsi pouvoir estimer la suite du projet. Ces estimations ne sont pas des engagements et peuvent être actualisées!

Scrum dans l’ingénierie du logiciel : Pratiques d’eXtreme Programming

Scrum est une méthode Agile pouvant s’adapter à différents domaines. Dans le cas de l’ingénierie du logiciel, Claude Aubry se tourne vers des pratiques de la méthode agile eXtreme Programming. Je vous invite à lire ce billet pour plus d’information : lien

Mise en place de Scrum

Dans cette dernière partie, Claude Aubry sort de l’aspect pratique de Scrum et s’attarde sur sa mise en place.

Adapter Scrum au contexte

Scrum n’est pas une méthode qu’il faut appliquer bêtement. Il faut la voir comme un cadre. A ce cadre vient s’appliquer des pratiques liées à l’ingénierie(pratiques d’eXtreme Programming pour l’ingénierie lié au développement du logiciel par exemple).

Claude Aubry nous explique également qu’il faut savoir adapter Scrum et revenir dessus à chaque rétrospective. Afin de bien cerner ce contexte, Il faut répondre à ces questions :

  • A quel niveau d’innovation se situe l’entreprise
  • Dans quel culture? N’oubliez pas le côté humain d’un projet!
  • Quel est le domaine métier?
  • Quel niveau de maturité? A-t-on beaucoup d’expérience dans le domaine?

Le contexte peut être partager en 4 catégories :

  1. La nature du produit
  2. L’état du logiciel
  3. L’équipe
  4. L’organisation de développement

Pour résumé, Scrum possède deux axes sur lesquelles repose son application : la sélection des pratiques liées au domaine métier et le contexte.

La transition à Scrum

La transition à Scrum ne doit pas être brutale, elle doit être réfléchis. Cette transition constitue en lui même un projet dans lequel sera exécuté un projet pilote. L’équipe du projet pilote peut être différente de l’équipe du projet de transition. L’équipe du projet de transition doit être un support pour l’équipe du projet pilote.

Claude Aubry définit un cycle de 5 étapes :

  1. Evaluer le contexte : Il s’agit d’avoir d’avoir un vision claire de la raison du changement.
  2. Préparer l’application de Scrum : Choisir le projet pilote, adapter les pratiques. Créer l’équipe pilote et la former à Scrum (il existe plusieurs méthodes).
  3. Exécuter Scrum sur un projet pilote : Le projet de transition et le projet pilote se déroule simultanément. Les phases de rétrospective sont nombreuses et importantes.
  4. Diffuser dans l’organisation : L’objectif du projet de transition et de faire passer toute l’organisation de l’entreprise à Scrum.
  5. Evaluer le niveau atteint : A chaque fin de projet, on évalue le niveau atteint et on ajuste.

Scrum avec un outil

Dans cette partie, Claude Aubry nous présente différents outils utilisés pour Scrum. Il nous présente également iceScrum dont il est Product Owner.

Scrum à grande échelle

Scrum s’applique à des équipes constituées de 5 à 10 personnes. Dans le cas de la création d’une très grosse application, il est possible d’avoir plusieurs équipes. Il est important alors de bien constituer le backlog. Pour cela, il est possible de constituer des scrums de scrum. C’est à dire que chaque équipe scrum possèdera son backlog. Un représentant de chaque équipe est choisi pour créer une autre équipe Scrum. Cette équipe a pour but d’avoir une vision globale du projet. Elle possède son propre backlog. En décomposant celui-ci, les features obtenues alimentent les backlogs des équipes “normales”.

Il faut cependant bien garder à l’esprit que la communication est la clé de la réussite d’un projet. Par conséquent, plus l’équipe sera grosse et éparpillé géographiquement, plus il sera difficile de maintenir le projet dans un environnement stable. Il est alors possible d’utiliser la méthode Kanban pour améliorer sa chaîne de processus.

Scrum en France

Dans cette dernière partie, Claude Aubry fais un état de lieu de la méthode Scrum en France.

 

Conclusion 

Ce qu’il faut retenir est que la méthode Scrum est un cadre qui repose sur un contexte et un domaine métier. Ce cadre possède des pratiques à respecter qu’il faut enrichir par des pratiques lié au domaine métier. Ce billet n’est qu’un résumé de ces pratiques. Pour plus d’information je vous conseille vivement la lecture de ce livre qui vous expliquera ces pratiques en détails ainsi que toute la dimension humaine lié à un projet Scrum. Cette dimension est malheureusement difficile à exprimé en un simple article de blog :  Scrum n’est en aucun cas une méthode permettant d’évaluer les membres d’une organisation.

 

 

 

 

Lecture de : Gestion de Projet eXtreme Programming

 

Je viens de lire le livre “Gestion de projet, eXtreme Programming” qui décrit la méthode Agile du même nom. Ce livre se découpe en 3 parties.

Les pratiques de l’Extreme Programming

Les valeurs de bases d’eXtreme Programming

Pour que les pratiques de l’eXtreme Programming fonctionne, il est nécessaire de respecter 4 valeurs.

  • La communication pour une meilleure visibilité

La communication est en effet un point indispensable dans une équipe XP. Lorsqu’on parle de communication, il s’agit surtout de communication directe (orale). Elle favorise en effet le transfert de compétence, la détection de problème, l’entraide au sein de l’équipe et la confiance entre le client et l’entreprise.

  • La simplicité comme garantie de productivité

Côté client, c’est à lui de définir ce dont il a réellement besoin et d’y mettre des priorités. Côté développeur,  il est inutile de s’occuper de cas qui n’arriveront peut-être jamais. C’est en appliquant cette simplicité que la rapidité de développement et la possibilité de changement seront favorisées.

  • Le feedback comme outil de réduction du risque

Le feedback est au coeur de la méthode eXtreme Programming. En effet, elle est gage de qualité. On retrouve la notion de feedback à différentes échelles du projet : des tests unitaires au tests de recettes jusqu’à la structure itérative de la méthode.

  • Le courage de prendre les bonnes décisions

Le courage est une qualité qu’il faut pour pouvoir respecter les trois précédentes valeurs. Il faut du courage pour se focaliser uniquement sur ce dont on a besoin, de maintenir une transparence en communiquant sur nos difficultés(et nos atouts) et admettre les différents feedbacks comme par exemple devoir jeter une partie de code qu’on aurait créé et qui ne conviendrait pas.

Les règles d’eXtreme Programming

Il existe 13 régles si on veut respecter l’eXtreme Programming. Celles-ci se découpe en 3 catégories :

Les pratiques de programmation

  • Une conception simple (simple design) : inutile d’inventer des mécanismes génériques, le “péché mignon” du développeur, si ce n’est pas nécessaire. Il faut toujours implémenter la solution la plus simple.
  • Le remaniement (refactoring) : Il est important que les développeurs reviennent  sur leur code pour le rendre plus simple, enlever les parties inutilisées.
  • Développement piloté par les tests unitaires(Test Driven Developpement) : Le développeur écrit des tests unitaires avant d’écrire le code. Cette pratique lui permet de bien structurer dans son esprit ce qu’il veut faire ainsi que d’éviter le phénomène de régression.
  • Test de recette (acceptance test) : Ces tests sont créés par le client. Il lui permet de définir les objectifs que les développeurs doivent atteindre. Si le test passe, alors la fonctionnalité est validée tel que le client la veut.

Les pratiques de collaboration

  • Programmation en binôme (pair programming) : Les développeurs doivent développer en binôme (deux par ordinateur). Cela permet une relecture en temps réel du code. Les binômes sont changés régulièrement
  • Responsabilité collective du code (collective code ownership : Les développeurs travaillent en binôme et changent régulièrement, ainsi, chacun travaille sur chaque partie de l’application. Chacun à le devoir d’améliorer le code même s’il n’en est pas l’auteur.
  • Règle de codage (coding standards) : Des règles de codage sont décidées au début du projet. Chacun doit s’y tenir afin de garantir la cohérence du code et ainsi faciliter la modification de celui-ci par n’importe quel développeur.
  • Métaphore : Le système ainsi que les sous-systèmes doivent être décrit par des métaphores ceci dans le but de faciliter la communication.
  • Intégration continue (continuous integrated) : Les développeurs doivent synchroniser le plus souvent possible leur travail afin de faciliter le processus d’intégration.

Les pratiques de gestion de projet

  • Livraisons fréquentes (fréquent releases) : Le logiciel doit être livré régulièrement. Cela permet au client ainsi qu’aux développeurs de s’assurer que le produit correspond bien aux attentes.
  • Planification itérative (planning game) : Lors d’une réunion dédiée, le planning décrivant l’itération en cours est décidé par le client et l’équipe de développement.
  • Client sur site (on-site customer) : Le client doit être intégré à l’équipe, la communication est ainsi optimale. Le client au sens eXtreme Programming n’est pas forcément le client au sens commun. Le client, au sens XP, est celui qui prend les décisions et qui est capable de répondre aux questions des développeurs.
  • Rythme durable (sustainable pace) : L’équipe de développement doit avoir un rythme qui peut être conserver tout le long du projet. Ce rythme doit favoriser le travail de qualité. Les périodes de “rush” sont à éviter.

Les rôles eXtreme Programming

EXtreme Programming définit six rôles principaux dans un projet IT :

  • Le programmeur : c’est le développeur. Dans son rôle XP, il est responsabilisé. En effet, sa proximité avec le client ainsi que le respect des différentes règles(dont la responsabilité collective du code) responsabilise et revalorise le métier de développeur.
  • Le client : Le client au sens XP est celui qui est présent au sein de l’équipe de développement, qui répond aux questions des développeurs et définit la priorité dans laquelle doit être implémenter les fonctionnalités. Il a le devoir de fournir un feedback aux développeurs ainsi que des tests de recette.
  • Le testeur :  le testeur est le bras droit du client. C’est à lui que revient la tâche d’installer les outils nécessaires à l’intégration continus, des tests de recettes et unitaires. Il est également là pour aider le client à créer les test de recette.
  • Le tracker :  Le tracker est là pour suivre l’avancement des tâches au sein d’une itération. Son rôle est donc de détecter au plus vite les éventuelles difficultés qui surviennent afin de les résoudre le plus vite possible. Ce rôle doit être évité d’être tenu par un membre hiérarchique supérieur afin d’empêcher un sentiment de surveillance.
  • Le manager : C’est le supérieur hiérarchique des développeurs. Il est là pour demander des comptes(à son équipe XP comme au client) et fournir les moyens humains et matériels pour l’avancement du projet. Il ne participe qu’aux réunions de planification et doit donc faire confiance à son équipe XP pour la réalisation du projet.
  • Le coach : Le coach est le garant du respect des règles eXtreme Programming. C’est à lui que revient le rôle de mettre en place la méthode. Son objectif est que l’équipe puisse fonctionner sans lui. Il doit donc s’armer de courage pour dire les choses telles qu’elles sont.
Un des objectifs de toutes ces règles est de pouvoir faire face aux changements réguliers d’un projet IT. Voici une évolution que l’on retrouve souvent dans les projets IT :
Et voici la courbe du coût du changement revue par les auteurs d’eXtreme Programming :

Facteur de compétitivité des entreprises

Dans la deuxième partie du livre, les auteurs d’eXtreme Programming nous explique la mise en place d’eXtreme Programming et ce que cela lui apporte.

Par où commence-t-on?

Dans une première partie, on nous explique la façon d’amener la méthode eXtreme Programming. En effet, certaines pratiques d’eXtreme Programming peuvent être vues par l’entreprise comme une perte de rentabilité(la programmation en binôme) ou alors comme du “flicage” pour les développeurs(le rôle de tracker par exemple).

La formation de toute l’équipe à l’eXtreme Programming est indispensable. Il est d’ailleurs important de souligner que la philosophie d’eXtreme Programming insiste dans le fait que toute l’équipe doit participer aux diverses formations. 3 différentes méthodes sont communiquées dans le livre :

  • Le coaching : un consultant eXtreme Programming est présent dans l’entreprise et joue le rôle de coach.
  • L’immersion XP : L’équipe se rend à une formation sur plusieurs jours et est encadrée par une entreprise de formation dans la création d’un projet fictif en utilisant les pratiques eXtreme Programming.
  • L’Heure Extreme : Ce sont des ateliers d’environ une heure mettant en pratique une notion d’eXtreme Programming.
Toutes les pratiques eXtreme Programming peuvent être dures à mettre en place dans une équipe. Il est donc recommandé de commencer par certaines pratiques comme la planification itérative et l’élaboration des tests unitaires avant le code.

Coûts et retours sur investissement

Cette partie du livre décrit les conséquences et la manipulation des variables clés qui font d’un projet XP une réussite.

Les variables clés

Les auteurs d’eXtreme Programming identifie 4 variables clés dans le déroulement d’un projet :

  1. Les coûts directs et indirects
  2. La qualité livrée
  3. La durée des projets
  4. Le périmètre fonctionnel des projets

Le livre nous explique les mécanismes de ces 4 variables ainsi que de leur inter-dépendance. Suite à cette analyse, la seule variable qui ressort manipulable est le périmètre fonctionnel des projets. En effet, il est impensable de diminuer la qualité du produit. Il est possible de modifier les coûts et le temps de développement mais le client ne sera pas satisfait. Par contre, réduire le nombre de fonctionnalités d’une version pour conserver la qualité, le coût et la durée de développement sera plus envisageable par le client.

Les auteurs listent ensuite les coût directs (exemples : la main-d’oeuvre, logiciels) ainsi que les coût indirects (exemples : les coûts du turn-over, défauts de qualité). Puis, on nous montre comment la méthode eXtrem Programming influe sur ces coûts, parfois en les augmentant comme pour la présence du client sur site, mais souvent en les diminuant. Les diminutions sont surtout visible sur les coûts indirects. En effet, les pratiques d’eXtreme Programming décrivent un environnement de travail serein au sein de l’équipe diminuant fortement le turn-over et le travail en binôme ainsi que les tests favorisent un travail de qualité.

Les aspects contractuelles

L’eXtreme Programming pose une certaine problématique lors de l’aspect contractuelle. En effet, la méthode n’est pas applicable suivant le type de contrat. En France, il existe 3 types de contrats:

  1. Les contrats forfaitaires : Le client définit un cahier des charges précis et contactera une société de service pour le mettre en oeuvre.
  2. Les contrats d’assistance technique : Le client définit et met en oeuvre le cahier des charges en faisant appel à du personnel compétent chez un fournisseur.
  3. Les contrats d’assistance forfaitée : Le client contacte un fournisseur qui lui fournira une équipe entière chargé de la réalisation du projet.

Seul le dernier contrat est véritablement adapté à la méthode XP (bien qu’il est possible de l’appliquer au second). En effet, le fait que ce soit une équipe en charge de la réalisation et d’être chez le client, le déploiement de la méthode est favorisé. Cependant, les auteurs du livre souligne le fait qu’il va falloir adapter les termes du contrat pour pouvoir spécifier les principes d’XP tels que le travail en binôme et le rythme durable par exemple. Le droit d’arrêt du projet est également donné au client, la méthode XP, grâce à sa structure itérative ainsi qu’aux livraisons d’un logiciel fonctionnel favorise la facture de ce qui est déjà fait.

Qualité et processus

Les auteurs du livre nous rappelle ce qu’est la norme iso:9000 ainsi que ces 8 principes.

  1. L’orientation client
  2. Leadership
  3. Implication du personnel
  4. Approche processus
  5. Management par approche système
  6. Amélioration continue
  7. Approche factuelle pour la prise de décision
  8. Relations mutuellement bénéfiques avec les fournisseurs

On nous explique alors les convergences entre l’eXtreme Programming et cette norme ainsi que les différents processus tel que les indicateurs de qualité(tests unitaires, recette) qui inscrivent XP dans la norme ISO:9001.

Méthodologie

Les auteurs nous expliquent que la méthode eXtreme Programming s’inscrit dans un mouvement plus vaste : celui de l’Agilité. Pour qu’une méthode soit validée comme étant agile, elle doit respecter le manifeste Agile :

L’importance est donnée:

  • aux individus et aux interactions plus qu’aux processus et aux outils
  • à des logiciels immédiatement disponibles plus qu’à une documentation exhaustive
  • à la collaboration avec le client plus qu’à la négociation contractuelle
  • à la réactivité face au changement plus qu’au respect d’un plan


Les méthodes Agiles s’appuient sur ces 4 valeurs clés et se différencient par la suite par leurs principes et leurs pratiques. Le livre nous décrit en quelques lignes d’autres méthode tel que Crystal, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development Model(DSDM) ou encore Scrum.

Etudes de cas

Dans cette dernière partie, 2 études de cas nous sont décrites. La première relate la réalisation d’un projet Web dans une équipe qui met en place pour la première fois eXtreme Programming. L’étude est analysée au rythme des itérations. La seconde étude de cas relate quant à elle un projet industriel. On nous explique alors la mise en place de la méthode XP avec les succès et les échecs à travers les points de vue des différents rôles.

Conclusion

La lecture de ce livre m’a appris énormément sur la méthode XP. J’ai cherché à travers ce billet de transmettre certaines valeurs de cette méthode. Seulement, ne vous contentez pas de ce billet pour la mettre en place. Je vous invite en effet à lire le livre pour comprendre les fondements de ces valeurs ainsi que l’importance qu’y attache eXtreme Programming. Le livre met également l’accent sur le fait que mettre en place eXtreme Programming n’est pas un objectif mais une base. On nous invite, une fois mise en place, à la modifier pour qu’elle s’adapte parfaitement à notre environnement de travail.