🧩 Bien découper les tâches d'un projet de construction
Cet article fait partie de la formation gratuite Agile pour l'architecture, n'hésite pas à t'y inscrire pour t'aider à mettre en place l'agile sur tes projets.
Comment faire ce découpage pratiquement pour qu'à chaque itération :
👉 de la valeur soit délivrée à ton client ou aux utilisateurs de ton projet
👉 et qu'idéalement les tâches soient "terminées" à chaque itération
Dans la conception d'un bâtiment ou d'un projet d'urbanisme, certaines tâches peuvent sembler très longues et presque sans fin. Enfin jusqu'au chantier en tout cas où une décision doit être finalement prise. Mais souvent trop tard et dans l'urgence.
Il est pourtant tout à fait possible de faire autrement et de découper les tâches en tâches plus petites, qui peuvent être terminées et soumises au client pour validation au "fil de l'eau" et non à la fin d'un long processus comme une phase.
L'avantage de cette approche est multiple :
👉 Les validations fréquentes de ton client sont autant de confirmations qui sécurisent ton travail
👉 "Terminer" et rendre visible même de manière partielle une tâche permet à ton client de faire des remarques qui sont autant d'enrichissements du projet
👉 Chaque étape ou itération requiert un travail de priorisation. Du coup, si tu le fais sérieusement, il y a moins de risque que tu perdes du temps à travailler sur des tâches qui ne seront pas utiles.
Oui, mais comment découper les tâches efficacement : La méthode INVEST
Dans le scrum, il y a une méthode, qui est très utilisée pour vérifier que le découpage des tâches est le bon. Il s'agit de la méthode INVEST.
INVEsT est en fait un acronyme que je vais t'expliquer maintenant.
I pour independent (Indépendante)
Pour que le principe des itérations marche, il faut que les tâches (récit utilisateurs ou users stories dans le Scrum) soient indépendantes d'autres tâches. En effet, si ce n'est pas le cas, elles pourraient ne pas être terminées à la fin de l'itération. Parfois, il y a tout de même des dépendances inévitables entre tâches, mais il est important de les connaître en avance.
N comme Negotiable (Négociable)
Dans le Scrum et les approches agiles, il est important d'avoir un dialogue constructif entre le client et l'équipe de projet. C'est moins une relation client - fournisseur, mais plus une relation de collaboration qu'il faut rechercher. Parfois le client qui ne se rend pas compte de toutes les implications de ses choix, peut complexifier inutilement le travail de la maitrise d'œuvre. S'il y a une manière plus simple et aussi efficace de faire le travail, il devrait toujours être possible de "négocier" et de faire une tâche différemment ou même ne pas la faire si elle n'est pas inutile finalement.
V comme Valuable (qui a de la valeur)
Dans le Scrum, il est important de mettre l'accent sur la valeur apportée itération après itération à son client. Il est évident que certaines tâches n'ont pas de valeur directe pour le client comme "nettoyer sa maquette Revit". Mais qu'il est tout de même crucial de le faire régulièrement. Cependant, il est préférable quand c'est possible de mélanger les tâches, qui ont une valeur client directe, avec celles qui en ont moins. Par exemple, "nettoyer la maquette BIM à l'occasion du nouveau plan d'étage" permet d'associer une tâche technique à une tâche à forte valeur ajoutée pour le client.
De plus, pour toutes les tâches qui ont une valeur client, il est possible de spécifier à quel point. Par exemple, définir les façades du bâtiment, peut avoir beaucoup de valeur, car cela facilite le processus de vente. Pratiquement, dans votre plateforme de gestion de tâches agile, vous pouvez créer un champ de type "business value" ou "valeur client", dans lequel vous estimez la valeur client pour l'avoir en tête et pouvoir prioriser les tâches en fonction.
Es comme Estimable (que l'on peut estimer)
L'un des objectifs du Scrum est d'améliorer la prédictibilité du travail de l'équipe. Si on n'estime pas le temps passé ou la difficulté, on ne peut pas être sûr que les tâches rentreront dans la durée de l'itération. Dans le Scrum, on utilise en général un système de points (1-3-5-8-13-21) plutôt que des heures estimées. Cela permet en effet de ne pas avoir à être précis et de ne pas risquer que le client prenne ce décompte au pied de la lettre. Encore moins qu'il se serve de cette info pour vous payer !
Non, le but n'est pas d'être redevable d'une estimation, mais plutôt d'évaluer si la tâche est faisable dans cette itération. Et permettre lors de la réunion pour estimer les tâches de mieux comprendre ce qu'il y a à faire et de poser toutes les questions qui permettront de mieux définir le travail à réaliser.
La somme des estimations de chaque tâche donne un chiffre, qui est comparé avec les performances des itérations précédentes, pour savoir si c'est réaliste de terminer cette tâche dans l'itération.
T comme Testable (que l'on peut tester)
Ce critère est très important en développement logiciel, car il s'agit de tester que le code livré fonctionne. Soit manuellement en reproduisant un scénario donné, soit automatiquement avec des tests automatiques. Dans le domaine de l'architecture et avec le BIM, le concept de test automatisé a commencé à émerger et c'est une bonne chose !
L'idée est qu'un logiciel va exécuter une série de tests automatiques pour vérifier des règles de la construction, de cohérence de la maquette… Donc une tâche qui est testable, est une tâche qui produit un résultat que l'on peut évaluer d'une manière ou d'une autre.
Si on prend l'exemple d'un pont. Supposons que le but de l'itération est de définir le profil d'un pont, et que le pont doit remplir un certain nombre de contraintes : hauteurs sous tablier, résistance à un trafic précis… Il doit être possible de tester soit manuellement, soit automatiquement que la nouvelle itération permet à l'ouvrage de remplir les normes préalablement définies.
📅 En pratique : Organise tes prochaines itérations avec la méthode INVEST
Bon, la méthode INVEST, c'est intéressant, mais maintenant il faut la mettre en pratique. Si tu travailles déjà avec des itérations, peut-être planifies-tu ces itérations lors de réunions ? Dans le Scrum, ces réunions sont appelées "Sprint planning". Si tu n'organises pas encore ce type de réunion, je t'encourage vivement à commencer à le faire.
Pour prioriser les tâches à inclure dans le sprint, tu as désormais 2 outils :
👉 la gestion des priorités avec la matrice d'Eisenhower (que l'on a vu au mail précédent)
👉 l'art du découpage avec la méthode INVEST
Donc à toi de les inclure et pour cela voila ce que tu peux faire :
✅ Sur chaque tâche que tu veux inclure dans la prochaine itération
✅ Pose la question à ton équipe si cette tâche est conforme aux principes de INVEST
✅ Essaie de résoudre les problèmes qui peuvent se poser dans le cas où la tâche n'y répond pas
Pour t'aider un peu dans la résolution des problèmes, voici des réponses possibles :
❌ Tâche pas indépendante
✅ Découpe la pour qu'elle le soit
✅ Ou gère les dépendances en commençant par la tâche qui va débloquer l'autre
❌ Tâche pas estimable
✅ Précise le travail et sa description pour qu'elle le devienne
✅ Ou découpe-la, une tâche trop grosse est difficilement estimable
❌ Tâche sans valeur client
✅ Combine des tâches sans valeurs directes avec des tâches avec valeur client
✅ Assure toi que suffisamment de tâches avec valeur utilisateur forte seront choisies dans l'itération
Enfin, n'oublie pas que la somme des estimations des tâches doit entrer dans une itération. À la fin de cette itération, la plupart des tâches qui ont prévues d'être finie doivent l'être. Si ce n'est pas le cas, il faut penser à améliorer le découpage pour la prochaine itération.
Enfin si ce contenu t'intéresse, sache qu'il fait partie d'une série pour apprendre l'agile pour l'architecture et la construction. Abonne toi à ma formation par email. C'est gratuit !