Salut Julien, Pour moi, il existe 2 solutions viables à terme en agilité : - pas d'estimations ou - en point (ou t-shirt ou toute autre unité abstraite) convertibles en jours. Sinon, tu finiras tôt ou tard par ne plus suivre les principes agiles de base (http://agilemanifesto.org/iso/fr/)
J'ai toujours du mal à comprendre qu'on puisse continuer à défendre les jours.hommes seuls dans une méthode itérative incrémentale comme Scrum ou XP. La seule chose sur laquelle nous sommes d'accord en jour, c'est qu'il fait 24h. Ensuite, personne n'a la même manière de travailler, tout le monde s'imagine des jours différents, un déroulement différent, et ce même avec une définition of done bien travaillée. L'avantage du JH, c'est que quand tu as 40 JH d'itération, si tu as estimé 40JH, tu sais donc exactement ce qui rentre de tes estimations. Mais c'est un avantage uniquement pour celui à qui tu demandes des comptes, donc inéquitable. A terme, ta seule variabilité est la durée de travail de ta journée, car tout le reste ajouterait des JH déjà estimés. Tu laisses une User Story à 5JH de côté, elle devra forcément être ré-estimée à chaque sprint où tu la prévois (oui, si par malheur l'équipe ne la finissait pas :). C'est ainsi qu'on évite à tout prix le changement de plans et qu'on passe son temps à ré-estimer. Lorsque le PO refuse une US, il dit juste que l'équipe a mal estimé et/ou mal fait son dev car les 2 viennent de l'équipe et pas de lui, mais ne s'engage pas dans ce délai supplémentaire. C'est la base de la non-collaboration client/équipe. L'avantage du point sur le jour.homme est qu'il est dynamique : si tu as un sprint avec 40 JH dispo, tu peux prévoir 50 ou 100 points. En fin d'itération, tu conclus en mesurant combien tu as réellement fait. Par exemple : 80 points ? Bien, l'équipe a fait 2 points par JH en moyenne. C'est en mesurant la moyenne faite que tu déduis ton nombre de points/JH, et donc une mesure en JH au final. Exemple précédent, tu fais ensuite 1,8 points/JH puis 2,5 points/JH en moyenne. Tu conclues que tu fais 2,1 points par JH sur 3 sprint, ce qui est assez significatif pour que ton PO prévoit sur cette base. De plus, tu estimes une User Story à 8 points aujourd'hui, sauf gros changement technique ou d'environnement humain, elle reste à 8 points dans le futur, mais peut-être pas le même nombre de JH. Pas de perte de temps à ré-estimer, tu multiplies par ton nombre de points/JH. Enfin, si ton PO refuse une User Story, il augmente la valeur du point en JH. Il est totalement engagé dans le compromis vélocité/qualité. Il est associé à l'équipe sur l'avancement et donc le coût du produit. Et pour conclure sur les points : sa killer feature est qu'on peut à tout moment convertir en JH sur la base d'une expérience réelle et indiscutable, tout en gardant une flexibilité énorme. Pour finir avec la "non estimation", je souhaite à tout le monde d'en arriver là, car c'est le plus efficace. Ca force à se faire confiance et à faire des US très petites. Maintenant, c'est pour ces raisons que c'est compliqué . Ca demande une grande maturité de l'équipe et de sa relation avec le client. Rares sont les clients qui acceptent de ne pas savoir d’emblée ce qu'ils vont dépenser pour telle date et/ou tel périmètre de projet. Bref, pour moi, "non estimation" > "estimation en points" >> "estimation en JH" Merci si vous avez lu jusqu'ici :) - Bastien Le 21 janvier 2014 12:55, <[email protected]> a écrit : > On 21.01.2014 12:32, [email protected] wrote: > >> ----- Mail original ----- >>> De: [email protected] >>> À: [email protected] >>> Envoyé: Mardi 21 Janvier 2014 11:58:07 >>> Objet: [RailsFr] Chiffrages en point ou en jours ? >>> >>> Hello les railistes, >>> >>> suite à des discussions avec des collègues on s’est aperçu que pour les >>> chiffrages de user stories il y a deux écoles: ceux qui chiffrent en >>> points et ceux qui chiffres en jours. >>> >> >> >> Bonjour, >> >> Et bien j'ajouterais bien une troisième option: pas d'estimation, pas >> d'engagement de moyens. En points ou en jour, la conversion est >> toujours faites... quand on estime à chaque itération (ce qui devrait >> êtrre fait) on perd 2h à une journée selon la taille de l'itération et >> la "vélocité" de l'équipe. Sans estimer, ce temps est utilisé à >> produire... >> >> Mais je suis conscient que c'est un peu extrémiste comme position... >> >> https://twitter.com/search?q=%23noEstimate >> http://zuill.us/WoodyZuill/2013/05/17/the-noestimates-hashtag/ >> http://vimeo.com/79128724 >> > > Un des avantages que j'observer à faire du poker planning c'est de voir si > tout le monde a bien la même perception des US et de détecter d'éventuels > oublis, à la limite sorti de la réunion tu peux jeter les estimations tu > auras construit quelque chose d'utile même si ce n'est pas du code. > > Si tu as une équipe si grosse qu'il te faut une journée à chaque sprint je > pense que tu as d'autres soucis :-) > > Julien > > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > --- Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes Railsfrance. > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse railsfrance+unsubscribe@ > googlegroups.com. > Pour plus d'options, visitez le site https://groups.google.com/ > groups/opt_out . > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
