Scrum et Extreme Programming

Méthodes pour application concrète des principes agiles

Launizo Consulting, Laurent Ninni

Nous avons vu, dans un précédent article, les origines et principes des méthodes agiles, et pourquoi les cycles traditionnels de travail sur les projets étaient de moins en moins adaptés au monde moderne, où l'environnement économique, technologique et concurrentiel change beaucoup plus vite qu'auparavant. Voyons maintenant comment ces principes agiles sont mis en application au travers de méthodes de travail formalisées.

Parmi les rédacteurs du Manifeste Agile, on trouve notamment Kent Beck, inventeur de l'Extreme Programming (ou XP), et Ken Schwaber, qui a formalisé la méthode Scrum (pour ne citer qu'eux). Ces 2 méthodes font référence dans le monde du développement logiciel agile (même si elles ne sont pas les seules), Scrum formalisant la gestion de projet, et Extreme Programming se focalisant surtout sur la production logicielle à proprement parler.

Scrum donne un cadre pour la gestion de projet

Scrum (qui signifie "mêlée") organise la gestion d'un projet autour de rituels et de personnages clés. Il définit ainsi les rôles suivants :

  • Product Owner (responsable produit) : personne unique qui porte la vision client du produit qui doit être réalisé (ce n'est pas nécessairement le client lui-même); il fait le lien entre le client et les équipes de développement.

  • Scrum Team (équipe Scrum) : l'équipe réalisant le projet; au sein de cette équipe, l'équipe étant liée par son engagement à réaliser un objectif commun, il est important qu'elle soit solidaire, et donc que chacun puisse réaliser ou aider à réaliser les différentes tâches requises pour l'équipe.

  • ScrumMaster (maître du Scrum) : il s'agit d'un expert en gestion de projet Scrum, responsable du processus Scrum, qui va s'assurer du bon respect des règles Scrum, de leur compréhension par les différents intervenants, et de l'implication et de la motivation de ces derniers.

Il est important de noter qu'il n'y a pas de "chef" en Scrum : le principe est d'avoir des intervenants qui coopèrent pleinement et efficacement pour produite le meilleur résultat. C'est pour cette raison notamment que le ScrumMaster n'est pas un chef de projet (même si le rôle peut être tenu par un ancien chef de projet) : c'est plutôt un coach qui va aider, soutenir et encourager tous les collaborateurs du projet. Ayant toute autorité sur le respect du process, il peut par exemple rappeler les règles et les manquements éventuels des intervenants à ces règles : il n'a en revanche pas autorité pour imposer aux membres de l'équipe ses vues sur la façon de réaliser les tâches du projet (contrairement à un chef de projet). Le rôle de ScrumMaster est important car l'une des clés du succès tient justement à l'implication et la disponibilité de tous.

L'organisation des itérations en Scrum se fait par une succession de "sprints" dont la durée (usuellement entre 2 et 4 semaines) est fixée pour le projet (sauf ajustement nécessaire). Chaque sprint doit aboutir à la réalisation concrète de fonctionnalités additionnelles et utilisables dans le produit. Chaque sprint donne lieu aux rituels suivants :

  • Sprint planning (planification du sprint) : au début du sprint, le Product Owner présente la liste des exigences du client (appelée "Product backlog") à l'équipe, en commençant par ce qui est le plus important pour le client. Après avoir échangé pour assurer la bonne compréhension de tous, l'équipe choisit dans cette liste ce qu'elle peut réaliser durant le sprint à venir, les éléments choisis constituant la liste des choses à réaliser durant le sprint (appelée "Sprint backlog"). Chaque élément donne naissance à une liste de tâche, qu'il convient d'estimer pour s'assurer que tout rentrera dans le temps du sprint. Un objectif de quelques lignes est écrit, qui résume ce qu'on attend du sprint à venir. L'équipe se met ensuite au travail.

  • Daily Scrum (mêlée journalière) : courte réunion (15 minutes) tenue chaque jour par l'équipe où chacun liste ce qui a été fait, ce qu'il s'engage à faire pour le lendemain, et les difficultés identifiées. Le ScrumMaster et si possible le Product Owner doivent y participer, pour rester en complète implication dans le projet; cela permet aussi au ScrumMaster, dans son rôle de facilitateur, de prendre en charge la résolution des difficultés qui auront été soulevées.

  • Sprint review (revue de Sprint) : en fin de sprint, l'équipe réalise une démonstration des fonctionnalités apportées au produit durant le sprint (l'incrément produit). Le résultat est confronté à l'objectif fixé, et le Product Owner peut accepter ou refuser les fonctionnalités présentées.

  • Sprint retrospective (rétrospective de sprint) : cette réunion de fin de sprint fait le bilan de ce qui a bien et mal fonctionné dans l'application de Scrum, et permet de décider des changements à réaliser pour améliorer la suite.

On représente régulièrement Scrum avec une boucle pour les itérations. Le schéma ci-dessous choisit au contraire de montrer les itérations de Scrum lors d'un projet, afin de pouvoir mieux le comparer au schéma du cycle en V classique

Schéma de Scrum

Schéma simplifié de cycles Scrum   - Les sprints se succèdent, et en comparaison avec le cycle en V, on note bien que la vision client est sollicitée à chaque sprint :

les exigences sont discutées lors de la planification de sprint, tandis que la revue constitue une mini-recette.

On le voit, Scrum permet, par ses cycles courts répétés, d'éviter l'apparition d'écarts trop importants entre les attendus et le réalisé. C'est l'une de grandes forces des cycles itératifs agiles. L'autre avantage est qu'à chaque début de cycle, le client peut apporter de nouvelles idées, des changements dans ses exigences, et celles-ci seront étudiées pour prise en compte.

Extreme Programming : méthode de production de logicielle agile

Nous ne détaillerons pas Extreme Programming ici. On peut citer, parmi ses grands apports, les éléments suivants :

  • livraison le plus tôt possible d'une première version du produit au client, puis itérations successives pour y ajouter des éléments : le client est ainsi impliqué tout au long du cycle de développement du produit, ce qui permet de réduire au plus tôt l'écart éventuel entre ses attendus et la réalisation.

  • travail en binôme : le travail de chacun est ainsi systématiquement vérifié, pour assurer que les bonnes pratiques sont respectées et limiter les erreurs dans la réalisation (2 paires d'yeux valent mieux qu'une).

  • intégration en continu : dès qu'une tâche du projet est finie, elle doit être intégrée (livrée) dans le projet global, de façon à pouvoir être testé et déceler ainsi au plus tôt les défauts. On évite ainsi le couperet du "test d'intégration" qui arrive à la fin du cycle en V : l'intégration est faite au fil de l'eau durant la phase de réalisation (développement) du produit, ce qui évite les mauvaises surprises en fin de cycle et fait donc gagner beaucoup de temps.

  • tests en continu : c'est le pendant de l'intégration en continu. Pour pouvoir réaliser les tests aussi souvent que possible, on les automatise le plus possible.

  • refactoring : on n'hésite pas à régulièrement reprendre des éléments du produit déjà réalisés pour les améliorer, quitte parfois à casser et jeter pour refaire, l'objectif étant de faire bien. Cela a une implication : le découpage des éléments du produit doit être bien établi (notamment les interactions entre eux), pour qu'on puisse facilement remplacer un élément par un autre de meilleure qualité sans avoir à modifier les autres éléments du produits avec lesquels il interagit. Le refactoring est, notamment, le moyen de prendre en compte les évolutions technologiques rapides dans le monde du numérique.


Si ces méthodes ont été pensées pour le développement logiciel, elles comportent un certain nombre de principes qui pourraient s'appliquer à d'autres domaines. C'est une observation à partir de laquelle des réflexions ont été construites, et qui ont notamment amené au concept d'entreprise agile : nous en ferons le sujet d'un prochain article.