eric.lemerdy

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 13 mai 2009

Présentation du Lean Software Developement

Je vais parler aux XP Day !

XP Day bag 1 (c'est le sac de l'année dernière)
1 2 3
  1. Ne pas négliger la théorie
  2. S'entraîner en s'écoutant pour se corriger
  3. Prendre des forces (5 fruits et légumes par jour, c'est un objectif dur à atteindre !)
La théorie permet d'être à l'aise avec les fondements de ce que l'on vit sur nos projets.
En s'écoutant, on apprend à se placer du côté de l'auditoire. Je cherche à me poser les questions en tant que public de la présentation : quels sont mes attentes et serais-je déçu si j'y assistais ? Mais la voix n'est pas le vecteur primordial pour faire passer l'information. L'attitude, le ton, la présence comptent aussi beaucoup.
Il est aussi important d'avoir une idée claire des messages que l'on souhaite faire passer. Ensuite, le mieux est de trouver une histoire à raconter pour faire passer le tout de façon agréable. Ce qui me plaît dans une présentation, ce sont les accroches, et lorsque les exemples résonnent dans mon expérience actuelle et passée. J'utilise donc des cartes pour répéter sur lesquelles j'inscris le message important du slide et les accroches et les transitions dans une autre couleur.
Tentons de faire tout ça pour le 26 mai !

dimanche 21 septembre 2008

Se rencontrer pour apprendre et partager

Logo-Valtech-Days-2008-web.gif Les Valtech Days 2008 se dérouleront les mardi 21 et mercredi 22 octobre 2008 à La Défense, soit dans un mois jour pour jour.
C'est un évènement qui permet de se tenir au courant des dernières avancées en matière d'agilité, d'industrialisation, d'architecture et de technos web.
Ce que je conseille, c'est de jeter un œil aux présentations et "white papers" de l'année dernière. Je l'ai fait moi même et j'ai été ravi de mes lectures. Les sujets sont pointus et ceux de fond sont toujours pertinents un an après ! Notamment sur la Gestion du Cycle de vie des Applications...
Je conseille notamment: Voir aussi le compte-rendu d'un bloggeur de developpez.com.

mardi 29 juillet 2008

Overview of Eclipse RCP UI testing tools

-All datas collected during Summer 2008-
Product Type Licence Source Status
Abbot framework (AWT/SWT) open source Sourceforge alpha for SWT (but seems pretty stable)
Costello recorder (AWT) open source Sourceforge not ready for SWT
GUI Dancer recorder commercial Bredex GmbH new version in july 2008
JDemo framework open source Sourceforge 2008
Mercury WinRunner recorder commercial Mercury End of support (feb 2008)
QF-Test recorder (XML/Jython) commercial Quality First Software GmbH - Kapitec (FR) 2008
Rational Functional Tester recorder commercial IBM
SWTBot framework (SWT) open source ThoughtWorks not fully SWT compatible but ThoughtWorks can be considered as trustable.
TPTP Automated GUI Recorder (AGR) recorder (XML/Java) open source Eclipse.org maintained ? but "as-is" component
WindowTester hybrid (java) commercial / free for opensource commiters Instanciations high quality product
This matrix is based on this article from the WindowTester architects ; this product list is enforced with the following post comments where people chat about their uses.
Feel free to visit the del.ico.us links where I store framework's related ressources on the fly. I am working on this subject until a satisfying product can be identified, so I will add some new links soon (screencasts and tutorials are the forthcomming waited material). I am glad that the Eclipse community is doing a substantial effort in 2008. For exemple, there was less submissions on this subject for EclipseCon2007 last year.

lundi 28 juillet 2008

De retour de la session TDR

En avant première, Gilles Mantel a réuni les praticiens de Paris ce soir pour nous faire partager sa session "Test-Driven Requirements: beyond tools" qu'il donnera le 5 août 2008 à Toronto à l'occasion de la conférence Agile 2008.
A travers deux expériences ludiques et leurs rétrospectives, il nous montre en quoi les exigences dirigées par les tests peuvent aider les clients à obtenir avec moins d'efforts ce qu'ils veulent vraiment.

TDR - Le jeu

Le premier jeu montre la distorsion du besoin initial exprimé par le client lorsqu'il passe par un cycle de développement d'un produit:
TDR.png (src)made with the lego tag in openclipart.org
Le produit est ici un parcours de billes et de dominos que seuls les utilisateurs vont pouvoir bâtir. Le 'product owner' (ou client) fait alors son apparition et doit étudier le modèle. Le développeur entre à son tour et doit reproduire le modèle sur les seules indications orales du product owner qui ne voit bien sûr pas le travail en cours du développeur. Le testeur doit quant à lui écouter les informations et c'est lui qui qualifie la livraison finale du développeur aux utilisateurs.

TDR - Expérimentations

Le second jeu permet au public d'expérimenter l'expression de besoins et les spécifications par les tests:
Un memo vient de tomber: une idée géniale a germée dans le service R&D et il faut recueillir ce besoin et le spécifier le plus efficacement possible afin d'intégrer cette idée au système d'information de la société ! Une réunion est donc organisée entre le porteur du message et l'équipe d'analystes et de développeurs réunie pour l'occasion.

Par l'expérimentation sur ce cas concret, on adopte intuitivement une démarche ou chacun est poussé à griffonner sur son papier pour comprendre le problème. Une fois le problème mieux cerné, on cherche à trouver un accord sur le formalisme à employer pour la spécification et les tests associés (les exemples de cette spécification). C'est un exercice enrichissant qui laisse le formalisme émerger à la différence des tests fonctionnels actuels où un outil en impose souvent la forme (par exemple des tableaux pour FIT ou du texte illustré d'exemples pour Concordion).

Je suis toujours enthousiaste après les réunions des praticiens. C'est un groupe où l'on découvre toujours énormément de choses par la pratique, une expérience toujours unique. Merci à Gilles qui va pouvoir assurer une animation au top niveau à Toronto.

mercredi 28 mai 2008

Travaillez-vous mieux sous pression ?

La pression exercée sur une équipe permet parfois de la stimuler ou de garder un bon niveau de motivation. Mais quand cette pression devient trop grande, la contre-productivité augmente... Voici un graphique issu de la pensée "lean" qui m'est apparu très clair lorsque Bent Jensen nous l'a exposé il y a quelques semaines.
agile_team_pressurepressure.png(src)
Ce que je remarque surtout, ce sont les gaspillages engendrés par des délais de livraison trop long. La pression en début de phase est insuffisante, on risque de pas assez bien utiliser un temps pourtant précieux. Avec des livraisons plus rapprochées, on conserve une pression quasi constante proche d'un niveau toujours acceptable.
Je pense qu'avec des arguments simples mais percutants comme celui-ci, on peut débattre sans choquer avec son équipe trop habituée au rythme "industriel à la française".