Exemple de Plan de Projet

Posté par jc-QualityStreet le 20 septembre 2007

Bien plus qu’un livrable, le Plan de Projet (appelé aussi Plan de développement Logiciel), est un outil indispensable, nécessaire à la bonne marche de tout projet informatique (petit ou grand). Disons qu’avec un Plan de Projet correct, bien pensé et compris par les équipes, le projet débute sous les meilleurs auspices…

Le Plan de Projet est donc sous la responsabilité du Chef de projet , du Management ou du ScrumMaster (contextes Agile-CMMI), et rassemble en son sein toutes les informations utiles et nécessaires pour gérer le projet. Il est donc l’élément fédérateur du projet, la référence sur laquelle chacun va s’engager, et qui sera évidemment ensuite accessible par l’ensemble de l’équipe.

Juste ce qu’il faut de formalisme!

Le plan projet doit être soigné mais son caractère formel/ informel et la densité de son contenu vont varier en fonction des contextes et des tailles de projet. Il est essentiel de l’initier pour démarrer le projet; il va ensuite évoluer avec le rythme de celui (notamment au fur et à mesure des sprints dans un mode Agile)

Voici un modèle de Plan de Projet (structure type):

Juste ce qu’il faut de documentation!

Le Plan de Projet est central dans un contexte CMMI, au cœur du domaine de processus de niveau 2, Planification de projet (PP), et essentiel pour  la Gestion des exigences (REQM) et la Gestion des risques (RSKM). Autrement dit, si vous avez un Plan de Projet (ainsi que la démarche et le contenu qui vont avec …), c’est aussi un bon point de départ du point de vue du SEI quant à la maturité de ce domaine de votre organisation.

Mais surtout, le Plan de Projet fait partie de ce “Juste ce qu’il faut” de documentation qu’on retrouve aussi bien dans du process plutôt lourd (type RUP) - de moins en moins utilisés - que dans des versions beaucoup plus light du Processus Unifié (comme OpenUP), ou encore et de plus en plus dans des méthodes Agiles qui ont le vent en poupe comme SCRUM.

Scrum et la plupart des méthodes Agiles ne vous imposent bien évidemment pas de mettre en place un plan projet, vous laissant pas mal de marges de manœuvre quant à celui-ci. Mon expérience et mes activités de coaching agile m’ont néanmoins montré que la présence d’un plan de projet, souple, léger et ouvert était une vraie bonne pratique, rassurante à la fois pour l’Equipe, pour le Management et l’organisation.

Gestion des risques: mieux vaut être AGILE

Posté par jc-QualityStreet le 10 septembre 2007

Les Méthodes Agiles et  le Processus Unifié 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 que le Processus Unifié 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:

1. 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).
2. 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.
3. 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.
4. 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)
5. 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.
6. 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 ? .
7. 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).

Votre expert UP n’en est pas un …

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 ….

Processus Unifié : 10 bonnes façons de se planter …

Posté par jc-QualityStreet le 18 juillet 2007

Adapter le Processus Unifié et basculer vers les méthodes Agiles ne se fait pas en un mois (c’était mon précédent billet); la démarche doit être rigoureuse, nécessite un vrai plan d’accompagnement du changement et passe par des jalons importants: Convaincre - Préparer et Planifier - Mettre en oeuvre - Evaluer, Raffiner et Améliorer.

Sinon, voici 10 bonnes façons d’échouer dans la mise en place du Processus Unfié :

1. Vous ne vous faites pas accompagner par un expert du Processus Unifié, et de ses différentes instanciations (RUP; AUP; Open UP …)
2. Vous adoptez trop d’éléments, votre process est trop lourd, et manque de souplesse
3. Vous faites une adoption Big Bang: on change tout et tout de suite, sans préparation, sans méthode et sans accompagnement !
4. Vous analysez vite fait votre processus de développement existant (type cascade) et croyez qu’UP s’y adapte parfaitement : y a presque rien à changer, vous dites-vous !
5. Au fond, vous n’adhérez pas : itérations, risques, intégration continue, c’est juste des concepts à la mode !
6. Vous pensez que ça prendra 3 mois et considérez votre Development case (la configuration du Processus Unifié à votre contexte) comme un aboutissement, une fin en soi !
7. Vous conservez des vieux noms de livrables, de vielles recettes au détriment de nouvelles techniques, de la nouvelle et bonne terminologie
8. Vous ne pouvez vous appuyer sur les bonnes personnes (niveau organisation) et des acteurs clés ne jouent pas le jeu
9. Vous ne disposez pas de chefs de projet formés et motivés
10. Vous continuez de faire des spécifications excessives avant de commencer le dév, de prévoir les tests à la fin, de fixer des plans détaillés de A à Z, modifier vos objectifs en cours d’itération, de bouger vos dates d’itération, vous faites les choses dans votre coin : bref vous n’avez rien compris !

En quoi puis-je t’aider ?

Posté par jc-QualityStreet le 6 juillet 2007

… Qu’est ce qui t’empêche de faire ton travail ? Comment te faciliter la vie ?

Peu importe sa forme, cette question est aujourd’hui centrale dans la vie des projets. Elle est posée par le Chef de projet à chaque membre de son équipe, notamment au moment des scrums (« mêlées »), ces réunions d’équipe projet qui ont lieu tous les jours (c’est mieux) ou 2 à 3 fois par semaine et qui durent environ 15 minutes (et si possible debout : « We stand up to keep the meeting short »).

Le SCRUM est, à bien des égards, symbolique, et véhicule pas mal de valeurs (UP et une dose de SCRUM), mais il est aussi le reflet d’un chef de projet devenu, par nécessité, facilitateur et protecteur. C’est une vraie tendance (le chef de projet Agile) mais aussi et surtout l’ingrédient essentiel pour la réussite du projet, un élément tout simplement indispensable dans une perspective Agile où les itérations sont souvent serrées.
Concrètement, l’Organisation (au sens large) et les événement extérieurs doivent donc le moins possible interférer dans vie du projet : le chef de projet est là pour y veiller (mais quel est le poids du chef de projet au sein (face) de l’Organisation, quelle est sa marge de manœuvre, me direz-vous ?. ).
Facilitation et Protection sont donc deux dimensions, parmi les bonnes pratiques de management, que les méthodes Agiles ( SCRUm) ont su mettre en avant, mais dont elles n’ont pas le monopole : Scott Berkun , 10 ans de projets Microsoft derrière lui, et auteur de « The art of project management », l’une des références pour la gestion de projet informatique, va lui aussi dans ce sens en comparant le chef de projet (Project Manager) au fameux « Blocker » du Football Américain, celui qui permet au « Running Back » de mener à bien ses plus belles actions (rôle ô combien ingrat). L’art de la gestion de projet est un peu l’art du sacrifice :

If you look carefully at any highlight reel where someone runs for 70 yards, you’ll see another guy lying flat on the ground, buried under various large people, who was responsible for making the play possible. Good PMs make plays possible. They seek out and eliminate issues that are slowing the team down

Rugby (Scrum), Football Américain … décidément, le sport est une vraie source d’inspiration pour le management de projet !!!

Spécifications, Exigences et Cahier des charges : Quoi, Comment ?

Posté par jc-Qualitystreet le 2 juillet 2007

… avant tout un outil de communication et un brin de documentation (juste ce qu’il faut pour rester Agile) visant à rendre compte de l’adéquation de ce qui est livré avec ce qui est attendu, voulu par le Client et les Utilisateurs finaux;
… un travail produit dans le cadre du Recueil & Expression, de la Spécification et de la Gestion du besoin, composantes principales de ce qu’on appelle « l’Ingénierie des exigences » (=« Requirements » );
… des exigences au cœur des projets, qu’elle soient fonctionnelles (ce que le système doit faire, constituant par exemple un backlog de produit agile) ou non fonctionnelles (qualité du produit, principalement les attributs issus de la norme ISO 9126), présentes au travers de ces trois activités essentielles.
… et de nouveaux champs d’intervention pour l’Ergonome Agile comme je le décris dans le précédent billet de cette série: Spécifications, Exigences et Cahier des charges: Qui ? Quand ?

Recueillir & Exprimer les besoins

L’objectif est de fournir une vision claire du système à concevoir, d’offrir la définition et les limites du système, les fonctionnalités clés, les autres exigences et contraintes. Définir puis partager la Vision du produit est donc cruciale.
La vision synthétique est un excellent point de départ :

POUR (public concerné par le produit)

QUI SOUHAITENT (formulation du besoin des cibles)

NOTRE PRODUIT EST (ce qu’est le produit)

QUI (le bénéfice majeur, l’utilité de la solution)

A LA DIFFERENCE DE (pratique actuelle, concurrence)

PERMET DE (éléments différentiateurs majeurs)

Elle peut se prolonger dans de petits docs. à la structure souvent similaire :

Plan d’un Cahier Des Charges de Site Web

Plan de Vision Document (Wiegers)

L’entretien et l’observation sont  les sources d’informations principales mais d’autres techniques peuvent aussi être utilisées : questionnaires, focus group, observation, tests utilisateurs exploratoires, benchmarking, étude de l’existant, de la concurrence), présentation de maquettes…
Le savoir-faire de l’ergonome dans la conduite de chacune de ces techniques est un véritable atout, notamment pour trier et organiserclassifying the voice of the customer », selon Karl Wiegers ), discours qui peut prendre différentes formes : l’input des utilisateurs (« exigences Business, scénarios d’usage, règles de gestion, exigences fonctionnelles, attributs de qualité, contraintes, données, idées et solutions).
Ce premier tri nous servira à établir notre base d’exigences.

Spécifier les besoins

L’objectif est de détailler et de clarifier les besoins exprimés en analysant le fonctionnement du système de manière formelle et exploitable par les équipes de développement.
Même si ce n’est pas forcément leur objectif initial, les user stories et les éléments de conversation les accompagnant (conditions de satisfaction, exemple, wireframes…) constituent un moyen particulièrement efficace de spécifier le besoin de manière collaborative.

Les formats de spécification plus anciens se recoupent (IEEE, RUP, Volere …). Ils  intègrent généralement en leur sein une partie Exigences fonctionnelles. Cette intégration qui se concrétise souvent sous forme de renvois vers d’autres formats ou document  permet à cette documentation générale de rester synthétique, ouverte et abordable.

Exemple SRS Volere

Exemple SRS IEEE 830

« Use cases et user stories », livrables d’ergonomie, diagrammes divers et variés … sont dans tous les cas de précieuses techniques pour spécifier les besoins.
Sur le plan fonctionnel et opérationnel, l’utilisation de ces user stories ou la construction progressive de Cas d’utilisation (« use cases »), (Acteur -> But -> Déclencheur et scénario nominal -> Extensions), le tout combiné aux spécifications IHM (wireframes ),  sont désormais des standards, et des avancées majeures dans une vision toujours plus utilisateur et toujours plus orientée BUT.

Il s’agit avant tout ici d’un travail d’Equipe même si les spécialistes de l’Experience Utilisateur, de l’Analyse et des Tests apportent une vraie plus value.

Gérer les exigences

Les objectifs de cette activité transversale sont de faciliter la reconnaissance et la compréhension du lien entre les exigences, de permettre leur priorisation, et surtout de tracer leur prise en charge dans le projet (tel composant est le fruit de tel UC ou User Story, lui même issu de tel besoin, le tout testé dans tel cas de test); en somme, la vie d’une exigence aussi bien en amont qu’en aval de sa spécification.

Exemple d’une base d’exigences (RequisitePro)

Des outils spécialisés (Doors, Caliber-RM, Requisite Pro…) existent. Au final, ils sont plus complexes que véritablement utiles, car c’est surtout la prise de conscience de l’importance de cette activité qui est cruciale.
La gestion doit s’opérer de manière continue très tôt dans le projet : la base d’exigences ou tout simplement le BACKLOG de PRODUIT qu’ils soient manuels ou automatisés vont servir de fil rouge au projet et de référence à l’ensemble des acteurs.
Lister & vérifier (selon ces huit critères : caractère correct, clair, sans ambiguïté, cohérent, complet, réaliste, pertinent, vérifiable et traçable), qualifier, valoriser et surtout prioriser, suivre les exigences sont des tâches inhérentes à cette activité : il s’agit d’une grosse part du travail de l’analyste ou plus globalement du Product Owner.

Retrouvez des références bibliographiques sur ces questions dans la rubrique “Quelques livres“.