⚖️ Estimer un projet de bâtiment en s'amusant grâce à l'agile

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.

Il n'est pas toujours fréquent dans la construction d'estimer précisément le temps passé à concevoir en tant qu'architecte, ingénieur ou BIM manager.

Cela est sans doute dû à la manière de facturer un projet en tant que maître d'œuvre, qui est souvent forfaitaire et donc ne demande pas de prouver le temps passé à son client.

Néanmoins, il est important d'estimer le temps ou du moins la complexité d'une tâche. Ceci afin de pouvoir travailler par itérations agiles et d'éviter l'effet tunnel.

C'est-à-dire le fait d'être bloqué sur une tâche sans que le client ou les autres intervenants ne voient de résultats et ne puissent infléchir le projet dans une direction ou une autre.

Pourquoi estimer ?

Mais d'abord, il faut se demander pourquoi il est important d'avoir un chiffre qui nous donne une idée de la complexité ou du temps passé à travailler sur un sujet.

Car hors du contexte de l'agile, on pourrait penser qu'estimer c'est finalement utiliser une méthode un peu "old school". Que c'est aussi nous contraindre vis-à-vis de nos supérieurs ou clients. En effet, si on annonce un temps estimé, nos chefs de projets vont s'en souvenir. Et si les choses ne se passent pas comme prévu, ce qui dans le bâtiment est monnaie courante, il faut l'avouer, cela risque de jouer contre nous !

D'abord, si tu ne prends pas le temps d'estimer la complexité d'un sujet, tu peux te retrouver avec une tâche trop longue et rentrer dans "un tunnel". D'où tu ne pourras sortir que bien après l'itération en cours. Prendre le temps d'estimer, c'est aussi prendre le temps de définir les priorités. C'est prendre le temps de comprendre ce qu'il y a à faire. Et c'est aussi chercher à réduire l'inconnu par le découpage, la comparaison et la discussion avec l'équipe.

Les points, plutôt que les heures

Nous allons voir que les approches agiles proposent plusieurs manières d'estimer, qui ont toutes comme point commun de ne pas utiliser un compte précis (heure, jours-homme) mais des points ou d'autres unités de mesures. Des points arbitraires donc, soit en utilisant une suite mathématique (suite de Fibonacci), soit une échelle de taille utilisée dans l'industrie textile (XS, S, M) ou ce que tu préféres !

Ainsi, rien qui ne permette à un manager en théorie de prendre ce chiffre comme une assurance, que le travail doit être rendu dans X heures. En effet, le problème des estimations est bien là, introduire une rigidité que par définition, on ne veut pas en Agile. Mais inversement, ne pas estimer, c'est juste avancer dans l'inconnu et faire des choix en catastrophe au dernier moment, pour prioriser ce qui pourra être rendu et non ce qui est le plus important !

Voilà pourquoi les méthodes d'estimation Agile utilisent souvent des systèmes de points pour ne pas tomber dans le piège d'une précision, qui n'existe pas en réalité.

Les méthodes d'estimations Agile

Il existe de nombreuses méthodes d'estimation dans les approches Agile, mais je vais t'introduire aux principales. J'approfondirai ce point dans ma prochaine formation à l'agile BIM en préparation !

Le pocker planning, ou comment transformer en jeu l'estimation

Le pocker planning est la plus connue des méthodes d'estimation, car c'est celle qui est communément utilisée dans le Scrum. Le pocker planning permet de rendre la réunion d'estimation amusante en la transformant en un jeu.

Ainsi, tu peux proposer à ton équipe de faire un jeu de pocker, avec des cartes un peu particulières. Ce jeu est composé de cartes avec des chiffres, qui correspondent à la Suite de Fibonacci, une suite de nombre croissants et séparés clairement l'un de l'autre tel que 1, 3, 5, 8, 13..... De même que des cartes spéciales, quand on ne sait pas estimer.

Le principe est qu'après une description de la tâche (ou user story), les membres de l'équipe donnent une estimation en points sans se concerter et donc sans s'influencer. Si le score diffère, une discussion s'ensuit pour clarifier pourquoi une personne a votée moins ou plus. Et l'équipe choisie l'une des versions ou finalement vote une nouvelle fois.

Il s'agit donc, au-delà de la simple estimation des tâches, d'un moyen de clarifier la compréhension de chacun et de définir mieux ce qu'il y a à faire.

Le T-shirt Sizing, l'estimation "à la grosse"

Quand on veut avoir une vision de moyen terme de la charge de travail nécessaire pour accomplir une partie du projet. Il est parfois impossible de lister toutes les tâches dans le détail. En effet, par définition, certaines tâches sont trop floues et on ne sait pas précisément comment les découper. Néanmoins, soit on ne fait rien et on reste dans l'inconnu. Ce qui est bien sûr possible !

Soit, on adopte une approche plus grossière que la précédente, en choisissant une unité de mesure à l'image de notre incertitude, le t-shirt, et plus exactement sa taille.

L'idée de cette estimation est de mesurer le niveau d'incertitude des membres de l'équipe et de constater si elle converge ou pas.

Par exemple, si tous les membres sont dans le vague à propos de ce qu'il y a à faire sur une tâche, ils peuvent choisir de l'estimer en XL. Que la tâche soit complexe et longue, ou simplement mal définie et donc trop floue revient finalement au même.

Toutes les tâches avec des tailles de T-shirt type XS, S, M sont conservées. Celles qui ont des tailles élevées sont destinées à être redécoupée pour arriver à des tâches plus simples, et en conséquence que l'on peut terminer plus rapidement.

L'Extreme cotation, les grands moyens pour vaincre l'inconnu

Peut-être le nom de cette méthode d'estimation Agile est un peu exagéré ! Mais il est en rapport avec la méthode Agile dite "Extreme programming", d'où nous vient également la notion de développement par les tests.

Ce qui est extrême ici n'est pas un quelconque danger comme dans les sports extrêmes, mais plutôt le temps alloué à la décision. Chaque tâche ou user story soumis à estimation n'a droit qu'à cinq minutes, divisées entre une présentation très succincte, 1 ou 2 questions maximum de l'assistance et finalement un vote de l'équipe de la même manière que dans le pocker planning.

Donc quelle est la finalité de cette pratique ? Elle est plutôt adaptée pour avoir une première estimation, forcer la difficulté de certaines personnes à s'exprimer même avec très peu d'infos, pour recueillir l'intuition de l'équipe. Elle oblige la personne qui explique à être très synthétique sans se perdre dans le détail.

Comme dans le T-shirt sizing, cette pratique est plutôt adaptée à une estimation grossière en amont pour avoir un ordre de complexité et faire des choix entre plusieurs solutions en fonctions de leur coût de developpement.

No estimates, et si on n'estimait pas finalement ?

Et oui, ça peut paraître paradoxal, après avoir détaillé les avantages de l'estimation en mode Agile, plutôt que de ne rien estimer et commencer directement à travailler. De terminer en quelque sorte au point de départ !

Pourtant un mouvement se développe, porté par des coach agile utilisant Scrum, qui pensent que finalement, le travail d'estimation est problématique. Car il introduit des attentes chez le client ou la personne qui a demandé ce travail. Et que très souvent les estimations restent trop approximatives c'est à dire qu'elle ne valent pas le temps dépensé à les produire.

Néanmoins, une chose n'est pas remise en cause dans cette approche et c'est pour cela qu'il faut la distinguer de l'absence totale d'estimation. Il s'agit de l'organisation du travail en sprint ou itération. Le raisonnement est le suivant : le but des estimations en Scrum est de pouvoir choisir des sujets de travail que l'on puisse terminer en un sprint. Et pour cela éliminer les sujets trop importants en les recoupant. Dans le no-estimate, une seule question est donc posée. Est-ce que ce sujet rentre dans un sprint ? Pas de subtilité de savoir si c'est petit, moyen ou gros. Si l'ensemble de l'équipe répond oui, alors on embarque ce sujet.

Finalement, ça peut aussi être un moyen de commencer avec les estimations de manière très simple. Effectivement, l'un des points fondamentale de l'estimation Agile est d'apprendre à découper les tâches pour les terminer régulièrement de manière à recevoir des retours du client et des autres parties prenantes du projet.

Cela nous amène à l'avant-dernier chapitre de cette formation à l'agile pour les professionnels de l'architecture, pourquoi c'est important de montrer le projet régulièrement.

Mais d'ici là, je t'ai préparé une petite liste de tâche comme d'habitude pour passer à l'action avec l'agile BIM et les estimations Agile !

📅 En pratique : Organise une session de pocker planning

Je te conseille de commencer par cette approche qui est la plus courante pour te donner une idée de ce dont il s'agit.

✅ Prépare une liste de tâche ou user stories, que tu penses prioritaires pour le prochain sprint, limite leur nombre pour une première session

✅ Vérifie que les tâches sont suffisamment détaillées ou au moins que tu puisses les expliquer clairement

✅ Achète toi un jeu de carte pocker planning, ou inscris toi à l'un des nombreux services en ligne qui permettent de faire des sessions même à distance

✅ Planifie une réunion d'une heure pour expliquer le principe du pocker planning et passer à l'action, invite bien toute l'équipe pour avoir les différents points de vues

✅ Une fois l'estimation faite, reporte le résultat sur ton outil de gestion de tâche agile préféré, par exemple Bricks spécialisé pour l'architecture ou JIRA, un classique de l'agile un peu complexe néamoins

En conclusion

Et voilà, ce n'est pas très compliqué et en plus, je pense que l'équipe va aimer.  Car c'est aussi un moment de détente et de convivialité, qui est l'occasion se parler du projet aulieu de "dérouler" sans réfléchir.

Je te dis donc à la semaine prochaine et où nous allons parler de la manière la plus efficace de montrer le projet en cours lors des réunions régulières avec le client. Pourquoi c'est important de le faire, et pourquoi le client doit être inclus dans l'équipe de conception pour apporter ses retours.

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 !