Adaptez votre style de coaching agile

((/dotclear/public/photos/.rachel-davies_sq.jpg|Rachel Davies|L|Rachel Davies))J’ai traduit l’article de Rachel Davies : ++[« Adapting Your Agile Coaching Style »|http://agilecoach.typepad.com/agile-coaching/2010/10/agile-coaching-zone.html|en]++.%%% %%% > Une des questions que nous examinons dans ma formation ++[« Agile Coaching Skills »|http://skillsmatter.com/course/agile-scrum/agile-coaching-skills|en]++ est quand adapter votre style de coaching. Ci-dessous, j’ai dessiné une flèche allant de __Directif__ à __Non Directif__ pour représenter un aspect important des styles de coaching. J’explique que le style de coaching que vous adoptez dépend de l’expérience des membres de l’équipe (flèche du haut) et de votre propre expérience (flèche du bas).%%% > %%% > [((/dotclear/public/traductions/.coaching-style_m.jpg|Style de coaching||Style de coaching))|/dotclear/public/traductions/coaching-style.png]%%% > %%% > Une approche très directive serait celle où vous dites fermement aux gens de suivre un ensemble spécifique de pratiques agiles, comme dans la présentation ++[« Shock Therapy »|http://scrum.jeffsutherland.com/2008/09/shock-therapy-bootstrapping.html|en]++ popularisée par Jeff Sutherland. Il n’y a pas de choix à faire par l’équipe, elle dépend entièrement de l’expertise du coach agile pour déterminer une approche adaptée à sa situation. La raison pour laquelle les membres de l’équipe sont prêts à faire cela, c’est qu’ils reconnaissent qu’ils sont nouveaux en agile et qu’ils n’ont pas les compétences pour décider ce qui est le plus approprié. Le coach agile agit comme leur guide et leur mentor pour leur permettre d’entrer dans le nouveau monde du développement logiciel agile. Beaucoup de coachs considèrent ce style de coaching directif plus comme du consulting ou de la formation que du coaching.%%% > %%% > Une approche totalement non-directive serait le cas où un coach s’appuie uniquement sur des questions qui poussent l’équipe à réfléchir, à partager ses observations et l’aider à identifier d’autres moyens de travailler. En théorie, ce coach ne doit pas avoir une expertise en matière d’application de pratiques agiles, il laisse à l’équipe le choix de l’endroit où aller. Cette approche fonctionne dans des situations où l’équipe a développé une connaissance suffisante des pratiques agiles de base pour les appliquer. Toutefois, l’équipe a encore du mal à surmonter les blocages mentaux sur ce qui est permis au sein de son organisation et à voir comment elle pourrait s’améliorer. Les questions du coach aident cette équipe à traverser les obstacles sur leur chemin et à lui révéler les choix qui s’offrent à elle. Une équipe qui débute en agile, et qui se bat encore avec le fait d’acquérir des compétences de base, peut trouver ce style de coaching frustrant parce que les gens veulent des réponses définitives lorsqu’ils apprennent et ils n’ont pas encore confiance pour les expérimenter.%%% > %%% > En tant que coachs agiles, nous travaillons avec des équipes qui ont une variété d’expériences et nous avons donc besoin de nous rappeler d’adapter notre style de coaching en conséquence. Certaines équipes sont au début de leur voyage agile, d’autres sont déjà à mi-chemin sur la route de l’agile, les équipes peuvent également contenir un mélange de membres nouveaux et expérimentés. Nous devons savoir reconnaître où en est l’équipe et adapter notre style de coaching pour répondre aux besoins de l’équipe. Ainsi, lorsque l’équipe est nouvelle, nous devons être prêts à agir en tant que professeur. Au fur et à mesure que l’équipe gagne en confiance, nous devons reconnaître le moment où il est temps de prendre du recul et à l’aider à construire un sentiment d’autonomie, permettant à ses membres de choisir où aller plutôt que de fournir toutes les réponses. Pour emmener l’équipe dans ce voyage, il est utile d’avoir une certaine expérience de l’application de l’agile sur laquelle s’appuyer pour soutenir l’équipe avec des conseils de style directif quand elle est coincée.%%% > %%% > Rappelez-vous aussi que le voyage d’une équipe agile n’est généralement pas une ligne toute droite où chacun, au début, prendrait sur son dos de nouvelles pratiques agiles et perfectionnerait ensuite simplement leur application en marchant. La route que la plupart des équipes prennent a de nombreux tours et détours. Selon le terrain que l’équipe va rencontrer, il peut être approprié d’apprendre de nouvelles pratiques et laisser tomber ou désapprendre les vieilles habitudes en cours de route. En tant que coach agile, nous avons besoin de voir à quel moment intervenir en orientant l’équipe dans la bonne direction pour l’aider à apprendre de nouvelles compétences et quand prendre du recul dans un style non-directif. Soyez prêt à passer de l’un à l’autre de ces styles tout au long du temps que vous passerez avec l’équipe.%%% —- ((/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]++.

Des objectifs STUPID

((/dotclear/public/photos/.christophe_louvion_sq.jpg|Christophe Louvion|L|Christophe Louvion))Christophe Louvion, au travers de son article ++[« STUPID goals »|http://runningagile.com/2010/01/31/stupid-goals/|en]++ paru sur son blog « Running Agile », reproche aux objectifs ++[SMART|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/04/18/Comment-se-definit-un-objectif]++ d’être stupides (micro-management, mini-waterfall, …) et propose un nouvel acronyme pour définir un objectif :%%% %%% * __S__incère : attaquez-vous à des sujets dont vous vous souciez réellement. Ne perdez pas de temps là où le cœur n’y est pas.%%% * __T__ransparent : vous ne pourrez pas réaliser de grandes choses tout seul. Rendez votre objectif le plus visible possible afin que d’autres puissent vous proposer leur aide.%%% * __U__nique : votre valeur repose sur des talents que personne d’autre n’a. Cultivez-les.%%% * __P__rimordial : concentrez-vous sur des choses importantes pour avoir un impact important.%%% * __I__ndépendant : atteindre un objectif est déjà assez difficile, ne les mélangez pas.%%% * __D__éterminé : soyez courageux et allez au-delà de vos limites.%%% %%% __Feedback :__ * Philippe Launay (SUG Bordeaux) : ++[« Cette année, mes objectifs seront STUPID ! »|http://sites.google.com/site/sugbordeaux/project-updates/cetteanneemesobjectifsserontstupid]++

Story Mapping pas à pas

Je rappelle que le concept de la Story Map a été introduit par __Jeff Patton__ (++[« The new user story backlog is a map »|http://www.agileproductdesign.com/blog/the_new_backlog.html|en]++). Au départ je n’avais pas compris l’intérêt de cette technique, puis de fil en aiguille, je l’ai expérimentée pour décliner la vision produit chez un client qui avait du mal à dresser sa roadmap… donc à prioriser.%%% %%% J’en ai profité pour traduire l’article de __Cara Turner__ : ++[« Story Mapping – step by step »|http://www.inevitable.co.za/2011/01/story-mapping/|en]++.%%% > __1. Introduction__%%% > %%% > Une story map$$NdT : cartographie des stories ?$$ est une vue haut-niveau de l’application à développer du point de vue de l’utilisateur.%%% > %%% > Le Story Mapping fait partie de l’étape de Planification de Release et se révèle un excellent outil pour identifier les Minimal Marketable Features (MMF$$NdT : ensemble de fonctionnalités minimales apportant de la valeur à l’utilisateur.$$) de la prochaine version. Cela se fait avec le Product Owner, idéalement avant de commencer le développement d’un nouveau produit, puis avant chaque nouvelle version.%%% > %%% > [((/dotclear/public/traductions/.story-mapping_s.jpg|Story mapping||Story mapping))|/dotclear/public/traductions/story-mapping.jpg]%%% > %%% > Pour préparer correctement une session de Story Mapping, vous devez d’abord identifier :%%% > – un Personnage$$NdT : on pourrait presque traduire par Persona.$$ pour chacun des utilisateurs du système, par exemple : Cathy, la gestionnaire de la flotte de véhicules et administrateur du système.%%% > – les principales activités effectuées par cet utilisateur et correspondant aux différentes parties du système qu’il va utiliser (par exemple, le tableau de bord, le suivi des véhicules, l’administration du système); écrivez-les sur de grands bristols.%%% > – Faites-vous une idée sur ce que seraient les sous-activités de chacune de ces activités principales.%%% > %%% > Vous aurez également besoin d’une pièce avec soit un grand tableau blanc, soit un grand mur, ou même un grand plancher pour déployer tous les post-its. Comme toujours, vous vous aiderez de pâte à coller et de marqueurs de toutes les couleurs.%%% > %%% > __2. La réunion de Story Mapping__%%% > %%% > __Les Personnages :__%%% > [((/dotclear/public/traductions/.story-mapping-characters_t.jpg|Personnages story mapping|L|Personnages story mapping))|/dotclear/public/traductions/story-mapping-characters.jpg] – Pour démarrer le Story mapping, créez un bristol pour chacun des personnages identifiés et mettez-les en place.%%% > – Le bristol doit contenir le nom du personnage, son rôle et ses responsabilités principales.%%% > %%% > %%% > %%% > %%% > %%% > __Le Squelette :__%%% > [((/dotclear/public/traductions/.story-mapping-skeleton_m.jpg|Squelette story mapping||Squelette story mapping))|/dotclear/public/traductions/story-mapping-skeleton.jpg]%%% > La ligne du haut est appelée le squelette.%%% > – Sélectionnez un utilisateur et les bristols concernant les principales activités pour lesquelles il est impliqué.%%% > – Collez-les dans l’ordre de fréquence d’utilisation pour lesquelles ces activités sont réalisées et de gauche à droite.%%% > %%% > Cela nous donne la vue sur un parcours typique de l’utilisateur à travers le système.%%% > %%% > __La Colonne vertébrale :__%%% > [((/dotclear/public/traductions/.story-mapping-backbone_t.jpg|Colonne vertébrale story mapping|L|Colonne vertébrale story mapping))|/dotclear/public/traductions/story-mapping-backbone.jpg] Dans l’étape suivante, on commence à définir les tâches typiques au sein de chacune des activités de haut niveau.%%% > Par exemple, pour le suivi des véhicules, Cathy devra être en mesure de :%%% > – Voir une carte%%% > – Voir l’état du véhicule%%% > – Activer le relais de communication%%% > – Afficher les événements en temps-réel%%% > – … y compris quelques activités de configuration du système.%%% > %%% > __Les Étapes :__%%% > Maintenant, nous sommes prêts à décomposer chacune des tâches en étapes.%%% > [((/dotclear/public/traductions/.story-mapping-steps_t.jpg|Etapes Story Mapping|L|Etapes Story Mapping))|/dotclear/public/traductions/story-mapping-steps.jpg] Déplacez le bristol du Squelette vers un autre tableau/mur et placez les tâches de la Colonne vertébrale identifiées dans l’étape précédente sur une ligne horizontale, cette fois par ordre de priorité pour le Version.%%% > %%% > Ici, « Configuration du système » a été mis en première position, ensuite la Carte et enfin les Actions sur carte en plus faible priorité.%%% > %%% > En dessous, nous listons les étapes à suivre pour chaque tâche :%%% > – Quelles actions ou étapes, Cathy, peut-elle réaliser pour chaque tâche ?%%% > – Quels sont celles de plus haute priorité ?%%% > %%% > Inscrivez-les sur des post-its, et ordonnez-les verticalement par ordre de priorité.%%% > %%% > Le Product Owner est maintenant facilement en mesure d’identifier les éléments qui seront critiques pour sa première version, et commence à avoir une très bonne intuition pour les versions futures. Ils peuvent être regroupés ou marqués avec des pastilles de différentes couleurs pour faire la différence entre la version 1, la version 2 et les autres priorités.%%% > %%% > Pour préparer le Backlog Produit, chacun des « Etapes » sera décomposée en 3 ou 4 Stories Utilisateurs, de sorte que le Product Owner sera également en mesure de commencer à les prioriser dans les sprints à venir.%%% > %%% > Et il est facile de partager la vision avec les équipes de développement, qui peuvent comprendre le contexte de chacune des étapes qu’elles fabriqueront.%%% —- ((/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]++.

Substitute leadership…

((/dotclear/public/punaise.JPG|Punaise|L|Punaise, aoû 2009)){{Eliminate slogans, exhortations, and targets asking for zero defects or new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force. Eliminate numerical goals, numerical quotas, and management by objectives. Substitute leadership.}}%%% %%%  »W. Edwards Deming »

De l’idée au lancement en passant par la vision

((/dotclear/public/photos/.photo-Roman-Pichler_sq.jpg|Roman Pichler|L|Roman Pichler))__Roman Pichler__ est toujours aussi prolifique pour tout ce qui concerne la définition de la vision produit. J’ai traduit son récent article ++[« From Idea to Launch »|http://www.romanpichler.com/blog/agile-product-innovation/idea-to-launch-process/|en]++.%%% > Scrum suppose que l’équipe est capable de créer un incrément du produit dès le premier sprint, un logiciel opérationnel qui pourrait potentiellement déjà être livré. Mais il y a très peu de choses de dites à propos des activités nécessaires pour préparer le premier sprint. Cet article traite de ce sujet en proposant un processus d’innovation agile qui démarre avec une idée et se termine avec un produit livrable.%%% > %%% > Que se passe-t-il avant le premier sprint ? Nous pouvons répondre à cette question si nous connaissons les critères d’entrée du sprint. Ken Schwaber recommande dans son livre  »Agile Project Management with Scrum », qu’une ++[vision produit|http://www.romanpichler.com/blog/product-vision/envisioning-your-product/|en]++ et un ++[backlog produit|http://www.romanpichler.com/blog/product-backlog/making-the-product-backlog-deep/|en]++ doivent être disponibles avant le début du premier sprint. Cela donne le processus suivant:%%% > %%% > [((/dotclear/public/traductions/.vision2product_m.jpg|de la Vision au Produit||de la Vision au Produit))|/dotclear/public/traductions/vision2product.gif]%%% > %%% > Le schéma ci-dessus est malgré tout incomplet. Il considère uniquement la partie « développement » du processus d’innovation produit. Où est l’étape amont ? D’où viennent la vision produit et le backlog produit ? Si l’on est d’accord sur le fait que toute innovation commence avec l’idée de créer un nouveau produit ou de mettre à jour un produit existant, nous pouvons étendre le processus comme suit :%%% > %%% > [((/dotclear/public/traductions/.idea2product_m.jpg|de l’Idée au Produit||de l’Idée au Produit))|/dotclear/public/traductions/idea2product.gif]%%% > %%% > Le schéma ci-dessus dessine un processus qui se compose de deux étapes : une étape de définition de la vision du produit et du backlog produit initial, et une étape de « développement » qui transforme la vision en un produit prêt pour le lancement.%%% > %%% > À la fin de l’étape de définition de la vision, les informations suivantes doivent être disponibles :%%% > * A quoi ressemblera et que fera le futur produit (version) ?%%% > * Qui sont les clients et les utilisateurs cibles ?%%% > * Quelle valeur ajoutée apporte le produit ?%%% > * Pourquoi est-il avantageux pour l’organisation de développer ce produit ?%%% > * La faisabilité du produit est-elle démontrée et comment en gros sera-t-il construit ?%%% > * Quelles sont la date de lancement désirée du produit et le budget cible ?%%% > %%% > Répondre à ces questions peut exiger la création d’éléments supplémentaires, comme par exemple une vision de l’architecture, des prototypes (jetables) et une analyse économique du projet.%%% > %%% > Comme toutes les choses en agile, donner une vision du produit requière un effort basé sur la collaboration. Le product owner doit mener les travaux de définition de la vision et impliquer les bonnes personnes : les membres de l’équipe, les parties prenantes et le ScrumMaster. Cette approche s’appuie sur le bon sens de l’ensemble des individus et conduit à la définition d’une vision réellement partagée. Gardez impliqués les mêmes individus au fur et à mesure que la vision se transforme en un produit livrable pour éviter le turnover, les anomalies, les attentes et les retards, et tout autre forme de gaspillage. Notez cependant que tous les membres de l’équipe ne doivent pas forcément participer à la définition de la vision.%%% > %%% > Assurez-vous d’impliquer les clients cibles et des utilisateurs tôt et régulièrement dans le processus d’innovation. Validez toute idée et supposition aussi rapidement que possible à l’aide de prototypes ou encore mieux avec un incrément du produit. Au lieu d’essayer de prédire l’avenir – ce qui est très difficile pour quiconque n’étant pas doté d’un pouvoir de prévision parfait – laissez le produit évoluer à travers un dialogue permanent avec ses utilisateurs et ses clients, ainsi que les autres parties prenantes.%%% > %%% > [((/dotclear/public/traductions/.feedback_m.jpg|Feedback||Feedback))|/dotclear/public/traductions/feedback.jpg]%%% > %%% > Évitez de négliger ou au contraire d’exagérer le travail de définition de la vision. Passer plusieurs mois sur des études approfondies des marchés, des planifications des produits et des analyses métiers n’est guère souhaitable dans un monde agile où le changement continuel et l’imprévisibilité dominent. Les deux facteurs suivants vous permettent de comprendre quel ++[effort de vision|http://www.romanpichler.com/blog/product-vision/how-much-visioning-is-necessary-in-scrum/|en]++ sera susceptible d’être requis pour votre produit : l’étape du cycle de vie de votre produit, et sa complexité – l’ensemble des fonctionnalités ainsi que la solution technique. Plus un produit est jeune et complexe, plus un important investissement initial sera nécessaire.%%% > %%% > Lorsque vous définissez la vision de votre produit, concentrez-vous sur le produit minimum commercialisable – un produit avec des fonctionnalités minimales qui répondent aux besoins prioritaires des clients. Ceci réduit l’effort nécessaire de vision globale et le délai global de mise à disposition sur le marché$$Time to market$$. En règle générale, quelques heures à quelques semaines – au lieu de plusieurs mois – devraient être suffisants pour répondre aux questions ci-dessus.%%% —- ((/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]++.

Doggy Planning et Estimation relative

((/dotclear/public/photos/michael-mccullough.png|Michael McCullough|L|Michael McCullough))Suite au jeu « Doggy Game » animé par Philippe Launay lors du ++[SUG Bordeaux du 11 janvier|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/01/15/Retrospective-Scrum-Cafe-Bordeaux-du-11-janvier-2011]++, j’ai souhaité traduire l’article original de __Michael McCullough__ ++[« Doggy Planning »|http://blog.tastycupcakes.com/es/2009/06/doggy-planning/|en]++. En prime, vous trouverez le jeu de cartes que j’ai conçu et qui peut être utilisé en guise d’introduction aux règles du Planning Poker :-)%%% > __Temps :__ 10 minutes%%% > %%% > __Accessoires :__%%% > %%% > – 1 jeu de cartes de planning poker par participant. ++[http://www.crisp.se/planningpoker/|http://www.crisp.se/planningpoker/|en]++%%% > %%% > __Instructions :__%%% > %%% > En procédant l’un après l’autre, montrer chacun des noms de chien qui suivent et demander aux participants de voter en montrant une carte d’estimation :%%% > %%% > – __Chihuahua__ – c’est le plus petit chien et ce devrait donc être l’estimation de référence. Les autres chiens doivent être estimés par rapport à lui.%%% > – __Grand Danois__ – les estimations devraient être très importantes.%%% > – __Golden Retriever__ – les estimations devraient être moyennes ou grandes.%%% > – __Caniche__ – les participants devraient demander plus d’informations, par exemple, est-ce un caniche normal ou un caniche nain ?%%% > – __Terre-Neuve__ – c’est le chien le moins bien connu ; ceux qui ne savent pas ne devraient pas voter et devraient plutôt poser des questions.%%% > – __Guildenbaur Autrichien__ – il s’agit d’une ruse : le chien n’existe pas, donc aucune estimation ne devrait être donnée.%%% > %%% > __Éléments d’apprentissage :__%%% > %%% > – Cet exercice permet de familiariser les participants avec les cartes du planning poker.%%% > – Ceux qui procèdent aux estimations ne doivent pas être influencés par les autres.%%% > – Les sujets (ici des chiens) sont estimés relativement les uns par rapport aux autres, en utilisant des unités floues.%%% > – Les gens ne doivent pas voter sur des sujets qui ne sont pas compris. Ils doivent demander des éclaircissements et, si cela ne relève pas de leur domaine, ils devraient s’abstenir.%%% [((/dotclear/public/traductions/.doggy-back_s.jpg|Dos de la carte||Dos de la carte))|/dotclear/public/traductions/doggy-back.jpg] [((/dotclear/public/traductions/.Chihuahua_s.jpg|Chihuahua||Chihuahua))|/dotclear/public/traductions/Chihuahua.jpg] [((/dotclear/public/traductions/.Grand-Danois_s.jpg|Grand Danois||Grand Danois))|/dotclear/public/traductions/Grand-Danois.jpg] [((/dotclear/public/traductions/.Golden-Retriever_s.jpg|Golden Retriever||Golden Retriever))|/dotclear/public/traductions/Golden-Retriever.jpg] [((/dotclear/public/traductions/.Caniche_s.jpg|Caniche||Caniche))|/dotclear/public/traductions/Caniche.jpg] [((/dotclear/public/traductions/.Terre-Neuve_s.jpg|Terre-Neuve||Terre-Neuve))|/dotclear/public/traductions/Terre-Neuve.jpg] [((/dotclear/public/traductions/.Guildenbaur-Autrichien_s.jpg|Guildenbaur Autrichien||Guildenbaur Autrichien))|/dotclear/public/traductions/Guildenbaur-Autrichien.jpg]%%% %%% —- ((/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]++.

Kanban multi-niveaux

J’ai traduit l’article ++[« Multi-tier Kanban »|http://toolsforagile.com/blog/archives/598|en]++ posté par __Siddharta__ sur le Blog de Silver Stripe. Ce mode de représentation multi-niveaux m’a clairement fait pensé à ce qui a été décrit par Claude Aubry, Antoine Vernois et moi-même lors de notre présentation ++[« Kanban et Scrum : tirer le meilleur des 2″|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/10/21/Retrospective-de-l-Agile-Tour-2010-Toulouse]++ à l’Agile Tour Toulouse 2010.%%% > L’un des défis avec une entreprise kanban est de relier les besoins des parties prenantes avec les besoins de l’équipe de développement.%%% > %%% > – Les parties prenantes réfléchissent en termes de gros morceaux de fonctionnalité (appelons-les des Epics$$NdT : voir ++[« Features, themes, epics et stories »|http://www.aubryconseil.com/post/2007/10/04/305-features-themes-epics-et-stories]++ par Claude Aubry$$), alors que l’équipe de développement a besoin d’avoir des stories de granularité très fine.%%% > – Les parties prenantes sont intéressés par le lead time$$NdT : voir ++[« 1er principe agile : réduire le lead-time… et plus encore »|http://etreagile.thierrycros.net/home/?post/2010/06/02/1er-principe-agile-%3A-r%C3%A9duire-le-lead-time]++ par Thierry Cros$$ de bout en bout d’une epic, alors que le tableau Kanban de l’équipe mesure uniquement le lead time d’une story.%%% > %%% > La solution à cela est le kanban multi-niveaux.%%% > %%% > __Les User Story Maps__%%% > %%% > Le User Story Mapping est une technique de représentation visuelle qui permet d’avoir une compréhension partagée d’un produit.%%% > %%% > Nous commençons par traiter les Epics qui intéressent les parties prenantes. Chaque Epic peut être décomposée en un ensemble de Minimum Marketable Features (MMF$$NdT : ensemble de fonctionnalités minimales apportant de la valeur à l’utilisateur$$) qui, ensemble, satisfont l’Epic. A son tour, chacune de ces MMF peut être décomposée en stories de granularité très fine. Cette hiérarchie est décrite dans le schéma ci-dessous :%%% > %%% > ((/dotclear/public/traductions/multi_tier_story_map.png|<>||Multitier Story Map))%%% > %%% > __Tableau Kanban global de l’entreprise__%%% > %%% > Puis, nous créons un tableau Kanban à l’échelle globale de l’entreprise. Ce tableau permet de visualiser le flux des Epics en partant de l’idée initiale jusqu’à sa réalisation. Chaque colonne du tableau représente une étape du workflow des Epics. Il est important ici de s’assurer que ce tableau contient bien le workflow de bout en bout. Quand une Epic atteint l’étape « Développement » du tableau kanban global, les stories associées à l’Epic dans la User Story Map sont transférées dans le tableau kanban de l’équipe. Là, le flux des user stories parcourt le processus de développement de l’équipe et est suivi sur le tableau kanban de l’équipe. Une fois le développement terminé, l’Epic est déplacée de l’étape « Développement » à l’étape suivante.%%% > %%% > ((/dotclear/public/traductions/multi_tier_kanban.png|<>||Multitier Kanban))%%% > %%% > Le schéma montre le processus en action. Les cartes Epics jaunes se déplacent sur le tableau kanban global de l’entreprise. Quand elles atteignent l’étape de « Développement », les cartes Stories bleues associées à chaque Epic parcourt ensuite le processus de l’équipe. Ce qui est bien, du coup, c’est que l’équipe ne doit pas nécessairement faire du Kanban. La même technique peut être utilisée lorsque l’équipe pratique Scrum, XP ou tout autre processus de développement logiciel.%%% > %%% > Donc, utiliser les user story maps et deux niveaux de kanban, nous permet d’étendre Kanban à l’entreprise et de donner de la visibilité sur le worflow des Epics pour les parties prenantes.%%% —- ((/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]++.

Phases et Jalons Agile UP

Hier, j’ai eu une discussion passionnante avec un architecte logiciel qui travaille sur le même projet que moi. Le sujet était de savoir si l’architecture devait être définie et ++stable++ avant de lancer les premiers sprints de développement, disons lors du sprint zéro (selon moi) ou si l’architecture pouvait ++fortement évoluée++ en parallèle des sprints et en y faisant éventuellement participer une partie de l’équipe au travers de technical stories ou de spikes (selon lui). J’ai eu affaire à forte partie (non j’ai pas dit une tête de mule) et il a même réussi à me faire douter en invoquant ++[UP|http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/]++.%%% %%% ((/dotclear/public/photos/.Scott-Ambler_t.jpg|Scott W. Ambler|L|Scott W. Ambler))Ni une, ni deux, j’ai fait quelques recherches sur le sujet et je vous propose ici la traduction des deux articles de __Scott W. Ambler__ :%%% – ++[Agile UP Phases|http://www.ambysoft.com/unifiedprocess/aup11/html/phases.html|en]++%%% – ++[Agile UP Milestones|http://www.ambysoft.com/unifiedprocess/aup11/html/milestones.html|en]++%%% %%% Pour ceux qui souhaiteraient réagir, je vous invite à me laisser un commentaire.%%% %%% —- ((/dotclear/public/logos/logoAgileUP.gif|Agile UP||Agile UP))%%% L’Agile UP peut être considéré à travers ses quatre phases, au travers desquels vous allez vous déplacez. La fin d’une phase est marquée par un jalon et la « revue de jalon » vérifie que votre équipe a bien réussi à remplir les critères du jalon concerné.%%% %%% [((/dotclear/public/traductions/.phasesAndMilestones_m.jpg|Phases et Jalons UP||Phases et Jalons UP))|/dotclear/public/traductions/phasesAndMilestones.gif]%%% %%% ///html

Phase Objectifs Jalon
1. Inception Pour identifier le périmètre initial du projet, une architecture potentielle de votre système, et obtenir un financement initial du projet et la validation des parties prenantes. Objectif défini (LCO)
2. Elaboration Pour valider l’architecture du système. Architecture définie (LCA)
3. Construction Pour construire un logiciel opérationnel sur une base itérative, incrémentale qui répond aux besoins les plus prioritaires des parties prenantes du projet. Première version exploitable (IOC)
4. Transition Pour valider et déployer votre système dans votre environnement de production. Livraison finale (PR)

/// !!1. Phase « Inception » – Jalon « Objectif défini » (LCO$$LCO : Lifecycle Objectives$$)%%% Pour ce jalon, les parties prenantes évaluent l’état du projet. Elles doivent se mettre d’accord sur les points suivants :%%% * __Validation du périmètre.__ Les parties prenantes parviennent à un accord sur le périmètre du projet.%%% * __Validation des besoins initiaux.__ Il y accord sur le fait que l’ensemble des besoins de haut niveau a été recueilli et que tout le monde partage la même compréhension des besoins.%%% * __Validation du planning.__ Les parties prenantes sont d’accord sur les estimations initiales du coût et du calendrier.%%% * __Validation du risque.__ Les risques ont été identifiés, évalués et des stratégies acceptables ont été identifiées pour y remédier.%%% * __Validation du processus.__ L’Agile UP a été initialement adapté et accepté par toutes les parties.%%% * __Faisabilité.__ Le projet a un sens du point de vue métier, technique et opérationnel.%%% * __Planning du projet.__ Un planning adéquat a été défini pour la prochaine phase (Elaboration).%%% * __Respect du portefeuille projets.__ Le périmètre du projet s’inscrit-il bien dans le portefeuille des projets de votre organisation ?%%% !!2. Phase « Elaboration » – Jalon « Architecture définie » (LCA$$LCA : Lifecycle Architecture$$)%%% Pour ce jalon, les parties prenantes évaluent l’état du projet. Ils doivent s’entendre sur les points suivants :%%% * __ Stabilité de la vision.__ La vision du projet est devenue stable et réaliste.%%% * __Stabilité de l’architecture.__ Vous validez le fait que l’architecture est stable et suffisante pour satisfaire les besoins. L’architecture a été prototypée pour faire face aux principaux risques.%%% * __Validation du risque.__ Les risques ont été évalués afin de s’assurer qu’ils ont bien été compris et documentés et qu’une stratégie acceptable a été mise en place pour les traiter.%%% * __Faisabilité.__ Le projet a toujours un sens du point de vue métier, technique et opérationnel.%%% * __Planning du projet.__ Un planning détaillé des itérations à venir lors de la phase de Construction ainsi qu’un planning global du projet ont été élaborés.%%% * __Respect de l’architecture d’entreprise.__ Est-ce que l’architecture du système respecte les règles de l’architecture d’entreprise ?%%% !!3. Phase « Construction » – Jalon « Première version exploitable » (IOC$$IOC : Initial Operating Capacity$$)%%% Pour ce jalon, les parties prenantes doivent s’entendre sur ce qui suit :%%% * __Stabilité du système.__ Le logiciel et la documentation sont validées (stables et mûrs) pour déployer le systèmes aux utilisateurs.%%% * __ Parties prenantes prêtes.__ Les parties prenantes (et le métier) sont prêtes pour que le système soit déployé (à la formation près).%%% * __Validation du risque.__ Les risques ont été évalués afin de s’assurer qu’ils ont bien été compris et documentés et qu’une stratégie acceptable a été mise en place pour les traiter.%%% * __Validation de l’estimation et du coût.__ Le budget consommé à ce jour est acceptable et des estimations raisonnables ont été fournies pour le calendrier et les coûts futurs.%%% * __Planning du projet.__ Un planning détaillé des itérations à venir lors de la phase de Transition ainsi qu’un planning global du projet ont été élaborés.%%% * __Respect de l’architecture d’entreprise.__ Est-ce que le produit développé par l’équipe respecte les standards de l’entreprise ?%%% !!4. Phase « Transition » – Jalon « Livraison finale » (PR$$PR : Product Release$$)%%% Pour ce jalon, les parties prenantes doivent s’entendre sur ce qui suit :%%% * __Validation par les parties prenantes métier.__ Les parties prenantes métier sont satisfaites et valident le système.%%% * __Validation par les opérations.__ Les personnes responsables de l’exploitation du système une fois en production sont satisfaites de la documentation et des procédures d’exploitation.%%% * __Validation par le support.__ Les personnes responsables du support du système une fois en production sont satisfaites de la documentation et des procédures de support.%%% * __Validation de l’estimation et du coût.__ Le budget consommé à ce jour est acceptable et des estimations raisonnables ont été fournies pour les coûts de production futurs.%%% %%% —- ((/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]++.

Jeff Liker : l’essence même de la Méthode Toyota est basée sur le respect des personnes et l’amélioration continue

((/dotclear/public/photos/.jeff-liker_sq.jpg|Jeff Liker|L|Jeff Liker))Le site ++[« The Lean EDGE »|http://theleanedge.org/|en]++ est très intéressant. Régulièrement, une question est soulevée pour solliciter l’avis éclairé de « grands penseurs » Lean. Je vous avais déjà traduit quelques articles de ++[Art Smalley|/dotclear/index.php?q=art+smalley]++, cette fois, j’ai traduit l’article de Jeff Liker$$Auteur de « The Toyota Way » et co-auteur de « Toyota Product Development System »$$ : ++[« The essence of the Toyota Way is respect for people and continuous improvement »|http://theleanedge.org/?p=2321|en]++. %%% > J’ai lu la ++[réponse de Mike Rother|http://theleanedge.org/?p=2307|en]++ et il donne une excellente explication pour laquelle je vais aller encore un peu plus loin. Je pense qu’il y a deux problèmes suggérés par la question initiale « Comment des organisations Lean peuvent-elles valoriser leurs employés si le Lean considère que les dépenses faites pour les ressources – en dehors de celles pour créer de la valeur – sont un gaspillage ? ». Premièrement, la définition du lean en tant que « élimination du gaspillage » est intrinsèquement limitative. Deuxièmement, il y a l’hypothèse implicite que tout ce qu’on doit faire c’est uniquement éliminer les gaspillages, et qu’aucune activité ne devrait être menée sans qu’elle ne soit effectivement considérée comme une « activité à valeur ajoutée ».%%% > %%% > Ces deux hypothèses sont restrictives. Voici quelques exemples d’activités générant du gaspillage et que l’on pourrait éliminer si nous faisions ces deux hypothèses :%%% > %%% > – la maintenance, et en particulier la maintenance préventive%%% > – l’inspection%%% > – la manutention%%% > – la comptabilité%%% > %%% > Je pourrais continuer, mais je pense que vous avez compris. Vous pourriez purement et simplement fermer la société du jour au lendemain si vous deviez « éliminer le gaspillage ».%%% > %%% > Comme Mike Rother l’a laissé entendre, l’essence même de la Méthode Toyota est basée sur le le respect des personnes et l’amélioration continue. __En fait, au sein de Toyota, les gens disent que le respect des personnes est le fondement même de l’amélioration continue. Et un élément clé du respect des personnes est d’investir sur eux, leur formation, la sécurité de leur emploi et sur l’amélioration de leur moral.__ Il est très important de comprendre que le concept d’investissements ne disparaît pas avec le lean.%%% > %%% > Un exemple courant est la réduction de la taille du lot de fabrication qui génère donc beaucoup plus d’aller-retours en termes de manutention. Donc vous investissez volontairement dans une manutention  »a priori » inutile pour réduire les stocks. Ce que vous faites réellement, c’est « abaisser le niveau de l’eau »$$NdT : Théorie des Contraintes et détection des goulots d’étranglements$$ et faire émerger les problèmes afin d’encourager l’amélioration continue.%%% > %%% > __Du point de vue de Toyota, investir sur les gens est l’investissement qui génère le plus grand profit à long terme.__%%% %%% —- ((/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]++.

Rétrospective Scrum Café Bordeaux du 11 janvier 2011

[((/dotclear/public/./.French_SUG_Bordeaux_s.jpg|Logo French Scrum Bordeaux||Logo French Scrum Bordeaux))|/dotclear/public/French_SUG_Bordeaux.jpg]%%% !!What went well%%% * Plus de 20 personnes présentes ! Plein de nouvelles têtes ! Les ++[Arpinum|http://www.arpinum.fr/]++ étaient là !%%% * Philippe Launay, notre animateur, nous a d’abord donné des nouvelles de la Scrum Alliance, ça devrait pas mal bouger en 2011 (++[Agile Leaders|http://groups.google.com/group/agile-leaders|en]++, Bruxelles, Pékin, …).%%% * Il a ensuite proposé deux défis :%%% ** Trouver un nom plus court pour le SUG Bordelais… heu, je propose ABEL pour Agilistes Bordelais En Ligne, A3 pour Association des Agilistes Aquitains, …, vous pouvez faire mieux ?%%% ** ++[Play4Agile|http://brunosbille.com/?p=981&lang=en|en]++, conférence sur les jeux agiles en Allemagne en février 2011 : chiche qu’on fait la même chose à Bordeaux !%%% * Philippe nous a également présenté le Doggy Game, un jeu qui permet d’apprendre à estimer collectivement. Ça a l’air facile ou évident au départ, mais comme tous les jeux que nous propose Philippe, c’est le second effet kiss cool qui compte !%%% * Mathieu Lombard (SoprAgileMan) nous a emmené dans la préparation d’une fête pour des enfants de 10 ans. On a sprinté pendant 45 minutes ! idéal pour découvrir que c’est beaucoup mieux quand le client est sur site et qu’il est disponible, qu’il faut souvent (se forcer à) livrer pour vérifier que les critères de validation sont bien remplis, … bref, du bon sens qu’il faut réapprendre, quand comme moi, on a été lobotomisé par des années de projets menés de façon traditionnelle !%%% !!What went wrong%%% * 11 minutes 58 secondes pour la présentation « Scrum en 5 minutes » : très mauvais exemple de timeboxing. Michael m’a conseillé d’arrêter de constamment traduire les mots anglais…%%% !!Puzzles%%% * Pierre Neis : ++[« Roboscrum – Comment mesurer Scrum pour les équipes hyperproductives »|http://managingagile.blogspot.com/2010/12/roboscrum-comment-mesurer-scrum-pour.html]++ ? slide #39 : la 4ème question ?%%% !!Lessons (re-)learnt%%% * Il vaut mieux être globalement bon que précisément erroné.%%% * Au lieu de passer du temps à ré-estimer, passer du temps à produire.%%% !!Appreciations%%% * Merci à ++[Sopra Group|http://www.sopragroup.fr/]++ qui nous recevait dans ses locaux à Mérignac.%%% * Merci aux orateurs : Philippe Launay, Mathieu Lombard (et ses acolytes Adrien Sifre et Xavier Gouardes).%%% * Merci à mes compagnons de fortune : Romain, Cyprien et Jérôme.%%% * Merci aux participants : Adrien, Xavier, Delphine, Corinne, Jean-Baptiste, Michael, Charles, Christophe, Thierry, et tous les autres…%%% !!References%%% * ++[Journal du French Scrum User Group|http://paper.li/frenchsug]++%%% !!EventList%%% * Prochain Scrum’Café pressenti le 17 février : on recherche une salle et un sponsor…%%% * ++[ScrumDay|http://www.meetup.com/frenchsug/calendar/15691943/]++ fin mars ? !!Feedback%%% * Philippe Launay sur le site du SUG Bordeaux : ++[« Scrum Café du 11 janvier »|https://sites.google.com/site/sugbordeaux/project-updates/scrumcafedu11janvier]++%%% %%% —- ((/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]++.