Cours : Méthodologie Agile
Enseignante : Ghada Feki
Introduction
• Définir la méthodologie du travail est une étape décisive pour
l’élaboration d’une application informatique.
• Le processus Agile permet de s’orienter vers l’opérationnel plutôt
qu’accumuler une masse d’informations difficile à traiter et qui fait
perdre de vue l’essentiel. Aussi, il cherche la collaboration avec le
client.
2
Introduction
• Le développement Agile tend à s’adapter aux changements qui
s’opèrent durant la réalisation du projet plutôt que suivre un plan
préétabli, qui ne prend pas en compte l’évolution de la situation.
• Dans les années 90, pour réagir aux méthodes non adaptées de
gestion de projet informatique, de nouvelles approches émergent :
les méthodes dites légères comme Scrum et Extreme programming
(XP).
3
Les concepts clés des méthodes agiles
o L’utilisateur revient au cœur du projet.
o L’humain également avec l’esprit d’équipe, la communication et la
collaboration.
o Un focus sur la simplicité, l’efficacité, l’intelligence collective.
o Une adaptation aux changements et un pilotage basé sur du
concret.
4
Méthodes agiles : un changement de paradigme
• Ces méthodes acceptent la réalité des projets informatiques : il est
très difficile, voire impossible de prédire et donc de planifier de
manière exhaustive tout un projet. Et ce, pour différentes raisons, de
définition du besoin, de communication, de complexité métier et
technique…
• Les projets ne sont pas généralement prédictibles, soit, il ne sert à
rien de perdre trop de temps à planifier dans le détail l’intégralité
d’un projet et de s’efforcer de suivre un plan irréaliste : 60% des
changements d’un projet informatique arrivent pendant la phase de
développement.
5
Spécifier et planifier / Productivité
• Les méthodes agiles partent du principe que spécifier et planifier dans les
détails l'intégralité d'un produit avant de le développer (approche
prédictive) est contre productif.
• Cela revient à planifier dans les détails un trajet "Paris - Lyon" en voiture
par les petites routes. Spécifiant chaque villes et villages traversés, l'heure
de passage associée, chaque rue empruntée dans les agglomérations, litres
d'essence consommés, kilomètres parcourus, etc. Les imprévus ne
manqueront pas d'arriver : embouteillages, déviations, travaux, sens de
circulation inversés, voire la panne, etc. Rendant votre planification et vos
spécifications très vite obsolètes. Combien de temps aurez vous passé à
planifier cet itinéraire, comment réagirez vous face à vos frustrations de ne
pas pouvoir appliquer votre plan à la lettre ?
6
Approche empirique
• L'idée consiste à se fixer un premier objectif à courts termes (une
grande ville par exemple) et se lancer sur la route sans tarder. Une
fois ce premier objectif atteint, on marque une courte pause et on
adapte son itinéraire en fonction de la situation du moment. Et ainsi
de suite jusqu'à atteindre la destination finale. On parle donc
d'une approche empirique.
• Dans le cadre d'un projet de développement logiciel, le client élabore
sa vision du produit à réaliser et liste
les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à
l'équipe de développement, communique directement avec elle
(plutôt que par papier) qui estime le coût de chaque élément de la
liste. On peut ainsi se faire une idée approximative du budget global.
7
Itération
• L'équipe sélectionne ensuite une portion des exigences à réaliser
dans une portion de temps courte appelée itération. Chaque itération
inclut des travaux de conception, de spécification fonctionnelle et
technique quand c'est nécessaire, de développement et de test. A la
fin de chacune de ces itérations, le produit partiel mais utilisable est
montré au client. Ce dernier peut alors se rendre compte par lui
même très tôt du travail réalisé, de l'alignement sur le besoin.
L'utilisateur final quant à lui peut se projeter dans l'usage du produit
et émettre des feedbacks précieux pour les futures itérations.
• La visibilité ainsi offerte est clef. Cette transparence peut également
apporter davantage de confiance et de collaboration dans la relation
client/fournisseur. Les risques quant à eux sont levés très tôt.
8
Time to market
• Si le client a priorisé avec soin son besoin, il peut saisir l'opportunité
d'accélérer le "time to market" si il estime que le produit en l'état
(partiel) peut aller en production.
• Économisant ainsi son budget et récoltant un premier retour sur
investissement. Il a aussi la possibilité de changer en cours de route la
priorité des fonctionnalités qui n'ont pas encore été développées
(prévues pour les itérations futures). Afin de retarder une
fonctionnalité dont le besoin n'est pas mûr, ajouter une nouvelle
fonctionnalité cruciale en échange du retrait d'une autre (respectant
ainsi budget et délais), etc
9
Cadre de projet
Définir un cadre (besoins, budget, planning) macroscopique et piloter le
projet à l’intérieur de ce cadre pour l’optimiser, en priorisant, supprimant,
modifiant ou ajoutant les fonctionnalités, tant que l’on répond aux besoins
exprimés. Les ajustements se font au niveau de la solution, de ses
fonctionnalités.
Ce changement a beaucoup d’implications :
• Il va falloir se doter d’une méthode et d’une organisation qui permettent ce
pilotage, c’est à dire sachant s’adapter aux changements en cours de route,
et plutôt rapidement !
• C’est aussi accepter que l’on ne maîtrise pas l’ensemble du projet dans le
détail.
10
L’approche traditionnelle
11
L’approche traditionnelle
12
L’approche Agile
13
Hypothèse des méthodes agiles
• On suppose toujours que le besoin de l’utilisateur est bien compris,
mais la solution qu’on lui propose est-elle la bonne ? Nous allons
valider cela au plus tôt avec les utilisateurs, et finaliser la solution
ensemble, éventuellement par de la co-construction.
• L’optimisation du projet se base alors sur la création de valeur
ajoutée. La valeur ajoutée est celle perçue par l’utilisateur que ce soit
un gain de productivité, d’ergonomie, de simplicité, d’accessibilité…
• Le changement en cours de route est une opportunité pour créer un
peu plus de valeur ajoutée que prévue, cela a un coût. L’hypothèse de
l’agilité, pour qu’elle soit pérenne, est que le surcoût de l’approche
itérative est moins important que la valeur ajoutée qu’elle créée.
14
Objectifs des méthodes agiles
Les objectifs sont multiples, certains focalisent sur un meilleur produit,
d’autres une réussite du projet, beaucoup sur un recentrage sur
l’humain et l’intelligence collective.
Le top 3 des objectifs est :
• Savoir gérer les changements de priorité
• Réduire les délais, pour principalement améliorer le Time To Market
• Augmenter la qualité du produit pour un meilleur usage
15
Organisation d’une équipe Agile
• Pour répondre à cela, les approches agiles proposent une conception
itérative, une livraison incrémentale, sur des cycles courts de quelques
semaines, généralement contraint par le temps, appelés des sprints.
• Pour que cela marche, les équipes sont plutôt petites, et pluridisciplinaires,
c’est-à-dire, ayant toutes les compétences et connaissances en interne
pour transformer une demande en une solution.
• La grande différence avec l’approche traditionnelle est que ces équipes
sont auto-organisées. Elles s’engagent sur un objectif pour le sprint, puis
font ce qu’il faut pour atteindre cet objectif. Il n’y a plus de chef de projet a
proprement parlé, le micro management, entre autres, est délégué à
l’équipe elle-même.
16
Organisation d’une équipe Agile
Cela soulève la question de la posture
managériale et de la place d’un manager
agile ?
17
Organisation d’une équipe Agile
18
L’écosystème Agile
Une fois qu’une organisation décide d’adopter une gestion de
développement Agile, il reste encore à choisir la méthodologie
la plus adaptée à son projet.
Les méthodes Agiles disponibles sont
nombreuses et peuvent être une source de
confusion !
19
L’écosystème Agile
Les méthodes Agiles les plus populaires en usage aujourd’hui sont:
• Extreme Programming (XP),
• Scrum,
• Kanban,
• Le Lean IT,
• Feature Driven Development (FDD),
• Agile Unified Process (Agile UP ou AUP),
• Crystal
•…
20
Extreme Programming (XP)
• Extreme Programming (XP) est une méthode agile de gestion de projet
particulièrement bien adaptée aux projets de développement
informatique.
• Le principe fondamental de la méthode XP est de faire collaborer
étroitement tous les acteurs du projet et d’opter pour des itérations de
développement très courtes. La planification des tâches reste très souple et
l’estimation des charges simplifiée par des projections à très court terme.
Ainsi la correspondance entre ce qu’attend le client et les réalisations est
garantie. Les fonctionnalités sont livrées régulièrement, afin d’être testées
et validée au travers de prototypes opérationnels.
• L’Extreme Programming préconise également le travail en binôme des
développeurs, facilitant ainsi la production d’un code simple, facilement
lisible et maintenable.
21
Extreme Programming (XP)
• Complémentaire à Scrum, voire indispensable pour une bonne partie
de ses pratiques, elle permet de mettre l’accent sur la qualité de ce
que l’on produit. XP permet de maîtriser la dette technique du code
au fil du temps et donc garder un code très évolutif.
• Les pratiques les plus connues sont le pair programming, la
conception émergente, le test driven development (TDD, coder les
tests avant le code), le refactoring, la revue de code, l’intégration
continue (voire déploiement continu)…
• Cette méthode est plutôt à destination des développeurs, des
testeurs, des architectes.
22
Scrum, la méthode agile la plus utilisée
• Scrum n’adresse pas la question des pratiques de développement en tant
que tel, mais plus l’organisation, le cadre, le pilotage, les rôles et
responsabilités. Elle permet de maîtriser la production de l’équipe dans un
environnement incertain, en pilotant par la valeur.
• On trouve une planification à plusieurs niveaux : de la roadmap au pilotage
de la release, au sprint. Un sprint est une itération, contrainte par le temps,
généralement quelques semaines, avec un objectif. L’équipe doit répondre
à cet objectif avec un incrément du produit logiciel, démontrable.
• Les décisions sont prises par l’équipe au jour le jour au cours de la mêlée
(d’où le nom de Scrum, la mêlée au rugby) ; Ainsi que la planification, les
estimations et l’amélioration continue qui sont collectives et régulières, à
chaque sprint.
23
Scrum
• Cette méthode est à destination de toute l’équipe, mais intéresse tout
particulièrement les managers, les responsables produit, les responsables
d’équipe.
• Le principe de Scrum est de pouvoir modifier la direction prise par le projet
au fur et à mesure de son avancement.
• La mêlée est donc une phase essentielle dans la gestion de projet. Si les
conditions de réussite ne sont pas remplies, alors il faut réorienter le projet
pour repartir sur de meilleures bases. Le client est étroitement impliqué
grâce à la livraison régulière de prototypes opérationnels permettant de
valider les développements.
• Cette gestion dynamique permet de s’assurer de la correspondance entre
le besoin exprimé et le produit livré, et de réorienter au besoin les futurs
développements.
24
Scrum
25
Scrum
26
Kanban, une approche plus au fil de l’eau
• Si l’on n’a pas de projet mais plutôt un flux de demandes, d’affaires,
de petits projets ? Comment être agile, dans ce cas de forte
incertitude ?
• La solution est la méthode Kanban : maîtriser le flux de travail en
améliorant le processus pour réduire les délais, l’encours. L’objectif
est d’aller vers du flux tiré.
• Kanban ne fait pas partie des méthodes agiles directement car elle ne
suit pas complètement les valeurs du Manifeste Agile. Et pourtant,
elle apporte tous les bénéfices de l’agilité mais de manière plus
douce, plus évolutive.
27
Kanban, une approche plus au fil de l’eau
28
Lean IT
• On commence souvent par le Lean IT pour aider les équipes de supports. En tant que
démarche d’amélioration continue, on l’utilisera dans un second temps sur la partie
réalisation avec Scrum ou Kanban pour avoir une équipe performante.
• Les principes du Lean IT :
oÉliminer les sources de gaspillage
oFavoriser l’apprentissage
oReporter les décisions
oLivrer vite
oRespecter les personnes et impliquer l’intelligence collective
oConstruire la qualité intrinsèque
oOptimiser le système dans son ensemble
• Le Lean IT, tout comme le Kanban, est à destination des managers et agents du
changement et de l’amélioration continue, et toute l'équipe.
29
Software Craftmanship
• Ce mouvement permet de réaffirmer que le développement logiciel
est une activité artisanale, loin de l’usine logicielle et qui ne se
résume pas à produire des lignes de code. C’est du XP relooké, sans
que cela soit péjoratif. Il existe un manifeste du Software
Craftmanship.
• Il ne suffit pas que le logiciel fonctionne, encore faut-il que le code
produit soit de qualité.
• Ce mouvement intéressera plus particulièrement les développeurs.
30
DevOps
• Scrum repose sur le principe d’une équipe pluridisciplinaire, nous l’avons
vu. Cela n’est pas toujours possible. Il est souvent difficile d’avoir la partie
exploitation présente dans une équipe Scrum.
• Or la réussite d’un produit ne se fait pas seulement lors de la conception
mais également au cours de son exploitation. Mettre en collaboration ces
deux équipes au plus tôt dans le projet, voilà l’objectif du mouvement
DevOps, fluidifier les échanges du développement à l’exploitation, apporter
les pratiques et les outils pour cela.
• DevOps et Kanban ensemble ont notamment contribué à passer de
l’intégration continue au déploiement continu (plusieurs fois par jour en
production potentiellement), au plaisir des startups du web.
• DevOps intéressera plus particulièrement développeurs et
exploitants/opérations. 31
Méthode Lean startup
• Lean Startup : processus de recherche d’un business model viable et
scalable dans un environnement incertain.
• Le Lean Startup est un savant mélange de Customer Development, de
méthodes agiles et de Lean. L’agilité permet un optimum local sur une
solution, avec le Lean startup on va chercher un optimum global sur
le business model.
• Cette méthode est à destination des managers, marketing, directeur
et chef produit, Product Owner ; mais également coach agile pour
amener l’agilité côté métier.
32
Méthode Lean startup
33
Feature Driven Development (FDD)
• Le Développement Dirigé par les Fonctionnalités est une méthode de
gestion de projet basée sur la gestion des risques. Les
développements sont organisés en itérations courtes autour de
fonctionnalités testables par l’utilisateur. L’utilisateur est ainsi
impliqué dans les développements, peut suivre l’avancement du
projet et la validation des fonctionnalités. Aucune méthode de
programmation n’est préconisée, c’est réellement la fonctionnalité
qui est mise en avant.
34
Feature Driven Development (FDD)
• Un projet géré par FDD est découpé en plusieurs grandes étapes. La
première consiste en la constitution d’un modèle général du produit, qui va
définir le périmètre global de réalisation. Vient ensuite la construction de la
liste complète des fonctionnalités à réaliser. Il est impératif lors de cette
étape d’impliquer au maximum le client. Ces fonctionnalités sont
finalement regroupées en fonction de leurs caractéristiques communes et
priorisées. Les deux dernières étapes verront le jour sous la forme
d’itérations, et englobent d’une part la conception technique des
fonctionnalités, puis leur réalisation.
• Cette méthode donne une importance plus grande à la phase de
conception, quitte à démarrer la réalisation plus lentement, afin d’avoir un
modèle plus solide.
35
Test driven development (TDD)
• Le développement piloté par les tests est une technique de
développement qui associe l’écriture des tests unitaires, la
programmation et le remaniement du code. Les tests unitaires sont
écrits avant le code. Chaque test décrit un élément de la
fonctionnalité. Le développeur écrit le minimum de code possible
pour que le test passe, et qu’il échoue pour des raisons prévisibles.
Au fur et à mesure de l’avancement, le code source doit être simplifié
autant que nécessaire et continuer à passer les tests. Les tests
s’accumulent durant le développement et sont exécutés
automatiquement de façon très régulière.
• Le TDD est toujours associé à des outils d’automatisation de tests
unitaires liés au langage de programmation utilisé.
36
Rational Unified Process (RUP)
• Cette méthode est un mélange des pratiques classiques et agiles de
gestion de projet. Les développements sont itératifs et incrémentaux.
Chaque itération respecte un cycle comprenant quatre phases qui
sont lancement, conception, réalisation et livraison.
• Les développements sont guidés par des cas d’utilisation. On
commence par les fonctionnalités génériques pour aller ensuite de
plus en plus vers le spécifique.
37
Agile Unified Process (Agile UP or AUP)
• Agile Unified Process (ou Processus Unifié Agile) est une version simplifiée du
Rational Unified Process, ou RUP. Il s’agit d’une méthode de développement
d’applications métier utilisant les techniques agiles du TDD (Test Driven
Development ou développement piloté par les tests), du MDD (Model Driven
Development ou développement piloté par le modèle) et de la gestion du
changement.
• La méthode est divisée en quatre phases :
oLancement : identification du périmètre du projet, définition de la ou des
architectures potentielles pour le système, implication des intervenants et
obtention du budget.
oConception : définir l’architecture du système et démonstration de sa
pertinence.
oRéalisation : développement du logiciel lors d’un processus incrémental dans
l’ordre de priorité des fonctionnalités.
oLivraison : validation et déploiement du système en production.
38
Crystal (Clear/Orange)
• La méthode Crystal Clear est particulièrement adaptée aux petites
équipes de développement. Idéalement, l’équipe est composée d’un
architecte et de deux à six ou sept développeurs, situés à proximité
les uns des autres, de façon à faciliter la communication, dans un
local calme. Des tableaux blancs servent de supports afin que tous
aient un accès rapide à toutes les informations. Les rythmes de
développement et de livraison sont rapides (toutes les deux semaines
ou une fois par mois) afin que les utilisateurs puissent passer les tests.
• Durant tout le processus de développement, l’équipe se remet en
question en permanence afin d’améliorer continuellement sa façon
de travailler.
39
Dynamic Systems Development Method (DSDM)
Cette méthode s’articule autour de neufs grands principes qui sont :
o la participation des utilisateurs
o l’autonomie de l’équipe projet
o la transparence des développements
o l’adéquation avec le besoin
o le développement itératif et incrémental
o la réversibilité permanente
o la synthèse du projet
o les tests automatisés et continus
o la coopération entre tous les intervenants.
40
Dynamic Systems Development Method (DSDM)
• Le projet commence par une étude de faisabilité afin de décider s’il
faut le faire ou non.
• Un rapport est rédigé, et éventuellement, un prototype est créé pour
démontrer la faisabilité de l’application.
• S’il a été décidé de continuer, une analyse fonctionnelle est réalisée et
les spécifications sont rédigées.
• A partir de ce moment-là, des itérations de conception technique et
de développement sont mises en place, puis au final, l’application est
livrée en production.
41
Adaptive software development (ASD)
• ASD est une méthode de développement rapide d’applications. Le
principe consiste à automatiser et à industrialiser un maximum de
processus. Des outils de modélisation sont utilisés et une usine
logicielle est mise en place de façon à générer un maximum de code
informatique automatiquement. Un atelier de génie logiciel (AGL)
permet ensuite aux développeurs de modifier l’application ainsi
générée. Pour finir, une usine de livraison assure l’automatisation de
l’ensemble des processus de déploiement.
• La méthode ASD est indépendante de toute méthodologie ou langage
de programmation.
42
Behavior driven development (BDD)
• Dans cette méthode, c’est le langage naturel qui est mis en avant.
Plutôt que de décrire les solutions techniques à mettre en œuvre, ce
sont les objectifs des fonctionnalités qui sont décrites par les
utilisateurs. Ces derniers sont donc particulièrement impliqués dans
le processus de fabrication. Le comportement cible de l’application
est donc décrit au travers d’exemples permettant aux développeurs
de mieux cerner les objectifs.
• Les expressions « Etant donné », « quand », « alors » et « et » sont
employées dans les scénarios décrits, qui sont également utilisés pour
créer des séries de tests de non régression. Les scénarios sont écrits
collectivement avec le client, les développeurs et toutes les équipes
impliquées dans le processus.
43
Domain-driven design (DDD)
• Le Domain Driven Design est une technique de conception
d’applications informatiques. La conception est centrée sur le
domaine métier et non sur les aspects techniques. Elle permet aux
équipes techniques et fonctionnelles de communiquer ensemble afin
d’obtenir un modèle commun de l’application, compréhensible par
tous. Les développeurs acquièrent ainsi une meilleure connaissance
du fonctionnel et de son vocabulaire spécifique, et l’équipe métier a
une meilleure vision des contraintes techniques.
• Grâce à cet outil, on obtient une meilleure communication entre les
différents intervenants et une conception modulaire facilitant à terme
la maintenabilité de l’application et la réutilisabilité de ses
composants.
44
Disciplined Agile Delivery (DAD)
• DAD est une méthode d’aide à la décision et d’industrialisation qui a pour
objectif de simplifier l’intégration des processus liés à une gestion de projet
incrémentale et itérative, agile. Elle s’applique de façon particulièrement
efficace en association avec une méthode de développement telle que
Scrum ou Lean. Il s’agit d’une méthode hybride, destinée à faciliter
l’adoption de l’agilité au sein d’une organisation de taille significative.
• Tous les aspects de l’intégration de l’agilité dans le développement logiciel
sont pris en charge en tenant compte du contexte global du projet et
surtout de l’entreprise. Lorsqu’une méthode agile doit être appliquée à un
projet impliquant des équipes importantes, DAD peut être d’un grand
secours pour faciliter l’adoption des différents processus.
45
Enterprise Unified Process (EUP)
• EUP est une extension des méthodes d’industrialisation comme DAD ou
comme les dérivés de Unified Process (UP), ou des méthodes de
développement agile comme Scrum. EUP apporte deux autres phases à la
fin des cycles des autres méthodes agiles :
• Mise en production : maintenance en condition opérationnelle des
systèmes déployés.
• Retrait de production : processus de retrait de la production des systèmes
déployés.
• La phase de retrait de production peut être mise en œuvre pour plusieurs
raisons comme le remplacement complet du système, la fin du support de
la version courante, la redondance du système ou encore l’obsolescence de
l’application.
46
Avantages méthodes agiles
• Toutes ces méthodes reposent sur les individus qui les utilisent. On
parle de collaboration, de respect, de transparence, de rythme
soutenable. Bien comprendre l’état d’esprit de ces approches, l’être
agile, plus que le faire agile, est primordial.
• En fait, les méthodes agiles reposent sur une approche empirique.
Elles ne sont pas des méthodes sur étagère complètement décrites.
Elles sont des cadres à l’intérieur desquels vous allez faire votre
implémentation de l’agilité compte tenu de votre contexte, de votre
maturité, de vos contraintes.
• D’autre part, votre implémentation agile va naturellement évoluer au
cours du temps.
47
Le cadre méthodologique Scrum
Scrum est la méthode la plus utilisée
48
Le cadre méthodologique Scrum
• Pourquoi traiter de Scrum en particulier ?
• Tout simplement parce que Scrum est de très loin la méthodologie la
plus utilisée parmi les méthodes agiles existantes. Elle est donc la
plus éprouvée, documentée et supportée. Livres, blogs, formations,
vidéos, associations, conférences traitant de Scrum ne manquent pas
et bon nombre de ces ressources sont accessibles gratuitement.
• On pourrait pratiquement parler d'un standard Agile. Un autre atout
important : Scrum est simple à comprendre. Sa maîtrise est en
revanche difficile.
49
Le cadre méthodologique Scrum
Scrum est considéré comme un cadre ou « framework » de gestion de
projet. Ce cadre est constitué d'une définition des rôles, de réunions et
d'artefacts.
Scrum définit 3 rôles :
• Le « Product Owner » qui porte la vision du produit à réaliser
(représentant généralement le client).
• Le « Scrum Master » garant de l'application de la méthodologie
Scrum.
• L'équipe de développement qui réalise le produit.
50
Le cadre méthodologique Scrum
Les artefacts de la méthodologie Scrum :
• « Product Backlog » : c’est la liste d’exigences fonctionnelles et non
fonctionnelles souhaitées dans le produit (projet).
• « Sprint Backlog » : c’est une liste des taches que l’équipe s’est
engagée à compléter à la fin de l’itération. C’est un sous ensemble de
produits Backlog à produire durant le sprint.
• « Incrément » : c’est un produit partiel potentiellement utilisable,
c’est le résultat d’un sprint..
51
Le cadre méthodologique Scrum
52
Vie d'un projet Scrum
La vie d'un projet Scrum est rythmée par un ensemble de
réunions (cérémonies) clairement définies et strictement
limitées dans le temps (timeboxing).
53
Vie d'un projet Scrum
• Planification du Sprint (Sprint = itération) : au cours de cette réunion,
l'équipe de développement sélectionne les éléments prioritaires du
« Product Backlog » (liste ordonnancée des exigences fonctionnelles
et non fonctionnelles du projet) qu'elle pense pouvoir réaliser au
cours du sprint (en accord avec le « Product Owner »).
• Revue de Sprint : au cours de cette réunion qui a lieu à la fin du
sprint, l'équipe de développement présente les fonctionnalités
terminées au cours du sprint et recueille les feedbacks du Product
Owner et des utilisateurs finaux. C'est également le moment
d'anticiper le périmètre des prochains sprints et d'ajuster au besoin la
planification de release (nombre de sprints restants).
54
Vie d'un projet Scrum
• Rétrospective de Sprint : la rétrospective qui a généralement lieu
après la revue de sprint est l'occasion de s'améliorer (productivité,
qualité, efficacité, conditions de travail, etc) à la lueur du "vécu" sur le
sprint écoulé (principe d'amélioration continue).
• Mêlée quotidienne : il s'agit d'une réunion de synchronisation de
l'équipe de développement qui se fait debout (elle est aussi appelée
"stand up meeting") en 15 minutes maximum au cours de laquelle
chacun répond principalement à 3 questions : « Qu'est ce que j'ai
terminé depuis la dernière mêlée ? Qu'est ce que j'aurai terminé d'ici
la prochaine mêlée ? Quels obstacles me retardent ? »
55
Projet Scrum
• L'organisation générale
• Travaux préparatoires
• L'approche Scrum propose de commencer par lister les exigences du
client afin de produire le « Product Backlog ». Voir l'exemple ci
dessous pour la réalisation d'un site d'e-commerce :
56
Projet Scrum
• L'unité de coût (ou complexité) de la colonne "Estimation" est arbitraire, on
procède généralement par relativité en définissant un étalon de base.
• Par exemple, "voir le détail d'un article" étant une exigence simple, elle
servira d'étalon et son estimation convenue sera par exemple de "1 point",
"modifier les caractéristiques d'un article" étant 2 fois plus compliquée, son
estimation sera de "2 points", etc.
• Le recours à une telle unité (plutôt que des €) permet de faciliter
l'ordonnancement du Product Backlog, la planification des sprints et des
releases. D'autre part il souligne le fait qu'il ne s'agit que d'une estimation
(par définition fausse) et non pas un chiffrage en tant que tel.
57
Projet Scrum
• Le Product Owner ordonnance ensuite la liste en fonction de la valeur
ajoutée métier, du coût estimé de chaque exigence et des risques
identifiés.
• Les exigences seront réalisées dans l'ordre ainsi défini selon les
contraintes de l'équipe de développement et les éventuelles
dépendances (exigence D à faire avant l'exigence X).
• On fixe ensuite la durée des sprints durant laquelle un certain nombre
d'éléments du « Product Backlog» seront réalisés.
• L'objectif de Scrum consiste à produire le plus tôt possible la plus
grande valeur possible, afin de créer des opportunités d'accélération
du "Time to market".
58
Enchaînement des sprints
• Une fois que le Product Backlog est prêt et que la durée du sprint est
fixée en accord avec le client, il n'y a plus qu'à remplir le sprint avec
des éléments du Product Backlog (planification de sprint).
• C'est également à ce moment que le Product Owner exprime plus
précisément son besoin (qu'il aura affiné au préalable) pour
permettre à l'équipe de développement d'estimer plus précisément la
charge de travail du sprint. Inutile pour autant de réaliser la
conception détaillée en séance, des ateliers dédiés pourront avoir lieu
en cours de sprint.
59
Enchaînement des sprints
• Le Product Owner peut à tout moment revoir la priorité des exigences
qui n'ont pas encore été planifiées dans le sprint en cours. En
revanche, les exigences engagées dans le sprint en cours sont
"sanctuarisées", seule l'équipe de développement à le pouvoir de
modifier le périmètre du sprint en cas d'avance ou de retard.
• Chaque sprint se termine par la revue de sprint suivie de la
rétrospective. Le sprint suivant s’enchaîne à la suite selon le même
cycle et ainsi de suite jusqu'au dernier sprint de la release.
60
Mesure de l'avancement
• Grâce aux estimations individuelles des exigences du « Product
Backlog » ainsi qu'à la segmentation en sprints, on peut aisément
produire un graphique de suivi d'avancement représentant l'évolution
du travail accompli en fonction du temps (voir illustration ci contre :
total de "points" d'estimation des exigences terminées en bleu et
charge totale de "points" de la release en rouge).
61
Mesure de l'avancement
62
La contractualisation agile
• La contractualisation d'un projet agile n'est pas la partie la plus facile
étant donné que le périmètre est par définition variable. La régie
ferait bien l'affaire mais difficile de rassurer le client avec un tel
contrat.
• Le contrat au forfait domine; surtout sur les gros projets.
Malheureusement pour le fournisseur - dans le cadre d'un forfait
classique - tous les risques sont pour lui (aussi bien sur un projet
agile que sur un projet traditionnel).
• On peut limiter ces risques en prenant quelques précautions, mais on
limite également la souplesse offerte par une approche Agile.
63
La contractualisation agile
• Cela ne veut pas dire qu'il n'existe pas de solutions. La forfaitisation
de chaque itération avec la possibilité pour le client d'arrêter le
contrat à la fin de chaque itération est assez intéressante.
• Ainsi que le principe de changement d'exigence : réalisation d'une
exigence imprévue en échange du retrait d'une autre moins
importante, de priorité faible et de même coût.
64
