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 - RSKM
Sur 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 …
Posté par jc-QualityStreet le
Quand une équipe fait appel à moi pour une mission de coaching Agile ou que je m’engage dans un séminaire interactif consacré à l’agilité, mes interlocuteurs sont toujours surpris et curieux de me voir aborder ces questions là …
Vous êtes le premier à nous en parler…
Je n’avais pas vu le Sprint Zéro sous cet angle…
Ça me rassure, j’y vois plus clair…
Attendez mais c’est donc compatible avec notre process de déploiement…
Sans pour autant fixer des règles ultra figées qui n’auraient guère de sens dans un contexte Agile, j’ai pourtant des messages forts à délivrer et quelques repères à proposer :
- Oui, dans un projet Agile, il y a un Sprint 0 au démarrage, un sprint vraiment différent des autres, même si sa durée selon les contextes est variable (de quelques jours à 3 semaines) en fonction de la maturité de l’Equipe sur certaines questions…
- Oui dans un projet Agile, il y a souvent un “End Game”, un sprint un peu particulier en fin de version…
Et puisqu’un schéma vaut mieux qu’un long discours, voilà un exemple de cycle de vie (agile) :
SPRINT 0
Le Sprint Zéro n’est pas un vrai sprint (agile) au sens où il ne se termine pas forcément par la livraison d’un produit qui marche, et que sa durée est variable (de quelques jours à 3 ou 4 semaines). Ce sprint est pourtant essentiel pour mettre le projet sur de bons rails et permettre à l’équipe d’apprendre à travailler ensemble.
C’est un moment privilégié pour construire sa collaboration et prendre ses marques.
Quelles sont les activités typiques menées en Sprint 0 ?
- Partager une VISION claire du produit
- Analyser les risques
- Déterminer un plan de release (version)
- Produire un Backlog de produit estimé et priorisé
- Préparer l’environnement de développement (y compris quelques docs)
- Définir la posture ergonomique de l’interface et identifier les cibles (Personas)
- Selon les contextes, travailler l’architecture
- Dans tous les cas rôder l’équipe qui se DECOUVRE
END GAME
“End Game” mais pas vraiment une fin dans le sens où dans les faits ce sprint apparaît davantage comme une transition. Ce sprint, c’est le moment où l’équipe met la touche finale à la version et travaille de concert avec ceux qui vont déployer et exploiter au quotidien la future application.
Attention : CE N’EST PAS UNE PHASE DE TEST, même si certains types de test y trouveront une place privilégiée (tests d’acceptation, performance globale, alpha ou beta testing).
La durée du End Game est aussi variable (selon les activités menées au préalable), il peut être très court même courir sur deux sprints…
Quelles sont les activités typiques pouvant être menées en End Game ?
- Test final de la version dans un environnement similaire à la Prod
- Tests d’acceptation et tests utilisateurs sur l’ensemble de la version (même si des tests ont été réalisés au fur et à mesure)
- Tests d’install
- Possibles tests d’intégration de parties tierces non disponibles jusqu’alors
- Rework car qui dit test dit activité de dév
- Touche finale à la documentation
- Formation des utilisateurs
- Travail sur les bases de données
- …
