Pyxis

Je suis fier de vous donner le lien vers le site de l’application Rabbit Reminder. Cette première application Androïd faite par Pyxis Technologies à Grenoble permet de mettre en place des alarmes dépendantes d’une position. Votre téléphone peut vous prévenir lorsque vous êtes proche d’un lieu ou quand vous êtes en train de le quitter. Rabbit Reminder est un logiciel publié sous licence GNU GPL v2 et il est bien sûr disponible sur Androïd Market.

La seconde session des matinales du Cluster-Edit sur le thème de l’agilité a rencontré un vif succès! Environ 35 personnes étaient présentes le 8 juin dernier à Villefontaine (entre Lyon, Grenoble et Annecy) et leur retours sont très positifs (mettre ici certains infos venant des questionnaires?)

L’objectif de cette seconde session était d’apprendre tout en s’amusant. Il existe en effet de nombreux ateliers “agiles” qui permettent aux participants de découvrir des principes et des pratiques à travers l’expérience du jeu.

Alexandre Boutin (Agiletoyou) et Emmanuel Etasse (Pyxis Technologies) ont animé l’atelier “artistes et spécifieurs”, le jeu créé par Alistair Cockburn qui est l’un des signataires du manifeste agile. Durant l’atelier, chaque groupe (de 5 à 6 personnes) a pu vivre les difficultés que l’on rencontre communément dans la communication écrite des besoins du client sous forme de “spécifications”.

Tout au long de l’atelier, les équipes ont pu améliorer leurs résultats en adoptant les pratiques simples et pragmatiques qu’elles souhaitaient mettre en place : parmi ces pratiques, nous trouvons

• la livraison fréquentes de petits incréments validés
• la demande de retours client le plus souvent possible
• la présence d’un “client embarqué”
• la synchronisation du travail en équipe

…pratiques clairement identifiées comme “agiles”.

L’énergie des participants était au rendez-vous! Il était parfois dangereux de se trouver dans la pièce avec une tasse de café à la main, vu le grand nombre de participants qui couraient! Il est surprenant de constater comme des équipes peuvent parfois se dépasser sans qu’il y ait besoin d’une récompense identifiée ou d’une autorité pour la contraindre… mais juste un cadre propice à ce que chacun puisse trouver sa propre motivation et contribuer à l’objectif commun de l’équipe

La session s’achevait à 11h00 précise (à l’heure prévue) après quelques questions en guise de conclusion.

Nous vous donnons rendez-vous en septembre pour la troisième matinale du Cluster-Edit sur le thème de l’agilité : il y sera question des outils pour la gouvernance et la planification de projets agiles.

A très bientôt en Rhône-Alpes!

We are proud to announce that a pre-release of GreenPepper for C++ developers is available! This release supports both Atlassian Confluence and XWiki wikis.

So C++ comes today to enhance the existing list of software development platforms supported by GreenPepper (Java, PHP, .NET, Ruby). This pre-release has been developped in 2 months in C++ using full test-driven approach thanks to the GoogleTest framework.

Compiled langages (like C++) are pretty challenging regarding the lack of mechanism like runtime type informations (or reflection). Our team took the challenge and got inspired by the same solutions as those retained by Google.

Our team hid complexity as much as possible, to allow GreenPepper C++ users to program with a simple source code (hum… although “simple” with C++ does not mean the same with other langages )

Want to see what a fixture source code looks like? Below a C++ header file sample :

CalculatorFixture.h using namespace greenpepper; using namespace type; CLASS_FIXTURE_BEGIN(CalculatorFixture) public: CalculatorFixture(void); IntegerType a; IntegerType b; void setA(IntegerType a); void setB(IntegerType b); IntegerType getA(); IntegerType getB(); IntegerType sum(); REGISTER_METHODS_BEGIN() REGISTER_PROCEDURE_1(setA, IntegerType) REGISTER_PROCEDURE_1(setB, IntegerType) REGISTER_METHOD_0(getA, IntegerType) REGISTER_METHOD_0(getB, IntegerType) REGISTER_METHOD_0(sum, IntegerType) REGISTER_METHODS_END() CLASS_FIXTURE_END(CalculatorFixture)

If you want to start using it within you projects, just tell us! Please contact us at grenoble@greenpeppersoftware.com. Download the package here.

Kind regards.

We are proud to announce that a pre-release of GreenPepper for C++ developers is available! This release supports both Atlassian Confluence and XWiki wikis.

So C++ comes today to enhance the existing list of software development platforms supported by GreenPepper (Java, PHP, .NET, Ruby). This pre-release has been developped in 2 months in C++ using full test-driven approach thanks to the GoogleTest framework.

Compiled langages (like C++) are pretty challenging regarding the lack of mechanism like runtime type informations (or reflection). Our team took the challenge and got inspired by the same solutions as those retained by Google.

Our team hid complexity as much as possible, to allow GreenPepper C++ users to program with a simple source code (hum… although “simple” with C++ does not mean the same with other langages )

Want to see what a fixture source code looks like? Below a C++ header file sample :

CalculatorFixture.h using namespace greenpepper; using namespace type; CLASS_FIXTURE_BEGIN(CalculatorFixture) public: CalculatorFixture(void); IntegerType a; IntegerType b; void setA(IntegerType a); void setB(IntegerType b); IntegerType getA(); IntegerType getB(); IntegerType sum(); REGISTER_METHODS_BEGIN() REGISTER_PROCEDURE_1(setA, IntegerType) REGISTER_PROCEDURE_1(setB, IntegerType) REGISTER_METHOD_0(getA, IntegerType) REGISTER_METHOD_0(getB, IntegerType) REGISTER_METHOD_0(sum, IntegerType) REGISTER_METHODS_END() CLASS_FIXTURE_END(CalculatorFixture)

If you want to start using executable specifications within you C++ projects, just tell us! Please contact us at grenoble@greenpeppersoftware.com. Download the package here.

Kind regards.

Nous sommes heureux de vous inviter à un petit déjeuner agile organisé par le Cluster-Edit (Cluster des éditeurs logiciels de la région Rhône-Alpes) le 13 avril prochain à Villefontaine. Il s’agit du premier rendez-vous d’une série de trois petit-déjeuners dédiés à l’Agilité dans l’édition logicielle. Ces petits-déjeuners seront conjointement animés par Alexandre Boutin (AgileToYou) Emmanuel Etasse (Pyxis Technologies).

L’objectif des petits-déjeuners agiles est de permettre à tous (Dirigeants, Managers, Testeurs, Développeurs, Architectes…) de venir découvrir l’agilité. Le terme Agile a vu le jour en 2001 avec la signature du “manifeste agile” par 17 individus en quête d’une autre façon de conduire les projets, mais les méthodes elles-mêmes sont pratiquées depuis les années 90. Les sessions proposées sont des moments d’échange conviviaux et privilégiés avec des professionnels expérimentés, reconnus comme des experts dans leur domaine.

Session 1 : “Découvrez l’agilité !”

Lors de cette première session, vous découvrirez l’agilité! Vous apprendrez en quoi elle peut être une opportunité d’améliorer votre façon de développer du logiciel. Vous aurez l’occasion de découvrir le manifeste agile, les origines de l’agilité et quelques approches agiles telles que Scrum, XP ou Lean. Puis vous aurez l’occasion de partager le retour d’expérience d’un industriel qui utilise concrètement l’agilité depuis plusieurs années au sein de son entreprise.

S’inscrire à ce petit-déjeuner.

J’ai eu l’opportunité de collaborer récemment avec Marc Vilcot qui est consultant-formateur en management d’équipe et techniques de ventes de la société Com-Hom (www.com-hom.com). Nous avons écrit une série d’articles autour du concept du « terrain de jeu » sportif mais appliqué au management.

Dans un premier article, Marc Vilcot décrit ce concept en faisant un parallèle entre une entreprise et une équipe jouant sur le “terrain”. Ce court article introduit les concepts de mission, valeurs, objectifs et de règles. L’article est disponible ici.

Dans un second article, j’ai essayé de mettre en perspective l’organisation d’un projet de développement logiciel en mode Scrum autour de ce “terrain de jeu”. Le second article est disponible ici.

Enfin, dans un troisième article, Olivier Nier, entraîneur de l’équipe de Rugby d’Oyonnax (D2), tisse un parallèle entre son coaching de l’équipe et le “terrain de jeu”. Son article est disponible ici.

Ce fut une bien belle expérience que d’échanger nos idées entre personnes venant de mondes professionnels différents. Cette confrontation nous permet de soulever de nombreux points communs et certaines différences. Elle illustre également que le management est une posture bien plus qu’une place dans un organigramme.

En découvrant les nouvelles fonctionnalités de GreenPepper 2.6 j’ai eu envie de les partager au plus vite ! GreenPepper autorise maintenant une syntaxe très flexible pour exprimer des scénarios (ou cas d’utilisation) dans un formalisme qui peut être défini en collaboration entre les experts métiers et développeurs. Le mot–clef associé à cette syntaxe est « scenario ». Je vais vous montrer dans ce billet comment utiliser GreenPepper pour exprimer des exigences sous la forme « Given, When, Then », formalisme recommandé par le courant « Behaviour Driven Developpement ».

Un cas concret à spécifier

Prenons un cas concret d’exigences fonctionnelles. Spécifions le comportement d’un agent virtuel d’assistance, dont le rôle est  de répondre à des demandes d’aide en trouvant des interlocuteurs pouvant satisfaire les demandes d’aide.

Les principales « user stories » seraient les suivantes :

• En tant qu’utilisateur ayant besoin d’aide, afin de trouver une personne qui pourrait m’aider, j’interpelle l’agent virtuel afin de lui décrire mon problème.
• En tant qu’utilisateur ayant besoin d’aide, afin de trouver une personne qui pourrait m’aider, je souhaite contacter une personne disponible et disposée à m’aider.
• En tant qu’utilisateur pouvant apporter mon aide, je souhaite être contacté par l’agent virtuel afin de proposer mon aide.

Reformulons maintenant sous la forme d’exemples certains cas d’utilisation :

Etant donné que Marc n’a jamais contacté l’agent virtuel

Quand Marc dit à l’agent virtuel « Hello »,

Alors l’agent virtuel lui répond « Que puis-je faire pour t’aider ? »

Quand Marc dit à l’agent virtuel « Je n’arrive pas à installer Credanse+ sur MacOS »

Alors l’agent virtuel lui répond « J’ai bien pris note de ta demande d’aide et te contacte dès que possible »

Etant donné que Marc a déjà formulé la demande d’aide « Je n’arrive pas à installer Credanse+ sur MacOS »

Etant donné que Steve est disponible

Etant donné que Marc n’est pas disponible

Quand l’agent virtuel contacte Steve pour lui dire « Marc a besoin d’aide, il m’a dit : Je n’arrive pas à installer Credanse+ sur MacOS . Acceptes-tu de l’aider ?»

Quand Steve dit à l’agent virtuel « Oui »

Alors l’agent virtuel lui répond « Merci, je vais en faire part à Marc et il te contactera dès que possible »

Spécifier dans GreenPepper

Voyons comment écrire le premier scenario avec GreenPepper :

Dans notre espace collaboratif d’édition de spécifications (Confluence ou XWiki), nous saisissons le tableau suivant :

Mettons un peu de couleur pour faire mettre en relief ce qui relève de la syntaxe et ce qui est en rapport avec les données du scénario.

Coder la classe de test

Maintenant, nous devons écrire la classe de test (ou fixture). Une première implémentation naïve de cette classe pour faire passer le test est :

Dans cet exemple C# (il est possible d’écrire la même fixture en Java avec GreenPepper), nous voyons des attributs en charge de gérer la correspondance entre chaque « phrase » du scénario et une méthode de la classe de test.

Le mot-clef « Given » permet de définir ou d’initialiser un comportement qui ne sera pas testé. Par contre, le mot-clef « Then » permet de déclarer des attentes et de les tester. Dans cet exemple, nous testons la réponse de l’agent virtuel.

Exécuter la spécification

Exécutons notre spécification avec GreenPepper et observons le résultat :

Après exécution, une confirmation visuelle affiche automatiquement en vert les parties de texte qui ont été vérifiées positivement par GreenPepper. En cas de confirmation négative, la couleur rouge sera utilisée.

En conclusion…

Nous voyons à travers cet exemple, que l’utilisation d’expressions régulières associées à des méthodes de la classe de test, permet une grande souplesse ! Aux équipes de jouer et de trouver une syntaxe qui facilitera une compréhension partagée entre toutes les parties prenantes du projet ! Cette compréhension partagée sera de plus testable en continue!

Après une nuit difficile (fièvre), je me dope au paracétamol au petit-déjeuner, et me voici sur place à Blagnac pour l’Agile Tour Toulouse seconde édition. 200 personnes présentes, un timing parfaitement respecté, des sessions de qualité, et de très bons petits fours

En première session, je suis allé écouter Jean-marie Damas au sujet « des promesses de l’agilité » : exposé très général sur les enjeux et les opportunité à « être agile ». Ensuite, ce fut l’occasion pour moi de parler des « core protocols » devant une salle de classe plutôt bondée. Difficile de savoir comment un tel sujet est perçu par un public aussi varié Quelques personnes enthousiastes sont venus à ma rencontre après la session, et ça m’a donné la pêche.

1 gramme de paracétamol plus tard, je vais assister au retour d’expérience « Scrum sur un projet critique » présenté par Julien Patou. Le projet concerne le milieu des assurances dans le bancaire. J’en ai retenu que le projet fut un succès.

Après la pause déjeuner, c’est l’heure du XP-Game animé par Thierry Cros, David Brocard et votre dévoué. Mais la concurrence est telle durant ce créneau horaire (Session de Claude Aubry, atelier TDD…) que bien peu de personnes viennent à notre atelier. Tant pis, l’atelier démarre avec 1 table bien motivée et encadrée par 2 coachs, quel luxe

Après une introduction de Thierry pour expliquer quelques fondamentaux d’eXtreme Programming, l’atelier démarre avec son lot de timeboxing, de stress, de rires et de gonflage de ballons. C’est dans la bonne humeur que l’on fait un débriefing de la session. A ce moment là, Thierry nous explique le TDD (développement dirigé par les test) grâce à un ballon, édifiant !!!! Mais comment ?

Imaginez que le ballon corresponde à du code : disons que la fonctionnalité à implémenter requiert un ballon de 40 cm de circonférence. Si vous gonglez un ballon directement, il est probable que vous ne résussirez pas à produire un ballon d’exactement 40 cm :
- Soit il sera trop petit : du coup, la fonctionnalité ne sera pas « terminée »
- Soit il sera trop grand : le volume supplémentaire correspond alors à du code mort : vous avez dépensez trop de souffle ! (trop d’argent dans vrai un projet)

Alors, avant de gonfler le ballon, fabriquez un garabit : un anneau en papier de 40 cm de long : placez le ballon au milieu du gabarit et soufflez : dès que le ballon sera en contact, arrêtez ! Voilà, grâce à votre gabarit (= le test) vous produisez le « juste » ballon (le « bon » code dans un vrai projet).

La dernière session fut une présentation de GreenHopper, l’outil qui permet de rendre JIRA plus agile, assurée par Eudes Nouvellon. L’outil très puissant, flexible et facilement configurable selon les besoins des projets, a visiblement intéressé les participants.

Je tiens à remercier chaleureusement Thierry, Jean-Marie et David pour leur invitation à cette conférence. La qualité de leur accueil m’a réellement touché. L’Agile Tour Toulouse fut pour moi une belle occasion de faire plus ample connaissance avec des personnes de la communauté agile de Toulouse. J’ai pu aussi revoir des amis de très longues dates qui m’ont gentillement accueilli durant mon séjour. Et surtout, j’ai découvert comment faire du TDD avec des ballons

Ouf, jeudi dernier le A319 touche la piste de Saint Exupéry et ma tourné des Agile Tour s'achève après avoir participé à 4 villes (Genève, Paris, Grenoble et Toulouse) et 6 sessions.

Agile Tour Grenoble 2009 est fini… après des mois de préparations, je suis très ému par les retours que j’ai pu obtenir. 300 personnes étaient présentes durant cette journée. Les agilamis du CARA étaient partout : à l’accueil, à la gestion du temps, dans les sessions. Un cadre de prestige avec un amphithéâtre plutôt confortable. Des horaires respectés à la minute près. Un grand merci aux 20 orateurs pour le niveau de leur intervention, certains d’entre eux sont venus de très loin ;-) De Stockholm pour Henrik Kniberg et d’outre-Atlantique pour Elisabeth Hendrickson !

Merci aussi aux sponsors de l'étape grenobloise : leur donation est précieuse pour un évènement de cet ampleur!

Je tiens à remercier du fond du cœur mes co-équipiers de l’organisation de cet évènement : Georges Allemand, Emmanuel Huguonnet, Anne-laure Dalban, Alexandre Boutin, Yves Crespin, Cédric Bourgeois, Arnaud Pierrel, Laurent Laslaz, Laurence Hanot, Pierre Maciejewski, Jérôme Barrand, Arnaud Pierrel, Jean-François Jagodinski... Tout le monde a donné de son temps, de son énergie et je crois qu’on peut être fier du résultat !

Le dépouillage des 220 feedbacks recueillis à la fin de la journée nous attend et un rapport de synthèse sera très bientôt disponible en ligne. De même que les présentations seront très bientôt en ligne ;-) Enfin, on se donne rendez-vous très prochainement pour faire la rétrospective grenobloise. Au fait, si un volontaire (extérieur aux organisateurs) est partant pour animer cette rétrospective, qu’il nous contacte !

Pour les plus curieux, voici mon album photo Agile Tour Grenoble 2009.