eric.lemerdy

Présentation du Lean Software Developement

Eric Le Merdy — Wed, 13 May 2009 07:58:00 +0200

(c'est le sac de l'année dernière)

1 2 3

Ne pas négliger la théorie
S'entraîner en s'écoutant pour se corriger
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 !

Nabaztag plugin improved

Eric Le Merdy — Mon, 23 Feb 2009 00:02:00 +0100

This is a list of improvements of the lastest version:

Use a checkbox for the "Report On Success" parameter.
Hide non mandatory parameters in an "Advanced..." section.
Text-To-Speech messages supports "${projectName}" and "${buildNumber}" special syntax to be more expressive (instead previously of adding project name and build number automatically at the end of the TTS).
Add help for each parameter.

The version is available here: nabaztag-1.5.hpi.
The wiki page also contains a new section to request changes. A Jira for such a little plug-in seems oversized, no ?

Productivité: faire son Hansei

Eric Le Merdy — Thu, 12 Feb 2009 23:45:00 +0100

"Je trouve que je passe trop de temps au travail."

Cette phrase exprime un ressenti sur une situation dangereuse.
Que faire pour améliorer cet état ? Et en premier lieu quel est cet état ?!?
Le bon sens cartésien veut que l'on ne puisse mesurer une amélioration que de ce que l'on peut préalablement quantifier.
Partant de ce constat, j'ai décidé de tenter une petite expérience cette semaine: mesurer mon temps de travail.

Ne disposant pas d'un outil aussi interactif que Talia (Pyxis en parle), je me suis monté un google document tableur pour reporter mon activité:
(Les valeurs sont en décimales d'heures)
Tous les jours, je remplis le nombre d'heures de travail

total de la journée (hors pause déjeuner)
de 'dev' on peut traduire par travail productif (slides, docs, etc.)
de 'support', les questions des utilisateurs, le support aux autres développeurs
de 'other', web surfing, checkage de mail clientèle, pro et perso, lecture de docs et... autre quoi

Le reste est calculé tout seul par différence. C'est ce qui n'est pas comptabilisé (pause toilettes (!), oubli du chrono, etc.).

Le chrono, justement, pièce maîtresse dans mon expérimentation. Je suis infidèle à la philosophie agile ou lean du 'physical communication'. Et non, je n'ai pas trois chronos qui trônent sur mon bureau. A la place, c'est un 'google gadget' sur mon bureau virtuel qui compte le temps qui passe. C'est le bien-nommé : Task List and Timer Timer

Bilan après une semaine:

L'interface du timer n'est pas très jolie. Encore un développeur qui essaye de faire une interface... Pourquoi diable a-t-il voulu créer sa propre scrollbar ? En regardant comment est fait un google gadget, j'ai compris mais au moins, il aurait pu prendre un style d'ascenseur plus joli.
A l'usage, c'est assez lourd de déclencher les chronos au changement d'activité. Un déclenchement à la voix serait sympa, ou alors une IA qui infère l'activité en fonction des logiciels en action sur le poste... C'est possible mais pas dispo. sur google gadget...
Ce qui n'apparaît pas justement est le nombre de "changements de contexte" qui est une cause classique de perte de productivité.
La tentation de l'isolation est donc importante pour augmenter facilement la productivité
L'irrégularité de la journée de travail dénote un emploi du temps assez torturé cette semaine...
Prise de conscience sur la répartition réelle des activités quotidiennes
Le côté motivant : voir la courbe de l'activité productive qui monte est assez stimulant.
Qu'est-ce-qui est fait pendant la journée de travail qui pourrait être éliminé sans conséquences ?

Je pense prolonger encore un peu le monitoring pour tirer d'autres leçons de ces données puis recommencer le mois prochain. Je n'ai pas encore terminé mon "Hansei" (auto-critique, réflexion).
En tous cas, j'encourage quiconque souffrant du temps qui passe trop vite de mener à son tour ce genre d'expérience adapté à son contexte. En effet, le lean nous apprend qu'il n'y a pas de métrique magique qui va illuminer tout seul les gains de productivité à faire. Par la suite, pourquoi ne pas partager les retours en "Hansei Kai" (réunion d'auto-critique) ?
(Ces termes japonnais sont issus de la pensée lean ^[ppt])

Paris Java Camp 3

Eric Le Merdy — Thu, 29 Jan 2009 08:40:00 +0100

Je compte participer à ce BarCamp. Il y a 22 inscrits pour l'instant. Je suis le 23ème. Je pense qu'il faut tenter le samedi au moins une fois pour voir ce que ça donne. En semaine, il m'est déjà arrivé d'être un peu fatigué le soir.

Agrandir le plan
Au plaisir de vous voir samedi prochain.

Valtech Go Ski

Eric Le Merdy — Fri, 23 Jan 2009 11:20:00 +0100

this week-end !

Wifi rabbit notifier plugin for Hudson

Eric Le Merdy — Fri, 19 Dec 2008 09:40:00 +0100

Everybody wants a BuildBunny

I rediscover yesterday Larinou, my electronic wifi buddy bunny, a brilliant representative of its Nabaztag species.
I decided to create an Hudson plugin to let my bunny alert me of my builds. I have already seen equivalent plugin for Teamcity for exemple. The Hudson plugin architecture is elegant, maven facilitates rapid immersion in the source code, provides an out-of-the-box debugging environment with Jetty and the "HelloWorld" template is brilliant to start. It was pretty pleased to implement.

A quick overview of the plugin

You will see the Nabaztag Notifier as a post build notifier:

You should then set the serial number of your bunny buddy and the associated token (not as a password in this preliminary version of the plugin).

The Hudson system configuration offers a new section related to the plugin:

This place you can configure the main API URL (in case it changes from the settings I use in France and you can set a custom voice for your bunny.

The result is that your bunny now alerts you about any build result. The position of the ears vary in respect with the buidl result. The rabbit will seam sad if a build is broken... Even if the API provides the way to light the rabbit with Hudson "build colors" (red/yellow/blue), my rabbit nevers turns on. By the way, the plugin is implemented in case Violet decide to let us pilot the colors.

One drawback is that the communication between the Hudson build machine and your wifi rabbit is not direct (there is a reverse engineering open-source project to achieve this goal). The communication is intermediated by Violet, your rabbit great creator.

Please find the first version of the plugin below (I will propose it to be a part of the main plug-in list on dev.java.net or I will put source on sourceforge later):
nabaztag.hpi

An overview of the rabbit messages

Project free-style-job gets better ! Here is the status : back to normal

Project free-style-job gets better ! Here is the status : stable

Edit: Seams like the idea was in the air: Stephan developed the same plug-in, the same day. He invokes the "white rabbit" effect. But which plug-in is the One ? The first to be committed of course !

Recherche dans les "mailing list"

Eric Le Merdy — Mon, 15 Dec 2008 13:15:00 +0100

Le service markmail.org permet de faire une recherche dans les mailing-lists des projets open source. L'interface est particulièrement utile pour repérer les messages au cours du temps. C'est un critère assez important quand on s'intéresse à l'obsolescence des frameworks et des projets.
Sur l'exemple ci-dessous, la requête choisie est: stubless web service.

Les rémanences des messages en 2008 montrent que le sujet n'est toujours pas clos aujourd'hui. L'intérêt de cette vue temporelle permet de voir quand le besoin était très fort. Ici, c'est entre 2002 et 2003. On peut donc parcourir les messages de l'époque pour savoir quel framework avait le mieux répondu au besoin. En l'occurence, il s'agit des promesses (déçues) du framework Apache WSIF (Web Servies Invocation Framework) qui s'est avéré ne pas gérer le typage complexe des paramètres des web services, ce qui est une (bonne) pratique tout de même assez répandue dès lors que l'ont veut exploiter ses web-services pour faire plus que du simple RPC.
Le service fête ses 1 an ce mois-ci. Espérons qu'il survive encore de nombreuses années !

Back from GWT and Restlet @ParisJUG - 3/3

Eric Le Merdy — Sun, 09 Nov 2008 13:49:00 +0100

See the full story in one image

Back from GWT and Restlet @ParisJUG - 2/3

Eric Le Merdy — Thu, 06 Nov 2008 22:13:00 +0100

Back from GWT and Restlet @ParisJUG - 1/3

Eric Le Merdy — Wed, 05 Nov 2008 05:40:00 +0100

Un tour à l'exposition des 100 ans d'industrie aérospatiale française

Eric Le Merdy — Sun, 12 Oct 2008 22:52:00 +0200

Eurocopter (civil)
Stand Thales (avec des bonbons): simulation et satellites de Thales Alenia Space
Session de simulateur de vol ATR sur un simulateur de vol certifié FAA (X-plane). Sans doute après avoir répondu à la question toute la semaine, l'instructeur précise à plusieurs reprises que Flight Simulator n'est pas un simulateur de vol mais un simulateur de navigation. Dans ce genre de simulateur grand public, il n'y a pas de simulation physique poussée des paramètres. Pour le démontrer, il affiche en direct les vecteurs de force représentant la portance de l'avion.
Avions de chasse réels avec armement Thales
Le très violent Tigre d'Eurocopter
Le tout nouveau radar de Thales, le Ground Master 400: un radar mis à jour par internet...
On finit en douceur avec un drone avec une propulsion à hélice en bois. Normal, la durée de vie d'un drone sur le champ de bataille: 3 mois seulement.

Jouant sur la fibre patriotique des visiteurs, l'exposition permet de réaliser un tour d'horizon des produits phares de grandes entreprises impliquées dans l'industrie de la défense et de l'aéronautique. On sent leur volonté de présenter sous leur meilleur jour au public les activités de leurs groupes. Un immense pavillon était dédié au recrutement. Leurs besoins sont en croissance.
En tant que visiteur du dimanche, j'ai particulièrement apprécié la séance de simulation d'ATR et les bonbons Thales, l'écran géant avec des images du lancement Ariane 5 était un beau défi technique avec un gros contre jour et une qualité d'image impeccable grâce à des matrices de led tricolores comme notre bon vieux tube cathodique.

slider flash parAlsacréations. Dewslider

Se rencontrer pour apprendre et partager

Eric Le Merdy — Sun, 21 Sep 2008 10:41:00 +0200

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:

Industrialisation
- Industrialiser vos développements avec Team System - par Eric Le Loc’h
- Integrated Agile Lifecycle Management for Heterogeneous Tooling Environments - par Dan Forman
Agilité
- Agilité : à monter soi-même... - par Laurent Bossavit
- UML est-il soluble dans les méthodes agiles - par Pascal Rocques
Architecture
- XForms: nouveaux concepts pour repenser une interface dans un concept web 2.0 - par Christophe Addinquy

Voir aussi le compte-rendu d'un bloggeur de developpez.com.

Aperçu sur IBM Rational Team Concert

Eric Le Merdy — Tue, 09 Sep 2008 23:44:00 +0200

jazz.net: l'indispensable site d'information sur la plate-forme.
jazz.net/blog : le blog de l'équipe dont le leader est actuellement Erich Gamma (l'un des co-inventeurs des Designs Patterns, excusez du peu)
L'équipe à l'origine de jazz est aussi celle qui a vécu le développement d'eclipse. L'IDE étant un succès et quasiment un sujet clos, l'idée du repository central était le dernier sujet à implémenter chez Rational. Ce fut pour cette équipe l'occasion de faire persister la même ambiance d'équipe ainsi que la collaboration avec des entités extérieures. Au sein d'IBM, les équipes qui testaient les premières version de jazz sont longtemps restées isolées pour maintenir le "secret" autour du projet, une façon de protéger les équipes de développement afin qu'elles puissent donner le meilleur d'elles mêmes.
Côté bonnes nouvelles, RTC est une application eclipse RCP mais basée sur les bundles eclipse.org et non pas ibm.com.

Ce qui permet d'utiliser dans RTC des plugins compatibles Eclipse.
Pour l'auditoire orienté 'management' ou les clients finaux, l'application web a beaucoup séduit. En effet, l'organisation de l'application lourde sera réservée aux développeurs habitués à eclipse tandis que l'application web assez soignée permet de bien visualiser les métriques et les indicateurs. A noter que les dashboards ne sont pas inclus dans la version express.

Au niveau du scope, la solution est clairement adressée aux PME et aux petites équipes. RTC adresse la phase de développement : la gestion des changements, la gestion de configuration, la collaboration et la gestion du build continu. L'outil est fonctionnellement déjà puissant. Mais comment fournir de si nombreuses fonctionnalités sans tomber dans les travers de l'usine à gaz ? IBM avait en effet du mal à recruter des consultants capables d'installer et de configurer ses produits ! La lourdeur des produits était un handicap à leur adoption. L'idée derrière RTC est que si l'on ne peut pas convaincre avec des produits certes puissants mais trop lourds, il faut alors simplifier et rendre accessible sa technologie en repoussant les limites de l'utilisabilité. Les "early adopters" semblent conquis mais il s'agit déjà d'aficionados d'eclipse et autres experts des plug-ins. Etant moi-même développeur d'application RCP, j'avoue avoir trouvé le produit assez affuté.
Tout l'enjeu de RTC sera de poser des concepts suffisamment simples et consensuels (work items, stream, etc.) afin que leur implémentation dans l'outil ne reproduise pas les lourdeurs des produits maison dont il est l'héritier.

TDR Applied

Eric Le Merdy — Fri, 22 Aug 2008 10:32:00 +0200

Last week, we used TDR^[1] to help us understand a problem and the solution finally emerges.

The problem

This is an eclipse RCP application that uses the well known MVC pattern. The data model is hierarchic and several editors can be opened at different levels. The problem is that we have some transversal data that can be viewed along the tree structure. How can a view be always updated against users editions ?
Considering the following structure:

root
- node1 - use transverse data X, Y
- node2 - use transverse data X, Z

Description of the scenario:

Editor on node 1 is opened
Editor on node 2 is opened
Some changes are made in editor 1 on transverse data X
The editor is "dirty".
Some changes are made in editor 2 on transverse data X
The editor is "dirty".
Editor 1 is saved.

How can the changes on transverse data X made in the first editor be reflected in the second one ?

Solving the problem

We shortly came to the fact that an event should be fired when the data model is changed. Editors are registered to listen for those events to make them aware that they should reflect changes. This is not the complicated part of the problem.
The "reconciliation" algorithm that the editor should implement is not trivial.
This was the time to stop trying to code it, step up the team in front of a blank white board and use TDR^[1] to help us specify with some examples.

The white board

After a short discussion, we found a notation to represent data attached to an editor:

Saved: saved data before any edition
Modified: modified data during edition. This is typically a bean that is tied on UI components
Data model: the new data model that is embedded in the event to alert editor that data changed
Output: the output of the algorithm: the reconciliated data

(Our data are indexed list of objects.)
Then we started to scratch on white board. The white board has been "saved" on this sheet:

Then we set up test cases from simple to complex (1.). For each of them, we specify data (2.) as couples: C_A, D_A (Clé (key), Data) and C_A', D_A' for modified data.
The final algorithm emerges in the box (3.). The result is simple:

if the "Saved data" is the same than "Modified data"
- "Output" should be set to "Data model"
otherwise
- "Output" should be set to "Modified data"

Big letters in output column learns us that algorithm applied for list comparison can be also be applied for list elements themselves when the case become more complex.

Lesson learned

TDR^[1] is helping emerging conception
Examples from a TDR^[1] session are capitalized in unit tests (in our case)
This TDR^[1] session became the technical documentation (because the client want a technical documentation)
Our examples remains generic because we found it useless to represent real data (a collection of objects
TDR^[1] is helping to make the implementation of a solution simpler
The client were intrigued to see programmers out of their usual 'behind-the-screen' position ! It helps our team to show what we were working on.

[1]: Test Driven Requirements ou spécifications dirigées par les tests.

Overview of Eclipse RCP UI testing tools

Eric Le Merdy — Tue, 29 Jul 2008 23:26:00 +0200

-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.

De retour de la session TDR

Eric Le Merdy — Mon, 28 Jul 2008 23:10:00 +0200

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:
(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.

Bilan du SI de notre asso d'anciens

Eric Le Merdy — Sun, 29 Jun 2008 01:21:00 +0200

Que pensez-vous des discours mettant en avant la débrouillardise et les talents de bricolage des réalisateurs de SI? Cela amène l'industrie à admirer les héros de l'artisanat et des heures supplémentaires... Que répondre alors à la question ouverte: "Comment bâtir un système d'information industrialisé qui réponde aux besoins de ses utilisateurs en minimisant la composition anarchique de développements spécifiques ?". Cela passe sans doute par une plate-forme standard, robuste, ouverte et extensible, bref, le Graal du Système d'Information.
Je vais prendre de cas du système que nous avons mis en place avec des collègue>s étudiants pour construire le système d'information de notre association d'anciens du Master GLR.

L'Amglr, une association de gestion d'anciens étudiants.

Créée en 1987 pour promouvoir le DESS IF (Informatique Fondamentale), l'association s'appelait alors ADESIF (Association des Diplômés d'Etudes Supérieures d'Informatique Fondamentale). L'existant pour nous en 2005 était donc un listing d'anciens adhérents qui allait constituer notre base initiale d'adhérents. Après avoir pris la décision de remonter l'association, le besoin d'un système d'information s'est fait naturellement sentir à la fois pour la gérer et pour fournir les services aux étudiants.

Des besoins...

Une Association loi 901: des adhérents, des statuts "classiques", un bureau pour animer tout ça et une trésorerie : un système d'information dont les données métier sont centrées sur les adhérents (attention à la loi sur les fichiers de personnes physiques, déclaration à la CNIL conseillée), pas de comptabilité compliquée dans notre cas.
Des anciens étudiants: but d'insertion professionnelle, maintient de relations, évolutions de carrière, mise en relation de personnes : réseau social.

Les besoins tournent donc autour de ces concepts:

...et des contraintes

Contraintes du SI
coût global	gratuit si possible (sauf nom de domaine)
licence	les licences libres ont plus de chance d'être gratuites...
serveur	linux, php, MySql (hébergement amical par un membre du bureau)
coût de main d'oeuvre	gratuit (bénévolat des membres du bureau)
type de système	distribué et accès web (ou en tous cas très ouvert)
sécurité	assez forte pour ne pas dévoiler les informations personnelles des membres

Cartographie actuelle de la solution

Utilisation de produits:
Le choix du CMS s'est porté sur le produit phpbb couplé à un "mod" Gf-portal permettant de définir en plus du forum, une arborescence de pages statiques ou dynamiques. La qualité des produits phpbb est parfois inégale. Cependant, nous n'avons pas rencontré de problèmes notables en utilisant ce couplage.

Par la suite, un planet a été installé pour fédérer les blogs des adhérents volontaires.
Personnalisations du produit:
Style: Par installation et modification d'un thème additionnel.

Contenu statique: Autant de temps que de rédiger des pages HTML standard, l'intégration dans le portail demandant un temps négligeable.
Développements spécifiques:
Contenu dynamique: La fiche adhérent a été un peu laborieuse (php basique), la géo localisation fut l'occasion pour l'auteur de cette partie de reprendre un code qu'il avait déjà écrit pour un autre site. Tandis que l'annuaire en ligne est l'intégration au portail de l'export XML de la base adhérent mise en forme avec un template XSLT.

Génération dynamique de l'annuaire: Un "wizard" est mis à la disposition du bureau par Java Web Start pour générer l'annuaire pdf complet. Les technos sous-jacentes sont: Swing, FOP (donc XML et XSL-FO) et XSLT. Pourquoi un choix si atypique dans cette architecture full php/MySql? Pour des raisons de compétences (ça n'arrive pas en entreprise, on aurait loué a ressource compétente ) et Java Web Start car java n'était pas installé côté serveur.

Outils fournis par l'hébergeur: une adresse mail pour le bureau (avec antispam), des statistiques (WebDruid)

Retrospective

"What went well?"	"What did not go so well?"
Couverture fonctionnelle assez étendue Taux d'utilisation des services par les adhérents Continuité de service (grâce à notre hébergeur) Coût (grâce à notre hébergeur)	Hétérogénéité des technologies Multiplication des produits installés, peut rendre la maintenance difficile Un SI sur internet génère beaucoup de SPAMs (mail et ouvertures de compte...) contre lesquels il faut apprendre à se défendre. Une fois que le système est en place, changer les choses devient plus compliqué : inertie du système... Séparation des données entre le référentiel d'adhérent (données métier) et les comptes forum (dans l'applicatif): cela aboutit à une fiche adhérent pour éditer les données métier et un profil pour le forum...

"What went well?"

"What did not go so well?"

Couverture fonctionnelle assez étendue
Taux d'utilisation des services par les adhérents
Continuité de service (grâce à notre hébergeur)
Coût (grâce à notre hébergeur)

Hétérogénéité des technologies
Multiplication des produits installés, peut rendre la maintenance difficile
Un SI sur internet génère beaucoup de SPAMs (mail et ouvertures de compte...) contre lesquels il faut apprendre à se défendre.
Une fois que le système est en place, changer les choses devient plus compliqué : inertie du système...
Séparation des données entre le référentiel d'adhérent (données métier) et les comptes forum (dans l'applicatif): cela aboutit à une fiche adhérent pour éditer les données métier et un profil pour le forum...

Le meilleur jugement sera celui de nos successeurs car ce sont eux qui vont assurer la suite, je suis finalement curieux de voir les bonnes idées qui nous ont échappé. Il faut peut-être chercher à utiliser une plate-forme de service en ligne de communautés de type web2.0. Ce business model est déjà déployé par certains sites comme ning par exemple. De plus, je constate un certain éloignement du bureau actuel par rapport à la dernières promotions qui n'utilise presque pas les services. C'est réellement le moment de changer pour conserver cette proximité nécessaire entre les animateurs de l'association et les promotions courantes.
En tous cas, ce fut pour moi un bon moyen de me rendre compte de la difficulté de fédérer des gens sur un si petit dénominateur commun (une année de Master pro.). C'est une expérience qui m'a donné confiance. En prenant les choses en mains avec des collègues, nous avons été capables d'aller plus loin qu'on aurait pu l'imaginer au départ. On se surprend alors du temps qu'on peut passer sur le sujet. Ca a permis de mieux me connaître et de comprendre ma relation au travail. J'ai alors compris que j'avais une forte capacité de travail aussi longtemps que la motivation de l'atteinte de d'objectif était présente (Génération Y?). J'ai aussi pris conscience de la valorisation mais aussi du risque associé à la charge d'une responsabilité.

Quels objectifs pour l'avenir?

A l'heure où la tendance du recrutement (en apparence du moins) cherche moins les profils "formatés" des écoles que les expériences personnelles des candidats, la valorisation des filières de Masters Pro. passe sans doute par une meilleure visibilité de la formation au niveau national voire international. Un réseau d'anciens à la fac peut être cet outil qui démarque un Master pour son attraction des étudiants entrant ainsi que pour la qualité des débouchés professionnels. Cette période très favorable aux candidats sur le marché actuel ne permet pas de tester la facilitation de l'insertion professionnelle mais l'ADESIF a déjà montré par le passé son efficacité pour l'insertion professionnelle.

Technology Readiness Levels

Eric Le Merdy — Fri, 20 Jun 2008 19:54:00 +0200

A l’extérieur de votre organisation est le chaos, les technologies naissent et meurent en fonctions de facteurs incontrôlés et incontrôlables (les effets de mode, la réglementation en vigueur, la volatilité des marchés, etc.).
A l’intérieur de votre organisation règne l’ordre, la maîtrise technologique, mais c’est aussi le royaume du « legacy-qui-marche-bien-pourquoi-on-le-changerait ». L’obsolescence des applicatifs vous guette, vous êtes fan des nouvelles technologies mais l’entropie de votre organisation ressemble à des sables mouvants qui ensevelissent toute action pour tenter d’y échapper. Comment alors stabiliser la technologie alien qui serait propre à sauver votre organisation de la décrépitude numérique ?
Il existe pour cela la méthode des Technology Readiness Levels (TRLs) pour vous sauver. C’est une méthode qui permet d’évaluer une technologie nouvelle pour la qualifier apte à supporter le développement de vos nouveaux produits. Voici les degrés d’avancement de la méthode (Origine: DOD (2006), Defense Acquisition Guidebook) :

TRL 1: Principes de base observés et signalés
TRL 2: Concepts et/ou applications de la technologie formulés
TRL 3: Fonction critique analysée et expérimentée et/ou « proof-of-concept » la caractérisant
TRL 4: Validation de l’artefact produit en conditions expérimentales
TRL 5: Validation de l’artefact produit en conditions de pré-production
TRL 6: Démonstration du modèle du système/sous-système ou du prototype en conditions de pré-production ou de production
TRL 7: Démonstration du prototype du système en conditions de production.
TRL 8: Complément du système résultant et « qualification » pour la production à travers des tests et des démonstrations (environnement de pré-production ou production)
TRL 9: Exécution du système résultant « prouvée » à travers le succès de la version en production

Plus on avance dans la méthode et moins on doit avoir de technos candidates qui passent les conditions nécessaires. C’est un peu comme cela que fonctionnent les organismes de recherche qui ne font pas aboutir toutes leurs recherches avec une application fonctionnelle et encore moins industrialisable.
Cette méthode a été développée par la NASA. J’ai adapté les termes à un produit logiciel. Par exemple, citons cette analogie : leur environnement de pré-production est le sol et celui de production de l’espace. Je pense que si c’était le cas en informatique, il y aurait sûrement plus de candidats à aimer la prod…
Ce processus est « outillé ». Un calculateur d’avancement réalisé avec Excel permet de suivre l’avancement au sein de la méthode. Attention, les couleurs piquent un peu les yeux… On peut décider de s’évaluer au choix avec le TRL, le Manufacturing Readiness Level et les Programmatic Readiness Level. Cela ajoute plus ou moins de questions au formulaire pour calculer l’avancement.
Voici la fiche de ce programme excel à télécharger (et sa documentation pdf - 16 pages)

Cette méthode est utilisée dans la société de ma mission actuelle comme base au processus de travail de l’équipe R&D. Ils ont des jalons à chaque degré avec des documents types à produire. Cette méthode qui a fait ses preuves aide effectivement à atteindre l'objectif qu'elle se fixe. On ne peut malheuresement pas tout rendre agile. Par contre l'agilité peut permettre de gagner en rapidité sur les "proof-of-concept" ce qui peut augmenter la taille de l'échantillon des technologies candidates et ainsi renforcer la fiabilité et la pertinence du choix final.

Travaillez-vous mieux sous pression ?

Eric Le Merdy — Wed, 28 May 2008 23:37:00 +0200

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.
(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".

My brother is back

Eric Le Merdy — Wed, 28 May 2008 22:10:00 +0200

I am very pleased to announce my twin's first post since 2006 ! Visit now his blog : sebastian.lemerdy.free.fr !