Nouvelles de Limoges

Pour mon fils Emmanuel je suis venu m'installer à Limoges.


C'est à la mi-mai 2008, c'est-à-dire il y a deux mois et demi, que j'ai quitté Montech dans le Tarn-et-Garonne pour la Haute-Vienne. C'était une période idéale pour s'installer.



J'habite maintenant pas très loin du centre de Limoges, près de la gare.



J'ai trouvé une petite maison avec vue et jardin, et des voisins fort sympathiques. La voisine au Nord élève des poules (c'est génial, non ? En pleine ville en plus), le voisin de l'Ouest a un magnifique potager (même remarque), au Sud ce sont des étudiants, et du côté Est on me tient parfois en rentrant du boulot des discussions très intéressantes.


La dernière fête organisée pour Emmanuel et ses copains a été très réussie aussi.

(des pingouins qui se mettent à l'eau et s'éclaboussent, quel rapport ? me direz-vous)

Côté boulot sur Limoges dans ma spécialité, j'ai commencé une mission au CNASEA ce mercredi. J'y ai déjà rencontré des personnes attachantes.

Petite fête du côté des étudiants vendredi soir, et hier samedi j'ai eu l'occasion à Blond au festival Estivol, de faire de la montgolfière au-dessus du pays.

(photo non contractuelle)

Tout ça commence bien.

"The F5 Factor"

Une tendance généralisée dans le développement informatique est l'utilisation d'environnements de développements (IDE, Integrated Development Environment), comme Eclipse, dont je vous conseille par ailleurs la 3.4 « Ganymede ». Ces outils apportent par exemple la syntaxe colorée, la navigation entre fichiers, mais aussi l'aide à la saisie et la compilation à la volée, parmi des milliers d'autres fonctionnalités (je n'exagère pas).




Je pense qu'il faut distinguer entre ces fonctionnalités par leur type d'interaction avec l'utilisateur :

• sans interaction : la coloration syntaxique, par exemple. La frappe suit son cours, et le résultat est formaté à l'écran.
  

• interaction au cours de la frappe : vérification de la syntaxe, aide à la saisie, compilation en tâche de fond... Ces assistants se déclenchent certes de façon asynchrone (ouf !), mais pompent quand même des ressources, aussi bien sur la machine que dans le cerveau de l'utilisateur (les fenêtres pop up ne sont jamais neutres pour un cerveau humain ;-)), ce qui au final freine le rythme naturel de la frappe... tout en accélérant par ailleurs la saisie des noms de classes, de méthodes, de variables. Avec une utilité à mesurer pour chacun, donc.
  

• interaction par décision de l'utilisateur : lancer l'exécution de tests ou d'une application par exemple. Cela se fait en général par un raccourci-clavier, plus rapide qu'un clic souris. Cette interaction ne perturbe pas le flot de développement : l'utilisateur déclenche de lui-même les événements.
  

Je ne parle pas des interactions de type Wizard, où l'utilisateur suit une série de formulaires.

Ajoutons un quatrième type, l'interaction par déclenchement en ligne de commande d'un script par l'utilisateur. En gros, je vais dans ma console, je tape ma commande (disons : mvn clean install), elle s'exécute, et je me rends le plus souvent dans une autre application pour voir le résultat (disons : un éditeur de texte, pour voir les logs).

Cette dernière interaction est la plus primitive et naît de la nécessité (pas d'intégration continue sans scripts autonomes, par exemple), et pourtant c'est celle qui est la plus perturbatrice, car on navigue entre des contextes différents, avec leurs IHMs et leurs temps propres. Là où les IDEs font énormément gagner de temps, c'est bien sur la suppression des interactions en ligne de commande.

Prenons par exemple un script qui fabrique et déploie une application web (je me place dans le cas où le serveur web n'est pas embarqué dans l'IDE, cas le plus courant pour moi). Le scénario classique est le suivant :

1. IDE : finir de modifier le code
2. console : lancer le script en ligne de commande de fabrication et de déploiement
   
3. navigateur web : voir le résultat

Pour gagner en puissance, nous pouvons faire la chose suivante qui nous évite le passage par la console :

1. IDE : finir de modifier le code
2. IDE : lancer le script externe par un raccourci clavier (voire obliger son lancement automatique après toute modification)
3. navigateur web : voir le résultat

Mais je pense que c'est quand même une perte cognitive : on demande à un contexte (l'IDE) de réaliser quelque chose, qui peut d'ailleurs mettre du temps, dont on verra le résultat dans un autre contexte (le navigateur). Cognitivement on est déjà dans le résultat (on sait ce qu'on demande au final : un résultat dans le navigateur), mais du point de vue de l'outillage on est encore dans la préparation (l'IDE).

Pour moi la bonne séquence est la suivante :

1. IDE : finir de modifier le code
2. navigateur web : rafraîchir la page en cours (touche F5), ce qui lance le script externe, puis affiche le résultat, sans changer de contexte
   

J'appelle ça le « facteur F5 » ("The F5 Factor" en anglais). Ce principe est orienté contexte de résultat, et non environnement de développement.

Si possible, disposer de deux machines, une pour le code, une pour le navigateur : ainsi il ne s'agit que d'appuyer sur F5 sur le clavier d'à côté. Pas d'autre manipulation du genre Alt-TAB. Aucun changement d'application, de perspective, de vue, de fenêtre, de space... ni aucun switch mécanique : on tourne simplement la tête.


Dans ce modèle, le serveur web doit évidemment être sur la première machine, ou en tout cas avoir accès aux fichiers qui ont été modifiés.


J'essaie de faire en sorte que mes outils de développement web, notamment mes outils de maquettage, mais aussi mes outils de validation, appliquent le « facteur F5 ». Cela pose de nombreuses questions d'intégration et de réactivité : sur la parallélisation des traitements, sur l'optimisation, sur la gestion des fichiers, etc. mais aussi sur le découpage des composants : s'il faut dérouler ne serait-ce qu'une partie de scénario fonctionnel pour arriver sur la page dont on veut valider le HTML, on n'est plus dans le « facteur F5 ». C'est dire s'il faut parfois pour se donner les moyens réarchitecturer entièrement un projet, et notamment repenser les phases de maquettage.

Ces outils sont évidemment couplés à des scripts autonomes (toujours pour l'intégration continue), mais les scripts encapsulent les outils, et non le contraire.

Au final, un très grand confort de développement : modifier deux lignes de Java, et voir le résultat quasiment immédiatement dans le navigateur. On se croirait en PHP ?... En fait c'est encore mieux, car si toutes les pages du site sont testables en appliquant le « facteur F5 », le temps gagné est inestimable. Par ailleurs il s'agit là d'une méthodologie, et c'est donc transverse aux technologies.

Pour mémoire, mon dernier outil en date qui applique le « facteur F5 » est un lanceur d'applications (Java) depuis une page web, qui en affiche ensuite les résultats à l'écran : résultats images, SVG, HTML ou texte. À utiliser en phase de maquettage, en appuyant sur... F5.

Kazeii.com - Gérer, suivre, partager sa construction de maison

Fin 2007 et début 2008, je m’étais lancé avec un copain établi près de Toulouse, Jérémy Girard, dans l’aventure d’une start-up web. Le thème : suivi de projets de construction de logements individuels et collectifs.

Il s’agissait d’une plate-forme web classique, de blogging, d’albums photos, etc. au service des particuliers qui font construire leur maison, cela afin de leur permettre de montrer aux copains et à la famille l’avancement des travaux (les internautes qui font construire ouvrent souvent un blog pour cela), d’avoir une vision synthétique des différentes étapes, voire d’utiliser la plate-forme pour gérer ses postes comptables et faciliter ses échanges avec l’architecte ou le maître d’œuvre. Le fait d'avoir une plate-forme centralisée pour plusieurs blogs de constructions, permettait également de créer une communauté autour du sujet.

L’idée est simple, et très bonne à mon avis. On avait pas mal dégrossi le concept, pondu un Business Model, demandé leurs avis à plusieurs professionnels, sans compter évidemment les particuliers rencontrés, puis commencé le développement. Étant tous les deux développeurs Java, ça travaillait fort.

Malheureusement, après un bout de chemin ensemble, il m’est apparu que l’équipe de Batilog.com (nom initial du projet) ne fonctionnait pas avec une vision commune. Proche, mais pas commune. Or dans un projet comme celui-là, l’énergie étant forcément présente, ce qui compte c’est la cohérence. Malgré les indéniables qualités humaines de part et d’autre, et le bon feeling, j’ai donc pris la sage décision de sortir du projet en l’état. Sage décision à mon avis en terme d’entrepreneuriat. Jérémy a continué d’arrache-pied seul pour sortir une version publique (ne me demandez pas quelle aurait été ma position : vous m’avez vu sortir une version publique dans les mêmes délais ? ;-) que voici : Kazeii.com - Gérer, suivre, partager sa construction de maison.

La version a été rendue publique hier dimanche 29 juin 2008, et il y a déjà presque 100 inscrits !

Je voudrais chaleureusement féliciter Jérémy pour avoir lancé son site. Grand bravo, et le succès pour cette implémentation d’une très bonne idée ! Il n’y a qu’à lire certains commentaires pour voir que l’accueil est positif ; Jérémy a fait connaître son site dans divers forums francophones, notamment par ici : Forum BricoZone - Sujet : Comment assurer un bon suivi de sa construction.

Bonne route Jérémy :-)

La vérification à la compilation, c'est bien

Soit un modèle où l'on diffère, sous forme de commandes, des appels à passer à une certaine classe. Par exemple, dans le cas où l'implémentation finale de la classe est distante, on souhaite passer tous les appels dans une seule connexion réseau : on va donc trouver un moyen de « sérialiser » les intentions d'appels, en général sous forme de texte, on les enverra en lot, puis côté serveur la liste sera détricotée, les appels passés, et on retournera la liste des résultats (dans le cas où tout se passe bien).

Pour illustrer le problème, disons que l'interface de la classe distante s'appelle « Toto », avec les méthodes « doSomething(int, int) » et « doSomethingElse(String) ».

On faisait jusqu'ici un appel réseau pour chaque invocation :


Avec le code Java ci-dessous :

final Toto toto = <proxy>; // proxy pour appel distant

toto.doSomething(2, 5); // 1er appel
toto.doSomething(14, 8); // 2e appel
toto.doSomethingElse("Fantastic!"); // 3e appel
toto.doSomething(0, 1); // 4e appel

Après s'être aperçu qu'on pouvait gagner en performances, nous décidons que du point de vue du réseau il n'y aura qu'un appel, qui agrègera les invocations :


Eh bien je ne sais pas pourquoi, mais pour faire ça certains pensent à écrire la chose suivante :

final Commands commands = new Commands(Toto.class);

commands.storeCommand("doSomething", 2, 5); // 1er
commands.storeCommand("doSomething", 14, 8); // 2e
commands.storeCommand("doSomethingElse", "Fantastic!"); // 3e
commands.storeCommand("doSomething", 0, 1); // 4e

CommandUtils.executeCommands(<proxy>, commands);

C'est tout à fait dommage, car on perd l'avantage de la vérification à la compilation : si on se trompe dans une chaîne de caractères qui contient un nom de méthode, ou dans le type des paramètres d'une méthode, on ne s'en apercevra qu'à l'exécution.

En fait il faut s'arranger pour pouvoir coder ainsi :

final Toto toto = FutureUtils.newFuture(Toto.class);

toto.doSomething(2, 5); // 1er appel
toto.doSomething(14, 8); // 2e appel
toto.doSomethingElse("Fantastic!"); // 3e appel
toto.doSomething(0, 1); // 4e appel

FutureUtils.execute(<proxy>);

C'est-à-dire qu'il faut s'appuyer le plus possible sur ce qui compile... déjà.

Un très bon modèle pour penser de cette façon, est EasyMock : ce framework d'aide aux tests permet d'enregistrer les appels à contrôler par du code d'appel ! On a donc la vérification de la syntaxe à la compilation, puis évidemment la vérification de la séquence à l'exécution.

Message de maintenance

L'hébergeur Online a procédé ce week-end à un changement de plate-forme technique du site de ma société Avantage Compris. Du coup plus rien ne fonctionnait. Pour seulement 5 simples pages, c'était un peu dommage.

Ça y est, c'est rétabli.

Pour les techniciens, attention à passer vos XSLT en UTF-8 : certaines configurations de Sablotron n'acceptent pas l'ISO-8859-1 dans les feuilles de styles (mais pour le XML en entrée, bien).

L'Irlande a dit non au traité de Lisbonne

Apparemment les Irlandais qui ont profité de la chance que leur démocratie à eux leur permet de s'exprimer sur un sujet qui les engage au sein de l'Union Européenne, ont répondu majoritairement « non » à la question qui leur était posée quant à la ratification par leur pays du traité de Lisbonne, lui-même vendu comme un mini-traité remplaçant le TCE, qui en 2005 avait déjà montré le gouffre abyssal entre certaines couches de la population européenne, notamment de la population française, et les élites-zet-dirigeants.

La démocratie est un sujet qui me tient à cœur. Peut-être plus encore que l'Europe, c'est dire. Ainsi le projet « Les Fûts » est, ou fut, un projet d'empowerment de citoyens, en l'occurrence de citoyens déjà engagés dans l'action collective et associative.

Pour en revenir à ce 13 juin 2008, je trouve admirable que les Irlandais aient dans leur Constitution une clause qui à oblige à organiser un référendum pour un sujet de cette nature. Je trouve évidemment lamentable qu'on ne prenne pas en compte le « non » français de 2005.

Car quelle que soit ma virulence à défendre le « oui », je suis avant tout pour un régime démocratique, c'est-à-dire qui donne le pouvoir à un peuple qui a les moyens d'en être responsable. Quand la question se résume à « vous sentez-vous prêt(s) à ratifier ce traité que vous avez dit à maintes reprises incompréhensible et loin de vos préoccupation ? », je trouve sain, je trouve hygiénique, que la réponse soit « non » quand les citoyens consultés ne se sentent effectivement pas prêts.

Je lis çà et là qu'il y aurait eu 885 000 Irlandais à voter non, contre 764 000 ouis, sur un traité qui doit être ratifié à l'unanimité au sein de 27 pays qui comptent au total 500 millions d'habitants. Ce sont les règles que nous nous sommes fixées, simple constat.

Une première remarque, qui me trouble énormément, c'est que si sur lesdits 27 pays, disons, 20 étaient à ce point pour le « oui », que n'ont-ils uni leurs forces de propagande (médias, conférences, meetings... ils avaient même les moyens de faire des films et de les diffuser dans les cinémas !) pour agir et faire œuvre éducative, sinon marketing ? La construction européenne les concerne-t-elle aussi peu qu'ils s'en tiennent à pleurer quand le mal est fait ?

L'autre remarque, je la tire d'un adage qui veut que l'éducation et la paix soient sœurs siamoises. En effet, dit vite, l'éducation permet la paix (elle en montre les bienfaits, les limites, la fragilité, les conditions), et la paix permet l'éducation (elle en est une condition). Or nous construisons l'Europe certes pour le bien-être économique et pour que tout le monde parle anglais, mais surtout et avant tout pour la paix. Aujourd'hui d'ailleurs cette paix a de plus en plus une composante écologique. Un corollaire de cette paix, c'est l'éducation, et notamment l'éducation politique, avec ses ramifications dans la plupart des sciences humaines. Ne pas construire l'Europe sur cette base-là, c'est ne pas construire l'Europe dans l'objectif de la paix.

Alors on peut pleurer d'un « non » dû à une inexistante propagande (j'emploie ce mot de façon pragmatique, sans connotation morale) d'État, mais il montre surtout un désintérêt des penseurs de l'Europe pour la question éducative. Et soyons clairs, je ne dis pas que le traité serait passé avec davantage d'éducation, car je ne confonds pas propagande et éducation : je dis qu'avec davantage d'éducation en amont le hiatus, pour le moins, entre ceux qui ont rédigé et manigancé ce traité, et ceux qui étaient consultés, voire ceux qui auraient dû l'être dans une visée démocratique, se serait grandement réduit. En particulier le traité lui-même n'aurait pas été rédigé dans cette forme si complexe. Accorder de l'importance à l'éducation, c'est aussi permettre un certain feedback entre les diverses couches sociales.

Inscription au Déjeuner sur web n°2 et Je-ne-sais-quoi

Voilà voilà, je me suis inscrit à la deuxième édition de Déjeuner sur web, à Toulouse, sur le site de la Mêlée Numérique.

C'est l'occasion d'une « magnifique » annonce Twitter :


Oui, j'utilise Twitter entre autres comme révélateur de TODO List : les choses que j'ai à faire n'apparaissent que quand elles sont faites. Comme ça, pas de stress. Et cela comble le Knowing-Doing Gap.

... J'ai comme l'impression que bloguer sur le Knowing-Doing Gap à partir d'un événement aussi anodin qu'une inscription à quelque chose qui n'a pas eu lieu, peut donner la même impression d'inutile mise en abyme que Twitter soi-même. Pourtant pourtant quelque chose se joue...

Déjeuner d'ex-Fûteurs et retour sur les Fûts

J'ai déjeuné ce midi avec les deux autres instigateurs du projet original « Les Fûts », c'est-à-dire Christophe et Pierre (ils sont dans la colonne à droite).

Repas très sympa à Gradignan ; on mange toujours aussi bien au Thé à la menthe.

On est revenus un peu sur le projet des Fûts (entre moults autres sujets). Pour ma part ce que j'en retiendrai :

• l'idée d'une plate-forme web avec fédération d'identité pour les associations reste « une idée qu'elle est bonne »
• pour des sites mon-associatifs, des solutions existaient à l'époque, et de nouvelles existent aujourd'hui, ou ont évolué. On a parlé par exemple de Joomla!, de Guppy...
  
• la disponibilité de l'équipe n'était pas là, ou mauvaise : on ne se voyait que quelques fois par semaine, par exemple. Or pour un tel projet, qui demandait un fort investissement technique, il faut s'y mettre à fond, et surtout sur de grosses plages de temps.
  
• à mon avis, le modèle économique basé sur un modèle associatif n'était pas bon. C'est une autre façon de voir le point précédent.
  
• on s'est dispersés à tort sur deux objectifs : des réunions d'architectes NTIC bordelais, et une plate-forme web pour les associations, les architectes développant (imaginait-on) la plate-forme.
• et évidemment, on a été trop ambitieux sur les délais affichés...

Gros problème de focus, je dirais.

Mais l'idée reste bonne ;-)

Validation de backups

OK, on fait tous des sauvegardes, ou backups, automatisés.

Un des risques est qu'un grain de sable s'immisce dans le processus de backup, et que le fichier de sauvegarde soit au final invalide, c'est-à-dire qu'il ne puisse plus servir à la restauration des données. Pas très pertinent, du coup.

Pour gérer ce risque, on peut disposer d'une machine jumelle, sur laquelle on va régulièrement procéder à une restauration de l'environnement qui a été sauvegardé. Mais il s'agit là de tâches « bas niveau », comme dirait un administrateur système de mes connaissances, et elles ne valident que le processus de restauration, non pas que les données ont été réinstallées avec succès.

Pour illustrer ce risque, imaginons que telle procédure de backup consiste à créer l'archive d'un répertoire. Et que pour un bête problème de configuration qui change, se retrouve archivé un mauvais répertoire ou un répertoire vide. Toutes les opérations techniques de sauvegarde, copie, transfert, et restauration, se passeront bien, mais les données issues de la restauration n'auront aucun intérêt. Et on ne s'en apercevra qu'en cas de besoin... (Ne rigolez pas, ça m'est arrivé).

J'ai donc pensé à automatiser une validation « applicative » de la restauration quotidiennne de mes données sauvegardées.

Prenons l'exemple d'un repository Subversion, qui est le cas le plus critique pour le développement. À intervalles réguliers, j'ai un processus qui :

1. récupère sur une machine dédiée la dernière version du backup du repository
2. extrait les fichiers
3. les installe en tant que repository temporaire, et démarre une instance svnserve (serveur Subversion)
4. simule un client (un poste de travail de développeur), et se connecte au serveur démarré pour rapatrier tous les fichiers
5. fait quelques mesures et validations sur les fichiers ainsi rapatriés : le nombre de projets est supérieur à 10, etc.
   

Au fil du temps, je vérifie que les restaurations de backups vérifient certains critères, comme :

• le numéro de révision Subversion ne cesse de croître avec le temps (non-réversibilité)
• le nombre de projets ne cesse de croître avec le temps (loi d'entropie du développement Java)
  
• la taille de l'archive croît grosso modo avec le temps (avec une tolérance de -2 %, car cela dépend de la compression)

Je pourrais aussi vérifier que :

• le numéro de révision Subversion rapatriée correspond à peu près (à 100 près, par exemple) à la révision Subversion qui est active sur la machine de production
  

J'ai une console qui me permet de suivre ces évolutions.

L'architecture technique que j'utilise est la suivante :

• Le serveur « ref » contient les données de référence, en l'occurrence le repository Subversion utilisé en développement
• [1]. À minuit (0:00), une hot copy est créée localement, compressée, et envoyée par FTP vers le serveur « ftp », qui est une sorte de sas.
  
• [2]. À 1:00, l'archive est récupérée et copiée localement sur « bkp », qui collecte une copie de tous les fichiers de sauvegarde de l'architecture.
• [3]. À 2:00, l'archive est récupérée et copiée localement sur « ci », qui est vu comme un serveur d'intégration continue (Continuous Integration).
• Les fichiers de l'archive sont extraits, installés en tant que repository local, svnserve est démarré, des tests sont passés, etc.
• Un rapport est émis, qui pourra être agrégé aux autres et servi par un Web Service.
  

Une console agrège ensuite les différentes informations. Voici un exemple de tableau de bord :

• La console présente les noms des derniers fichiers de sauvegarde, leur date, leur « âge » en jours, leur taille, et indique s'ils ont fait l'objet d'une restauration ou non.
• La mention « restored » indique que la restauration du fichier a réussi.
• La mention « NO » indique que la restauration n'a pas eu lieu (il y a quelques progrès à faire, visiblement)
• Les mentions « -1 », « -2 », etc. indiquent que le dernier fichier de sauvegarde n'a pas encore fait l'objet de restauration, et que la dernière restauration pour ces données a eu lieu sur l'avant-dernière sauvegarde, l'antépénultième, etc.
  

L'intérêt de la machine sas « ftp » est de pouvoir interdire les accès directs de « ref » vers « bkp », dans le cas de réseaux différents par exemple. Dans le cas où tout ce beau monde est sur le même réseau, on peut s'en passer.

La machine « bkp » a bien comme responsabilité de centraliser tous les backups de l'architecture. On pourrait avoir par exemple :

Une remarque :

• il est intéressant d'imposer que les données de référence soient systématiquement versionnées en amont (exemples : Subversion, un wiki, etc.). Une réflexion à mener pour les données métier si vous voulez mon avis...
  

Bon, je suis bien content. Ça fait longtemps que je souhaitais implémenter ce système.

Et vous ? Quelle garantie vous offrez-vous sur la pertinence de vos backups ? Vous contentez-vous de faire confiance à vos logiciels utilitaires ?

Cela vous paraît un peu compliqué ?... ;-)

Assertions JUnit 4.4 : assertThat()

Merci aux blogueurs de Xebia France de me faire découvrir la méthode assertThat() de JUnit 4.4, sur laquelle je ne m'étais pas encore penché : Simplifier les assertions JUnit et améliorer vos tests.

Avoir des tests les plus clairs possible est une Bonne Chose™.

À lire : Scrum and XP from the Trenches

Dans mon post précédent sur Scrum, j'ai oublié de reparler du bouquin de Henrik Kniberg, « Scrum and XP from the Trenches ». Les opérationnels et les techniciens liront ce PDF gratuit comme un roman. Il s'agit d'une plongée passionnante dans le quotidien d'un Scrum Master.

Faites-vous de l'agile ?

Anecdote rapportée :

- Faites-vous de l'agile dans votre organisation ?
- Oui !
- Ah, et quelles pratiques avez-vous adoptées ? XP (eXtreme Programming) ?
- Non.
- Le pair programming ?
- Non.
- Euh... Vous faites du refactoring, alors ?
- Non plus.
- ... De l'intégration continue ?
- Non.
- ... Alors quoi ???
- On ne fait pas de documentation.

Formation Scrum Master à La Défense

J'ai eu l'occasion la semaine dernière, précisément les mardi 25 et mercredi 26 mars, de suivre une formation « Scrum Master » donnée par Jeff Sutherland en partenariat avec Xebia France, à Paris-La Défense.

Pour ceux qui ne connaissent pas Scrum, je dirais qu'il s'agit d'une boîte à outils méthodologiques pour mener des projets à bien.

Basiquement, ces projets sont :

• avec des objectifs « démontrables » : par exemple, un site web, un rapport rédigé, un gâteau...
• suivis de près par un « directeur de produit » (Product Owner)
  
• à équipe réduite : entre 5 et 9 personnes, avec une préférence pour des équipes de 5
  
• menés de façon itérative : à la fin de chaque itération, une version du produit est garantie testée, et est démontrable entre autres au directeur de produit ; cela assure que le feedback est reçu à intervalles rapprochés et réguliers, et qu'on vérifie que la trajectoire prise par l'équipe n'est pas déconnante
  
• menés sur des itérations courtes : de 2 à 5 semaines, avec souvent une préférence pour des itérations de 2 semaines (je n'en reviens toujours pas, car cela me semble bien court, mais plusieurs participants m'ont assuré travailler ainsi)
  

Une des grandes devises de Scrum est « inspect & adapt », c'est-à-dire qu'un projet mené avec Scrum améliore lui-même sa méthode de travail tout du long.

Scrum est une méthodologie « agile », au même titre que XP pour le processus de développement logiciel.

Pour de plus amples renseignements, je vous conseille le blog de Claude Aubry, et le livre Agile Project Management with Scrum, de Ken Schwaber (Ken Schwaber est le co-inventeur, avec Jeff Sutherland, de Scrum).

J'avais eu l'occasion de m'intéresser à Scrum par l'intermédiaire de lectures sur le web, et d'expérimenter avec enthousiasme deux ou trois principes portés par ce framework. Suivre la formation à Paris m'a permis d'équilibrer mes connaissances théoriques, et évidemment de rencontrer d'autres personnes impliquées dans Scrum.

Ce furent deux jours passionnants.

D'abord, Jeff Sutherland, l'homme. Il est à la fois brillant et précis dans son discours, très intelligent dans sa façon d'appréhender les choses, humble et... marrant. Je dirais qu'il apparaît que Scrum s'inscrit pour lui dans une démarche plus globale. Il a évoqué le bouddhisme zen par exemple.

Ensuite, Scrum. En anglais, « scrum » signifie « mêlée » : celle du rugby. À entendre Jeff Sutherland, il s'agit bien et prioritairement de permettre à une équipe d'être la plus efficace possible pour atteindre un objectif commun. Pour cela, il faut (et il suffit ?) de clarifier par tous les moyens (discussions, démonstrations suivies de feedbacks, échanges avec le client) l'objectif à atteindre, et de libérer l'équipe de tout ce qui pourrait gêner sa tâche.

À ce titre, la méthode invoque un rôle particulier dans l'équipe, celui du « Scrum Master » (c'était l'objet de la formation, vous suivez). Je dirais que celui-ci est principalement là pour régler les impediments, c'est-à-dire les obstacles que rencontre l'équipe, et pour favoriser les échanges et le feedback continuels, en organisant notamment, et en cadrant, des réunions quotidiennes d'environ un quart d'heure (daily scrums).

Les impediments peuvent être de divers ordres : matériels, logiciels, environnementaux, voire budgétaires, mais aussi humains, politiques, ou managériaux. Le Scrum Master est concentré sur le travail que doit fournir l'équipe, pas sur la hiérarchie dans l'organisation.

Quand on se pose la question de cette façon simple, il n'y a pas grand-chose à penser :

• Le Scrum Master met de l'huile dans les rouages (daily scrums et tenue à jour des backlogs),
• et balaie les grains de sable de l'engrenage.
• L'équipe prend à sa charge la réalisation du produit,
• produit dont le Product Owner maintient une vision claire et compréhensible (accessible).

L'image qui me venait est celle d'une piste de bobsleigh : si la piste est constamment dégagée, l'équipe la descendra d'abord à pied (on n'est jamais trop prudent), puis en se laissant glisser individuellement (confiance), puis... en bobsleigh (confiance + équipe).

Les études menées sur l'utilisation de Scrum montrent paraît-il qu'une équipe de développeurs moyens est toujours meilleure à terme que des bons ou des très bons développeurs qui travaillent séparément. Cette émergence qui naît au sein d'une équipe est captée dans le « ba », terme japonais.

Le fait d'avoir son esprit vacant (no impediment) et concentré sur l'activité s'appelle le « kaizen ».

L'objectif de Scrum est de permettre au « ba » de s'exprimer dans une équipe composée de personnes en état de « kaizen » ;-)

Pour en revenir à la formation, nous étions 30 stagiaires. La formation et le support étaient en anglais, avec l'aide de Guillaume Bodet, directeur technique de Xebia France, présent pendant ces deux jours, dans le cas où des termes auraient nécessité une traduction (cela n'a finalement pas été le cas).

Deux exercices m'ont particulièrement intéressé :

• la réflexion en équipe et la rédaction collaborative d'une réponse à un problème donné, en trois itérations de 8 minutes, chacune précédée de 4 minutes de daily scrum. Je jouais le Scrum Master, et me bornais donc à organiser les daily scrums et à régler les problèmes de l'équipe. J'ai trouvé que le résultat, c'est-à-dire le document rédigé, malgré le caractère parfois désordonné du travail, et la vitesse demandée, était de bien meilleure facture que ce qu'on aurait pu composer chacun de son côté, ou de ce qu'on aurait pu organiser linéairement sans itérations. Pour la démo, l'équipe m'a demandé de présenter le document ! alors que je n'avais pas participé à sa matière. C'est le rôle du Scrum Master, si j'ai bien compris : être au service de l'équipe...
  
• un exercice de planification en fonction de la « valeur métier » des composants d'un produit à réaliser. Notre équipe n'a pas terminé l'exercice (!!!) car nous passions trop de temps en planification. La qualité de réalisation était évidemment très bonne (vu la planification), mais le projet a été planté, vu que nous n'avancions pas à un rythme suffisant. Cet exercice m'a montré l'importance primordiale du Product Owner, qui doit être clair dans ses demandes et exigeant quant au résultat, et celle, finalement secondaire, du cadrage apporté par le Scrum Master.

Quelques questions font débat :

• Scrum Master, n'est-ce pas simplement un rôle chef de projet ? Voire un sous-rôle de chef de projet ? Pour ma part je pense que le Scrum Master a notamment comme fonction de balayer les obstacles et de cadrer l'énergie collective, pas de se mettre en avant par rapport à l'équipe (d'ailleurs par moments ça gêne, si on se met en avant). Par ailleurs ce n'est en aucun cas un positionnement hiérarchique : les tâches ne sont pas affectées par le Scrum Master. Donc à chacun de se faire son idée.
• Le client final a-t-il plutôt besoin de bons Scrum Masters, ou de bons Product Owners ? La réponse de Jeff Sutherland est fortement et sans hésiter : de bons Product Owners. La vision du produit doit être portée, avec en permanence la visée de la maximisation de la valeur métier. C'est le Product Owner qui fixe les priorités de chaque itération et qui, en fonction des réalisations de l'équipe (et de la vélocité, dont je n'ai pas parlé dans ce post), gère les dates de livraison.
  

Au final, je vais appliquer Scrum sur tous mes projets. Outre le contact avec le Scrum Trainer, la formation Scrum Master permet de faire le tri dans les bases théoriques sur Scrum, largement disponibles sur le web ou dans la littérature, et de les confronter à la réalité à l'aide de quelques exercices pratiques.

Je ne peux que conseiller cette formation.

Google for Non Profits : plate-forme Les Fûts ?

C|net: Google launches tool portal for nonprofits.

Google communique sur sa palanquée d'outils auprès des organisations à buts non lucratifs :

• Gmail
• Checkout
• Docs
• Calendar
• Analytics
• Google Grants
• YouTube
• Blogger
• Maps&Earth
• Gadgets
• Groups
  

Il manque le wiki, je suis surpris.

Reste qu'avec les outils Google, et si on n'en sort pas, le concept d'identification numérique partagée d'association à association, concept qui est au cœur des Fûts (une personne qui fait partie d'une association appartient souvent à d'autres groupes), est fourni de base.

MindManager gratuit pour les blogueurs

Vu chez Cmicblog : MindManager gratuit pour les blogueurs

J'ai demandé ma clef, qu'on m'a fort gentiment envoyée. Puis j'ai installé cette application paraît-il surpuissante de mind mapping. On verra bien. En tout cas pour s'y mettre, d'après les habitués de la pratique, il faut prendre « au moins » MindManager.

YAML est au-dessus de XML

Développeur Java.

Des montagnes de fichiers XML pour la configuration, pour les tests, pour la sérialisation de données, parfois même pour les logs.

Une envie de penser plus vite.

Solution : adoption radicale de YAML.

Un exemple

Pour mes tests je joue beaucoup avec des descriptions de données au format XML. Ainsi, je peux manipuler des valeurs de référence (pour les tests) sous la forme suivante :

currentUser.xml :

<DataBean name="currentUser"
 class="com.avcompris.model.User" scope="request">
<properties>
 <property name="firstName"
    class="java.lang.String">Dominique</property>
 <property name="lastName"
    class="java.lang.String">Vandrault</property>
 <property name="birthDate"
    class="org.joda.time.DateTime">1978-01-06</property>
</properties>
</DataBean>

Première discussion. On m'objectera qu'il vaudrait mieux avoir deux fichiers XML, un pour la description de la structure et un pour les valeurs. Cela donnerait éventuellement :

User.xml :

<DataBeanClass
 class="com.avcompris.model.User" alias="User">
<properties>
 <property name="firstName"
    class="java.lang.String"/>
 <property name="lastName"
    class="java.lang.String"/>
 <property name="birthDate"
    class="org.joda.time.DateTime"/>
</properties>
</DataBeanClass>

currentUser.xml :

<User name="currentUser" scope="request">
<firstName>Dominique</firstName>
<lastName>Vandrault</lastName>
<birthDate>1978-01-06</birthDate>
</User>

C'est un premier choix à faire. L'idée n'étant pas de faire de l'architecture mais bien de pisser du test, je n'ai aucune envie de me retrouver avec des fichiers de description dans tous les sens, qui deviendront impossibles à maintenir au bout de 30 refactorings. Pourquoi pas écrire des XML Schemas dès maintenant, aussi ?

Pour mes procédures de tests je conserve donc le principe du fichier unique, avec méta-données côte-à-côte avec les données.

Mon fichier de départ est bien le suivant :

currentUser1.xml :

<DataBean name="currentUser"
 class="com.avcompris.model.User" scope="request">
<properties>
 <property name="firstName"
    class="java.lang.String">Dominique</property>
 <property name="lastName"
    class="java.lang.String">Vandrault</property>
 <property name="birthDate"
    class="org.joda.time.DateTime">1978-01-06</property>
</properties>
</DataBean>

Première idée, accepter les valeurs par défaut. Convention over configuration. Ainsi, je pourrais décider par convention que quand l'attribut @class est absent, la propriété est forcément de type java.lang.String. Et puis supprimons le tag <properties> qui ne sert à rien (il serait très utile si je souhaitais écrire un XML Schema validant mon XML, mais... ce n'est pas le cas pour le moment). Voyons ce que ça donne :

currentUser2.xml :

<DataBean name="currentUser"
 class="com.avcompris.model.User" scope="request">
 <property name="firstName">Dominique</property>
 <property name="lastName">Vandrault</property>
 <property name="birthDate"
    class="org.joda.time.DateTime">1978-01-06</property>
</DataBean>

Ah, mieux. Beaucoup mieux !

Deuxième idée, passer à des éléments qui ont le nom de la propriété. On élimine donc, par convention, l'attribut @name (et parallèlement, on s'éloigne de plus en plus de la possibilité d'écrire un XML Schema validant non trivial).

currentUser3.xml :

<currentUser
 class="com.avcompris.model.User" scope="request">
 <firstName>Dominique</firstName>
 <lastName>Vandrault</lastName>
 <birthDate
    class="org.joda.time.DateTime">1978-01-06</birthDate>
</currentUser>

Ça avance. Je ne me pose pas la question des sous-DataBeans, car je sens que ça me ferait reculer dans ma joie simplificatrice.

Continuons. Passons maintenant en tant qu'attributs de leur parent les éléments uniques qui n'ont pas d'attributs.

currentUser4.xml :

<currentUser
 class="com.avcompris.model.User"
 scope="request"
 firstName="Dominique"
 lastName="Vandrault">
 <birthDate
      class="org.joda.time.DateTime">1978-01-06</birthDate>
</currentUser>

OK. C'est un peu mélangé, ce n'est pas uniforme, mais j'y gagne.

Chouette.

...

Allez, j'arrête le cinéma. Ce XML est immonde, il n'est pas évolutif, il n'est pas validable, et il est moche. Moche comme du... XML.

Dites-moi que vous n'y avez pas cru...

L'approche YAML

YAML est un format de données qui est abondamment utilisé dans le monde de Ruby on Rails.

Quand je choisis YAML pour décrire mes données, je ne me dis pas « comment être sûr que je pourrai écrire un XML Schema validant plus tard », mais « comment ai-je envie d'écrire mes données ».

Le parsing, les transformations et la validation viendront bien plus tard. En fait, le plus souvent en passant par une étape XML intermédiaire.

En premier lieu je me contente d'une utilisation ad hoc du format.

Ainsi, mon fichier currentUser4.xml deviendrait :

currentUser4.yaml :

currentUser:
 class: com.avcompris.model.User
 scope: request
 value:
   firstName: Dominique
   lastName: Vandrault
   birthDate:
     class: org.joda.time.DateTime
     value: 1978-01-06

Beaucoup mieux que l'équivalent XML.

Mais on peut aller plus loin :

currentUser5.yaml :

currentUser:
 com.avcompris.model.User:
   firstName: Dominique
   lastName: Vandrault
   birthDate:
       org.joda.time.DateTime: 1978-01-06

(En passant, je supprime l'attribut @scope, en décidant qu'il vaut "request" par défaut. J'aurais aussi pu le faire dans le cas du XML).

Voici les « équivalents » YAML des autres fichiers XML :

currentUser3.yaml :

currentUser:
 class: com.avcompris.model.User
 scope: request
 value:
  firstName: Dominique
  lastName: Vandrault
  birthDate:
     class: org.joda.time.DateTime
     value: 1978-01-06

currentUser2.yaml :

- DataBean:
   name: currentUser
   class: com.avcompris.model.User
   scope: request
   properties:
    - name: firstName
      value: Dominique
    - name: lastName
      value: Vandrault
    - name: birthDate
      class: org.joda.time.DateTime
      value: 1978-01-06

currentUser1.yaml :

- DataBean:
    name: currentUser
    class: com.avcompris.model.User
    scope: request
    properties:
     - name: firstName
       class: java.lang.String
       value: Dominique
     - name: lastName
       class: java.lang.String
       value: Vandrault
     - name: birthDate
       class: org.joda.time.DateTime
       value: 1978-01-06

Ou le « degré zéro » de YAML :

currentUser0.yaml :

- DataBean:
    name: currentUser
    class: com.avcompris.model.User
    scope: request
    properties:
     - property:
           name: firstName
           class: java.lang.String
           value: Dominique
     - property:
           name: lastName
           class: java.lang.String
           value: Vandrault
     - property:
           name: birthDate
           class: org.joda.time.DateTime
           value: 1978-01-06

« currentUser5.yaml », propre, intelligent, lisible, fait 6 lignes.

Le dernier fichier, « currentUser0.yaml », d'une structure digne d'un fichier XML validable, pour ne pas dire d'une base de données relationnelles, en fait 17. Quasiment 3 fois plus.

YAML :

• ne demande pas d'indiquer les fins d'éléments (ouf !), car il se base sur l'indentation
• n'a pas de notion de sous-élément ou d'attribut : on se débrouille avec l'arborescence. Disons qu'il y a bien la notion de maps et de lists, qui correspondraient à peu près aux attributs (noms uniques) et aux sous-éléments (noms éventuellement répétés), mais les maps peuvent avoir des sous-arborescences, contrairement aux attributs du XML.
• est... lisible.
• il n'y a pas de guillemets dans tous les sens
• l'indentation fait partie de la syntaxe
  

YAML n'a rien à voir avec JSON. Je dirais grosso modo que YAML est orienté lisibilité des fichiers par des humains, tandis que JSON est orienté transfert de données entre machines. Mais surtout, JSON est fortement similaire à XML, tandis que YAML a une autre logique.

La place de YAML dans le processus de développement

J'utilise YAML pour les données de tests, la configuration, et les fichiers sources de génération.

Comme les composants côté serveur ou côté plugins savent surtout ingérer du XML, j'opère toujours une première phase de sérialisation de YAML vers un XML « neutre » équivalent.



La bibliothèque Java que j'utilise pour le parsing de YAML est JvYAML.

Voir aussi la bibliothèque JYaml.

La page de Wikipedia sur YAML : YAML.

Pour une check-list de productivité

À mon sens, la productivité et l’efficacité sont avant tout une affaire de détermination.

1. De déterminations extérieures :
   1.1. L’environnement doit faciliter l’activité
   1.2. L’environnement ne doit pas gêner l’activité
   
   
2. De déterminations propres :
   2.1. Il faut avoir envie de bosser
   2.2. Il faut que ce soit le bon moment
   2.3. Il faut savoir ce qu’il y a à faire
   2.4. Il faut être « motivé » par le feedback qu’on reçoit
   

Je vais décliner chacun des points pour mon cas personnel, en ne parlant que de ce qui concerne le développement J2EE / web.

1.1. Un environnement qui facilite l’activité

Par environnement, entendons au sens large tout ce qui m’entoure, avec qui je bosse, avec quels outils, et où je suis installé.

Le meilleur type d’endroit dans lequel j’ai pu faire du développement a été :

• un bureau dédié qui ne soit pas partagé avec des collègues,
• disposant d’une grande fenêtre — en fait une baie vitrée sur deux niveaux donnant sur l’Océan Atlantique,
• travaillant avec une équipe de « smart guys », jeunes ou moins jeunes,
• dans des locaux donnant accès à une bibliothèque interne, à une salle de repos, à des lieux informels de relaxation et de discussion (poufs bienvenus),
• donnant accès à un tableau partagé où chacun peut noter ses idées,
• avec une connexion internet haut débit (si, si, il faut le préciser),
  
• et un réseau local performant (ou une solution « on the cloud ») pour le partage occasionnel de fichiers — la grande majorité des échanges se faisant par le SCM.

Toujours à titre personnel, le meilleur poste de travail comprenait :

• un fauteuil de qualité (Markus, anyone?),
• une immense table (enfin, à l’époque elle me paraissait immense…),
• deux machines puissantes avec écran et clavier, dont une avec un ecran plat 20’’,
• pour le choix des systèmes d’exploitation, dans l’ordre : MacOS X, Windows 2000, Windows XP, Ubuntu,
• et un téléphone fixe avec haut-parleur, avec accès au national et à l’international.
  

On peut aussi faire son marché dans la liste de Calacanis : How to save money running a startup (17 really good tips)

Divers outils en coulisses qu’on ne présente plus :

• un SCM propre, comme Subversion,
• un wiki propre, comme Confluence,
• une plate-forme de blogging interne (en général, la même plate-forme offre le wiki et le blogging ; c’est le cas de Confluence),
• un bug tracker propre, comme Jira,
• une solution interne de messagerie instantanée, comme Jabber,
• et une plate-forme d’intégration continue propre, comme Continuum.
  

Parmis les outils logiciels, toujours pour ma partie, citons les plus importants :

• Java 5 ou ultérieur,
• Maven 2
• un IDE, comme Eclipse 3.3.2
• une panoplie de navigateurs web, dont Firefox 2.0.0, Mozilla et Opera
• un éditeur de textes, comme TextWrangler, Crimson Editor ou UltraEdit
• YAML, XML, XSLT
  

De plus, il est important de savoir investir dans des outils maison. Un bon outil maison est un outil qui n’est pas indispensable techniquement (surtout pas d’adhérence à la technologie !) et qui fait gagner des jours de charge.
Les contre-exemples bien connus sont :

• les framework maisons monolithiques auxquels le legacy est fortement couplé
• les outils maisons difficiles d’utilisation : mal documentés, qui gèrent mal les erreurs, pas ergonomiques, etc.

Le summum étant je pense les outils développeés en interne qui se révèlent moins bons que les solutions gratuites strictement équivalentes.
Attention, ce genre d’initiative freine la productivité non seulement en terme d’outillage pur, mais également en minant la motivation des équipes, car l’image de la boîte renvoyée en interne n’est pas bonne.

Je cite mes outils maison préférés jusqu’ici :

• plugins Maven de génération de code
• outil de rendu dynamique de JSP/JSF sans déploiement (et ne me parlez pas de Tomcat dans Eclipse, ou de JBoss qui redéploie en autonome)
• plugins Maven de tests de design web
  

Et la décoration du bureau ? Et la musique ? Et le Feng Shui ? À creuser…

1.2. Un environnement qui ne gêne pas l’activité

Il faut laisser la place aux bons points qu’on a vus précédemment d’être utiles.

Ainsi, on évitera, et je parle là de seuils d’acceptabilité :

• le bureau où on est 5 dans lequel parle à voix haute (je rappelle que je parle de développement. De tels bureaux peuvent être utiles pour d’autres choses),
  
• les open spaces,
• le bureau sans lumière extérieure,
• l’équipe de neuneus (oui, je sais, on est toujours le neuneu de quelqu’un),
• la société qui n’affiche pas un intérêt évident à investir dans des livres, dans des serveurs ou dans des formations,
• l’absence ou la restriction d’accès à internet,
• le poste de travail sous-dimensionné,
• la société où l’on ne peut pas capitaliser la connaissance dans une base ouverte, partagée, pratique d’utilisation et indexée,
• la société où l’on ne communique pas librement (oui, je sais, c’est le Moyen Âge, mais ça existe encore),
• les projets techniques sans phase d’investissement dans l’outillage technique : il faut savoir gérer les effets de seuil.
• les projets Java en-deçà de Java 5
  

En termes d’outils, je ne peux que souscrire à la liste de Pierre-Olivier Carles : 10 conseils pour conjuguer Innovations, Internet & Efficacité, en retenant pour ma part :

• Bloquer les e-mails entre 8 h 00 et 14 h 00
• Trier ses flux RSS
• Bloquer Skype et Twitter (très difficile) sur certaines plages temporelles
  

Souffrant d’électro-hyper-sensibilité (EHS), l’absence de téléphone portable et de Wi-Fi est cruciale pour moi si je veux pouvoir réfléchir normalement. Cela me restreint d’emblée l’accès à un bon nombre de locaux, mais ce type de discernement est tout le sujet de ce post.

Et la décoration du bureau ? Et la musique ? Et le Feng Shui ? À creuser également…

2.1. Avoir envie de bosser

Bah, ce n’est pas compliqué : il faut et il suffit d’être convaincu du résultat.

2.2. Le bon moment

Entre quatre heures et huit heures du matin, je suis en général trois fois plus rapide et efficace qu’après neuf heures du soir…

À huit heures, c’est le journal…

À midi, la faim se fait sentir, donc je réfléchis mieux…

Après le repas, sans sieste je passe trois heures à ne pas démarrer…

À 18 h 00, ça stagne… Pour baisser en général vers 19 h 00…

À environnement idéal (en dormant au boulot, donc !), je pourrais donner la courbe de productivité suivante :



Noter que je passe sur les problématiques de fatigue installée, de stress, etc. Tout ce qui constitue la moitié basse de la Pyramide de Maslow doit évidemment être réglé.

Cela étant dit, dans une journée la productivité n’est pas constante. Il faut connaître et utiliser les bons moments.

• Il est inefficace de travailler quand le moment « n’y est pas »
• Il est inefficace de ne pas travailler quand c’est le moment

Pour un article radical sur le bon emploi de son temps, et qui va bien plus loin que le bête sujet de la productivité, lire chez Paul Graham : Good and Bad Procrastination.

2.3. Savoir ce qu’il y a à faire

La concentration (notions de focus et de flow) est indissociable de la productivité.

À ce titre, il est crucial que la TODO-List, la liste des tâches à faire (par extension, l’ensemble des backlogs de Scrum par exemple) soit claire et affichée. Utiliser un outil informatique ou un cahier ne suffit pas. Pour les tâches du quotidien, un affichage mural est bien plus efficace.

2.4. Être « motivé » par le feedback qu’on reçoit

C’est un point important dans l’efficacité.

D’abord, comment savoir qu’on maintient le cap ? Qu’on a le sens des priorités ? On peut en effet être très concentré, très « productif » sur des menus détails, et laisser tomber des pans de l’activité. Pour cela, la TODO-List, ou les fameux backlogs de la méthode Scrum sont utiles.

En parlant de Scrum, les dailys scrums, lors desquelles toute l’équipe se réunit debout une demi-heure pour présenter les choses faites, le reste à faire et les problèmes rencontrés, représentent un gain redoutable tant pour la productivité individuelle que collective (notion de gel). La productivité en équipe n’est cependant pas le sujet de cet article.

Ensuite, il faut savoir juger ce qu’on produit. C’est aussi une façon de maintenir le cap. Et c’est encore une question de priorités : savoir identifier ce qui est important dans le produit réalisé, afin de se concentrer dessus.
Il s’agit d’un ensemble d’indicateurs, dont aucun n’est à négliger. Ils devraient même à mon sens avoir le même coefficient, avec seuils planchers éliminatoires :

• Les feedbacks des utilisateurs (organiser des démonstrations)
• Les feedbacks des « pairs » (peer reviews) (idem, et rédiger des bilans)
• La qualité interne du produit (audits automatisés réguliers)
  

Ces différents feedbacks, backlogs et indicateurs, sont bien des moteurs de « motivation », au sens où sans eux il est très facile de rester enkysté dans un axe de développement donné. Même s’il produit du code, et semble rassurant par certains aspects, cet immobilisme est forcément nocif, et au niveau de la productivité sera à terme destructeur. La remise en question, donc l’écoute des avis extérieurs, est un élément indirect mais fondamental de la motivation.

Enfin, il y a un feedback capital dans la productivité, c’est celui qu’on apporte soi-même. Passer du temps à bloguer en interne ce qu’on a fait dans la journée, à formaliser telle procédure, tel outil, telles spécifications même incomplètes… Bloguer ses pratiques, bloguer ses configurations, alimenter les bug trackers et les backlogs… On en retire :

• une capitalisation du savoir (non ? Sans blague ?),
• une pratique de la formalisation
• une réflexion en tâche de fond, et une habitude de communiquer,
• un recueil incrémental des problèmes et des solutions
  

Passons rapidement sur l’aspect évidemment pratique de faire vivre une telle base de connaissance.

En terme de productivité de développement, c’est utile car on y gagne en recul, donc d’acuité, donc de pertinence… donc de productivité.

On a vu l’importance de la concentration (focus) : il faut donc éviter le trop-plein de feedbacks qui mènent à la distraction voire à la dispersion. C’est tout l’objet de ce point : à mon avis le feedback doit être motivant, bien qu’il soit parfois laudateur ou critique. Motivant, c’est-à-dire qu’on ne doit pas le chercher pour lui-même mais pour l’effet qu’il aura sur l’activité.

C’est aussi pour cela que je parle de « détermination propre » au lieu de « détermination extérieure » pour le feedback : ce qui compte pour la productivité c’est ce que j’en fais moi.

Bonus : 3. Ce qui n’apporte rien

Grande question : que fait-on des outils suivants ? Sont-ils des facilitations de productivité pour le développement ?

• Twitter
• Blogs publics (via des flux RSS)
• Comptes publics de messagerie instantanée (Skype…)
• Facebook (que je ne connais pas assez)
• E-mail
  

À mon sens, ces outils, dont j’aurais bien du mal à me passer, notamment Twitter avec twhirl, maintiennent un certain éveil, une certaine acuité. Ils nous permettent d’apporter, de recevoir, de nous ouvrir, ils participent de la confiance et de l’estime.

Seulement, en terme de pure productivité, l’élément important est l’acuité. Ainsi, se concentrer quatre heures sur un bouquin ou une doc en ayant éteint tous ces outils, sera plus profitable à un moment donné que fureter sur le même sujet sur internet. Il ne faut pas gérer sa productivité uniformément, mais selon les caps à franchir.

Conclusion

La productivité s’appuie sur un environnement, des outils et des pratiques, et est liée par feedback à la motivation (feedback dans les deux sens). Elle peut être favorisée ou handicapée par la nature de ces différents éléments. Les éléments en gras ci-dessus constituent une check-list empirique d’éléments à prendre en considération.

La productivité se jauge continuellement. Outre la quantité de travail abattue, un signe de bonne productivité et d’efficacité est l’agilité.

Encore une fois, tout cela vaut comme mon avis personnel. Si vous avez des réflexions ou des pointeurs sur le même sujet, je serai heureux d’en discuter.

Simplicité, deuxième

Que voit-on à l'entrée de votre entreprise ?





À ma gauche, 1, Infinite Loop (Apple). À ma droite...

Je trouve ça excellent.

Via Sanji.

Blog sur Garonne, 4 mars 2008

Bon ben oui, j'y étais, à l'édition de mardi dernier de Blog sur Garonne.

C'était évidemment à Toulouse, au « Sur Mesure », anciennement appelé le « Chez Nous ».

On était quoi ? 20 ? 25 ? Dans le petit espace, c'était assez chaleureux. L'ambiance était cool et... jeune.

Allez, un peu de name dropping...

J'y ai discuté avec plusieurs personnes, mais pas tous les présents ! On a pas mal parlé avec Xavier, qui semble très actif sur tel blog politique (UMP). Adresse = ?. J'ai pu revoir avec plaisir Maxime Garrigues (rencontré au Déjeuner sur web 2.0) qui comme d'hab' déchire. Cédric Giorgi. Benoît Ramus, de NetOcéan, m'a parlé des deux versions de sa boutique Boatiful, version e-commerce et version vraie boutique toulousaine. J'ai trouvé la démarche logique et excellente. Bien, de voir des projets qui grandissent. Guillaume Beuvelot (PME Performance), était là aussi... Ah, et je n'ai fait que croiser Pierre-Olivier Carles, de FoolInvest.

Cette soirée était vraiment sympa. Les gars ont un très bon état d'esprit. Conquérant, positif, beaucoup d'écoute. On sent très bien le côté « ce que tu m'apprends m'enrichis ». Et le respect. La pratique des blogs est civilisatrice, par définition.

Côté réseautage, je pense que sans téléphone portable / iPhone / Wi-Fi / MacBook Air en poche, je vais encore avoir à échanger quelques cartes de visite papier. C'est d'ailleurs parfois ce qui convient le mieux, car dans l'histoire de la relation ça fait un point d'entrée fixe pour se retrouver, contrairement au nuage de blogs / recherches Google / profils Ziki / MyBlogLog / CopainsDavant / groupes Facebook, etc.

C'est marrant, après ce genre de rencontres on va davantage faire du Follow sur Twitter, éventuellement du lien sur FaceBook (pas mon truc cependant), que faire des mises en relation Viadeo ou LinkedIn. Et suivre directement les liens RSS avec un agrégateur ? It's so 2004... Pour le suivi live de la présence numérique au sein de cette génération, Twitter gagne haut la main. Enfin, disons que c'est vrai pour 2008 Q1 ;-)

SigmaT 5 : Scrum et méthodes agiles à Toulouse

Vendredi 28 mars 2008 prochain aura lieu le 5e séminaire « SigmaT ». Il s'agit d'une rencontre sur Toulouse d'acteurs des méthodologies agiles, comme Scrum ou XP. Cette session se focalisera sur les retours d'expérience.

Cela se déroule à l'Université Paul Sabatier, et ça commence à 16 h 00.

Voir des détails ici :

• sur le blog de Claude Aubry
• sur le blog de Thierry Cros
• présentation sur le blog de Claude Aubry
  

J'avais assisté au SigmaT 4 le 14 décembre dernier, dont le thème était « le feedback ». C'était décontracté et assez intéressant, notamment le retour d'expérience d'une équipe des laboratoire Pierre Fabre sur la mise en place d'une méthodologie « agile », c'est-à-dire itérative, avec des contacts appuyés avec la MOA, et une acceptation d'entrée de jeu que le scope fonctionnel sera susceptible d'évoluer en cours de projet.