Sprint final : PR bloquée, périmètre élargi et facteur bus de 1
Quatre étudiants de BUT2 ont 8 semaines (dont 5 déjà écoulées) pour livrer une application de gestion de tournois à un client interne. Bilan à la semaine 5 : 4 user stories livrées sur 14, aucune CI, tout le monde pousse directement sur main, un merge a coûté deux jours. Une pull request de 900 lignes est ouverte depuis six jours avec 40 commentaires, principalement sur des points de style (virgules, nommage) ; son auteur refuse de la découper. Un membre en alternance n'est disponible que le soir et n'a jamais écrit de test ; il détient seul le module d'authentification. Le client annonce en semaine 5 qu'il veut « en plus » la gestion des équipes et un export PDF, sans retirer de fonctionnalité. Aucun des quatre n'a relu le cahier des charges depuis la semaine 2.
1. Comment débloquer la pull request et prévenir ce type de blocage ? Décrivez les décisions concrètes : découpage, automatisation, règles de revue.
Read the worked answer
Séparer le style du fond, et l'automatiser. 40 commentaires sur des virgules ne constituent pas une revue. Adopter un formateur (Prettier, ESLint, Spotless ou black selon la stack) et un hook pre-commit, puis reformater la branche en un commit dédié. Les goûts personnels deviennent une configuration versionnée, et la revue se concentre sur la conception, les cas limites et les tests - ce qui a de la valeur.
Découper la PR. 900 lignes dépassent largement la capacité d'une revue sérieuse (ordre de grandeur admis : 200 à 400 lignes). Découper par fonctionnalité, avec des branches courtes et une feature flag si le code n'est pas complet. Laisser l'auteur piloter le découpage évite le rapport de force et préserve sa motivation.
Poser des règles collectives. Protection de main (PR obligatoire, CI verte), délai de revue cible à 24 h ouvrées avec un relecteur désigné par rotation, checklist courte : test présent, migration réversible, aucun secret, aucun code mort. Justification : le goulot n'était pas la qualité du code mais le délai de revue et l'absence de CI - les deux jours perdus sur un merge en sont le symptôme le plus visible.
2. Le client ajoute deux fonctionnalités à la semaine 5. Comment gérez-vous le périmètre ? Rédigez la réponse au client et la contrepartie interne.
Read the worked answer
Rendre le coût visible avant de répondre. Il reste 3 semaines et 10 user stories ; la vélocité observée est d'environ 0,8 US par semaine, soit une capacité réaliste de 2 à 3 US. Dire oui aux deux ajouts, c'est promettre l'échec et livrer sans tests.
Réponse au client (4 à 5 phrases) : « Nous avons bien noté l'ajout de la gestion des équipes et de l'export PDF. Avec trois semaines restantes et notre vélocité actuelle, nous pouvons livrer soit les fonctionnalités cœur (création de tournoi, inscription, résultats) plus l'export PDF, soit l'ensemble en décalant la recette de deux semaines. Nous proposons de traiter la gestion des équipes en version 2 et de livrer dès maintenant un export CSV utilisable. Pouvez-vous nous confirmer l'option retenue par écrit avant vendredi ? »
Contrepartie interne. Geler le périmètre après accord écrit, prioriser en MoSCoW (indispensable, souhaitable, optionnel), et ne pas sacrifier les tests sur ce qui est livré. Poser un jalon de démonstration à la semaine 7 plutôt qu'une recette finale surprise. L'export CSV est un compromis honnête : il rend service, coûte environ une journée et n'hypothèque pas la suite.
3. Comment réduire le risque lié au module d'authentification détenu par un seul membre, sans le démotiver ?
Read the worked answer
Objectif : faire passer le facteur bus de 1 à 2. L'authentification est le module le plus risqué (sécurité, dépendance de tous les autres) et son unique détenteur est le moins disponible. Le problème est organisationnel, pas individuel : on ne « reprend » pas son code, on le partage.
Actions concrètes.
- Une session de pair programming sur son créneau du soir, où il pilote et explique ; la synthèse tient en deux pages (flux de connexion, gestion des tokens, variables d'environnement, points de vigilance).
- Écrire avec lui des tests d'intégration autour de l'authentification : ils capturent le comportement attendu et permettront à un autre de modifier le module sans casser.
- Désigner un second relecteur systématique sur ce périmètre et lui confier une petite évolution (réinitialisation de mot de passe) en binôme, pour que la connaissance circule par la pratique plutôt que par un document mort.
Côté planning, ne lui confier que des tâches bien délimitées, avec un point écrit asynchrone plutôt que des réunions qu'il ne peut pas suivre. On corrige ainsi le risque sans jamais le désigner comme le problème : c'est la condition pour qu'il adhère à la démarche.