Posté par jc-Qualitystreet le 24 septembre 2009
Mais pas seulement…
Entre 1994 et 2009, le taux de réussite des projets IT est passé de 16% à 32 % (selon les dernières statistiques, et le dernier Chaos report).
Ok c’est mieux, mais toujours et vraiment pas terrible…
Petit retour en arrière, en 2006, le Standish Group revenait sur ces projets qui marchent en analysant les facteurs de réussite. Pour la première fois, l’agilité était citée … d’ailleurs Jim Johnson (Standish Group) en faisait l’éloge dans une interview sur InfoQ
TOP 5 des Facteurs de Succès (2006)
- IMPLICATION DES UTILISATEURS FINAUX
- Soutien de la direction
- Objectifs Business clairs
- Périmètre de projet optimal
- PROCESS AGILE
Chaque élément est important, et je suis ravi (comme tant d’autres qui prêchent pour leur paroisse…) de retrouver aussi bien placés dans la liste des éléments qui me tiennent à cœur. Mais la richesse d’un projet IT, et surtout les clés de sa réussite résident avant tout dans la juste association, l’habile combinaison, des bonnes pratiques et des méthodes. Combiner pour voir les choses différemment, combiner pour faire la différence et donner plus de valeur, combiner pour déclencher l’étincelle… et FAIRE QUE CELA MARCHE VRAIMENT.
Ma conviction est simple :
un cadre Scrum + le Lean Thinking et ses outils + des pratiques XP (toujours extrêmes en 2009 ? ) + l’Experience Utilisateur en fil rouge + une stratégie de Testing appropriée (Agile testing quadrants de Brian Marick) … Le TOUT EN CONTEXTE, AVEC DES EQUIPES MOTIVEES
= SUCCES !
Posté par jc-Qualitystreet le 12 mai 2009
La seconde édition de l’ouvrage de référence sur les
Méthodes Agiles vient tout juste de paraître.
Veronique Messager Rota nous livre là une
seconde édition enrichie (notamment sur les aspects Lean, Changement, Coaching et Ergonomie), un ouvrage complet et surtout
très OPERATIONNEL.
Pour avoir eu le privilège de le découvrir en avant première, je peux vous assurer que vous ne regretterez pas votre investissement. A consulter d’urgence et sans modération …
Au sommaire:
- Introduction - Chef de projet : un métier complexe
- Diagnostiquer sa gestion de projet
- Méthodes traditionnelles ou méthodes agiles ?
- Recueillir efficacement les besoins
- Planifier son projet
- Suivre et piloter son projet
- Gérer les hommes
- Adopter une approche agile
- Annexes
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 26 mars 2009
Prenez une grande bouffée d’air agile les 25 et 26 mai 2009 à Vincennes dans un lieu d’exception (Bravo les organisateurs !).
Vous souhaitez
découvrir l’agilité ou
approfondir avec des spécialistes des sujets plus précis qui vous tiennent à coeur sur
SCRUM,
LEAN ou
XP,
venez nous rejoindre (à un tarif préférentiel jusqu’à la fin du mois).
Cette conférence: c’est 2 jours d’intenses échanges au cours desquels se succéderont présentations, ateliers de travail et discussions informelles autour d’un bon café; le tout au vert, à deux pas de PAris.
J’interviendrai pour ma part le 25 après midi pour vous parler de
l’intégration de l’ergonomie (
Utilisabilité)
et de l’Experience Utilisateur dans les projets Agiles avec un gros Focus sur les
PERSONAS et le prototypage rapide et collaboratif.
Bref, une modeste contribution au sein d’un
programme qui personnellement me fait rêver…
Pour le reste si vous voulez discuter de SCRUM, d’Ergonomie, de Coaching, de pratiques collaboratives ou encore d’Agile CMMI (avec déjà de premiers retours d’expérience sur la question) : je serai là les deux jours !
Le programme:
D’ailleurs, et si on prenait le temps de faire un ROTI à chaque session ?
Jour 1:
Jour 2:
Posté par jc-Qualitystreet le 9 mars 2009
Vous devrez vous IMPLIQUER
Vous devrez privilégier la COLLABORATION
Vous devrez comuniquer la Vision du produit à concevoir
Vous devrez fixer des priorités
Vous devrez expliquer ce que vous attendez
Vous devrez répondre aux questions
Vous devrez donner vos critères d’acceptation
Vous devrez passer du temps avec les équipes
Vous devrez changer votre façon de spécifier
Vous devrez changer votre façon de recetter
Vous devrez STATUER en fin d’itération sur ce qui est DONE et ce qui ne l’est pas !
Sans quoi ça ne marchera pas !
… mais pour tout cela on vous aidera …
