ayeba : marché public agile ?

[((/dotclear/public/logos/.logo-ayeba_t.jpg|ayeba|L|ayeba))|/dotclear/public/logos/logo-ayeba.png]Ayeba, société de conseil en organisation, vient de publier sa ++[lettre d’information (mars 2010)|http://ayeba.fr/2010/03/30/lettre-dinformation-de-mars-2010/|fr]++.%%% %%% On y trouve notamment le retour de ++[Patrick Leroy Kowalski|http://www.cnsa.fr/article.php3?id_article=360|fr]++, responsable études et développement à la CNSA (Caisse Nationale de Solidarité pour l’Autonomie) sur l’introduction des méthodes de développement agile dans le cadre de marchés publics.%%% %%% Mon avis : pas de scoop avec une proposition sous forme de marchés à tranches ferme (cadrage) et à bons de commande (itérations)… mais ça a le mérite de faire un état des lieux et de poser le problème. Je pense que la notion d’engagement sur des unités d’œuvre peut être remplacée par un engagement sur la vélocité…%%% %%% Dans tous les cas, sans (r)évolution des procédures d’appel d’offres et des formes des marchés publics, on sent bien que les acheteurs et donneurs d’ordre publics sont aujourd’hui obligés de feinter s’ils souhaitent passer à l’Agile. Au boulot les juristes !%%% %%% Rappelons que {{les appels d’offres publics, c’est 120 milliards d’euros par an, soit environ 10% du PIB français}} (source : ++[Répondre à un appel d’offre/marché public|http://www.appeldoffrepublic.fr/|fr]++).%%% %%% __Feedback :__%%% * ++[Guide de l’agilité dans les marchés publics|http://ayeba.org/2010/04/05/guide-de-lagilite-dans-les-marches-publics/|fr]++ par Alexis Monville

Facilitating change is more effective than attempting to prevent it

((/dotclear/public/punaise.JPG|Punaise|L|Punaise, aoû 2009)){{Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond to unpredictable events; it’s more important than trusting in your ability to plan for disaster.}}%%% %%% Martin Fowler and Jim Highsmith

Whisky Live Aquitaine le 12 avril à Bordeaux

[((/dotclear/public/whisky/.Whisky-Live-Aquitaine-12042010_t.jpg|WHISKY LIVE AQUITAINE – 12 AVRIL 2010|L|WHISKY LIVE AQUITAINE – 12 AVRIL 2010))|/dotclear/public/whisky/Whisky-Live-Aquitaine-12042010.jpg]Le __WHISKY LIVE AQUITAINE 2010__ se tiendra __le 12 avril 2010 de 19h à 22h__ à Bordeaux dans le cadre du __Hangar 14 – quai des Chartrons__.%%% %%% Cette 6ème édition régionale accueillera plus de 50 distilleries, parmi les plus prestigieuses d’Écosse, d’Irlande, du Japon, des États-Unis, du Pays de Galles et de France !%%% %%% Vous pouvez dès maintenant réserver votre entrée sur le site de ++[La Maison du Whisky|http://www.whisky.fr/produit-14049-whisky-live-aquitaine-%2812-avril-2010%29.html|fr]++.%%% %%%

Rétrospective « Embarquez Agile ! » le 18 mars

!!Embarquez Agile : l’agilité pour les développements embarqués critiques certifiables%%% Cette journée à l’Institut de Maintenance Aéronautique de Mérignac avait pour objectif de catalyser une communauté Agile au sein de ++[Aerospace Valley|http://www.aerospace-valley.com/|fr]++ (pôle de compétitivité mondial Midi-Pyrénées & Aquitaine) et de favoriser l’émergence de projets pilotes. Elle était construite autour de tables rondes d’experts et nous a permis d’appréhender l’état de l’art, les enjeux, les verrous technologiques et de prendre connaissance des retours d’expériences liés à la mise en place de l’agilité dans les développements embarqués.%%% %%% Programme de la journée :%%% ((/dotclear/public/20100318-IMA-program.png|Programme de l’événement Aerospace Valley du 18 mars 2010||Programme de l’événement Aerospace Valley du 18 mars 2010))%%% !!What went well%%% – J’aime bien l’idée  »récursive » présentée par Yann Coste/Eurogiciel de réaliser un projet agile de développement d’un outil d’aide au pilotage d’un projet agile (++[Youkan.eu|http://youkan.eu/|en]++) : très fort !%%% – Présentation très  »humaniste » de l’Agilité par Thierry Cros/A2-Artal : j’ai un brin d’admiration pour cet Être Agile…%%% – Présentation très pédagogique par Cyrille Comar/AdaCore de l’Open source, du Logiciel Libre et du modèle de collaboration de sociétés – concurrentes ou qui n’ont rien à voir entre elles – à travers les communautés libres.%%% – Présentation très intéressante par Cyrille Comar/AdaCore (encore lui !) du concept de « Certification continue » par l’analyse quotidienne de couverture structurelle du code.%%% – Présentation exceptionnelle de Pascal Fortin/Thales Avionics à Valence. Il a remis les pendules à l’heure avec un retour d’expérience concret et réussi de la mise en œuvre des principes agiles dans ses projets : très lucide et pragmatique, chapeau bas ! ++[Emmanuel Chenu|http://emmanuelchenu.blogspot.com/|fr]++ est dans ses équipes !%%% – Présentation très intéressante de Thierry Torlotin et Francis Dachicourt/Freescale sur la courageuse mise en œuvre de l’Intégration Continue sur un projet extrêmement complexe (4 sites, 290 ingénieurs / 7 équipes, 100 livraisons commerciales en 14 mois, 3000 change request & problem report, 65000 tests fonctionnels, …) : on sent que ça a chauffé !%%% %%% __Je restitue ici quelques phrases percutantes prononcées par chacun des intervenants :__%%% !Gérard Ladier – Membre permanent Aerospace Valley%%% > – L’approche Agile est mal comprise et même perçue à l’antithèse des principes de développement d’un bon système avionique. Aerospace Valley souhaite casser ce mythe, offrir un bon niveau de compréhension de l’Agile, permettre la collaboration autour de l’Agile, aider et financer le démarrage de projets agiles.%%% ! Thibaut Gavard – ScrumMaster Eurogiciel%%% > – Scrum ne résout pas les problèmes. Scrum met en lumière les problèmes.%%% ! Thierry Cros – Coach XP/Scrum A2-Artal%%% > – L’auto-organisation ce n’est pas les bisounours, c’est la prise de responsabilité par les membres de l’équipe.%%% > – On peut jouer pour ne pas perdre. En Agilité, on joue pour gagner !%%% > – L’Agilité est une affaire de valeurs : soit vous les achetez, soit vous ne les achetez pas. C’est là que se situe le vrai critère de l’Agilité.%%% > – XP : plus qu’Agile…%%% > – Scrum c’est la marque qui fait vendre XP aujourd’hui.%%% > – La user story est une promesse de discussion (référence aux ++[3Cs de Ron Jeffries|/dotclear/index.php?post/2009/11/11/XP-l-essentiel-%3A-Carte-Conversation-Confirmation|fr]++).%%% > – La véritable respiration agile se situe au niveau de la release (livraison en production).%%% ! Yann Coste – Responsable du pôle Agile chez Eurogiciel%%% > – Alignez les indicateurs de performance avec les intérêts communs.%%% > – CMMI, un modèle qui définit le quoi. L’Agilité définit le comment.%%% > – L’Agile peut être évalué CMMI. CMMI et l’Agile sont complémentaires.%%% ! Cyrille Lomar – Président fondateur de AdaCore%%% > – Le « Big Freeze » : une fois passée la machine à certifier, l’idée de changer 1 ligne de code va déclencher une levée de bouclier !%%% > – La DO178 dit de faire les tests à partir des spécifications et non à partir du code. Donc écrivez les tests avant le code = principe agile.%%% > – Faire collaborer/partager des concurrents sur le long terme au lieu d’envoyer leur travail dans certains pays et se créer de nouveaux compétiteurs ! aïe, ça tape où ça fait mal !%%% ! Pascal Fortin – Responsable métier logiciel Navigation chez Thales Avionics%%% > – Dans un produit ou un système, le logiciel est la seule partie « molle » ( »soft »ware).%%% > – Le cycle en V date des années 70 et n’est plus adapté au contexte.%%% > – Le cycle en V part du principe que tout peut être défini à l’avance et que toute la phase descendante du V va se faire de façon parfaite (pas d’erreur, pas d’oubli, pas d’incompréhension) : complètement utopique !%%% > – Le cycle est trop long, les projets durent plus d’1 an, donc pas d’asservissement…%%% > – Scrum pour le processus (rigueur et transparence). XP pour les pratiques techniques. Le Lean pour la philosophie (amélioration continue et flux tiré continu).%%% > – Les méthodes agiles sont là pour limiter les impacts du changement.%%% > – Le code redevient vivant et donc réutilisable puisqu’on a une base de tests automatisés.%%% > – Un process et des techniques appliquées rigoureusement restent nécessaires pour le succès.%%% > – On a travaillé en sous-marin pendant longtemps… et puis la démarche Lean dans l’entreprise nous a permis de faire notre coming-out !%%% > – 70% des projets échouent => relation client/fournisseur perdant/perdant => revoir la contractualisation pour être gagnant/gagnant.%%% !!What went Wrong%%% – Thierry Cros n’a pas pu faire sa présentation « La gouvernance agile » par manque de temps… tant pis ce sera pour la prochaine fois !%%% !!Puzzles%%% – Sujet de Yann Coste « Mise en oeuvre de SCRUM / XP dans un contexte d’évaluation CMMI niveau 2″ présenté aux Agile Tour 2009 de Rennes, Nantes, Paris mais pas Bordeaux ???%%% – Lapsus de Thibaut Gavard : équipe  »disciplinaire » au lieu de pluri-disciplinaires ;-)%%% – Thierry Cros : l’Agile est structurellement  »prophylactique » ?%%% – Depuis quand Thierry Cros porte-t-il la barbe ?%%% –  »MDD » ou Model Driven Development ?%%% – C’est quoi un  »Point d’unité d’œuvre » ?%%% –  »FPGA » ou Field Programmable Gate Array ?%%% – ++[Electric Cloud|http://www.electric-cloud.com/|en]++ ?%%% !!Lessons (re-)learnt%%% – Vidéo à revoir : ++[« Le lean engineering chez Thales »|http://www.dailymotion.com/video/x9pv7w_le-lean-engineering-chez-thales_tech|fr]++%%% – En 1970, Winston W. Royce publie un article, ++[« Managing the development of large software systems »|http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf|en]++, qui décrit le modèle de la cascade (Waterfall) en tant que modèle théorique… il n’a jamais préconisé de l’appliquer tel quel…%%% – Un des freins de l’Intégration Continue c’est la transparence : pas toujours appréciée par les contributeurs…%%% !!Appreciations%%% – Merci à Aerospace Valley, représenté par son membre permanent Gérard Ladier, qui a tenu à réaliser cet événement sur Bordeaux%%% – Merci aux intervenants Jean-Frédéric Real/Eurogiciel, Thierry Cros/A2-Artal, Yann Coste/Eurogiciel, Thibaut Gavard/Eurogiciel, Cyrille Comar/AdaCore, Pascal Fortin/Thales Avionics, Thierry Torlotin/Freescale, Francis Dachicourt/Freescale, Matteo Bordin/AdaCore.%%% – Merci aux 57 participants qui ont également permis que cet événement soit une réussite.%%% – Merci à Eurogiciel (notamment Isabelle Drouillard) d’avoir efficacement géré l’organisation de la journée.%%% – Encore merci à Thierry Cros qui, grâce à son blog ++[« Être Agile »|http://etreagile.thierrycros.net/home/index.php?post/2010/03/11/Embarquez-agile-!|fr]++, m’a informé de l’événement.%%% !!Feedbacks%%% – Blog de David Brocard : ++[« Agilité pour systèmes critiques : Yes We Can! »|http://www.davidbrocard.org/node/91|fr]++%%% – Blog SigmaT : ++[« Embarquez Agile »|http://www.sigmat.fr/dotclear/index.php?post/2010/03/23/Embarquez-Agile|fr]++%%% %%% [((/dotclear/public/./.20100318-IMA_m.jpg|Evénement Aerospace Valley 18 mars 2010||Evénement Aerospace Valley 18 mars 2010))|/dotclear/public/20100318-IMA.JPG]

Je ne résiste pas…

C’est toujours et encore la même image, mais que voulez-vous, c’est mon quotidien en ce moment, alors voilà :%%% %%% [((/dotclear/public/./.requirements-communication_m.jpg|Ce que veut le client…||Ce que veut le client…))|/dotclear/public/requirements-communication.jpg]%%% %%% Ça doit sûrement venir du cahier décharge ou du respect d’énorme 😉 %%% %%% __Feedback :__%%% * ++[Project Cartoon|http://www.projectcartoon.com/|en]++, vu sur le billet de l’Institut Agile intitulé ++[« Quarante ans de crise »|http://blog.institut-agile.fr/2010/10/quarante-ans-de-crise.html]++

Flux – Découvrir les problèmes et les gaspillages en Kanban

[((/dotclear/public/photos/.michael-dubakov_t.jpg|Michael Dubakov|L|Michael Dubakov))|/dotclear/public/photos/michael-dubakov.png]J’ai traduit un billet intéressant de Michael Dubakov ++[« Flow. Discover Problems and Waste in Kanban »|http://www.targetprocess.com/blog/2010/02/flow-discover-problems-and-waste.html|en]++.%%% > Vous ++[kanban-isez votre processus de développement|http://www.targetprocess.com/blog/2009/10/our-development-process.html|en]++ et mettez en œuvre un ++[flux parfait|http://www.targetprocess.com/blog/2009/10/how-do-we-use-kanban-board-the-real-example.html|en]++. Vous voyez le flux et ressentez sa puissance. Vous mesurez même le temps de cycle et vous souhaitez le réduire. Mais ce n’est pas aussi facile que prévu. Certains des problèmes de votre processus de développement sont difficiles à trouver et à mettre à jour au niveau de l’équipe. Je vais ici vous décrire une technique intéressante qui peut vous aider.%%% > %%% > L’idée est assez simple. Prenez une seule user story et enregistrez ses différents états du début à la fin, ainsi vous visualisez __le flux entier d’une unique story__. Inscrivez tous ses états sur un axe Y et les jours sur un axe X. Vous obtenez finalement le tableau suivant (cliquez pour agrandir) :%%% > [((/dotclear/public/traductions/.flow3_weekend_m.jpg|Flux d’une user story complexe||Flux d’une user story complexe))|/dotclear/public/traductions/flow3_weekend.jpg]%%% > C’est une user story réelle du projet TargetProcess. Elle était assez complexe et son temps de cycle était de __19 jours__. Laissez-moi apporter quelques détails.%%% > %%% > La user story est restée dans l’état Planifié pendant seulement 1 jour, puis les développeurs l’ont prise et déplacé dans l’état En cours. Jusqu’ici ça va. 4 jours de développement et la user story est déplacée dans l’état __Codé__, mais elle est resté là pendant __2 jours__. Pourquoi ? Pourquoi les testeurs ne l’ont-ils pas tout de suite traitée ? De toute évidence, nous venons de constater 2 jours de retard et le motif du retard doit être trouvé, car cela augmente le temps de cycle de la story.%%% > %%% > Ensuite, les testeurs ont testé la story pendant 2 jours. Puis la story a été déplacée dans l’état __En cours__ de nouveau et les développeurs ont travaillé dessus pendant __2 jours de plus__ (y compris le samedi). Pourquoi ? Cela représente la moitié de la charge initiale de développement. C’est clairement un signe de gaspillage, mais nous avons besoin de plus d’informations. Il apparaît que les testeurs ont trouvé __11 bogues__. La moitié des bogues a été causée par une spécification insuffisante de la story, les autres bogues doivent faire l’objet d’une enquête. Nous devrions ici appliquer l’analyse de cause racine (NdT : root-cause analysis) pour trouver les vrais problèmes.%%% > %%% > OK. Ensuite, les testeurs ont vérifié la user story pendant 2 jours et l’ont passé dans l’état Prêt à intégrer. Elle a été intégrée assez rapidement (en 1 jour), mais là encore il y a peut-être du gaspillage à éliminer. Finalement, la user story est restée dans l’état __Intégrée__ pendant __5 jours__ et a été livrée le 29 Janvier.%%% > %%% > Au total (et au minimum !) nous avons découvert environ __9 jours de gaspillage__. Cela signifie que nous pouvons réduire le temps de cycle de manière significative par l’élimination de ce temps d’attente (gaspillage). Si vous vérifiez plusieurs user stories en utilisant cette technique, je crois que vous trouverez des résultats comparables pour des stories simples et complexes.%%% > %%% > Voici un autre exemple avec une user story assez simple. Nous voyons encore clairement apparaître des temps d’attente dans notre flux ! Nous pouvons réduire le temps de cycle à __2 jours au lieu de 6__ en éliminant simplement les temps d’attente dans le flux. Mais ce n’est pas facile ;-)%%% > [((/dotclear/public/traductions/.flow2_weekend_m.jpg|Flux d’une user story simple||Flux d’une user story simple))|/dotclear/public/traductions/flow2_weekend.jpg]%%% > %%% > Ce graphique est un outil très puissant. Il est facile à créer et vous pouvez l’utiliser pour trouver des gaspillages dans votre cycle de développement.%%% __Feedbacks :__%%% * Blog Agile Gardener de Tremeur Balbous : ++[« Mettre de la pression sur le système pour faire apparaître le gaspillage »|http://www.agilegardener.com/2010/03/11/mettre-de-la-pression-sur-le-systeme-pour-faire-apparaitre-le-gaspillage/|en]++

Concours logo Okiwi

((/dotclear/public/logos/Kiwi-Bird-icon-64×64.png|Exemple ©Logo Design New Zealand|L|Exemple ©Logo Design New Zealand))J’ai lancé un ++[concours de logos pour l’association Okiwi|http://okiwi.org/blogs/?p=442|fr]++ sur son nouveau blog (mis en œuvre par ++[Colin Garriga Salaün|http://fr.linkedin.com/pub/colin-garriga-sala%C3%BCn/9/670/600|fr]++ et motorisé sous WordPress).%%% %%%  »Wait and see… »

Inherent compromises of today’s project-oriented world

((/dotclear/public/punaise.JPG|Punaise|L|Punaise, aoû 2009)){{Do you want it quick, cheap or good? I can give you any two.}}%%% %%%  »Arthur C. Clarke »%%% %%% Courtesy: Cooney Training Services Pty Ltd:%%% > If you want a product, service or project to be:%%% > – Cheap and fast, it won’t be good%%% > – Good and fast, it won’t be cheap%%% > – Good and cheap, it won’t be fast%%% Source : ++[« What is a Business Analyst? by Derrick Brown and Jan Kusiak © 2002-2010 IRM Training Pty Ltd »|http://www.requirementsnetwork.com/system/files/What_is_a_Business_Analyst.pdf|en]++%%%

Un remède contre la manie d’estimer les tâches – Ne le faites pas, c’est tout

((/dotclear/public/photos/.AlanAtlas_t.jpg|Alan Atlas|L|Alan Atlas))Philippe Launay a mentionné cet article de __Alan Atlas__ au cours des deux derniers ++[Scrum Café bordelais|http://www.meetup.com/frenchsug/calendar/12457547/|fr]++ :%%% %%% ++[« A Cure for Task Estimation Obsession – Just Don’t Do It »|http://www.scrumalliance.org/articles/116-a-cure-for-task-estimation-obsession|en]++.%%% %%% Lors de mon récent aller-retour à Paris, j’ai profité du temps passé dans les transports pour le traduire en français.%%% > Je vois souvent des équipes obsédées lors des réunions de planification des sprints, notamment par l’estimation des tâches. J’insiste, réellement obsédées. Deux jours de planification pour un sprint de deux semaines ? Croyez-moi ou non mais cela arrive. Même s’ils se plaignent de passer trop de temps en réunions Scrum, ils vont insister pour se prendre la tête sur l’estimation de chacune des tâches. Pour les équipes qui souhaitent profiter de leur expérience acquise en Scrum et optimiser leur planification, éliminer purement et simplement l’étape d’estimation des tâches est une solution possible. %%% > %%% > Ne soyez pas choqué. C’est possible. Un avertissement néanmoins. Pour les équipes qui débutent en Scrum, je déconseille d’éliminer tout de suite l’étape d’estimation, en tout cas pas avant d’avoir atteint une vélocité stable.%%% > %%% > Par contre, une fois que vous avez atteint une vélocité stable, vous  »pouvez » utiliser les concepts des story points et de vélocité pour vous épargner d’estimer les tâches lors des planifications de sprint. Le temps consacré à l’estimation des tâches peut alors être utilisé plus raisonnablement pour créer un logiciel opérationnel. Je vais vous présenter une démarche en plusieurs étapes que vous pourrez employer pour progressivement éliminer l’estimation des tâches de votre processus de planification d’un sprint.%%% > %%% > __Contexte__%%% > %%% > Avant de commencer, rappelons rapidement la raison d’être de la planification de sprint (nous voulons ici garantir que nous satisferons les besoins de départ lorsque nous aurons optimiser le processus. Nous planifions un sprint pour nous retrouver dans la situation suivante :%%% > 1. une compréhension des objectifs du sprint, partagée par toute l’équipe%%% > 2. une compréhension du travail qui va être réalisé pendant le sprint, partagée par toute l’équipe%%% > 3. un environnement dans lequel chaque membre de l’équipe sait ce qu’il doit réaliser à l’étape suivante (ou en tout cas qui lui permet de le retrouver en quelques secondes)%%% > 4. un réel engagement de l’équipe à livrer une certaine quantité de valeur exprimée sous la forme d’éléments du backlog produit%%% > 5. et un burndown chart que l’équipe pourra utiliser pour observer sa progression durant le sprint.%%% > %%% > L’estimation des tâches répond le plus souvent à l’objectif 5, et pour certaine équipes à l’objectif 4. Si nous pouvons atteindre ces deux objectifs sans avoir besoin d’estimer les tâches alors nous sommes libres de ne plus estimer du tout les tâches, n’est ce pas ? Si vous êtes d’accord sur ces points alors je vous présente ici la démarche à utiliser pour progressivement vous passer de l’estimation des tâches.%%% > %%% > __Étape 1 : établissez une vélocité stable__%%% > %%% > Utilisez votre processus standard de planification de sprint, qu’il prenne deux jours ou deux heures, jusqu’à ce que vous constatiez que votre vélocité est stable (il y a beaucoup de discussions sur comment atteindre une vélocité stable et c’est un sujet trop vaste pour le traiter ici ; pour en savoir plus, je vous conseille de lire « Agile Estimating and Planning » de Mike Cohn). Assurez-vous que votre équipe passe le test Nokia en produisant un logiciel potentiellement livrable à chaque sprint (autrement dit que vous avez prouvé que vous pouviez correctement calculer votre vélocité). Une fois que vous avez obtenu une vélocité stable, votre équipe pourra s’engager et réussir à atteindre les objectifs en se basant uniquement sur une vélocité avérée et une estimation des éléments du backlog produit en story points. Vous souhaitez bien dans tous les cas atteindre ces objectifs que votre niveau de mise en œuvre de Scrum soit bon ou pas, n’est-ce pas ?%%% > %%% > __Étape 2 : expérimentez avec un burndown chart basé sur les tâches__%%% > %%% > Lorsque vous pensez être prêt pour ne plus estimer les tâches, commencez à utiliser deux burdown charts au lieu d’un seul. Continuez à utiliser votre burndown actuel basé sur l’effort donc l’estimation des tâches du backlog du sprint. Utilisez un nouveau burndown chart qui sera uniquement basé sur le nombre de tâches dans le backlog sans tenir compte de leurs estimations. Ce nouveau burndown chart peut être baptisé burndown chart basé sur les tâches.%%% > %%% > Votre classique burndown chart basé sur l’effort démarre avec le total des tâches estimées pour le sprint et, étant donné que les estimations sont révisées quotidiennement, le burndown continue à refléter la quantité estimée d’effort restant à produire lors du sprint. Cette quantité a heureusement tendance à tendre vers zéro. Votre nouveau burndown basé sur les tâches démarre quant à lui avec le nombre total de tâches identifiées pour le sprint. Les estimations ne sont pas mises à jour dans ce cas et la tâche est déclarée terminée sur le burndown (passe donc de 1 à 0). Pour de meilleurs résultats, assurez-vous que le découpage des tâches ait produit des tâches qui soient les plus petites possibles. Le burndown chart basé sur les tâches reflète le nombre total de tâches estimé et restant à réaliser dans les sprints et non l’effort estimé restant à produire. Cela fonctionne mieux si vous avez plein de petites tâches, typiquement réalisables en un jour ou même moins.%%% > %%% > Assurez-vous que les deux burndown charts soient bien synchronisés et qu’ils vous donnent tous les deux la même visibilité de votre progression durant le sprint. Si vous pensez que le burndown basé sur les tâches n’est pas utile, passez à l’étape 3.%%% > %%% > __Étape 3 : rétrécissez les tâches pour améliorer le burndown basé sur les tâches__%%% > %%% > Un bon et instructif burndown chart dépend du nombre de petites tâches. D’un point de vue conceptuel, si vous n’avez qu’une seule tâche par éléments du backlog produit dans le backlog du sprint, vous disposez peut être d’un excellent burndown chart basé sur l’effort parce que chaque mise à jour quotidienne de l’estimation des tâches est donnée avec une granularité arbitraire (sauf que si vos éléments du backlog produit ont réellement une seule tâche chacun alors cela indique que vous avez un problème soit avec vos stories soit avec votre découpage en tâches).%%% > Par contre, le burndown chart basé sur les tâches sera, pour ce sprint, insensible à une mise à jour quotidienne puisque les tâches auront tendance à tenir sur plusieurs jours et votre progression ne sera pas visible avant que la tâche soit terminée. La solution est de découper en petites tâches. Une bonne règle est que la tâche soit réalisable en une journée voire moins.%%% > %%% > __Étape 4 : arrêtez d’estimer les tâches__%%% > %%% > Lorsque vos deux burndown charts contiennent des informations similaires et que vous pouvez livrer en vous engageant sur des sprints basés sur la vélocité, vous pouvez arrêter d’estimer les tâches et ne plus gérer un burndown chart basé sur l’effort. Ce sera facile pour certaines équipes et pour d’autres cela prendra plusieurs sprints. L’idée clé est d’utiliser correctement la vélocité. Notez bien que vous continuerez encore à découper en tâches. Éliminer le tâches est une étape encore différente.%%% > %%% > Qu’avons-nous finalement perdu en n’estimant plus les tâches ? L’estimation des tâches sert les objectifs 4 et 5 de la liste de départ. Nous disposons toujours d’un burndown chart pour suivre la progression donc nous servons toujours l’objectif 5. Nous n’avons plus besoin de l’objectif 4 parce que notre équipe a prouvé sa capacité à s’engager sur des estimations d’éléments du backlog produit en story points et n’utilise plus l’estimation des tâches pour validation.%%% > %%% > La seule chose que nous avons peut être perdue est de ne plus fournir un axe de visibilité sur le planning des travaux à réaliser durant le sprint (objectif 2). Autrement dit, en ne demandant plus d’estimations, nous avons peut être supprimer une forme de pression psychologique/motivation pour traiter la problématique de planification correcte des tâches qui exigeait un travail de fond sur le sujet, en regardant les problèmes un par un, en faisant le parallèle avec des travaux similaires et plus généralement en apportant de façon active de la connaissance et de l’expérience. Était-ce vraiment primordial ? Seuls votre équipe et vous-même pouvez répondre à cette question…%%% %%% __Feedbacks :__%%% * Blog SFEIR ++[« Séance d’estimation »|http://blog.onagileway.fr/post/2010/03/15/S%C3%A9ance-d-estimation|fr]++%%%