Parcourez tous les articles dans cette catégorie
Une équipe qui code sait déjà, à chaque PR ouverte et à chaque merge, où en est le travail. Le problème n'est pas l'information, c'est qu'elle reste côté dépôt pendant que l'outil de gestion de projet, lui, attend une mise à jour manuelle.
Le dossier CIR/CII se construit habituellement en reconstituant a posteriori, dans un tableur, des heures et des descriptions déjà présentes dans l'outil de suivi. L'export CIR/CII évite cette reconstitution : le justificatif part directement des issues réelles.
Un milestone atteint à la date prévue ne dit rien sur ce qui a réellement été livré à l'intérieur. Une release, elle, ne peut pas être déclarée atteinte sans que son contenu le soit aussi. C'est là que se joue la vraie différence.
Un développeur veut des issues et des dépendances claires. Un QA veut des testings liés au travail réel. Un PM veut une vue release et roadmap lisible. Peu d'outils couvrent les trois sans qu'un métier se sente second.
Un abonnement à 10 euros par utilisateur et par mois semble anodin. Le temps que l'équipe perd chaque semaine à cause d'un outil mal adapté, lui, ne figure sur aucune facture, et coûte largement plus cher.
La question qui bloque le plus de migrations n'est pas technique : c'est « comment on fait pendant la transition, sans tout arrêter ». Voici un déroulé concret qui évite ce blocage.
Changer d'outil de gestion de projet une fois l'équipe installée coûte des semaines de migration et de résistance au changement. Ces cinq questions évitent de découvrir les limites de l'outil après l'avoir adopté.
La réunion de planification de cycle s'étire souvent bien au-delà de ce qu'elle devrait durer, parce qu'elle sert en réalité à faire un travail qui aurait dû être fait avant qu'elle commence.
Le fichier « QA_tests_v4_final_vraiment_final.xlsx » n'est pas une exagération pour beaucoup d'équipes. Voici pourquoi Excel craque sur ce cas d'usage précis, et ce qu'un suivi structuré change concrètement.
La question « on peut releaser ? » reçoit trop souvent une réponse basée sur une impression générale plutôt que sur des critères vérifiables. Voici comment transformer cette impression en checklist.
Trois projets, une seule équipe, un seul backlog qui grossit sans qu'on sache ce qui appartient à quoi : ce scénario finit toujours par ralentir tout le monde, pas seulement le projet le moins prioritaire.
Une spec vit dans Notion. Le ticket qui l'implémente vit dans Jira. Six mois plus tard, la spec a changé trois fois et le ticket ne le sait pas. Ce scénario, presque toutes les équipes qui combinent les deux outils le vivent.
Linear et Sinra utilisent tous les deux le mot cycle. Ce n'est pas un hasard : les deux outils rejettent le vocabulaire Scrum classique. Mais au-delà du vocabulaire, leur périmètre diverge nettement.
Monday.com permet de tout construire : c'est sa force marketing et sa faiblesse pratique. Une équipe de développement qui adopte Monday.com passe ses premières semaines à définir, par elle-même, ce qu'un outil dédié offre par défaut.
Asana est un excellent outil de gestion de tâches, utilisé par des équipes marketing, RH et opérations aussi bien que par des équipes produit. Cette polyvalence a un prix quand il s'agit de suivre des releases logicielles précises.
Passer une demi-journée à configurer des workflows Jira avant même d'avoir créé un seul ticket : beaucoup de petites équipes vivent ce moment et se demandent si l'outil est vraiment fait pour elles. Voici ce qui coince et ce qu'il faut chercher à la place.
Un CTO qui code encore à temps plein n'a pas encore compris son poste. Le vrai travail consiste à absorber la pression du business pour que les équipes techniques puissent construire correctement, et à porter seul les décisions qui tournent mal.
Un Lead Developer qui code toute la journée n'est pas un lead, c'est un développeur avec un titre en plus. Le vrai travail est ailleurs : dans les décisions qu'on prend pour que d'autres puissent bien faire les leurs. Et ça commence par accepter de disparaître un peu.
Le projet a une date de début, une date de fin, et un périmètre. Quand c'est livré, c'est terminé. Le produit, lui, n'a pas de fin. Il évolue, il s'améliore, il répond à des besoins qui changent. Ces deux façons de travailler ne sont pas compatibles - et confondre l'une avec l'autre coûte cher.
Il est 14h. Tu viens de rentrer dans un état de concentration profonde. Ton ticket avance. Et là : une invitation de réunion pour dans dix minutes. « Rapide sync sur le sujet X. » Cette réunion aurait pu être un message.
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.
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.
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 ?
« 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 fois avez-vous eu un 1-on-1 où votre manager a ouvert Jira pour passer en revue vos tickets en cours ? Cette réunion aurait pu être un email, ou une consultation de tableau Kanban. Le 1-on-1 qui ressemble à un rapport de statut est un 1-on-1 gâché.
Votre équipe a une page Notion avec le plan du prochain trimestre. Elle a été rédigée la semaine dernière. Trois personnes ont ajouté des commentaires. Deux ont mis un emoji. Le plan n'a pas changé. Personne n'a pris de décision. C'est l'async sans contrôle : beaucoup d'activité, peu de résolution.
Quand est-ce qu'une epic est terminée ? La question devrait avoir une réponse simple. En pratique, dans la plupart des équipes, c'est une longue conversation. L'epic grandit, se divise, se réouvre, migre d'un sprint à l'autre. Ce n'est pas un problème d'implémentation Scrum. C'est un problème de définition.
« Notre velocity est de 42 points par sprint. » Cette phrase est prononcée avec fierté dans des centaines de réunions de planification chaque semaine. Elle dit quoi, exactement ? Que l'équipe ferme des tickets à un rythme cohérent. Ce qu'elle ne dit pas : si ces tickets créent de la valeur, si les estimations sont réalistes, si l'équipe est épanouie.
Combien de fois avez-vous vu une release se transformer en fourre-tout de fonctionnalités semi-terminées, de corrections de dernière minute et de tickets migrés depuis trois sprints précédents ? La release a perdu son sens parce qu'elle n'est utilisée que comme conteneur de livraison, pas comme outil de pilotage.
« En tant qu'utilisateur, je veux pouvoir me connecter afin de pouvoir accéder à mon compte. » Ce ticket a été écrit des millions de fois. Il ne décrit rien d'utile sur ce que le développeur doit faire. C'est le problème central de la user story comme unité de travail.
sinra