Académique Documents
Professionnel Documents
Culture Documents
BIM Boite À Outils
BIM Boite À Outils
Daily meeting
Retrospective / Amélioration continue
Travail par pair (ou en binôme)
Itérations
Récit utilisateur
Démos régulières du projet
Conception pilotée par les tests
....
Vous pouvez contribuer à ces fiches pratiques pour mettre en place même de manière
épisodique ou expérimentale certaines de ces pratiques agiles.
Le standup ou daily meeting
Faire le point sur le projet avec tous les intervenants idéalement tous les jours pendant une
durée de 15 minutes environ. Cela permet que chacun soit au courant de l'état
d'avancement et de lever très rapidement de possible blocages.
Pour approfondir
https://open.spotify.com/show/75fEAJA
Agile BIM Ss5baQJQrZBQWJC?
si=NkIKd9jUQ06BhnoEwkDoug
Read it in English
Réduire la complexité d'un projet et terminer des parties au lieu de tout avancer de
front
Obliger les parties prenantes à faire des choix prioriser ce qui est le plus important en
premier
Montrer le plus vite possible des choses (maquettes, esquisse, calcul....) pour faire
réagir et recueillir des retours
Structurer le rythme de travail que ça soit avec une méthodologie de travail en continu
(kanban) ou par période de temps ou sprint (scrum)
Néanmoins les phases sont une étape trop grande (2-3 mois en général), et il faut
rechercher à d'avantage découper ce qui est dans les phases ou même pourquoi remettre
en question certains découpages de phases traditionnelle.
Vous n'avez pas besoin de découper tous le projet de A à Z en avance bien sûr. Mais il est
tout de même important d'avoir une vision globale des différentes étapes qui doivent être
franchis pour concevoir un bâtiment ou un espace public. Une fois la vision globale connue,
vous pouvez identifier ce qui pourrait être votre premier objectif.
Un cycle agile ou itération courte est une période de travail de 1, 2 ou 3 semaines qui
correspond à une étape de conception d'un projet
L'itération doit être définie à l'avance si possible pour être sûr d'avoir pris le temps de
prioriser les tâches et qu’au bout de la période il sera possible de faire une démo
Préférez une itération modeste mais qui se termine comme prévu, à une itération trop
ambitieuse mais ou la moitié des points ne seront à la fin par traité. En effet choisir
pour ne garder que le plus important est au cœur des approches agiles.
Une fois l'itération terminée, il est important d'en tirer des conclusions en faisant une
demo avec les parties prenantes (maître d'ouvrage, équipe projet...) et si possible une
retrospective en interne pour bien analyser comment s'est passer l'itération. Dans un
but de progresser et d'apprendre, c'est l'amélioration continue.
Pour approfondir
https://open.spotify.com/episode/4Z7C1
Utiliser les cycles courts en architecture a0WUIIfNTHuDZq5dA
Priorisation / Storyboard
En architecture il est rare d'avoir le retour direct de l'utilisateur final. Par exemple dans le cas
d'un logement, des personnes qui vont habiter ce logement.
Les démarches d'informer mais aussi de faire participer les utilisateurs finaux sont plus
répondues en urbanisme notamment, lors de la conception d'un quartier entier. Les
"utilisateurs" qui sont donc les habitants du quartier sont d'ailleurs à plus d'un titre les
experts de leur quartier. Ils en connaissent les problèmes, les qualités. Il faut alors trouver
un point de rencontre entre le projet proposé par l'équipe de conception et les attentes des
habitants.
Certaines agences se sont fait la spécialité de travailler de manière collaborative avec les
habitants. On peut citer par exemple l'atelier d'architecture autogérée qui présentent sur
son site plusieurs projets appliquant la démarche collaborative.
Autre Exemple de démarche collaborative pour la conception d'un quartier : La ZAC Clichy
Batignolles
https://archive-clichy-
L'Atelier Batignolles batignolles.parisetmetropole-
amenagement.fr/latelier-batignolles.html
Atelier Clichy Batignolles / Conception participative
Conception par pair / Un travail à deux pour apprendre et résoudre des problèmes
Comment le faire
S'assurer que tout le monde est au courant et d'accord (les personnes qui travaillent en
pair mais aussi la hiérarchie)
Définir l'objectif et la délimitation du travail à faire ainsi à deux
L'une des personne propose de mener la session et donc commence à travailler sur le
logiciel BIM par exemple. L'autre personne sert un peu de co-pilote et questionne si
besoin ses choix. Le travail devient ainsi une discussion.
Au bout d'un certain temps, 1 ou 2 heures, 1 demi-journée, on inverse les rôles
Pourquoi ça marche ?
Les deux personnes ont souvent une connaissance et une expérience qui se complètent
Travailler à deux génère naturellement de l'émulation
Le fait d'avoir un rôle en recul dans le cas du co-pilote permet d'avoir une vision qu'on a
rarement quand on travaille tout seul et qui permet au final de gagner du temps.
On est donc tenté de calculer le temps de tout ce que l'on fait et de demander à l'équipe de
le faire. Cette stratégie n'est en soi pas mauvaise. Mais elle peut être perçue comme un
poids pour l'équipe, notamment pour une majorité d'entre nous qui ne voient pas d'un très
bon œil, de se surcharger à faire ces tâches, perçues qu'on le veuille ou nous comme du
"reporting".
Mais surtout car ces métriques ne sont finalement pas très actionnables. Une fois qu'on a
passé 10 h à faire une tâche alors qu'on pensait en passer 5 h seulement. Qu'est-ce qu'on
peut faire ? Demander un supplément au client ? C'est rarement possible malheureusement.
Alors quoi faire ? Je vous propose de regarder le Scrum, l'un des approches Agile les plus
populaires, et ce que cette approche propose pour visualiser l'avancement par rapport à des
objectifs.