Suzanne et James Robertson ont écrit la 3ème édition de leur ouvrage Maîtriser le Processus d'Exigences. Cette édition inclut du contenu mettant l'accent sur les défis des exigences dans des contextes de projet modernes, notamment les relations entre l'agilité et l'externalisation. Ils présentent un certain nombre de Vérités Fondamentales qui sont à la racine de leur approche.
InfoQ a eu l'opportunité d'interviewer les auteurs sur leur nouvel ouvrage.
Un extrait de celui-ci peut être téléchargé ici.
InfoQ: Il s'agit de la troisième édition de votre livre, quelle en est raison ? Qu'est-ce qui a changé depuis la deuxième édition, qui justifiait un nouvel ouvrage complet ?
Un certain nombre de choses. Les méthodes de développement agiles sont plus répandues et les gens veulent savoir comment les exigences doivent être gérées dans un environnement agile. Toutefois, le livre n'est pas uniquement centré sur l'agile, il couvre le spectre entier des tâches d'un analyste métier dans la découverte et la communication des exigences. En plus du contenu de l'édition 2, nous avons ajouté :
- Des guides stratégiques sur différents environnements, y compris l'externalisation
- Des stratégies de découvertes et de mise en oeuvre des exigences pour des versions itératives.
- Penser de manière latérale pour trouver le problème réel
- Comment passer de l'exigence au choix de la bonne solution
- Le modèle de la Vache Brune pour des points de vue plus clairs
- L'utilisation de cartes explicatives en tant qu'exigences
- Des vérités fondamentales sur les exigences, le développement de systèmes, et plus encore
InfoQ: Vous commencez par fournir une liste de Vérités Fondamentales, qu'est-ce qui les rend si importantes?
En parlant à nombre d'analystes métier, nous entendions sans cesse des messages confus et contradictoires sur l'analyse métier et le développement de système. Il semble qu'un certain nombre de personnes confondent leur méthodologie avec les bonnes pratiques. Nous voulions souligner qu'il existe des principes de base à respecter. Par exemple - "les exigences ne sont pas réellement à propos des exigences" - le but est d'étudier le travail réalisé par le métier, car c'est de là que proviennent les exigences. Vous ne pouvez pas spécifier le produit adéquat à moins de comprendre le travail.
Les autres vérités sont des choses que nous savons utiles aux analystes métier de prendre en considération.
InfoQ : Est-ce que les "exigences" ne sont pas démodées aujourd'hui - comment les approches comme le Lean et l'Agilité impactent le travail de définition des exigences ?
La manière dont vous développez votre logiciel n'a pas d'importance. Si celui-ci ne répond pas aux besoins métier, à tous les besoins, c'est un mauvais logiciel (je ne suis pas sûr du premier qui ait dit cela, mais c'est vrai). Beaucoup de méthodes actuelles à la mode se concentrent sur la solution, et accordent peu d'attention au vrai problème à résoudre. Bien sûr, elles produisent du logiciel rapidement, mais ça n'a aucune utilité si elles se trompent dans la réelle raison d'être de produire ce dernier. Comme dit précédemment, le but des exigences n'est pas de produire une spécification considérable (la plupart des équipes modernes qui développent en interne ne le font pas de toute manière), mais de comprendre la problématique.
Nous devons aussi prendre en considération qu'une quantité importante de développement est réalisée de manière délocalisée. Si vous pensez externaliser votre développement logiciel en Inde ou en Russie, vous devriez disposer de bonnes spécifications ou vous allez jeter votre argent par la fenêtre. De la même manière, vous devez résoudre le bon problème.
Nous traitons les stratégies pour ces trois types de développement dans le livre - évidemment, vous gérez vos exigences différemment en fonction de la manière dont vous réalisez votre développement.
InfoQ : Vous présentez le Processus d'Exigences de Volere - pourriez-vous expliquer brièvement ce processus et ce qui le rend unique s'il vous plaît ?
Nous aimons à penser qu'il ne s'agit pas d'un processus parallèle, mais bien d'un cadre pour la découverte et la communication des besoins réels du métier. Ce processus est constitué d'activités qui doivent être réalisées d'une certaine manière, dans un ordre certain, avec un certain degré de détail. Et alors que nous suggérons au lecteur comment il peut réaliser ces activités, nous savons que les différences dans les structures et l'historique des organisations rendent nécessaires une approche différenciée. Ce qui compte, c'est d'obtenir le résultat adéquat dans chaque partie du processus.
Le processus de Volere est unique, en ce qu'il n'est pas basé sur la manière dont les choses doivent être réalisées, mais sur des observations de terrain de découverte et de mise en oeuvre d'exigences réussies. Nous parlons de résultats tangibles que vous devez atteindre, plutôt que se focaliser sur les procédures comme d'avoir une réunion debout à 9h30 tous les matins.
InfoQ : Vous accordez beaucoup d'importance au concept d'un produit qui ait une "valeur optimale" - pourquoi donc ?
Si ça n'apporte pas de valeur au métier, alors c'est du gaspillage de le produire. "Valeur optimale" veut dire que vous construisez un produit qui n'a pas plus de capacités que ce qui est nécessaire, que vous ne dépensez pas en développement plus que sa valeur ne le demande. L'idée première est d'être conscient de la valeur que votre produit apporte au métier - il doit résoudre des problèmes métier significatifs. En prenant conscience de sa valeur, vous vous assurez que vous ne dépensez pas plus dans son développement que ce que sa valeur ne nécessite.
C'est à la mode de parler de tout logiciel en tant que "valeur client". Toutefois, ce n'est le cas que s'il fournit au métier un service à la fois mesurable et avantageux. S'il a une valeur optimale, alors vous aurez atteint ces deux qualités.
InfoQ : Vous avez une véritable ménagerie dans le livre - des chevaux, des éléphants, des lapins et des "vaches brunes" - pouvez-vous expliquer certaines de ces métaphores s'il vous plaît ?
Les trois premières sont des analogies. Nous demandons au lecteur de considérer son projet. S'agit-il d'un projet petit, rapide, avec une courte durée de vie ? Si oui, il s'agit d'un projet lapin et vous devriez réaliser uniquement certaines choses et d'autres non. Par exemple, nous suggérons que les projets lapin devraient certainement découvrir toutes leurs exigences, mais qu'ils ne doivent pas forcément écrire des spécifications complètes. Les projets lapin peuvent abréger leurs spécifications.
D'un autre côté, si vous externalisez ou si vous travaillez sur un projet militaire, médical ou gouvernemental, vous êtes un éléphant. Les éléphants sont plus lents et plus gros, et vous avez besoin d'une documentation formalisée (essayez de commercialiser un nouvel appareil sans une spécification complète).
Les chevaux se trouvent entre les lapins et les éléphants. En donnant un nom et une image au style d'un projet, les analystes métier sont plus à même de parler de leurs différences et d'agir en conséquence, et de ne pas perdre du temps en tâches inutiles.
Le modèle de la Vache Brune ( Brown Cow ) est un outil de réflexion qui se penche sur différentes vues ou abstractions du problème. Le premier quadrant du problème est appelé Comment-Maintenant ( How-Now ) et nous avons immédiatement pensé à l'exercice d'élocution anglaise quand vous devez dire "How now brown cow?". Stupide mais mémorable.
InfoQ : Vous parlez de trouver le problème réel, et de trouver "l'essence" du métier - pourquoi est-ce si important ?
Trop de projets foncent pour construire la première solution évidente, ou la solution que l'utilisateur n'a jamais demandée. Bien qu'il y ait une chance que ce soit exactement ce qui est nécessaire, l'expérience et les probabilités prouvent que ce n'est généralement pas le cas. Trop de logiciels (et de produits de consommation) sont produits pour résoudre le mauvais problème. Pourquoi ? Parce ce que l'équipe de développement s'est concentré sur leur solution et n'ont pas suffisamment prêté attention au métier qui déploie leur solution.
L'essence du problème est une abstraction : que serait-ce si nous n'avions pas à prendre en compte la technologie ? Autrement dit, quel est le problème réel lorsqu'il n'est pas déformé par la solution proposée ? Nous pourrions aussi l'exprimer différemment : l'essence représente le problème sous-jacent à résoudre. Si vous ne découvrez pas l'essence, vous résolvez le mauvais problème.
InfoQ : Vous disposez d'une section qui fournit des conseils sous la forme de "stratégie pour l'analyste métier contemporaine" - quelles sont certaines de ces stratégies et pourquoi sont-elles nécessaires ?
L'une de ces stratégies est pour le développement externalisé, pour l'outsourcing si vous préférez. Elle montre quelles activités sont importantes, quels sont les livrables que vous devez produire et comment déterminer si le niveau de détail est suffisant dans votre situation particulière.
Une autre stratégie est dédiée au développement itératif. Si vous utilisez une méthode agile, alors c'est de l'itératif et vous devez vous assurez que vous passez votre temps sur les détails les plus pertinents et ceux qui ont de la valeur. Cette stratégie montre ce dont vous avez besoin pour travailler efficacement avec votre méthode.
Nous avons développé les stratégies car il est clair que toutes les organisations ne doivent pas travailler de la même manière. Nous avons fourni des alternatives pour travailler sur les exigences qui répondent aux caractéristiques de votre propre organisation.
InfoQ : Vous parlez de l'importance des Critères de Conformité et de Justification - qu'est-ce que c'est et pourquoi sont-ils importants ?
Ils sont importants car si vous ne les avez pas, vous n'avez probablement pas les exigences correctes. La justification est la raison ou le fondement de l'exigence. "Pourquoi voulez-vous ça ?" est dans les fait plus important que "Que voulez-vous ?". Si l'analyste métier et le développeur savent pourquoi une fonctionnalité est demandée, ils peuvent produire le meilleur résultat.
Le critère de conformité est une mesure de l'exigence. Vous pouvez le dériver lorsque vous disposez d'une justification. Par exemple, supposez que vous ayez une exigence "Je veux un produit qui soit facile à utiliser". C'est une exigence valide, mais pas encore utile. Maintenant, demandez une justification "Pourquoi voulez-vous cela ?". "Je veux que mes clients changent volontairement pour ce nouveau système." A partir de là, vous pouvez en dériver le critère de conformité ainsi "Dans un délai de six mois, 70% des clients ont adopté le nouveau système et ont abandonné l'ancien." Le critère de conformité est en fait le critère d'acceptation, et le concepteur/développeur doit rendre le nouveau système suffisamment attractif pour atteindre l'objectif. Noter que "facile à utiliser" était une proposition de solution - elle n'aurait pas garanti que les clients aient changé. En incorporant un critère de conformité, vous énoncez l'essence de la problématique.
InfoQ : qu'est-ce qui qualifie une "bonne" exigence ?
Un élément de réponse est qu'une bonne exigence résout un problème pertinent et notable, et coûte en fonction de la valeur procurée à son détenteur. Toutefois, nous pensons que ce n'était pas le sens de votre question. Dans ce cas, nous devrions dire qu'une bonne exigence est sans ambiguïté (c'est la raison pour laquelle nous avons un critère de conformité), résout le problème exact (la justification devrait adresser ce point) et est écrite de manière à ce que toutes les parties prenantes puissent la comprendre et se mettre d'accord. Bien sûr, elle doit être testable, et de nouveau, le critère de conformité est aussi là dans ce but.
InfoQ : De quelle manière le processus de Volere supporte les pratiques de développement agiles/itératives ?
En n'étant pas un processus rigide, et en se concentrant sur la découverte des besoins réels. Les exigences réelles doivent être découvertes, sous peine que votre projet livre le mauvais produit, ou au mieux un produit moins qu'optimal. L'approche de Volere fait en sorte que vous n'ayez pas à découvrir l'intégralité des exigences et écriviez une spécification complète avant de commencer. Mais vous devez démontrer l'essence du problème que vous solutionnez.
Beaucoup de techniques agiles utilisent des cartes explicatives. Nous avons inclus une section qui décrit comment écrire de bonnes cartes, et comment éviter que celles-ci décrivent la solution et non le problème sous-jacent.
InfoQ : Comment ce processus supporte l'innovation - si nous recueillons uniquement les exigences, d'où proviennent les nouvelles idées ?
L'innovation est particulièrement importante. Sans innovation, la valeur du produit final est probablement nulle - il n'a fourni rien de nouveau. Et l'idée de "recueillir" les exigences" s'éloigne généralement de l'innovation. Comme dit précédemment, vous ne demandez pas "que voulez-vous ?" mais "pourquoi le voulez-vous ?".
L'innovation au sens des exigences n'est pas l'invention d'une nouveauté technologique mais la découverte d'une nouvelle manière de réaliser le travail. En mettant en exergue les raisons sous-jacentes d'une tâche, l'analyste métier peut mener la charge de l'innovation pour ne pas trouver uniquement une meilleure manière de faire, mais un meilleur travail à exécuter. Cela transforme l'analyste métier de sténographe qui recueille et documente les exigences en innovateur qui étudie les processus et découvre des innovations de valeur.
Le processus de Volere suggère qu'entre les quadrants du Quoi-Quand et du Futur-Quoi du modèle de la vache brune (vous allez devoir acheter le livre pour comprendre entièrement tout cela) vous considérez l'innovation et la manière d'améliorer le travail, ce qui conduit à améliorer le métier. Après tout, améliorer le travail est l'objectif de tout projet logiciel.
A propos des auteurs
Suzanne Robertson et James Robertson ont aidé des centaines d'entreprise à renforcer leurs techniques d'exigence pour améliorer leur développement de systèmes. Leurs cours et leurs séminaires sur les exigences, l'analyse et la conception sont largement reconnus pour leur approche innovante. Ils sont tous deux consultants principaux de Atlantic Systems Guild, une entreprise de conseil bien connue spécialisée dans la dimension humaine de la construction de systèmes complexes. Ils sont également co-auteurs de 'Requirements-Led Project Management' (Addison-Wesley, 2005).
Cet article est basé sur la 3ème édition du livre 'Mastering the Requirements Process: Getting Requirements Right' par Suzanne Robertson & James Robertson, publié par Pearson/Addison-Wesley Professional, Août 2012, SBN 0321815742, Copyright 2013 Pearson Education, Inc. Pour plus d'information, veuillez consulter le site de l'éditeur.