Beaucoup pensent encore que CMMI et les méthodes Agiles sont incompatibles. Que si l’on fait du CMMI, on ne peut pas être/faire agile et que agilité ne peut pas rimer avec CMMI. Selon moi, tout est une question de (choix d’) implémentation, de créativité et de culture également.
La comparaison CMMI et méthodes Agile a été et est encore un sujet mainte fois abordé mais j’avais envie de faire l’exercice de mon côté, sans grande prétention, avec ma perception des choses et un peu de bibliographie.
Commençons donc par le début : le besoin client et les exigences (les Requirements du CMMI). Comment les 2 mondes envisagent-ils la gestion des exigences d’un projet ? Et comment pourrait-il être possible d’être agile dans ce domaine et conforme à CMMI ?
Les exigences composent le scope du projet et la gestion des exigences, au sens large, comprend chez CMMI :
- Requirement Development ( RD - niveau 3) : traite du recueil, de l’analyse, de l’arbitrage et la validation des exigences d’un projet à différents niveaux : clients, produits, composants, interfaces.
- Gestion des exigences (REQM - niveau 2) : traite de la gestion des exigences en terme de traçabilité et de gestion des changements.
- Tout cela devant être processé, mesuré, “audité”… ce sont certaines des GP, Generic Practices, que je préfère traiter globalement plus tard dans un futur article.
Travailler avec le client pour satisfaire ses besoins
CMMI ou Agile, même combat mais l’organisation peut varier énormément.
Dans un système CMMI “classique” où le client reste à sa place de client, souverain, où il existe une barrière plus ou moins forte entre MOA et MOE, le niveau de complétude ou d’exactitude du recueil des besoins dépend étroitement de l’efficacité du chef de projet (product manager, analyste…) ainsi que de la bonne volonté du client et sa capacité à exprimer ses besoins, immédiats et à plus ou moins long terme. Le CMMI, au niveau 3, blinde cette situation dans Requirement Development (Elicitation, analyse, scénarios, validation…). Mais c’est selon l’organisation de l’équipe et sa maturité en fait que la définition des exigences sera plus ou moins complète et efficace.
Pour ce faire, les méthodes agiles, dans leur majorité, intègrent d’emblée étroitement le client dans leur processus. Le client fait partie de l’équipe XP ou SCRUM alors que dans un certain nombre d’implémentations CMMI, le client n’intervient que ponctuellement lors du projet - et quand c’est pour voir le produit, il en profite pour émettre quelques demandes de changement… je carricature un peu, certes.
Pour régler ou limiter les conséquences de ce dernier point, SCRUM pose d’ailleurs une règle très simple : 0 change request quand le sprint est commencé. Cette philosophie n’est d’ailleurs pas contraire à CMMI, rien ne l’interdit, c’est un choix que l’organisation (incluant ou non le client) peut faire.
D’une manière générale, Agile accueille favorablement le changement car plus adapte à l’appréhender grâce à un cycle d’itération court et des livrables souvent moins nombreux- et ce, malgré (ou plutôt grâce à ?) les feedbacks fréquents que demande Agile de la part de ses clients.
Livrables et outillage
Définition des exigences
Dans des systèmes CMMI “classiques”, on trouvera des cahiers des charges plus ou moins lourds et détaillés, suivis par des spécifications fonctionnelles et/ou techniques plus ou moins verbeuses. Mais on peut aussi trouver de simples listes d’exigences (ou de fonctionnalités) plus ou moins détaillées type backlogs produit de SCRUM, de simples diagrammes Use cases… et des User Stories ! … Et ce, avec ou sans support d’un outil spécialisé.
Traçabilité
En terme de traçabilité, on trouvera des matrices de traçabilité reprenant les id de chaque exigence avec les relations entre elles et entre les livrables (dont les tests et le code source). Chez XP, un système de numérotation ou de nommenclature peut permettre une traçabilité simple entre High Level Stories, Detailed Stories and Test Scenarios. Une simple structure arborescente peut suffir également. Et on pourrait, autant pour CMMI que pour Agile, envisager même de faire une MindMap, si on veut sortir un peu des sentiers battus (d’ailleurs il faudrait que je creuse ça…)
La traçabilité peut se construire d’autant plus facilement chez Agile que les livrables sont moins nombreux et que les exigences se construisent progressivement, en partant d’un niveau restreint et suffisant pour lancer le projet. Dans un système “traditionnel” CMMI, les livrables ont souvent plus nombreux (parfois redondant), plus denses, amenant à des matrices lourdes à gérer, une cohérence difficile à maintenir. Et surtout on cherche à définir le maximum d’exigences afin d’établir le plan qui va guider le projet le plus précisément. La traçabilité a ainsi un coût d’entrée plus lourd.
Maintenant, la valeur ajoutée de cette pratique pour les méthodes Agiles pourrait être longuement discutée : itérations courtes au scope maitrisé, Test Driven, livrables peu nombreux… Mais le refactoring continu, ne pourrait-il pas être optimisé avec le support d’une matrice complète et à jour ? Le système, à force de grossir, deviendra trop gros pour être maîtrisé sans une traçabilité forte.
Enfin, des outils font ça très bien maintenant mais toutes les organisations, Agile ou CMMI ne peuvent pas forcément s’en doter alors il faut bien se contenter d’un tableur.
Gestion du Changement
La gestion des changements est souvent appréhendée dans les systèmes CMMI par une classique Change Request. C’est assez efficace en terme de preuve CMMI mais souvent mal vécu sur le terrain : un livrable supplémentaire qui ralentit l’action sur le projet. La Change Request a cependant l’avantage d’après moi, de forcer la mécanique d’étude d’impacts et de modifications en conséquence chez une population parfois ignorante de ce qu’est la gestion de configuration et trop immature (”agile !” diraient-ils 
) pour maintenir une documentation même minimale.
Et comme dit plus haut, le changement est bien accueilli car le rythme d’itération permet de l’appréhender plus facilement et la discipline requise pour le gérer est généralement présente : la règle de maintenance de la documentation permet de maintenir l’efficacité du système Agile.
Utilisation des tests
Les tests jouent un rôle extrêmement important dans les méthodes Agile car ils peuvent permettre la traçabilité exigences/composants mais peuvent aussi directement servir de spécification, ce qui va paraître hérétique pour un puriste CMMI. Mais en fait pourquoi pas puisque la spéc n’est que la description de ce que le système doit faire et le test, la retranscription de la spéc via les “résultats attendus”. Donc pourquoi écrire 2 fois la même chose sur des supports différents ?
Outils de support
L’utilisation d’outils commerciaux ou open source spécialisés en gestion des exigences ou de gestion de test va supporter la gestion des exigences de manière plus ou moins adaptée et faciliter la production de livrables (export de rapports, intégration avec Word / Excel) ou mieux, servir directement de preuve au sens CMMI (statut d’exigences, logs, traçabilité…)
Des outils de gestion documentaire, des Wikis aideront le versionning et le partage et l’identification des livrables. Quant aux outils de gestion de code source… comment dire ? pas d’informatique sans ce type d’outil, indispensable pour suivre à tous les niveaux l’implémentation des exigences et des changements dans chaque release.
On peut également faire des choses très efficaces sous Office ou Open Office et je pense que beaucoup d’organisations se lançant dans CMMI commencent par là. Un tableur bien ficelé avec des drop listes et des macros qui vont bien sera certainement dans un grand nombre de cas, suffisant pour suivre le backlog produit, les backlogs de sprint, la liste des exigences et automatiser en partie la génération d’une matrice de traçabilité.
Proposition de réponse agile aux pratiques CMMI
Donc si je devais envisager une réponse Agile à CMMI pour la gestion des exigences, cela donnerait le tableau ci-dessous :
| Pratique et Objectif CMMI | Explication CMMI |
Réponse Agile possible |
|
Requirement Development |
||
|
SG 1 Develop Customer Requirements |
||
| SP 1.1 Elicit Needs |
Eliciter les besoins des parties prenantes, les attentes, les contraintes et interfaces pour toutes les phases du cycle de vie du produit. |
L’initialisation du projet (définition du sprint 0 du Scrum, exploration XP) est une phase primordiale qui va aboutir à une Vision, premier stade, plus ou moins avancé du recueil des besoins ainsi qu’à une première version du logiciel. Durant le projet, le client fait partie de l’équipe, il exprime quasiment en continu ces besoins, et est à disposition des développeurs pour apporter autant de précisions que nécessaire. C’est de l’élicitation qui est en fait intrinsèque aux méthodes Agiles (XP, SCRUM, RAD…) Livrables / preuves : Vision, user stories, use cases, minutes de réunions*, prototypes, maquettes, wiki et ses logs (comme trace de l’intervention du client par exemple), revue de sprint, Persona |
| SP 1.2 Develop the Customer Requirements |
Transformer les besoins des parties prenantes, les attentes, les contraintes et interfaces en exigences clients |
Les besoins recueillis doivent être analysés et les conflits/contradictions/incohérences/lacunes résolus. La phase d’initialisation est principalement faite pour ça, jusqu’à un niveau jugé suffisant. Ensuite, ceci est fait en continu avec le client dans l’équipe. Les besoins sont “naturellement” transformés en exigences qui viennent se stocker dans les backlogs de SCRUM par ex. On doit y trouver des exigences fonctionnelles, non fonctionnelles, explicites et implicites. XP propose plusieurs niveaux de User Stories : High Level, Detailed puis les tests scenarios. Livrables / preuves : backlogs produits, backlog de sprint, use cases, user stories, tests scenarios |
|
SG 2 Develop Product Requirements |
||
|
SP 2.1 Establish Product and Product Component Requirements |
Etablir et maintenir les exigences produits et composants qui sont basées sur les exigences clients |
Les fonctionnalités sont directement traduites en exigences et d’autes en sont déduites (exigences non fonctionnelles, implicites). Ceci va constituer le backlog produit qui va être maintenu tout au long du projet. Les test d’acceptance sont ensuite définis dans la foulée. Le développeur Agile transforme les exigences en caractéristique/contrainte de son design et définit ainsi les exigences de ses composants via la philosophie du Test Driven Development qui répond à mon sens parfaitement à cette pratique. Livrables / preuves : backlog produit |
|
SP 2.2 Allocate Product Component Requirements |
Allouer les exigences à chaque composant produit |
Chaque fonctionnalité / exigence devra être assignées à une application, un module ou composant, ceci peut se faire dans la description de l’exigence - un champ “composant” par ex - et/ou via la définition des tests, eux obligatoirement rattachés à un composant (nommenclature, champ d’un outil de tests, classement des tests dans un repository…). XP introduit également des exigences “imposées” sur le code source : maintenabilité, lisibilité, faible couplage. C’est à ne pas oublier… Livrables / preuves : use cases, tests unitaires, tests d’intégration, tests système, référentiel de tests |
|
SP 2.3 Identify Interface Requirements |
Identifier les exigences d’interface |
Des tests d’intégration doivent être définis, qui peuvent répondre à des exigences plus large : communication entre composants, API, flux, ensemble/chaîne de composant réalisant un traitement, interfaces entre différents produits voire différents systèmes. L’interface graphique fait aussi partie de cette pratique. Et dans certains cas (Agile ou pas d’ailleurs), l’intervention d’un Ergonome aura un effet plus que bénéfique. Livrables / preuves : tests unitaires, tests d’intégration, tests système, référentiel de tests |
|
SG 3 Analyze and Validate Requirements |
||
|
SP 3.1 Establish Operational Concepts and Scenarios |
Etablir et maintenir les concepts operationnels et les scénarios associés |
Typiquement, la vision - à maintenir au cours du projet, d’itération en itération lorsque des changements surviennent. Mais aussi des diagrammes d’architecture plus ou moins high level. Livrables / preuves : Vision, Users Stories, Use Cases, architecture technique et fonctionnelle (overview) |
|
SP 3.2 Establish a Definition of Required Functionality |
Etablir une définition des fonctionnalités requises |
Les fonctionnalités viennent du client qui les expriment dans son langage, non technique, sous forme simple : users stories, use cases… Normallement, les uses cases suffisent car ils ont un niveau de granularité suffisament fin pour que le développeur commence son design et la définition de ses tests. Dans le cas contraire, un diagramme complémentaire apportera l’information nécessaire. Livrables / preuves : (Detailed) Uses Cases, Flowcharts, Activity Diagrams |
|
SP 3.3 Analyze Requirements |
Analyser les exigences pour s’assurer de leur nécessité et leur suffisance |
Agile réclame la priorisation des exigences par le client afin de répondre à un de ses objectifs : apporter de la valeur. Derrière les exigences fonctionnelles du client se cachent dans la plupart des cas des contraintes techniques ou des exigences non fonctionnelles (performance, recovery plan, sécurité, mirorisation…) qu’il convient de déceler et d’ajouter au backlog. Le refactoring intervient dans cette pratique dans le sens où il simplifie le design et peut aller jusqu’à supprimer des exigences / fonctionnalités devenues obsolètes. Livrables / preuves : backlog produit avec priorités, backlog de sprint avec priorités, versions/log/audit trail des user stories/use cases/design/tests scenarios (comme indice du travail d’affinement, de complément progressif ou encore de nettoyage) |
|
SP 3.4 Analyze Requirements to Achieve Balance |
Analyser les exigences pour équilibrer les besoins des parties prenantes et les contraintes |
L’équipe Agile est totalement orientée vers la livraison de fonctionnalités et s’engage sur un scope à chaque itération. La définition de l’itération se fait en prenant en compte sa capacité à la réaliser et les priorités données par le client. Par la notion de TimeBoxing, le scope sera corrigé en livrant moins si l’équipe ne peut faire autrement. Pour minimiser le travail de développement, l’équipe Agile privilègiera la réutilisation de code, la recherche de ce qui peut être réutiliser répond selon moi à cette pratique, si toutefois, une preuve est apportée. La composition d’une itération ne se fait pas forcément sur le simple critère de priorité donnée par le client. Il peut être judicieux de grouper des exigences de priorité différente car il existe une synergie à exploiter techniquement. Ce travail répond également à la pratique si un minimum d’explication est apporté. A contrario, une exigence prioritaire pourait être refusée pour l’itération à venir car un pré-requis technique n’est pas encore disponible, ce pré-requis sera inscrit au backlog de l’itération et l’exigence à celui de la suivante. Encore une fois, un minimum d’explication sur l’ordonnancement sera nécessaire. Livrables / preuves : minutes de réunion*, backlog de sprint (si un champ/colonne apporte une info du type commentaire “synergie avec exigence XYZ”, “pré-requis de ABC”..) |
|
SP 3.5 Validate Requirements |
Valider les exigences pour s’assurer que le produit fini fontionnera comme attendu dans l’environnement utilisateur |
La première itération du projet livre un produit qui permet de valider le périmètre fonctionnel du projet, ajuster certaines exigences. Je ne sais pas si cela est systématique ou fréquent pour les itérations suivantes - si pas trop courtes - mais une démo, revue d’un proto tôt dans l’itération, permettra également de répondre clairement à cette pratique. En fin d’itération, une revue peut permettre la validation d’exigences pour des itérations futures (selon le plan de release). Le contenu des itérations est élaboré avec le client avant démarrage. Pour chaque itération, l’engagement de l’équipe, dont le client, peut valoir pour validation. Livrables / preuves : statuts des exigences, minutes de réunion* |
|
Requirement Management |
||
|
SG 1 Manage Requirements |
||
|
SP 1.1 Obtain an Understanding of Requirements |
Développer une compréhension avec les fournisseurs d’exigences sur leur signification |
Cette pratique équivaut en fait, en résumé, à Requirement Development. Tout ce qui est dit plus haut, s’applique pour cette pratique. Précision toutefois : le rôle de fournisseur d’exigence fait partie intégrante des méthodes agiles : Product Owner chez SCRUM par ex. Livrables / preuves : Vision, User Stories, Uses Cases, prototypes, maquettes… |
|
SP 1.2 Obtain Commitment to Requirements |
Obtenir l’engagement sur les exigences de la part des participants du projet |
L’engagement de l’équipe projet, incluant le client, est un point primordial qui est obtenu lors de la préparation d’une itération. Livrables / preuves : minute de la réunion de préparation*, statut d’une exigence dans le backlog |
|
SP 1.3 Manage Requirements Changes |
Gérer les changements d’exigences au cours du projet |
Cette pratique touche de très près le Configuration Management de CMMI (que j’aborderai une autre fois) où une des pratiques est “Track Change Requests”, qui fait partie de l’Objectif SG2 “Track and Control Changes” - d’où en fait, le réflexe d’identifier une Demande de Changement en tant qu’objet et livrable dans la gestion des exigences. Mais l’objectif SG2 ne dit pas “Track and Control Change Requests”… donc si l’on se contente du libellé du SG2 seul, il existe sûrement une alternative sans Demande de Changement comme livrable supplémentaire… Livrables / preuves : versions (commentées ! - pour indiquer le pourquoi de la version) des User stories, des use cases… (logs de pages d’un wiki, audit trail d’un outil de gestion des exigences…), type “Change” pour un item dans le backlog de sprint ou versionning d’un item du backlog produit, versions des tests scenarios |
|
SP 1.4 Maintain Bidirectional Traceability of Requirements |
Maintenir une traçabilité bi-directionnelle entre exigences et livrables |
Je vois assez mal comment faire “agile” sans le support d’un outil qui automatise la traçabilité. Un tableur fera toujours des miracles et donnera le résultat escompté mais avec un coût certain qui me semble rendre cette pratique partiellement incompatible avec Agile. La traçabilité ascendante peut être mise en place sans effort insurmontable au niveau des différents livrables puisqu’il suffit d’indiquer quelque part le niveau d’exigence parent
La traçabilité descendante est plus complexe à mettre en place manuellement : tableur/liste à maintenir, problème pour les exigences transversales (UI, perf, sécurité…). Elle est pourtant fondamentale pour s’assurer que tous les use cases issus d’une user story sont bien livrés et que toutes les exigences sont couvertes par des tests. Livrables / preuves : matrice, tagging / nommenclature des livrables |
|
SP 1.5 Identify Inconsistencies Between Project Work and Requirements |
Identifier les incompatibilités entre les plans projet, les livrables et les exigences |
Le refactoring et la discipline de maintenir à jour une documentation reflétant systématiquement la réalité s’inscrivent dans cette pratique. CMMI ne dit pas qu’il faut identifier les incompatibilités avant de commencer à coder donc on peut faire ce travail à la fin de chaque itération pour commencer la suivante proprement. Livrables / preuves : logs de versions des livrables (User Stories, Use Cases, code source), tâche de refactoring/maj de doc, revue d’itération (minutes*). |
* j’entends par minute toute trace physique ou électronique qu’une réunion a eu lieu et dont le contenu apporte la preuve (directe ou indirecte) qu’une pratique a été mise en application. Sa forme, l’organisation de son contenu n’a que peu d’importance, on peut se contenter dans certains cas, de photos, de vidéos, de conversations enregistrées… au lieu d’un doc Word ou d’un formulaire d’un portail collaboratif.
Comment renforcer la conformité au CMMI ? (ou faciliter sa démonstration)
Des éléments sont donnés dans le tableau pour chaque pratique quand j’ai pu ou quand j’ai été inspiré. Toutefois, d’une manière plus générale…
- des traces doivent être laissées pour toutes les pratiques et il convient qu’au maximum ces traces soient produites “dans l’action” et non pas spécialement. Les compte-rendus de réunion ne sont peut-être pas naturels pour certaines équipes mais d’autres preuves sont possibles (statut, versions et simplement mails…) ou d’autres moyens que Word sont plus “amusants” d’utilisation (formulaire pré-conçus de portails collaboratifs à remplir au fur et à mesure lors de la réunion)
- la documentation minimale et suffisante peut s’avérer parfois à la limite de la conformité. Un flowchart en complément d’un use case sera toujours le bienvenu (une photo numerique d’un diagramme sur white paper suffit mais une photo numérique reste toujours délicate à refactoriser)
- une documentation plus générale du produit (overview d’architecture technique ou fonctionnelle) sera nécessaire et répondra d’office à certaines pratiques si elle est mise à jour bien sûr.
- la spécification d’un produit par les tests est simple et efficace mais va poser problème lorsque le système devient important : on ne peut pas prendre connaissance rapidement d’un produit s’il faut lire 10 000 cas de tests (automatiques en plus). Différents niveau d’abstraction sont nécessaires (cf point précédent). Le backlog produit peut être suffisant, remarquez…
- les versions des livrables doivent être commentées afin de répondre à certaines pratiques et éviter des livrables supplémentaires à gérer (change requests)
Où trouver d’autres infos ?
Certains hyperliens dans le texte vous apporteront des précisions sur des points précis mais voici d’autres liens que j’ai utilisés ou trouvés intéressants :
Site du SEI :
Diverses études de comparaisons dont :
Méthodes Agiles
Divers
Bibilothèque de lien concernant les méthodes Agiles
Outils
Related posts
Written by Arnaud
Tags: Agile, CMMI, exigences, méthode, requirements, Scrum, XP
(3 votes, average: 3.33 out of 5)
Loading ...Comments are closed.
