Tableau avec des tâches, voilà :-(

Je suis récemment tombé sur le taskboard suivant d’un projet dit « agile ».%%% On trouve le temps sur l’axe horizontal, le trigramme du développeur sur l’axe vertical, la tâche affectée à l’intersection.%%% Ne cherchez pas la story…%%% %%% Avez-vous des remarques ? Oui ? Laissez-moi un commentaire.%%% %%% [((/dotclear/public/screenshots/.taskboard_m.jpg|Taskboard||Taskboard))|/dotclear/public/screenshots/taskboard.jpg]

Technique de Timeboxing

((/dotclear/public/photos/steve-ash.jpg|Steve Ash|L|Steve Ash))Suite à mon billet ++[« Technique de priorisation MoSCoW »|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/12/07/Technique-de-priorisation-MoSCoW]++, je continue avec la traduction du document ++[« Timeboxing Briefing Paper »|http://www.dsdm.org/knowledgebase/details/166/timeboxing-briefing-paper.html|en]++ de __Steve Ash__ publié sur la base de connaissances du site du __Consortium DSDM__.%%% %%% Vous trouverez le document traduit ici : ++[« Technique de Timeboxing »|http://www.fabrice-aimetti.fr/dotclear/public/traductions/Timeboxing.pdf]++.%%% %%% Liens pointés par le document original :%%% * ++[DSDM Manual – Timeboxing Section|http://www.dsdm.org/version4/2/public/Timeboxing.asp]++%%% * ++[Timeboxing is an Effective Getting Things Done Strategy|http://www.davecheong.com/2006/07/26/time-boxing-is-an-effective-getting-things-done-strategy/]++%%% —- ((/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]++.

Indicateur de l’Innovation

((/dotclear/public/photos/.Paul-Sloane_sq.jpg|Paul Sloane|L|Paul Sloane))J’ai traduit le questionnaire ++[« Innovation Traffic Light Indicator »|http://www.destination-innovation.com/index.php?page=downloads|en]++ de Paul Sloane. Vous le trouverez ++[ici|/dotclear/public/traductions/Indicateur-Innovation.pdf]++… déprimant 🙁

Technique de priorisation MoSCoW

((/dotclear/public/photos/steve-ash.jpg|Steve Ash|L|Steve Ash))A l’époque, j’avais fait un ++[court billet|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/05/03/MoSCoW]++ sur le concept qui me semblait simpliste, mais en fait je n’avais rien compris… Cette fois, j’ai traduit le document ++[« MoSCoW Prioritisation Briefing Paper »|http://www.dsdm.org/knowledgebase/details/165/moscow-prioritisation-briefing-paper.html|en]++ de __Steve Ash__ publié sur la base de connaissances du site du __Consortium DSDM__. C’est beaucoup plus subtil et étroitement lié au cycle de développement itératif.%%% %%% Vous trouverez le document traduit ici : ++[« Technique de Priorisation MoSCoW »|http://www.fabrice-aimetti.fr/dotclear/public/traductions/MoSCoW_priorisation.pdf]++.%%% %%% Liens pointés par le document original :%%% * ++[Dai Clegg|http://www.evidencefordevelopment.com/newefd/index.php?option=com_content&view=article&id=5|en]++%%% * ++[CASE Method Fast-Track: A RAD Approach|http://www.amazon.ca/Case-Method-Fast-Track-RAD-Approach/dp/020162432X|en]++%%% * ++[Dynamic Systems Development Method Consortium|http://www.dsdm.org/|en]++%%% * ++[Wikipedia – MoSCoW Method|http://en.wikipedia.org/wiki/MoSCoW_Method|en]++%%% —- ((/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]++.

Critère de succès : la taille de l’équipe

J’ai traduit l’article ++[« Key Success Factor 10: Team Size »|http://www.mitre.org/work/sepo/toolkits/ippd/StandardProcess/factors/KSF10.html#footnote|en]++ de Mission Partnering Toolkit.%%% > Il y a eu de nombreuses études sur la performance des équipes en fonction de leur taille. La conclusion générale est que la taille optimale d’une équipe se situe à peu près entre sept et onze personnes. Il s’agit d’un juste équilibre, entre d’une part une équipe avec trop peu de personnes pour assurer la diversité et l’expertise et, d’autre part trop de personnes pour obtenir une pleine participation et une communication ouverte.%%% > %%% > Lorsque les équipes deviennent trop grandes, il leur est très difficile de parvenir à une compréhension commune d’un problème ou d’une situation. Les grandes réunions finissent généralement par des réunions d’information de l’équipe plutôt que la collaboration en équipe. Beaucoup de gens se sentent mal à l’aise lorsqu’il faut participer activement dans de grands groupes, sachant que les discussions sont généralement dominées par un petit nombre de participants.%%% > %%% > Un désaccord officiel est rare dans un grand groupe, sauf quand cela devient une vitrine pour les individus qui se disputent. Dans les deux cas, une véritable collaboration est rare car les participants n’ont pas l’occasion d’interagir dans un environnement collaboratif. Les grandes équipes ne permettent pas facilement aux membres de l’équipe de se connaître et de se faire mutuellement confiance. En outre, les membres de l’équipe ne comprennent pas et ne sont pas conscients des rôles des autres participants, de leurs responsabilités, et de leur niveau de contribution attendu pour le succès de l’équipe.%%% > %%% > D’un autre côté, les équipes de grande taille offrent la possibilité de produire des idées innovantes si elles sont correctement accompagnées. Le soutien officiel de l’organisation sur les principales décisions peut s’avérer difficile sans que des conversations officieuses n’aient d’abord eu lieu. Même lorsqu’une équipe démarre modestement, les gens souhaitent la rejoindre à mesure qu’elle connaît des succès, pour finalement atteindre une taille où l’efficacité de l’équipe régresse.%%% > %%% > Sur le plan de l’efficacité du transfert d’information, les grandes équipes offrent des avantages. Sur le plan de la résolution de problèmes, de la prise de décision et de l’adoption d’une même vision, les grandes équipes peuvent avoir beaucoup de difficulté. La courbe ci-dessous est une représentation nominale de la performance de l’équipe par rapport à la taille de l’équipe.%%% > %%% > ((/dotclear/public/traductions/KSF10graphic-team-size.gif|Performance vs Taille de l’équipe||Performance vs Taille de l’équipe))%%% > %%% > Le niveau de performance d’une équipe est très sensible aux relations individuelles entre les membres de l’équipe. Pour que les équipes atteignent un niveau élevé de collaboration, leurs membres ont besoin de se connaître les uns les autres, de savoir comment travailler ensemble, de développer un sentiment d’implication et de responsabilité mutuelle les uns pour les autres ainsi que pour les enjeux du projet. Comme l’ont noté Katzenbach et Smith (1993) dans leur ouvrage »The Wisdom of Teams », les équipes hautement performantes sont constituées de membres ayant un fort intérêt personnel pour les autres ainsi que pour le respect et la collaboration d’un point de vue professionnel. Les grandes équipes, en raison du nombre impressionnant de personnes, sont incapables de répondre à ce critère.%%% > %%% > Bien que la taille des équipes puisse varier lorsque des gens partent ou rejoignent l’équipe, ces changements ont un double impact sur la performance de l’équipe. Les nouveaux membres prennent leur temps pour s’intégrer à l’équipe et pour contribuer intellectuellement. Une équipe performante est composée de personnes qui se connaissent bien, qui ont appris à travailler ensemble et qui reconnaissent les forces et les faiblesses de leurs coéquipiers. Ils assument également des rôles spécifiques au sein de l’équipe, en fonction des objectifs du moment. Les membres de l’équipe ne peuvent donc pas être remplacés au pied levé tout en maintenant l’efficacité de l’équipe. Même s’il sera toujours nécessaire de changer des membres de l’équipe, l’impact potentiel sur la performance doit être reconnue et traitée efficacement. Des informations complémentaires existent sur la dégradation des performances dans une équipe.%%% > %%% > Cela présente des avantages de faire venir de nouveaux membres dans l’équipe pour en remplacer d’autres. Les nouveaux membres de l’équipe apportent de nouvelles idées et de nouvelles expériences à l’équipe et peuvent permettre de favoriser l’ouverture et la souplesse intellectuelles des autres membres de l’équipe. De nouvelles personnes peuvent permettre de conserver les connaissances de l’équipe pour répondre aux exigences imposées à l’équipe au moment des changement de phases du projet. Bien que l’équipe ait toujours besoin d’un éventail complet d’expertises, certaines phases du projet peuvent mettre davantage l’accent sur une expertise plutôt qu’une autre.%%% > %%% > Finalement, les équipes peuvent devenir si unies et si concentrées qu’elles perdent leur capacité à rester flexibles et ouvertes à d’autres perspectives$$NdT : j’appelle ça la consanguinité :-)$$. Lorsque cela se produit, il est essentiel que du sang neuf arrive dans l’équipe. Le responsable de l’équipe doit s’assurer que la pression des membres de l’équipe sur le nouvel entrant n’empêche pas les discussions ouvertes sur les différentes façons de faire les choses.%%% —- ((/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]++.

Tableau des Epics en Agile

((/dotclear/public/logos/agile101_logo.png|Logo Agile101|L|Logo Agile101))En ce moment, je prépare un atelier pour aider le client à initialiser son backlog produit, et j’ai bien évidemment un problème de granularité des fonctionnalités. Je m’oriente donc tout naturellement vers une approche basée sur les thèmes (domaines fonctionnels = collection de stories ?), les epics (++[grosses stories ?|http://www.aubryconseil.com/post/2007/10/04/305-features-themes-epics-et-stories]++) et les stories. J’en ai profité pour relire et traduire l’article de __Agile101__ : ++[« Agile Epic Board – Epic Card Template »|http://agile101.net/2009/08/20/agile-epic-board-epic-card-template/|en]++.%%% > Le Tableau des Epics est un outil de gestion de programme et de projet, qui est, dans sa forme la plus simple, un plan de release concret$$NdT : Pour une bonne présentation du plan de release, je vous renvoie sur ++[« la présentation de Claude Aubry lors du SigmaT8″|http://www.sigmat.fr/public/SigmaT8/ReleasePlanning-sigmat8.pdf]++.$$.%%% > %%% > Bien que j’utilise ce tableau pour suivre notre programme de développement sur plusieurs produits, équipes et sprints, le Tableau des Epics peut également être un outil de gestion de projet très utile. Voir ++[« The Epic Board – An Essential Project Management Tool »|http://agile101.net/2009/07/25/the-epic-board-an-essential-agile-project-management-tool/|en]++.%%% > %%% > Cet outil peut fonctionner à plusieurs niveaux, c’est à dire pour __suivre la livraison de plusieurs Epics__ associées à un thème particulier __OU la livraison d’un certain nombre de stories__ associées à une Epic ou à une Minimum Marketable Feature (« MMF »)$$NdT : pour les MMF, je vous renvoie à l’aticle de Ismaël Héry : ++[« MMF ou incrément ? »|http://blog.octo.com/mmf-ou-increment/]++.$$. Gardez à l’esprit que cet outil est utilisé pour suivre__ l’état d’avancement sur plusieurs sprints__, sachant que la production d’un sprint spécifique est suivi à l’aide d’un Tableau de Tâches. Voir ++[« La différence entre les termes Agiles Thèmes, Epics et User Stories »|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/20/La-difference-entre-les-termes-Agiles-Themes-Epics-et-User-Stories]++.%%% > %%% > À la demande générale, j’ai mis en place un __modèle simple et générique que vous pourrez utiliser pour produire la Carte d’une Epic__$$NdT : pour télécharger le modèle original au format tableur, je vous renvoie à l’++[article de l’auteur|http://agile101.net/2009/08/20/agile-epic-board-epic-card-template/|en]++, rendons à César ce qui est à César.$$.%%% > [((/dotclear/public/traductions/.agile-epic-board-epic-card_s.jpg|Carte Epic par Agile101||Carte Epic par Agile101))|/dotclear/public/traductions/agile-epic-board-epic-card.jpg]%%% > %%% > __Carte de l’Epic__%%% > %%% > La taille de la carte a été conçue pour qu’elle puisse être collée sur un post-it 5″x8″ (si vous le souhaitez !). %%% > %%% > __Titre__%%% > %%% > C’est le titre de votre Epic, juste assez pour vous rappelez ce que cela représente.%%% > %%% > __Thème__%%% > %%% > L’objectif de niveau supérieur auquel contribue l’Epic. Par exemple, si le thème est « Augmenter le Trafic », l’Epic pourrait être « Lancer une Section Vidéo sur le site Truc ».%%% > %%% > __Product Owner__%%% > %%% > S’explique de lui-même.%%% > %%% > __Date limite__%%% > %%% > Certaines Epics seront pilotées par des échéances, d’autres ne le seront pas.%%% > %%% > __Description__%%% > %%% > Un aperçu de haut niveau de __ce dont traite cette Epic__ : les principaux résultats, … Vous pouvez y ajouter un croquis ou des remarques pour le développement, …%%% > %%% > __Points d’Effort__%%% > %%% > Il s’agit d’une __estimation relative de la quantité d’effort__ requise pour livrer l’Epic par rapport à d’autres Epics et en utilisant les Points de Story. Vous pouvez aussi utiliser les tailles de T-shirt pour établir cette valeur. Voir ++[« Estimation Agile et Cône d’incertitude »|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/21/Estimation-Agile-et-Cone-d-incertitude]++.%%% > %%% > __Points de Valeur__%%% > %%% > Il s’agit d’une __estimation relative de la quantité de valeur__ livrée par cette Epic par rapport à d’autres Epics et en utilisant les Points de Valeur. Vous pouvez aussi utiliser les tailles de T-shirt pour établir cette valeur. Voir ++[« Value Points – Estimating the Relative Value of a User Story »|http://agile101.net/2009/07/22/value-points-estimating-the-relative-value-of-a-user-story/|en]++.%%% > %%% > __Score__%%% > %%% > En un sens, le score pourrait être considéré comme le __ »Bénéfice » apporté par cette Epic__$$NdT : autant parler de Retour sur Investissement (ROI).$$. Il est calculé en point comme suit : Score = Valeur – Effort.%%% > %%% > Ce score aide à prioriser à un niveau macro, ce n’est __pas une science exacte__, juste un outil utile pour mener les conversations.%%% > %%% > __Liste des choses à faire__%%% > %%% > Cette liste__ rappelle ce que vous devez produire pour « terminer » l’Epic__.%%% > %%% > Nous l’utilisons de nombreuses façons, par exemple :%%% > %%% > 1. __Une liste des User Stories__ (pas la User Story en entier, juste un rappel) requises pour terminer et livrer l’Epic. Nous distinguons ensuite les « Incontournables »$$Must-Haves$$ et les « Souhaitables »$$Nice-To-Haves$$ OU nous découpons sous forme de MMF.%%% > 2. __Une liste de produits/sites__ impliqués dans une mise à niveau majeure ; nous avons besoin de cocher que nous avons bien tout testé, livré et que nous avons procédé à la mise à jour.%%% > %%% > Ce modèle permet donc de générer __une carte individuelle pour chaque élément de la liste des choses à faire__. Ces cartes peuvent ensuite être regroupées dans des sprints sur le Tableau des Epics. Voir ++[« Introducing the Agile Epic Board »|http://agile101.net/2009/07/08/introducing-the-agile-epic-board/|en]++ pour des photos.%%% > %%% > Nous repassons sur cette carte à la fin de chaque sprint (à la réunion de Planification du Programme/Revue de Sprint) et __ nous cochons tout ce qui est terminé__.%%% > %%% > Vous pouvez également, sans trop de difficultés, __générer un burndown chart de la release__ au dos de la carte. Je pourrais peut être vous __proposer une version améliorée de ce modèle qui vous permet de le faire__.%%% > %%% > __Pour une vue plus détaillée (et quelques photos) sur la façon de construire et d’utiliser un Tableau d’Epics, je vous invite à consulter ++[« Agile Epic Board Channel » sur Agile101|http://agile101.net/category/programme-management/agile-epic-board/|en]++.__%%% —- ((/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]++.

Speed Boat Game

((/dotclear/public/./.speedboat_t.jpg|Speed Boat Game|L|Speed Boat Game))Cette semaine, j’ai mené un atelier __Speed Boat Game__ avec mon client pour identifier ce qu’il n’appréciait pas dans le produit ou le service rendu par son fournisseur bien-aimé. Le Speed Boat Game est décrit dans le livre ++[Innovation Games|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/11/28/Innovation-games-:-creer-des-produits-novateurs-grace-aux-jeux-collaboratifs]++ de Luke Hohmann.%%% %%% Lors d’un ++[SUG bordelais|http://sites.google.com/site/sugbordeaux/]++, Philippe Launay nous avait donné l’occasion de pratiquer ce jeu et nous avait fait un retour d’expérience sur son utilisation dans le cadre d’une relation client-fournisseur complexe et dégradée.%%% %%% Mes points d’amélioration :%%% * Prévoir une salle de réunion permettant à chaque personne de se lever pour poser ses post-it sur le mur ; là ce n’était pas possible compte tenu de la taille de la salle et de la disposition des tables et du vidéo-projecteur ; pourtant Luke dit bien d’y prêter la plus grande attention dans son bouquin… mouarf, ça m’apprendra à survoler les chapitres !%%% * Etre prudent sur l’indication de la vitesse que l’on pourrait gagner si l’ancre était levée : ça a faussé notre appréciation du poids des ancres. Résultat, lorsque j’ai demandé de voter un top 3 des ancres les plus lourdes, nous sommes partis sur une algorithmie hasardeuse. Donc pas de vitesse, KISS$$Keep It Simple and Stupid$$.%%% * Etre prudent lorsqu’on demande aux personnes de proposer des moteurs ; nous avons quitté la phase de recueil des problèmes pour très vite tomber dans le « y a qu’à… faut qu’on… » ; du coup j’étais bien content d’arriver au bout de mon timeboxing (se forcer à livrer) et j’ai pu écourter cette phase expérimentale : je ne le referai plus ou alors dans un atelier dédié.%%% %%% Le ROTI$$Return On Time Invested$$ était quand même bon :-)%%%