Les méthodes agiles représentent un mouvement qui vise à apporter plus de valeur aux clients et aux

utilisateurs, ainsi qu’une plus grande satisfaction dans leur travail aux membres de l’équipe.

Le but affiché d’une méthode agile est de maximiser la valeur ajoutée : le développement s’effectuant par

itérations successives, il est possible, à la fin de chaque itération, de changer les priorités en faisant en

sorte que les éléments apportant le plus de valeur soient réalisés en premier.

Un meilleur accomplissement des personnes impliquées dans un développement est rendu possible par la

notion d’équipe auto-organisée.

Une tentative de définition, adaptée de Scott Ambler, pourrait-être :

« Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé

de manière très collaborative par des équipes responsabilisées, appliquant un cérémonial minimal, qui

produisent un logiciel de grande qualité dans un délai contraint, répondant aux besoins changeants des

utilisateurs. »

Le cérémonial c’est ce qui définit les règles sociales et conventionnelles régissant la vue d’une équipe ; s’il

est vrai que, pour une méthode agile, il est minimal pour la documentation, il existe bien pour le côté

social, mais avec des règles nouvelles.

Avec ses valeurs et ses principes, on peut considérer l‘agilité comme une nouvelle culture du

développement.

Celles-ci ont été précisées dés 2001 avec le Manifeste agile, avant même l’apparition des premières

méthodes agiles :

Livrer fréquemment et régulièrement le logiciel

Faire des cycles de développement courts et limités dans le temps

Constituer une équipe complète pour un développement

Gérer les membres de l’équipe en les responsabilisant

Avoir le représentant des utilisateurs sur le même site que le reste de l’équipe

Produire des plans à plusieurs niveaux : détaillés uniquement pour le court terme, et plus généraux

pour le moyen terme

Développer en intégrant le code de façon continue

Faire des bilans de projet dans le but d’améliorer la façon de travailler.

Prises individuellement, ces pratiques sont déjà efficaces. Insérées dans le cadre cohérent d’une

approche agile, elles se renforcent mutuellement, et contribuent à la qualité du produit et à son utilité.

Les méthodes agiles existaient avant le Manifeste : Scrum et Extreme Programming datent des années

1990. Il y a eu de nombreuses autres méthodes qualifiées d’agiles, le Manifeste en énonçant les valeurs

et les principes communs a contribué à les fédérer toutes derrière la même bannière de l’agilité.

Plus récemment, l’engouement pour Scrum a mis fin à une hypothétique rivalité entre les méthodes agiles.

Les études d’opinion et les tendances des recherches sur le Web tendent à montrer que Scrum est de loin

la plus populaire des méthodes de gestion de projet agiles.

Scrum signifie mêlée au rugby. Scrum utilise le valeurs et l’esprit du rugby et les adapte aux projets de

développement. Comme le pack lors d’un ballon porté au rugby, l’équipe chargée du développement

travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster

aiguillonne les membres de l’équipe, les repositionne dans la bonne direction et donne le tempo pour

assurer la réussite du projet.

On est naturellement tenté de parler de méthode agile ou de processus agile pour parler de Scrum. En

fait, la définition officielle, celle donnée par la Scrum Alliance et son fondateur Ken Schawaber est

légèrement différente.

Le plus souvent, K. Schawaber décrit Scrum comme un cadre (framework) ; à d’autres occasions il en

parle comme d’une voie à suivre (path). De manière concrète, Scrum définit des éléments qui feront

partie du processus appliqué pour développer un produit. Ces éléments sont en petit nombre, le cadre

imposé par Scrum étant très léger : guère plus que des itérations, des réunions en début et à la fin de

chacune, un « inventaire des tâches » (backlog) et trois rôles. Ce côté minimaliste est sans conteste une

des forces de Scrum, facilitant énormément son implémentation en entreprise.

Si la vraie nature de Scrum est difficile à définir, il est beaucoup plus simple d’expliquer la mécanique de

mise en œuvre :

Scrum sert à développer des produits, généralement en quelques mois. Les fonctionnalités

souhaitées sont collectées dans le backlog de produit et classées par priorité. C’est le product

Owner qui est responsable de la gestion de ce backlog.

Une version (release) est produite par une série d’itérations appelées des sprints. Le contenu d’un

sprint est défini par l’équipe, avec le Product Owner, en tenant compte des priorités et de la

capacité de l’équipe. A partir de ce contenu, l’équipe identifie les tâches nécessaires et s’engage

pour réaliser fonctionnalités sélectionnées pour le sprint.

Pendant un sprint, des points de contrôle sur le déroulement des tâches sont effectuées lors des

mêlées quotidiennes (Scrum Meeting). Cela permet au ScrumMaster, l’animateur chargé de faire

appliquer Scrum, de déterminer l’avancement par rapport aux engagements et d’appliquer, avec

l’équipe, des ajustements pour assurer le succès du sprint.

A la fin de chaque sprint, l’équipe obtient un produit partiel (un incrément) qui fonctionne. Cet

incrément du produit est potentiellement livrable et son évaluation permet d’ajuster le backlog pour

le sprint suivant.

Les 3 piliers de la théorie sont la transparence, l’inspection et l’adaptation du processus dont Scrum fournit

le cadre :

Transparence : Elle garantit que tous les indicateurs relatifs à l’état du développement sont visibles par

tous ceux qui sont intéressés par le résultat du produit.

Inspection : Les différentes facettes du développement doivent être inspectées suffisamment souvent

pour que des variations excessives dans les indicateurs puissent être détectées à temps.

Adaptation : Si l’inspection met en évidence que certains indicateurs sont en dehors des limites

acceptables, il est probable que le produit résultat sera également inacceptable si on ne réagit pas. Le

processus doit donc être ajusté rapidement pour minimiser les futures déviations.

Scrum fait partie des approches itératives et incrémentales, dont le modèle de cycle de développement est

basé sur une phase qui se répète plusieurs fois successivement. C’est la notion d’itération, appelée sprint

avec Scrum. Tous les sprints se déroulent selon le même schéma et on y fait à chaque fois les même

types de travaux.

Dans les approches classiques de la gestion de projet, un cycle dit en ‘V’ est couramment utilisé. Il

permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante

doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés, afin

d'améliorer le logiciel.

Scrum va à l’encontre de cette pratique en offrant une approche itérative et incrémentale pour le

développement d’un produit.

Incrémental :

Est utilisé pour mettre en évidence l’accroissement du produit obtenu à la fin de chaque sprint. Un

processus incrémental permet de construire un produit morceau par morceau, chaque nouvelle partie

venant s’ajouter à l’existant.

C’est une pratique rependue dans les développement de logiciel ; on parle souvent de lots pour les

incréments.

Itératif :

Itérer est l’action de répéter. Le terme itération est utilisée pour désigner une période de temps dans

laquelle sont effectuées des activités, qui seront répétées dans les prochaines itérations.

Un processus itératif permet de revenir sur ce qui a été fait, dans le but de l’émaliorer ou de le compléter.

Cela part de l’idée qu’il est difficile, voire impossible, de bien faire la première fois. Le feedback collecté

sur le résultat d’une itération permet de faire des améliorations dans la suivante. On cesse d’itérer dans la

qualité obtenue est jugée satisfaisante.

Itératif et Incrémental

Scrum combine les deux approches avec la notion de sprint :

A l’issu du sprint, il y a un incrément de produit qui est réalisé

Le feedback sollicité sur cet incrément permet de le perfectionner dans un prochain sprint.

Dans chaque processus de développement, il existe des jalons majeurs et des jalons mineurs. Avec

Scrum, le jalon mineur et la fin d’un sprint, et le jalon majeur est la production de la release.

Une release est une série de sprints qui se termine quand les incréments successifs constituent un produit

qui présente suffisamment de valeurs à ses utilisateurs.

Un sprint dure habituellement entre 2 et 4 semaines. Sur le projet AVEA, la durée du sprint a été fixé à 2

semaines, et les sprints s’enchainent sans délai : le nouveau démarre immédiatement après le précédent.

Le cycle de développement se présente come un enchaînement de phases dans lesquelles on effectue

des activités, qui dans le développement de logiciels suivent le schéma suivant :

Spécifications fonctionnelles

Architecture ( conception )

Codage et tests unitaires

Tests ( d’intégration et de recette )

Chaque sprint se compose donc de ses 4 activités, et met en évidence la différence avec un cycle

séquentiel traditionnel :

Scrum

Séquentiel

Avec une méthode agile comme Scrum, les activités de spécifications et de conception sont continues. On

part du principe que l’architecture va évoluer, dans une certaine limite, pendant la vie du projet.

L’approche est plus réaliste et pragmatique. L’autre principe important est que les tests sont pratiqués dés

le premier sprint.

Release Sprint 1 Sprint 2 Sprint 3

Sprint 1

• Spécifications

• Architecture

• Codage

• Test

Sprint 2

• Spécifications

• Architecture

• Codage

• Test

Sprint 3

• Spécifications

• Architecture

• Codage

• Test

Sprint 4

• Spécifications

• Architecture

• Codage Test

Spécif. Architecture Codage Test

La hiérarchie classique chef de projet / développeurs est remise en cause dans la méthode Scrum. Celle-

ci préconise en effet la suppression de toute forme d’autorité au sein d’une équipe, mais prévoit en lieu et

place des rôles complémentaires et indépendants.

Les 3 rôles définis sont celui de ScrumMaster (Animateur ou Facilitateur), de Product Owner (Directeur de

produit) ainsi que l’équipe. Les propositions de traduction françaises de ces rôles étant source de conflit

dans la communauté, les termes originaux seront préférés.

Lorsqu’on évoque un projet développé par un groupe de personnes, une pensée très rependue est de

considérer qu’une personne identifier doit être responsable de l’équipe. Traditionnellement, ce rôle est

appelé chef de projet. Dans Scrum, ce rôle est tout simplement éliminé.

Le travail et les responsabilités d’un chef de projet ne disparaissent pas pour autant. Une grande partie est

dévolue au Product Owner, une autre est laissée à l’équipe elle-même. Un des principes de Scrum est

l’auto-organisation : il signifie que les membres de l’équipe s’organisent eux-mêmes, et n’ont pas besoin

d’un chef qui leur assigne le travail à faire.

Le ScrumMaster n’est donc pas le nouveau nom donné au chef de projet, il est tel le demi de mêlé d’une

équipe de rugby, un guide qui sache faire avancer son équipe vers la victoire.

Il a pour responsabilité essentielle d’aider l’équipe à appliquer Scrum et à l’adapter au contexte. A ce titre,

il doit :

veiller en l’application de Scrum, par exemple en faisant en sorte que les différentes réunions aient

lieu et qu’elles se fassent dans le respect des règles.

Encourage l’équipe à apprendre, et à progression

Faire en sorte d’éliminer les obstacles qui pourraient freiner l’avancement, par exemple en

protégeant l’équipe des « interférences » extérieures pendant le déroulement d’un sprint

Inciter l’équipe à devenir autonome.

Il influence l’équipe et c’est un meneur d’homme qui sait motiver une équipe, pour qu’elle arrive au

résultat. Mais il doit arriver à ses fins par la persuasion, sans imposer ses décisions : un ScrumMaster ne

dispose d’aucune autorité hiérarchique sur l’équipe.

Son travail le plus important est d’éliminer les obstacles, qui peuvent être d’origine technique,

environnementaux, personnels, etc. Il joue le rôle de médiateur entre les membres de l’équipe, mais

surtout avec le client lorsque cela s’avère nécessaire. Un client mécontent aura toujours affaire au

ScrumMaster qui s’efforcera de trouver un compromis pour les deux parties, pendant que les

développeurs resteront dans un environnement optimal pour avancer leur travail.

Le Product Owner est responsable de définir l’objectif du produit et de le partager avec l’équipe qui le

développe. Il doit absolument avoir une bonne vision du produit, qui se construit au début du

développement d’un nouveau produit et se consolide ensuite.

Il va a se titre rédiger en collaboration avec le client un document permettant de décrire le contenu du

produit. Pour cela, il identifie les fonctionnalités requises et les collecte dans une liste appelée le backlog

de produit.

Par la suite, il va définir l’ordre dans lequel les parties du produit seront développées. Il doit alimenter

l’équipe avec les fonctionnalités à développer, selon ses priorités définies, en fonction de la valeur qu’elles

apportent, ou de l’urgence de leur intégration. En résumé, le Product Owner défini l’objectif d’une release

et prend les décisions sur son contenu et sa date de mise à disposition.

Une bonne connaissance du domaine métier est fondamentale pour le Product Owner, puisqu’il est le

représentant dans l’équipe de toutes les personnes qui utilisent le produit. Cela s’acquière notamment par

des échanges continues avec le client et ses utilisateurs finaux.

Avec une approche agile, la spécification des exigences n’est pas détaillée dès le début du

développement. Il doit donc savoir, en fonction de l’avancement, à quel moment détailler des éléments du

backlog de produit. Cela se fait généralement dans un autre document nommé « tests d’acceptations »

qui définit pour chaque user story, c'est-à-dire pour chaque tâche élémentaire, comment la vérifier une

fois finie.

L’équipe est donc composée des « techniciens » qui vont travailler sur le projet, guidés par le

ScrumMaster et aidé par le Product Owner. Elle a le rôle essentiel, c’est elle qui va réaliser le produit, en

développant un incrément à chaque sprint. Elle est investie avec le pouvoir et l’autorité pour le faire de

façon la plus efficace.

Pour cela, elle s’organise elle-même et doit avoir toutes les compétences nécessaires au développement

du produit. Chaque membre de l’équipe apportant son expertise, la synergie améliore l’efficacité globale,

et chaque développeur se trouve individuellement responsable du produit qu’il crée.

Les réunions représentent pour bon nombre de développeurs une perte de temps en raison de leur

inefficacité ou de leur fréquence trop importante.

En réponse à se sentiment général, la méthodologie Scrum ne définit qu’un nombre limité de cérémoniaux

qui ont tous un objectif clairement définis et une méthodologie d’application, permettant ainsi d’optimiser le

temps de tous les collaborateurs tout en gagnant en efficacité.

Sur l’ensemble du cycle de vie d’un projet, ils sont au nombre de 5.

Dans tous les projets, on fait des plans, pour essayer de prévoir ce que va contenir un produit ou à quelle

date il sortira sur le marché. Avec Scrum, la planification de release a les mêmes objectifs : fournir à

l’équipe et aux parties intéressées des informations sur le contenu des sprints constituant la release.

A cette étape, le Product Owner a en sa possession le backlog de produit contenant les différentes tâches

à réaliser en priorité, ainsi que la capacité de l’équipe ( c'est-à-dire le nombre de jours homme disponible

dans le sprint ). La planification de release consiste alors à définir quels sont les User Story qui seront

incluses dans cette release.

Une grande partie de l’effort nécessaire pour produire le plan de release est consacrée à l’estimation.

Avec Scrum et les méthodes agiles, celle-ci est collective, elle s’élabore lors de réunions où toute l’équipe

participe. C’est un point fondamental que l’équipe s’occupe des estimations, car c’est elle qui va par la

suite exécuter les tâches de réalisation , et s’est donc elle qui est la mieux placée pour en connaître les

difficultés.

Ma méthode de planification préconisée par Scrum est à elle seule significatrice de l’esprit de cette

méthode. Il n’est ici pas question d’estimer le temps nécessaire au développement de chaque tâche, mais

bien l’effort à fournir pour y arriver.

Bien que la technique ne soit pas imposée par Scrum, la plus fréquente est de faire une estimation

collective au cours d’une séance appelée planning poker et d’estimer plutôt la taille que la durée.

Release

… Sprint 1 Sprint N

Rétrospective de sprint

Revue de sprint

Scrum meeting (quotidient)

Planification de sprint

Planification de release

Le planning Poker

Il s’agit d’une séance d’estimation en groupe, avec des cartes, qui combine la jugement d’expert et

l’estimation par analogie.

Pour commencer la séance, il faut définir un étalon, c’est simplement une user story connue par tous, pour

laquelle l’équipe décide en commun d’une valeur arbitraire.

Comme il est plus facile de faire des estimations sur une échelle prédéfinie plutôt que d’avoir à sa disposition tous

les entiers, la suite de Fibonacci est généralement utilisée :

Pour chaque autre tâche, les membre de l’équipe posent des questions au Product Owner pour bien la

comprendre et débattent brièvement. Tous les participants présentent en même temps la carte choisie

pour l’estimation et la valeur moyenne est prise en compte.

Une des caractéristiques importante des méthodes agiles est leur capacité à prendre en compte les

changements. Cela implique que les plans sont remis à jour régulièrement. C’est particulièrement vrai

pour le plan de release, qui est actualisé à chaque sprint, dont les priorité et la liste des tâches peuvent

varier.

Cette réunion met en évidence le rôle essentiel de l’équipe dans l’élaboration des plans. Le travail du

sprint appartient à l’équipe : ce n’est pas un chef qui définit ce qu’il y a à faire, c’est l’équipe qui s’organise

elle-même. Au-delà de sa fonction première de planification, la réunion est un rituel qui prépare l’équipe à

travailler de façon collective pendant le sprint, comme les préparatifs dans les vestiaires qui amènent une

équipe de rugby à rentrer dans son match.

A ce niveau, l’équipe a déjà définie les user story qui seront à effectuer dans le sprint. Après que le

Product Owner ai présenté à l’équipe de façon détaillée une storie, l’équipe va l’étudier pour parvenir à

identifier les tâches atomiques nécessaires à sa réalisation. Le but étant de parvenir à séparer les tâches

de manière optimale, en pensant parallélisassions notamment. Celles-ci sont alors estimés en terme de

temps de développement.

Des tâches annexes sont souvent rajoutés tel que : écriture des plans de tests (PT), écriture de tests

unitaires, prendre contact avec X pour demander plus d’ informations, etc.

Chaque jour, et à heure fixe, l’équipe complète se réunit durant un quart d’heure pour effectuer la réunion

d’avancement.

Chaque participant doit alors répondre à 3 questions :

Qu’as-tu fait depuis la dernière réunion ?

Que prévois-tu de faire jusqu’à la prochaine réunion ?

Quels sont les obstacles qui te freinent dans ton travail.

C’est l’occasion pour les développeurs de prévoir la meilleur façon de paralléliser leur travaux ou de

demander de l’aide si une tâche s’avère plus délicate que prévue ( le travail en binôme est conseillé dans

les méthodes agiles ).

Pour les équipes qui utilisent un tableau des tâches mural, comme c’est le cas chez IOcean, c’est aussi

l’occasion de déplacer physiquement la carte correspondante dans la ligne : en cours ( je prend en

charge cette tâche ), à tester ( un autre collaborateur doit tester cette user story ) ou fini.

La revue de sprint est une démonstration de l’incrément en présence de toutes les parties prenante (

hiérarchie pour un produit interne, client … ). Elle a pour objectif de montrer le résultat du travail de

l’équipe durant le sprint.

Dans un premier temps le Product Owner va rappeler le but du sprint défini dans la réunion de

planification, puis l’équipe présente le produit partiel, résultat de ses travaux, en faisant une démonstration

des stories réalisées.

Les participants à la réunion sont invités à poser des questions à l’équipe et à donner leur impression sur

le produit montré. Leur feedback se concrétise en propositions et demandes de changement, qui seront

prisent en compte dans le backlog de produit.

La difficulté de cette réunion est d’éviter qu’elle ne tourne en « chasse au bug » avec un client difficile, le

rôle de modérateur du ScrumMaster est alors indispensable pour rappeler la chaîne de remontée des

bugs, et ne pas retarder la revue de sprint.

En reprenant l’analogie d’un match de rugby, on peut comparer la rétrospective de sprint à la discussion

« d’après match ». A partir des expériences tirées du développement du sprint courant, l’équipe identifie

ce qui marche bien pour elle, ce qui marche moins bien, et trouve collectivement ce qu’il faut modifier au

processus qu’elle utilise.

C’est une pratique d’amélioration continue amenant à l’adaptation des processus, à la capitalisation des

connaissances et à l’change de points de vues. Elle prend généralement la forme d’un brainstorming entre

tous les acteurs de l’équipe.

Une fois tous les points évoqués, l’équipe décide de trois choses à faire pour améliorer l’itération suivante

(par exemple : travailler en binôme une heure par jour, réaliser les tests d’acceptations plus tôt dans le

cycle, impliquer d’avantage le client).