<?xml version="1.0" encoding="utf-8"?> <?xml-stylesheet title="XSL formatting" type="text/xsl" href="/atom.xsl" ?> <feed xmlns="http://www.w3.org/2005/Atom" xml:lang="fr"> <title>Agile</title> <link rel="self" type="application/atom+xml" href="http://agile.blogspirit.com/atom.xml"/> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/" /> <subtitle>Un journal de l'Agilité, de Scrum à Hydro-Québec, Montreal</subtitle> <updated>2008-08-19T11:54:57+02:00</updated> <rights>All Rights Reserved blogSpirit</rights> <generator uri="http://www.blogspirit.com/" version="5.0">blogSpirit.com</generator> <id>http://agile.blogspirit.com/</id>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>CMMI et Agilité</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2008/07/29/cmmi-et-agilite.html" />  <id>tag:agile.blogspirit.com,2008-07-29:1601968</id> <updated>2008-07-30T01:22:54+02:00</updated> <published>2008-07-29T22:50:00+02:00</published>   <category term="Scrum" scheme="http://www.blogspirit.com/ns/types#category" />    <summary> Chez nous on est en train de débuter un programme autour du CMMI....</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> &lt;p&gt;Chez nous on est en train de débuter un programme autour du CMMI. Actuellement on est en train de voir à quel niveau nos équipes sont. Sur papier on est à au moins au niveau 3 car notre méthodologie actuelle (Centre Productivité P+) est full CMMI. Le problème n'est pas avec le niveau de maturité de la méthode mais plutôt avec celui de l'utilisation de la méthode. D'une équipe à une autre il y a effectivement de grandes variations dans la compréhension et la maitrise de la méthode.&lt;/p&gt; &lt;p&gt;Comme je me fais le promoteur de l'agilité dans notre entreprise, et que la tendance va être à la &quot;certification&quot; CMMI, je ressort la litérature existante sur le sujet. Généralement il n'y a pas d'incompatibilité entre les approches agiles et le CMMI, tout comme il n'y en avait pas avec le PMBOK. Souvent c'est une incompréhension des divers éléments en cause qui ammène une perception négative.&lt;/p&gt; &lt;p&gt;Ainsi à la base, le cadre du CMMI indique les pratiques qui doivent être mise en ouevre par les organisations et non comment les mettre en oeuvre. Or les approches agile décrivent pluôt comment mettre en oeuvre les pratiques. Donc pas d'incompatibilité fondamentale.&lt;/p&gt; &lt;p&gt;Il est possible cependant qu'une approche agile ne couvre pas tous les aspects (KPA) d'un niveau CMMI donné. C'est le cas de SCRUM qui se concentre plus sur la gestion de projet que sur les pratiques d'ingénieries logiciels prescrites par le CMMI et les bonnes pratiques en générale. C'est d'ailleur la raison pour laquel j'utilise rarement SCRUM seul.&lt;/p&gt; &lt;p&gt;Comme il faut s'y attendre il existe déjà le site &lt;a href=&quot;http://www.agilecmmi.com/&quot;&gt;http://www.agilecmmi.com/&lt;/a&gt;.&amp;nbsp;&lt;/p&gt; &lt;p&gt;Dans la littérature on trouve par exemple&amp;nbsp;la façon dont MicroSoft a rendu sa &lt;a target=&quot;_blank&quot; href=&quot;http://www.agilemanagement.net/Articles/Papers/StretchingAgiletoFitCMMIL.html&quot;&gt;méthologie agile au niveau 3&lt;/a&gt;. La &lt;a target=&quot;_blank&quot; href=&quot;http://www.agilemanagement.net/Articles/Papers/Agile_2005_Paper_DJA_v1_5.pdf&quot;&gt;présentation de 2005&lt;/a&gt; (en PDF) montre comment a été conçu MSF for Agile.&lt;/p&gt; &lt;p&gt;Jeff Dalton, un évaluateur CMMI à un &lt;a target=&quot;_blank&quot; href=&quot;http://askthecmmiappraiser.blogspot.com/&quot;&gt;blog intéressant&lt;/a&gt; sur CMMI et l'agilité. Un autre blog intéressant est celui de &lt;a target=&quot;_blank&quot; href=&quot;http://herdingcats.typepad.com/my_weblog/2005/11/cmmi_and_agile.html&quot;&gt;Glen Alleman&lt;/a&gt;.&lt;/p&gt; &lt;p&gt;Le &lt;a target=&quot;_blank&quot; href=&quot;http://www.agile-itea.org/public/papers/Pikkarainen_Mantyniemi_Agile_CMMI_camera_ready.pdf&quot;&gt;papier présenté en 2006&lt;/a&gt; au SPICE discute de 3 études de cas de CMMI dans un contexte agile&lt;/p&gt; &lt;p&gt;L'excellente revue (militaire) CrossTalk discute dans un &lt;a target=&quot;_blank&quot; href=&quot;http://www.stsc.hill.af.mil/CrossTalk/2007/04/0704Turner.html&quot;&gt;article&amp;nbsp;de 2007&lt;/a&gt; des processus d'ingénierie, de l'agilité et de la maturité. D'ailleur tout le numéro &lt;a target=&quot;_blank&quot; href=&quot;http://www.stsc.hill.af.mil/crosstalk/2007/04/index.html&quot;&gt;d'avril 2007 de CrossTalk&lt;/a&gt; est consacré à l'agilité et adresse la maturité. En février 2008 on trouve un &lt;a target=&quot;_blank&quot; href=&quot;http://www.stsc.hill.af.mil/crosstalk/2008/02/0802jones.html&quot;&gt;excellent article de Capers Jones&lt;/a&gt; qui présente des données touchant les bénéfices du CMMI et de l'agilité et des approches hybrides.&lt;/p&gt; &lt;p&gt;Un &lt;a target=&quot;_blank&quot; href=&quot;http://www.drdobbsjournal.com/architect/184415287&quot;&gt;article de Dr. Dobbs&lt;/a&gt; discute des approches agiles (valeurs de base) du TSP (Team Software Process) et du CMMI en général.&lt;/p&gt; </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>Transformer les applications d'entreprise par le web 2.0</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2008/07/25/transformer-les-applications-d-entreprise-par-le-web-2-0.html" />  <id>tag:agile.blogspirit.com,2008-07-25:1599879</id> <updated>2008-07-26T21:29:39+02:00</updated> <published>2008-07-25T18:40:00+02:00</published>   <category term="web 2.0" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary> Avec tout le brouhaha autour du web 2.0 depuis quelques années, je me suis...</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> &lt;p&gt;Avec tout le brouhaha autour du web 2.0 depuis quelques années, je me suis pencher sur la question de comment le web 2.0 pouvait nous aider à améliorer les applications que nous construisons pour nos entreprises. Il faut l'admettre, en effet, nos applications sont assez &quot;classiques&quot;, pour ne pas dire franchement &quot;platte&quot;. J'entends par là qu'elle font le travail, mais sans plus.&lt;/p&gt; &lt;p&gt;Parmi les dimensions importantes du web 2.0 on trouve &lt;strong&gt;l'aspect social&lt;/strong&gt;, la contributiion des utilisateurs et l'effet réseau. Or sur ces plans, nos applications font généralement piètre figure, principalement parce qu'elle ne sont pas concues avec ce point de vue.&lt;/p&gt; &lt;p&gt;Par exemple, lorsque nous modélisons les besoins, on considère les cas d'utilisation de chacun des acteurs séparéments. L'acteur A consulte une information XYZ. On ne tient pas compte du fait que Jean consulte XYZ, Marie consulte ABC et Paul consulte MNOP et&amp;nbsp;aussi XYZ. Or le simple fait d'exécuter le cas d'utilisation procure de l'information utile. Par exemple XYZ semble être populaire actuellement, et peut-être qu'il serait pertinent de dire à ceux qui&amp;nbsp;consulte XYZ que MNOP pourrait être intéressant.&lt;/p&gt; &lt;p&gt;Ainsi il m'apparaît que certaines fonctionnalités pourraient être ajouter à nos applications, parfois sans grands efforts.&lt;/p&gt; &lt;p&gt;Voiçi quelques exemples:&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;simplification de l'interface utilisateur&lt;/strong&gt;. On veut souvent mettre toutes les possibilités d'interactions et d'informations sur des écrans qui finissent par être surchargés. Bien que cette caractéristique soit un effet de bord de la méthode de développement (en cascade, juste une chance pour émettre le besoin, alors on ne prend pas de chance, on l'ajoute!), il reste que les applications web 2.0 on souvent des interfaces épurées, simples et concentrées sur une fonction à la fois.&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;informer l'utilisateur sur la &quot;fraîcheur&quot; de l'information&lt;/strong&gt;. Beaucoup de système d'entreprise conservent les dates de création et de modifications des informations, mais peu exploitent cette information. Il est pourtant simple d'afficher une liste des dernières informations modifiées ou créées dans une format simple à lire comme &quot;il y a 1 heure&quot;, ou &quot;mis à jour il y 2 semaines&quot;. S'il vous plait n'affichez pas la date brut!&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;évaluations&lt;/strong&gt;. Une façon simple de permettre aux utilisateurs de contribuer du contenu est de leur permettre de voter sur un élément d'information. Par exemple, est-ce que l'information est importante? Utile? De qualité? L'évaluation peut être annonyme ou requérir une autentification selon les besoins. L'information ainsi contribuée permettra me mettre de l'avant les informations ayant une meilleure cote par exemple.&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;commentaires&lt;/strong&gt;. Une autre façon de permettre une contribution est d'offrir aux utilisateurs la possibilité d'ajouter un commentaire, lié à une information. Règle générale, lorsque nos systèmes ont un champ commentaire, ceux-çi sont retreint aux utilisateurs &quot;officiels&quot; du système. Pourquoi ne pas ouvrir l'ajout de commentaires à tous? On pourrait pousser plus loin et parler de &quot;revue&quot; de l'information.&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;trace des visites&lt;/strong&gt;. Une application a tout le loisir de garder une trace de ce que les utilisateurs font durant une session. Cette information peu servir a découvrir quels sont les fonctions, les champs et les informations les plus visitées et par conséquent les plus utiles dans le système, par exemple les informations les plus consultées. Ces traces permettent d'établir des patterns dans les données, par exemple &quot;ceux ont consulté XYZ ont aussi consulté ABC&quot;. D'un coté cela permet de faciliter la navigation de l'utilisateur et de l'autre de lui faire découvrir des informations qu'il ne connaissait pas.&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;touche personnelle&lt;/strong&gt;. Il est souvent relativement simple d'identifier l'utilisateur, car la plupart des systèmes d'entreprise sont sécurisé et requiert une authentification. Tout les systèmes auxquels j'accède savent que je suis Jean Desbiens, mais peu s'en préoccupe. Sachant que je me reconnecte, pourquoi ne pas me présenter les informations que j'ai créés ou modifiés&amp;nbsp;récemments, pourquoi ne pas se souvenir des recherches que j'ai effectuées. Pourquoi ne pas me montrer les informations que je partage avec mon groupe de travail? Beaucoup de choses peuvent être faites qui font que je me sente supporté personnellement par l'application plutôt que de façon anonyme.&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;liste en format RSS&lt;/strong&gt;. La plupart des applications web permettent de sauvegarder les listes affichées sous un format Excel ou CSV, pourquoi ne pas ajouter le format RSS? Ce n'est pas plus difficile et en plus ça peut facilement être consommé par d'autres applications! C'est probablement la façon la plus simple de permetttre à une tierce application de souscrire aux informations de l'application et de permettre les mashups.&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;recherche en format RSS&lt;/strong&gt;. Une fois les listes de l'applications disponibles en format RSS, pourquoi ne pas permettre d'interroger l'application dans le même format. Il s'agit simplement de permettre à la fonction de recherche de recevoir ses paramètres par un URL simple et de retourner un fichier RSS ou un autre microformat, ou carrément un XML.&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;édition ouverte&lt;/strong&gt;. Nos applications sont souvent très sécurisées, limitées a un groupe d'utilisateur restreint et la publication de l'information passe même parfois par un flux de travail (workflow) complexe d'approbation. Peut-être est-il temps de voir quel effet aurait une ouverture plus large aux utilisateurs, sur le modèle de wikipedia. A bas les approbations! Responsabilisons les utilisateurs! (Ca ne veux pas dire qu'on ne garde pas de trace des modifications ou qu'il n'y a pas un processus de modération).&lt;/p&gt; &lt;p&gt;- &lt;strong&gt;API, Application Programming Interface&lt;/strong&gt;. La plupart de nos systèmes sont conçu principalement en fonction des besoins des utilisateurs (interactif) et des liens avec d'autres systèmes planifiés lors de l'élaboration des besoins. Ceci fait que les systèmes sont souvent fortement couplés et que ces interfaces sont très &quot;privé&quot;. Un premier pas vers les architectures de services est de concevoir les systèmes comme une portion &quot;présentation&quot; et une portion &quot;services&quot; en gardant le couplage entre les deux au minimum. Et publiez cette interface de services ou API afin que d'autres puissent utiliser les informations de l'applications de nouvelles façons, qui apporterons de la valeur à l'entreprise.&lt;/p&gt; &lt;p&gt;Voilà quelques idées pour introduire un peu de web 2.0 dans vous applications.&lt;/p&gt; </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>Présentation de la mêlée quotidienne au Groupe Agile Montreal</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2008/05/28/presentation-de-la-melee-quotidienne-au-groupe-agile-montrea.html" />  <id>tag:agile.blogspirit.com,2008-05-28:1561230</id> <updated>2008-05-29T17:18:12+02:00</updated> <published>2008-05-29T10:35:00+02:00</published>   <category term="Mêlée quotidienne" scheme="http://www.blogspirit.com/ns/types#category" />    <category term="standup" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="mêlée" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="scrum" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="agile montreal" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary> Hier soir j'ai présenté la technique de la mêlée quotidienne (standup...</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> &lt;p&gt;Hier soir j'ai présenté la technique de la mêlée quotidienne (standup meeting ou daily crum) à une vingtaine de membres du &lt;a target=&quot;_blank&quot; href=&quot;http://www.pyxis-tech.com/agilemontreal/fr/index.php&quot;&gt;Groupe Agile de&amp;nbsp;Montreal&lt;/a&gt;.&amp;nbsp;&lt;/p&gt; &lt;p&gt;Ma &lt;a target=&quot;_blank&quot; href=&quot;http://cid-e7d1b14283dc5541.skydrive.live.com/self.aspx/Public/M%c3%aal%c3%a9e%20quotidienne.ppt&quot; title=&quot;Powerpoint 2.6 Mb&quot;&gt;présentation&lt;/a&gt; en format PowerPoint est basé sur un &lt;a target=&quot;_blank&quot; href=&quot;http://agile.blogspirit.com/melee_quotidienne/&quot; title=&quot;Article francais sur la mêlée quotidienne par Jean Desbiens&quot;&gt;article sous forme de pattern&lt;/a&gt; que j'ai écrit. Vous pourrez aussi vous référer à l'article de &lt;a target=&quot;_blank&quot; href=&quot;http://martinfowler.com/articles/itsNotJustStandingUp.html&quot;&gt;Jason Yip&lt;/a&gt;, que je considère le meilleur article sur le standup&amp;nbsp;meeting. Mike Coan a aussi un &lt;a target=&quot;_blank&quot; href=&quot;http://agile.blogspirit.com/archive/2005/12/16/mauvaises-odeurs-de-scrum.html&quot;&gt;article sur les smells&lt;/a&gt; reliés au daily scrum.&lt;/p&gt; &lt;p&gt;Merci à tous les participants, vos commentaires ont rendu la présentation plus intéressante, j'en suis certain. J'ai d'ailleurs incorpore quelques modifications à la présentation.&lt;/p&gt; </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>Automatisation des tests WPF</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2008/05/03/automatisation-des-tests-wpf.html" />  <id>tag:agile.blogspirit.com,2008-05-03:1543163</id> <updated>2008-05-03T23:29:27+02:00</updated> <published>2008-05-03T23:29:27+02:00</published>   <category term="Tests" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="XBAP" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="WPF" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary>  www.thoughtworks.com &amp;nbsp;a un nouveau framework de test, nommé  White...</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> &lt;p&gt;&lt;a href=&quot;http://www.codeplex.com/www.thoughtworks.com&quot; class=&quot;externalLink&quot;&gt;www.thoughtworks.com&lt;/a&gt;&amp;nbsp;a un nouveau framework de test, nommé &lt;a target=&quot;_blank&quot; href=&quot;http://www.codeplex.com/white&quot;&gt;White&lt;/a&gt;,&amp;nbsp;qui permet d'automatiser les tests fonctionnels via l'interface des applications WPF (XBAP).&lt;/p&gt; &lt;p&gt;Nous allons y jeter un coup d'oeil car notre première recherche ne s'était pas avérée fructueuse (voir &lt;a href=&quot;http://agile.blogspirit.com/archive/2007/10/05/tests-dans-visualstudio-suite.html&quot;&gt;http://agile.blogspirit.com/archive/2007/10/05/tests-dans-visualstudio-suite.html&lt;/a&gt;). En espérant que ce nouveau framework sera intéressant. Ca devrait être le cas, car généralement thoughtworks produit des choses intéressantes. Je pense par exemple à &lt;a href=&quot;http://selenium.openqa.org/&quot;&gt;Selenium&lt;/a&gt; pour les tests web.&lt;/p&gt; </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>Présentation Intracom2008</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2008/05/03/presentation-intracom2008.html" />  <id>tag:agile.blogspirit.com,2008-05-03:1543154</id> <updated>2008-05-03T23:07:10+02:00</updated> <published>2008-05-03T23:00:00+02:00</published>   <category term="Intracom" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="web" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="intégration" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary> Jeudi dernier, le 1er mai 2008, je donnais, à l'invitation de Louise Loyer,...</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> &lt;p&gt;Jeudi dernier, le 1er mai 2008, je donnais, à l'invitation de Louise Loyer, présidente de l&quot;Association des Profressionnels en Intranets, Internet et Extranets (&lt;a href=&quot;http://www.api-quebec.ca/&quot;&gt;http://www.api-quebec.ca/&lt;/a&gt;), une présentation intitulée &quot;&lt;strong&gt;&lt;a target=&quot;_blank&quot; href=&quot;http://www.intracom2008.com/conference-integration_applications_interface.php&quot;&gt;Comment intégrer des applications diverses dans l'interface d'un site Web&lt;/a&gt;&lt;/strong&gt;&quot;.&lt;/p&gt; &lt;p&gt;La présentation se trouve &lt;a href=&quot;http://cid-e7d1b14283dc5541.skydrive.live.com/self.aspx/Public/Intracom2008%20v10.ppt&quot;&gt;ici&lt;/a&gt;. Comme mes présentations sont très visuelle, vous trouverez le &lt;a target=&quot;_blank&quot; href=&quot;http://cid-e7d1b14283dc5541.skydrive.live.com/self.aspx/Public/Conf%c3%a9rence%20texte.doc&quot;&gt;texte ici&lt;/a&gt;.&lt;/p&gt; </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>CSAF08</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2008/04/15/csaf08.html" />  <id>tag:agile.blogspirit.com,2008-04-15:1530128</id> <updated>2008-04-15T18:49:35+02:00</updated> <published>2008-04-15T18:49:35+02:00</published>   <category term="MicroSoft" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="CSAF" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary> MicroSoft Canadian Strategic Architect Forum 2008 – Vancouver, Canada    La...</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> MicroSoft Canadian Strategic Architect Forum 2008 – Vancouver, Canada&lt;br /&gt; &lt;br /&gt; La semaine dernière j'assistais au &lt;a target=&quot;_blank&quot; href=&quot;http://csaf08.com/default.aspx&quot;&gt;CSAF&lt;/a&gt;, un événement commandité par MicroSoft Canada et qui regroupait une centaine d'architectes de grandes entreprises canadienne (plusieurs de plus de 1000 employés et beaucoup de moins de 1000).&lt;br /&gt; &lt;br /&gt; Représentant la région de Montréal, il y avait des entreprises comme Hydro-Québec, Bombardier Aéronautique, Canadien National et Radio-Canada.&lt;br /&gt; &lt;br /&gt; Il y avait des keynotes à saveur plus business et des breakouts sessions plus technique regroupé autour de 3 tracks (entreprise and solution architecture, infrastructure architecture, Microsoft application platform).&lt;br /&gt; &lt;br /&gt; Les présentations les plus intéressantes étaient celles à saveur business.&lt;br /&gt; &lt;br /&gt; La meilleure fut celle de &lt;a target=&quot;_blank&quot; href=&quot;http://silverlight.services.live.com/invoke/61525/KeynoteRichardCleaver/iframe.html&quot;&gt;Richard Cleaver&lt;/a&gt; de Bank Of Montreal, qui est une présentateur hors pair. Son message sur le rôle de l'architecte d'entreprise se résume ainsi :&lt;br /&gt; &lt;br /&gt; - connaître le contexte (know the context)&lt;br /&gt; - établir une vision du futur (chart the future)&lt;br /&gt; - faire la différence (make a difference)&lt;br /&gt; &lt;br /&gt; Sa présentation fut inspirante par rapport au rôle d'architecte d'entreprise mais aussi à titre de présentateur. Je compte bien m'inspirer de son approche pour ma prochaine présentation à &lt;a target=&quot;_blank&quot; href=&quot;http://www.intracom2008.com/conference-integration_applications_interface.php&quot;&gt;l'Intracom 2008&lt;/a&gt;.&lt;br /&gt; &lt;br /&gt; &lt;a target=&quot;_blank&quot; href=&quot;http://silverlight.services.live.com/invoke/61525/KeynoteNormJudah/iframe.html&quot;&gt;Norm Judah&lt;/a&gt; de Microsoft nous a présenter quelques technologies qui vont amener des &quot;discontinuités&quot;. C'est-à-dire de technologies qui change la donne et qui transforme le monde. Il nous a montrer un &lt;a target=&quot;_blank&quot; href=&quot;http://blogs.msdn.com/healthblog/archive/2007/08/02/future-vision-microsoft-knowledge-driven-health.aspx&quot;&gt;vidéo, fort apprécié&lt;/a&gt;, qui résume bien la vision du futur que Microsoft peut avoir.&lt;br /&gt; &lt;br /&gt; Le keynote de &lt;a target=&quot;_blank&quot; href=&quot;http://silverlight.services.live.com/invoke/61525/AligningITwithBusinessStrategyPerformance/iframe.html&quot;&gt;Stephen Ibaraki&lt;/a&gt; était plate comme un carré de sable au milieu du Sahara, mais le message était important. Essentiellement, que pour conserver sa position en terme de qualité de vie, le Canada doit innover et que nous comme personne devenions ce qu'il appelle des &quot;versatilists&quot;, des &quot;multi-spécialistes&quot;. Il a aussi parlé de la génération Y et de l'impact qu'elle aura dans les prochaines années. Il a aussi présenté une approche basée sur le plan d'affaire pour répondre à l'érosion de notre part de marché sur le plan mondial.&lt;br /&gt; &lt;br /&gt; Le keynote de &lt;a target=&quot;_blank&quot; href=&quot;http://silverlight.services.live.com/invoke/61525/EAEverythingAligned/iframe.html&quot;&gt;Gary Doucet&lt;/a&gt; du Gouvernement du Canada, était intéressant pour l'envergure du problème considérée (l'architecture d'entreprise au GC) et par sa vision de l'architecture d'entreprise qui est essentiellement l'architecture de l'entreprise, donc comment architecturer les fonctions et l'organisation de l'entreprise, indépendamment des technologies de l'information.&lt;br /&gt; &lt;br /&gt; Le reste des présentations étaient plus technique et m'ont moins frappé sauf peut-être celle sur la plate-forme &lt;a target=&quot;_blank&quot; href=&quot;http://dev.live.com/&quot;&gt;MicroSoft Live&lt;/a&gt;.&lt;br /&gt; &lt;br /&gt; Finalement la grande valeur de ce forum ce sont les échanges que l'on a avec les collègues dans les autres entreprises. </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>Fonctionnement de la mêlée quotidienne</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2007/10/23/fonctionnement-de-la-melee-quotidienne.html" />  <id>tag:agile.blogspirit.com,2007-10-23:1405058</id> <updated>2007-10-23T21:00:07+02:00</updated> <published>2007-10-23T20:55:00+02:00</published>   <category term="Mêlée quotidienne" scheme="http://www.blogspirit.com/ns/types#category" />    <category term="Mêlée quotidienne" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="pattern" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary> Mêlée quotidienne      Vous désirez améliorer la communication afin de...</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> &lt;p&gt;Mêlée quotidienne&lt;br /&gt; &lt;br /&gt; &lt;br /&gt; Vous désirez améliorer la communication afin de faciliter la synchronisation et la coordination des efforts de chacun.&lt;br /&gt; Toute l'équipe est très occupée, le contexte de travail évolue rapidement. La pression monte, les personnes se concentrent sur leurs tâches et s'isolent. On prend moins le temps de se tenir au courant et on garde nos petits problèmes pour soi. L'équipe a de la difficulté à savoir où en sont les choses, à voir comment elles progressent et ce qui freine la progression. Les efforts de l'équipe sont dispersés, la motivation et l'énergie diminuent. Il faut trouver un moyen d'informer tout le monde de ce qui se passe dans le projet, d'empêcher les petits problèmes de grossir, et ce, sans perdre de temps en longues réunions.&lt;br /&gt; &lt;br /&gt; Il y a beaucoup de personnes à informer et cette information évolue rapidement. Les rencontres de suivi ne sont pas assez fréquentes ou sont trop longues. Il est de plus difficile de planifier des rencontres avec beaucoup d'intervenants. Les rencontres ad hoc ne rejoignent pas toutes les personnes impactées par l'information. D'un autre coté, si on implique tout le monde, certaines ne seront pas intéressées par le sujet discuté. L'organisation de plusieurs rencontres est coûteuse et requiert beaucoup de temps.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Par conséquent :&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; Remplacez certaine de ces rencontres par une mêlée quotidienne, ouverte à tous, d'une durée de 15 minutes, où les participants répondent à trois questions.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;La mêlée quotidienne permet :&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; - De communiquer rapidement et efficacement aux membres de l'équipe et aux observateurs l'information pertinente, l'état, le plan et la progression du projet ;&lt;br /&gt; - De concerter les actions de la journée;&lt;br /&gt; - D'identifier rapidement les obstacles et écueils rencontrés par l'équipe afin de trouver des solutions rapides;&lt;br /&gt; - D'augmenter l'esprit d'équipe, la collaboration et la communication.&lt;br /&gt; - De donner la visibilité à l'avancement des travaux;&lt;br /&gt; - De donner un rythme à l'équipe;&lt;br /&gt; - D'obtenir un engagement de chacun des membres.&lt;br /&gt; &amp;nbsp;&lt;/p&gt; &lt;p&gt;Cette technique est aussi connue sous les noms suivants : «daily scrum», «stand-up meeting» dans XP, «morning roll call» dans FDD et «daily wash-in» dans DSDM.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Ouvert à tous&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; De nombreuses personnes sont intéressées par l'information d'un projet, soit en contribuant à l'information, soit en étant intéressées par le contenu. Il peut s'agir d'information sur l'état d'avancement, d'éléments de discussion, de situations qui freinent l'avancement des travaux, ou toute autre information d'intérêt général.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Par conséquent :&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Toutes personnes intéressées ou pouvant contribuer de l'information doivent participer à la mêlée quotidienne.&lt;br /&gt; &lt;br /&gt; En ouvrant la participation à tous les intéressés, on rejoint un grand nombre de personnes d'un seul coup. La présence à la mêlée est obligatoire, ce qui facilite l'organisation.&lt;br /&gt; &lt;br /&gt; Profiter de la présence de tous pour décider d'éléments demandant l'aval de tous. Si la décision ne peut être prise immédiatement, convenez d'un plan d'action pour y parvenir. Par exemple…&lt;br /&gt; &lt;br /&gt; Rejoindre un grand nombre de personnes peut être difficile. Pour faciliter l'organisation des mêlées quotidiennes, celles-ci auront toujours lieu à la même heure tous les jours et au même endroit.&lt;br /&gt; &lt;br /&gt; Cependant, le nombre de participant peut devenir important, ce qui tend à allonger la durée de la rencontre et réduire le niveau d'énergie. Par conséquent, le nombre de participants devrait être limité à 10 personnes maximum. Comme toutes les personnes ne sont pas directement impliquées, certaines peuvent faire dérailler la rencontre, ceci suggère qu'un autre type de rencontre peut être envisagé pour répondre à leurs besoins ou une séparation des rôles en «cochons et poules».&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Fermer le cercle. Tour de table.&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Il est important que toutes les informations soient partagées de la façon la plus transparente et libre possible. Dans certaines organisations fortement hiérarchiques, les participants peuvent être intimidé par la présence de supérieurs, de figures d'autorités ou de personnes qui leurs sont inconnues et retenir certaines informations. Par conséquent, Egalitaire, safe place.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Moins de 15 minutes&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; L'attention des personnes tend à diminuer rapidement, en particulier si elles ne sont pas concernées ou si elles ne participent pas aux échanges. Une durée fixe (timebox) facilite la planification. Après 15 minutes, les personnes sentent qu'elles perdent leur temps.&lt;br /&gt; &lt;br /&gt; Certaines personnes peuvent avoir de la difficulté à se dégager pour de longues périodes.&lt;br /&gt; &lt;br /&gt; Par conséquent, limitez la durée de la mêlée à 15 minutes maximum, si possible.&lt;br /&gt; &lt;br /&gt; Une durée de 15 minutes permet de garder un niveau d'énergie élevé.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Tout le monde debout. Chronométrer la durée.&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; On peut se servir d'une échéance quotidienne pour forcer la fin de la mêlée. Par exemple, une équipe débutait les mêléeS à 11h30 pour terminer au plus tard à 11h45. 11h45 étant l'heure ultime pour aller déplacer sa voiture en raison des heures de stationnement.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Trois questions&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; On désire faire ressortir l'information pertinente à la synchronisation et à la coordination des efforts. On désire identifier les éléments qui freinent ou bloquent le travail à réaliser. Poser des questions trop pointues limite l'expression des membres de l'équipe, alors que des questions floues risquent de ne pas apporter les éléments d'information requis. Poser un grand nombre de questions augmente la complexité et rallonge la rencontre, alors que poser une question unique n'offre pas une grande richesse de perspective. La nature humaine, cherchant à plaire, on peut être tenté d'ignorer des petits problèmes en se disant qu'ils vont se régler rapidement et qu'on n'est pas obligé d'en parler à tout le monde.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Par conséquent, chaque membre de l'équipe répond, en environ une minute, aux trois questions suivantes :&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; - Ce que j'ai fait depuis la dernière mêlée…&lt;br /&gt; - Ce que je compte faire d'ici à la prochaine mêlée…&lt;br /&gt; - Ce qui me bloque ou me ralentit…&lt;br /&gt; &amp;nbsp;&lt;/p&gt; &lt;p&gt;Ces trois questions sont simples, directes et ouvertes. Elles offrent une perspective sur le passé, le futur et le présent. Elles permettent à chacun d'identifier les opportunités de synchronisation et de coordination des travaux. L'identification des bloqueurs permet à l'équipe d'agir rapidement afin de les faire disparaître, soit en identifiant une solution immédiate, soit en les réglant en dehors.&lt;br /&gt; &lt;br /&gt; Il se peu qu'une personne donne trop de détails ou donne de longues explications, ce qui tend à rallonger la mêlée et à diminuer le niveau d'énergie. À l'inverse, il est possible qu'il n'y ait pas suffisamment de détails pour permettre aux autres collaborateurs d'identifier les impacts sur leur travail ou des éléments sur lesquels ils pourraient aider. Dans cette situation, des questions d'éclaircissement peuvent être posées. Chaque membre doit être sensible aux niveaux de détails afin de respecter le temps alloué. Au besoin, le groupe peut se doter d'un signe indiquant que la personne devrait conclure son intervention rapidement.&lt;br /&gt; &lt;br /&gt; La nature des questions permet aux membres de l'équipe de déceler les opportunités d'entraide, de coordination, de synchronisation, de demander de l'aide et elle permet au chargé de projet de suivre la progression des travaux au quotidien.&lt;br /&gt; &lt;br /&gt; La mêlée apporte aux participants un sentiment d'appartenance, de fierté par la visibilité qu'elle donne à l'apport de chacun à l'avancement des travaux. Lorsque la mêlée sert uniquement de rencontre de suivi, les membres y trouvent peu de bénéfices et vont dire qu'ils y perdent leur temps. On observe alors que les membres s'adressent exclusivement au chargé de projet, et que souvent le chargé de projet «demande» l'information.&lt;br /&gt; &lt;br /&gt; La nature des informations échangée donne beaucoup de visibilité à la progression, ou la stagnation du projet. Lorsque l'équipe sent que la progression ne rencontre pas les objectifs, il se peut que certaines informations ne ressortent pas. Ce peut aussi être le cas si un des membres rencontre un problème. Pour que l'information soit partagée il ne faut pas qu'elle serve à «punir» la personne ou l'équipe. On doit la traiter comme un fait et voir, en équipe, ce qui peut être fait pour faire avancer les choses. Il faut donc voir à maintenir une «safe place».&lt;br /&gt; &lt;br /&gt; Si les tâches réalisées sont découpées grossièrement, il se peut que la réponse aux deux premières questions soit: «j'ai travaillé sur la même chose qu'avant hier, et je vais continuer aujourd'hui sur la même chose». Dans cette situation, on peut en profiter pour donner plus de détails sur le travail effectué et à faire.&lt;br /&gt; &lt;br /&gt; Si on utilise la technique de programmation par paire, alors une seule personne peut répondre aux trois questions, afin de ne pas répéter inutilement la même information.&lt;br /&gt; &lt;br /&gt; Ce n'est pas un rencontre de suivi de projet par et pour le chef de projet.&lt;br /&gt; &lt;br /&gt; Ces trois questions et le temps alloué ne permettent pas de régler tous les problèmes. Souvent on aura tendance à rechercher des solutions au problème énoncé par un membre. Si la solution n'apparaît pas rapidement il est préférable de régler en dehors.&lt;br /&gt; &lt;br /&gt; Il arrive, surtout lors des premières mêlées, qu'une personne se lance dans un long préambule ou une longue explication avant de répondre aux trois questions. Dans ces situations, il faut reconnaître le besoin d'une discussion plus élaborée que ce que permet la mêlée quotidienne et offrir de régler en dehors cette situation par un autre type de rencontre.&lt;br /&gt; &lt;br /&gt; L'identification des bloqueurs est un élément important de la mêlée quotidienne, qui vise à les éliminer le plus rapidement possible afin d'accélérer le travail et d'en réduire les impacts. Certaines cultures, cherchant à plaire, et ce sans malveillance, vont réduire ou ignorer certains bloqueurs. Le fait de poser la questions leur donne un opportunité de le faire, mais ne garantie pas qu'ils seront identifiées. Souvent la réponse sera «Pas de bloqueurs». Si le groupe a très peu de bloqueur.&lt;br /&gt; &lt;br /&gt; Prendre action / décider si possible&lt;br /&gt; &lt;br /&gt; Écoute active/ s'adresser à tous&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Même heure, tous les jours&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Les rencontres peuvent être difficile à planifier lorsqu'il s'agit de trouver une plage commune à un grand groupe de personnes. Un événement débutant toujours à la même heure, tous les jours, sans exception, permet à tous les participants de planifier d'avance leur temps et permet à des observateurs de se présenter sans planification préalable.&lt;br /&gt; &lt;br /&gt; Par conséquent, tenez la mêlée quotidienne toujours à la même heure.&lt;br /&gt; &lt;br /&gt; Le fait de débuter toujours à la même heure crée un rythme et permet aux observateurs d'assister à la mêlée de façon opportuniste.&lt;br /&gt; &lt;br /&gt; L'heure du début de la mêlée devrait être décidée par les participants. La mêlée peut débuter la journée, alors que les participants n'ont pas encore débuté les travaux. La mêlée peut aussi terminer la journée, mais dans ce cas, l'énergie est généralement plus faible. Alternativement la mêlée peut se tenir à la fin de l'avant-midi ou au début de l'après-midi. Évitez de tenir la mêlée au moment où les participants sont pleinement investis dans leur travail car cela peut briser le rythme.&lt;br /&gt; &lt;br /&gt; Il ne faut pas attendre les retardataires ni les absents, que ce soit le chargé de projet, les architectes ou les gestionnaires. La mêlée est pour tous, pas pour une personne en particulier. Certaines équipes instaurent une pénalité pour chaque retard, ce qui donne de la visibilité à ce comportement. Par exemple, ce peut être une amende qui sera remise à une œuvre de charité. Malgré cette punition, le comportement peut persister. S'il y a des retardataires systématiques, on peut voir avec eux quelles en sont les raisons, (peut-être l'heure ne leur convient pas, etc...) Si la personne croit qu'elle n'est pas souvent en retard on peut créer un tableau où sont consignés les retards afin de rendre factuelle cette information.&lt;br /&gt; &lt;br /&gt; Pour faciliter l'arrivée de tous les membres à la bonne heures, on peut installer une horloge sur le mur on inscrire la mêlée dans le calendrier électronique des membres de l'équipe.&lt;br /&gt; &lt;br /&gt; Affichez l'heure de la mêlée quotidienne sur le mur afin que tous puissent savoir facilement à quelle heure elle a lieu.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Débuter la journée&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; Il faut trouver un moment pour tenir la mêlée quotidienne. Il n'y a pas de moment idéal, trop tôt dans la journée tous les membres ne sont peut-être pas tous présent. Tard dans la journée et on est susceptible d'être confronté au même problème. Au début de la journée on a encore en tête ce qu'on a fait la veille et on est près à débuter le travail de la journée avec une énergie nouvelle. Tard dans la journée, on sait précisément ce que l'on vient de réaliser mais demain est encore loin. De plus en fin de journée on a moins d'énergie. Par conséquent, débuter la journée par la mêlée au moment où tous les participants sont arrivés.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Même endroit&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; La fréquence élevée des mêlées peut rendre la réservation de salle problématique. La mêlée étant ouverte à tous, et comme certaines personnes participeront sporadiquement, il faut diffuser l'endroit où elle se tient. Un événement se tenant toujours au même endroit, sans exception, permet à tous les participants et observateurs de se présenter sans planification préalable.&lt;br /&gt; &lt;br /&gt; Par conséquent, tenez la mêlée toujours au même endroit.&lt;br /&gt; &lt;br /&gt; Il peut être difficile de trouver une salle ou un endroit formel pour tenir la mêlée. Dans ce cas, on peut se servir d'un espace libre, un corridor, un bureau vide où tout le monde est debout. Les équipes travaillant dans un espace ouvert peuvent l'utiliser pour tenir la mêlée quotidienne. Les équipes qui ont des panneaux d'information peuvent tenir la mêlée devant ceux-ci, l'information qui s'y trouve peut servir à alimenter la mêlée quotidienne.&lt;br /&gt; &lt;br /&gt; La disponibilité des salles peut être réduite. Tenir une mêlée quotidienne dans un espace non dédié à cette fin peut incommoder les autres occupants. Réduire la durée de la mêlée quotidienne à moins de 15 minutes permet d'en réduire les impacts.&lt;br /&gt; &lt;br /&gt; Certaines personnes peuvent se trouver à l'extérieur de l'endroit où se tient la mêlée quotidienne. L'utilisation de moyens de télécommunication (téléphone main libre, vidéo-conférence…) peut permettre à ces personnes de participer activement à la mêlée quotidienne.&lt;br /&gt; &lt;br /&gt; Affichez l'heure de la mêlée quotidienne sur le mur afin que tous puisse savoir facilement à quelle heure elle a lieu.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Autour du info wall&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Speaker phone&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; &lt;br /&gt; &lt;strong&gt;10 personnes maximum&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Un grand nombre de personnes peuvent être intéressées à l'information de la mêlée quotidienne. Beaucoup de personnes augmentent la quantité d'information disponible et rejoindre tout le monde d'un seul coup est moins dispendieux que de multiples rencontres. Par contre un nombre élevé de participant diffuse l'énergie, crée des opportunités pour des conversations parallèles et rallonge la mêlée. On trouve qu'au-delà d'une dizaine de personnes, le besoin de coordination augmente rapidement.&lt;br /&gt; &lt;br /&gt; Par conséquent, limitez le nombre de participants à une dizaine de personnes.&lt;br /&gt; &lt;br /&gt; Si plus de dix personnes doivent participer à la mêlée quotidienne, séparez les en cochons et poules (voir plus bas), ou faites une mêlée de mêlées.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Fermer le cercle&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Le niveau sonore affecte l'attention et l'efficacité de la communication. Certaines personnes parlent faiblement et trouvent inconfortable parler plus fort. Souvent la mêlée se tient près d'autres personnes qui ne sont pas concernées et qui peuvent être dérangées par la mêlée.&lt;br /&gt; &lt;br /&gt; Par conséquent, rapprochez les personnes en fermant le cercle.&lt;br /&gt; &lt;br /&gt; S'il y a beaucoup de personne à la mêlée, former un cercle des participants (cochons) et laissez les observateurs (poules) se placer autour.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Cochons et poules **&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; L'histoire va comme suit :&lt;br /&gt; &lt;br /&gt; - Une poule propose à un cochon de lancer un restaurant&lt;br /&gt; - Le cochon y réfléchit et lui demande comment s'appellerait le restaurant.&lt;br /&gt; - La poule répond «Œuf et jambon»&lt;br /&gt; - Le cochon répond, «Non merci! Je serai engagé alors que tu serais uniquement impliquée.»&lt;/p&gt; &lt;p&gt;Durant la mêlée, les observateurs peuvent créer de l'interférence par leurs interventions, leurs questions ou commentaires. S'il y a trop d'interférences, les membres voudront utiliser une autre façon de communiquer le statut quotidien. D'autre part, exclure les observateurs les privent d'information importante. Par conséquent, instituez la règle que seuls les cochons (participants) participent alors que les poules (observateurs) observent sans intervenir.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Tour de table&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Les participants ne savent pas dans quel ordre intervenir. Si on laisse le groupe à lui-même, certaines personnes pourraient ne pas s'exprimer ou penser qu'elles n'ont pas rien à dire. Si une personne donne la parole aux intervenants, celle-ci aura tendance à la contrôler. Dans l'esprit de rendre les équipes autonomes, le chef de projet ne devraient pas déterminer l'ordre.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;«Passez le crachoir».&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Par conséquent, faites un tour de table où chacun répond aux trois questions. Il est important que ce soit le groupe qui fasse fonctionner la mêlée et non le facilitateur ou le chef de projet.&lt;br /&gt; &lt;br /&gt; La participation n'est pas facultative.&lt;br /&gt; &lt;br /&gt; Rôle de l'animateur&lt;br /&gt; &lt;br /&gt; Cluster de stories&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Mêlée de mêlée **&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; Chaque jour plusieurs mêlées quotidiennes ont lieu par groupes de 10 personnes maximum. Vous devez coordonner et permettre la synchronisation des efforts de l'ensemble des groupes. Participer à chacune des mêlées est impossible ou coûteux. Chaque mêlée contient généralement un animateur. Par conséquent, tenez une mêlée quotidienne avec l'animateur de chacune des mêlées quotidienne après les mêlées quotidienne de chaque équipe.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Régler en dehors&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Certaines personnes ont le réflexe de rechercher des solutions dès qu'un problème est énoncé, ceci rallonge la durée de la mêlée et en diminue l'énergie, car tous ne sont pas nécessairement concernés. D'autres évitent de prendre des décisions. On désire profiter de la présence de tous les participants à la mêlée pour régler rapidement le plus grand nombre de problèmes possibles. Cependant tous les problèmes ne peuvent être réglés durant la mêlée quotidienne. Il est important de noter que le sujet mérite qu'on y accorde le temps nécessaire.&lt;br /&gt; &lt;br /&gt; Par conséquent, utilisez une phrase ou un signe qui signale à l'équipe que la discussion doit être «réglée en dehors» de la mêlée et convenez du moment pour le faire. Il y a cependant une différence entre la recherche de solution et les questions de clarification. Ces questions peuvent être abordées, dans la mesure où la mêlée ne dépasse pas les 15 minutes prévues. Si une décision s'avère difficile à prendre et requiert plus de temps, alors il faut convenir du moyen approprié pour prendre la décision ou régler le problème. Certains problèmes ou bloqueurs ne peuvent être écartés rapidement, mais il demeure important de s'en occuper. Afin de ne pas les oublier, on peut les inscrire sur une feuille bien visible de tous.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Chronométrez la durée&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Il est difficile d'estimer la durée d'une rencontre quand on y participe. Par conséquent, le facilitateur devrait chronométrer la durée de la mêlée pour s'assurer que ça ne déborde pas à cause de la recherche de solutions, de longues explications ou raconter une histoire.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Tout le monde debout&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; Certaines personnes ont tendance à vouloir élaborer sur une situation et finissent par raconter une histoire. D'autres personnes débutent la recherche des solutions immédiatement. Ces deux situations tendent à rallonger la mêlée quotidienne. La posture assise, confortable, permet aux participants de s'installer pour longtemps alors que la posture debout, inconfortable à la longue, aura tendance à raccourcir la mêlée.&lt;br /&gt; &lt;br /&gt; Par conséquent, tenez la mêlée en vous tenant debout.&lt;br /&gt; &lt;br /&gt; La posture assise tend, à la longue, à réduire le niveau d'énergie. La station debout est elle dynamique et crée une énergie positive. La station debout est inconfortable si elle perdure. En se tenant debout, les personnes auront moins tendance à prolonger inutilement la mêlée. Pour certaines personnes, la posture débout peut être déconseillée ou impossible, par exemple pour une femme enceinte ou pour une personne handicapée. Dans ces situations il est préférable que tous soit assis.&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Règles simples&lt;br /&gt; &lt;br /&gt; Afficher les règles&lt;br /&gt; Élaborer en équipe&lt;br /&gt; &lt;br /&gt; Problèmes...&lt;/strong&gt;&lt;br /&gt; &lt;br /&gt; Un participant (cochon) ne participe pas.&lt;br /&gt; Manque d'écoute d'un participant (cochon)&lt;br /&gt; Un participant arrive en retard systématiquement&lt;br /&gt; Comprendre pourquoi. Peut-être que l'heure ne convient pas à ce participant.&lt;br /&gt; &lt;br /&gt; Un participant quitte prématurément.&lt;br /&gt; Les participants (cochons) s'adressent à l'animateur, au chargé de projet.&lt;br /&gt; La mêlée quotidienne appartient à l'ensemble de l'équipe. Bien que l'information permette au chargé d'équipe de suivre l'avancement du projet, ce n'est pas l'objectif principal. S'ils se limitent à cette seule dimension, les membres de l'équipe vont y trouver peu d'intérêt pour eux et l'atmosphère va s'en ressentir. Dans cette situation, le chargé de projet devrait s'effacer, prendre physiquement du recul et limiter son intervention.&lt;br /&gt; &lt;br /&gt; Un observateur (poule) interrompt la mêlée&lt;br /&gt; Conversations parallèles&lt;br /&gt; &lt;br /&gt; La mêlée débute en retard&lt;br /&gt; La mêlée dépasse les 15 minutes allouées&lt;br /&gt; Le chargé de projet prend tout en note&lt;br /&gt; &lt;br /&gt; La mêlée est annulée&lt;br /&gt; &lt;br /&gt; Hidden agenda, second agenda&lt;br /&gt; &lt;br /&gt; Around the wall&lt;br /&gt; &lt;br /&gt; Support de production et autres projets empiettent sur le temps des ressources&lt;br /&gt; On raconte une histoire, longues explications&lt;br /&gt; On recherche des solutions&lt;br /&gt; &lt;br /&gt; Assignation de tâche vs autonomisation&lt;br /&gt; &lt;br /&gt; Grosseur des lots vs «même chose qu'hier»&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Exemple&lt;/strong&gt;&lt;br /&gt;&lt;/p&gt; &lt;div style=&quot;text-align: center&quot;&gt;&lt;img src=&quot;http://agile.blogspirit.com/media/01/02/e11124080c82e7a74ff4d9cda70b90ac.jpg&quot; alt=&quot;e11124080c82e7a74ff4d9cda70b90ac.jpg&quot; style=&quot;margin: 0.7em 0px; border-width: 0px&quot; id=&quot;media-70199&quot; /&gt;&lt;/div&gt; &lt;p&gt;&lt;br /&gt; &lt;br /&gt; &lt;strong&gt;Références :&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; Yip, 2004, http://www.thoughtworks.com/PatternsDailyStandupJason%20Yip.pdf&lt;br /&gt; easyComp, 2003, &lt;a href=&quot;http://www.easycomp.org/cgi-bin/OrgPatterns?StandUpMeeting&quot;&gt;http://www.easycomp.org/cgi-bin/OrgPatterns?StandUpMeeting&lt;/a&gt;&lt;/p&gt; &lt;p&gt;&lt;strong&gt;Règles de base de la mêlée quotidienne&lt;br /&gt;&lt;/strong&gt;&lt;br /&gt; - J'arrive à l'heure (la mêlée débute toujours à la même heure, au même endroit).&lt;br /&gt; - Ma participation est obligatoire.&lt;br /&gt; - Notre mêlée à lieu même s'il y a des absents.&lt;br /&gt; - J'informe l'équipe de mes travaux et blocages en une minute en répondant aux trois questions :&lt;br /&gt; &amp;nbsp;&amp;nbsp;&amp;nbsp; Ce que j'ai fait depuis la dernière mêlée…&lt;br /&gt; &amp;nbsp;&amp;nbsp;&amp;nbsp; Ce que je vais faire d'ici la prochaine mêlée…&lt;br /&gt; &amp;nbsp;&amp;nbsp;&amp;nbsp; Ce qui me bloque…&lt;br /&gt; - J'écoute activement mes co-équipiers. Je ne prends pas d'appel.&lt;br /&gt; - Je m'adresse à l'équipe, pas seulement au chargé de projet.&lt;br /&gt; - Notre mêlée appartient à tous, pas juste au chargé de projet.&lt;br /&gt; - Si je n'ai rien de nouveau à dire, je donne plus de détails sur mes travaux.&lt;br /&gt; - Je résume mes interventions afin que la mêlée ne dépasse pas 15 minutes.&lt;br /&gt; - En tant qu'observateur, j'observe.&lt;br /&gt; - Notre mêlée quotidienne est animée, par défaut, par le chargé de projet. En son absence, je me porte volontaire.&lt;/p&gt; </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>Conception d'interface riche</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2007/10/12/conception-d-interface-riche.html" />  <id>tag:agile.blogspirit.com,2007-10-12:1396045</id> <updated>2007-10-12T21:33:57+02:00</updated> <published>2007-10-12T20:45:00+02:00</published>   <category term="design" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="ria" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="interface riche" scheme="http://www.blogspirit.com/ns/types#tag" />  <category term="xbap" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary> La conception d'interface personne système pour des applications riches...</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> &lt;p&gt;La conception d'interface personne système pour des applications riches représente un nouveau défi, d'une part parce qu'elles diffèrent des applications de bureau ou web et d'autre part parce qu'elle partage des similitudes avec ces deux type d'applications.&lt;/p&gt; &lt;p&gt;Les applications riches sont différentes des applications purement web (HTML) notamment car elles permettent plus d'interactivité. Elles partage aussi des traits commun avec le web, par exemple l'utilisation du bouton &quot;page précédente&quot; (&quot;back&quot;), la possibilité de &quot;bookmarker&quot; un état de l'application et du fait qu'elle sont disponibles à l'intérieur d'un fureteur et ne requiert pas d'installation locale.&lt;/p&gt; &lt;p&gt;Comme les applications de bureau (&quot;desktop application&quot;), les applications riches réagissent rapidement et permettent de manipuler de grandes quantités d'informations.&lt;/p&gt; &lt;p&gt;La plupart des applications riches incorporent des caractéristiques comme:&lt;/p&gt; &lt;ul&gt; &lt;li&gt; &lt;div&gt;glisser-déplacer (drag and drop)&lt;/div&gt; &lt;/li&gt; &lt;li&gt; &lt;div&gt;sélection et manipulation directe d'objets&lt;/div&gt; &lt;/li&gt; &lt;li&gt; &lt;div&gt;validation interactive en cours de saisie&lt;/div&gt; &lt;/li&gt; &lt;li&gt; &lt;div&gt;complétion de champ de saisie (ex: &lt;a target=&quot;_blank&quot; href=&quot;http://www.google.com/webhp?complete=1&amp;amp;hl=en&quot;&gt;GoogleSuggest&lt;/a&gt;)&lt;/div&gt; &lt;/li&gt; &lt;li&gt; &lt;div&gt;utilisation de graphique vectoriel (ex. &lt;a target=&quot;_blank&quot; href=&quot;http://finance.google.com/finance?q=NASDAQ:MSFT&quot;&gt;GoogleFinance&lt;/a&gt;)&lt;/div&gt; &lt;/li&gt; &lt;li&gt; &lt;div&gt;utilisation de média riche comme la vidéo (ex. &lt;a target=&quot;_blank&quot; href=&quot;http://www.youtube.com&quot;&gt;YouTube&lt;/a&gt;)&lt;/div&gt; &lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Dans le cas de notre applications de registre des demandes, on pourrait permettre de supprimer une demande simplement en la faisant glisser dans une corbeil, plutôt ou en plus d'un bouton de suppression. On pourrait imager assigner une personne à la demande en faisant glisser une demande sur une personne et/ou l'inverse.&lt;/p&gt; &lt;p&gt;Si la plupart des sites web ont une structure hiérarchique et que les applications de bureau sont souvent multi-fenêtres, les applications riches quant à elles sont à page unique, i.e. que toute l'interaction se produit dans une seule page qui répond au contexte d'utilisation. Le catalogue de la &lt;a target=&quot;_blank&quot; href=&quot;http://www.fnac.com/Magazine/logiciels_jeux/themas/windows_vista/decouvrir4d.asp?NID=%2D4&amp;amp;RNID=%2D4&amp;amp;Origin=FnacAff&amp;amp;SID=169d5d53%2D8f77%2D6a1e%2D332b%2D38a3abb83775&amp;amp;UID=0aa5be4a4%2D1297%2D54df%2D5a41%2Dd02a760b375b&amp;amp;OrderInSession=1&amp;amp;TTL=010220070018&quot;&gt;FNAC&lt;/a&gt; est un bon exemple xbap, et &lt;a target=&quot;_blank&quot; href=&quot;http://www.vertigo.com/familyshow.aspx&quot;&gt;FamilyShow&lt;/a&gt; un bon exemple WPF.&lt;/p&gt; &lt;p&gt;C'est d'ailleur un constat (application à page unique) auquel nous sommes nous même arriver en ébauchant le concept général de nos applications XBAP. De par l'observation d'applications existante et par les limites d'une approche qui mélange le web et le bureau.&lt;/p&gt; &lt;p&gt;Cela à pour implication de mettre l'emphase sur la tâche de l'utilisateur, sur son objectif courant. Donc les notions de contexte, de contenu et de tâches seront des aspects centraux de la conception.&lt;/p&gt; &lt;p&gt;En résumé, la conception sera driver par les objectifs/tâches de l'utilisateur. La question initiale est: qui sont nos utilsateurs et quels tâches font-ils?&lt;/p&gt; </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>Un excellent blog pour s'introduire à l'agilité</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2007/10/12/un-excellent-blog-pour-s-introduire-a-l-agilite.html" />  <id>tag:agile.blogspirit.com,2007-10-12:1395909</id> <updated>2007-10-12T17:18:21+02:00</updated> <published>2007-10-12T17:18:21+02:00</published>   <category term="Référence" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary>  http://kw-agiledevelopment.blogspot.com/  </summary> <content type="html" xml:base="http://agile.blogspirit.com/"> &lt;a href=&quot;http://kw-agiledevelopment.blogspot.com/&quot;&gt;http://kw-agiledevelopment.blogspot.com/&lt;/a&gt; </content> </entry>  <entry> <author> <name>Jean DESBIENS</name> <uri>http://agile.blogspirit.com/about.html</uri> </author> <title>Auto publication</title> <link rel="alternate" type="text/html" href="http://agile.blogspirit.com/archive/2007/10/12/auto-publication.html" />  <id>tag:agile.blogspirit.com,2007-10-12:1395786</id> <updated>2007-10-12T14:27:43+02:00</updated> <published>2007-10-12T14:27:43+02:00</published>   <category term="référence" scheme="http://www.blogspirit.com/ns/types#tag" />  <summary> Voici un  site d'auto publication  qui contient des livres intéressants sur...</summary> <content type="html" xml:base="http://agile.blogspirit.com/"> Voici un &lt;a target=&quot;_blank&quot; href=&quot;http://www.scribd.com/&quot;&gt;site d'auto publication&lt;/a&gt; qui contient des livres intéressants sur Agile et Scrum par exemple, notamment un livre de pattern&amp;nbsp;sur l'adoption de l'agilité, aussi disponible sur infoq.com, &amp;nbsp;&lt;a href=&quot;http://www.scribd.com/&quot;&gt;http://www.scribd.com/&lt;/a&gt; </content> </entry>  </feed>