Posté par jc-Qualitystreet le 4 avril 2009
ou comment faire une gestion des risques vraiment efficace dans un projet Agile ?
Vous vouliez des réponses, en voilà ! …
Risk Board Agile Jc Grosjean
- c’est une activité essentielle de la gestion de projets informatiques
- c’est aussi une brique incontournable du référentiel AGILE-CMMI que quelques clients (conscients du potentiel énorme de la double approche dans certains contextes) commencent à me réclamer
- c’est enfin un ÉNORME point fort de l’Agilité (quand on s’y prend bien), point fort le plus souvent et étonnamment passé sous silence
En quoi la gestion Agile des risques est-elle différente ? Qu’est ce qui la rend extrêmement efficace (bien plus que ….) ?
- Ma gestion Agile des risques est MOINS FORMELLE et se fait dans un esprit “LEAN” (en jouant sur le juste ce qu’il faut et en éliminant les sources de gaspillage potentielles)
- Ma gestion Agile des risques est l’AFFAIRE DE TOUS, PLUS COLLECTIVE (portée par l’équipe du début à la fin du projet)
- Ma gestion Agile des risques est FACILITEE (seulement) par le chef de projet Agile (ou ScrumMaster)
- Ma gestion Agile des risques est avant tout QUALITATIVE
- Ma gestion des risques est OMNIPRÉSENTE
- Ma gestion Agile des risques propose des points de contrôle et de surveillance beaucoup PLUS NOMBREUX et beaucoup PLUS FRÉQUENTS
ET concrètement comment ça se passe ? ce qui nous intéresse c’est l’opérationnel 
Contextes pur Agile (SCRUM, XP) ou Agile-CMMI, peu importe… dans les deux cas il y a nécessairement un changement culturel important : la gestion des risques doit appartenir à l’équipe; elle est portée par l’équipe et va s’appuyer (fortement) sur un important travail de facilitation du Chef de Projet Agile.
Dans les grandes lignes, voilà à quoi ressemble une gestion Agile des risques:
- Un travail de planification de la gestion des risques est nécessaire au démarrage (ou à la signature) du projet Agile; ce court exercice relève selon moi d’un Process AGILE et insiste sur le caractère la fois ORGANIQUE (intégrée) et SPÉCIFIQUE (au travers de nombreux RDV) de la gestion Agile des risques. Il s’accompagne d’un petit guide prêt à l’emploi décrivant catégories, paramètres de risque, divers conseils peuvent aider notre chef de projet agile dans son activité de facilitation.
- En sprint 0, les risques seront identifiés et priorisés selon les paramètres classiques (probabilité d’occurrence et impact potentiel), c’est classique mais fait en équipe
- Ensuite à chaque sprint:
- les risques sont identifiés à tous les RDV du sprint (réunion de planification, Daily SCRUM, revue de sprint, rétrospective)
- les risques sont analysés et gèrés (recherche de diminution ou autre stratégie contenir, accepter, éviter) à tous les RDV du sprint (réunion de planification, Daily SCRUM, revue de sprint, rétrospective)
- les risques sont surveillés en permanence grâce au RISK BOARD présent sur le radiateur d’informations, et grâce au Burndown Chart
- Plus formellement, chaque début (réunion de planification) et chaque fin de sprint marquent des jalons plus formels pour la gestion Agile des risques: volet dédié dans l’ordre du jour, fiche de synthèse à chaque fin de sprint incluant une partie risque (ce point est d’ailleurs une exigence remontée par quelques chefs de projet à notre groupe de travail Agile-CMMI)
- Le RISK BOARD devient le support collectif de la gestion des risques, support aux vertus incroyables ! Tester votre gestion des risques avec ou sans, vous comprendrez la différence; c’est encore plus fort que les pilules rouges de Jeff Sutherland :) . On me demande souvent quoi placer sur un radiateur d’informations, et bien voilà quelque chose d’essentiel !
Et le Mapping avec CMMI / PMI ?
Vous avez là véritablement la première brique d’un référentiel AgileCMMI…
Même si les risques sont abordés dans d’autres domaines de processus CMMI (PP notamment), RSKM (”Gestion des risques”) est le domaine de processus que le SEI (Software Engeneering Institute) dédie aux risques. L’intention de RSKM est “d’identifier des problèmes potentiels avant qu’ils surviennent de telle sorte que les activités pour traiter les risques puissent être planifiées et déclenchées au besoin tout au long de la vie du produit ou du projet afin que les impacts nuisibles à l’atteinte des objectifs soient atténués.”
CMMI exige dans RSKM que vous répondiez à trois objectifs spécifiques:
- Se préparer à la gestion des risques = OK
- Identifier et analyser les risques = OK
- Atténuer les risques = OK
La gestion Agile des risques (telle que décrite ci-dessus) vous permet clairement de répondre aisément à ces trois objectifs et de bénéficier le cas échéant de toute une somme de preuves directes et indirectes tout à fait pertinentes dans un contexte de certification (SCAMPI A). Pour un mapping plus complet, vous pouvez vous référez à cet article :
AgileCMMI- Voyage d’un coach Agile au coeur de la gestion des risques - RSKMSur la question des risques
PMI et
CMMI marchent de concert, et notre gestion Agile des risques s’y retrouve donc aussi plutôt bien… Le
PMBOK décrit 5 grandes activités dans son domaine de connaissance “Management des risques du projet”, il suffit de regarder si ça colle …
- Planification de la gestion des risques = Oui
- Identification des risques = Oui et en mieux dans une dynamique plus collective
- Analyse quantitative et qualitative = Oui mais en mettant l’accent sur le qualitatif
- Planification des réponses aux risques = Oui et en mieux (collectif, fréquence et RISK board)
- Surveillance et maîtrise des risques = Oui et en mieux: les risques sont revus tous les jours et sont l’affaire de tous !
Bon, tout est dit. A vous de jouer.
Posté par jc-QualityStreet le 17 octobre 2007
Si vous n’étes toujours pas convaincu qu’OpenUP (”a lean Unified Process”) est un excellent compromis entre le RUP (instance la plus lourde du Processus Unifié) et les Méthodes Agiles, lisez cet article de Per Kroll, OpenUP In a Nutshell.
Peut-être vous incitera-t-il à télécharger OpenUP 1.0 (c’est gratuit), et à l’essayer au sein de votre organisation ! D’ailleurs pour cela, n’hésitez pas à consulter mes quelques conseils ou ceux de Claude Aubry.
Mais revenons à Per Kroll:
A couple of years ago, several colleagues and I started to think about how you could create a stripped-down version of the IBM® Rational Unified Process®, or RUP®, reflecting an agile approach to using RUP, while at the same time leverage all the good things we liked in other agile processes, such as Scrum and XP.
… sa démarche me plait d’autant plus, que c’est l’esprit qui m’anime depuis plus de 2 ans… je me sens donc moins seul :).
Per Kroll nous propose ainsi, dans son introduction, quelques rappels sur le développement itératif et incrémental, le cycle de vie du projet, le pilotage par les risques et la création de valeur ainsi que la “philosophie” Agile. Cela dit, on reste un peu sur sa faim côté pratiques SCRUM, XP et LEAN …
Sinon pour les inconditionnels, Per Kroll vous en parle directement dans cette video diffusée sur INfoQ.
Posté par jc-QualityStreet le 30 septembre 2007
Vous êtes nombreux à m’avoir sollicité sur cette question de l’Ergonome Agile :
en quoi consiste concrètement son travail dans des contextes UP, OpenUP, XP, SCRUM, DSDM ou Lean ?
Comment intégrer l’Expérience Utilisateur, le Design d’Interaction et le Graphisme dans un projet appliquant l’une de ces nouvelles méthodes, dites Agiles (car opposées aux cycles de développement traditionnels, en cascade ou V) ?
Tout d’abord, un constat : l’intégration d’une conception centrée utilisateur dans un contexte Agile n’est pas aisée, l’ergonome n’est pas attendu, et s’il ne parvient pas à prouver rapidement sa plus value, ou pire s’il retarde les équipes de dév. … on le sortira poliment du projet, c’est ça le Lean Thinking !!
Pourtant, croyez-moi les projets Agile ont un réel besoin d’ergonomie !!
L’ergonome Agile introduisait la nécessité pour nous autres Ergonomes ou Spécialistes de l’Interface Utilisateur, d’adapter notre démarche, nos outils et nos ivrables pour une collaboration plus efficace au sein d’équipes fonctionnant en mode itératif, incrémental. Cet article vous présente donc quelques pistes concrètes d’intégration de notre démarche mais n’hésitez pas à me contacter si vous voulez en savoir plus …
« … Le temps est donc venu pour l’ergonome de devenir Agile … », telle était donc ma précédente conclusion, mais quelles spécificités du profil de l’Ergonome Agile vont rendre sa collaboration plus efficace et surtout plus efficiente ? Quelles dimensions de son activité seront bénéfiques au projet, au client, aux utilisateurs finaux et en quoi son intervention donnera-t-elle satisfaction à l’équipe de développement ?
D’ABORD LE PROFIL DE L’ERGONOME AGILE
L’ergonome Agile possède…
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 28 août 2007
Agilité rime souvent avec Absence de documentation : voilà une idée reçue bien nuisible qui doit être combattue avec force … car mener un projet en utilisant les méthodes Agile (Agile UP, xxUP, XP, SCRUM…), n’a jamais signifié « ne produire aucune documentation ».
A l’origine de cette confusion ? Peut être une mauvaise interprétation de l’Agile Manifesto et de l’une de ses 4 valeurs « un logiciel fonctionnel plutôt qu’une documentation complète », ou plus simplement la facilité, un manque de volonté voire de compétences de certaines équipes de développement souvent soumises à un timing toujours plus serré …
Soyons clairs, privilégier l’application (ou un prototype) qui marche, plutôt que la documentation, à la fois pour mesurer l’avancement d’un projet et valider ce qu’on fait est un principe agile de base, indispensable et dont je suis entièrement convaincu (la documentation ne doit jamais servir d’indicateur de productivité). Mais aujourd’hui, peu de projets peuvent se passer d’une documentation (au sens large) précise et adaptée.
Ma position tient donc en quelques mots … « JUSTE CE QU’IL FAUT », en réfléchissant attentivement :
- A la Valeur du doc (ou de l’artefact) par rapport à l’Effort pour le produire et surtout le maintenir, sans perdre de vue que notre but, notre métier, c’est faire du soft, c’est concevoir des applications informatiques, ce n’est pas produire du papier !
- En termes de réponse à un besoin, de bénéfice pour le projet, de feedback …
- Et toujours en fonction de destinataires potentiels
Car être agile c’est avant tout penser communication, feedback, réactivité et adaptation plutôt que lourdeur, lenteur et bureaucratie, et croyez-moi une telle approche nécessite même une grande discipline ! Etre agile, c’est donc documenter de façon intelligente, appropriée et précise son projet en s’appuyant sur ce dont on a réellement besoin et ce qui est attendu pour éviter un gaspillage de temps et d’argent.
L’expérience me montre que l’utilisation d’un certain nombre de documents est quasi obligatoire sur la plupart des projets (la Vision par exemple, et d’autres pour la gestion de projet, les spécifications, …), et que certains contextes nécessitent plus naturellement (sans imposer) un certain formalisme (je pense à l’Offshore ou encore au CMMI, Capability Maturity Model Integration …). D’ailleurs, à l’autre extrême (autre idée reçue), se référer aux bonnes pratiques du modèle CMMI ne signifie pas pour autant, excès de bureaucratie et documentation à outrance.
Tout est donc affaire de mesure … SCRUM (la méthode Agile la plus populaire du moment) ou encore la conduite efficace de projets agiles vont dans ce sens.
Le Processus Unifié (dans une version customisée et adaptée à l’entreprise) peut assurer un très bon compromis, en permettant de constituer rapidement un excellent référentiel de doc. et bonnes pratiques que le chef de projet devra de nouveau ajuster à chaque projet (par l’intermédiaire du Plan de projet, élément incontournable d’UP qu’on retrouve aussi dans les pratiques du processus PP (« Planification du Projet »), l’un des 7 processus de niveau 2 du CMMI 1.2).
Pour le reste, les qualités de l’auteur de la documentation feront la différence pour la rendre correcte, précise et pertinente mais aussi lisible, légère et acceptable : en effet rédiger des cas d’utilisation ou même des user stories ne s’improvise pas, tout comme décrire des « personas », faire des diagrammes UML, des grilles fonctionnelles, rédiger un guide utilisateur, définir un plan de projet ou encore maintenir un plan d’itération …
Posté par jc-QualityStreet le 25 juillet 2007
- S’il décrit les phases du processus comme des phases séquentielles et insiste pour que la plupart des tâches soient effectuées avant le développement proprement dit
- S’il vous suggère des itérations de plus de 6 semaines
- S’il vous recommande de planifier une longue phase d’inception
- S’il vous recommande d’élargir le nombre de livrables plutôt que de les réduire
- S’il diffère sans cesse les tests … plus tard … rien ne presse
- S’il vous invite à produire toujours plus de diagrammes UML ….
