3.1.
Manifeste de la méthode Agile
Le manifeste de la méthode Agile [Agile 01] énoncée dans ses douze principes dans la Figure 1: le Manifeste
Agile tiré de [Agile 01] ci-dessous a été signé en février 2001 par 17 professionnels de la programmation dont K.
Schwaber, J. Sutherland et M. Beedle qui sont les principaux auteurs de la méthode Scrum ([Schwaber… 02] et
[Schwaber…17]). La méthode Agile est aujourd’hui très répandue et repose sur quelques idées simples telles
l’attention et le dialogue constant avec le client ou l’utilisateur. Ce dialogue permet à la fois de mieux
comprendre et de suivre au plus près l’évolution du besoin client. Elle ouvre la porte à l’acceptation de
changements pouvant être tardif durant le développement du produit ce qui se démarque nettement des méthodes
plus classiques comprenant une spécification qui une fois figée sera suivie d’un développement puis de tests
telles que le cycle de vie du logiciel en V ou en cascade. Deux autres points importants du manifeste de la
méthode Agile sont d’une part l’intention de délivrer régulièrement de fréquentes versions incrémentales du
produit et d’autre part la volonté forte de maintenir et constamment améliorer les performances de l’équipe de
développement à travers des revues et des retours d’expérience permettant également d’adapter les différents
outils de production et processus aux besoins d’évolution du produit.
Énoncé des douze principes de la méthode Agile
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s
competitive advantage.
3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
4 Business people and developers must work together daily throughout the project.
5 Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6 The most efficient and effective method of conveying information to and within a development team is face-
to-face conversation.
7 Working software is the primary measure of progress.
8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9 Continuous attention to technical excellence and good design enhances agility.
10 Simplicity—the art of maximizing the amount of work not done—is essential.
11 The best architectures, requirements, and designs emerge from self-organizing teams.
12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
Figure 1: le Manifeste Agile tiré de [Agile 01]
Dans ce qui suit, nous ferons parfois référence à l’un ou l’autre de ces principes au moment de son application.
3.2. Composants principaux du processus scrum
La méthode scrum opère sur un ensemble de composants que l’on peut séparer en trois (comme pour de très
nombreuses méthodes au demeurant) : les artefacts, les étapes principales du processus, les différents rôles que
les participants remplissent.
1. Les artéfacts :
le « backlog produit » contient les diverses fonctions et caractéristiques non fonctionnelles qu’il est désirable de
développer. Ces fonctions peuvent être décrites dans des « story cards » qui peuvent être disposées sur un
tableau de type kanban afin d’obtenir une vue synthétique du statut des travaux en cours. Le « backlog de
sprint » est un sous-ensemble du backlog produit. Le tableur de charge de travail (graphique d’avancement ou
burndown chart) est utile afin de mesurer la charge de travail restant à effectuer, de surveiller et constater la
convergence du sprint.
2. Les étapes du processus :
le « sprint » est le niveau d’organisation le plus petit ayant pour but le développement d’un quantum du livrable ;
la réalisation de livraison produit (ou version produit) (release en anglais). Les réunions journalières (daily
3
meetings) obligatoires des équipes de développement sont conçues pour rendre compte de l’évolution des
travaux en cours et de pouvoir être aussi prédictible que possible.
3. Les équipes et les différents rôles :
Le « gardien du produit » maintient le backlog produit. Le « maître de scrum » anime un sprint, les membres de
l’équipe de développement ou « équipe scrum » vont participer aux différents sprints qui constituent le
développement d’une version du produit.
Dans la suite, nous décrirons ces éléments de la méthode scrum. En effet, ils nous ont semblé saillants dans nos
deux expériences. Nous essayerons de préciser quand et comment nous avons parfois divergé afin d’une part
prendre en compte le fait d’être une jeune pousse aux ressources limitées et d’autre part intégrer la méthode avec
des artéfacts existant ainsi qu’avec tous les participants à la réalisation du produit. Souvenons-nous qu’une
méthode n’a pas à être suivie à la lettre mais plutôt dans son esprit. Elle doit toujours être adaptée, intégrée au
milieu dans lequel elle va être utilisée.
3.3. « Pigs » et « chickens »
Les « pigs » et les « chickens » (termes qu’on se refusera à traduire par cochons et poulets tant différentes sont
les connotations attachées à ces mots entre l’anglais et le français) sont deux attributs séparant en deux camps
l’ensemble des participants à la réalisation du produit. Les désignations proviennent d’une blague américaine
[Schwaber 04] dont la chute insinue que les « pigs » vont en quelque sorte donner leur sang pour le succès d’un
projet, ils sont donc directement engagés ; alors que ce ne sera nettement pas le cas des « chickens » qui
s’impliquent et contribuent ou a minima observent et encouragent les « pigs ».
Dans nos deux expériences, les ingénieurs ont vraiment tout donné pour livrer leurs développements dans les
temps avec la plus haute qualité possible ; sans conteste possible ils faisaient partie des « pigs » tout comme le
gardien du produit. Dans le cadre de jeunes pousses les enjeux sont tellement élevés sur le fait de livrer le plus
tôt possible que tous les membres de l’entreprise s’intéressent de près ou de loin à la réalisation du
produit (surtout si l’entreprise n’a qu’un seul produit comme ce fut le cas dans nos deux expériences!); à ce titre,
tous les membres de l’entreprise sont au moins des « chickens ». Ainsi, le management (tout comme les clients)
font partie des « chickens ». Qu’ils soient « pigs » ou « chickens », tous les acteurs de l’entreprise surtout si
celle-ci est une jeune pousse sont soumis à de hautes doses de stress pour délivrer dans les temps le meilleur
produit possible. Les « chickens » ne sont pas simplement en train d’observer calmement la réalisation du
produit. Certains « chickens » essayeront d’orienter le développement ou de changer certaines fonctions ; ce sera
le rôle du gardien du produit ou du maître de scrum de protéger les équipes de ces pressions. D’autres
« chickens » loin d’être inutiles peuvent donner de précieuses idées pour le backlog produit ; ils se doivent par
ailleurs d’être présents quand les choses tournent mal, dans des situations de crise et de s’impliquer afin de
trouver des solutions.
4. « BACKLOG PRODUIT » ET AUTRES ARTEFACTS DU PRODUIT
4.1 Backlog produit, story card et backlog de sprint
Le backlog produit et sa décomposition en backlogs de sprint est un artefact central de la méthode scrum. Le
backlog produit contient la liste ordonnée de tous les éléments du produit qui nécessitent un développement. Les
éléments du backlog produit peuvent être très variés et peuvent être fonctionnels ou non ; de simples défauts
venant de la base d’utilisateurs via l’équipe de support ou des composants nécessitant des développements
importants.
Ces éléments sont identifiés soit au cours des développements et de la qualification des versions précédentes, soit
le long des travaux de la direction technique, mais surtout lors des nombreuses rencontres avec les clients ou
utilisateurs, en particulier lors des rencontres avec les groupes utilisateurs (User Groups) qui, bien sûr restant en
ligne avec un des principes essentiels de la méthode Agile, ont un poids important sur l’évolution du produit.
Dans ce dernier cas, ces éléments ou « histoires d’utilisateurs» (user story) peuvent être décrits de manière
concise dans des « story cards ». Ces cartes auront un format bien défini. Comme le montre la Figure 2, elles ont
une identité, un titre et une description des actions composant « l’histoire ». Ces actions mettent en jeu un ou
plusieurs participants qui chacun tiennent un rôle supporté par le produit. Enfin, la carte doit également décrire
les conditions que doit satisfaire la réalisation de l’histoire. Ces conditions pourront servir plus tard à engendrer
des tests et à valider le produit. Ces histoires d’utilisateurs peuvent de plus avoir une première estimation de la
charge de travail nécessaire pour les développer ; elles sont alors au cœur de la méthode de programmation