La présente description des Méthodes Agiles
permet de décrire les principes sur lesquels les Parties ont entendu
réaliser le projet. Les autres documents contractuels de rang
inférieur ne peuvent déroger aux grands principes exposés,
même si expressément ou tacitement ils peuvent adapter aux besoins
particuliers les modalités de sa mise en oeuvre, notamment dans le
PQS.
Principes des Méthodes Agiles
Le spectre du développement dit agile
repose sur un certain nombre de principes et en particulier :
o Un pilotage orienté Produit : les
critères de succès sont explicités dès le
démarrage du projet et font l'objet d'une attention permanente.
L'analyse de valeur du logiciel permet d'arbitrer en permanence pour optimiser
la valeur produite en regard de l'effort fourni. Le Directeur de Produit
(appelé Product Owner - voir définition en article 2)
coopère avec le Client et l'Équipe pour maximiser la valeur du
logiciel livré, compte tenu des contraintes qui sont les siennes (budget
et délais, en particulier).
Le développement est priorisé par le risque et
la valeur métier. La production incrémentale permet
d'éradiquer les risques au plus tôt et de maximiser le revenu
potentiel, tout en autorisant un pilotage très transparent de la
progression.
Le changement de périmètre est possible et
passé au crible de l'analyse de valeur et de l'analyse de risque.
L'impact sur le planning est mesuré avec le Prestataire (LE
PRESTATAIRE), et un arbitrage éclairé peut être
effectué par le Client et le Prestataire.
Ainsi, le Client, en cas de périmètre revu
à la hausse peut, soit amender son Cahier des Charges en
conséquence, soit supprimer certaines fonctionnalités
jugées moins importantes pour intégrer les changements
souhaités et garder son budget projet inchangé. Pour cela, il
opèrera un système d'échange de Story Points (voir
définition en article 2) en accord avec le Prestataire. C'est le
mécanisme du Trade in / Trade out.
De la même manière, le Client peut revoir le
périmètre à la baisse (droit d'interruption
anticipée) dont les modalités sont définies au
Contrat.
o L'excellence des équipes : le
développement logiciel est une activité d'ingénierie qui
requiert des compétences pointues et variées. Les équipes
du Prestataire sont de petite taille, expérimentées,
pluridisciplinaires, dotées de toutes les compétences
nécessaires au
développement d'applications modulaires,
évolutives, performantes, documentées, intégrables et
exploitables. Pour ces équipes, la qualité n'est jamais une
variable d'ajustement, ni le test une activité négociable.
La stabilité de l'équipe est un facteur
clé du succès d'un développement, et le turn-over un
risque commun à tous les projets. Le Prestataire fait en sorte que sur
deux mois glissant les deux tiers de l'équipe soient stables.
Les membres de l'équipe sont identifiés et
présentés au Client qui peut ou non valider la pertinence des
profils dans le contexte projet. Les équipes sont constituées au
moins à 75% de membres senior (plus de 5 ans d'expérience).
o Un développement incrémental
: La réalisation est incrémentale. Les incréments, d'une
durée typique de 2 semaines, aboutissent à la livraison d'un
logiciel (éventuellement partiel) parfaitement opérationnel. Les
fonctionnalités développées durant l'incrément sont
systématiquement intégrées et testées. Seules
celles effectivement validées au terme de l'incrément sont prises
en compte dans la mesure de la progression. L'effet tunnel est ainsi
supprimé et le pilotage de l'avancement est rendu transparent.
o Qualité et productivité :
Les équipes du Prestataire disposent d'une usine logicielle performante,
et tous leurs membres sont rompus aux techniques de développement issues
de l'eXtreme Programming (XP) : gestion de source et propriété
collective du code, tests unitaires systématiques, tests
d'intégration et tests fonctionnels automatisés, conception
continue, refactoring, pair programming, build automatisé,
intégration continue, qualimétrie automatisée, normes de
développement, etc.
o Une transparence absolue : le
déroulement du développement est totalement transparent.
L'intégralité des artefacts est continuellement accessible au
Client. En particulier, selon les artefacts mis en oeuvre dans le cadre du
projet du Client : le code source, les documents de conception, les rapports de
tests, les rapports d'intégration continue, le tableau de bord
qualité, l'outil de gestion de projet, le portail projet (wiki)
où sont consignés tous les comptes-rendus. Une description plus
précise de ces outils est fournie dans la section consacrée
à l'usine logicielle. Une analyse des risques et des problèmes,
ainsi qu'une liste des actions prises pour les mitiger ou les supprimer sont
également maintenues publiques dans le portail projet.
Contrairement aux méthodes formelles
traditionnelles, les méthodes agiles sont davantage un système de
valeurs qu'une prescription rigoureuse quant à l'enchaînement
d'activités et de livrables intermédiaires.
Ce système de valeurs a été
formalisé en 2001 sous la forme du Manifeste Agile :
Individus et interactions plutôt que
les processus et les outils
Un logiciel qui fonctionne
plutôt qu'une documentation exhaustive
La collaboration entre
les parties plutôt que la négociation
contractuelle
Répondre au changement plutôt
que suivre un plan
La contractualisation d'une réalisation en
Méthodes Agiles est nouvelle sur le marché français tant
sur les concepts qu'elle sous tend que sur la nature des relations
instaurées entre le Client et le Prestataire.
Des incertitudes tant du point de vue technologique
que fonctionnel ont été identifiées par les deux Parties
avant la signature de ce Contrat.
Le Contrat prévoit donc en conséquence,
les modalités possibles d'ajustement du périmètre
contractuel.
Description de la démarche projet du Prestataire
et définitions de l'agilité
Le Prestataire réalisera le développement du
Logiciel en s'appuyant sur Scrum et XP (eXtreme
Programming), les deux méthodes agiles les plus
répandues dans l'industrie logicielle.
Ce paragraphe définit la terminologie agile qui est
utilisée dans le Contrat et qui le sera tout au long du projet.
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 méthodologies fonctionnent bien ensemble : elles adressent des
problématiques différentes et se complètent
mutuellement.
SCRUM
Davantage qu'une méthode formelle, Scrum peut
être vue comme un cadre méthodologique 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 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 risques. Scrum est
entièrement pilotée par la valeur métier - la gestion des
risques, en particulier, est réalisé au travers de ce prisme.
Le logiciel développé s'appelle en terminologie
Scrum, le Produit (Product). Scrum identifie trois acteurs
:
o 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 Product Owner est issu du personnel du Client et est
suffisamment disponible pour l'équipe (voir obligations du Client).
o le Scrum Master, membre de
l'Équipe, et dont la tâche principale est d'optimiser la
capacité de production de l'Équipe 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.
Il est enfin le garant vis-à-vis de l'Équipe, de la suppression
de tous les obstacles qui empêchent l'équipe
d'avancer. Dans certains cas, il se retournera vers le Client qui est,
en dernier recours, en charge de supprimer tous les obstacles
lorsqu'ils sont portés à sa connaissance.
o l'Équipe, 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
Équipe Scrum est d'être « auto-organisée », et
donc dépourvue de hiérarchie.
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 définit également trois artefacts :
o Le Burndown Chart, qui est une
représentation graphique de l'avancement du projet, visible de tous les
personnels Client et Prestataire impliqués dans le projet.
o 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 Product Backlog sont
rédigés sous forme de « User Stories ».
o Une User Story est une forme
simplifiée et faiblement détaillée de cas d'utilisation,
et doit se focaliser sur les objectifs métiers du logiciel
développé. Elle est accompagnée de critères
d'acceptance servant à sa validation (Scenario de test, script de test,
etc ..)
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'Équipe et le Product Owner 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 User Story
est déterminée. Les User Stories 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'Équipe 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'Équipe s'engage à produire durant
l'itération naissante, et liste les tâches correspondantes.
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 User Stories implémentées font
l'objet d'une démonstration publique à laquelle le Client
est tenu d'assister. Au même titre que les livraisons sont
incrémentales, les recettes, effectuées par le client, le sont
également.
Ainsi la recette incrémentale
nécessite que la recette du contenu développé pendant le
Sprint N doit impérativement être prononcée avant la fin du
Sprint N+1 (cf $ engagements).
Outre le Sprint Planning, voici les principales
cérémonies introduites par Scrum :
o 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'Équipe et le Product
Owner, 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.
o
XP comprend un certain nombre de pratiques dont la mise en
place est souvent associée à l'adoption des méthodes
agiles comme :
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 Product Backlog. Le personnel du Client, notamment le
Product Owner, doit être présent à cette
cérémonie.
o la rétrospective, qui réunit
l'Équipe, 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.
Scrum, on le voit, adresse la problématique du
processus de production du logiciel. Les promesses du développement
itératif et incrémental ne peuvent cependant pas être
tenues sans adopter un certain nombre de pratiques de génie logiciel,
réunies sous le terme eXtreme Programming (XP).
La complexité des User Story à
développer s'évalue en Points de Fonction (FP),
qui représente une mesure relative par rapport à un niveau de
complexité étalon.
La productivité de l'équipe s'appelle
la vélocité et s'évalue en Points de Fonction par
Sprint. Cette vélocité a tendance à augmenter dans le
temps jusqu'à se stabiliser à un niveau de «
croisière ».
Le Prestataire maintient aussi un tableau de bord de son
projet, le Kanban, dans lequel le Client trouvera
l'intégralité des informations nécessaires à sa
compréhension de l'état d'avancement de l'Équipe.
EXTREME PROGRAMMING - XP
La première des pratiques de l'eXtreme Programming, la
plus fondamentale également, est le test.
L'approche incrémentale suppose une vision minimaliste
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é. 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
et la recette incrémentale.
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
unitaires automatisés, et fait du taux de couverture
des tests - la proportion du code exécutée par les tests
unitaires - une métrique clé pour estimer le niveau de
qualité des développements.
o 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 unitaires et d'intégration -
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. A plus grande échelle,
l'intégration continue permet de tester de façon
régulière (au moins quotidiennement) l'intégration de
composants développés par des équipes distinctes.
o 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 favorisée par des pratiques telles que la programmation en
binôme qui permet 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.
o 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
(interfaces d'accès).
o Programmation en binôme (Pair
Programming), qui consiste à développer à deux
sur un même poste ; cette pratique n'est utilisée que
ponctuellement, 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ées en charge de l'Équipe : elle
permet d'intégrer plus rapidement les nouveaux développeurs.
o 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.
Certaines des pratiques de l'eXtreme Programming ont
irrigué Scrum - « 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.
