10 façons de se planter avec Scrum et XP

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:

  1. Croire à un miracle de l’Agilité
  2. Incapacité à définir ce que signifie «Terminé» (Definition of Done) ou à suivre la définition en pratique
  3. Incapacité à gérer la Vélocité (mauvaise utilisation, tricher sur la vélocité réelle…)
  4. Rétrospectives inefficaces
  5. Manque d’engagement de l’équipe
  6. Incapacité à bien gérer la dette technique
  7. Problème de travail en équipe (mauvaise définition des rôles, pb de coopération, interférence du management…)
  8. Problème avec le Product Owner (disponibilité, pouvoir, implication, mauvaise gestion du product backlog…)
  9. Peur de fusionner les développements car trop complexe à faire
  10. Problème d’utilisation du tableau des tâches (mise à jour peu fréquente, complexité…)

Suivre l’avancement du Projet

Suivre l’avancement est la mission n°1 du chef de projet pendant la phase d’exécution. Tout le travail de planification ne sert à rien si on ne suit pas l’avancement. L’avancement est au cœur de la gestion de projet.

Ce tutoriel présente comment se gère l’avancement avec TimePerformance.

3 bonnes nouvelles pour les chefs de projet

Tout a été fait dans TimePerformance pour simplifier le travail du chef de projet.

Suivi de l'avancement du Projet

La première bonne nouvelle est que le calcul de l’avancement est totalement automatique pour les niveaux supérieurs du plan projet. Ces niveaux sont le projet, les phases, les étapes et les livrables avec des sous-livrables (cf. structure du plan du projet).

Pour ces éléments, la technique de la valeur acquise définit la bonne façon de calculer l’avancement. Il s’agit d’une somme des avancements pondérés par les budgets. C’est standard et le logiciel fait tout.

La deuxième bonne nouvelle est qu’il n’y a pas besoin de suivre l’avancement des tâches. Dans TP, les tâches sont soit « pas commencées », soit « en cours », soit « terminées ». (toute ressemblance avec une méthode agile bien connue est fortuite 😉 ). C’est la personne qui réalise la tâche qui met à jour son statut.

Les seuls avancements restants à déterminer concernent les livrables. La troisième bonne nouvelle est que ce travail de suivi de l’avancement des livrables demande moins de 5 minutes par semaine.

Avancement d’un livrable

Il n’y a que 2 avancements qui soient sûrs: 0% (pas commencé) et 100% (terminé). Plusieurs techniques permettent d’évaluer l’avancement entre ces 2 valeurs.

Le suivi de l’avancement d’un livrable peut être fait par une saisie directe de l’avancement ou automatiquement selon 4 modes de calcul.

Chaque option a ses avantages et ses inconvénients. Le choix de l’option dépend du type de livrable et des préférences du chef de projet. Ce choix se fait dans le formulaire de chaque livrable. Dans la configuration du projet, le chef de projet peut choisir l’option par défaut de suivi d’avancement des livrables.

Saisie manuelle

Dans ce mode, le chef de projet saisit directement dans le rapport d’avancement le pourcentage d’avancement ou le reste à faire du livrable. (cf. formule entre reste à faire et avancement )

Options d’avancement automatique

Voici les 4 modes automatiques du calcul de l’avancement.

Reste à faire sur les tâches Quand cette option est choisie, toutes les tâches associées ont un reste à faire à renseigner au départ puis mis à jour automatiquement
% de tâches terminées % d’avancement = ratio du nombre de tâches terminées.
Ex: 4 tâches terminées sur 10 ⇒ 40% d’avancement
% de la charge consommée Ex: Une formation de 4 jours (donc 4 jours-hommes budgétés). 2 jours déjà effectués. L’avancement est de 50% = 2/4
% du délai écoulé Ex: La gestion de projet pour la phase d’étude qui dure 3 mois. A la fin du premier mois, l’avancement est de 33% = 1/3

Note: Le calcul automatique à partir des tâches exige que toutes les tâches rattachées au livrable soient créées en amont.

Quelques conseils

Conseil n°1: La simplicité

Dans le doute ou au départ, choisissez toujours l’option la plus simple: la saisie manuelle. Cela permet de garder le contrôle.

Conseil n°2: La bonne granularité

Choisissez la bonne granularité pour les livrables du projet.

Si les livrables sont trop gros, l’avancement risque d’être très approximatif. Dans ce cas, décomposez les livrables en sous- livrables.

Si les livrables sont trop petits, ce sera très lourd à gérer. Dans ce cas, il est possible de regrouper plusieurs livrables pour en faire un plus gros.

La bonne granularité des livrables est une affaire de compromis entre précision de l’avancement et charge de gestion.

Conseil n°3: Clore les livrables

Si un livrable est à 100% d’avancement, pensez à le clore en changeant son statut à Terminé. Ainsi vous vous assurez qu’il ne reste aucune tâche non terminée rattachée à ce livrable.

Conseil n°4: La régularité

Les saisies et le suivi de l’avancement doivent être faits au moins une fois par semaine.

Si cela n’est pas fait, cela signifie que les écarts ne sont pas surveillées, et donc que le projet est sans pilote. Que fait le chef de projet ?

Conseil n°5: Mixer les options

Voici une technique pour combiner les avantages de chaque option.

Pour un livrable, commencez par saisir manuellement l’avancement. C’est simple et ne requiert pas d’identifier immédiatement toutes les tâches et d’estimer leur reste à faire.

Puis lorsqu’on approche de la fin (par exemple à 70% d’avancement), basculez le livrable en mode «reste à faire sur les tâches. Saisissez le reste à faire au niveau des tâches restantes. A ce stade, l’identification des tâches restantes devrait être simple et la saisie des restes à faire moins lourde.

Avec cette technique, on combine la simplicité au début et la précision sans lourdeur excessive vers la fin.

Version 2.8

  • Nouvelles possibilités pour le calcul de l’avancement (reste à faire …).Cette nouvelle version introduit 3 nouvelles façon de suivre l’avancement des objectifs du projet (i.e. livrables).
    Les 4 options sont:

    • la saisie du pourcentage au niveau de l’objectif,
    • la saisie d’un reste à faire pour l’objectif (nouveau)
    • calcul de l’avancement à partir du % de tâches closes (nouveau)
    • calcul à partir du reste à faire au niveau des tâches (nouveau)

    Pour plus de détails, consulter le tutoriel sur le suivi de l’avancement.

  • NB: la saisie de l’avancement d’un objectif se fait maintenant directement dans le rapport d’avancement et non dans la fiche des objectifs.
    Pour cela, il suffit de cliquer sur la case dans le tableau pour saisir une valeur.
  • Nouveau graphique: le Burndown Chart.Le Burndown Chart permet de visualiser graphiquement le reste à faire pour le projet, une phase ou une étape (i.e. sprint). C’est l’outil de prédilection des méthodes Agiles (ex: SCRUM) pour suivre l’avancement.

    Burndown Chart (SCRUM)

    burndown chart

  • Ajout d’un rapport d’activité global au niveau du projet. Ce rapport est disponible dans le Tableau de Bord. Il permet au chef de projet de vérifier la bonne saisie des temps de son équipe en un coup d’oeil.

Rapport d’Activité de l’équipe pour le projet

burndown chart

Timeboxing

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.

Continuer la lecture de « Timeboxing »

Gestion de Programme: quelles différences avec la gestion de Projet ou de Portefeuille ?

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

portefeuille-programme

Différences Programme vs Gros Projet avec des sous-projets

Dans un projet avec des sous-projets, les liens entre les sous-projets sont plus forts que les liens entre les projets d’un programme. Notamment, dans un gros projet, chaque sous-projet ne peut exister en dehors de l’ensemble. Dans un programme, on peut imaginer que des projets puissent continuer même si le programme est remis en cause.

Concrètement, dans un programme, chaque projet a son propre Business Case, c.-à-d. sa propre justification. Dans le gros projet, il n’y a qu’un seul Business Case et les sous-projets sont créés afin de faciliter la gestion d’un projet très complexe.

Le programme a aussi son propre Business Case qui explicite les gains générés au niveau du programme et justifie la création de cette couche de management supplémentaire.

Différences Programme vs Portefeuille

Un portefeuille rassemble des projets qui n’ont pas forcément de rapport entre eux. Dans un programme, c’est justement le rapport existant – ou possible – entre les projets qui est la raison d’être du programme.

Le terme rapport est volontairement assez vague pour couvrir des situations diverses.

L’exemple évident de rapport entre les projets est la notion d’interdépendance (ex: le projet A utilise un résultat du projet B). Dans ce cas, le programme permet de renforcer le contrôle par une meilleure coordination entre les projets.

Mais un programme permet aussi de créer de nouveaux liens entre les projets afin de générer des bénéfices supplémentaires. Un programme permet de créer de nouvelles opportunités.

Par exemple, en réunissant plusieurs projets au sein d’un programme, on peut générer des offres combinées à plus grande valeur ajoutée. Sans programme, l’offre combinée risque de ressembler à un patchwork sans homogénéité.

De plus, la bonne coordination de plusieurs projets peut générer une valeur supplémentaire, par exemple en créant un effet d’annonce grâce à la sortie simultanée de plusieurs produits.

Enfin, le programme est aussi une source d’économies (par ex: passage d’appels d’offres plus importants, développements de composants réutilisables sur plusieurs projets, mutualisation des coûts publicitaires ou de communication etc.).

Le portefeuille et le programme ont des vocations très différentes. Le portefeuille est un outil de pilotage managérial. De son côté, le programme apporte une valeur business supplémentaire en plus d’être un outil de pilotage.

Quelles sont les techniques spécifiques de la gestion de programme ?

Il n’y en a pas vraiment car la gestion d’un programme empreinte tour à tour les techniques de la gestion de portefeuille de projets (alignement stratégique, sélection des projets, optimisation des ressources etc.) et toutes celles de la gestion de projets (risques, coûts, délais, qualités, communication etc.).

Les processus spécifiques à la gestion de programme sont:

  • ceux qui concernent l’initialisation du programme et la mise en place de la structure de management
  • ceux liés à la gestion des gains stratégiques (Benefits Management)

La gestion des gains stratégiques est sans doute l’élément le plus spécifique car c’est la raison d’être du programme.

Le programme se situe à cheval entre le portefeuille de projets et le gros projet. C’est pourquoi la frontière est souvent floue. Nous espérons que cet article vous aura apporté un nouvel éclairage. N’hésitez pas à nous laisser vos commentaires.

PS: Cet article a été écrit suite à la participation à la formation «Best Pratices in Program Management» de PMGS.

Les outils de gestion de projet mal aimés

À 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:

  1. 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.
  2. 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.
  3. «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.»
  4. «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, TimePerformance 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