Publié par
Il y a 8 années · 14 minutes · Agile

Scrum ou XP ? Scrum ET XP !

Lors des Rencontres Agiles, que nous avons co-organisées en décembre dernier – et qui, soit dit en passant, ont rencontré un fort et encourageant succès -, plusieurs personnes m’ont demandé si, pour démarrer un projet agile, il était préférable de choisir eXtreme Programming (XP) ou Scrum. La réponse est simple : il faut adopter les deux !

La complémentarité de Scrum et XP est communément admise. Scrum se positionne au niveau de la gestion et de l’organisation de projet là où XP se positionne au niveau des activités de développement. C’est la raison pour laquelle ces deux approches fonctionnent si bien ensemble : elles adressent des problématiques différentes et se complètent mutuellement.

Je vous propose, dans cet article, une présentation sommaire de Scrum et de la façon dont elle (il? non, allez, c’est plutôt une fille) s’articule avec eXtreme Programming… Bonne lecture !

Scrum

Davantage qu’une méthode formelle, Scrum peut être vu comme un framework méthodologique – ses fondateurs parlent d’organisationnal pattern – dont l’implémentation doit être ajustée en fonction des caractéristiques techniques, organisationnelles et culturelles des projets qui souhaitent la mettre en oeuvre (Scrum, au demeurant, ne limite pas son champ d’application aux seuls projets informatiques : ses principes sont applicables pour toute activité visant à produire un résultat).

Dans ses grandes lignes, Scrum définit un jeu minimal d’acteurs, de cérémonies et d’artefacts qui permettent de relever les défis principaux du développement incrémental : la planification, la gestion du temps et la gestion des obstacles. Scrum est entièrement piloté par la Valeur Métier – la gestion des risques, en particulier, est réalisée au travers de ce prisme. Scrum identifie trois acteurs :

  • le Product Owner (Directeur de Produit), qui possède l’expertise fonctionnelle et est à même de réaliser les arbitrages nécessaires à la priorisation des développements. Son rôle est absolument essentiel, et son respect des règles du jeu est la pierre angulaire du succès d’un projet agile.
  • le Scrum Master, membre de l’Equipe, et dont la tâche principale est d’optimiser la capacité de production de l’Equipe en l’aidant à travailler de façon autonome et à s’améliorer constamment. Il est également le garant de la bonne implémentation de Scrum.
  • l’Equipe, dont la taille doit être réduite (7 à 9 personnes est généralement admis comme une borne supérieure), et qui prend en charge le développement du produit (planification, conception, codage, tests, documentation) sans spécialisation des rôles. La particularité d’une Equipe Scrum est d’être « auto-organisée », et donc dépourvue de hiérarchie. Cet aspect constitue une rupture radicale avec les approches managériales traditionnelles, qui privilégient un contrôle centralisé généralement incarné par le Chef de Projet.

L’unité de temps, dans Scrum, est le Sprint. Un sprint est une itération courte (de l’ordre de 2 à 4 semaines) dont le périmètre est garanti et défini lors d’une cérémonie de planification initiale.

Le schéma suivant décrit l’articulation générale de Scrum :

Scrum

Scrum définit également trois artefacts (nous conservons les noms anglais pour rester consistant avec la littérature sur le sujet) :

  • le Product Backlog, que nous décrivons plus loin
  • le Sprint Backlog, également décrit plus loin
  • le Burndown Chart, qui est une représentation graphique très simple de l’avancement du projet (un Burndown Chart est produit pour chaque Sprint, un autre pour la version du produit)

Le Product Backlog est fondamental à Scrum – sans lui, rien n’est possible.

Le Product Backlog est la liste des fonctionnalités du logiciel. Les éléments du backlog sont rédigés sous forme de « User Stories » (une User Story est une forme simplifiée et faiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métier du produit. A minima, un élément du backlog (ou une histoire) comporte typiquement les informations suivantes :

  • un identifiant – unique, il permet de tracer l’élément quand on le renomme
  • un nom – court et descriptif, suffisamment clair pour que le Directeur de Produit et l’Equipe comprennent approximativement de quoi il est question
  • l’importance – un chiffre permettant de hiérarchiser l’importance de l’élément aux yeux du Directeur de Produit. Sa valeur absolue ne signifie rien, seule la valeur relative compte
  • l’estimation initiale – exprimée en points de complexité, et dont la valeur est déterminée par l’Equipe. Pour établir cette estimation, on utilise le plus souvent une technique issue de l’eXtreme Programming : le Planning Poker.
  • comment faire la démo ? – cela correspond globalement à la spécification d’un test fonctionnel simple.
  • des notes – aussi brèves que possible, visant à clarifier certains points ou à renvoyer vers d’autres ressources

Le Product Backlog peut également contenir des éléments techniques – mais il est indispensable alors qu’ils soient libellés selon un angle métier, afin que le Directeur de Produit puisse lui affecter une valeur.

Le Product Backlog peut être conservé sous différentes formes, la plus fréquente – et probablement la plus efficace – étant un simple tableau Excel partagé.

Le Product Backlog n’est pas un document figé : tout au long du projet, les histoires peuvent être modifiées, fusionnées ou segmentées (celles bien sûr qui ne sont pas encore achevées) ; de nouvelles histoires peuvent être ajoutées, d’autres supprimées ; l’importance et l’estimation initiale peuvent être revues, à la hausse ou à la baisse.Au début de chaque Sprint a lieu la cérémonie qui est probablement la plus importante de Scrum : le Sprint Planning (planification du Sprint). Le Sprint Planning réunit l’Equipe et le Directeur de Produit pour déterminer l’objectif et le contenu du Sprint à venir. C’est durant cette cérémonie que l’estimation fine de la charge de développement de chaque histoire est déterminée. Ces histoires sont découpées en tâches dont chacune fait l’objet d’une estimation de charge – exprimée en heures ou en jours. Il est important de noter que c’est l’Equipe qui détermine la charge afférente à chaque tâche. Le principal résultat de cette cérémonie est le Sprint Backlog, qui regroupe l’ensemble des fonctionnalités que l’Equipe s’engage à produire durant l’itération naissante, et liste les tâches correspondantes.

La charge totale du Sprint Backlog ne doit pas excéder la capacité de production de l’Equipe (il existe plusieurs techniques que nous n’aborderons pas ici pour établir cette capacité de production, ou vélocité estimée).

Au terme de chaque sprint, le produit partiel est livré avec le niveau de qualité attendu pour son exploitation en production – cette caractéristique est à l’origine du qualificatif « incrémental » souvent associé aux méthodes agiles. Les histoires implémentées font l’objet d’une démonstration publique.

Les méthodes agiles sont inspirées des pratiques industrielles de la production en flux tendus et du zéro-défaut – un ensemble de pratiques désignées dans l’industrie par le terme Lean. L’une des caractéristiques de cette approche est de ne jamais figer les méthodes de travail, mais d’intégrer dans l’activité une introspection permanente sous-tendue par la recherche systématique d’axes d’amélioration. Une autre caractéristique est de ne jamais utiliser la qualité comme variable d’ajustement. Dans Scrum (et d’une façon générale pour toutes les méthodes agiles), la qualité du produit est de la responsabilité de l’Equipe, et ne fait pas l’objet de négociations.

Afin de faciliter cette démarche, Scrum intègre un certain nombre de cérémonies additionnelles – une cérémonie est une réunion dont la durée est fixée et dont les produits en entrée et en sortie sont définis. La limite de temps pour chacune des cérémonies fait partie de l’ADN de Scrum (on parle de time boxing).

Voici les principales cérémonies préconisées par Scrum :

  • le Sprint planning, que nous avons déjà abordé
  • la mêlée quotidienne (Daily Scrum), courte cérémonie (de l’ordre de 15 minutes) menée chaque jour avec les membres de l’Equipe et le Directeur de Produit, et dont l’objectif est de maintenir chacun au courant de l’activité de tous, de déterminer les tâches de la journée et d’identifier les éventuels obstacles qui ralentissent ou empêchent la progression du sprint
  • la revue de sprint (Sprint Review), qui consiste pour l’essentiel, au terme de chaque itération, à faire une démonstration publique du résultat du sprint ; cette cérémonie permet de garantir le caractère incrémental du développement (pour être démontré, le produit doit être utilisable) mais aussi de recueillir un retour régulier des commanditaires aux fins d’ajuster le contenu du backlog de produit
  • la rétrospective (au moins 1 heure), qui réunit l’équipe et le Product Owner au terme de chaque sprint afin d’identifier les erreurs commises lors du sprint précédent et de définir un plan d’actions (concret et affecté) en vue d’améliorer le processus ; la rétrospective est une cérémonie capitale qui incarne l’un des principes fondamentaux énoncés par le Manifeste Agile : « A intervalles réguliers, l’équipe réfléchit sur les moyens de devenir plus efficace, puis adapte et ajuste son comportement en conséquence ».

Une dernière question peut se poser : quels outils utiliser pour assurer le suivi de projet ? Il existe un certain nombre d’offres logicielles dans ce domaine. Dans la pratique, nous préconisons de débuter avec l’outillage le plus élémentaire : une feuille Excel, des post-it et un mur. Avec l’expérience, et en adhérant aux principes généraux de la méthode (inspecter et s’adapter), le Scrum Master pourra choisir d’utiliser d’autres outils. Dans la pratique, une telle démarche n’est que rarement nécessaire.

Scrum, on le voit, adresse la problématique du processus de production du logiciel, l’organisation et la dynamique du projet. Le développement incrémental, néanmoins, suppose des pratiques d’ingénierie logicielle rigoureuses et efficicaces, que Scrum ne couvre pas – rappelons que Scrum est avant tout un style organisationnel. C’est précisément sur ce terrain des techniques de génie logiciel incrémental que l’eXtreme Programming trouve tout son sens, en proposant un certain nombre de pratiques reconnues aujourd’hui comme l’état de l’art.

eXtreme Programming – XP

La première des pratiques de l’eXtreme Programming, la plus fondamentale également, est le test automatisé.

L’approche incrémentale suppose une vision minimaliste – on aurait envie de dire zen – du développement : seules les fonctionnalités effectivement nécessaires sont développées, et le design adopté doit être le plus simple imaginable permettant d’implémenter intégralement la fonctionnalité (ce principe est souvent désigné sous l’acronyme KISS : Keep It Simple and Stupid). Le Manifeste Agile définit au demeurant la simplicité comme « l’art de maximiser le volume de ce qui ne doit pas être fait ». Conséquence de cette recherche de simplicité, certains choix de design, suffisants à un moment donné, peuvent s’avérer inadaptés lors de développements ultérieurs. L’ajustement se fait alors par refactoring (ou ré-ingénierie), qui consiste à modifier le design voire l’architecture d’un composant sans changer son comportement. Le refactoring – une opération techniquement triviale avec les environnements de développement java, plus délicate lorsqu’il s’agit de la base de données – comporte un risque de régression évident, risque couvert en principe par la pratique des tests unitaires. L’équation est alors simple : sans tests unitaires, le refactoring devient rapidement impossible ; sans refactroring, les choix d’implémentation ne peuvent plus être remis en question ; sans remise en question, le développement incrémental devient illusoire, et c’est tout l’édifice du développement agile qui s’écroule.

Le test automatisé n’est pas seulement une bonne pratique du développement agile : il en est l’épine dorsale.

XP inclut la systématisation des tests automatisés – unitaires, fonctionnels, d’intégration, de performance, le plus est le mieux. Poussée à l’extrême, cette pratique a donné naissance au principe du TDD (Test Driven Development). Le TDD modifie sensiblement la pratique du développement. Son principe est d’une redoutable simplicité, mais sa mise en oeuvre est un véritable défi. Voici comment Henrik Kniberg résume le TDD :

Test-driven development means that you write an automated test, then you write just enough code to make that one test pass, then you refactor the code primarily to improve readability and remove duplication. Rinse and repeat.

Traduction : le développeur écrit en premier lieu un test automatisé de la fonctionnalité qu’il souhaite implémenter, développe ensuite juste assez de code pour satisfaire le test et finalement remanie le code pour améliorer le design et supprimer la duplication.

Outre les bénéfices classiques des tests unitaires, le TDD possède deux vertus cardinales : il permet de maintenir le focus du développeur sur les fonctionnalités réellement utiles ; il a des effets spontanés et profonds sur la qualité du design.

Au delà du TDD, XP comprend un certain nombre de pratiques dont la mise en place est souvent associée à l’adoption des méthodes agiles – sans pour autant sue cette mise en place soit obligatoire.
Voici, sans exhaustive, les plus importantes de ces pratiques :

  • le Refactoring ; nous l’avons déjà rapidement abordé, c’est une pratique intrinsèque du développement incrémental et qui mériterait un billet à part entière. Pour une bonne introduction aux technique de refactoring objet, je vous invite à consulter le site que Martin Fowler a consacré au sujet : refactoring.com.
  • l’Intégration Continue ; cette pratique consiste à déclencher de façon systématique le système de build – qui comprend notamment la compilation et l’exécution des tests automatisés – chaque fois qu’un membre de l’équipe valide des sources dans le référentiel projet ; c’est une pratique essentielle pour détecter et corriger au plus tôt les problèmes d’intégration des développements (principe de fail fast)
  • la Propriété Collective ; la propriété collective du code consiste à ne pas spécialiser certains membres de l’équipe sur certains composants – et donc à favoriser la polyvalence au sein de l’équipe. Elle est évidemment favorisée par des pratiques telles que la programmation en binôme qui favorise l’appropriation d’une base commune de code. Les équipes avec un haut niveau d’appropriation collective de code sont réputées pour être plus robustes : un sprint ne sera par exemple pas forcément menacé par l’absence ponctuelle d’un membre de l’équipe.
  • les Normes de développement ; sans être une particularité de l’eXtreme Programming, les normes de développement en sont un élément clé, facilitant les tests, l’intégration continue et l’appropriation collective de la base de code. Elles renforcent également la consistance des APIs.
  • la Programmation en binôme (Pair Programming), qui consiste à développer à deux sur un même poste ; cette pratique, souvent mal comprise, n’est que rarement systématisée. Il ne faut par contre pas s’interdire son utilisation ponctuelle, par exemple sur une nouvelle technologie, une problématique pointue, un fonctionnel plus complexe, ou plus simplement, si l’un des membres de l’équipe demande de l’assistance. C’est aussi une pratique utile lors des montée en charge de l’équipe : elle permet d’intégrer plus rapidement les nouveaux développeurs et de leur communiquer la culture de l’équipe.
  • un Rythme soutenable ; ce principe est commun à toutes les méthodes agiles, et directement issu du heijunka Lean ; il part du principe qu’il n’y a rien de plus contre-productif à moyen terme que de maintenir une équipe de développement sous la pression d’une charge de travail supérieure à sa capacité de production – cela revient à étrangler la poule aux œufs d’or et se traduit généralement par une baisse massive de la qualité et de la motivation.

Certaines des pratiques de l’eXtreme Programming ont irrigué Scrum (ou le contraire, peu importe) : « une équipe », « une même pièce », la notion de « stories », le « rythme soutenable » ou encore le « planning game », raison pour laquelle ces deux approche sont très complémentaires.

Cet article vous a proposé un rapide aperçu de Scrum et XP et aura, je l’espère, contribué à mettre en exergue la complémentarité des deux approches. Beaucoup de notions ont été évoquées de façon trop brève, et je reviendrai dessus dans de prochains billets… N’hésitez pas à laisser vos commentaires et questions !

17 réflexions au sujet de « Scrum ou XP ? Scrum ET XP ! »

  1. Publié par Sanlaville, Il y a 8 années

    Bravo pour ce billet très claire et très intéressant. Il permet de bien comprendre la complémentarité entre Scrum et XP. On attend les prochains billets avec impatience…

    Sinon j’ai pu remarqué que la difficulté avec l’approche TDD est de bien écrire les tests unitaires. En effet, si les tests unitaires sont bien fait, le développement est facilité. Voir par exemple, le challenge (très instructif) proposé à cette adresse http://xp123.com/xplor/xp0201/. Le problème souvent est qu’on nous apprend à développer du code mais pas des tests unitaires et écrire de bons tests unitaires n’est pas inné et simple. C’est d’ailleurs une des raisons qui fait qu’une bonne partie des gens sont convaincus par l’approche TDD mais ne la met pas vraiment en place. Il y a sans doute un terrain à explorer dans ce sens. Si vous avez des liens ce point, je suis preneur.

    Rémy

  2. Publié par Guillaume Bodet, Il y a 8 années

    Je suis parfaitement d’accord : la pratique du TDD (et du test d’une façon générale) est une problématique beaucoup plus complexe qu’il n’y parait. Pour ne prendre qu’un exemple, le test unitaire systématique aboutit à doubler peu ou prou le volume de code à maintenir. Il est donc important, lorsque l’on pratique le refactoring, de refactorer également les tests – faute de quoi leur évolution deviendra impossible.
    Et puis il faut maîtriser les différents types de tests (tests unitaires en isolation, tests d’intégration, tests fonctionnels, white box vs black box testing…) ainsi que les outils (mock objects, xunit, selenium, etc.) et patterns (fixtures, transaction rollback, etc.)…
    Je consacrerai bientôt un article au sujet. En attendant, et en guise d’appéritif, je vous propose quelques références :
       * la bible du TDD, par Kent Beck : Test-Driven Development: By Example
       * un catalogue de patterns pour les tests, moins digeste mais très précieux : http://xunitpatterns.com/
       * cette présentation de unitils (une bibliothèsue qu’il faut que j’essaie une de ces jours, d’ailleurs)
       * cette publication qui capture visuellement les différentes pratiques agiles, et en particulier les tests

  3. Publié par Guillaume Bodet, Il y a 8 années

    Pour compléter, j’ajouterais que si vous avez du mal à développer et maintenir les tests sur vos projets, je vous conseille d’intégrer dans vos équipes un ou plusieurs développeurs expérimentés, connaissant bien les techniques de test, voire le TDD, et de pratiquer le pair-programming pour diffuser ce savoir…

  4. Publié par Sanlaville, Il y a 8 années

    Merci pour les liens.
    En fait je pense que les tests unitaires sont un peu la pierre angulaire du développement et qu’il vaut mieux avoir des experts pour la création des tests que pour le développement. Ce que semble confirmer vos retours.

    Pour la gestion de projet, il vaut donc mieux affecter les tests aux experts voir en pair-programming pour diffuser le savoir.

    Rémy

  5. Publié par Cyrille Le Clerc, Il y a 8 années

    Je préfère votre deuxième proposition Remy : les développeurs expérimentés aident au développement des tests.

    Le premier auteur des tests est le développeur du composant lui même car c’est lui qui connaît mieux les points sensibles des algorithmes. Par la suite, les développeurs qui interviennent en bug-fixing ajoutent et améliorent les tests.

    … et le développement des tests comprend le refactoring du code pour faciliter la testabilité ;-)

    Cyrille (Xebia)

  6. Publié par ehsavoie, Il y a 8 années

    Bonjour,
    Je trouve le dessin suivant http://www.xprogramming.com/images/circles.jpg très parlant puisqu’il présente les 3 niveaux d’un projet :le développeur (en bleu), l’equipe (en vert) et le projet (en rouge) et son organisation. C’est typiquement là que l’on verrait Scrum et c’est ainsi qu’on voit comment il s’intègre bien avec l’XP.
    Emmanuel

  7. Publié par Anthony Guillemette, Il y a 8 années

    Très bon article ! Je connaissais XP de renommée et parce que l’on a déjà mis quelques principes en pratique dans notre équipe de développement. Par contre, je ne connaissais pas du tout Scrum, mais notre chef de projet avait assisté quand lui aux Rencontres Agiles et nous avait dit qu’il serait bon de s’y intéressait aussi.
    Votre article permet tout à fait de comprendre la complémentarité de ces deux “méthodes”. La mise en pratique d’XP et Scrum est normalement prévu pour le mois prochain, on verra ce que ça donnera, mais ça me parait très prometteur.
    Anthony

  8. Publié par Patrice, Il y a 8 années

    Bonjour,

    Pourquoi réduire XP à la notion de testabilité quand il s’agit en fait d’une méthode de gestion de projet complète ?

    Cdlt,

    Patrice

  9. Publié par Thomas, Il y a 7 années

    Bonjour,

    Très bon article. Par contre une question se pose, comment mettre tout ceci en pratique dans le projet qui est déjà démarré depuis long temps ?

    Thomas

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *