Livrer tôt est différent de maximiser le retour sur investissement

((/dotclear/public/photos/.MattiasSkarin_sq.jpg|Mattias Skarin|L|Mattias Skarin))J’ai traduit le billet de __Mattias Skarin__ : ++[« Early release is not same as maximizing your return »|http://blog.crisp.se/mattiasskarin/2011/04/22/1303460651193.html]++.%%% > N’avez-vous jamais vu une fonctionnalité très pratique dans un logiciel en vous demandant : « sensas ! mais qui a eu du temps pour faire  »ça » ? »%%% > %%% > Il arrive de temps à autre que je rencontre des représentants du métier qui me disent combien ils sont heureux que leurs équipes, une fois passées à l’Agile, soient maintenant capables de livrer le logiciel à un rythme régulier : « Avant, ils donnaient l’impression de ne jamais avoir fini, il restait toujours quelque chose à faire ».%%% > %%% > Bien que ce soit un grand bond en avant, penchons-nous sur certains des dangers d’étendre cette pratique à toutes les fonctionnalités de votre système.%%% > %%% > Vous serez probablement d’accord pour visualiser à peu près de la manière suivante la valeur d’une fonctionnalité par rapport à l’effort dépensé…%%% > [((/dotclear/public/traductions/.featurecompletionovertime_m.jpg|Feature completion over time||Feature completion over time))|/dotclear/public/traductions/featurecompletionovertime.PNG]%%% > Dans ce cas, il est parfaitement logique de livrer la fonctionnalité dans une fenêtre où la valeur peut être maximisée :%%% > [((/dotclear/public/traductions/.roiwindow_m.jpg|ROI window||ROI window))|/dotclear/public/traductions/roiwindow.PNG]%%% > Mais il y a une chose qui manque… Si nous essayons de déployer la fonction sur une population importante, le rendement attendu a probablement la forme d’une courbe exponentielle, qui à un certain point, fait que la fonctionnalité a atteint suffisamment d’ampleur pour être capable de se propager à l’ensemble des utilisateurs. Si l’on ajoute cette courbe au-dessus des autres :%%% > [((/dotclear/public/traductions/.featurevsexpectedreturn_m.jpg|Feature vs expected return||Feature vs expected return))|/dotclear/public/traductions/featurevsexpectedreturn.PNG]%%% > Nous constatons alors que livrer la fonctionnalité en fonction de notre cadence normale va court-circuiter nos retombées économiques et minimiser notre retour sur investissement.%%% > %%% > Conscient de cela, je préconise de ne pas considérer toutes vos fonctionnalités de la même manière. Beaucoup d’entre elles tireront partie d’être livrées selon un cycle régulier de livraison, mais pas toutes si nous sommes intéressés par maximiser notre rendement économique.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Démarrer en Kanban

((/dotclear/public/photos/.Tomas_Bjorkholm_sq.jpg|Tomas Bjorkholm|L|Tomas Bjorkholm))J’ai traduit cet article de __Tomas Björkholm__ : ++[« Kanban Kick-start »|http://blog.crisp.se/tomasbjorkholm/2011/04/21/1303410403236.html|en]++.%%% %%% Vous le trouverez ++[ici|/dotclear/public/traductions/demarrer-en-kanban]++ ou sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start]++.%%%

Sélection d’un projet Agile dans un portefeuille de projets

((/dotclear/public/photos/.kane-mar_sq.jpg|Kane Mar|L|Kane Mar))J’ai traduit la pièce jointe attachée au billet de Kane Mar$$About the author: Kane Mar is an international Scrum Coach and Trainer, based in Australia. He has trained over 1000 people in over 30 countries, and worked with large multinational corporations such as Microsoft, Oracle, Telstra, and Capital One. His blog on Scrum and software can be found here: ++[Scrumology Pty Ltd|http://scrumology.com/|en]++$$ : ++[« Agile project selection from a portfolio of projects »|http://kanemar.com/2005/12/13/agile-project-selection-from-a-portfolio-of-projects/|en]++. Il s’agit d’une grille de notation permettant d’évaluer l’aptitude d’un projet à être un bon pilote pour une démarche agile.%%% %%% Vous trouverez la traduction directement sur ++[ce lien|/dotclear/public/traductions/Agile-project-selection-FR.pdf]++ ou sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start]++.

Comment choisir le projet pilote idéal ?

((/dotclear/public/./.Mike_Cohn_sq.jpg|Mike Cohn|L|Mike Cohn))((/dotclear/public/logos/.mountain_goat_software_logo_sq.jpg|Mountain Goat Software|R|Mountain Goat Software))J’ai traduit ce célèbre billet de __Mike Cohn__ : ++[« Four Attributes Of The Ideal Pilot Project »|http://blog.mountaingoatsoftware.com/four-attributes-of-the-ideal-pilot-project]++, je devrais plutôt dire célèbre schéma que j’ai d’ailleurs revu dans la présentation de Romain Couturier (++[innovation gamer|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/03/31/Retrospective-Master-Class-Innovation-Games-du-29-au-30-mars-2011]++) : ++[« Transition agile & Accompagnement au changement »|http://www.slideshare.net/calton13/transition-agile-accompagnement-au-changement]++.%%% > Choisir le bon projet pilote peut se révéler difficile. Jeff Honious, vice-président responsable de l’innovation chez Reed Elsevier, a mené la transition à Scrum de son entreprise. Son collègue Jonathan Clark et lui ++[ont retracé leur combat|http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&tp=&arnumber=1667581&isnumber=34909|en]++ pour sélectionner le bon projet pilote.%%% > %%% >  »Trouver le bon projet a été la tâche la plus difficile et critique. Nous avions besoin d’un projet significatif que les gens ne rejetteraient pas comme étant un cas particulier, déjà nous ne voulions pas d’un projet visant à répondre à tous les défis possibles, trop de choses dépendaient de son succès. »%%% > %%% > Tous les projets ne font pas forcément l’affaire pour être le premier. Le projet pilote idéal se situe, comme l’indique la figure ci-dessous, à la rencontre de la bonne taille de projet, la bonne durée du projet, la bonne importance du projet et l’engagement du sponsor côté métier. Vous constaterez peut-être qu’il est impossible d’identifier le projet pilote « parfait ». Effectivement. Prenez en compte les projets que vous avez et faites les bons compromis entre les quatre facteurs présentés dans la figure ci-dessous. Il est de loin préférable de choisir un projet sur le point de démarrer et de vous lancer que de tout reporter de six mois ou plus en attendant que le projet pilote idéal se présente de lui-même.%%% > %%% > [((/dotclear/public/traductions/.pickproject-fr_m.jpg|Choisissez le bon projet||Choisissez le bon projet))|/dotclear/public/traductions/pickproject-fr.jpg]%%% > %%% > __Durée :__%%% > Si vous sélectionnez un projet qui est trop court, les sceptiques diront que Scrum ne fonctionne que sur des projets courts. Dans le même temps, si vous sélectionnez un projet qui est trop long, vous risquez de ne pas pouvoir déclarer le succès du projet avant qu’il ne soit terminé. De nombreux projets gérés de façon traditionnelle prétendent être sur la bonne piste avec un calendrier de 9 à 12 mois, mais sont finalement hors budget et hors délai… un projet Scrum proclamant la même chose ne sera donc pas très convaincant.%%% > Ce que je trouve préférable, c’est de choisir un projet dont la durée est à la moitié de ce qu’il est coutume de faire dans l’organisation. Idéalement, cela se situe souvent autour de trois ou quatre mois. Cela laisse ainsi beaucoup de temps à une équipe pour commencer à obtenir de bons résultats lors des sprints, à y prendre plaisir et à voir les avantages que cela apporte pour eux et pour le produit. Un projet de trois ou quatre mois est habituellement suffisant pour déclarer que Scrum mènera à un succès similaire sur des projets plus longs.%%% > %%% > __Taille :__%%% > Sélectionnez un projet qui peut être démarré avec une équipe dont les membres sont tous situés au même endroit, si possible. Commencez avec une seule équipe, même si le projet pilote devra s’agrandir pour inclure plus d’équipes. Essayez de trouver un projet pilote qui ne mettra pas en jeu plus de cinq ou six équipes, même si ces projets sont monnaie courante dans votre organisation. Non seulement vous aurez les yeux plus gros que le ventre en essayant tout de suite de coordonner les travaux entre les équipes Scrum, mais en plus vous n’aurez probablement pas le temps de passer d’une à cinq équipes sur un projet qui devra être terminé en trois ou quatre mois.%%% > %%% > __Importance :__%%% > Il peut être tentant de choisir un projet pas vraiment important et présentant un faible risque. Si les choses vont mal, vous n’aurez pas perdu grand-chose. Et les gens ne remarqueront peut-être même pas l’échec d’un projet de faible importance. Ne cédez pas à cette tentation. Choisissez plutôt un projet important. Un projet peu important n’attirera pas suffisamment l’attention du reste de l’organisation. En outre, certaines des choses nécessaires à la transition d’une équipe Scrum sont difficiles ; si le projet n’est pas important, les gens ne feront pas tout ce que l’on exige d’eux. Jim Highsmith, l’un des premiers agilistes, inventeur du processus Adaptive Software Development, a donné des conseils à ce sujet dans son livre ++[Agile Software Development Ecosystems|http://www.amazon.com/dp/0201760436/ref=cm_sw_su_dp|en]++.%%% > %%% >  »Ne commencez pas avec un premier « projet d’apprentissage » ayant une importance marginale. Démarrez sur un projet qui soit absolument essentiel pour votre entreprise, sinon cela se révélèra trop dur de mettre en œuvre toutes les choses difficiles exigées par Scrum. »%%% > %%% > __Engagement d’un sponsor métier :__%%% > L’adoption de Scrum nécessite des changements du côté métier de l’équation du développement d’un produit, pas uniquement du côté technique. Disposer de quelqu’un du métier qui a le temps et l’envie de travailler avec l’équipe est essentiel. Un sponsor métier engagé peut aider l’équipe si elle en a besoin pour secouer les individus et départements ancrés dans les processus métiers. En plus il n’y a pas plus utile pour promouvoir la réussite du projet qu’un sponsor métier qui a obtenu ce qu’il avait demandé. Un sponsor métier racontant à un autre que, récemment, un projet s’est mis à Scrum et a livré davantage de valeur que n’importe quel projet antérieur fera des merveilles pour que d’autres sponsors demandent à leurs propres équipes d’également essayer la nouvelle approche.%%% > %%% > __Pour finir, les gens :__%%% > Je n’oublie pas l’importance des personnes impliquées dans la réussite d’un projet pilote. Les personnes impliquées sont, bien sûr, le facteur le plus important dans la réussite de tout projet. Les conseils fournis dans ce billet supposent que vous avez déjà choisi la bonne équipe et que vous cherchez maintenant à les positionner sur le meilleur projet pilote. Des conseils supplémentaires sur la façon de choisir les personnes qui formeront des équipes pilotes sont donnés dans le paragraphe « Sélectionnez une Equipe Pilote » du chapitre « 5. Vos Premiers Projets » de mon livre ++[« Succeeding with Agile »|http://www.mountaingoatsoftware.com/books/7–succeeding-with-agile]++.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Philosophie Lean : des stocks, de l’eau, un navire et des rochers

J’ai traduit ce billet de __Greg Pawlik__ : ++[« Lean Philosophy | Idea behind »|http://www.thetoyotasystem.com/lean_concepts/lean_philosophy_idea_behind.php]++.%%% > Shigeo Shingo, l’un des principaux experts du Système de Production Toyota$$NdT : TPS = Totyota Production System$$, a utilisé une métaphore très intéressante qui montre de quoi traite le Système de Production Toyota. C’est simple. Il y a seulement trois éléments :%%% > %%% > ((/dotclear/public/traductions/.shipanalogy2_s.jpg|Métaphore du bateau 2||Métaphore du bateau 2))%%% >  »… une entreprise c’est comme un navire flottant sur ​​l’océan des stocks »%%% > %%% > – un __navire__ qui représente l’entreprise, par exemple une usine,%%% > %%% > – une __eau__ qui ++coûte beaucoup d’argent++ (pour les besoins de la métaphore) et représentant les stocks,%%% > %%% > – des __rochers__ représentant toutes sortes de gaspillages (par exemple : la surproduction, des travailleurs qui attendent le matériel dont ils ont besoin, le transport, les défauts, les pannes de machines, …).%%% > %%% > Dans une  »usine classique », la façon dont les rochers sont gérés est la suivante : beaucoup d’eau est déversée pour les recouvrir. « Le navire doit naviguer coûte que coûte », ainsi pense un gestionnaire classique. « Je dois empêcher à tout prix que l’usine s’arrête ». Pourquoi ? « Parce que ça coûte cher ! Déverser davantage d’eau coûtera moins cher que de heurter les rochers et d’arrêter le navire ! ». Et c’est vrai. Tout comme il est vrai que choisir de faire le plein quelques kilomètres plus tôt vous coûtera peut-être moins cher et que payer pour le réglage de votre voiture ou installer des feux de circulation est plus cher que de traverser prudemment une rue passante sans allumer vos feux. En d’autres termes, ajouter plus d’eau peut être une solution moins coûteuse, mais ce n’est qu’une solution à court terme, et cela ne résoudra pas réellement le problème. Lorsque l’eau s’évaporera, les rochers referont surface et de l’eau devra de nouveau être achetée pour les recouvrir.%%% > %%% > ((/dotclear/public/traductions/.shipanalogy1_s.jpg|Métaphore du bateau 1||Métaphore du bateau 1))%%% >  »… à court terme, ajouter plus de stock peut résoudre les problèmes »%%% > %%% > Dans une  »entreprise fonctionnant en harmonie avec la Philosophie Lean », chaque fois que le navire heurte un rocher, il s’agit d’un moment heureux car il présente une nouvelle opportunité pour éliminer un autre problème. Une fois que le rocher est éliminé, il ne sera plus jamais heurté. Et en plus, un peu d’eau peut être pompée (garder à l’esprit qu’elle est précieuse, qu’elle peut être revendue ou du moins qu’il n’y aura plus besoin d’en acheter pendant un certain laps de temps).%%% > %%% > ((/dotclear/public/traductions/.shipanalogy3_s.jpg|Métaphore du bateau 3||Métaphore du bateau 3))%%% >  »… éliminer les obstacles réels est bien le sujet d’étude de la Pensée Lean$$NdT : Lean Thinking$$ »%%% > %%% > Donc, si le __Système de Production Toyota__ est un nouveau concept pour vous, n’en ayez pas peur parce qu’il est simple. Tout ce que nous faisons c’est enlever les rochers et nous moquer de nos concurrents qui sont en train de payer pour davantage d’eau, pendant ce temps-là nous nous asseyons et nous nous posons la question suivante : « Puisque nous n’avons plus à payer pour tout ce stock, ne devrions-nous pas réduire nos prix ou nous offrir une prime ? ». Le Système de Production Toyota a du sens : éliminer les problèmes réels est beaucoup plus logique que de les cacher, ce qui à long terme peut devenir extrêmement coûteux.%%% > %%% > ((/dotclear/public/traductions/.shipanalogy4_s.jpg|Métaphore du bateau 4||Métaphore du bateau 4))%%% >  »… le Système de Production Toyota augmente la productivité tout en réduisant les coûts »%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Choisir le bon projet pilote pour l’Agile

J’ai traduit ce billet de __Roman Pichler__ : ++[« Choosing The Right Agile Pilot Project »|http://www.romanpichler.com/blog/agile-product-management/choosing-the-right-agile-pilot-project/]++.%%% > [((/dotclear/public/traductions/.iStock_000012210065Small_t.jpg|Choisir…||Choisir…))|/dotclear/public/traductions/iStock_000012210065Small.jpg]%%% > « Quel projet est le mieux placé pour être piloté avec Scrum ? » est la question qu’on me pose régulièrement dans mes ateliers et formations. Bien qu’il soit toujours important d’examiner attentivement la situation spécifique d’une organisation, j’ai trouvé les six critères suivants utiles pour sélectionner le bon projet pilote pour l’agile :%%% > %%% > 1. __Petit :__ Votre projet pilote doit être de petite taille et composé de pas plus de deux à trois équipes. À grande échelle, le développement agile introduit encore d’autres défis et exige de nouvelles pratiques. Si vous devez escalader, commencez avec une ou deux équipes et ajouter progressivement plusieurs équipes en répartissant les équipes existantes et en ajoutant de nouveaux membres.%%% > %%% > 2. __Important :__ Assurez-vous que votre projet pilote est pertinent pour l’organisation. Sinon, les sceptiques pourraient le rejeter comme un « projet bisounours » et saper l’étape d’appropriation de cette nouvelle approche. Mais évitez les projets critiques, c’est-à-dire les efforts de développement dont le succès impacte de façon importante l’organisation. Le développement de logiciels Agile est un processus d’innovation par la rupture pour la plupart des organisations. Il exige la possibilité d’expérimenter, de faire des erreurs et d’en tirer des leçons.%%% > %%% > 3. __Indépendant :__ Choisissez un projet qui a peu de dépendances avec les autres équipes. Se coordonner avec d’autres projets ou différents groupes ajoute un niveau de complexité et rend l’application rigoureuse des pratiques agiles difficile, surtout si les autres projets suivent un processus différent. Si vous devez choisir parmi de gros projets complexes, alors cherchez un sous-projet avec peu de dépendances pour le piloter avec votre approche agile.%%% > %%% > 4. __Colocalisé :__ Commencez avec un projet agile sur un seul site et évitez la contrainte des équipes de développement distribuées, car cela rend la collaboration plus difficile et exige des pratiques et des outils supplémentaires. Sinon, rédiger ensemble les stories utilisateur, programmer en binôme et avoir des revues de sprints efficaces devient beaucoup plus difficile.%%% > %%% > 5. __Logiciel uniquement :__ Limitez votre projet pilote agile au développement de logiciels. Cela réduit considérablement la complexité liée à d’autres disciplines comme par exemple le hardware, la robotique, … Les pratiques de développement logiciel Agile sont bien connues dans le monde du logiciel, dans une moindre mesure pour ces autres disciplines.%%% > %%% > 6. __Développement de nouveaux produits :__ Sélectionnez un projet de développement d’un nouveau produit plutôt que de mettre à jour un produit existant si vous voulez essayer Scrum. Cela vous permet d’explorer la manière dont une idée peut être d’autant mieux transformée en un produit livrable grâce aux pratiques agiles. Cela vous permet de ne pas vous soucier d’un code existant qui peut être difficile à comprendre et qui ne dispose pas du patrimoine de tests nécessaires. Qui plus est, Scrum est particulièrement bien adapté pour traiter le flux, l’incertitude, l’innovation et le risque qui sont les caractéristiques inhérentes au développement d’un nouveau produit.%%% > %%% > Avant de sélectionner votre projet pilote ou de décider de retarder l’expérimentation des pratiques agiles, prenez en compte les conseils suivants :%%% > %%% > a. __Apprenez à connaître votre objectif :__ essayez de comprendre pourquoi vous voulez essayer une certaine approche agile et quels avantages vous souhaitez en tirer, même si c’est juste pour comprendre les raisons de tout ce battage médiatique.%%% > %%% > b. __Faites-le, un point c’est tout :__ Il est bien sûr utile de trouver le bon projet pilote, mais dans tous les cas rien ne vaut l’application des pratiques agiles, même si vous ne pouvez utiliser que certaines techniques au sein de votre processus actuel.%%% > %%% > « Ce que j’entends, je l’oublie.%%% > Ce que je vois, je m’en souviens.%%% > Ce que je fais, je le comprends. »  »Confucius »%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Nous sommes au-delà de votre état d’esprit

J’ai traduit ce billet de __David Joyce__ : ++[« We Are Beyond Your Mindset »|http://leanandkanban.wordpress.com/2011/04/14/we-are-beyond-your-mindset/]++.%%% > [((/dotclear/public/photos/.matsushita_s.jpg|Konosuke Matsushita|L|Konosuke Matsushita))|/dotclear/public/photos/matsushita.jpg]Vos entreprises sont fondées sur le modèle de Taylor. C’est encore pire quand on regarde ce que vous avez dans la tête. Avec vos patrons qui réfléchissent tandis que vos ouvriers manient le tournevis, vous êtes sincèrement convaincus que c’est la bonne façon de gérer une entreprise. Car le principe du management est d’extraire les idées de la tête des patrons pour les mettre dans la tête des travailleurs.%%% > %%% > Nous sommes au-delà de votre état ​​d’esprit. Le métier, nous le savons bien, est devenu si complexe et si difficile, la survie des entreprises si périlleuse dans un environnement de plus en plus imprévisible, compétitif et plein de dangers, que leur existence dépend de la mobilisation quotidienne de chaque once d’intelligence.%%% > %%% >__ Konosuke Matsushita__, fondateur de Panasonic Technics.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Priorisation des Fonctionnalités par le Coût du Retard

((/dotclear/public/photos/jeff-anderson.jpg|Jeff Anderson|L|Jeff Anderson))J’ai traduit – avec un peu de mal – cet article de Jeff Anderson : ++[« Using Cost of Delay Functions to Prioritize Product Delivery »|http://agileconsulting.blogspot.com/2011/03/using-cost-of-delay-functions-to.html]++.%%% > Dans beaucoup de projets « agiles » auxquels j’ai participé, une partie de ma stratégie consistait à découper tout ce qui passait – que ce soit des fonctionnalités, des cas d’utilisation ou des stories – et à livrer une partie à la fois la plupart du temps. Par exemple, dans l’itération 1, on livre la fonctionnalité de prise de commandes et dans l’itération 2 on livre le traitement de la commande.%%% > %%% > ((/dotclear/public/traductions/.typicaliterativeapproach_m.jpg|Typical iterative approach||Typical iterative approach))%%% > %%% > Bien que cette approche nous aide à livrer efficacement en découpant le travail en petites unités, cela ne nous aide pas beaucoup d’un point de vue métier. Lorsque vous livrez un produit, l’approche agile considère le produit d’un point de vue réellement incrémental. Quel est l’ensemble minimum livrable à l’instant t qui répondra aux objectifs vitaux du produit, quel est le prochain ensemble de fonctionnalités pour rendre l’outil meilleur, et ainsi de suite jusqu’à ce que j’obtienne le produit final, une partie étant livrée à la fois.%%% > %%% > ((/dotclear/public/traductions/.ineedashelter_m.jpg|I need a shelter!||I need a shelter!))%%% > %%% > Utiliser cette approche agile n’est pas suffisant pour que les équipes développent à chaque itération des choses qui partent en production. L’organisation entière doit réfléchir à la façon de livrer de façon incrémentale des versions du produit sur le marché.%%% > %%% > Pour réaliser ce travail, le métier doit s’entraîner à ne plus demander la terre entière un an avant… mais plutôt de demander un petit bout la semaine suivante.%%% > %%% > Un de mes collègues, Alexis Hui, nous a amené une approche innovante pour gérer cette situation sur l’un des projets que nous menions. Cela consistait à étendre notre tableau Kanban avec une cartographie des caractéristiques et thèmes fonctionnels illustrée ci-dessous.%%% > %%% > ((/dotclear/public/traductions/.themeorientedmap_m.jpg|Theme oriented map||Theme oriented map))%%% > %%% > Le tableau fut découpé en sections basées sur des caractéristiques fonctionnelles majeures que le produit devait comporter. Ces caractéristiques fonctionnelles furent ensuite découpés en thèmes fonctionnels composés d’attributs. Chaque attribut était vu comme une fonctionnalité pouvant être revisitée plusieurs fois durant le cycle de vie du projet. Chaque fois qu’un attribut nécessitait un travail, une story était étiquetée avec le thème et l’attribut concerné.%%% > %%% > Par exemple, la caractéristique fonctionnelle « casque » aura un thème pour la messagerie vocale avec un attribut pour l’activation et un autre pour la désactivation. Une story initiale concernera le travail nécessaire pour fournir la messagerie vocale sur un téléphone portable avec un ensemble de fonctionnalités très simples et une story finale pourra décrire des fonctionnalités plus fantaisistes comme visualiser la messagerie vocale.%%% > %%% > Chaque ensemble de thèmes/attributs agira comme une file d’attente persistante dans laquelle les stories sont placées.%%% > %%% > Nous avons ensuite utilisé un concept connu sous le nom de Coût du Retard (CDR$$NdT : COD = Cost Of Delay$$) d’une Fonctionnalité pour prioriser les stories. Pensez-y comme un moyen simple de montrer l’impact de ne pas réaliser une story donnée pour le métier. Le CDR, également baptisé le Coût d’Opportunité, est souvent schématisé sous la forme d’une courbe représentant la relation entre l’impact et le temps ; plus la pente de la courbe est raide, pire est l’impact à court terme. Le CDR peut représenter un impact financier, politique, moral ou tout autre impact défavorable pour l’organisation.%%% > %%% > Bien qu’il puisse être assez dur pour une organisation d’estimer l’impact exact de ne pas réaliser un élément donné sur la durée, nous sommes normalement capables d’affecter le CDR dans une catégorie ou profil donné. Lorsqu’on utilise le CDR, je recommande d’utiliser des couleurs ou des annotations sur l’élément du tableau Kanban, ceci afin de pouvoir facilement identifier son profil CDR.%%% > %%% > [((/dotclear/public/traductions/.costofdelay_m.jpg|Cost of delay||Cost of delay))|/dotclear/public/traductions/costofdelay.png]%%% > %%% > Puisque notre projet concernait le lancement d’un nouveau produit, nous avons décidé de baser nos profils CDR en tenant librement compte des risques du marché.%%% > %%% > Les tickets rouges représentaient les éléments qui furent considérés vitaux pour le lancement d’une première version du produit, le CDR est représenté comme une ligne verticale. Si nous n’avions pas livré ces fonctionnalités à la date annoncée pour la première version alors le projet aurait été voué à l’échec. Ces fonctionnalités étaient indispensables pour percer le marché.%%% > %%% > Les tickets beiges représentent un deuxième passage sur les tickets rouges, en prenant la plupart des fonctionnalités manuelles brutes et en les automatisant, en ajoutant une meilleure gestion des erreurs ainsi que d’autres tâches permettant de s’assurer que le produit sera pleinement opérationnel et constituera plus qu’un simple projet pilote. Ce CDR est représenté comme une courbe progressant vers la droite, nous aurions perdu de l’argent quotidiennement si cela n’avait pas été mis en œuvre, et les choses se seraient aggravées si cela n’avait pas été livré. Ces tickets étaient nécessaires pour soutenir la croissance du marché.%%% > %%% > Les tickets verts représentent des fonctionnalités haut de gamme comme le suivi de clientèle, des outils de productivité, des fonctionnalités personnalisées et même des fonctionnalités permettant de préserver le marché, comme conserver son numéro de téléphone lors du transfert vers une nouvelle offre. Le CDR a été modélisé ici comme celui des tickets beiges, mais avec un certain délai avant de subir des pertes et une pente de la courbe plus prononcée ; nous n’avions pas besoin de ces fonctionnalités tout de suite, même si elles se révélèrent très précieuses un peu plus tard. Ces tickets furent en effet nécessaires pour prendre des parts de marché aux concurrents.%%% > %%% > Les tickets bleus représentent des investissements à plus long terme. Traiter un ticket bleu n’a pas d’impact commercial notable. C’est plutôt la qualité du travail qui s’améliore. Les sujets « architecture », « former l’équipe sur les pratiques agiles », « refactoring », « documentation technique » ont tous été profilés en tickets bleus. Le CDR de ces tickets est représenté sous la forme d’une ligne horizontale avec une légère pente vers le haut, la valeur métier est loin d’être immédiate, mais ne pas les faire entraînerait plus tard des souffrances. Ces tickets furent nécessaires pour que l’équipe informatique puisse continuer à traiter les autres besoins du marché à un rythme et à un prix raisonnable.%%% > %%% > ((/dotclear/public/traductions/.themeorientedmap-color_m.jpg|Theme oriented map profiled||Theme oriented map profiled))%%% > %%% > Les schémas ci-dessus montrent des stories coloriées selon le CDR. On peut facilement voir les caractéristiques fonctionnelles les plus critiques dès les premières étapes de développement et celles qui pourront être traités plus tard. On peut remarquer que prioriser n’est pas aussi simple que de choisir une couleur, puis une autre, puis encore une autre. Dans des contextes métiers ou projets différents, on choisira une affectation différente des profils CDR dépendant de leur position dans le cycle de vie du produit.%%% > %%% > Cette affectation du CDR dépend aussi de la nature du contexte métier, par exemple les start-ups subiront davantage d’évènements fugitifs que de grosses sociétés et auront donc plus de tickets de couleur « chaude » (rouge, beige) pour répondre à ces événements au fil de l’eau.%%% > %%% > Il est typique d’utiliser cette approche pour revisiter les attributs à plusieurs reprises. La première story pour un attribut peut être un ticket bleu mettant en jeu un spike, un POC ou une conception réelle. Des stories liées à l’attribut pourront impliquer des tickets rouges et beiges, dépendant du souhait de disposer d’un composant essentiellement manuelle ou complètement automatisé. Les stories suivantes seront souvent des séries de tickets bleus et verts nécessaires pour réaliser des POC sur de nouvelles technologies et poser le socle à la base d’une fonctionnalité haut de gamme.%%% > %%% > L’idée est donc que la simple utilisation d’une couleur peut porter un maximum d’informations pertinentes d’un point de vue métier et permettre de livrer de la valeur sur un mode réellement agile.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Les serious games, bien plus sérieux qu’il n’y paraît

[((/dotclear/public/lectures/.plug-and-play_m.jpg|Les serious games, bien plus sérieux qu’il n’y paraît||Les serious games, bien plus sérieux qu’il n’y paraît))|/dotclear/public/lectures/plug-and-play.png]%%% %%% Lien sur la vidéo : ++[Comment mener un Serious Game ?|http://pro.01net.com/editorial/530554/comment-mener-un-serious-game/]++%%% ((/dotclear/public/games/.serious-games-philippe-launay_m.jpg|Philippe Launay et les Serious Games – 01 Informatique||Philippe Launay et les Serious Games – 01 Informatique))