Un concept très simple

Le Timeboxing consiste en la 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.

Voici 2 liens pour télécharger la version 2010 du Scrum Guide (équivalent d'un PMBoK) écrit par Ken Schwaber et Jeff Sutherland.

Scrum Guide février 2010 en français

Scrum Guide février 2010 en anglais

Définitions

Définitions du PMI librement traduites

Version corrective:

• problème lorsqu'on fait passer une tâche d'un projet vers un autre
• problème d'affichage lors de l'édition de la feuille de route dans IE 7
• mauvais rafraîchissement de la liste de tâches sur certaines actions avec les navigateurs basés sur le Webkit (Safari, Google Chrome etc.)
  

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, 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