Le scope creep (dérive du contenu) est un fléau bien connu des projets informatiques. L'approche traditionnelle consiste à lutter contre ce phénomène en ajoutant plus de contrôle, plus de temps de réflexion et de préparation, plus d'implication des métiers, plus de précautions...
De son côté, l'approche Agile va consister à ne pas lutter contre le courant mais à avancer en se laissant porté afin de satisfaire le client et ses utilisateurs.
Pour le point de vue de l'approche traditionnelle sur le problème de la dérive du contenu (scope creep), nous vous recommandons l'article «comment empêcher que la dérive de contenu n’emporte au loin votre projet» de Duncan Haughey (traduit en français par Michel Operto sur son blog DantotsuPM).
Dans cet article, on identifie 5 causes à la dérive du contenu:
- Pauvre analyse des besoins
- Implication trop tardives des utilisateurs
- Sous-estimation de la complexité du projet
- Manque de contrôle du changement
- Sur-qualité
Dans le tableau ci-dessous, nous avons fait une comparaison entre les solutions de l'approche traditionnelle et celles de l'approche Agile aux causes de la dérive du contenu. L'objectif est de mettre en évidence l'opposition des types de solution recherchée: soit on ajoute des choses (contrôle, préparation...), soit on simplifie (lean).
|
|
Lire la suite...
|
La mise en place du suivi des temps déclenche souvent une réaction épidermique de la part des équipes, qui suspectent leur management de vouloir les surveiller, voire de vouloir les espionner.
Le suivi des temps est-il une forme de « flicage »?
Le suivi des temps ne sert pas à «fliquer». En effet, il repose entièrement sur une action volontaire de la personne concernée.
A l'inverse, pour faire du «flicage», il faudrait un vrai système de surveillance avec des logiciels qui espionnent à l'insu des personnes.
Le suivi des temps est généralement réalisé sur la base d'une déclaration de bonne foi sans aucune forme de vérification. On fait confiance aux gens pour déclarer leurs temps, et ceux qui veulent «tricher» peuvent donc le faire en toute impunité.
A quoi sert le suivi des temps ?
En premier lieu, le suivi des temps sert à comptabiliser.
Comptabiliser sert à donner de la visibilité au management et est la base d'une bonne gestion. Ce n'est peut-être pas « fun », mais c'est nécessaire, surtout dans un environnement professionnel.
On peut réussir des projets sans gestion, mais c'est risqué. On peut aussi faire de la comptabilisation implicite, comme dans SCRUM, mais cela implique certaines contraintes pas toujours faciles à respecter (taille de l'équipe constante, durée des sprints identiques etc.).
En général, le suivi des temps reste le brique de base de la comptabilité du projet, indispensable à sa gestion et à son pilotage.
Le suivi des temps peut aussi être utilisé par les premiers concernés, ceux qui suivent leur temps.
|
|
Lire la suite...
|
Le suivi des temps déchaîne rarement l'enthousiasme dans les équipes et bien des managers traditionnels peinent à le mettre en place. Cependant il trouve un nouveau sens et se renouvelle en mode agile en devenant une source précieuse de feedbacks pour toute l'équipe, principe fondamental de l'Agilité.
Feedback et Suivi des temps (Time Tracking)
 En matière de gestion de projet, le processus d'estimation reste un exercice difficile et approximatif, alors qu'il est essentiel pour déterminer la viabilité du projet. Et le suivi des temps est le seul moyen d'obtenir un feedback pertinent sur ce processus critique.
Dans le domaine du développement logiciel, les tentatives de rationalisation du processus d'estimation ont abouti à des résultats médiocres malgré la complexité des modèles analytiques développés (points de fonction, Cocomo etc.). En général, estimer un projet reste un processus empirique basé sur l'intuition et l'expérience des équipes, agrémenté de techniques de recherche de consensus. Mais la fiabilité des processus empiriques est soumise à caution et on constate en pratique des marges d'erreur importantes.
En mode Agile, on a la chance de pouvoir vite améliorer le processus d'estimation empirique. Il suffit de fournir à l'équipe le feedback adéquat: les écarts entre les estimations et le temps réellement passé au niveau de chaque item du backlog.
Alimenter en informations chiffrées les rétrospectives (SCRUM) est le premier objectif du suivi des temps en mode Agile. L'équipe fournit un retour qualitatif et humain, le suivi des temps le complète par un feedback quantitatif et objectif.
L'indicateur de Vélocité seul ne permet pas d'identifier les causes des problèmes. En effet, calculé au niveau du Sprint (= itération), c'est un indicateur trop macroscopique influencé par de nombreux facteurs. De plus, la Vélocité n'est pas une mesure mais le paramètre d'un modèle linéaire simple entre complexité et charge de travail.
Le suivi des temps permet aussi d'avoir une mesure précise du facteur de concentration (focus factor) pour ceux qui l'utilisent.
|
|
Lire la suite...
|
Souvent la technique de la Valeur Acquise (Earned Value Analysis ou EVA) est présentée comme une technique de gestion de projet parmi d'autres, alors que c'est LA Technique, et la seule, pour contrôler les coûts d'un projet.
Pourtant elle n'est que rarement pratiquée...
Une formation sur la gestion de programme a donné l'occasion de faire un petit sondage sur les usages de la technique de la valeur acquise. Sur les 9 chefs de projet expérimentés (>10 ans), 5 connaissaient la théorie et les formules (il y avait des PMP dans le groupe) mais aucun ne l’utilisait en pratique. Consternant, non ?
Ce sondage n'a pas une grande valeur statistique mais il révèle une triste réalité sur l'état de maturité de la gestion de projet dans notre pays et ailleurs.
Ce que dit le PMBoK
Dans le processus Contrôle des Coûts du PMBoK (§7.3), on ne trouve qu'une seule technique: l'analyse de la valeur acquise (Earned Value Analysis). Plusieurs pages lui sont consacrées, ce qui démontre son importance.
Le PMBoK donne un avertissement implicite en cas de non utilisation de la valeur acquise:
|
|
Lire la suite...
|
Pour tous les fans de l'Agilité et du développement logiciel, le site d'InfoQ est une mine d'informations et de ressources utiles.
Nous vous invitons à regarder la présentation intitulée: «10 ways to screw up with SCRUM and XP». Réalisée par Henrik Kniberg, elle a été filmée sur l'Agile Tour 2008.
En résumé, voici les 10 façons de se planter avec Scrum et XP:
- Croire à un miracle de l'Agilité
- Incapacité à définir ce que signifie «Terminé» (Definition of Done) ou à suivre la définition en pratique
- Incapacité à gérer la Vélocité (mauvaise utilisation, tricher sur la vélocité réelle...)
- Rétrospectives inefficaces
- Manque d'engagement de l'équipe
- Incapacité à bien gérer la dette technique
- Problème de travail en équipe (mauvaise définition des rôles, pb de coopération, interférence du management...)
- Problème avec le Product Owner (disponibilité, pouvoir, implication, mauvaise gestion du product backlog...)
- Peur de fusionner les développements car trop complexe à faire
- Problème d'utilisation du tableau des tâches (mise à jour peu fréquente, complexité...)
|
|
Le Timeboxing est une technique de gestion du temps utilisée dans les méthodes agiles pour la planification et la maîtrise des délais. Cet article en rappelle le principe et souligne les différences avec les approches traditionnelles.
Un concept très simple
Le Timeboxing est une division du temps en périodes successives d'une durée égale et relativement courte. Pour un projet, la durée recommandée des périodes est entre 2 et 6 semaines.
Cette technique est utilisée dans le domaine du développement logiciel pour imposer des livraisons fréquentes et régulières. L'objectif est d'accélérer le cycle de développement et le feedback des utilisateurs. Il s'agit aussi de lutter contre les problèmes bien connus de gestion du temps (cf. effet tunnel, lois de Parkinson et de Hofstadter, syndrome de l'étudiant etc.).
Dans le cas du développement logiciel, chaque période se conclut par une livraison. Elle est assimilable à une boîte dans laquelle il faut faire entrer le maximum de nouvelles fonctionnalités. La taille de la boîte est imposée et correspond à la charge de travail réalisable pendant la période. Le principal enjeu de la planification consiste à optimiser l'espace de chaque boîte en fonction de la priorité de chaque fonctionnalité et du temps nécessaire pour la développer.
Différence avec l'approche traditionnelle
En général, les techniques agiles prennent le contrepied de l'approche traditionnelle. Le Timeboxing n'échappe pas à la règle.
|
|
Lire la suite...
|
En quoi un Programme est-il différent d'un Portefeuille de Projets ou d'un gros Projet avec des sous-projets ?
L'objet de cet article est de clarifier le concept de Programme en s'appuyant sur les définitions du PMI ou de l'OGC.
Définitions
| Projet |
Entreprise temporaire, décidée en but de produire un résultat, produit ou service unique. |
| Programme |
Groupe de projets en rapport les uns avec les autres, gérés de manière coordonnée afin d'obtenir des gains et un contrôle supérieurs à ce qu'on aurait en les gérant indépendamment les uns des autres. |
| Portefeuille |
Ensemble de projets et de programmes qui sont regroupés afin de faciliter une gestion efficace dans l'atteinte des objectifs stratégiques. |
Définitions du PMI librement traduites
|
|
Lire la suite...
|
À en croire M. Yves Cavarec, secrétaire chapître du PMI Ile-de-France, les progiciels de gestion de projet sont perçus par les chefs de projets comme lourds, inadaptés ou contraignants.
En effet, dans une interview sur Microsoft TechNet, M. Cavarec fait un sombre constat en énonçant les 4 situations suivantes rencontrées dans les entreprises:
- le chef de projet «qui a l'habitude de gérer ses projets en toute transparence mais sans forcément utiliser des outils», pour lesquels l'utilisation d'un outil serait une contrainte.
- le chef de projet «qui va se dépêcher de mettre à jour sa planification dans l'outil de planification quelques jours [avant] ou la veille d'une revue de projet», ce qui correspond à un détournement de la finalité de l'outil.
- «l'utilisation parallèle des outils de gestion de projet et puis d'autres outils [tableur, traitement de texte etc.]. Pourquoi ? parce que l'outil n'est manifestement pas adapté à l'usage.»
- «le chef de projet est assommé par un ensemble de demandes. On lui demande de mettre à jour une planification dans un outil. on lui demande de mettre à jour un fichier Excel [etc...]. Il passe beaucoup de temps à faire de l'administratif alors [qu'il a bien d'autres fonctions]. L'aspect administratif de la gestion de projet prend le pas sur le reste.»
Chez Time Performance, nous partageons ce constat et c'est ce qui nous a poussé à envisager la gestion de projet autrement. De là est venue l'idée d'une Gestion de Projet 2.0 et d'un outil différent qui réunit l'essentiel de la gestion de projet dans un seul logiciel, simple et dont le reporting est totalement automatisé.
Sans être la panacée, PMA garantit un excellent rapport entre la valeur ajoutée pour le chef de projet et le temps qu'il passe dans l'outil.
Cliquez ici pour voir l'interview sur le site Microsoft TechNet
|
Sous la bannière de l'Agilité, il n'est pas rare de trouver réfugiées des équipes qui veulent retrouver une liberté d'action en échappant aux lourdeurs des méthodes traditionnelles. Mais connaissent-elles réellement les implications de l'Agilité ?
Suite au précédent article, 5 idées fausses à propos des Méthodes Agiles, nous vous proposons un 2ème opus avec 5 nouveaux préjugés sur l'Agilité.
Idée fausse n°6: les Méthodes Agiles, c'est la liberté de faire à sa façon
Equipe en "autogestion", remise en cause du rôle de chef de projet, redistribution des responsabilités, suppression des aspects contractuels, pas de planification détaillée, absence ou presque de documents, communication principalement verbale...
Tous ces éléments qui séduisent les équipes ont un petit goût de liberté et d'émancipation qui effrayera plus d'un manager.
Cependant il serait faux de considérer que l'Agilité est synonyme d'absence de règles, de contraintes et de structures.
|
|
Lire la suite...
|
|
