Apprenez les stratégies modernes de gestion de projet, planification des releases, intégration QA et montée en charge des équipes. Conseils pour les leaders techniques et chefs de projet.
Il est 9h30. L'équipe est réunie. Chacun à son tour répond aux trois questions : « Qu'est-ce que j'ai fait hier, qu'est-ce que je fais aujourd'hui, quels sont mes blocages. » Quinze minutes plus tard, tout le monde repart à son écran sans que rien n'ait changé. Ce daily n'a servi à rien.
Il existe dans l'industrie tech un archétype admiré : le développeur brillant et solitaire qui produit plus de code que dix développeurs ordinaires. Cet archétype influence les recrutements, justifie des packages salariaux inégaux et crée des cultures d'équipe dysfonctionnelles. Il est aussi en grande partie un mythe.
Votre organisation a implémenté SAFe. Vous avez maintenant des ARTs, des PI Plannings, des System Demos et des Inspect & Adapt workshops. Votre organisation est également plus lente, plus réunionnée et plus frustrante pour les ingénieurs qu'avant. Ce n'est pas un bug de votre implémentation SAFe. C'est souvent une caractéristique.
L'estimation est souvent une fiction partagée : les développeurs donnent des chiffres qu'ils savent imprécis, le management les prend comme des engagements, et quand les estimations sont dépassées, tout le monde est surpris d'être surpris. #NoEstimates dit : arrêtons la fiction. La question est : par quoi on la remplace ?
La base de données de production est tombée vendredi à 18h. Le post-mortem a eu lieu lundi. Dans le compte-rendu : cinq points d'amélioration des processus, trois actions de remédiation technique, et une mention discrète que 'l'incident a été causé par une erreur humaine lors de la migration'. Cette phrase est l'opposé d'un blameless post-mortem.
Si votre équipe passe plus de temps à débattre de monorepo vs polyrepo qu'à écrire du code, c'est le signe que le débat est mal posé. Les deux approches fonctionnent. La vraie question est : quelle structure correspond à votre organisation et à votre cycle de livraison ?
Votre codebase a 47 feature flags actifs. Cinq sont documentés. Trois sont liés à des fonctionnalités livrées il y a neuf mois et personne n'a pensé à les supprimer. Deux sont conflictuels : activer les deux en même temps produit un comportement indéfini. Vous venez de découvrir pourquoi les feature flags ne sont pas gratuits.
L'équipe a passé trois semaines à modéliser les bounded contexts, les aggregates et les domain events de son application de gestion de contenu. L'application fait du CRUD sur cinq tables. C'est le signe que DDD est utilisé comme fin en soi, pas comme outil.
« On a besoin d'un sprint de dette technique. » Cette phrase est prononcée dans des centaines d'équipes chaque trimestre. Ce qui se passe ensuite : deux semaines de refactorisation sans direction claire, dont la valeur est impossible à communiquer au management, et qui ne change pas fondamentalement les problèmes les plus douloureux.
Combien de jours un nouveau développeur passe-t-il à essayer de faire tourner le projet en local avant de pouvoir contribuer réellement ? Dans la plupart des équipes, la réponse est entre deux et dix jours. La documentation d'onboarding existe, elle est juste fausse.
