Rétrospective Master Class Innovation Games du 29 au 30 mars 2011

[((/dotclear/public/games/.badge-innovation-games_s.jpg|Badge session Innovation Games||Badge session Innovation Games))|/dotclear/public/games/badge-innovation-games.jpg] [((/dotclear/public/CV/.innovation-games-trained-facilitator_s.jpg|Innovation Games Trained Facilitator||Innovation Games Trained Facilitator))|http://innovationgames.com/] !!What went well%%% * Objectif : être capable de sélectionner, préparer, jouer, expérimenter et exploiter les résultats d’exercices de créativité animés sous forme d’ateliers dans un environnement sûr/sain.%%% * Nous avons appris en pratiquant, c’est ce qui est le plus drôle : Personal Trading Card, Training Backlog, Fritz, Pre-Mortem, Process Improvement, Speed Boat, Blendz Corporation, Buy a Feature, Give Them a Hot Tub, Amusement Park, Start your Day, Prune the Product Tree, Product Box, My Worst Nightmare, …%%% * J’ai enfin fait connaissance de Alexandre Boutin (++[Agilex : Agilité et Expertise|http://www.agilex.fr/]++, Président du célèbre ++[CARA|http://clubagile.org/]++ et que j’avais brièvement croisé lors de l’++[Agile Tour Toulouse 2010|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/10/21/Retrospective-de-l-Agile-Tour-2010-Toulouse]++) et Romain Couturier (++[Exakis|http://www.exakis.com]++, Administrateur du CARA), c’est cool…%%% * Quelques photos souvenirs :%%% [((/dotclear/public/games/.alex-gallery_m.jpg|Alex gallery||Alex gallery))|/dotclear/public/games/alex-gallery.jpg] [((/dotclear/public/games/.product-box-institut-agile_s.jpg|Product Box Institut Agile||Product Box Institut Agile))|/dotclear/public/games/product-box-institut-agile.jpg] [((/dotclear/public/games/.1stMasterClass-20110329_m.jpg|1st Master Class Innovation Games||1st Master Class Innovation Games)) |/dotclear/public/games/1stMasterClass-20110329.jpg] [((/dotclear/public/games/.sfeir-et-surface_s.jpg|Sfeir et Microsoft Surface||Sfeir et Microsoft Surface))|/dotclear/public/games/sfeir-et-surface.jpg]%%% %%% !!What went wrong%%% * Il a plu pendant 2 jours.%%% * Ceux qui ne manipulent pas un tant soit peu la langue de Shakespeare seront définitivement largués.%%% * On en a bavé comme pas permis sur le 13ème jeu « My Worst Nightmare »… un vrai cauchemar !%%% !!Puzzles%%% * @Oana : Poor Morale = Pourrir le Moral ?%%% * @Alina : c’est quoi un « static flying blender » et un « mouse trapping system » ?%%% * Serious games for serious people ?%%% * Utiliser Buy a feature pour préparer la liste de Noël avec les enfants ?%%% * Afficher le modèle Scrum dans l’Obeya Room ?%%% * Cargo cult ?%%% !!Lessons (re-)learnt%%% [((/dotclear/public/games/.maarten-volders_s.jpg|Maarten Volders|L|Maarten Volders))|/dotclear/public/games/maarten-volders.jpg]- Pre-Mortem : dans la plupart des projets, nous tirons les leçons bien trop tard (Post-Mortem).%%% – Passer d’une logique d’ouvriers de l’industrie à une logique d’ouvriers de la connaissance.%%% – Vous ignorez ce que vous ignorez : c’est là que se situe la véritable innovation !%%% – Collaborer = expérimenter ensemble.%%% – Les jeux impliquent un haut niveau d’émotion ; les émotions nous aident à nous concentrer, à nous rappeler, à décider, à agir et à apprendre.%%% – Nous démarrons toujours un jeu par une question tirée d’une problématique réelle.%%% – Des artefacts concrets (post-its, …) rendent les idées concrètes.%%% – Parfois, matérialiser votre pire cauchemar n’est pas si éloigné de la réalité.%%% – Quelles sont vos questions ? que ferez-vous des réponses ?%%% – Espérez l’inattendu.%%% – C’est drôle parce que c’est vrai.%%% – Pilotez/guidez par l’exemple.%%% – Il n’y a pas de bonnes ou de mauvaises réponses.%%% – Ce sont les jeux qui font le travail (Alex).%%% – Les scientifiques sont aussi des artistes (Alina).%%% – N’arrêtez jamais d’apprendre !%%% !!Appreciations%%% * Merci à l’++[Institut Agile|http://institut-agile.fr/]++, donc à __Laurent Bossavit__, pour avoir organisé cette Master Class Innovation Games.%%% * Merci à ++[Maarten Volders|http://www.agileminds.be/training/3|en]++, l’animateur « accrédité » par Innovation Games Inc.%%% * Merci à Microsoft France pour nous avoir accueilli dans les locaux de son ++[Campus|http://www.microsoft.com/france/microsoft-en-france/microsoft-france/campus.aspx]++ à Issy-les-Moulineaux.%%% * Merci aux 14 autres aventuriers : Alina, Agnès, Oana, Yann, Romain (1), Romain (2), Frédéric, Alex, Rémy, Thierry, Nicolas, Ludovic, Jean-François et Gilles.%%% * At last but not least, merci à Philippe Launay, animateur du SUG bordelais qui m’a fait découvrir les Innovation Games.%%% !!Feedback%%% * Philippe Launay sur le SUG Bordeaux : ++[« Innovation Games »|http://sites.google.com/site/sugbordeaux/project-updates/innovationgames]++%%% * Alexandre Boutin : ++[« Innovations Games (r) … c’était Génial ! « |http://www.agilex.fr/2011/04/innovations-games-r-cetait-genial/]++%%% * ++[LES PHOTOS PRISES PAR MAARTEN !!!|https://picasaweb.google.com/AGILEMinds.be/InnovationGames032011Paris#]++%%% !! Links%%% * Le blog ++[AGILEMinds|http://agilemindsblog.wordpress.com/|en]++%%% * Le site ++[Innovation Games|http://innovationgames.com/|en]++%%% * Le livre ++[Innovation Games|http://www.amazon.com/Innovation-Games-Creating-Breakthrough-Collaborative/dp/0321437292|en]++%%% * Le livre ++[Gamestorming|http://www.amazon.com/Gamestorming-Playbook-Innovators-Rulebreakers-Changemakers/dp/0596804172/ref=sr_1_1?ie=UTF8&qid=1301608285&sr=8-1|en]++%%% * ++[Innovation Games Trained Facilitators|http://innovationgames.com/resources/partners/trained-facilitators/]++%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes rétrospectives sur le wiki ++[Rétrospectives Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/retrospective:start]++.

Caractéristiques d’un Product Owner

((/dotclear/public/photos/shane_hastie.jpg|Shane Hastie|L|Shane Hastie))J’ai traduit cet article de Shane Hastie ++[« Product Owner Patterns »|http://www.infoq.com/news/2011/03/product-owner-patterns|en]++ sur InfoQ.%%% %%% Le rôle du Product Owner est régulièrement débattu dans de nombreux forums et blogs. La diversité des responsabilités et les défis que comportent ce rôle constituent de fréquentes sources de discussions et de prises de position.%%% %%% Récemment, il y a justement eu quelques discussions sur les aspects fondamentaux du rôle du Product Owner et les actions importantes qu’il réalise dans le cadre d’un projet agile.%%% %%% ++[Mary Poppendieck|http://www.poppendieck.com/|en]++ a écrit un article sur le sujet ++[« The Product Owner Problem »|http://www.leanessays.com/2010/12/product-owner-problem.html|en]++ où elle constate les choses suivantes :%%% > Découvrir quelles sont les bonnes choses à construire est l’étape la plus importante dans le processus de création d’un bon produit. Si vous ratez cette étape, vous générez 100% de gaspillage. Déléguer à un unique Product Owner les décisions sur ce qu’il y a à construire, c’est externaliser le travail le plus important de l’équipe de développement à une personne qui n’a probablement pas la connaissance ou les compétences suffisantes pour réellement prendre de bonnes décisions. L’inconvénient de la plupart des implémentations du rôle de Product Owner, c’est l’idée qu’il prépare de façon détaillée les stories à développer par l’équipe. Cela ne permet pas aux membres de l’équipe de devenir des partenaires et des collaborateurs sur la conception du produit.%%% Mary Poppendieck discute ensuite des différents aspects du rôle du Product Owner et de la diversité des responsabilités portées par ce rôle :%%% > %%% > Dans Scrum, le Product Owner est un rôle mais ne devrait pas être un poste de travail dans l’entreprise. Le Product Owner a plusieurs casquettes : Chef Produit, Ingénieur Système, Ergonome, Architecte Logiciel, Analyste Métier, Ingénieur Qualité et même Rédacteur Technique. Nous ferions mieux d’utiliser ces intitulés de poste bien connus plutôt que d’en inventer un nouveau qui soit ambigu et qui, de surcroît, tend à créer un goulot d’étranglement empêchant l’équipe de développement de jouer son rôle principal de concepteur de logiciel.%%% Dans le même ordre d’idée, ++[John Mansour|http://www.zigzagmarketing.com/|en]++ évoque la confusion entre le rôle de product owner et celui de chef produit. Dans son article intitulé ++[« Agile Product Owner – New Name, Same Old Problem »|http://productmanagementtips.com/2009/07/29/agile-product-owner-new-name-same-old-problem/|en]++, il précise que l’équipe doit assurer deux rôles importants :%%% > 1. Le rôle du « quoi et pourquoi » : la responsabilité pour déterminer « quelles » fonctionnalités devraient être mises en œuvre dans le produit et « pourquoi » d’un point de vue métier et marché concurrentiel. Ce rôle du « quoi et pourquoi » pilote tous les aspects internes et externes. Ce rôle a pour objectif primordial d’aligner le produit avec la dynamique du marché et les besoins des clients. La responsabilité du « quoi et pourquoi » est typiquement du ressort du Chef Produit. Que la démarche soit traditionnelle ou Agile, ce rôle est nécessaire quelle que soit la personne, son titre ou la manière d’y arriver.%%% > %%% > 2. Le rôle du « comment » : la responsabilité pour déterminer « comment » les fonctionnalités du produit doivent fonctionner pour que les utilisateurs puissent travailler. Dans sa forme la plus simple, ce rôle est délégué à un utilisateur pour expliquer sous forme orale, écrite et illustrée ce que les utilisateurs font, comment ils le font et comment le logiciel devrait « fonctionnellement » travailler pour aider les utilisateurs. Evidemment, les personnes les mieux placées pour ce rôle sont d’anciens utilisateurs ou celles qui ont travaillé aux côtés de nombreux utilisateurs dans de nombreux contextes.%%% John Mansour précise que de nombreuses équipes agiles font l’erreur de combiner les deux rôles pour le product owner, ce qui produit une direction floue et de la confusion.%%% > A mon humble avis, la confusion repose sur deux choses. Premièrement, les sociétés logicielles ont essayé de combiner les responsabilités de Chef Produit et de Concepteur fonctionnel du produit pendant des années et c’est à chaque fois un cauchemar, du moins pour ce que j’en ai vu… et j’en ai vu. La crise d’identité est la même entre le chef produit et le product owner dans le monde agile.%%% > %%% > Quelle que soit la méthode de développement, combiner ces rôles conduit immanquablement à l’échec puisque les compétences et profils requis sont complètement distincts, sans parler du niveau de disponibilité exigé lorsqu’ils sont combinés, le résultat final ressemble à la bonne fonctionnalité mais peu utilisable ou des fonctionnalités très utilisables mais qui n’intéressent personne. Dilemme que l’on peut résumer par la formule « souhaitez-vous perdre un bras ou une jambe aujourd’hui ? ».%%% Vous trouverez d’autres commentaires, avis, suggestions et idées pour tirer le meilleur du rôle du product owner. ++[Monica Yap|http://www.solutionsiq.com/Training/Instructors.aspx|en]++ a commencé à publier une série d’articles sur le sujet « Product Owner Anti-patterns ». Elle a identifié les anti-patterns suivants :%%% * ++[le Product Owner absent|http://www.agileiq.org/2011/02/16/product-owner-anti-patterns-the-absent-product-owner/|en]++%%% * copier le dernier Product Owner%%% * ++[le Backlog change tout le temps|http://www.agileiq.org/2011/03/16/product-owner-anti-patterns-part-2-the-churning-backlog/|en]++%%% * la longue Définition du Fini qui ne veut rien dire%%% * le Product Owner n’est pas unique%%% * pas assez de parties prenantes%%% %%% ++[Jack Milunsky|http://agilesoftwaredevelopment.com/user/jackmilunsky|en]++ a identifié ++[les 10 principales activités d’un product owner|http://agilesoftwaredevelopment.com/blog/jackmilunsky/top-10-activities-product-owner|en]++ :%%% # Crée et MAINTIENT le Backlog du produit.%%% # Priorise et trie le Backlog en fonction de la valeur métier ou du ROI.%%% # Aide à élaborer les Epics, Thèmes et Features et les découper en stories utilisateurs de granularité assez fine pour être traité dans un sprint.%%% # Porte la Vision et les Objectifs de chaque Version et Sprint.%%% # Représente le Client et s’engage pour lui.%%% # Participe aux mêlées quotidiennes, aux réunions de planification de sprint, aux revues de sprint et aux rétrospectives.%%% # Inspecte l’avancement du produit à la fin de chaque sprint et a toute latitude pour accepter ou rejeter le travail réalisé.%%% # Peut changer le cours du projet à la fin de chaque Sprint.%%% # Communique sur l’état d’avancement autour de lui.%%% # Termine le sprint courant si un changement radicale est nécessaire.%%% —- ((/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]++.

Sur notre façon de coacher chez Crisp ! (phoque, canard ou albatros)

((/dotclear/public/photos/.MattiasSkarin_sq.jpg|Mattias Skarin|L|Mattias Skarin))J’ai traduit le billet ++[« How we coach at Crisp! »|http://blog.crisp.se/mattiasskarin/2011/03/15/1300185527591.html|en]++ de __Mattias Skarin__ qui témoigne, une fois de plus, de l’originalité de ++[Crisp AB|http://crisp.se/|en]++. Pour ceux qui ne connaissent pas encore l’état d’esprit de cette société suédoise, ça se passe ++[ici|http://www.fabrice-aimetti.fr/dotclear/public/traductions/c-est-quoi-crisp.pdf]++.%%% > En dehors de Lean & Agile, nous avons également expérimenté le fait d’avoir des développeurs jouant le rôle de coachs en immersion dans des équipes pour développer les compétences « de l’intérieur ». Pour éviter toute confusion (entre nous), nous avons développé une terminologie sur mesure pour notre travail de coaching :%%% > %%% > ((/dotclear/public/traductions/.seal2_t.jpg|Phoque|L|Phoque))__Phoque__%%% > %%% > Les phoques plongent en profondeur et reste en bas pendant un long moment. Ils sont fidèles, ils aiment les problèmes et les côtoient jusqu’à ce qu’ils soient résolus. Dotés d’un grand sens de l’odorat, ils peuvent chasser du mauvais code sur plusieurs kilomètres et ramener la proie à leurs amis.%%% > %%% > %%% > %%% > ((/dotclear/public/traductions/.duck_t.jpg|Canard|L|Canard))__Canard__%%% > %%% > Les canards nagent à la surface le long de l’étang, chassant tout ce qui peut passer à portée. Parfois, ils plongent en profondeur. Les canards sont particulièrement bien préparés avec des équipes qui améliorent constamment leurs pratiques d’ingénierie et éliminent les obstacles complexes. Un canard suivra une équipe jusqu’à ce que de nouveaux canards apparaissent pour conquérir d’autres domaines.%%% > %%% > %%% > %%% > ((/dotclear/public/traductions/.albatross_t.jpg|Albatros|L|Albatros))__Albatros__%%% > %%% > Les albatros sont assez bruyants et vous les trouverez en train de discuter avec passion jusqu’à ce que la nourriture soit à nouveau disponible. Ils aiment prendre de la hauteur sur les choses. Les albatros recherchent les amis lors des activités de formation. Tout albatros souhaite secrètement retrouver l’étang pour jouer avec les canards.%%% > %%% > … Quel genre de coach êtes-vous ? 🙂 —- ((/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]++.

L’Agilité à l’Exia.Cesi

((/dotclear/public/logos/.logo-exia-cesi_sq.jpg|Exia.Cesi|L|Exia.Cesi))Je souhaiterais remercier Florian Duport et Jean-Aymeric Diet de l’école supérieure d’informatique ++[Exia.Cesi|http://www.exia.cesi.fr/centre-bordeaux.asp]++ de Blanquefort pour m’avoir invité à animer une session sur l’Agilité toute l’après-midi. Je dirais que la vingtaine d’étudiants de 4e année présents paraissaient intéressés compte tenu (de la pertinence) des questions posées :)%%% %%% Jean-Aymeric m’a informé que la pédagogie de l’école ne reposait pas sur des cours mais sur des mises en situation des étudiants avec une cinquantaine de mini-projets à l’année. Je dis bravo ! {{Exia.Cesi, l’école d’informatique qui libère ton talent.}}%%% %%% ((/dotclear/public/logos/Sopra_Group_logo.jpg|Logo Sopra Group|L|Logo Sopra Group))Je remercie également ma société ++[Sopra Group|http://www.sopragroup.com/]++ d’avoir autorisé mon intervention.

7±2

((/dotclear/public/communication.jpg|Communication à 3|L|Communication à 3))Il est surprenant que l’on doive encore persuader les gens de garder une taille d’équipe qui soit petite (7 personnes plus ou moins 2). J’ai rapidement traduit les quelques slides du support ++[« Communication Nodes 2007-12-5″|http://agileconsortium.pbworks.com/w/page/1527437/Presentations|en]++ trouvé sur le wiki __agileconsortium__. La traduction est ++[ici|/dotclear/public/traductions/Noeuds-de-Communication-FR.pdf]++. %%%

On vend plus cher un mauvais chef de projet…

((/dotclear/public/punaise.JPG|Punaise|L|Punaise, aoû 2009)){{On vend plus cher un mauvais chef de projet qu’un bon développeur avec de l’expérience.}}%%% %%%  »Source : ++[« Peut-on réussir un forfait ? »|http://www.net-liard.com/blog/2011/03/peut-on-reussir-un-forfait/]++ de Samuel Liard. »

Déclaration d’Interdépendance

((/dotclear/public/logos/.logo-doi_t.jpg|Declaration of Interdependence »|L|Declaration of Interdependence))J’ai traduit la page ++[« Declaration of Interdependence|http://pmdoi.org/|en]++ publiée par __Jim Highsmith__.%%% %%% Vous trouverez la traduction sur le lien ++[Déclaration d’Interdépendance|/dotclear/public/traductions/pmdoi-org-fr.html]++.%%%

Bilan de période d’essai et Perfection game

Vous souhaitez préparer le bilan de votre période d’essai. Vous ne savez pas trop comment préparer cette réunion ? Vous avez tendance à réclamer ou râler sans être vraiment constructif ? Je vous conseille de faire un __Perfection Game__ (popularisé par ++[Yves Hanoulle|http://www.hanoulle.be/2010/07/perfection-game/|en]++) et de le partager avec votre hiérarchique. Autrement dit, habituez-vous à faire des retours sous une forme positive et proposez des pistes d’amélioration (impactant la note globale). C’est ce que je viens de faire aujourd’hui et ça s’est plutôt bien passé.%%% %%% ((/dotclear/public/./.20110307-periode-d-essai_m.jpg|Période d’essai||Période d’essai))%%% %%% __Feedback :__%%% * Yves Hanoulle : ++[« How to give feedback »|http://www.hanoulle.be/2011/03/how-to-give-feedback/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Paircoaching+%28PairCoaching%29|en]++

Kanban, Flux et Cadence

((/dotclear/public/photos/.photo-karl-scotland_sq.jpg|Karl Scotland|L|Karl Scotland))Après avoir lu l’excellent roman d’industrie ++[« Le But » de Eliyahu M. Goldratt|/dotclear/index.php?post/2011/02/23/Le-But-Un-processus-de-progres-permanent]++, j’ai eu une fringale de Kanban. Je vous propose ici la traduction du billet de Karl Scotland : ++[« Kanban, Flow and Cadence »|http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/|en]++.%%% %%% > __Introduction__%%% > %%% > Il y a récemment eu une augmentation notable de l’intérêt pour Kanban avec, d’une part un certain nombre de personnes réclamant plus d’informations, et d’autre part davantage de personnes écrivant de nouveaux blogs et articles sur le sujet. Je tente ici de décrire plus en détail mon opinion :%%% > – Kanban… Travail maîtrisé%%% > – Flux… Travail efficace%%% > – Cadence… Travail fiable%%% > %%% > __Kanban__%%% > %%% > Un système Kanban est un mécanisme pour maîtriser le travail effectué dans un système de développement logiciel. Le terme Kanban peut être défini comme une « carte visuelle », comme illustré ci-dessous (et gentiment écrit pour moi par Kenji Hiranabe lors de l’événement Agile 2008).%%% > %%% > ((/dotclear/public/traductions/.kenji-kanban-2_s.jpg|Kenji Kanban||Kenji Kanban))%%% > %%% > L’origine du Kanban est le Système de Production Toyota. Taiichi Ohno, dans son livre « Toyota Production System », a écrit :%%% > %%% >  » »Les deux piliers du Système de Production Toyota sont le juste-à-temps et l’automatisation avec une touche humaine, ou autonomation. L’outil utilisé pour faire fonctionner le système est le Kanban. » »%%% > %%% > Kanban est ce qui permet à un système tiré de travailler en juste-à-temps.%%% > %%% > À quoi ressemble un système Kanban dans le développement logiciel ? Très simplement, il y a une file d’attente de travail, qui passe par un certain nombre de stades de développement jusqu’à ce qu’elle soit finalement traitée. Lorsque le travail est achevé à une étape, il passe dans la file d’attente aval en entrée de l’étape suivante. Lorsque quelqu’un a besoin de travailler, il tire les travaux à réaliser de la file d’attente amont. Ceci peut être illustrée comme suit.%%% > %%% > [((/dotclear/public/traductions/.basic-kanban_m.jpg|Basic Kanban||Basic Kanban))|/dotclear/public/traductions/basic-kanban.png]%%% > %%% > Cela ressemble fort à un tableau de tâches typique en Agile, avec peut-être quelques étapes supplémentaires, bien sûr il ne peut pas y avoir une étape de développement unique. Cependant, il y a un autre élément important qui définit vraiment le système Kanban – les limites. Il y a deux limites de base – les limites des files d’attente et les limites de WIP$$WIP = Work In Progress. NdT : traduit en TAF (Travail A Faire) par Claude Aubry dans la traduction de l’ouvrage ++[« Kanban et Scrum : tirer le meilleur des deux|http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/?page=glossaire#-1]++$$.%%% > %%% > [((/dotclear/public/traductions/.limits-kanban_m.jpg|Limits Kanban||Limits Kanban))|/dotclear/public/traductions/limits-kanban.png]%%% > %%% > Les limites de file d’attente sont conçues pour éviter le travail prématuré. C’est de cette façon que le juste-à-temps est atteint. La limite doit être suffisamment grande pour garder l’équipe occupée (autrement dit, il y a toujours quelque chose pour que l’équipe commence à travailler dessus), mais suffisamment petite pour éviter une priorisation prématurée (c’est-à-dire avoir des éléments qui stagnent trop longtemps dans la file d’attente avant d’être traité). Idéalement, la file d’attente doit être gérée en mode FIFO, même si ce n’est qu’une préconisation et non une règle stricte, car parfois ce n’est pas possible en fonction de la disponibilité des compétences ou des autres ressources.%%% > %%% > Les limites de WIP sont conçues pour réduire le multi-tâches, maximiser le throughput et améliorer le travail d’équipe.%%% > %%% > Réduire le multitâche est bénéfique pour deux raisons principales :%%% > %%% > 1) 20% du temps est perdu pour passer d’une « tâche » à une autre, donc moins on a de tâches moins on perd de temps (lire Gerald Weinberg dans son livre Quality Software Management: Systems Thinking).%%% > %%% > [((/dotclear/public/traductions/.context-switching_m.jpg|Context switching||Context switching))|/dotclear/public/traductions/context-switching.png]%%% > %%% > 2) Exécuter des tâches séquentiellement produit des résultats plus tôt. Comme le montre le diagramme ci-dessous – le multi-tâches A, B et C (en haut), conduit à livrer A (et même C) un peu plus tard – plutôt que de façon séquentielle (en bas).%%% > %%% > [((/dotclear/public/traductions/.multitasking_m.jpg|Multitasking||Multitasking))|/dotclear/public/traductions/multitasking.png]%%% > %%% > Un excellent exercice pour démontrer les effets du multi-tâches a été décrit par ++[Clarke Ching|http://www.clarkeching.com/2007/09/multi-tasking-e.html|en]++.%%% > %%% > Le throughput est également optimisé en diminuant le WIP. Des exemples simples de cet effet sont les embouteillages, où la vitesse de la circulation se réduit au fur et à mesure que le trafic augmente, ainsi que la charge CPU, où les performances des applications diminuent à mesure qu’augmente la charge CPU. L’effet peut être expliquer avec la Loi de Little sur la Théorie des files d’attente :%%% > %%% > « Temps de Cycle Total = Nombre d’éléments en cours / Taux moyen d’achèvement »%%% > %%% > Par conséquent, pour améliorer le temps de cycle, il y a deux options ; réduire le nombre d’éléments dans le processus ou améliorer le taux moyen d’achèvement. La réduction du nombre d’éléments en cours est l’option la plus facile, et une fois maîtrisée, les changements les plus difficiles pour améliorer le taux d’achèvement peuvent être appliqués.%%% > %%% > Finalement, en ayant moins d’éléments en cours de travail, l’équipe est en mesure de se concentrer davantage sur les objectifs plus larges, et moins sur les tâches individuelles, encourageant ainsi un effet d’essaimage, et l’amélioration du travail d’équipe.%%% > %%% > Limiter le WIP de cette manière peut sembler inhabituelle pour les équipes, et il y a souvent une inquiétude que les membres de l’équipe soient inactifs parce qu’il n’y a pas de travail à faire et soient incapables de tirer de nouveaux travaux de la file d’attente. Les directives suivantes peuvent aider l’équipe dans cette situation :%%% > %%% > 1. Pouvez-vous aider à faire progresser un kanban existant ?  »Travaillez là-dessus alors. »%%% > 2. Vous n’avez pas les compétences requises ?  »Trouvez le goulot d’étranglement et travaillez pour le lever. »%%% > 3. Vous n’avez pas les compétences requises ?  »Tirez du travail de la file d’attente. »%%% > 4. Impossible de démarrer quoi que ce soit dans la file d’attente ?  »Y a-t-il une priorité moindre que vous pouvez commencer à traiter ? »%%% > 5. Il n’y a rien de plus faible priorité ?  »Trouvez d’autres travaux intéressants. »%%% > %%% > Les questions importantes ici sont ce qui constitue un travail à faible priorité ou un autre travail intéressant. Il s’agit essentiellement d’un travail qui ne créera pas de travail en aval, qui permettra d’améliorer le futur throughput et qui pourra être suspendu dès qu’un travail existant dans le kanban est disponible. Les travaux de priorité moindre peuvent être des spikes ou des analyses pour un travail qui va commencer de façon imminente. D’autres travaux intéressants peuvent être le refactoring, l’automatisation des outils, le développement personnel ou l’innovation.%%% > %%% > La taille des limites de WIP peut dépendre du type de travail et de la taille de l’équipe et doit être ajustée pour obtenir un flux maximal. Une approche est de commencer petit (par exemple une limite de 1) et de l’augmenter si nécessaire. Une autre est de commencer avec une limite plus grande (par exemple une limite correspondant à la moitié de la taille de l’équipe) et de la réduire jusqu’à ce que la zone optimale soit atteinte.%%% > %%% >  »Les conséquences de l’utilisation d’un système kanban sont que le Backlog Produit peut être éliminé, parce que la file d’attente immédiate est la seule digne d’intérêt, les itérations de durée fixe (ou sprints) peuvent être éliminées parce que le travail est tiré dès que nécessaire, et l’estimation peut être éliminée parce que le travail n’est pas planifié dans des itérations. »%%% > %%% > __Flux__%%% > %%% > Le flux décrit comment le travail dans le système peut livrer un maximum de valeur. Comme ++[Mary et Tom Poppendieck|http://www.poppendieck.com/|en]++ l’ont écrit :%%% > %%% > « Dans les entreprises lean, les structures organisationnelles traditionnelles cèdent la place à de nouvelles organisations axées sur des équipes centrées sur le flux de valeur, et non pas sur l’expertise fonctionnelle. »%%% > %%% > En particulier, le Lean met l’accent sur « Flux pièce à pièce ». Cela signifie de déplacer une pièce à la fois entre les étapes d’un workflow au lieu de passer des lots de travaux entre les différentes étapes dans un workflow. Le « Flux pièce à pièce » dans un système Kanban pour le développement logiciel peut être considéré comme une MMF (Minimal Marketable Feature$$NdT : MMF = ensemble de fonctionnalités minimales apportant de la valeur à l’utilisateur$$) tel que décrit par M Denne & H Cleland-Huang dans Software by Numbers.%%% > %%% > « Une MMF est un morceau de fonctionnalité qui satisfait un sous-ensemble des exigences du client, et qui est capable de livrer de la valeur au client lorsqu’elle est livrée en tant qu’entité indépendante ».%%% > %%% > Les éléments kanbans doivent être minimes, de sorte qu’ils sont aussi petits que possible afin de permettre une livraison incrémentale, de réaliser le produit plus tôt, de réduire l’inflation fonctionnelle et de se concentrer sur les fonctionnalités du noyau qui sont les plus importantes, et de minimiser la complexité car chaque fonctionnalité a un coût pour un utilisateur.%%% > %%% > Les éléments kanbans peuvent être commercialisables de différentes manières.%%% > %%% > – Les fonctionnalités de base – il s’agit du ticket d’entrée pour être dans le jeu%%% > – Les différenciateurs – qui différencient le produit de la concurrence et ravient l’utilisateur%%% > – Les spoilers – ils annulent le facteur de différenciation des concurrents%%% > – Les réducteurs de coûts – réduisent les coûts et améliorent la marge bénéficiaire%%% > %%% > Une pratique utile est de dire qu’une MMF est commercialisable si elle peut être écrite sur le blog d’un produit.%%% > %%% > Les éléments kanbans doivent être des fonctionnalités qui sont distinctes, livrables et observables. L’acronyme INVEST (Indépendante, Négociable, de grande Valeur, qu’on peut Estimer, Suffisamment petite et Testable) tel que décrit par ++[Bill Wake|http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/|en]++, peut également être appliqué aux MMFs.%%% > %%% > Le terme Commercialisable$$Marketable$$ des MMFs signifie qu’elles sont probablement plus grandes que les typiques Stories utilisateurs, qui décomposent souvent le travail pour être livrées de façon incrémentale tout en apportant une certaine valeur, même si elles ne sont pas commercialisables en tant que tel. Par conséquent, il est important d’appréhender la chaîne de valeur$$Value Stream$$ des MMFs pour livrer la MMF entièrement le plus rapidement possible. Une chaîne de valeur décrit les étapes, les retards et les informations nécessaires pour livrer un produit, et peut souvent être utilisée pour décider des mesures à prendre dans un système kanban initial. Avec de grosses MMFs, les Stories utilisateurs sont plus le fruit d’une technique d’analyse afin de permettre la livraison incrémentale d’une MMF, sans perdre de vue la globalité de la MMF. Je décris comment un flux continu peut être réalisé avec des MMFs dans ++[The Anatomy of an MMF|http://availagility.co.uk/2008/07/07/the-anatomy-of-an-mmf/|en]++.%%% > %%% > Un certain nombre de techniques peuvent aider à gérer les relations entre les MMFs et les Stories utilisateurs afin de tirer bénéfice des deux. L’une d’entre elles est le Story Mapping décrit par ++[Jeff Patton|http://agileproductdesign.com/blog/the_new_backlog.html]++.%%% > %%% > [((/dotclear/public/traductions/.user-story-mapping_m.jpg|User story mapping||User story mapping))|/dotclear/public/traductions/user-story-mapping.png]%%% > %%% > J’ai aussi récemment travaillé dans un environnement réglementé où les buts et sous-buts des cas d’usage ont produit des MMFs, avec des scénarios détaillés pour fournir les détails supplémentaires.%%% > %%% > Une autre amélioration consiste à utiliser des Kanbans à deux niveaux, avec un niveau pour les MMFs, et un autre pour les Stories utilisateurs.%%% > %%% > [((/dotclear/public/traductions/.2-tier-kanban-1_m.jpg|2-tier Kanban||2-tier Kanban))|/dotclear/public/traductions/2-tier-kanban-1.png]%%% > [((/dotclear/public/traductions/.2-tier-kanban-2_m.jpg|2-tier Kanban||2-tier Kanban))|/dotclear/public/traductions/2-tier-kanban-2.png]%%% > %%% >  »La conséquence de l’application du concept de Flux, c’est que l’accent est mis sur l’utilisation de MMFs plus grandes et axées sur la valeur, plutôt que de petites Stories livrées de façon incrémentale. »%%% > %%% > __Cadence__%%% > %%% > La cadence est l’approche qui consiste à atteindre engagement et efficacité avec un système kanban. Je reçois souvent des questions à ce sujet :%%% > %%% > « Si l’équipe n’estime pas ou ne planifie pas au sein de boîtes de temps de durée fixe, comment peut-elle prendre des engagements fiables ? »%%% > %%% > Pour citer une fois de plus Mary et Tom Poppendieck :%%% > %%% > « Une cadence régulière, ou « battement de cœur », établit la capacité d’une équipe à livrer efficacement un logiciel opérationnel à une vitesse fiable. Une organisation qui livre à une cadence régulière démontre son aptitude au processus et peut facilement mesurer sa capacité. »%%% > %%% > L’itération de durée fixe est une forme de cadence, qui combine planification, revue et livraison. Un système kanban découple ces événements, leur permet d’avoir des cadences distinctes et également d’en ajouter deux nouveaux. Le throughput est la quantité de production d’un processus dans une période de temps donnée, et le temps de cycle est le temps pris pour terminer un processus. La relation entre les deux est :%%% > %%% > Throughput = WIP / Temps de cycle%%% > %%% > Le throughput permet de prévoir la capacité future, sans avoir à spécifier ce qui pourra être livré. Le temps de cycle est une forme d’engagement qui peut se matérialiser sous forme de SLA dans l’entreprise (voir ++[Kanban commitment|http://availagility.co.uk/2008/04/09/kanban-commitment/|en]++). Lorsque la taille du travail varie, de grandes nouvelles fonctionnalités à de petites corrections et de petites demandes de changement, alors une classification des MMFs peut amener une variété de temps de cycle. Le throughput ainsi que le temps de cycle peuvent être tracés et projetés, d’une manière similaire à la vélocité en XP, en tant que moyen pour encourager l’équipe à s’améliorer. Un Diagramme de Flux Cumulé peut également rendre visible la manière dont le travail s’écoule à travers le système et mettre en évidence les goulots d’étranglement.%%% > %%% > [((/dotclear/public/traductions/.cfd_m.jpg|CFD||CFD))|/dotclear/public/traductions/cfd.png]%%% > %%% > Pour des prévisions à plus long terme, une planification trimestrielle de la cadence se concentre sur les objectifs trimestriels. Des MMFs peuvent ensuite être priorisées pour atteindre ces objectifs. Une cadence de livraison régulière va renforcer la confiance en l’équipe qui travaillera à pleine capacité et throughput.%%% > %%% > D’autres cadences, comme les daily stand-up, les rétrospectives et les revues régulières sont décrites par ++[David Anderson|http://www.agilemanagement.net/index.php/blog/Sample_Chapter/|en]++. Certaines équipes utilisent un Kanban de Rétrospective pour signaler lorsqu’une rétrospective est nécessaire, et j’ai déjà brièvement blogué sur le sujet : ++[Kanban and Retrospectives|http://availagility.co.uk/2008/08/28/kanban-and-retrospectives/|en]++.%%% > %%% >  »La conséquence de la Cadence est que l’engagement et la fiabilité sont atteints via la mesure plutôt que par a planification. »%%% > %%% > __Résumé__%%% > %%% > Les points clés de Kanban, Flux et Cadence sont :%%% > %%% > – Un système Kanban gère le flux de travail d’une manière qui permet d’éliminer la notion de Backlog Produit, Itérations de durée fixe et Estimations.%%% > – Le flux doit permettre de livrer efficacement une valeur maximale en mettant l’accent sur l’optimisation de la chaîne de valeur des MMFs les plus grandes.%%% > – La cadence permet de découpler les entrées et les sorties des itérations et d’atteindre engagement et fiabilité via la mesure plutôt que par la planification.%%% > %%% > Vous trouverez d’autres articles sur ma page ++[Kanban|http://availagility.co.uk/kanban/|en]++, y compris la plupart des informations qui ont influencé et guidé ma réflexion.%%%