Retour à l'index Livret blanc : les timeboxes Jeudi, 2 Août 2001, par Ian Stokes Sujet : Livrets Blancs Résumé : Un timebox est une période courte de temps avec une date butoir pour livrer des produits visibles et vérifiables. Corps de l'article : Les livrables sont destinés à l'équipe projet (y compris l'utilisateur ambassadeur) ou bien aux utilisateurs finaux. Un produit livré peut être partiel ou complet, mais devra satisfaire les critères d'acceptation définis. Les livrables seront composés typiquement de : Besoins impératifs - 60%, Besoins souhaitables - 20% Besoins facultatifs - 20% L'effort associé aux besoins impératifs ne doit jamais dépasser 75%. Les premiers timeboxes doivent se focaliser sur la fonctionnalité, l'architecture , et les modules qui sont difficiles à estimer. Les contenus des timeboxes doivent être pilotés avec une prise en compte des risques. Deux types de risques : Architecture - des retards peuvent obliger des reprises importantes d'éléments existants. Estimation - des incertitudes quant au temps nécessaire pour réussir certains modules. Afin de déterminer la fonctionnalité d'un timebox, il faut définir des ensembles fonctionnels qui sont logiques pour les utilisateurs. Les regroupements les plus évidents sont par cas d'utilisation, le plus petit que possible. Les besoins priorisés pilotent la mise à disposition des composants : Nom du composant => Liste des fonctions qui dépendent du composant. Les composants de l'architecture doivent être priorisés tout comme les éléments fonctionnels. La plupart des méthodes demande un diagramme à barres, mais ce n'est pas le meilleur outil pour piloter des timeboxes. Un Gantt ne peut pas indiquer l'importance relative des éléments au sein du timeboxe. Cette table présente un exemple de planification des priorités : Timebox Must Should Could Fourchette de temps A dans le Gantt Liste des fonctions et composants impératifs Liste des fonctions et composants souhaitables Liste des fonctions et composants facultatifs Il faut rester vigilants sur plusieurs aspects : des dépendances des fonctions impératives sur d'autres éléments non-encore livrés ; la vitesse d'exécution par rapport aux prévisions ; l'évolution des priorités ; les contraintes d'architecture. Tout timebox comprend cinq phases principales : Réunion de lancement - prioriser localement par rapport aux timebox, faisabilité des besoins impératifs dans le timebox, les critères d'acceptation, les dates, les interfaces. Etude initiale - créer une base solide pour le développement avec la participation de l'équipe, préciser les méthodes de tests et d'acceptation. Développement - planifier, noter les évolutions, mettre à jour la configuration. Consolidation - vérifier et tester, préparer les livrables, définir les actions suivantes. Livraison - conclure et valider. Le chef de projet tient un registre d'incidents (vert, orange, rouge). Toutes les décisions sont suivies et notées, et surtout celles qui relèvent des priorités. En cas de retard sur les livrables d'un timebox, l'action préférée consiste à enlever certaines des fonctions. Il ne suffit pas de glisser les fonctions dans le prochain timebox. Une replanification est essentielle. En cas d'avance, il existe trois options : (i) s'entendre avec l'utilisateur ambassadeur pour commencer le prochain timebox ; (ii) importer un travail supplémentaire sans changer le contenu formel ; (iii) s'offrir une pause pour des raisons de récupération des énergies. Tous les jours à la même heure et au même endroit est prévu une mise au point d'une quinzaine de minutes, et d'une trentaine de minutes maximum, sans exception. La fin de la réunion sera sujet à la guillotine ! * Le sujet de la réunion est strictement limité à : 'Quel travail est fait depuis la dernière mise au point ?' 'Quels ont été les points de blocage ?' 'Que faites-vous avant la prochaine mise au point ?' Le résultat pourrait inclure : le transfert d'une tâche à quelqu'un d'autre, l'identification d'une nouvelle tâche, une décision pour réunir quelques personnes. L'organisateur de la réunion doit s'assurer que le travail avance, que les risques diminuent, et que tout incident est géré. * Le mot 'guillotine' ne veut pas dire que les gens vont perdre leurs têtes à la fin de la réunion, mais que la réunion se termine strictement dans les délais impartis. 0KB (0 bytes) Publiez vos commentaires sur cet article