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.
Le ticket passe en « Done ». Tout le monde passe à la suite. Trois semaines plus tard, on découvre que la fonctionnalité n'a jamais été déployée en production, que les tests d'intégration n'ont pas été mis à jour, et que personne n'a de monitoring en place. Elle était finie, vraiment ?
Votre équipe livre 40 story points par sprint. Le backlog avance. Les tickets se ferment. Et pourtant, les utilisateurs attendent des features depuis six mois. Quelque chose ne tourne pas rond. Le problème : vous mesurez l'activité, pas la livraison de valeur.
Trois équipes travaillent sur le même produit : une équipe frontend, une équipe backend, une équipe mobile. Six mois plus tard, le système a exactement trois couches bien distinctes avec des interfaces définies entre chacune. Personne n'a conçu ça explicitement. C'est Conway's Law.
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.
sinra