Posté par jc-Qualitystreet le 6 octobre 2009
Première étape de mon parcours au travers d’un référentiel Agile CMMI, et premier billet d’une longue série qui s’adresse en priorité à mes lecteurs AGILISTES, aux praticiens CMMI et à ceux qui s’intéressent de prés ou de loin à l’amélioration des processus.
Ma posture est celle d’un coach agile qui accompagne une organisation cherchant à atteindre, pour diverses raisons, le niveau de maturité 3 CMMI, mais souhaitant garder un mode de fonctionnement agile fondé sur des pratiques SCRUM et XP.
Voici donc REQM, “Gestion des exigences“, l’un des 7 domaines du Niveau de maturité 2, dont l’intention est de « gérer les exigences des produits et composants de produits du projet et d’identifier les incohérences entre ces exigences et les produits d’activité du projet ».
La gestion des exigences (REQM) est avec RD (Développement des exigences) la base de ce qu’on appelle l’Ingénierie des exigences, des activités ô combien cruciales dans les projets informatiques. Les exigences sont fonctionnelles (« ce que les système doit faire ») ou non fonctionnelles (attributs de qualités, par exemple fondés sur l’ISO 9126).
Au programme, REQM dans une perspective Agile CMMI :
- Quels sont les objectifs spécifiques à satisfaire OBLIGATOIREMENT?
- Quelles sont les pratiques spécifiques initialement recommandées, et comment l’agilité se marrie-t-elle avec celles-ci?
- Quels sont les objectifs génériques à satisfaire OBLIGATOIREMENT ( Niveau 2 & 3), et comment se positionne l’agilité sur les pratiques génériques initialement recommandées?
1 OBJECTIF(S)SPECIFIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI
REQM SG1 : Gérer les exigences
OK AGILE CMMI
Un seul objectif à satisfaire mais il est de taille. Les exigences sont gérées, et les incohérences avec les plans du projet et les produits développés sont identifiées. C’est l’objectif à atteindre, et l’agilité le permet largement.
2 PRATIQUES(S)SPECIFIQUES DE REFERENCE RECOMMANDEE POUR CMMI
Il s’agit des pratiques recommandées dans le modèle théorique. Non imposées, elles servent souvent de guide pour ceux qui démarrent leur projet d’amélioration des processus mais peuvent être remplacées par des pratiques alternatives, contextualisées à l’entreprise, pourvu qu’elle permettent d’atteindre l’objectif fixé. L’idée pour nous est de prouver qu’avec un process Agile, vous gérez les exigences !
REQM-SP1.1 Développer une compréhension commune des exigences et de leur signification avec ceux qui les ont fournies.
OK AGILE CMMI
L’agilité se retrouve bien dans cette pratique qu’elle pourrait faire sienne. Les ateliers de travail, les face à face, pour construire de manière collaborative une Vision PARTAGEE, et un Backlog de produit, ESTIME et PRIORISE vont dans ce sens. La réunion de lancement en fait partie. Les critères d’acceptation portant sur chaque User Story (élément du Backlog) prolongent cet effort de compréhension commune et concourent à l’atteinte de l’objectif.
Qui : Product Owner, Equipe
Quoi : Vision, Backlog de produit, Réunion de lancement, Réunion d’estimation, Réunion de planification, User Stories
REQM-SP1.2 Obtenir des participants au projet leur engagement sur les exigences.
OK AGILE CMMI
Engagement et responsabilisation : voilà des points forts des méthodes Agiles. La réunion de planification (à chaque début de sprint) est un moment où l’équipe s’engage collectivement sur la réalisation, durant le sprint, d’une partie du Backlog de produit (et user stories). Chaque jour, les membres de l’équipe s’engagent sur la réalisation d’une tâche pour construire les user stories : c’est le Daily Scrum.
Qui : Equipe, ScrumMaster
Quoi : Réunion de planification (CR PPT ou Wiki), Daily Scrum
REQM-SP1.3 Gérer les modifications aux exigences au fur et à mesure de leur évolution en cours de projet.
OK AGILE CMMI
Maintien et contrôle des exigences : c’est aussi l’objectif du Backlog de produit, qui vit et évolue au fur et à mesure de l’avancée du projet. Il est actualisé à la fin de chaque Sprint (suite à la réunion de fin de sprint).. Historiser les versions du Backlog est très pertinent dans un contexte CMMI.
Le changement dans les exigences peut se traduire aussi au niveau des user stories (éléments du Backlogde produit). Mettre à jour, faire vivre, la partie « Conversation » de l’User Stories est déjà une pratique en place chez beaucoup d’équipes.
Le burndown chart montre concrètement au quotidien ce qui est réalisé, et les changement éventuels survenus.
Au final, ce qui compte ici, c’est UN BACKLOG DE PRODUIT ET DES USER STORIES à JOUR.
Qui : Product Owner, Equipe
Quoi : Backlog de produit, User stories, Burndown Chart, Réunion de fin de sprint (CR PPT ou Wiki)
REQM-SP1.4 Maintenir une traçabilité bidirectionnelle entre les exigences et les produits d’activité.
OK AGILE CMMI
On s’en fait une montagne, et pourtant …il suffit d’envisager la fonction développée et présentée en DEMO comme la barquette de viande vendue au supermarché. Le cas échéant, on doit pouvoir remonter toute la chaine, et mesurer les enjeux collatéraux. Pour les végétariens, vous vez aussi la métaphore du Petit Poucet J Le quatuor (Backlog de produit - User Stories - Tâches - Produit Développé) assure un système de suivi des exigences souple et performant, se concrétisant dans la démo de fin de sprint. CMMI attend une matrice de traçabilité des exigences. Les feuilles de calcul et les outils du marché gérant les Backlog de produit permettent d’atteindre cet objectif.
Qui : Product Owner - Equipe
Quoi : Backlog de produit, Démo, Réunion de fin de sprint (CR PPT ou Wiki)
REQM-SP1.5 Identifier les incohérences entre les plans du projet et les produits d’activité d’une part et les exigences d’autre part.
OK AGILE CMMI
Cette pratique est un vrai point fort de l’Agilité. Elle s’effectue de manière continue, dans la collaboration, durant tout le sprint avec comme clé de voute les critères d’acceptation définis pour chaque User story mais aussi grâce aux daily scrum. La démo de fin de sprint est un RDV formel permettant de déterminer ce qui a été fait ou pas, ce qui est bien fait de ce qui ne l’est pas. Ce RDV qui donne lieu potentiellement à des actions correctives et à l’actualisation du Backlog de produit. FEEDBACK ET ADAPTATION.
Qui : Product Owner - Equipe - ScrumMaster
Quoi : Backlog de produit, User Stories, Daily Scrum, Démo, Réunion de fin de sprint (CR PPT ou Wiki)
3 OBJECTIF(S) GENERIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI, et PRATIQUES ASSOCIEES
REQM GG1 : Réaliser les objectifs spécifiques
OK AGILE CMMI
En somme pour REQM, les exigences doivent être gérées (renvoie à REQM SG1 : Gérer les exigences)
REQM GG2 : Institutionnaliser le processus en tant que processus discipliné
OK AGILE CMMI
Là cela devient intéressant… Cet objectif n’est pas le plus simple à atteindre ; il est pourtant nécessaire dans les contextes CMMI et Agile CMMI. Il ne nécessite pas forcement une adaptation des pratiques Agiles, mais plutôt un élargissement de celle-ci à l’entreprise : « J’ai réussi un projet agile, et je souhaiterais capitaliser et faire en sorte que mes autres projets en bénéficient ». Des expériences que je capitaliserais à nouveau pour les améliorer.
Je vous parle donc de PROCESS AGILE, Capitalisation et amélioration continue. Je vous parle donc d’ENTREPRISE AGILE… C’est dans l’ère du temps non ?
REQM-GP2.1 Établir et maintenir une directive organisationnelle traitant du processus Gestion des exigences…
OK AGILE CMMI
C’est un élément incontournable de mon Process Agile. Je m’appuie généralement sur le sponsor pour travailler cette directive qui vient d’en haut. Le plus souvent, elle reste générique (les méthodes agiles) mais on peut aborder brièvement, c’est mieux, la gestion « agile » des exigences (développement et gestion). C’est en quelque sorte officialiser le process Agile dans l’entreprise.
Qui : Coach Agile, Sponsor, Direction, Equipes
REQM-GP2.2 Planifier le processus Gestion des exigences…
OK AGILE CMMI
Une adaptation des pratiques agiles est nécessaire puisqu’on doit introduire pour chaque projet un plan de projet ou charte projet qui décrira dans les grandes lignes le Qui, Quoi, Quand, Ou du projet. Je conseille aux équipes de le faire en Sprint 0 et demande au ScrumMaster de s’en charger. C’est un petit doc, commun à beaucoup de domaines de process CMMI (exigences, risques, qualité …). C’est court, PPT, Word ou Wiki.
Qui : ScrumMaster.
REQM-GP2.3 Fournir les ressources adéquates pour le processus Gestion des exigences…
OK AGILE CMMI
Preuve doit être donnée que les ressources adéquates (humaines, outils …) ont été fournies. Dans notre cas, cela passe entre autres par le choix de l’outil de Backlog, et par la désignation d’un Product Owner (disponible). Cette pratique m’est très utile car elles la question des moyens est souvent un facteur d’échec des projets agiles. Avec cette pratique, on gagne en maturité. Cette activité fait partie intégrante du rôle du ScrumMaster, en Sprint 0. Donc pas de problème.
Qui : ScrumMaster.
REQM-GP2.4 Assigner la responsabilité et l’autorité pour mettre en œuvre le processus Gestion des exigences…
OK AGILE CMMI
C’est une composante du Process Agile, à inclure dans le Plan de projet. Qui fait quoi ? Cela revient à décrire brièvement le rôle de Product Owner …
Qui : ScrumMaster.
REQM-GP2.5 Former les personnes qui mettent en œuvre ou soutiennent le processus Gestion des exigences…
OK AGILE CMMI
Cela fait partie de mon travail de coach Agile. Dans ce cas précis, cela passe par la mise en place de formations et ateliers dédiés au Product Owner, aux testeurs, à l’équipe.
Qui : Coach Agile.
REQM-GP2.6 Placer les produits d’activité identifiés du processus Gestion des exigences au niveau de contrôle approprié…
OK AGILE CMMI
Comme sur tous les projets informatiques … Il s’agit du niveau de configuration d’éléments comme le Backlog de produit ou les User Stories. Les CR de réunions de planification ou de sprint rentrent aussi dans cette catégorie.
Qui : Product Owner, ScrumMaster.
REQM-GP2.7 Identifier et impliquer les parties prenantes concernées par le processus Gestion des exigences…
OK AGILE CMMI
Un petit tableau dans le Plan de projet fait en Sprint 0 est tout à fait pertinent. Le Product Owner est l’acteur principal sur laquestion mais, l’équipe (en particuliers les testeurs) est fortement partie-prenante. Business analysts, Ergonomes, Utilisateurs… sont aussi concernés.
Qui : ScrumMaster.
REQM-GP2.8 Suivre et contrôler le processus Gestion des exigences …
OK AGILE CMMI
Cette pratique consiste à suivre l’avancement des activités de gestion des exigences sur la base d’indicateurs. La fin du sprint est un jalon essentiel avec la collecte de données : sur les user stories (Done / Ready), le burndown chart, les changement sur les stories…. Cela fait partie « par défaut » des attributions du ScrumMaster.
Qui : ScrumMaster
REQM-GP2.9 Évaluer objectivement le respect du processus Gestion des exigences…
OK AGILE CMMI
Relié aussi au GP2.2. C’est du QA. Le ScrumMaster est le garant de la bonne application du Process Agile sur le projet. Cela fait partie « par défaut » de ses attributions. Maintenant attention, le Process Agile est adaptatif…
Qui : ScrumMaster.
REQM-GP2.10 Revoir l’état du processus Gestion des exigences avec la hiérarchie et résoudre les problèmes…
OK AGILE CMMI
C’est à la fois donner de la visibilité et remonter des problèmes potentiels à la hiérarchie. C’est justement le rôle du ScrumMaster (le « Chien de berger ») qui doit aussi protéger l’équipe et faire remonter, les obstacles éventuels soulevés par l’équipe (par exemple en Daily Scrum). Il peut s’appuyer sur des éléments du radiateur d’informations, burndown chart et fiches de Sprint pour donner de la visibilité à sa hiérarchie sur cette question des exigences.
Qui : ScrumMaster, Product Owner, Hiérarchie
REQM GG3 : Institutionnaliser le processus en tant que processus ajusté
OK AGILE CMMI
Comme précédemment, pas facile mais nécessaire (pour la maturité 3). On est plus que jamais dans du Process Agile…on est dans du standard mais dans une perspective qui me plaît bien, c’est à dire adaptative et non figée, fondée sur l’amélioration continue.
REQM-GP3.1 Établir et maintenir un processus Gestion des exigences ajusté
OK AGILE CMMI
Une description du processus Agile « standard » de l’entreprise doit être disponible .Elle servira de référence, mais sera ajustée à chaque projet (cela doit être prouvé). On est en plein dans de l’AGILITE en CONTEXTE.
Définir le Process Agile standard, de manière collaborative et participative (jamais seul !)cela fait partie de mon travail.
L’adaptation au projet : c’est le boulot du ScrumMaster avec l’équipe et le Product Owner.
Qui : Coach Agile, les ScrumMaster, les Product Owner, les Equipes
REQM-GP3.2 Collecter l’information d’amélioration du processus Gestion des exigences
OK AGILE CMMI
Le projet doit se servir de retour d’expérience à la fois pour le Process Standard et pour les autres. C’est très agile, c’est très adaptatif (niveau organisation), et c’est la base de l’amélioration continue. Les agilistes doivent se féliciter de cette pratique.
Qui : Agile, les ScrumMaster, les Product Owner, les Equipes
Une autre référence sur la sujet : Flex”i”MMI
Posté par jc-QualityStreet le 2 février 2008
Mais tout d’abord, une petite question : selon vous, parmi la centaine de posts de ce blog, quel est le “billet le plus consulté” ?
Allez… quelques secondes de réflexion…
Bon fin du suspens (et quel suspens !) … le billet gagnant se trouve être (et de loin) …
“Spécifications, Exigences et Cahier des charges : Quoi, Comment ?”, l’un des billets de mon TOP 14.
Je ne me risquerai pas à émettre des conclusion hâtives sur cette statistique (car les facteurs l’influençant sont nombreux).
Je ne m’aventurerai pas non plus à postuler que le billet en question est celui qui VOUS intéresse le plus, vous les habitués de Qualitystreet, lecteurs assidus qui venez d’horizons souvent différents mais qui vous retrouvez dans ma vision des projets, de la qualité et dans cette convergence vers laquelle je tends.
Alors surpris ? Moi non (mais je triche car je consulte mes stats), et Vous ?…
J’espère que les lecteurs de “ce billet le plus consulté” trouvent déjà dans celui-ci ce qu’ils recherchent… Pour les y aider davantage, voici un petit “best of” de billets Qualitystreet relatifs à l’Ingénierie des exigences (besoins, spécifications, analyse ….), mais rassurez-vous nous en reparlerons, dans des contextes agiles, à partir d’un référentiel CMMI ou même en mixant les deux!
- Spécifications, Exigences et cahier des charges: Quoi, Comment ?
- Spécifications, Exigences et cahier des charges: Qui, Quand
- Modèle de Kano: si précieux pour…
- La voix de l’utilisateur, entre recueil du besoin et gestion de l’incertitude
- Un user proxy mais pas d’utilisateurs
- Une interface conviviale (1/3)
- Une interface conviviale (2/3)
- Une interface conviviale (3/3)
- Use cases, User Stories
- Use cases, User Stories: les différences
- Use Case, UML, oui mais …
- User stories, plus appropriées ?
Si vous avez le courage d’en lire ou en avez lu certains :); dites-moi celui qui vous inspire le plus, sinon plus simplement faites nous partager vos meilleures sources.
Posté par jc-QualityStreet le 5 octobre 2007
N’oubliez pas qu’un cas d’utilisation est avant tout TEXTUEL, et n’associez donc pas aussi radicalement ce cas d’utilisation (Use Case) au diagramme UML: privilègiez plutôt la démarche.
En effet, se lancer dans la rédaction des cas d’utilisation, pour décrire un besoin fonctionnel (spécifications), c’est se lancer dans une véritable démarche d’analyse, progressive, parfois lente, parsemée d’ateliers de travail, d’entretiens …
C’est aussi adopter une vraie réflexion en termes d’utilisateurs (acteurs), de buts et de tâches.
Croyez-moi, c’est bien là l’essentiel.
Le diagramme des cas d’utilisation UML (« Use Case diagram ») est quant à lui trés précieux pour bénéficier d’une vue globale sur l’application; il permet de visualiser immédiatement les liens entre acteurs et cas d’utilisation, ou encore de délimiter explicitement les différents packages. « Modéliser graphiquement » est un principe du Processus Unifié (ceci dit toujours fonction des destinataires), donc le diagramme des Use Cases ne doit pas absolument pas être négligé !
Pour ma part, ce n’est pourtant pas le diagramme qui m’a séduit …
j’ai découvert les cas d’utilisation en 2000 quand j’étais consultant au Luxembourg et j’ai très rapidement perçu, en les construisant (et grâce à de bons mentors), la forte complémentarité à la fois avec la démarche Ergonomique (profil utilisateurs, réflexion sur les buts et scénarios, UCD …) et avec les activités, livrables de l’Ergonome ou Designer d’interaction (Personas, Storyboard, Diagramme de Tâches, Wireframes).
Le fait que les cas d’utilisation se focalisent seulement sur le Quoi (Fonctionnel et Métier) _c’est une règle d’or_, sans décrire les éléments d’interfaces (Ecrans et enchaînement), laissés aux spécialistes de l’IHM, est aussi un élément que j’ai beaucoup apprécié, selon moi un vrai point fort.
Modéle générique de cas d’utilisation
Donc, depuis tout ce temps, j’évangélise … en insistant principalement sur 6 points :
- La démarche de découverte et de construction progressive des cas d’utilisation: l’essentiel …
- La forte adéquation avec le développement itératif (dans l’estimation, la priorisation, la planification, le traitement)
- La complémentarité avec le travail de l’Ergonome
- La lisibilité, le formalisme des cas d’utilisation (élément clé de son efficacité et de son acceptation par les équipes)
- La gestion des modifications (pas si simple que ça!)
- Le lien fort avec les cas de tests et une approche de validation fonctionnelle (c’est l’idéal!)
… Et je recommande toujours « Rédiger des cas d’utilisation efficaces », d’Alistair Cockburn, la référence que je conseille à tous ceux qui souhaitent s’attaquer à l’analyse système ou mètier.
Enfin, même si aujourd’hui je me retrouve davantage dans les User stories, je reste convaincu de la pertinence des cas d’utilisation dans pas mal de contextes … quand ils sont bien rédigés 
Posté par jc-Qualitystreet le 2 juillet 2007
… avant tout un outil de communication et un brin de documentation (juste ce qu’il faut pour rester Agile) visant à rendre compte de l’adéquation de ce qui est livré avec ce qui est attendu, voulu par le Client et les Utilisateurs finaux;
… un travail produit dans le cadre du Recueil & Expression, de la Spécification et de la Gestion du besoin, composantes principales de ce qu’on appelle « l’Ingénierie des exigences » (=« Requirements » );
… des exigences au cœur des projets, qu’elle soient fonctionnelles (ce que le système doit faire, constituant par exemple un backlog de produit agile) ou non fonctionnelles (qualité du produit, principalement les attributs issus de la norme ISO 9126), présentes au travers de ces trois activités essentielles.
… et de nouveaux champs d’intervention pour l’Ergonome Agile comme je le décris dans le précédent billet de cette série: Spécifications, Exigences et Cahier des charges: Qui ? Quand ?
Recueillir & Exprimer les besoins
L’objectif est de fournir une vision claire du système à concevoir, d’offrir la définition et les limites du système, les fonctionnalités clés, les autres exigences et contraintes. Définir puis partager la Vision du produit est donc cruciale.
La vision synthétique est un excellent point de départ :
POUR (public concerné par le produit)
QUI SOUHAITENT (formulation du besoin des cibles)
NOTRE PRODUIT EST (ce qu’est le produit)
QUI (le bénéfice majeur, l’utilité de la solution)
A LA DIFFERENCE DE (pratique actuelle, concurrence)
PERMET DE (éléments différentiateurs majeurs)
Elle peut se prolonger dans de petits docs. à la structure souvent similaire :
Plan d’un Cahier Des Charges de Site Web
Plan de Vision Document (Wiegers)
L’entretien et l’observation sont les sources d’informations principales mais d’autres techniques peuvent aussi être utilisées : questionnaires, focus group, observation, tests utilisateurs exploratoires, benchmarking, étude de l’existant, de la concurrence), présentation de maquettes…
Le savoir-faire de l’ergonome dans la conduite de chacune de ces techniques est un véritable atout, notamment pour trier et organiserclassifying the voice of the customer », selon Karl Wiegers ), discours qui peut prendre différentes formes : l’input des utilisateurs (« exigences Business, scénarios d’usage, règles de gestion, exigences fonctionnelles, attributs de qualité, contraintes, données, idées et solutions).
Ce premier tri nous servira à établir notre base d’exigences.
Spécifier les besoins
L’objectif est de détailler et de clarifier les besoins exprimés en analysant le fonctionnement du système de manière formelle et exploitable par les équipes de développement.
Même si ce n’est pas forcément leur objectif initial, les user stories et les éléments de conversation les accompagnant (conditions de satisfaction, exemple, wireframes…) constituent un moyen particulièrement efficace de spécifier le besoin de manière collaborative.
Les formats de spécification plus anciens se recoupent (IEEE, RUP, Volere …). Ils intègrent généralement en leur sein une partie Exigences fonctionnelles. Cette intégration qui se concrétise souvent sous forme de renvois vers d’autres formats ou document permet à cette documentation générale de rester synthétique, ouverte et abordable.
Exemple SRS Volere
Exemple SRS IEEE 830
« Use cases et user stories », livrables d’ergonomie, diagrammes divers et variés … sont dans tous les cas de précieuses techniques pour spécifier les besoins.
Sur le plan fonctionnel et opérationnel, l’utilisation de ces user stories ou la construction progressive de Cas d’utilisation (« use cases »), (Acteur -> But -> Déclencheur et scénario nominal -> Extensions), le tout combiné aux spécifications IHM (wireframes ), sont désormais des standards, et des avancées majeures dans une vision toujours plus utilisateur et toujours plus orientée BUT.
Il s’agit avant tout ici d’un travail d’Equipe même si les spécialistes de l’Experience Utilisateur, de l’Analyse et des Tests apportent une vraie plus value.
Gérer les exigences
Les objectifs de cette activité transversale sont de faciliter la reconnaissance et la compréhension du lien entre les exigences, de permettre leur priorisation, et surtout de tracer leur prise en charge dans le projet (tel composant est le fruit de tel UC ou User Story, lui même issu de tel besoin, le tout testé dans tel cas de test); en somme, la vie d’une exigence aussi bien en amont qu’en aval de sa spécification.
Exemple d’une base d’exigences (RequisitePro)
Des outils spécialisés (Doors, Caliber-RM, Requisite Pro…) existent. Au final, ils sont plus complexes que véritablement utiles, car c’est surtout la prise de conscience de l’importance de cette activité qui est cruciale.
La gestion doit s’opérer de manière continue très tôt dans le projet : la base d’exigences ou tout simplement le BACKLOG de PRODUIT qu’ils soient manuels ou automatisés vont servir de fil rouge au projet et de référence à l’ensemble des acteurs.
Lister & vérifier (selon ces huit critères : caractère correct, clair, sans ambiguïté, cohérent, complet, réaliste, pertinent, vérifiable et traçable), qualifier, valoriser et surtout prioriser, suivre les exigences sont des tâches inhérentes à cette activité : il s’agit d’une grosse part du travail de l’analyste ou plus globalement du Product Owner.
Retrouvez des références bibliographiques sur ces questions dans la rubrique “Quelques livres“.
Posté par jc-QualityStreet le 27 juin 2007
Plus j’interviens dans les projets de développement informatique (Logiciel, Application Web, Sites Internet, INTRANET, EXTRANET …), plus je m’aperçois du caractère essentiel mais complexe, de trois activités, qui bien menées, maximisent pourtant les chances de réussite des projets:
- Recueillir et exprimer le besoin (Expression des besoins, Cahier des Charges, Vision …)
- Spécifier le besoin (Dossier de spécification, SRS, Use cases, User stories …)
- Gèrer et tracer les exigences (Backlog de produit, Liste des exigences, manuelle à base d’attributs ou sur des outils dédiés)
Évidemment, l’intensité, la répartition de ces activités va varier selon la taille et la nature du projet (Applications mètier, Sites Internet…), selon le contexte (Projet interne, R&D, Client, Appel d’offres), mais toutes trois se doivent d’être présentes et définies sur vos projets de conception…. D’ailleurs, dans un prochain billet, je détaillerai davantage le Quoi, et vous proposerai une réflexion sur le Comment.
Sans détours et sans vous rappeler les rapports CHAOS du Standish Group, je vous affirmerai pourtant que:
- La capture est souvent incomplète, biaisée, mal maîtrisée.
- La spécification souvent confuse, inadéquate, incorrecte, incompréhensible pour ses destinataires.
- La gestion des exigences faite dans l’urgence voire absente, et de toute façon sous estimée.
Sans détours, j’ajouterai même que le recueil, la spécification et la gestion du besoin, nécessitent au final une véritable expertise, la maîtrise de diverses techniques souvent complémentaires (issues des Sciences Humaines), et pas mal de rigueur…
bref, moins de blabla, moins d’artisanat, plus de professionnalisme et de méthode.
QUI
Vaste débat… et potentiellement pas mal de dérives…
Dans un contexte agile, on parlerait de Product Owner. Plus largement, l’Analyste, le Consultant, le Client sont des acteurs récurrents … mais aussi l’Ergonome qui de par son savoir-faire, ses objectifs et sa démarche centrée utilisateur doit en effet être un acteur privilègié du recueil et de l’analyse du besoin. Souvenez-vous , un produit “ergonomique” est un produit utile (issu d’un besoin EXPRIME ou NON) et utilisable : la présence de l’ergonome à ce stade est donc plus que légitime.
QUAND
L’expression des besoins et autres Cahiers des charges (suffisamment ouverts) sont quant à eux le fruit de l’activité de recueil, et servent souvent de déclencheurs pour la suite des opérations en mode agile, itératif ou séquentiel.
Dans une perspective séquentielle (cascade ou V: le pire), l’enchaînement est simple et bien connu. Les disciplines d’ingenierie (Spécification, Conception, Developpement, Intégration, Test) vont se dérouler dans un ordre trés précis avec la nécessaire validation de l’étape précédente pour passer à la suivante.
Les écueils de cette démarche sont nombreux : feedbacks et retours en arrière non prévus, corrections difficiles, pas de pilotage par les risques, manque de visibilité… Dans ce cadre, la gestion des exigences sera au mieux menée de manière transversale, servant de fil rouge à l’ensemble des acteurs et au projet; toutefois la plupart du temps la gestion des exigences ne sera pas envisagée ou sera traitée dans l’urgence.
Non ce qui marche, c’est l’AGILITE avec une bonne dose d’analyse, de test et d’expérience utilisateur.
Dans une perspective agile donc (l’idéal)
… de type SCRUM, méthode Agile la plus populaire, le degré de formalisme sera diffèrent; le tout intégré à chaque Sprint. Un effort particulier sera fait en Sprint 0, l’ingenierie des exigences se jouera principalement au travers du Backlog de produit & User Stories dans une dynamique plus collaborative, toute aussi disciplinée mais moins formelle. Le backlog de produit servira donc de fil rouge
Dans une perspective seulement itérative
… de type Processus Unifié (”Unified Process”), le concept ou plutôt la discipline “Ingènierie des exigences” prend cette fois tout son sens puisque prévue, formalisée et cadrée, permanente et continue. Les acteurs chargés de ces activités vont donc suivre le projet du début à la fin, certes avec plus de spécification en 1ère partie du projet (80% des cas d’utilisation doivent être rédigés en fin d’Elaboration), et davantage de gestion des exigences dans la seconde partie.
A bientôt pour plus de détails sur le Quoi et une idée du Comment.
