L'organisation

Pour le management du chantier, on s'inspire des méthodes agiles et en particulier du cadre SCRUM. Les méthodes agiles nous offre un cadre et des méthodes de gestion de projet partant du principe qu'une planification détaillée de bout en bout n'est pas viable et qu'il vaut mieux se préparer à être flexible au changement. La méthode SCRUM en particulier découpe le temps en une succession de sprints correspondants à une période de 3 semaines dans notre cas, avec un certain nombre de rendez-vous que nous allons détailler plus loin.

Tout d'abord, si la planification globale détaillée n'est pas viable, il nous faut tout de même identifier ces activités et les ordonner grossièrement dans un "macro-plan". Il s'agit dans le cadre SCRUM de réaliser le plan de release, c'est à dire de définir de gros jalons qui seront dans notre cas "Gros œuvre, second œuvre, équipement (avant déménagement), puis finitions (après déménagement). Pour chacune de ces releases, on répartit les activités à mener dans ce qu'on appelle des story epics.

Voici notre plan de release :

Nous sommes 2 dans l'équipe donc la répartition des rôles est triviale, nous serons respectivement Product Owner et Scrum master, le premier est principalement en charge de l'affinage des activités, le second principalement en charge du suivi des activités de suivi de chantier (y compris le suivi des tâches affectés aux artisans) et de l'identification et la résolution des obstacles.

Voici nos points de rendez-vous:

- Daily meeting (Tous les soirs vers 19h, 5-10 min): debout devant le dashboard (Voir plus loin) pour mettre à jour l'avancement des activités et éventuellement des obstacles et identifier les activités du lendemain.

- Sprint review (occasionnellement le Vendredi après-midi ts les 3 semaines): Dans le cadre SCRUM, il s'agit ici de montrer ce qui a été réalisé dans le sprint afin de provoquer du feedback. Sachant que nous sommes à la fois maîtres d'œuvre et maîtres d'ouvrage, le feedback n'attendra donc pas ce jalon mais ce sera pour nous l'opportunité de partager avec notre conseiller AMO (Assistant à maîtrise d'ouvrage) afin de provoquer un feedback extérieur de type expertise technique.

- Rétrospective (Vendredi soir toutes les 3 semaines): La rétrospective sera l'occasion de prendre du recul sur notre projet et d'identifier ce qui fonctionne bien, ce qu'il faut continuer à faire, ce qu'il faut mieux faire, moins faire ou arrêter de faire, mais aussi le moral de l'équipe (du couple en l'occurrence!!!) et ce n'est pas à négliger, une bonne communication du début à la fin du projet est/sera un critère de réussite !!! 

- Planification (Samedi matin en début de sprint): En début de sprint, on identifie les stories (activitées) prêtes et on détaille les tâches sur le dashboard pour les 3 semaines à venir.

- Affinage (Samedi matin sauf en cas de planification): 2 rendez-vous intermédiaires dont l'objectif est d'identifier et d'affiner (ce qui signifie découper en activités réalisables dans un sprint de 3 semaines) les story (activités) du prochain sprint afin de les prioriser et des les rendre "prêtes". 

Notre définition de prêt est (pour l'instant) la suivante:

  • Conforme au permis de construire / plans
  • Zone d'intervention localisé sur plan
  • Les outils sont identifiés
  • Les matériaux sont identifiés
  • L'intervenant est identifié
  • La tâche a été discuté & validé par le product owner et le scrum master

Notre définition de fini est (pour l'instant) la suivante:

  • contrôlé/mesuré
  • Conforme au Permis de construire/plans
  • Vérifié par le product owner et le scrum master

Ces définitions de prêt et de fini évolueront certainement au cours du chantier puisque nous sommes pour le moment dans des activités de type ingénierie et des critères apparaîtront/évolueront en phase d'exécution.

Voici notre dashboard de sprint rempli lors de la planification et devant lequel nous faisons quotidiennement notre daily meeting.



En complément , un second tableau contenant les backlog des story de la release en cours d'affinage sous responsabilité du Product Owner. Ce tableau est utilisé lors des points d'affinage pour la préparation/identification des activités du prochain sprint.