Exigences Complexes dans un Projet Agile

Scott W. AmblerLes 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 "Complex Requirements On An Agile Project" 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 "agiles à petite échelle", 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 "backlog de produit1". 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 "Beyond Functional Requirements On Agile Projects2" (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

telle que passer en revue les travaux d’une autre équipe, participer à une formation, ou installer un équipement. Dans l’article "Scaling Test-Driven Developpment" (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 "disciplinées".

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 "Modélisation en avance de phase" (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 "DDJ 2008 Modeling and Documentation Survey" (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.

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

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 "étapes intermédiaires" 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 "Scaling On-Site Customer" (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 "Agile and Large Teams" (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 "scrum de scrums" 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

années IBM a agi selon cette constatation et identifie activement les "green threads7" (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.