Le développeur précédent est parti
On récupère les accès, le dépôt, l'hébergement et la documentation disponible avant de toucher au code.
Chargement...
Bug critique, dette technique, accès dispersés ou développeur absent : on commence par comprendre l'existant, puis on traite le blocage qui empêche réellement le produit d'avancer.
Premier échange de 30 minutes, sans engagement.
On récupère les accès, le dépôt, l'hébergement et la documentation disponible avant de toucher au code.
On reproduit le problème, on identifie sa cause et on traite d'abord le parcours qui a le plus d'impact métier.
On distingue ce qui peut rester de ce qui doit changer, puis on avance par étapes courtes et réversibles.
Le périmètre est fixé après l'analyse initiale. On préfère une amélioration prioritaire réellement livrée à une promesse de tout corriger sans avoir vu le code.
Non. Le dépôt de code et les accès techniques suffisent généralement pour commencer. La première étape consiste justement à cartographier l'existant et les zones inconnues.
Le sprint traite un périmètre prioritaire défini après l'analyse initiale. L'objectif n'est pas de promettre une réécriture complète, mais de remettre le projet sous contrôle et de livrer une amélioration vérifiable.
Oui. Le plan de fin de sprint permet de décider sereinement : continuer par étapes, organiser une refonte progressive ou transférer le projet à votre équipe.
Vous. Les modifications sont versionnées sur un dépôt auquel vous avez accès, avec un compte rendu permettant à une autre équipe de reprendre le travail.
Explique-moi ce qui bloque. Tu repars du premier échange avec une priorité claire, même si nous ne travaillons pas ensemble.