Traduction

1. Timeboxing
Origine
L’une des choses qui « ennuie » les clients, c’est que les projets semblent toujours prendre plus de temps que ce qu’ils avaient prévu au départ ; ce qui génère
généralement plus de coûts.
Lorsque le RAD (Rapid Application Development) fut introduit au début des années 90, le développement devint beaucoup plus rapide mais les solutions
produites n’étaient presque jamais maintenables.
Des personnes intéressées, provenant de nombreuses entreprises et des milieux de l’industrie, se réunirent pour essayer de concevoir des processus qui
permettraient de résoudre ces problèmes ; le timeboxing fut l’une des techniques conçues à ce moment-là. Ce groupe finit par devenir le Consortium DSDM
(Dynamic Systems Development Method), conçu et publia le premier framework RAD et fit partie des membres fondateurs de l’Agile Alliance.
La philosophie du timeboxing a ensuite été adoptée par tous les frameworks de développement Agile, sous une forme ou une autre.
Historique
Beaucoup de professionnels, comme les journalistes, ont à produire un travail à un niveau acceptable de qualité dans un délai donné. Ils le font en rassemblant
toutes les informations possibles dans le produit final tout en priorisant l’information par rapport aux faits et au niveau de détail attendu ; si une personne
souhaite avoir plus de détails, cela peut alors être produit une fois l’échéance initiale passée.
Le principe du développement agile peut être résumé par le schéma suivant :
Ce schéma représente le soi-disant « Triangle des Forces d’un Projet », liant ainsi les variables fondamentales de tout projet que sont les Exigences/Qualité, le
Délai et le nombre de Ressources nécessaires pour terminer le projet ; la prise en compte des Ressources et du Délai permet d’en déduire le Coût, donc le Coût
n’est pas considéré comme fondamental.
Dans les projets traditionnels, une grande partie du temps est consacré à documenter dans le détail toutes les exigences et à produire un planning cohérent pour
satisfaire ces exigences. Ce planning constitue la base du « contrat » établi entre le fournisseur et le client ; le client attend donc que la livraison respecte le
délai et le coût.
Pourtant, au fur et à mesure du développement de la solution, des problèmes non vus pendant la phase de planification apparaissent et compromettent la date
de fin du projet. L’un des moyens possibles pour rétablir la situation est d’augmenter le nombre de ressources (donc le coût) mais cela reste une stratégie
limitée ; généralement, on en arrive à un point où le seul moyen de respecter le niveau de qualité attendu sur toutes les exigences est de prolonger la durée du
projet. Par conséquent, pur produire un ensemble « Fixe » d’exigences, les Ressources et le Délai deviennent « Variables ».
Au sein des projets Agile, le délai est généralement fixé par un impératif métier, par exemple une contrainte réglementaire ou un avantage concurrentiel, et le
nombre de ressources de « l’équipe de base » du projet est fixé à un petit nombre, entre 5 et 10. Par conséquent, la seule chose qui pourra varier est ce qui sera
produit par ces personnes durant la période de temps allouée ; la liste des exigences prises en compte est gérée par la technique de priorisation MoSCoW (voir
le document « MoSCoW Prioritisation »).
C’est ainsi que cette période de temps fixe donna naissance à l’expression Timeboxing.
Ressources
DSDM Manual - Timeboxing Section
Timeboxing is an Effective Getting Things Done Strategy
Description
Le Timeboxing est une technique qui peut être appliquée aux différents niveaux de période de temps d’un projet :
Nous pouvons voir que la notion « LA Timebox » n’existe pas et qu’à chaque fois que l’on parle d’une période de temps particulière, le nom exact de la
timebox doit être employée sinon gare aux risques de confusion et d’incompréhension.

2. Le schéma ci-dessus montre les niveaux pour lesquels la technique de timeboxing pourrait être employée ; cela peut ne pas se révéler nécessaire voire même
pertinent dans certains cas de timeboxer au niveau des itérations du produit (voir le document « Iterative and Incremental Development ») et il peut être
avantageux de timeboxer pour certaines activités/personnes, dans certains cas à un niveau inférieur de l’itération produit.
Chaque timebox, à quelque niveau que ce soit, doit avoir les caractéristiques suivantes :
• Une liste de livrables attendus
• La liste des personnes à impliquer pour produire chacun des livrables
• Une estimation « honnête » du temps requis pour produire chacun des livrables (n’incluez pas la traditionnelle marge) et qui soit réalisée par les
personnes impliquées
• Une liste priorisée des livrables (voir le document « MoSCoW Prioritisation ») ; les livrables priorisés « Should Have » et « Could Have »
constituent la marge tolérée sur la timebox (voir le document « Agile Governance »)
• Un planning validé sur la façon dont les livrables seront produits.
Il est impératif que les estimations de chacun des livrables « rentrent » dans la timebox : si le total estimé excède la longueur de la timebox et que les tâches
parallélisées ne peuvent être terminées alors la liste des livrables requis doit être réduite.
Le pourcentage d’effort estimé pour les livrables priorisés « Must Have » rapporté aux « Should Have » et « Could Have » est extrêmement important (voir le
document « MoSCoW Prioritisation »). Il a été constaté que les équipes qui s’essayaient la première fois à la technique de timeboxing peuvent uniquement
accepter de consacrer une répartition maximale de 50% de l’effort estimé sur les livrables priorisés « Must Have » ; des équipes expérimentées, quant à elles,
peuvent aller jusqu’à 60 à 65% de l’effort consacré aux « Must Have » ; un effort plus conséquent imposerait un risque élevé d’échec de la timebox.
Processus de la Timebox
Chaque timebox nécessite de nommer un Responsable de la Timebox, c’est-à-dire une personne garantissant que les caractéristiques de la timebox sont bien
spécifiées et qui peut suivre son état d’avancement. Cela peut être le chef de projet, un chef d’équipe ou tout autre rôle approprié du projet.
Chaque timebox doit commencer par l’animation d’un atelier (voir le document « Facilitated Workshops »), qu’on appelle Atelier de Lancement, impliquant
tous les participants et les parties prenantes à la timebox pour valider les caractéristiques de la timebox.
Pendant la timebox, le Responsable de la Timebox suit son état d’avancement, habituellement sous forme de Daily Stand-Up Meetings, uniquement pour
s’assurer qu’au minimum les livrables « Must Have » sont en voie d’être terminés. S’il s’avère que les Must Haves sur lesquels on s’est engagé ne pourrons
pas être terminés alors le Responsable de la Timebox Stoppe la Timebox et anime un nouvel Atelier de Lancement pour renégocier et prioriser ; une fois
validée et planifiée, une nouvelle timebox débute. Ne soyez jamais tenté de prolonger une timebox pour terminer les Must Haves.
A la fin de la timebox, les participants et les parties prenantes doivent participer à un atelier de revue de « Clôture », non seulement pour examiner ce qui est
terminé mais aussi comment cela a été terminé (« Leçons Apprises » durant la timebox).
Il est fréquent de combiner l’Atelier de Clôture d’une timebox avec l’Atelier de Lancement de la timebox suivante.
Modification des Exigences
Durant une timebox, les exigences validées sur les livrables de la timebox peuvent donner lieu à modification, ajout ou suppression ; par exemple une nouvelle
réglementation peut nécessiter d’ajouter de nouvelles fonctionnalités au projet. Au niveau de l’itération produit, cela peut impacter une modification majeure
des interfaces du système et une éventuelle remise en cause des estimations initiales.
Il est de la responsabilité du Responsable de la Timebox d’évaluer l’impact des changements requis sur la bonne fin des Must Haves de la timebox. Il est
probable que les Must Haves initialement validés pour la timebox seront remis en cause et que le Responsable de la Timebox devra Stopper la Timebox et
animer un nouvel Atelier de Lancement pour cette timebox afin de renégocier le priorités et replanifier.
Si le changement consiste à supprimer certaines exigences ou certains livrables sans remettre en cause ce qui a déjà été produit alors il est possible de ne rien
faire ; toutefois, si la suppression d’une « fonctionnalité » a un effet collatéral sur d’autres « fonctionnalités » dépendantes alors l’effort supplémentaire estimé
pour découpler ces « fonctionnalités » devra être pris en compte dans le planning et une évaluation de l’impact réalisée comme indiquée dans le paragraphe
précédent.
Questions
Risques
Risque Réduction du risque
Les livrables priorisés Must Have dans la timebox représentent plus de 65%
de l’effort total estimé – risque élevé que les Must Haves ne soient pas
terminés, ce qui entraîne un échec de la timebox.
Renégocier les priorités pour obtenir un pourcentage d’effort sur les Must
Haves beaucoup plus acceptable.
Les estimations des livrables de la timebox n’ont pas été réalisées par les
personnes désignées pour faire le travail – risque élevé pour n’avoir le soutien
d’aucun des participants.
Aucune parade.
Prolongation de la longueur de la timebox pour terminer les livrables
priorisés Must Haves – conduit à un manque de confiance dans la technique
par les clients et les fournisseurs.
Stoppez toute timebox dès qu’il devient probable qu’un livrable priorisé Must
Have ne pourra pas être terminé dans la timebox.
Liens
Ce document doit être lu en parallèle des documents suivants :
• Agile Governance
• Iterative and Incremental Development
• MoSCoW Prioritisation
• Facilitated Workshops