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.