AGILE CMMI : Voyage d’un coach agile au coeur de la gestion des risques - RSKM

Posté par jc-Qualitystreet le 15 décembre 2009

Seconde étape de mon parcours au travers d’un référentiel Agile CMMI, après REQM « Gestion des exigences »,

Pour rappel, 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 la marche à suivre pour RSKM, “Gestion des risques“, l’un des  domaines du Niveau de maturité 3, dont l’intention est de « 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 ».

La gestion des risques est une activité indispensable à tout projet informatique ou pas. D’ailleurs le risque est inhérent à toute activité. DANS LE CADRE D’UNE APPROCHE combinant AGILE et CMMI, la gestion des risques est encore PLUS EFFICACE : collective, omniprésente et facilitée !

Au programme donc, RSKM dans une perspective Agile CMMI :

1. Quels sont les objectifs spécifiques à satisfaire OBLIGATOIREMENT?
2. Quelles sont les pratiques spécifiques initialement recommandées, et comment l’agilité  se marrie-t-elle avec celles-ci?
3. 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

RSKM SG1 : Se préparer à la gestion des risques
OK AGILE CMMI

Un travail de préparation est requis. Ce travail consiste à documenter la stratégie d’identification, d’analyse  et d’atténuation des risques. Agile ou pas : on doit le voir comme une aide. Un petit guide, incluant des checklists est toujours  précieux au démarrage d’un projet. J’en ai moi-même rédigé il y a quelques années. Ce travail relève de ce que j’appelle  le Process Agile : il est à disposition des équipes et du ScrumMaster quand le projet démarre. Dans un contexte Agile-CMMI,  c’est indispensable sans être véritablement contraignant.

RSKM SG2 : Identifier et analyser les risques
OK AGILE CMMI

Passé la préparation, on entre dans le vif du sujet, cette fois au niveau du projet. Les risques doivent être identifiés et analysés. Les méthodes Agiles contribuent fortement au travail d’identification des risques, en particulier quand le projet est lancé : c’est un des premiers atouts d’une gestion agile des risques.

RSKM SG3 : Atténuer les risques
OK AGILE CMMI

Une fois identifiés et analysés, il faut tout simplement les gérer. Je conseille aux équipes de rendre cette gestion la plus visible possible en adoptant l’AGILE RISK BOARD, à placer au cœur du radiateur d’informations. Là encore, cette pratique est littéralement décuplée sur les projets Agiles.

Agile Risk Board - Jean Claude Grosjean

Voilà donc trois objectifs à atteindre. Est-ce un problème pour l’agilité ? Non, et bien au contraire. Un process, des pratiques (l’AGILE RISK BOARD) et des équipes Agile CMMI permettent d’atteindre largement ces objectifs d’une manière résolument différente : à la fois organique (intégrée) et spécifique (au travers de différents RDV)

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’elles permettent d’atteindre l’objectif fixé. L’idée pour nous est de prouver qu’avec un process Agile, vous gérez les risques! Les trois premières pratiques relèvent du process Agile et sont menées hors projet.

RSKM-SP1.1 Déterminer les sources et les catégories de risques.
OK AGILE CMMI

Rien de très agile la dedans en effet. Des bonnes pratiques existent en la matière. Cela passe par des rapides checklist, la connaissance des sources potentielles (externes ou internes) et l’émergence de catégories : technique, fonctionnels, métiers, fournisseurs …, le tout en capitalisant sur les projets passés. Pourtant, garder l’esprit Agile reste la clé de ce petit guide fondé sur l’expérience et adapté à ses destinataires : juste ce qu’il faut !
Qui : Coach Agile
Quoi : Guide de gestion des risques

RSKM-SP1.2 Définir les paramètres utilisés pour analyser et catégoriser les risques ainsi que les paramètres utilisés  pour contrôler la charge de gestion des risques.
OK AGILE CMMI

Idem, nous sommes dans du Process Agile, et des bonnes pratiques existent : échelle de probabilité d’occurrence, échelle d’étendue de l’impact et sévérité. C’est du classique, c’est simple mais ça marche bien.
Qui : Coach Agile
Quoi : Guide de gestion des risques

RSKM-SP1.3 Etablir et maintenir la stratégie qui sera utilisée pour la gestion des risques
OK AGILE CMMI

Toujours du process Agile avec une description de la façon dont on va procéder sur les projets. On insistera ici sur l’aspect intégré et collectif de la gestion agile des risques mais aussi sur les points de contrôle et de surveillance beaucoup plus fréquents (réunion de planification, daily scrum, revue de sprint, Agile Risk Board…). Un rappel de ces éléments est nécessairement effectué dans le Plan de Projet.
Qui : Coach Agile
Quoi : Guide de gestion des risques - Plan de projet

RSKM-SP2.1 Identifier et documenter les risques.
OK AGILE CMMI

On est cette fois dans le projet. Le sprint 0 est le moment idéal pour compléter un travail probablement initié auparavant (business oblige !). J’insiste pour que cette démarche soit collective : l’identification des risques par des équipes pluri-disciplinaires est en effet généralement plus riche et plus efficace. L’autre avantage est de partager cette nouvelle connaissance sur les risques du projet. L’output de cet atelier de travail « Risques » est évident : une liste des risques.
Qui : ScrumMaster - Product Owner - Equipe
Quoi : Liste des risques (XLS,  PPT ou Wiki)

RSKM-SP2.2 Evaluer et catégoriser chaque risque identifié en utilisant les catégories et les paramètres de risques établis et déterminer leur priorité relative.
OK AGILE CMMI

Cette pratique va de pair avec la précédente, et se traite au cours du même atelier de travail puisque les risques identifiés sont catégorisés et priorisés selon les paramètres établis dans le petit guide de gestion des risques.
Qui : ScrumMaster - Product Owner - Equipe
Quoi : Liste des risques priorisée (XLS,  PPT ou Wiki)

RSKM-SP3.1 Développer un plan d’atténuation du risque pour les plus importants du projet tel que défini dans la stratégie de gestion des risques.
OK AGILE CMMI

RSKM SP3.1 , tout comme la pratique suivante RSKM SP3.2, ne se limite pas à l’atténuation des risques mais traite aussi du plan de contingence pour les risques avérés.  Ces pratiques sont les forces de l’Agilité. Ce travail permanent est médiatisé par l’Agile Risk board qui fait de la gestion des risques l’affaire de tous. La pratique est donc collective même si le ScrumMaster y joue un rôle essentiel : facilitateur dans l’âme sur toutes ces questions, il est là pour lever (avec l’équipe) les obstacles se dressant devant elle. Il est par ailleurs aisé d’ajouter un volet Risques sur un Backlog de Sprint et d’y maintenir une sorte de Top Ten des risques. Sur les projets que je coache, c’est le ScrumMaster qui gère les Backlogs produit et de Sprint qui s’en charge.  A tous les RDV de chaque sprint, les risques sont donc identifiés, analysés et gérés collectivement.
Qui : ScrumMaster - Product Owner - Equipe
Quoi : Agile Risk Board, Réunion de planification, Daily Scrum, Revue de sprint, Rétrospective

RSKM-SP3.2 Surveiller périodiquement le statut de chaque risque et mettre en œuvre selon les besoins, le plan d’atténuation du risque.
OK AGILE CMMI

Le management visuel : quel atout pour l’agilité !
l’Agile Risk Board permet beaucoup de choses mais plus formellement chaque début (réunion de planification) et chaque fin de sprint marquent des jalons essentiels 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 sont des passages obligés dans une perspectivel Agile-CMMI.
Qui : ScrumMaster - Product Owner - Equipe
Quoi : Agile Risk Board, Réunion de planification, Daily Scrum, Revue de sprint, Rétrospective

3 OBJECTIF(S) GENERIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI, et PRATIQUES ASSOCIEES

RSKM GG1 : Réaliser les objectifs spécifiques
OK AGILE CMMI

En somme pour RSKM, les 3 objectifs de préparation, d’identification, d’analyse et d’atténuation doivent être atteints.

RSKM GG2 : Institutionnaliser le processus en tant que processus discipliné
OK AGILE CMMI

Cet objectif est nécessaire dans les contextes CMMI et Agile CMMI.   Comme pas mal d’autres domaines de processus (par exemple La gestion des exigences), 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.
On parle donc de PROCESS AGILE et d’ENTREPRISE AGILE.

RSKM-GP2.1 Établir et maintenir une directive organisationnelle traitant du processus Gestion des risques…
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 (portant sur les méthodes agiles) mais on peut aborder brièvement, c’est mieux, la  gestion « agile » des risques . C’est en quelque sorte officialiser  ce mode de gestion dans l’entreprise.
Qui : Coach Agile, Sponsor, Direction, Equipes

RSKM-GP2.2 Planifier le processus Gestion des risques…
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. Dans ce document, un volet sera consacré à la gestion des risques, décrivant  le Comment sur le projet. Je conseille aux équipes de le faire en Sprint 0 et demande au ScrumMaster de s’en charger, en s’appuyant sur le guide de gestion des risques. C’est un petit doc, commun à beaucoup de domaines de process CMMI (exigences, risques, qualité …). C’est court, PPT, Word ou Wiki.
Qui : ScrumMaster.

RSKM-GP2.3 Fournir les ressources adéquates pour le processus Gestion des risques…
OK AGILE CMMI

Preuve doit être donnée que les ressources adéquates (humaines, outils …) ont été fournies et que l’attribution de ces ressources fut suffisante.  Dans notre cas, cela passe entre autres par le choix de l’outil de Backlog de sprint qui pourrait intégrer le volet risques, et par l’organisation d’un workshop dédié au risques en Sprint 0.. Cette activité fait partie intégrante du rôle du ScrumMaster, en Sprint 0. Donc pas de problème.
Qui : ScrumMaster.

RSKM-GP2.4 Assigner la responsabilité et l’autorité pour mettre en œuvre le processus Gestion des risques…
OK AGILE CMMI

C’est une composante du Process Agile, à inclure dans le Plan de projet. Qui fait quoi ? On s’attachera ici à décrire l’approche résolument collective de la gestion agile des risques (portée par l’équipe du début à la fin du projet) et la forte activité de facilitation du ScrumMaster sur cette activité.
Qui : ScrumMaster

RSKM-GP2.5 Former les personnes qui mettent en œuvre ou soutiennent le processus Gestion des risques…
OK AGILE CMMI

Cela fait partie de mon travail de coach Agile. J’aborde cette problématique dans les formations aux méthodes Agiles au sein de l’organisation. L’équipe devra prendre conscience de celle nouvelle gestion et du rôle qu’elle y joue mais un effort particulier devra être mené auprès du ScrumMaster, tant son rôle d’animation et de facilitation est intense sur le sujet.
Qui : Coach Agile.

RSKM-GP2.6 Placer les produits d’activité identifiés du processus Gestion des risques 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 la liste des risques, ou même des photos de l’Agile Risk board placées sur le wiki. Les CR de réunions de planification ou de sprint rentrent aussi dans cette catégorie.
Qui : ScrumMaster.

RSKM-GP2.7 Identifier et impliquer les parties prenantes concernées par le processus Gestion des risques…
OK AGILE CMMI

Comme pour la gestion des exigences, un petit tableau dans le Plan de projet fait en Sprint 0 est tout à fait pertinent. Le ScrumMaster est le responsable du plan de projet et le facilitateur de l’activité « Gestion des risques ». Pourtant, je ne l’associerai pas à l’acteur principal tant l’équipe, au quotidien, est partie-prenante.
Qui : ScrumMaster.

RSKM-GP2.8 Suivre et contrôler le processus Gestion des risques …
OK AGILE CMMI

Cette pratique consiste à suivre l’avancement des activités de gestion des risques sur la base d’indicateurs, vis-à-vis de son plan de mise en œuvre. La fin du sprint est de ce point de vue un jalon essentiel. Cela fait partie « par défaut » des attributions du ScrumMaster (également garant du process) mais un coach agile peut aussi s’impliquer dans cette pratique.
Qui : ScrumMaster - (et Coach Agile)

RSKM-GP2.9 Évaluer objectivement  le respect du  processus Gestion des risques…
OK AGILE CMMI

Relié aussi au GP2.2. C’est du QA. Le ScrumMaster étant le garant de la bonne application du Process Agile sur le projet, cela fait partie « par défaut » de ses attributions. Un coach agile de l’organisation ou externe peut aussi se charger de cette évaluation. Maintenant attention, le Process Agile est adaptatif…il faut en tenir compte dans le cadre de cette pratique.
Qui : ScrumMaster - (et Coach Agile)

RSKM-GP2.10 Revoir l’état du processus Gestion des risques avec la hiérarchie et résoudre les problèmes…
OK AGILE CMMI

Il s’agit essentiellement de donner de la visibilité à la hiérarchie pour que celle-ci  puisse entre autres résoudre les problèmes  soulevés. Et c’est justement le rôle du ScrumMaster. Il peut s’appuyer sur des éléments de l’Agile Risk Board.
Qui : ScrumMaster, Hiérarchie

RSKM 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… du standard certes mais dans une vision adaptative et non figée, fondée sur l’amélioration continue.

RSKM-GP3.1 Établir et maintenir un processus Gestion des risques ajusté
OK AGILE CMMI

Une description du processus Agile « standard » de l’entreprise doit être disponible (dont la gestion agile des risques). Elle servira de référence, mais sera ajustée à chaque projet (cela doit être prouvé),  Une AGILITE en CONTEXTE requise par CMMI. Oui vous avez bien entendu !
Définir le Process Agile standard, de manière collaborative et participative, cela fait partie de mon travail. Quant à l’adaptation au projet : c’est le boulot du ScrumMaster avec l’équipe, le Product Owner et le Coach Agile si nécessaire. Cette adaptation sera documentée dans le Plan Projet.
Qui : Coach Agile, les ScrumMaster, les Product Owner, les Equipes

RSKM-GP3.2 Collecter l’information d’amélioration du processus Gestion des risques
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. Revue de sprint, Rétrospective de sprint et de projet sont des moments privilégiés pour cette pratique.
Qui : Agile, les ScrumMaster, les Product Owner, les Equipes

BREF VOUS L’AVEZ COMPRIS, CMMI RSKM et AGILE… C’EST SANS RISQUES !

Agile CMMI : Voyage d’un coach agile au cœur de la gestion des exigences-REQM

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 :

1. Quels sont les objectifs spécifiques à satisfaire OBLIGATOIREMENT?
2. Quelles sont les pratiques spécifiques initialement recommandées, et comment l’agilité se marrie-t-elle avec celles-ci?
3. 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

RISK BOARD: la gestion AGILE des risques conforme à CMMI et à PMI !

Posté par jc-Qualitystreet le 4 avril 2009

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

• 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 ?

• Se préparer à la gestion des risques = OK
• Identifier et analyser les risques = OK
• Atténuer les risques = OK

• 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 !

Exclusivité ! UX: le futur Process CMMI Niveau 3…

Posté par jc-QualityStreet le 15 décembre 2008

…

WAIT! There is more to read… read on »

AGILE CMMI: le rapprochement officiel… et cette fois c’est le SEI qui vous le dit !

Posté par jc-QualityStreet le 17 novembre 2008

C’est officiel. C’est énorme !

Le voici donc enfin divulgué ce rapport technique du SEI (Softaware Engineering Institute) que j’attendais avec une impatience non dissimulée depuis plusieurs mois.

Ce rapport CMMI® or Agile: Why Not Embrace Both!, Technical Note (CMU/SEI-2008-TN-003) marque en effet un véritable tournant…

WAIT! There is more to read… read on »