Qu’est-ce-que le Lean ?

 »Traduction du billet ++[« What is Lean? »|http://blog.crisp.se/henrikkniberg/2010/04/30/1272639780000.html|en]++ de Henrik Kniberg. »%%% %%% ++[Mary Poppendieck|http://www.poppendieck.com/|en]++ a utilisé cette définition lors de notre stage ++[Mise en œuvre du Lean Software Development|http://www.crisp.se/leadinglean|en]++ il y a quelques mois. Définition du lean qui a le mérite d’être à la fois excellente et concise.%%% %%% [((/dotclear/public/traductions/.what-is-lean_s.jpg|What is Lean?|L|What is Lean?))|/dotclear/public/traductions/what-is-lean.png]__Qu’est-ce-que le Lean ?__%%% %%% – Livrer régulièrement de la valeur au client et de plus en plus%%% – Déployer régulièrement des efforts mais de moins en moins%%% – Dans le délai le plus court possible%%% – Avec la meilleure qualité possible%%% %%% Un  »voyage », pas une destination.%%%

Rétrospective Formation Certifiante Scrum Product Owner

((/dotclear/public/CV/.Scrum_ProductOwner_seal_t.jpg|CSPO|L|CSPO))Je vous livre ici une rétrospective de la Formation Certifiante Scrum Product Owner animée par Michel Goldenberg et Zenika les 15 et 16 avril et à laquelle j’ai participé.%%% !!What went well * Michel a un sens de la provocation et de la répartie inégalable : idéal pour des électrochocs sur nos idées reçues ! Il n’est pas dupe de la nature humaine et a su nous le rappeler. * Nous n’étions que 6 : Michel s’est occupé de chacun d’entre nous…%%% * Mise en situation à travers de nombreux jeux dont le dernier d’une durée de 2 heures ! (business value, calcul du ROI, Time to market, stratégie d’implémentation, positionnement marketing, …) * Beaucoup d’outils simples fournis pour nous aider. * A la fin, rétrospective de la formation en bonne et due forme. * Deux journées avec un coach qui donne le meilleur et le maximum de lui même. [((/dotclear/public/./.CSPO-jeu-des-pieces_s.jpg|CSPO – Jeu des pièces||CSPO – Jeu des pièces))|/dotclear/public/CSPO-jeu-des-pieces.JPG] !!What went wrong * J’aurais bien vu une 3ème journée de formation entièrement dédiée à un jeu/simulation avec PO, SM, stakeholders et l’équipe. !!Puzzles * Scrum n’est pas une méthodologie qui va vous aider à développer de meilleurs produits ? Scrum ne va pas donner les réponses pour faire des produits de qualité rapidement ? Scrum est un framework, une boîte à outils, pour  »vous aider à trouver comment faire » des produits de qualité rapidement. * ATDD ? Acceptance Test Driven Development. * Exemple de fonctionnalité quelquefois utilisée ? la calculatrice scientifique de Windows ; qui le sait ? qui l’utilise ? * Ne pas communiquer la Business Value à l’équipe ? Ne pas communiquer les Story Points aux stakeholders ? ne pas les influencer… * Michel livre une story dès qu’elle est acceptée par le PO ? potentially shippable story… * ++[Precision ≠ Accuracy|http://en.wikipedia.org/wiki/Accuracy_and_precision|en]++ * Acétate pour diapositive slide ? * Ce sera encore plus « trippant » si vous apprenez avant quelques expressions québécoises (par exemple ++[ici|http://www.dictionnaire-quebecois.com/index.html|fr]++)%%% !!Lessons (re-)learnt Un avant-goût pour ceux qui iront faire la formation avec Michel : * Le planning traditionnel pour le client : ils ont un gros mensonge en face d’eux et ils y croient !%%% * Bonne implémentation de Scrum, on augmente la vélocité par 4 ou 6. Mauvaise implémentation de Scrum, on réduit le gaspillage par 10.%%% * Scrum est un processus empirique pour la gestion de produits complexes. Quand il y a de l’imprévisible, c’est la meilleure méthode. Lean serait la meilleure méthode pour le prévisible.%%% * La seule façon de savoir ce que le client veut, c’est de lui livrer le mauvais produit rapidement ! on veut rater le plus vite possible sur des choses utiles ! et plus vite le PO réagira !%%% * Le PO c’est le radin, l’avare de la compagnie. Il est même capable de jouer sur la qualité. C’est au SM et à l’équipe de lui dire qu’il y a des minima.%%% * Le PO, le seul responsable en cas d’échec.%%% * Le PO, un dieu humain dans une tribu qui fait des sacrifices !%%% * Si on a un mauvais PO alors le SM est un facilitateur. Si on a un bon PO alors le SM peut être un développeur.%%% * Les stakeholders contribuent au fonctionnel et au non-fonctionnel du projet. * Types de documentation interdites en Agile : la doc. qui sert à faire de la communication, la doc. qui sert à se protéger. * Si le client donne la solution alors le développeur donnera la solution de la solution. * Il est préférable d’être plus ou moins correct que d’être précisément erroné. * Quand on commence à évaluer trop grand, c’est qu’il y a des doutes. * Un bon PO sort 80% de la Business Value en consommant 75% du temps sur un projet de 6 mois alors que sur le marché on est habitué à livrer 50% de la Business Value en 150-180% du temps. * Plus l’équipe s’agilise, plus le PO a du travail. * Ne forcez pas les gens à penser au futur trop tôt. * On peut documenter autant qu’on veut, on ne fera jamais la bonne chose. Pour faire la bonne chose, il faut la montrer ! * Plus le projet est long, plus le nombre de problèmes générés est important, plus vous dégraderez la vélocité…%%% !!Appreciations * Merci à ++[Michel Goldenberg|http://www.scrumalliance.org/profiles/38596-michel-goldenberg|en]++, co-fondateur du ++[Scrum User Group à Montréal|http://www.scrumusergroup.ca/|fr]++, l’un des plus importants groupes d’utilisateurs Scrum au Canada.%%% * Merci à ++[Zenika|http://www.zenika.com/catalogue-formation|fr]++, notamment Catherine Carron (Responsable Formation).%%% * Merci à Caroline, Gaelle, Djamel, Hervé et Jonas qui ont participé à l’aventure avec moi.%%% %%% [((/dotclear/public/./.CSPO-Dream-Team_s.jpg|CSPO – La Dream Team||CSPO – La Dream Team))|/dotclear/public/CSPO-Dream-Team.JPG]

Rétrospective Whisky Live Bordeaux 2010

__What went well__%%% Pour cette rétrospective, je n’ai pas voulu mettre en avant les whiskies mais plutôt certains animateurs de stand… levez les yeux au-dessus de votre verre et vous découvrirez des gens passionnés et passionnants. J’en ai choisi trois :%%% %%% [((/dotclear/public/photos/.julian-hutchings_s.jpg|Julian Hutchings||Julian Hutchings))|/dotclear/public/photos/julian-hutchings.JPG][((/dotclear/public/photos/.alexandra-lovato_s.jpg|Alexandra Lovato||Alexandra Lovato))|/dotclear/public/photos/alexandra-lovato.JPG][((/dotclear/public/photos/.stephane-profit_s.jpg|Stéphane Profit||Stéphane Profit))|/dotclear/public/photos/stephane-profit.JPG]%%% %%% * __Julian Hutchings__, évangéliste du stand Talisker, Lagavulin et Caol Ila : pour instantanément vous téléporter dans une distillerie en Écosse, un poète comme on n’en fait plus…%%% * __Alexandra Lovato__, ambassadrice Ardbeg & Glenmorangie : pour vous faire participer à un safari de saveurs et de parfums, un côté sauvage (je parle de l’Ardbeg) à redécouvrir…%%% * __Stéphane Profit__, sommelier et directeur Agrappa : pour une subtile et (ré-)créative découverte des combinaisons gustatives entre un single malt et un fromage ou des fruits de la mer, un explorateur et un guide à suivre…%%% %%% __Mes dégustations__ :%%% ///html

ARDBEG Blasda 40% (lightly peated, 8ppm)
ARDBEG Corryvreckan 57,1%
ARDBEG Supernova 60,1% (sort début juin 2010)
ARDBEG Ten 10 ans 46%
ARDBEG Uigeadail 10 ans 54,2% (assemblage de fûts de 10 ans, 13 ans et de 1975)
BRORA 30 ans 53,2% n°1292 (bottled in 2009)
LAGAVULIN Special Release 12 ans 56,4% (bottled in 2008)
LAGAVULIN 16 ans 43% (dégusté avec des huîtres du Cap-Ferret)
LAGAVULIN Distillers’ Edition 1993 Double Matured 43°en fût de Pedro Ximinez (dégusté avec des huîtres du Cap-Ferret)
TALISKER 25 ans 56,9% (dégusté avec un caviar d’Aquitaine)
TALISKER 30 ans 50,7%

/// %%% __What went wrong__%%% * 19h-22h : trop court ! pas le temps de faire les whiskies irlandais, japonais ou même français !%%% * Thomas G. n’est toujours pas là !%%% %%% __Puzzles__%%% * Twitter Lionel Nallet ? ++[ici|http://twitter.com/Nallet|fr]++%%% %%% __Lessons (re-)learnt__%%% * Leçons de ppm (parts per million) avec Alexandra L.%%% * La puissance de l’Huître contre le Single Malt, un match à voir avec Stéphane P.%%% * Distillerie Ardberg rachetée et réouverte par Glenmorangie en 1997%%% %%% __Appreciations__%%% * Merci à Alexandra L., Julian H., Stéphane P., Émilie C., …%%% * Merci aux organisateurs du Whisky Live Aquitaine 2010.%%% %%%  »et rendez vous en septembre à ++[Paris|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/09/28/Retrospective-Whisky-Live-Paris-2009|fr]++ ! »%%% %%% __Feedback__%%% * Artvest : ++[« Whisky Live Bordeaux – 12 Avril »|http://artvest.6mablog.com/post/2010/05/12/Whisky-Live-Bordeaux-12-Avril|fr]++

Prioriser les features

[((/dotclear/public/photos/.dean-leffingwell_t.jpg|Dean Leffingwell|L|Dean Leffingwell))|/dotclear/public/photos/dean-leffingwell.jpg]J’ai traduit l’article ++[« Prioritizing Features »|http://scalingsoftwareagility.wordpress.com/2010/04/08/prioritizing-features/|en]++ de Dean Leffingwell. Ça a été difficile compte tenu des termes économiques utilisés mais ça reste tout de même intéressant à lire :-)%%% > Dans le dernier ++[billet|http://scalingsoftwareagility.wordpress.com/2010/04/02/estimating-features/|en]++, je décrivais un système d’estimation des features qui sera dans mon prochain ++[livre|http://scalingsoftwareagility.wordpress.com/agile-requirements-the-book/|en]++. Ce billet, prioriser les features, le complète. Ensemble, ils fournissent une stratégie raisonnable pour estimer le coût et le délai d’une feature, et une démarche systématique pour sélectionner en premier les features qui offriront la plus grande valeur ajoutée, basée sur le coût du retard. Si cela vous intéresse, vous pouvez aussi parcourir les billets de la catégorie ++[Big Picture|http://scalingsoftwareagility.wordpress.com/category/big-picture/|en]++ et la catégorie ++[Agile Requirements|http://scalingsoftwareagility.wordpress.com/category/agile-requirements/|en]++.%%% > %%% > __Introduction__%%% > %%% > Un des plus grands défis auxquels sont confrontés toutes les équipes logicielles, est de prioriser le développement et la livraison aux clients. C’est certainement un défi pour toutes les équipes agiles au début et à la fin de chaque itération, et il prend encore plus d’envergure lorsqu’il s’agit de prioriser les features à l’échelle d’un programme. Là, chaque petite décision peut avoir de gros impacts sur le coût de développement et l’opportunité de livrer rapidement de la valeur.%%% > %%% > Il y a un certain nombre de raisons pour lesquelles la priorisation reste un problème difficile :%%% > %%% > 1. Les clients sont apparemment peu enclins à prioriser les features. C’est peut-être tout simplement parce qu’ils  »veulent tout », ce qui est compréhensible ; ou peut-être qu’ils ne sont pas sûrs de ce que sont les priorités relatives ; ou peut-être qu’ils ne peuvent pas se mettre d’accord entre eux.%%% > %%% > 2. Les Product managers sont, souvent, encore plus réticents. Peut-être parce que s’ils pouvaient  »obtenir toutes les features », ils n’auraient rien à prioriser et plus important encore, ils auraient la garantie de recevoir toute la valeur finale $$Il y avait une bande dessinée Dilbert sur ce sujet. Le développeur dit au client, « s’il vous plaît dites-moi quelles sont vos priorités pour que je sache sur quoi ne pas travailler. »$$%%% > %%% > 3. Quantifier la valeur est extrêmement difficile. Certaines features sont purement et simplement « obligatoires » pour rester compétitives ou conserver des parts de marché. Comment peut-on quantifier l’impact de maintenir des parts de marché, une feature à la fois ?%%% > %%% > Pour nous aider, nous sommes souvent tenter d’estimer un retour sur investissement (~ROI) par feature, en prédisant l’augmentation probable des revenus lorsqu’une feature est disponible. Bien entendu, la détermination du ROI est très probablement une fausse science, de même qu’aucune boule de cristal ne peut prédire des revenus futurs, surtout lorsque vous vous basez sur une estimation des revenus par feature. Cette situation est aggravée par le fait que l’analyste qui fait le travail est susceptible de développer un intérêt personnel pour voir la feature développée. De plus, un product manager ou un analyste métier va probablement insister sur le ROI de ses propres features, sinon ils n’auraient pas travaillé dessus.%%% > %%% > Pourtant, en agile, le défi de la priorisation est immuable – nous admettons d’emblée que nous ne pouvons pas mettre en œuvre (ni même  »découvrir ») l’ensemble des besoins potentiels. Après tout, nous avons fixé la qualité, les ressources et le planning de livraison. Par conséquent, la seule variable d’ajustement dont nous disposons est le périmètre. Une prorisation efficace devient donc une pratique et un art obligatoire qui doivent être maîtrisés par chaque équipe agile.%%% > %%% > Bien sûr, la priorisation des exigences n’est pas un nouveau problème. Un certain nombre d’auteurs ont décrit des mécanismes raisonnables pour prioriser. Nos favoris sont :%%% > %%% > –  »Agile Estimating and Planning » (Cohn, 2006)%%% > –  »Software Requirements » (Wiegers, 1999)%%% > –  »Software by Numbers » (Deene et Cleland-Huang, 2004).%%% > %%% > Pour ceux pour qui ce sujet est potentiellement un facteur déterminant de réussite ou d’échec, nous vous préconisons aussi de prendre connaissance de ces travaux. Même si nous allons adopter une approche différente dans ce livre, il n’y a certainement pas une seule bonne façon de prioriser et les équipes bénéficieront ainsi de perspectives différentes sur ce problème unique.%%% > %%% > __Valeur / Effort en tant que ROI proxy – Une Première Approximation__ > %%% > Comme nous l’avons évoqué plus haut, nous avons traditionnellement essayé de prioriser le travail en essayant de comprendre le retour sur investissement relatif, qui est le rapport entre le rendement potentiel (la valeur) et l’effort (le coût du développement) pour une feature. Au moins, le modèle était simple :%%% > %%% > ((/dotclear/public/traductions/relative-roi.png|Relative ROI||Relative ROI))%%% > %%% > Si nous pouvions simplement établir la valeur et le coût d’une feature – sinon en termes absolus, du moins par rapport à d’autres features – alors nous aurions un moyen de prioriser fondé sur l’économie. Après tout, qui ne souhaiterait pas livrer une feature de ROI supérieur avant une feature de ROI inférieur ? Cela semble être totalement intuitif et (apparemment) du bon sens économique.%%% > %%% > __Quel est le problème avec notre ROI proxy Valeur / Effort ?__%%% > %%% > Bien que basé sur un cadre économique très complet, il s’avère que le ROI relatif (comme nous l’avons trop simplement défini ci-dessus) n’est pas un indicateur adéquat pour prioriser la valeur à livrer. Tout récemment, un point de vue plus réfléchi et plus rigoureux économiquement parlant pour prioriser la valeur à livrer ( »planification du travail » en terminologie de flux) a été exprimé dans les  »Principles of Product Development Flow » de Reinertsen (Celeritas Publishing, 2010), et que nous avons déjà présenté dans un précédent billet. Ces principes décrivent les méthodes de planification du travail basé sur les mathématiques et les principes d’économie du « lean product development ».%%% > %%% > Nous allons utiliser ces principes pour décrire une meilleure méthode de priorisation des features. En le faisant, nous allons découvrir une faille profondément enracinée dans notre hypothèse de départ – l’hypothèse selon laquelle un projet avec un grand ROI relatif devrait naturellement être prioritaire sur un projet de plus petit ROI.%%% > %%% > Au lieu de cela, nous allons comprendre la manière dont l’économie de notre programme peut être considérablement affectée par la  »planification ». Par exemple, le bénéfice potentiel pour une feature de ROI particulièrement élevé pourrait être moins sensible à un retard de calendrier qu’une feature de ROI inférieur. Dans ce cas,  »la feature de ROI inférieur devrait être développée en premier », suivie de la feature de plus grand ROI. Ce n’est pas intuitif, mais nous allons voir que cela respecte une logique économique.%%% > %%% > __La priorisation des features basée sur le coût du retard.__%%% > %%% > Puisque prioriser la valeur à livrer est le principal moteur économique, nous aurons besoin d’un modèle plus sophistiqué pour produire de meilleurs rendements. Pour construire le modèle, nous allons faire un petit détour par quelques-uns des principes fondamentaux de la théorie des files d’attente. Après tout, comme nous l’avons décrit dans un autre billet, prioriser la valeur à livrer dans le développement logiciel n’est qu’un cas particulier de la théorie des files d’attente. Ainsi, l’application de ces principes devrait créer une base solide pour la prise de décisions critiques.%%% > %%% > __Introduction au coût du retard__%%% > %%% > Comme le souligne Reinertsen, « si vous ne quantifiez qu’une seule chose, quantifiez le coût du retard » $$Principle of Product Development Flow:E3$$, donc nous devrons être en mesure d’estimer le CdR (NdT : Coût du Retard ~ CoD) dans le cadre de notre approche plus concrètement économique. (Je vous donnerai plus de détails bientôt). Heureusement, nous n’avons pas  »seulement » qu’une seule chose à quantifier, et comme nous avons déjà esquissé une stratégie d’estimation, nous serons réellement en mesure de quantifier  »deux » choses, l »’estimation de l’effort d’une feature », comme nous l’avons décrit dans le dernier billet, et le  »Coût du Retard ». Nous devrions ainsi avoir ce dont nous avons besoin.%%% > %%% > Dans « Product Development Flow », Reinertsen décrit trois méthodes pour prioriser le travail basées sur la théorie économique du Coût du Retard.%%% > %%% > __Le travail le plus rapide en premier__%%% > %%% > Lorsque le coût du retard est équivalent pour deux features, réaliser le  »travail le plus rapide » (le plus petit dans notre cas) produit les meilleurs rendements économiques, comme illustré dans la figure ci-dessous :%%% > %%% > ((/dotclear/public/traductions/shortest-job-first.png|Shortest Job First||Shortest Job First))%%% > %%% > L’impact est manifestement important : réaliser le plus petit travail a des retombées économiques  »bien meilleures » que réaliser le plus gros travail en premier. Nous arrivons donc à notre première conclusion :%%% > %%% >  »Si deux features ont le même Coût du Retard, réalisez la plus rapide d’abord. »%%% > %%% > __Le Coût du Retard le plus important en premier__%%% > %%% > Si la quantité de travail est sensiblement la même, alors la seconde approche illustre l’effet de prioriser des travaux avec le coût du retard le plus important. Encore une fois, la théorie économique est convaincante comme l’indique la figure ci-dessous.%%% > %%% > ((/dotclear/public/traductions/high-delay-cost-first.png|High Delay Cost First||High Delay Cost First))%%% > %%% > Bien sûr, cela a un sens intuitif dans ce cas aussi (même si l’intuition ne nous a pas toujours conduit à la conclusion correcte). Car si le Coût du Retard est une approximation de la valeur, et qu’une feature a plus de valeur qu’une autre et que l’on doit produire le même effort, alors on doit réaliser la première; nous le savions déjà avec notre ROI proxy Valeur / Effort. Nous avons donc notre seconde conclusion :%%% > %%% >  »Si deux features ont le même effort, réalisez le travail avec le coût du retard le plus important ».%%% > %%% > __Le travail pondéré le plus rapide en premier__%%% > %%% > Maintenant que nous avons vu l’impact, nous comprenons que ces deux conclusions sont tout à fait raisonnables lorsque la taille ou le coût du retard des deux features sont comparables. Bien sûr, nous ne sommes pas ici en train de fabriquer des gadgets. Le coût du retard et l’effort de développement des différentes features logicielles sont très variables. De plus, ils ont souvent de faibles voire aucunes corrélations (c’est-à-dire que certains travaux à forte valeur ajoutée sont faciles à faire et d’autres sont difficiles); c’est la même chose pour un logiciel. Dans le cas où le coût du retard et l’effort pour une feature sont très variables, alors la meilleure rentabilité est atteinte lorsque nous les développons dans l’ordre du  »Travail pondéré le plus rapide en premier ».%%% > %%% > Dans ce cas, nous calculons le poids de la priorité relative d’un travail en divisant le coût du retard par l’estimation de sa taille. Si les coûts du retard et les tailles varient beaucoup, alors les écarts de rendement peuvent être énormes, comme l’illustre la figure ci-dessous.%%% > %%% > ((/dotclear/public/traductions/weighted-shortest-job-first.png|Weighted Shortest Job First||Weighted Shortest Job First))%%% > %%% > Voilà donc l’approche que nous privilégions pour le développement de logiciels :%%% > %%% >  »Si deux features sont de tailles et de coûts du retard différents, traitez la feature pondérée la plus rapide en premier. »%%% > %%% > __Estimer le Coût du Retard__%%% > %%% > Cela semble être un modèle de décision prometteur pour la priorisation des features. Il est basé sur de solides théories économiques et est tout à fait rationnel une fois que vous le comprenez. Toutefois, nous avons exclu un petit élément – comment fait-on pour calculer le coût du retard pour une feature ? Si nous n’y prenons pas garde, nous pourrions tomber dans le piège que nous avons mentionné plus haut – passer trop de temps à calculer des estimations de la taille des features – ainsi qu’à calculer le coût du retard – pourrait conduire à trop de gaspillage et à un risque de partialité de la part de ceux qui font le travail. Nous avons donc besoin de quelque chose de plus simple.%%% > %%% > Nous suggérons que la coût du retard – si essentiel à nos critères de décision – soit à son tour, le regroupement de trois attributs d’une feature, dont chacun peut être estimé assez facilement, si on la compare à d’autres features. Ce sont la  »valeur utilisateur », la  »valeur temps », et la  »valeur découverte de l’information ».%%% > %%% > – la  »valeur utilisateur » est tout simplement la  »valeur potentielle » de la feature aux yeux de l’utilisateur. Les product managers ont souvent une bonne perception de la valeur relative d’une feature, (« ils préfèrent ceci plutôt que cela ») même quand il est impossible de déterminer une valeur absolue. Et puisque nous sommes intéressés par cette forme de priorisation, une valeur utilisateur relative est ce qu’il nous faut.%%% > %%% > – la  »valeur temps » est une autre estimation relative; basée sur la façon dont la valeur utilisateur décroît au fil du temps. De nombreuses features offrent une meilleure valeur quand elles sont livrées au début, discriminantes sur leurs marchés, et de moindre valeur lorsque les features sont banalisées. Dans certains cas, la valeur temps est au mieux modeste (« mettre en œuvre la norme d’ergonomie avec l’image de marque de la nouvelle entreprise »). Dans d’autres cas, la valeur temps est extrême (« mettre en œuvre le nouveau protocole de test avant la prochaine saison des achats de rentrée scolaire »), et bien sûr il y a aussi les entre deux (« supporter les serveurs 64 bits »).%%% > %%% > – la  »valeur découverte de l’information » ajoute une dernière dimension – qui témoigne du fait que nous faisons réellement de la R&D logicielle. Notre monde comporte à la fois des risques et des opportunités. Certaines features sont plus ou moins à valeur ajoutée pour nous selon qu’elles nous aident à débloquer ces mystères, atténuer les risques et à exploiter de nouvelles opportunités. Par exemple, faire passer l’authentification des utilisateurs par un nouveau service web, pourrait être un effort risqué pour un fournisseur de logiciels qui ne l’a jamais fait par le passé, mais imaginez les opportunités que cette nouvelle feature pourrait générer.%%% > %%% > Avec ces trois critères de valeur, la valeur utilisateur, la valeur temps et la valeur découverte de l’information, nous avons les dernières pièces de notre puzzle sur la priorisation.%%% > %%% > __Matrice d’évaluation de la priorisation des features__%%% > %%% > Maintenant, nous pouvons intégrer toutes ces informations dans une matrice d’évaluation que nous pouvons utiliser pour établir les priorités relatives d’une feature, et qui se base à la fois sur l’effort et le coût du retard. Un exemple est donné dans le tableau ci-dessous :%%% > %%% > ((/dotclear/public/traductions/evaluation-matrix.png|Evaluation Matrix||Evaluation Matrix))%%% > Légende :%%% > Échelle de pondération : 10 le plus haut et 1 le plus bas%%% > La pondération est le rapport entre le Coût total du retard et l’Effort%%% > %%% > Dans notre exemple, il est intéressant de noter que la Feature B – le travail avec la plus haute valeur utilisateur (8)  »et » la feature de plus grand effort (1.3=8/6) – est en réalité le travail qui a la pondération la  »plus faible » et qu’elle devrait donc être développée en  »dernier ». La feature qui a la valeur utilisateur la plus faible (Feature 1) est en réalité celle qui génère le  »meilleur » retour sur investissement lorsqu’elle est développée  »en premier ». Ne vous fiez pas à votre intuition ! %%% > %%% > __Toutes les priorisations sont locales et temporelles__%%% > %%% > Reinertsen a également signalé une autre subtile implication de la planification par le « travail pondéré le plus rapide en premier ». La priorité devrait être basée sur le coût du retard, qui est une propriété  »globale » de la feature, et l’effort, qui est une propriété  »locale » de l’équipe qui développe la feature. En d’autres termes, un travail avec une valeur relative faible peut exiger peu de ressources d’une équipe donnée, et peut donc par conséquent être développée avant une autre feature de plus grande priorité, si cette feature exige davantage de ressources pour cette équipe. Cela signifie que toutes les priorités sont par nature locales $$Principle of Product Development Flow:F18$$.%%% > %%% > Cela va parfois à l’encontre de la façon dont nous faisons les choses, par exemple lorsqu’une Direction fixe une priorité globalement pour un projet et qui doit être appliquée dans toutes les équipes. Dans ce cas, une tâche moins prioritaire pour un projet de haute priorité peut avoir préséance sur une tâche prioritaire pour une feature de priorité moindre. Et la disponibilité des ressources limitées n’entrent même pas dans l’équation. Nous voyons aujourd’hui que cette approche n’a tout simplement pas de sens économique.%%% > %%% > En outre, nous constatons que notre modèle est très sensible à l’élément temps –  »les priorités changent rapidement à l’approche des échéances ». Par exemple : « développer le nouveau protocole de test avant la prochaine saison des achats de rentrée scolaire » pourrait avoir une valeur temps de « 1 à 2 » en hiver avant le début de l’année scolaire prochaine, mais pourrait facilement monter à « 10 » en Mai de l’année suivante.%%% > %%% > On peut tirer une conclusion de ce qui précède, à savoir que les priorités doivent être déterminées au niveau local, et le plus tard possible dans la prise de responsabilité. C’est le moment où nous pouvons le mieux évaluer le coût du retard ainsi que les ressources disponibles pour travailler sur la feature.%%% > %%% > Heureusement, dans notre modèle, nous priorisons les features lors de chaque planification de Release. Par conséquent, la cadence établie pour notre release nous sera très utile ici, tant que nous prenons le temps de  »revoir les priorités » à chaque planification.%%% > %%% > Quand nous faisons cela, nous pouvons être sûrs que nos priorités sont à jour, qu’elles tiennent bien compte de la disponibilité réelle des ressources et du coût du retard réel, tout en étant fondée sur de solides fondamentaux économiques.%%% > %%% > __Définir la valeur discriminante – le Modèle de Kano de la Satisfaction Client__%%% > %%% > Avec ses collègues, Noriaki Kano, un expert dans le domaine de la gestion de la qualité et la satisfaction client, a développé un modèle pour la satisfaction client qui remettait en cause de nombreuses croyances traditionnelles. Plus précisément, le modèle de Kano conteste l’idée que la satisfaction client est atteinte en équilibrant les investissements à travers les divers attributs d’un produit ou d’un service. Au contraire, la satisfaction du client peut être optimisé en mettant l’accent sur les  »features discriminantes », ces « excitateurs » et « attracteurs » qui augmentent la satisfaction et la fidélité des clients au-delà de ce que demanderait proportionnellement un investissement. Le modèle de Kano est illustré dans la figure ci-dessous :%%% > %%% > ((/dotclear/public/traductions/kano-model.png|Kano Model||Kano Model))%%% > %%% > Le modèle illustre trois types de features :%%% > %%% > – Features fondamentales (obligatoires) – des features qui doivent être présentes pour avoir une solution viable.%%% > – Features linéaires – features pour lesquelles l’investissement est directement proportionnel au résultat. Plus vous investissez, plus la satisfaction est grande.%%% > – Excitateurs et Attracteurs. Ce sont des features qui différencient la solution de la concurrence. Ils fournissent les plus grandes opportunités de satisfaction et fidélité de la part du client.%%% > %%% > L’idée principale du modèle de Kano est la position et la forme des courbes inférieure et supérieure.%%% > %%% > La forme de la courbe de  »base » est révélatrice. Jusqu’à ce qu’une feature soit simplement « présente », l’investissement est proportionnel au résultat, mais la satisfaction reste faible jusqu’à ce qu’un seuil soit atteint. Par la suite, cependant, les investissements supplémentaires produisent moins de résultat proportionnellement. Le point central de cette courbe donne lieu à ce qui est souvent décrit comme la Minimum Marketable Feature (MMF). En d’autres termes, pour que la solution soit considérée comme viable, elle doit contenir l’ensemble des MMFs. Toutefois, l’amélioration d’une MMF ne produira pas un résultat proportionnel.%%% > %%% > La position et la forme de la courbe  »excitateurs et attracteurs » racontent le contraire. Parce que ces features sont uniques, irrésistibles et discriminantes, même un petit investissement (la zone à gauche) suscite toujours l’intérêt du client et une satisfaction potentielle. Des investissements supplémentaires produisent encore plus, et un investissement proportionnellement important produit une satisfaction encore plus élevée. C’est là où nous disposons du meilleur effet de levier pour notre investissement.%%% > %%% > __Prioriser les Features selon leurs Valeurs Discriminantes__%%% > %%% > Étant donné que nous avons déjà décrit un modèle de priorisation à part entière avec le « travail pondéré le plus rapide en premier », la question se pose de savoir quels sont les avantages supplémentaires que nous pouvons tirer de la pensée de Kano ? Il y a trois notions stratégiques à garder :%%% > %%% > Premièrement, lorsque les features sont déjà en concurrence sur un marché existant, les équipes doivent placer une valeur utilisateur relativement élevée (et donc un coût du retard relativement élevé) sur les features nécessaires pour atteindre un niveau équivalent  »minimal ». Cela nous conduit à la règle n°1:%%% > %%% >  »Règle n°1 de la Valeur Discriminante – Investir dans des MMFs, mais ne jamais surinvestir dans une feature qui est déjà banalisée. »%%% > %%% > Par la suite, l’orientation stratégique devrait nous amener à accorder une plus grande valeur utilisateur aux  »features discriminantes » – celles qui vont « exciter et attirer » les utilisateurs, celles pour lesquelles des solutions compétitives n’existent pas, et celles pour lesquelles un investissement supplémentaire produit un résultat non linéaire. Ce qui nous amène à la règle n°2 :%%% > %%% >  »Règle n°2 de la Valeur Discriminante – Stimuler l’innovation en ayant le courage d’investir dans les « excitateurs et attracteurs ». »%%% > %%% > Enfin et plus subtilement, quand nous sommes forcés de nous engager dans des guerres de features avec des concurrents qui en disposent peut-être déjà,  »il n’est peut être pas raisonnable de mettre tous nos investissements dans les MMFs ». Après tout, nos concurrents vont aussi continuer à investir; qu’est ce qui nous fait penser que nous pouvons rattraper le retard ? Au lieu de cela, il peut être préférable de se concentrer sur une catégorie restreinte de MMFs et, au contraire, d’investir un certain montant sur les « excitateurs » –  »même si nous n’avons pas atteint l’équivalence complète sur les features fondamentales ».%%% > %%% > L’expérience a montré que les clients peuvent être relativement patients avec les développeurs quand a) ils peuvent raisonnablement anticiper la date d’apparition des MMFs adéquates et b) voir se concrétiser la promesse de valeur discriminante des « excitateurs » que l’équipe traite en premier dans le backlog. Cela nous amène à notre troisième et dernière règle de priorisation des features :%%% > %%% >  »Règle n°3 de la Valeur Discriminante – Si les ressources ne le permettent pas et que vous ne pouvez pas rivaliser avec les règles actuelles du jeu, changez le jeu. »%%% > %%% > __ »Résumé »__%%% > %%% > Dans ce billet, nous avons fourni une méthode pour prioriser les fonctionnalités basées sur un Coût du Retard pondéré. Ce n’est pas si différent des modèles antérieurs, et elle intègre des attributs d’estimation de taille (coût), de rendement potentiel et d’ajustements pour risques (découverte de l’information). Nous avons également décrit le modèle de Kano qui nous a conduit à ajuster de façon appropriée nos investissements dans des « excitateurs et attracteurs ». Ce n’est peut être que du bon sens, ou peut-être du bon sens étayé par les réelles, mais subtiles, théories économiques sur les flux de développement d’un produit.%%% > %%% > Vos commentaires sont les bienvenus.%%%  »Traduction référencée dans le wiki ++[Traductions agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/start|fr]++ »%%% %%% __Feedback :__%%% * Blog People In Action : ++[« Notre revue de presse (13/04/2010) »|http://blog.piaction.com/2010/04/people-in-action-revue-de-presse-13042010/|fr]++%%% %%%

Emmanuel is back

((/dotclear/public/./.emmanuel_chenu_t.jpg|Emmanuel Chenu|L|Emmanuel Chenu))Ça y est, Emmanuel fait son come back ! ça faisait un moment que j’attendais qu’il se remette à (nous) écrire sur son blog. Le billet d’aujourd’hui : ++[« UN BON CODE… »|http://emmanuelchenu.blogspot.com/2010/04/un-bon-code.html|fr]++. La suite ! La suite !

5S

[((/dotclear/public/./.5S_t.jpg|5S|L|5S, nov 2008))|/dotclear/public/5S.gif]La méthode des 5 « S », qui tire son origine de la première lettre de chacune des cinq opérations, est une technique de management japonaise.%%% %%% Elle est tirée du Système de Production Toyota (TPS). Elle repose sur cinq principes simples :%%% * Seiri 整理(せいり)%%% * Seiton 整頓(せいとん)%%% * Seiso 清掃(せいそう)%%% * Seiketsu 清潔(せいけつ)%%% * Shitsuke 躾(しつけ)%%% %%% Cette démarche a été traduite en français par le mot ORDRE qui signifie :%%% * Ordonner/Débarrasser (ou plus littéralement ôter l’inutile)%%% * Ranger%%% * Dépoussiérer/Nettoyer, Découvrir des anomalies%%% * Rendre évident/Maintenir propre%%% * Être rigoureux.%%% %%% ++Carte heuristique de la méthode des 5 « S » disponible sur [Wikipédia |http://fr.wikipedia.org/wiki/5S|fr] :++%%% %%% ((/dotclear/public/Carte_5S.png|Carte heuristique des 5 « S » – source Wikipédia||Carte heuristique des 5 « S » – source Wikipédia))

Développement durable agile ?

Aujourd’hui, j’ai encore été destinataire d’une communication prônant la mise en œuvre d’une « Politique de développement durable » dans l’entreprise. J’aimerais aussi de temps en temps qu’on me parle de « Politique de développement itératif avec un rythme durable » !%%% %%% Tiens, ça m’a rappelé que j’ai rencontré un  »géoécologue » lors du ++[Scrum Café bordelais du 15 décembre 2009|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/12/15/Retrospective-Scrum-Cafe-Bordeaux-du-15-decembre-2009|fr]++. C’est vrai que Scrum ne s’applique pas uniquement au monde de l’IT.%%% %%% Du coup j’ai fait une recherche rapide sur Internet… et là je tombe sur ++[« Le blog de l’Eco Facilitateur »|http://ecofacilitateur.wordpress.com/2009/09/16/eco-facilitation-et-lagilite/|fr]++ avec ce slide où l’on reconnaît clairement le processus Scrum :%%% %%% ((/dotclear/public/eco-facilitation.png|Eco Facilitation et Agilité||Eco Facilitation et Agilité))

Le Modèle de la Cascade

[((/dotclear/public/traductions/.waterfall_escher_s.jpg|Waterfall by Escher|L|Waterfall by Escher))|/dotclear/public/traductions/waterfall_escher.jpg]Lors de la ++[journée « Embarquez Agile ! » du 18 mars dernier|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/03/18/Retrospective-Embarquez-Agile-le-18-mars|fr]++, Pascal Fortin (Thales Avionics) a fait référence à l’article original de Winston W. Royce datant de 1970 : ++[« Managing the development of large software systems »|http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf|en]++. Ça m’a mis la puce à l’oreille ;-)%%% %%% Même s’il n’a pas du tout utilisé ce terme dans son article, W. W. Royce a été le premier à décrire le modèle de la cascade (~waterfall). Je dois avouer que l’article est extrêmement intéressant et que l’auteur pose très bien le problème dans le contexte de l’époque. Ce qui m’a étonné c’est que dès le départ, il présente sa réflexion comme personnelle, il s’agit avant tout d’une démarche humble et donc pas du tout d’une présentation d’un état de l’art. Il reconnaît que ce modèle ne peut être appliqué tel quel et comporte des risques inévitables. Il présente donc différents axes d’amélioration comme par exemple de réaliser deux versions (une version pilote d’abord) avant de livrer le produit final au client, donc une cascade en 2 passes !%%% %%% La suite de l’histoire vous la connaissez avec le Département de la Défense américain (DoD STD 2167 en 1985) qui déploie et impose ce modèle (sauf que ce n’est plus qu’une cascade en 1 passe !) en tant que standard sur tous ses projets informatiques militaires, les dérivés tels que le cycle en V qui préconise 2 équipes indépendantes pour la réalisation et la validation des produits (déjà recommandé dans l’article de W. W. Royce !), le cycle en W qui met en œuvre un premier cycle en V pour la réalisation du pilote de la solution avant de généraliser la solution lors d’un deuxième cycle en V après un temps d’utilisation du pilote (déjà recommandé dans l’article de W. W. Royce !), etc.%%% %%% Si la lecture de cet article vous intéresse, je l’ai traduit en français : vous le trouverez ++[ici|http://www.fabrice-aimetti.fr/dotclear/public/traductions/waterfall-FR.pdf|fr]++ ou sur le ++[wiki « Traductions agiles »|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/start|fr]++.%%% %%% N’hésitez pas à laisser un commentaire sur le blog…%%% %%% __Feedback :__%%% * ++[« La cascade, retour aux sources »|http://blog.institut-agile.fr/2010/10/la-cascade-retour-aux-sources.html]++ par Laurent Bossavit sur l’Institut Agile%%%

Séminaire sur les méthodes agiles à l’IUT du Limousin

((/dotclear/public/logos/logo-iut-limousin.gif|IUT du Limousin|L|IUT du Limousin))Le 26 février dernier, un séminaire agile était organisé à l’IUT du Limousin. ++[Claude Aubry|http://www.aubryconseil.com/post/Presentation-de-Scrum-a-Limoges|fr]++ et ++[Thierry Cros|http://etreagile.thierrycros.net/home/index.php?post/2010/04/05/S%C3%A9minaire-agile-de-Limoges-26-f%C3%A9vier-2010|fr]++ étaient parmi les intervenants. Les supports de présentation et les vidéos des conférences sont disponibles sur le ++[site de l’IUT du Limousin|http://www.iut.unilim.fr/conferences-informatique/videos-supports.html|fr]++.%%% %%% Je vous conseille de ne pas zapper le super retour d’expérience de ++[Bénédicte Taillebois|http://fr.linkedin.com/pub/b%C3%A9n%C3%A9dicte-taillebois/5/b68/38b|fr]++, Responsable des Études Informatiques chez ++[Astria|http://www.astria.com/|fr]++.

Yet Another Agile Laboratory

J’ai récemment eu le plaisir de rencontrer les deux associés de la société bordelaise ++[Yaal.fr|http://yaal.fr/|fr]++ : ++[Colin Garriga-Salaün|http://fr.linkedin.com/in/colingarrigasalaun|fr]++ et ++[Arthur Ledard|http://www.viadeo.com/fr/profile/arthur.ledard|fr]++.%%% %%% Si vous souhaitez faire réaliser vos projets informatiques innovants par de jeunes professionnels passionnés qui maximisent leurs chances de succès grâce aux méthodes Lean et eXtreme Programming alors ++[contactez les|mailto:contact@yaal.fr]++, ils vous surprendront !%%% %%% [((/dotclear/public/logos/.YAAL_m.jpg|Cartes de visite Yaal.fr||Cartes de visite Yaal.fr))|/dotclear/public/logos/YAAL.png]%%% %%% Feedback :%%% ///html
Pépinière Eco-Creative ///