mageekblog - Mot-clé - scrumLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearGizmo !urn:md5:190d7716acedcf5f4a3ad5baac5279282011-01-07T14:00:00+01:002011-01-07T14:52:59+01:00mageekguyAgilitéagilitégizmomêléePHPscrumélephpant<p>Chez <a href="http://www.pmsipilot.com">PMSIpilot</a>, nous travaillons en suivant (plus ou moins) la méthode <a href="http://fr.wikipedia.org/wiki/Scrum_%28m%C3%A9thode%29">Scrum</a>.</p>
<p>Et lors de notre premier sprint, mon équipe de développement a été confronté à un problème relativement classique.</p>
<p>En effet, notre mêlée matinale avait une furieuse tendance à s'éterniser, et dépassait régulièrement et allègrement les 15 minutes.</p>
<p>La réunion perdait donc en efficacité puisqu'elle était polluée par un bruit constitué d'un tas de discussion techniques ou fonctionnelles, sans aucune structure.</p>
<p>Afin de régler le problème, nous avons donc décidé de prendre une série de mesures complémentaires lors de notre rétrospective de sprint.</p> <p>Tout d'abord, nous avons rappelé clairement l'objectif de la mêlée, afin que tout le monde puisse rester concentré dessus lors de son déroulement.</p>
<p>Ensuite, nous avons décidé de chronométrer nos mêlées, afin de pouvoir prévenir le plus tôt possible les débordements afin de ne pas perdre trop de temps.</p>
<p>Enfin, nous sommes tombé d'accord sur le fait que la durée de la mêlée s'allongeait car tout le monde avait tendance à prendre la parole à sa guise, afin de donner des précisions, exprimer son soutien, signaler un oubli ou bien encore dire son désaccord avec une solution mise en œuvre lors de la journée précédente, ce qui générait des débats largement en dehors du périmètre de la réunion.</p>
<p>J'ai donc suggéré d'avoir recours à un <a href="http://fr.wikipedia.org/wiki/Gizmo_%28homonymie%29">gizmo</a> lors de chacune des mêlée du second second sprint afin d'éviter tout débat transverse et ainsi rester concentrer sur les buts de la réunion.</p>
<p>En effet, le <a href="http://fr.wikipedia.org/wiki/Gizmo_%28homonymie%29">gizmo</a> est la traduction/transposition anglaise/geekienne du concept du <a href="http://fr.wikipedia.org/wiki/B%C3%A2ton_de_parole">bâton de parole</a> populaire dans les tributs d'Amérique du sud, et qui a justement pour but de réguler la parole au sein d'un groupe.</p>
<p>Sa mise en œuvre est très simple et immédiate, puisqu'elle n'est gouvernée que par une seule règle : seul celui qui possède le <a href="http://fr.wikipedia.org/wiki/Gizmo_%28homonymie%29">gizmo</a> a le droit de s'exprimer, les autres devant alors l'écouter avec attention.</p>
<p>De plus, malgré le fait qu'il soit mis en place pour imposer un comportement, le <a href="http://fr.wikipedia.org/wiki/Gizmo_%28homonymie%29">gizmo</a> est très bien accepté dans une équipe de développement car il apporte une touche d'humour et d'amusement bienvenue dans un cadre professionnel puisqu'il peut prendre n'importe quelle forme : peluche, <a href="http://fr.wikipedia.org/wiki/Mogwai">mogwai</a>, stylo, bombe à eau, ballon de rugby, j'en passe et des meilleurs.</p>
<p>Dans notre cas, vu que nous utilisons <a href="http://www.php.net">PHP</a> au quotidien et pour l'ensemble de nos développement, nous avons tout simplement kidnappé <a href="http://www.elephpant.com/">l'élephpant</a> de notre <a href="http://www.glagla.org/weblog/">directeur technique</a>.</p>
<p>Et je dois dire que les résultats de l'utilisation de notre <a href="http://fr.wikipedia.org/wiki/Gizmo_%28homonymie%29">gizmo</a> ont été spectaculaires.</p>
<p>Non seulement nos mêlées se déroulent maintenant effectivement en 15 minutes, voir moins, mais elles sont également beaucoup plus agréables et efficaces, car elles sont structurées et atteignent pleinement leurs objectifs.</p>
<p>D'ailleurs, nous en sommes maintenant à notre troisième sprint et cela marche tellement bien que nous ne les chronométrons même plus.</p>
<p>Et vous, utilisez-vous un <a href="http://fr.wikipedia.org/wiki/Gizmo_%28homonymie%29">gizmo</a> ?</p>http://blog.mageekbox.net/?post/2011/01/07/gizmo#comment-formhttp://blog.mageekbox.net/?feed/atom/comments/229Niko niko !urn:md5:21abf2af338c2f32a0992e6c04aba6352010-11-29T14:00:00+01:002010-11-30T17:57:09+01:00mageekguyAgilitébacklogburn down chartNiko-NikoPMSIpilotPost-itscrumScrumMaster<p>J'avais indiqué dans <a href="http://blog.mageekbox.net/?post/2010/11/03/Ce-blog-a-deux-ans-%21">mon billet d'anniversaire</a> que je j'allais abordé de nouveaux thèmes dans ce blog, et notamment le développement agile.</p>
<p>Ce billet est donc le premier d'une série que j'espère longue sur ce sujet qui me tient particulièrement à cœur, car je suis persuadé que l'avenir du développement logiciel et surtout la qualité logicielle passe par l'utilisation de l'agilité.</p>
<p>De plus, chez <a href="http://www.pmsipilot.com/">PMSIpilot</a>, mon nouvel employeur, les équipes de développement sont en train de passer en mode agile, et j'ai donc de la matière brute de première main et un retour direct d'expérience à vous faire partager.</p>
<p>Les sprints ont en effet débuté il y a quelques mois, et un certain nombre de pratiques, pour la plupart issues de <a href="http://blog.mageekbox.net/?post/2010/03/07/SCRUM-par-la-pratique">SCRUM</a>, sont en place.</p>
<p>Il y a donc entre autre pour chaque projet un <q><a href="http://www.aubryconseil.com/post/Le-backlog-de-produit">backlog</a></q>, une réunion de planification, une estimation de la complexité, des sprints de trois semaine, une mêlée matinale, un mur, des tickets, un <a href="http://en.wikipedia.org/wiki/Burn_down_chart">burn down chart</a>, des rétrospectives, etc.</p>
<p>Tout cela est évidemment épaulé par de l'intégration continue ainsi que par des tests unitaires et fonctionnels, <del>même si le développement piloté par les tests et la programmation en duo ne sont pas encore au goût du jour</del> et sera complété prochainement par du développement piloté par les tests et de la programmation en duo.</p>
<p>C'est donc naturellement que mon équipe a suivi le mouvement lorsque nous avons commencé à travailler sur notre projet, et comme j'en suis le seul membre à avoir une expérience agile, je me suis permis de proposer certains ajouts, tel que le <a href="http://www.infoq.com/articles/agile-kanban-boards">calendrier Niko-Niko</a>.</p>
<p>Je vous propose donc ici un bilan de cette pratique, suite à la conclusion de notre premier sprint.</p> <p>Concrètement, le <a href="http://www.infoq.com/articles/agile-kanban-boards">calendrier Niko-Niko</a> se présente sous la forme d'une feuille divisée en colonne, chaque colonne correspondant à un membre de l'équipe.</p>
<p>Chaque jour, à l'issue de sa journée de travail, chacun membre met dans sa colonne un <a href="http://fr.wikipedia.org/wiki/Smiley">smiley</a> représentant son ressentie de la journée.</p>
<p>Un <a href="http://fr.wikipedia.org/wiki/Smiley">smiley</a> qui fait la gueule représente donc une mauvaise journée, tandis qu'un <a href="http://fr.wikipedia.org/wiki/Smiley">smiley</a> souriant représente une bonne journée et un smiley neutre une journée mi-figue, mi-raisin.</p>
<p>Ce smiley a de plus une valeur globale sur la journée, dans le sens ou il englobe aussi bien l'aspect humain que technique, et il est strictement personnel.</p>
<p>J'ai également proposé de noter sur un <ins>P</ins><a href="http://fr.wikipedia.org/wiki/Post-it">ost-it</a> les raisons du mécontentement représenté par un <a href="http://fr.wikipedia.org/wiki/Smiley">smiley</a> aigri.</p>
<p>En effet, personnellement, au bout d'une ou deux semaines, j'ai beaucoup de mal à me souvenir de l'origine des problèmes que j'ai rencontré et qui m'ont amené à remplir ma colonne de la sorte.</p>
<p>L'ajout de ce <ins>P</ins><a href="http://fr.wikipedia.org/wiki/Post-it">ost-it</a> permet donc de pallier <del>à</del> ce genre de déficiences, et ainsi de gagner du temps lors de la rétrospective de fin de sprint.</p>
<p>La mise en place de la pratique a donc été très rapide, puisque la création du calendrier n'a pas du prendre plus de deux minutes, et fournir les explications à l'équipe lors de la mêlée matinale n'a pas du prendre plus de temps.</p>
<p>Le coût financier est quand à lui proche du zéro absolu, puisqu'elle ne nécessite qu'une à deux feuilles de papier, en fonction de la taille de l'équipe de développement.</p>
<p>Au niveau de l'équipe, justement, ma proposition a été très bien accueillie, à tel point qu'au fil du temps, remplir le <a href="http://www.infoq.com/articles/agile-kanban-boards">Niko-Niko</a> est presque devenu un jeu et permettait de dédramatisé les mauvaises journées.</p>
<p>Nous avons eu ainsi des <a href="http://fr.wikipedia.org/wiki/Smiley">smileys</a> enjolivés de noms d'oiseaux ou et autres massues lors des mauvaises journées, et les membres de l'équipe n'hésitaient pas à rappeler à ceux qui omettaient de le remplir leur obligation.</p>
<p>L'équipe s'est donc appropriée la pratique en y ajoutant sa touche personnelle et en s'auto-disciplinant ce qui est un signe certain qu'elle était acceptée et intégrée.</p>
<p>Au jour le jour, le <a href="http://www.infoq.com/articles/agile-kanban-boards">calendrier Niko-Niko</a> a été un outil appréciable lors de la mêlée quotidienne, car il a permis d'avoir un retour immédiat sur les problèmes rencontrés lors du développement, alors que traditionnellement, ce retour est donné lors de la rétrospective de fin de sprint.</p>
<p>Il a donc permis à notre <q><a href="http://en.wikipedia.org/wiki/Scrum_%28development%29#Roles_2">ScrumMaster</a></q> d'avoir un ressentie immédiat du moral de l'équipe et de comprendre qu'il y avait eu des problèmes sans avoir besoin de poser la question, ce qui lui a permis de se concentrer immédiatement sur les éventuelles solutions à apporter.</p>
<p>Évidemment, pour les membres de l'équipe, il a été un support très utile pour expliquer de manière plus efficace les problèmes rencontrés, ce qui a également facilité le travail du <a href="http://en.wikipedia.org/wiki/Scrum_%28development%29#Roles_2">ScrumMaster</a>.</p>
<p>le <a href="http://www.infoq.com/articles/agile-kanban-boards">calendrier Niko-Niko</a> a donc permis d'avoir des mêlées plus efficaces lorsque le développement se passait mal, qui se sont alors transformées partiellement en mini-rétrospectives informelles.</p>
<p>Le <a href="http://www.infoq.com/articles/agile-kanban-boards">Niko-Niko</a> a également été un support efficace lors de la rétrospective, car il a permis de faire ressortir en un temps record que l'ensemble des problèmes qui avait influé sur l'humeur de l'équipe avait été posé par l'apprentissage de nouveaux outils tel que <a href="http://www.phpunit.de/">PHPUnit</a>, à lui seul responsable d'au moins 80% des <a href="http://fr.wikipedia.org/wiki/Smiley">smileys</a> coléreux.</p>
<p>En outre, le calendrier a fait ressortir le fait que l'ensemble de l'équipe avait été impacté, et plus ou moins aux mêmes moments.</p>
<p>Nous avons également pu constater une relation très forte entre les décalages du <a href="http://en.wikipedia.org/wiki/Burn_down_chart">burn down chart</a> et la répartition des <a href="http://fr.wikipedia.org/wiki/Smiley">smileys</a>.</p>
<p>Très logiquement, lorsque l'équipe est heureuse, les pentes théoriques et réelles du <a href="http://en.wikipedia.org/wiki/Burn_down_chart">burn down chart</a> sont en corrélation, alors qu'elles divergent lorsque l'équipe rencontre des problèmes.</p>
<p>Le <a href="http://www.infoq.com/articles/agile-kanban-boards">Niko-Niko</a> est donc un outil simple mais très efficace pour optimiser le déroulement des mêlées quotidiennes ainsi que les rétrospectives, puisqu'il permet d'avoir, même s'il s'agit d'un indicateur très subjectif, une vision immédiate et précise du moral et de l'état d'esprit de l'équipe, indépendamment d'indicateurs plus objectifs, et cela même s'il existe une relation entre les deux types d'indicateurs. </p>
<p>Je pense par ailleurs que nous n'avons pas encore découvert toutes les possibilités offertes par cet outil, et que les prochains sprints seront riches en enseignement à ce niveau, d'autant que son utilisation a été généralisée à l'ensemble des équipes de développement de <a href="http://www.pmsipilot.com/">PMSIpilot</a>.</p>http://blog.mageekbox.net/?post/2010/11/29/Niko-niko-%21#comment-formhttp://blog.mageekbox.net/?feed/atom/comments/213SCRUM par la pratique ?urn:md5:24be84a9a0cccfce43c0a2194511b03a2010-03-07T19:50:00+01:002010-03-08T11:02:54+01:00mageekguyLivresagilitéclaude aubrycritiquelivrescrum<p>Vu que je suis en <q>congés</q> (relatifs, vu qu'il s'agit de congés paternités, les papa comprendront), je comble mon retard dans mes lectures.</p>
<p>J'ai donc quasiement terminé le livre <q><a href="http://www.amazon.fr/SCRUM-guide-pratique-m%C3%A9thode-populaire/dp/2100540181/ref=sr_1_1?ie=UTF8&s=books&qid=1267983887&sr=8-1">SCRUM, le guide pratique de la méthode agile la plus populaire</a></q> de <a href="http://fr.linkedin.com/in/claudeaubry">Claude Aubry</a>, l'auteur du blog <a href="http://www.aubryconseil.com/">Scrum, Agilité et Rock'n roll</a>.</p>
<p>Comme son titre l'indique, il traite de la mise en pratique de <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a>, l'une des plus populaires méthodes de développement agile.</p> <p>Les presques 300 pages du livre, écrites en français par l'une des références <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a> françaises, sont décomposées en chapitre indépendant dédié chacun à l'un des concepts véhiculés par la méthode.</p>
<p>Chacun d'eux est écrit dans un style clair et limpide qui va à l'essentiel, pour preuve, je l'ai lu majoritairement la nuit, entre minuit et 4 heures du matin, en donnant le biberon, et je n'ai jamais perdu le fil du livre, malgrè la fatigue qui s'est parfois faite cruellement sentir.</p>
<p>Fidéle à son titre, le livre est émaillé de détails et de cas réels issues de l'expérience de l'auteur dans la mise en application de la méthode.</p>
<p>Ces exemples permettent d'appréhender la façon de mettre en oeuvre certaines pratiques <q>dans la vraie vie</q>, et cela que l'on soit juste désireux de découvrir la méthode ou bien membre d'une équipe <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a>, débutant ou expérimenté.</p>
<p>De plus, cela permet d'éviter un côtè scolaire et abstrait vite soporifique plus que bienvenue dans mon cas, et démontre que la méthode fonctionne.</p>
<p>Autre bon point du livre, il met clairement en lumière les forces, mais également les limites de <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a> en tant que telle, aussi bien de par sa nature que lors de la sa mise en oeuvre.</p>
<p>Il insiste donc à bon escient, à mon sens, sur le fait que <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a> n'est pas un recette magique et ne donne pas l'ensemble des réponses aux problèmes susceptibles d'être rencontré lors du développement d'un logiciel.</p>
<p>Il faut pour cela déjà l'appliquer correctement, en connaître les forces et les limites, afin de pouvoir faire appel à des méthodes d'ingénierie logicielle ou d'autres concepts agiles au meilleur moment pour obtenir le résultat désiré, en fonction du contexte.</p>
<p>Il insiste également sur le fait que <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a> est un cadre relativement informel qui doit être adapté à son contexte de mise en oeuvre et qui peut, voir même doit, via le feedback et les rétrospectives, évouler avec le temps et l'expérience acquise dans sa mise en oeuvre.</p>
<p>Il a par ailleurs répondu à certaines de mes interrogations, notament au sujet de la planification et de l'estimation de la valeur des tâches, tant en terme d'intérêt pour le client qu'en terme de temps à passer pour leur réalisation, et m'a permis d'avoir une vision plus globale de sa mise en application.</p>
<p>Petit bémol, j'aurais aimé plus de détail sur certaines pratiques, tel que le planning game ou assimilé, mais après tout, ces techniques ne font pas parties de <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a> et ne sont que des moyens à mettre en oeuvre pour arriver à utiliser la méthode au mieux.</p>
<p>Cependant, le livre regorge de référence vers des sites qui permettent de combler les vides et de trouver les informations manquantes sans effort.</p>
<p>Autre petit point négatif à mon sens, l'aspect commercial relatif à la mise en oeuvre des méthodes agiles et de <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a> en particulier n'est pas du tout abordé.</p>
<p>En effet, si l'auteur insiste sur l'importance d'impliquer le client au niveau technique, il ne donne aucune piste pour lui vendre l'agilité et gérer cet aspect au cours du développement.</p>
<p>Or, vu qu'une équipe <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a> est censée être le plus possible en prise directe avec le client (comment, je vous laisse lire le <a href="http://www.amazon.fr/SCRUM-guide-pratique-m%C3%A9thode-populaire/dp/2100540181/ref=sr_1_1?ie=UTF8&s=books&qid=1267983887&sr=8-1">livre</a> pour le découvrir), c'est un point qui ne peut manquer d'être abordé en amont et au cours du développement.</p>
<p>Il aurait donc été intéressant de fournir quelques indications sur la façon de gérer l'aspect financier d'un développement réalisé à l'aide de <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a>, à la fois en avant-vente et au niveau de l'équipe au cours du développement, d'autant qu'un technicien, qui est clairement la cible du livre, peut ne pas avoir du tout la fibre commerciale.</p>
<p>Pour conclure, ce livre est donc une excellente référence en langue française pour le technicien, curieux, débutant ou expérimenté, qui cherche à avoir une approche pratique et pragmatique de <a href="http://fr.wikipedia.org/wiki/Scrum">SCRUM</a>, et non une approche purement théorique potentiellement déconnectée de la vie réelle, le tout dans un style clair et direct, même si certain points précis, certe externes à la méthode dans l'absolu, aurait pu être un peu plus développés.</p>http://blog.mageekbox.net/?post/2010/03/07/SCRUM-par-la-pratique#comment-formhttp://blog.mageekbox.net/?feed/atom/comments/92