Il y a deux choses intéressantes que j’aimerais vous partager :

1. Lors du premier cours, nous avons demandé aux étudiants de partager leur expérience en Agilité. Plusieurs ont parlé de Pyxis et ils ont nommé quelques Pyxissiens. Bravo! Nous avons encore une grande visibilité, même chez les débutants.

2. Je trouve que Pyxis est un incubateur d’opportunités et je suis reconnaissant d’en profiter.

• À mon retour de la France, je me suis impliqué dans l’organisation d’Agile Montréal sur invitation de François.
• Lorsque la communauté Agile de Montréal a quitté les locaux du CRIM, nous avons rencontré Claude Besner, professeur à l’UQAM. Il contribue énormément aux activités d’Agile Montréal et d’Agile Tour Montréal.
• Devenir Coach à Pyxis m’a permis d’élargir mes connaissances sur l’Agilité et de donner des cours de formation.
• Répondre à l’invitation d’Éric Laramée d’écrire un livre, jumelé à la rencontre de Sylvie en mandat avec moi à la SIQ, a permis l’écriture d’un ouvrage couvrant de manière large les méthodes Agiles.
• Claude m’a mis en relation avec Shayne, qui a fait une thèse portant sur l’Agilité, pour que nous préparions ensemble un cours sur les méthodes Agiles.

Pour ma part, j’en conclus que Pyxis et la communauté Agile sont une source de potentiel insoupçonné. Même si on a l’impression que certaines de nos actions ne paient pas à court terme, on peut être surpris en chemin. Dans le doute, ne lâchez pas!

Un jeu d’enfants, pas vraiment

Le concept est inspiré des plateformes de jeu. Dans la plupart des jeux modernes, il existe ce concept d’achievement que l’on peut débloquer en réalisant certains exploits lors de nos quêtes. Par exemple, réussir à ramasser tous les jetons d’un niveau ou réussir sans se servir de pouvoir spécial.

Ce concept porté à Visual Studio et à l’environnement de développement se traduit par des achievements du genre ‘utiliser tous les mots clés de scope (private, protected, internal, public) dans une même classe’. Ou bien ‘utiliser plus de 50 fois la fonction Reorganize using’. Le but de ces achievements est de faire découvrir des notions ou fonctions méconnues de la plateforme. Il en existe une tentaine et chacun d’eux procure des points pour un total possible de 169 points. Les résultats son également publier sur le site web de channel 9.

Un peu plus fou, un peu plus loin

Lors d’une discussion avec Martin Proulx, président de Pyxis, celui-ci a émis l’idée que ce concept de renforcement positif pourrait s’appliquer à des équipes Agiles. J’ai fait part de cette idée au Scrum Master de l’équipe de mon mandat actuel. L’idée a lentement fait son chemin, tellement qu’au dernier sprint l’équipe a reçu l’achievement de binômage pour avoir accompli plus de 10 séances d’au moins une heure de travail par paire.

Le ridicule ne tue pas

Au départ, cette idée, qui semblait farfelue, s’est avéré un puissant motivateur dans notre équipe. Les membres ont finalement été fiers lors de la démonstration quand en plus d’avoir réussi tous les points prévus pour le sprint, ils ont vu apparaître la médaille de pairing sur l’écran du projecteur.

Nous pensons déjà ajouter de nouveaux achievements pour les prochains sprints. Parmi les idées qui me viennent en tête, il y a celles-ci : Maître de la revue de code (10 revues de code), Bâti sur du roc (aucun bris du build), Précis comme une horloge (aucun retard à la mêlée quotidienne) et Tireur d’élite (estimation avec moins de 10 % d’erreur). On peut aussi penser à des achievements personnels comme le Super Héros pour la personne qui aura sauvé le sprint en aidant des collègues, le Prix Nobel à la personne qui aura une super idée ou le Coureur de fond à la personne qui aura pris et mené à terme la tâche la plus longue et répétitive du sprint.

Suggestions

Maintenant que vous avez lu ceci, avez-vous des idées? Est-ce que vous pourriez appliquer ce concept dans votre équipe? Quels autres achievements pouvez-vous imaginer? J’aimerais vous lire; manifestez-vous.

]]> http://pyxis-tech.com/blog/2012/03/20/achievements-seulement-pour-les-jeux-ou-pour-l%e2%80%99agilite-aussi/feed/ 0 http://pyxis-tech.com/blog/2011/12/27/vous-avez-dit-ddd-demo-driven-design/?utm_source=rss&utm_medium=rss&utm_campaign=vous-avez-dit-ddd-demo-driven-design http://pyxis-tech.com/blog/2011/12/27/vous-avez-dit-ddd-demo-driven-design/#comments Tue, 27 Dec 2011 00:10:08 +0000 éric de carufel http://pyxis-tech.com/blog/?p=4632 Être agile

Pour moi être agile c’est savoir s’adapter, éviter les mauvais coups. Un boxeur agile ne frappera pas nécessairement plus fort ou précis mais il recevra moins de coup. Un joueur de hockey agile ne comptera pas nécessairement plus de but mais il pourra se rendre plus souvent dans la zone pour le faire.

Un développeur agile n’est pas vraiment plus rapide qu’un autre, il sait juste éviter les récifs comme s’il descendait les rapides en kayak. Le développeur agile voit venir les coups et sait les éviter. Il sait même se mettre dans une situation où il sera en meilleure posture pour les éviter.

S’adapter c’est développer ses forces pour contrer les problèmes rencontrés. S’adapter c’est aussi laisser de côté ce qui ne fonctionne pas et utiliser ce qui fonctionne. La nature a évolué depuis des millions d’années comme ça. Il faut arrêter de faire ce qui ne fonctionne pas pour ne pas se faire déclasser pas les autres.

Démontrer

Un des préceptes des méthodologies agile est de produire des résultats démontrables à la fin de chaque cycle, ou sprint si on utilise la méthodologie SCRUM. La démo est une façon de présenter le travail accompli. J’insiste sur le terme accompli pour apporter la notion de done. Le done ne veut pas dire que l’on peut le démontrer, ça veut dire que tous les critères que l’on s’est donnés sont respectés. La démo peut faire partie de ces critères.

L’objectif d’un sprint n’est pas la démo. L’objectif du sprint est de terminer les stories sur lesquels on s’est commis.

Trop souvent j’ai participé à des sprints où les priorités étaient dirigées par le désir de satisfaire les besoins de la démo sous prétexte que le VP allait y être. Les priorités doivent être dirigées par la valeur d’affaire. Le DDD ne veut pas dire Demo Driven Design mais bien Domain Driven Design mais ça c’est une autre histoire.

En tant que Scrum Master, je souhaitais faire vivre au directeur de produit (Product Owner) l’expérience de l’émergence des fonctionnalités au cours du projet. C’est pourquoi nous avons ‘oublié’ le travail considérable fourni en avance par le client sur l’analyse de son besoin et la conception de son futur service. Cette démarche n’a pas été bien accueillie au début mais lorsqu’il a fallu définir sur quoi l’équipe de développement allait commencer à travailler, il a bien fallu considérer que les 100 pages d’analyse du besoin n’avaient pas toutes la même priorité. Scrum, et de manière plus générale la démarche Agile, était nouvelle pour la plupart des personnes impliquées dans le projet côté client. Pour cela, il a fallu expliquer que l’engagement de l’équipe de développement se faisait sprint par sprint et qu’elle ne s’engagerait pas lors du démarrage du projet à couvrir l’ensemble des fonctionnalités souhaitées en production à la mi-décembre. Le directeur de produit n’en était pas à son premier projet Scrum, et il a su rassurer les inquiets… où assumer seul le risque fonctionnel, selon le point de vue.

Nous sommes alors partis sur un rythme de sprints de 2 semaines pour permettre au directeur de produit de modifier la direction suivie plusieurs fois avant son échéance marketing de mise en production. Un sprint de deux semaines est, en fait, une bonne durée pour l’équipe de développement qui parvient assez bien à déterminer les items du carnet du produit (product backlog) qu’elle peut convertir en fonctionnalités pendant le sprint. Plus long, cela devient plus difficile car le potentiel d’incertitudes augmente. Plus court, l’ensemble des items choisis ne permettait pas de livrer un ensemble cohérent de fonctionnalités ni de définir un but à l’itération. De plus, cette capacité d’appréhender sur deux semaines nous a permis de démarrer le premier sprint sans connaître la vélocité de l’équipe. Nous avons par la suite constaté une vélocité moyenne d’environ 50 points, ce qui permettait de faire tinter la sonnette d’alarme lorsque nous étions trop loin de cette valeur lors d’une rencontre de planification.

Vous avez sans doute songé qu’entre le 22 octobre et le 13 décembre, il n’y a pas la place pour 5 sprints de 2 semaines. Effectivement! Nous avons terminé anormalement le sprint 3 et dédié le sprint 5 à la mise en production en ramenant sa taille à une seule semaine.

Côté outils, nous avons utilisé JIRA pour gérer notre carnet du produit et notre carnet du sprint. De plus, le plugiciel GreenHopper nous a permis de générer simplement notre graphique d’avancement du sprint. Cet outil offre une visualisation du travail en cours sous forme de tableau des tâches.

Mon meilleur souvenir (pour l’instant)? La personne du marketing qui, au début, avait voulu qu’on s’engage à livrer tout ce qui était dans leur dossier d’analyse. Cette personne découvrait les méthodes Agiles, et Scrum a fortiori. Lors de la revue du sprint 1, en ayant sous les yeux une application qui tourne, elle a eu une nouvelle idée à laquelle personne n’avait pensé et qui devenait évidente avec l’application sous les yeux. Je crois qu’elle a réalisé ce jour-là l’intérêt des méthodes Agiles et l’absurdité d’un monde dans lequel on essaie de tout prévoir à l’avance.

Le client est très satisfait de cette expérience. La preuve? On continue! Nous sommes repartis pour une série de sprints et une future livraison (livraison 2) du produit au début de l’année prochaine. À suivre…

réf: Orange Business Services – Online Multimedia