Les Méthodes Agiles ne se contentent pas d’une gestion « classique » des risques; ils approchent les risques d’un projet informatique de manière beaucoup plus offensive, à la fois en termes de considération et de traitement: le projet est entièrement organisé pour lever au plus vite les risques les plus forts, ceux menaçant le plus de compromettre la bonne marche du projet.
Savoir gérer les risques est une bonne pratique de gestion de projet enseignée déjà depuis bien des années … alors pourquoi vous en parler aujourd’hui ?
- Parce qu’il y a quelques années, le Processus Unifié et surtout et l’Agilité ont redonné au risque une place de choix : les risques pilotent le projet (du moins pour le Processus Unifié), le contenu des itérations, et impactent donc l’activité de chacun d’entre nous (du développeur au testeur, de l’ergonome au Client ….).
- Parce que les bonnes pratiques Agiles, issues de SCRUM ou XP (courtes itérations, livraison incrémentale, daily scrums, reporting visuel, intégration continue, feedback client …) sont des armes redoutables pour faire face aux risques inhérents à tout projet informatique
- Parce que sur terrain, l’analyse des risques doit être conduite dans cette finalité, ce qui nécessite une véritable prise de conscience … Place à l’offensive (c’est là qu’elle prend tout son sens), n’y allons pas à reculons, ou simplement parce que le PMI nous dit de le faire ou que c’est un domaine de processus du CMMI !
- Parce qu’on sous estime (voire néglige) toujours des activités majeurs : Surveiller, Suivre et réajuster, Communiquer, Capitaliser pour les autres projets. Dans mon organisation, le pilotage par les risques (l’un des 6 principes du Processus Unifié) a été perçu comme un point fort; l’analyse a selon les cas été bien menée, servant de base à une priorisation des dév. (après arbitrage), malheureusement la suite n’a pas toujours suivi, sans parler de la base de risques, inexistante !! A nous d’aller jusqu’au bout et de s’en donner les moyens …
- Et parce qu’au final, la gestion des risques s’applique partout : petit ou gros projets, informatique ou non, comme le suggère la définition de l’AFNOR (« Un risque est un événement dont l’apparition n’est pas certaine et dont l’apparition est susceptible d’affecter les objectifs du projet »)
Bon, allons à l’essentiel, et glissons-nous un instant dans la peau de notre Chef de Projet Agile …
La gestion des risques sera partagée par l’équipe mais tout de même sous ma responsabilité… Je vais tout d’abord user et abuser du RISK BOARD tout au long du projet. Pour le rest dans les grandes lignes:
- Je mène l’analyse des risques de mon projet (sur la base de check-list, celle du SEI par exemple, grilles, critères, brainstorming …), évidemment pas tout seul en m’appuyant sur l’expertise de mes collègues techniques et analystes, sans qui je ne suis rien ! Je m’aide aussi de ces 5 catégories de risque pour y voir plus clair : Client / Organisation du projet / Métier (et fonctionnel) / Technique (et technologique) / Fournisseur (pratique quand on a des sous traitants).
- Très vite, et grâce au concours de mes collègues experts et de l’équipe, je valorise les risques en termes de Sévérité de l’Impact (délais, coûts, qualité…) et Probabilité d’apparition, ce qui me donne pour chaque risque un indicateur (une note) de criticité. C’est très classique.
- Je documente ensuite une fiche de risque, disons pour les 8 à 10 risques majeurs ; risques que je suivrai tout particulièrement. C’est à ce moment que je vais consulter mon responsable des tests car sa stratégie de tests sera impactée.
- Je veille ensuite à ce que les risques ne se transforment pas en problème, organise mon projet pour « lever » au plus vite les risques majeurs (en traitant par ex. en priorité les use cases / user stories contenant les éléments les plus risqués), utilise les bonnes pratiques Agiles les plus appropriées (côté technique, côté test, ou côté gestion de projet) et choisis plus globalement d’appliquer à mes risques l’une des 3 stratégies suivantes : Evitement, Transfert (autres équipes, autres projets ….) ou Acceptation (provisoirement en cherchant à réduire son impact, sa probabilité d’apparition ou définitivement si son impact est faible; le cas échéant, je passe au plan de secours)
- Je surveille, effectue le suivi et réajuste ma liste de risques … estimation et planification des itérations … arbitrages mais aussi feedback, rétrospective et adaptation ; toutes ces pratiques garderont le risque au coeur des préoccupations de mon équipe.
- Je mets à jour ma liste des risques et communique (notamment auprés de mon équipe) sur ceux-ci à chaque début et fin d’itération, et chaque jalon important ; communication verbale et écrite … Sans compter mes scrums tous les 2 ou 3 jours où ils sont régulièrement évoqués : en quoi puis-je t’aider ? .
- Mon projet se termine, je capitalise : la destinée de mes risques fut variable mais je les ai tracés, j’ai récolté de précieux indicateurs … et je commence à me constituer une base de risques disponible pour les projets suivants.
Au final: de l’AGILITE avec anticipation des difficultés et des points bloquants, maîtrise rassurante du projet et de ses évolutions, atteinte des objectifs, mais aussi une démarche disciplinée, définie et maîtrisée telle qu’attendue par le CMMI entre autres dans les domaines de processus suivants (PP, Planification du projet ; PMC, Surveillance et contrôle du projet ; RSKM, Gestion des risques).