J’ai cherché sur le web mais je n’ai pas trouvé de retour d’expérience sur le sujet donc je viens vous demander vos avis !
Lors des backlogs refinement ou des sprint planning, l’équipe passe pas mal de temps à estimer les items de montée de version de nos outils (par exemple angular, elasticSearch,…). Souvent l’équipe a du mal à évaluer quels vont être les impacts de la montée de version, et on en arrive à cette conclusion : soit ça se passe bien du premier coup et on pourrait estimer à 1 point de complexité, soit ça se passe mal et c’est un 8.
D’habitude je vois assez l’utilité des estimations, mais pour ce type d’item technique je trouve que ça prend beaucoup de temps pour une estimation très approximative car elle dépend beaucoup d’inconnues. Déjà parce que l’équipe ne connais pas encore parfaitement bien tous les recoins du code, et parfois car on se prend des incompatibilités qui n’avaient pas pu être anticipées.
Est-ce qu’il faut mieux préparer ces items avant de les estimer ? Est-ce qu’on les estime en fonction du risque ? Est-ce que vous avez des bonnes pratiques ou des techniques d’estimation ?
Je vais faire simple, mais pour moi, c’est la décision du PO:
Une tache à 1 devient en fait un 8 et pourrait faire capoter le sprint dans sa dimension objectif ? Le PO annule le sprint, et on replanifie pour gérer au mieux cette nouvelle information. Ca règle pas mal de problèmes.
Sauf erreur de ma part, cela ne répond pas à la question. Si vous partagez votre point de vue sur la gestion d’une tache dont la valeur s’avère complètement différente de l’estimation, Marie nous interroge sur comment l’estimer au mieux.
Vous me confirmez @MarieMathivet ?
Oh… si, ça répond indirectement. Pour être plus clair, c’est pas le genre de chose qu’on estime facilement sans boule de cristal. Donc, faisons au mieux et avisons si l’estimation est pas la bonne.
Bonjour,
L’estimation en point prend en compte la marge d’erreur. Si cette marge d’erreur devient trop grande comme dans le cas que vous évoquez, je commencerai petit en faisant un item qui comprend l’upgrade avec un peu d’analyse si ca ne fonctionne pas du 1er coup.
Si ca se passe bien ok c’est fini, si ca se passe mal on analyse ce qui ne fonctionne pas et cette analyse nous permet de définir le prochain item, qui sera du coup plus précis car on aura déjà eu un retour.
Ce premier item, pourrait être estimé à 3 ce qui réduit déjà beaucoup le risque, par contre vient ensuite la question de quand est-ce qu’on réalise le second item si ça s’est mal passé. Est-ce qu’on l’intègre dans le même sprint ou dans le suivant.
J’admet que la réponse de @Samuel_Abiassi me semble un peu extrême, mais en effet il arrive parfois que des montées de versions perturbent fortement l’objectif de sprint.
Et comme dit @Si_Le, c’est vrai que je pensais plutôt à des techniques pour justement éviter que ça arrive et estimer efficacement ce genre d’items Sur ce point, merci pour ta réponse @jgranier, c’est en effet une méthode qu’on applique sur certains items techniques.
C’est certes extrêmes, mais c’est une option à ne pas oublier/éviter. Il y a des raisons derrière comme changer le focus de l’équipe ou communiquer à l’organisation et aux stakeholders le soucis, mais cette mécanique existe dans Scrum et elle est importante aussi. Sinon, elle ne serait plus là depuis le nombre de versions qui ont pu sortir.
Bonjour,
Si mes souvenirs sont bons, quand on décide d’estimer, il est mieux de le faire de façon RELATIVE qu’absolue et que SCRUM (si c’est le cadre que vous utilisez) est empirique.
Cela m’amène à penser qu’il serait peut-être intéressant de baser vos estimations « montée de version » sur celles déjà faites.
Et pour que ce soit encore plus pertinent, je proposerai, à l’équipe de faire un atelier d’« amélioration de prédictibilité ». Sous ce terme « barbare », se cache un atelier mené pendant la retro (par exemple) et ayant pour objectif de créer un « étalon » pour les estimations suivantes. Cela consiste « simplement » à reprendre toutes les US engagées dans le sprint (toutes les actions d’upgrades passées, dans votre cas) et de les réestimer (« Avec ce que l’on connaît maintenant, cette action de 8 vaut maintenant 2 » (… ou 23 :)).
Quand c’est fait, lors d’une prochaine montée de verion, on utilise cet étalon.
Je ne sais pas si c’est faisable dans votre cas et je ne prône pas les estimations (sans pour autant les dénigrer).
En espérant avoir alimenter la discussion.
Bonne soirée
Franck
Je viens de me rendre compte que j’ai répondu à 2 sujets en même temps. La réponse est vraiment la même. Comme toujours, elle est a adapter suivant le contexte.
Pour moi, les estimations sont un exercice de projection sur le résultat et comment je vais le découper ou le comparer à une chose connue pour en tirer un effort ou une complexité. Dès lors que l’on fait appel à l’imagination, je ne vois pas cela comme qq chose de factuel.
Les estimations sont un outil d’aide à la communication sur mon imaginaire et celui du reste de l’équipe.
Dès lors que cette communication a lieu, cela m’est suffisant car elle aboutira à un meilleur alignement sur le résultat à atteindre, sur le chemin à prendre pour l’atteindre ou sur les obstacles à résoudre.
De mon expérience, sur ce genre de sujets, j’ai eu pour habitude de proposer un ticket d’exploration.
Grâce à ce travail d’exploration, les dévs ont une meilleure idée des étapes pour réaliser la tâche technique (et donc avoir une meilleure estimation) et durant cette exploration, le dév a aussi potentiellement avancé dans la réalisation de la tâche technique.
Pour ces tickets, un temps maximum était bloqué et estimé par les dévs. Généralement c’était un ou deux jours max.
Merci à tous pour vos réponses !
Dans le cas de mon équipe, je pense qu’il faut en effet qu’on explore les impacts avant d’estimer, quitte à créer un item dédié si l’exploration est conséquente.
Et pour l’étalon des estimations en se basant sur ce qui a déjà été fait, c’est une très bonne idée que je vais généraliser sur les autres types d’items aussi, ça nous aidera sûrement à être plus efficaces durant les estimations.
J’ai une question sur ta question… j’ai l’impression que tu parles des outils que vous utilisez au quotidien dans le cadre de votre travail mais qui ne concernent pas votre produit… or les estimations que vous faites doivent concerner le produit… du coup, que l’équipe garde une marge pour gérer ces upgrades est nécessaire lorsqu’il est temps de monter de version, mais ça n’est pas lié à votre objectif de sprint qui lui devrait apporter une plus value à votre produit destiné au client…
Cela n’empêche pas que vous fassiez une estimation du risque de cette montée de version et que ce soit étalé pour ne pas trop impacter le sprint… mais de là à mettre ce travail dans l’objectif du sprint me laisse dubitatif…
Au pire, estimez si ça se passe mal (bien que ce n’est jamais possible de toute façon)… et réservez vous cette plage dans le sprint pour ne pas déraper sur votre objectif engagé.
Si ça se passe bien du premier coup, vous pourrez traiter plus de tickets, donc objectif accompli… si ça dérape, vous finirez plus tard… le produit ne devant pas être impacté par ces montées de version.
Si ce sont les outils de dev, essayez de le faire dans un environnement virtuel pour voir comment ça se comporte avant de casser vos postes…
