Les méthodes Agiles n’abordent pas, à ma connaissance, le sujet du comment je prends une décision et quelles décisions je dois formaliser de manière approfondie. Le besoin de formaliser une décision mais surtout, formaliser le processus qui a amené à cette décision n’est déjà pas naturel - Agile ou pas - alors comment serait-il possible de se conformer à CMMI dans un cadre Agile ?
DAR, Decisions Analysis and Resolution… mais kézako ?
Tout simplement le processus appliqué pour prendre des décisions… et c’est là que certains managers, déjà échaudés par CMMI en général, sautent au plafond en montrant les crocs… “quoi ? il va falloir justifier toutes mes décisions ? mais c’est moi le manager, c’est moi qui décide, :evil: et il n’y a pas besoin de tout formaliser…” et blabla et reblabla…
Oula… respirons.
DAR est le processus amenant à une prise de décision… pour une décision qui mérite de déployer un processus formalisé. DAR ne demande donc pas de “formaliser” toutes les décisions - le processus stipulera quelles décisions devront passer à la moulinette. DAR demande en fait à ce que certaines décisions soient rationalisées grâce à des critères et prises selon des règles ou méthodes prédéfinies. L’objectif est d’aboutir à des décisions importantes prises objectivement, de manière posée et pesée. Donc, il est normal que toutes les décisions, notamment les plus anodines et les plus quotidiennes ne soient pas concernées.
Enfin, quand il y a une décision à prendre, c’est qu’il y a un choix, plusieurs solutions possibles. Quand il n’y a pas de choix ou une seule possibilité, il n’y a pas vraiment de décision à prendre… quoiqu’on pourrait décider de ne pas choisir… Ainsi donc, DAR devra s’appliquer quand il y a un choix à faire et que ce choix n’est pas évident ou que ses conséquences méritent d’être pesées.
On va ainsi “faire du DAR” pour des décisions bien particulières :
- quand il s’agira de choisir un sous-traitant ou un outil de production, de gestion de projet, de gestion de configuration,
- pour des décisions stratégiques de choix d’architecture ou de “make or buy”,
- pour stopper ou suspendre un projet,
- pour ré-orienter une stratégie produit et donc le ou les projets qui vont avec,
- quand le choix n’apparait pas naturel et que différentes alternatives sont possibles et valables,
- quand une décision implique un investissement de plus de X,
- quand le projet prend n de délai ou dépassement de charge
- …
Maintenant, si une organisation veut appliquer un processus formel de décision pour décider de la taille du bouton OK de son wizard d’installation… libre à elle, mais je lui conseille dans ce cas de distribuer le prozak à l’entrée des bureaux et d’éviter les plannings trop serrés à horizon de moins d’un siècle :o/
Mais en fait, si vous y regardez 2 secondes, vous vous rendrez compte qu’il y a une part de DAR tout le temps, dans toutes les décisions que vous prenez (dans le cadre professionnel ou quand il s’agit d’acheter le dernier grille pain téléviseur LCD à la mode et hors budget). Toujours, il y a un choix qu’il faut trancher, même minime et ça peut vous prendre 1s chrono en main de trancher. Durant cette seconde, vous avez passé en revue 3 ou 4 critères évidents pour vous et vous avez fait une comparaison pour faire votre choix. La différence, c’est que DAR réclame un formalisme là où vous resteriez planter à vous gratter la tête et à hésiter à monter une réunion pour résoudre ce point grâce aux avis éclairés de collègues ou de spécialistes. Et DAR va coûter plus d’une seconde, mais pas forcément n jours.
Les questions qui vous viennent maintenant, j’en suis sûr sont :
- “Si je prend 1min pour poser noir sur blanc sur un bout de papier, ces 3-4 critères et mes choix dans un tableau, est-ce que je fais du DAR”
- “Mais si je fais ça, est-ce CMMI ?”
- “Et est-ce agile ?”
Je vous laisse répondre … :-D
Quelles seraient les applications dans un cadre Agile ?
Comme je l’ai dit plus haut, certaines décisions sont quotidiennes comme celles issues des standing meetings / sprints quotidiens. Pas besoins de DAR, juste un compte-rendu de réunion listant les actions décidée, ça va de soi (… 
).
D’autres décisions sont évidentes : corriger ou pas ce bug critique sur la feature la plus prioritaire de l’itération… heu :-P
Là où DAR est le plus applicable selon moi est durant la phase d’initialisation où des choix doivent être faits qui vont guider toute la suite du projet. J2EE ok mais AJAX ou FLEX ? quelle base de donnée pour cette application financière ? refonte progressive du SI actuel ou projet Big Bang ? dois-je outsourcer mes tests et si oui, lesquels ? …
DAR a pleinement sa place dans cette phase d’initialisation. Et c’est le document de Vision qui a permettre de formaliser en partie le processus…
Plus tard dans le projet, l’équipe pourrait être amenée à choisir entre développer un composant ou l’acheter par exemple. Et mine de rien, ce n’est pas toujours aussi trivial que ça : gain / coût, maîtrise du code, évolutivité… voici quelques critères sur lesquels il pourrait être bon de se pencher pour faire son choix. Choix qui devrait être fait durant la préparation de l’itération.
Je suis sûr que vous avez d’autres circonstances ou cas où DAR s’appliquerait bien ou où vous avez appliqué DAR sans vraiment savoir que CMMI plainait au dessus de vous.
Déployer DAR peut se faire très facilement et rapidement :
- Préparation par l’initiateur du process 1h
- Préparation / revue par les personnes impliquées : 0.25 - 0.5h
- Réunion : 1h
- Compte-rendu : 0.5h
Soit un coût de 1j environ pour 5 personnes impliquées. Et si vous aviez déjà l’habitude de lancer des réunions pour prendre des décisions en équipe, DAR vous coûte 0j supplémentaire… hormis un coût initial pour créer les supports qui vous rendrons conforme à CMMI.
Une réponse possible à DAR en contexte Agile
| Pratique et Objectif CMMI | Explication CMMI | Réponse Agile possible |
|
Decision Analysis and Resolution
|
||
|
SG 1 Evaluate alternatives
|
||
| SP 1.1 Establish Guidelines for Decision Analysis | Etablir et maintenir des guides pour déterminer quels problèmes sont sujets au process formel |
Il n’y a pas de document prévu à cet effet chez Agile. Il faut donc trouver une place pour ça. Et selon moi, la meilleure place est le plan projet qui décrit l’organisation du projet. Un simple chapitre, court, sur les “Décisions formelles” suffirait. A défaut de plan projet, un complément à la vision - qui peut faire office de plan projet selon son contenu - (nouveau chapitre, annexe) ira très bien aussi. Livrables/preuves : Plan Projet, Vision |
|
SP 1.2 Establish Evaluation Criteria |
Etablir et maintenir les critères pour évaluer les solutions et leur poids |
Ici, ce sont les critères sur lesquels les solutions doivent être évaluées. Plusieurs approches possibles :
Des critères standard pourront être inscrits dans le chapitre “Décisions formelles” proposée en SP1.1. Livrables/preuves : Plan Projet, Vision, outil de support à la décision |
|
SP 1.3 Identify Alternative Solutions |
Identifier des solutions alternatives qui répondent au problème |
Les solutions mises en colonne dans un tableau d’évaluation / comparaison, quoi de plus simple ? En fait, une brève description de chaque solution sera toutefois la bienvenue : 2-3 lignes dans une case Excel devraient suffir à satisfaire CMMI et Agile et tout manager/chef de projet pressé. Livrables/preuves : outil de support à la décision, diagrammes, mail de préparation de la réunion décrivant les solutions, slides de support de réunion, prototypes |
|
SP 1.4 Select Evaluation Methods |
Sélectionner les méthodes d’évaluation |
On pourrait inventer une tonne de méthode d’évaluation et les combiner toutes pour en définir d’autres : vote, cabinet d’expert, échantillonage et méthode du Ki², certes mais prototypage et revue de proto me paraissent bien adaptées dans le cadre d’un projet Agile. “Simple” et dans la culture. Comme ce n’est pas toujours faisable, une revue de conception fera très bien l’affaire : 2 diagrammes UML à comparer sur un tableau blanc iront bien aussi (photos à l’appui, pour paufiner le tout et satisfaire le besoin de preuves CMMI). Afin de ne pas se poser la question à chaque décision formelle à prendre, décrire une ou 2 méthodes dans le plan projet au chapitre “Décisions formelles” est une bonne chose. La méthode doit indiquer le protocole d’évaluation mais aussi celui de notation et de choix. Ces méthodes prédéfinies pourront être modifiées lorsque nécessaire si cela est prévu à l’avance pendant la préparation du DAR (je précise à l’avance, car il est bien entendu très facile et tentant de modifier la méthode de notation lorsque celle choisie n’a pas donné le résultat attendu secrètement :roll: ) Livrables/preuves : outil de support à la décision, compte-rendu de réunion |
|
SP 1.5 Evaluate Alternatives |
Evaluer les solutions alternatives sur la base des critères définis et des méthodes choisies | Livrables/preuves : outil de support à la décision, compte-rendu de réunion, prototype, résultats d’analyse du/des prototype(s) (graph de performance, tests de charge, bugs saisis dans un outil de gestion d’anomalies ou autre document) |
|
SP 1.6 Select Solutions |
Sélectionner les solutions |
Livrables/preuves : outil de support à la décision, compte-rendu de réunion
|
Des outils ?
Vous pourrez sûrement trouver des outils tous faits sur le net mais franchement, hormis le logiciel que je compte développer un jour 8-) , il n’y a pas plus simple et maléable (agile allais-je dire) qu’Excel/Calc.
Un simple tableau suffit :
- les critères en ligne et leur poids éventuel
- les solutions en colonne
- chaque évaluateur rempli ses cases ou le groupe vote (selon la méthode choisie) et on calcule une somme, une moyenne pondérée ou pas (selon la méthode choisie une fois encore)…
- une formule de calcul
et le tour est joué.
Voici d’ailleurs un exemple :
Conclusion
On fait tous du DAR sans le savoir et sans le vouloir. Agile ou pas. Par conséquent, il y a peu à faire pour se conformer à CMMI.
Le gros du travail pour Agile réside dans le plan de projet (ou un doc de Vision modifié) et l’élaboration d’un outil de support plus ou moins standard et généralisé.
Ensuite, il ne s’agit pas de faire du DAR à tout va même si cela peut ne coûter qu’1j comme vu plus haut mais seulement pour des décisions qu’il ne faut pas “louper”, qui représentent un réel enjeu pour le projet, dans des cas prévus et anticipés (et parfois aussi de manière improvisée si nécessaire). Les projets Agiles, comme tout projet, ne manquent pas d’occasion.
Related posts
Written by Arnaud
Tags: Agile, CMMI, méthode, Scrum, XP
(No Ratings Yet)
Loading ...Comments are closed.
