Scott Ambler nous présente dans cet article du Doctor Dobb's journal (http://www.ddj.com) son approche des exigences complexes pour les projets Agiles.

1. Exigences Complexes dans un Projet Agile
Scott W. Ambler
Les exigences complexes et les projets agiles sont tout sauf simples. Cependant, avec de
la discipline et un peu de chance ….
Scott travaille en qualité de Practice Leader Agile Development pour IBM Rational.
Traduction par Emmanuel Hugonnet de l’article quot;Complex Requirements On An Agile
Projectquot; avec l’aimable autorisation de Scott Ambler et de Jon Erickson du Dr. Dobb’s
Journal.
Le monde réel est un monde complexe et donc il en résulte des exigences complexes pour tout
système souhaitant y fonctionner. Cela reste valable quelque soit la méthodologie de
développement. Bien que les méthodes quot;agiles à petite échellequot;, comme Scrum ou Extrem
Programming (XP), nous aient permis d’améliorer notre approche, trop de gens ont jeté le
bébé de la gestion des exigences avec l’eau de la bureaucratie en mettant trop de ferveur dans
leur croyance dans les stratégies réductrices de ces méthodes. Heureusement, avec un peu de
discipline, il est possible d’adresser les défis inhérents à des exigences complexes de manière
agile sans avoir à recourir aux trop lourdes pratiques documentaires qui ont la faveur des
équipes traditionnelles.
Au delà de Scrum
La méthode Scrum a rendu populaire la gestion des exigences au travers d’une pile de petits
blocs fonctionnels, empilés par priorité dans un quot;backlog de produit1quot;. L’idée est qu’à chaque
début d’itération, l’équipe va prendre les blocs qu’elle estime pouvoir réaliser dans cette
étape, du sommet de la pile. Ah, si seulement tout était aussi simple. Bien que Scrum nous ait
permis de nous affranchir des coûteuses stratégies de prévention du changement (oups, je
voulais dire les stratégies de gestion du changement) des méthodes traditionnelles, toute une
génération de développeurs a perdu les notions de nuance et de complexité inhérente à la
compréhension et la réalisation des exigences. Le backlog de produit de Scrum fonctionne
très bien pour des exigences fonctionnelles simples, mais comme je l’ai écrit dans quot;Beyond
Functional Requirements On Agile Projects2quot; (www.ddj.com/architect/210601918), il
atteint ses limites pour traiter les exigences et contraintes non fonctionnelles. Pour adresser ce
type d’exigences il existe trois stratégies : se faire une vision globale de l’architecture et des
exigences au début du projet, des tests réalisés par une équipe de testeurs indépendants de
l’équipe de développement tout au long de la réalisation, et de la formation.
Au cours d’une itération une équipe agile réalise de nouvelles exigences, mais elle doit aussi
corriger les anomalies et prendre en compte les tâches externes aux exigences à proprement
parler. La Figure 1 présente la stratégie de gestion des tâches OpenUP (www.eclipse.org/epf),
une extension de la stratégie de backlog de produit de Scrum. La première chose à remarquer
est qu’il ne s’agit pas d’un classique backlog de produit mais d’une pile de tâches à réaliser.
Une tâche est très souvent une petite exigence fonctionnelle, comme une histoire d’utilisateur
ou une fonctionnalité, mais il peut aussi s’agir d’un défaut ou d’une tâche non fonctionnelle
1
N.d.T. : product backlog sera traduit par backlog de produit (ce qui correspond au choix de Claude Aubry).
2
N.d.T. : une traduction française de cet article est disponible http://www.ehsavoie.com/2008/10/dpasser-les-
exigences-fonctionnelles.html

2. telle que passer en revue les travaux d’une autre équipe, participer à une formation, ou
installer un équipement. Dans l’article quot;Scaling Test-Driven Developpmentquot; (www.ddj.com/
architect/205207998) je vous ai décrit comment une équipe agile disciplinée possédait en son
sein un groupe de testeurs indépendants dont le rôle était de valider les artéfacts produits et de
remonter les défauts trouvés à l’équipe de développement. En traitant les défauts comme une
exigence à prioriser, évaluer et à placer dans la pile de tâches on simplifie la gestion du
changement en fusionnant gestion des défauts et gestion des exigences. De plus, bien que l’on
puisse planifier les tâches non fonctionnelles avec un coefficient ‘magique’ durant la session
d’estimation, en réalité, ces coefficients ‘magiques’ vont varier d’une itération à l’autre
puisque que ces tâches n’arrivent pas de manière continue tout au long du projet. Pour voir
cette stratégie de pile de tâches en action, vous pouvez télécharger une version d’évaluation
de Rational Team Concert (RTC) depuis www.jazz.net, qui intègre cette fonctionnalité dans
un environnement Eclipse pour des équipes agiles distribuées.
Figure 1 : les tâches sont traitées par ordre de priorité dans les équipes agiles quot;disciplinéesquot;.
Un autre point qui apparait au travers de la Figure 1 est qu’il faut vérifier la présence de
tâches potentiellement complexes lors des prochaines itérations. Lorsque l’on trouve une telle
tâche proche du sommet de la pile, il nous incombe de suivre la bonne pratique quot;Modélisation
en avance de phasequot; (www.agilemodeling.com/essays/bestPractices.htm), et donc d'analyser
cette tâche afin d'éviter qu’elle ne nous aveugle. Même si tout cela peut sembler hérésie pour
les puristes de l’Agilité, nous avons vu dans l’étude quot;DDJ 2008 Modeling and Documentation
Surveyquot; (novembre 2008) qu’il est courant que les agilistes modélisent. Au premier abord cela
semble être en contradiction avec la philosophie de l’Extrem Programming (XP) qui consiste
à avoir le courage de remettre à demain les problèmes du lendemain. Bien que cette forme de
machisme fasse que les développeurs ont l’impression de bien faire, et c’est sûrement une
excellente juxtaposition aux risques inhérents à une modélisation initiale détaillée, cette
philosophie poussée à l’extrême peut se retrouver être une stratégie médiocre en réalité, car
parfois des tâches complexes peuvent mettre le projet en péril si elles n’ont pas été anticipées.
Nulle part dans Scrum ou dans XP il est écrit qu’on doit être stupide, il est donc tout à fait
acceptable d’y ajouter des pratiques venues d’autres méthodologies.

3. La véritable utilisation est complexe
Les exigences fonctionnelles complexes peuvent être facilement organisées en un ensemble
de plus petites exigences fonctionnelles, une opération que l’on appelle désagrégation des
exigences, mais cela n’implique pas que ces petites exigences fonctionnelles apportent de la
valeur en dehors du contexte de l’exigence fonctionnelle complexe. Par exemple, on peut
écrire une histoire d’utilisateur qui indique que le système va devoir récupérer le nom et
l’adresse d’un client, puis qu’il va construire des listes de diffusion de clients, listes que vous
pourrez réduire selon certains critères, et qu’il exportera sous forme XML. Tout ceci forme un
ensemble intéressant d’exigences, qui chacune n’apporte que très peu de valeur jusqu’à ce
qu’on les replace dans le contexte plus global d’envoi de documents marketing à un groupe
ciblé de clients. Tant que ces histoires utilisateur et d’autres ne sont pas toutes réalisées, votre
système n’apporte pas de valeur métier à ses commanditaires, même si on a un produit
utilisable à chaque itération.
La Figure 2 montre des exigences empilées qui restent liées entre elles. Par exemple, les
exigences en rouge doivent être terminées en même temps même si l’une d’entre elle se
trouve plus bas dans la pile que les autres. Les exigences en vert sont elles aussi liées même si
elles sont plus regroupées que les rouges. Une fois que les responsables du produit3 se sont
rendus compte du couplage qui existe entre les différentes tâches et qu’une tâche avec une
priorité basse peut être bloquante pour la disponibilité de fonctions hautement prioritaires, ce
qui allonge le délai pour que le projet produise de la valeur, ils repenseront peut être leur
stratégie. Cette remise en cause peut passer par une repriorisation des tâches ou par la
renégociation avec les parties-prenantes4 qu’ils représentent pour abandonner la dépendance
vers la tâche peu prioritaire.
Figure 2 : Chaque exigence fonctionnelle n'intègre qu'une partie du scénario d'utilisation qui apporte la
véritable valeur
La compréhension de ces exigences complexes demande une approche plus sophistiquée que
de passer uniquement par les histoires d’utilisateur ou les fonctionnalités. Une stratégie simple
consiste à organiser en épopées5 ou regroupement de fonctionnalités, un ensemble de petites
exigences liées entre elles. Trier ainsi les exigences permet de les organiser mais ne fournit
pas le contexte. Pour adresser ce contexte il est préférable d’utiliser des scénarii d’usage ou
des cas d’utilisation. De nombreux agilistes regardent d’un mauvais œil les cas d‘utilisation
car souvent les seuls qu’ils ont croisés sont des cas d’utilisation produits par des analystes
3
N.d.T. : product owner est le représentant des clients et utilisateurs.
4
N.d.T. : stakeholder est traduit par le terme partie-prenante.
5
N.d.T. : epics

4. métier incontrôlables qui voulaient y modéliser le moindre détail. Mais comme je l’ai montré
dans www.agilemodeling.com/artifacts/systemUseCase.htm, il est possible d’écrire des cas
d’utilisation simples sous forme de fiches qui vont nous permettre de penser l’utilisation du
système sans risquer de produire de la documentation inutile. Chacun des points de ces fiches
peut être adressé par zéro ou une histoire d’utilisateur, l’ordre des étapes du cas d’utilisation
ainsi que les quot;étapes intermédiairesquot; qui sont adressées par des activités manuelles ou des
fonctionnalités réalisées ailleurs, fournissent alors le contexte absent des histoires d’utilisateur
individuelles.
Dans l’article quot;Scaling On-Site Customerquot; (www.ddj.com/architect/204801134), je montrais
que le rôle de client sur site6 (XP), ou de responsable produit chez Scrum, est en fait très
difficile car il doit représenter un large ensemble de clients, et non juste les utilisateurs finaux.
C’est pour cette raison que le contexte est aussi important, chaque partie-prenante du projet
interagit avec le système d’une manière qui lui est propre, et il faut comprendre chacune de
ces différentes, souvent mêmes contradictoires, utilisations et agir en conséquence. Les
artéfacts sophistiqués pour les exigences, comme par exemple les cas d’utilisation, fournissent
ce contexte, le véritable défi est donc de les produire de manière agile afin d’éviter toute la
bureaucratie inutile que l’on retrouve le plus souvent dans les équipes traditionnelles.
Exigences réparties sur plusieurs composants
Dans quot;Agile and Large Teamsquot; (www.ddj.com/architect/208700162) j’ai décrit comment les
grosses équipes agiles sont organisées en petites sous-équipes agiles, souvent autour de
l’architecture du système en cours de réalisation, et comment les responsables du produit pour
chacune de ces sous-équipes doivent coordonner leurs efforts entre eux. La raison de tout ceci
est représentée par la Figure 3, qui montre comment une exigence d’utilisation doit être
réalisée au travers de tout un ensemble de petites exigences à réaliser par plusieurs sous-
équipes. Dans cet exemple, les tâches en jaune forment une seule exigence d’utilisation, les
lignes qui les relient représentant la suite logique du scénario. Les responsables de produit de
chacune des sous-équipes doivent comprendre les interdépendances entre les exigences et agir
en conséquence. Cette coordination se fera au travers de réunions régulières de l’ensemble des
responsables de produit, un quot;scrum de scrumsquot; autour des exigences, ainsi que par des
réunions impromptues de quelques responsables produit pour résoudre des problèmes
spécifiques.
On ne trouve pas ce genre de problème que dans le cas d’un unique grand système, mais aussi
dans les relations entre différents systèmes. Très peu de personnes s’assoient devant un écran
pour utiliser une seule application toute la journée. La conclusion de tout ça est que pour que
chaque système apporte véritablement de la valeur aux parties-prenantes, les fonctionnalités
exigées doivent être réalisées. Par exemple, imaginons le cas d’un banquier qui utilise un
système de gestion de clients, un système de gestion de comptes et enfin un système
d’impression lorsqu’il ouvre un compte bancaire pour une personne. Imaginons toujours que
les nouvelles versions du système de gestion de clients et de gestion de comptes sont en
production avec cette fonctionnalité, mais que le système d’impression a rencontré des
problèmes et que donc il ne sera pas mis en production avant trois mois. On voit bien alors
que cette nouvelle fonctionnalité ne pourra pas être exploitée laissant croire que les trois
projets sont un échec, alors que pour deux d’entre eux ce n’est pas le cas. Depuis plusieurs
6
N.d.T. : on-site Customer : Une personne côté client est disponible tout le temps pour aider à la
compréhension du métier

5. années IBM a agi selon cette constatation et identifie activement les quot;green threads7quot;
(www.ddj.com/development-tools/196603524) qui sont des scénarii d’utilisation répartis sur
différents systèmes, afin de nous permettre de bien comprendre les besoins des clients et ainsi
de leur fournir de meilleurs produits.
Figure 3 : Scénario d’utilisation traversant plusieurs composants sur un grand projet Agile.
Aller au plus simple (KISS)
Les exigences sont, dans la pratique, le plus souvent complexes. Bien que les méthodes agiles,
et Scrum en particulier, aient offert de bons conseils pour faciliter la gestion des exigences, ce
conseil peut parfois s’avérer trop réducteur et mettre le projet en péril. Le conseil de la
communauté traditionnelle est lui trop compliqué et trop bureaucratique, et fait tout autant
courir de risques aux projets. Il existe cependant une voie médiane comme je viens de le
montrer dans cet article et on peut donc adresser les difficultés de la gestion des exigences
complexes sans prendre les risques inhérents aux stratégies traditionnelles de prévention du
changement.
7
N.d.T. : green threads est un concept ‘maison’ d’IBM.