Comme l’explique Daniel Pink dans son excellent livre La vérité sur ce qui nous motive, ce qui fait que nous sommes impliqués dans notre entreprise, dans notre travail, ne dépend pas principalement de récompenses financières.

D’après lui, les trois véritables facteurs qui ont un réel impact sur la motivation sont :

• L’autonomie
  

  Notre « paramétrage par défaut », c’est l’autonomie et l’indépendance. Malheureusement, les circonstances -entre autres des notions périmées de management- concourent souvent à changer ce paramétrage et à faire baisser notre motivation intrinsèque. Pour favoriser la motivation intrinsèque et les bonnes performances qu’elle permet de réaliser, la première condition est l’autonomie. Les entreprises qui permettent à leurs salariés d’être autonomes, parfois de façon radicale, sont plus performantes que leurs concurrents.

• La maîtrise
  

  La maîtrise obéit à trois règles particulières :

  • C’est un état d’esprit : elle requiert la capacité d’envisager ses propres possibilités comme étant non pas finies mais infiniment améliorables.
  • La maîtrise suppose des efforts, des difficultés et une pratique délibérée.
  • La maîtrise est impossible à atteindre entièrement, si bien qu’elle comporte à la fois un coté frustrant et un côté attirant.

   

• La finalité
  

  Il est dans la nature humaine de rechercher la finalité, c’est-à-dire de trouver un sens à ce que l’on fait, un but qui dépasse notre propre condition. Or les entreprises ont longtemps considéré la finalité comme accessoire, comme un élément souhaitable tant qu’il n’interfère pas avec les choses importantes. Cette situation est en train de changer, en partie grâce au vieillissement des baby-boomers qui se retrouvent confrontés à leur condition de mortel. Dans les organisations, ce nouveau « motif de finalité » s’exprime de trois manières : sous forme d’objectifs de finalité dans lesquels le profit est un moyen, sous forme d’un discours qui met l’accent sur autre chose que l’intérêt personnel, et sous forme de mesures pour permettre aux salariés de trouver par eux-mêmes du sens à ce qu’ils font.

Inspiré par la lecture de ce livre, je vous propose d’adapter l’activité classique de rétrospective, XP Radar, au thème de la motivation.

Lire la suite de cet article »

Le French Scrum User Group organise une belle journée de partage sur l’agilité le 31 mars prochain au Centre de Conférences de Microsoft à Issy-les-Moulineaux. La journée promet d’être enrichissante avec la présence de Harvey Wheaton, Ken Schwaber et 20 conférences tenues dans 5 salles en parallèles (voir le programme).
Je serai également présent et j’aurai la chance de vous présenter le sujet : Pratiques avancées de tests. J’y aborderai les meilleures pratiques de tests unitaires en Java. Cette présentation permettra d’identifier certains code-smell spécifiques aux tests et de mettre en œuvre des techniques de refactoring. Ce sera également l’occasion de découvrir les possibilités d’outils de tests (notamment Junit, Mockito, Fest, Spock) afin de créer des tests extrêmement lisibles et maintenables.

Il reste quelques places disponibles sur le site du scrumday, dépêchez-vous si vous n’êtes pas encore inscrit.

En ce beau matin d’hiver, me voilà bien décidé à effectuer un peu de ménage sur notre projet. Ma cible d’aujourd’hui : la chasse aux warnings.

Grosso modo, j’observe qu’il y a 3 types de warning :

• imports inutilisés (60%)
• unchecked casts (30%)
• variables ou méthodes private non utilisées (10%)

Je prends mon bâton de pèlerin et je nettoie. Cependant, je me rends bien compte que ces warnings sont pour la majorité des erreurs d’inattention qui pourraient être facilement évitées.

A quoi bon nettoyer, si c’est pour se retrouver dans la même situation dans trois mois ? Donc, en plus de ma maintenance corrective, je pars également à la recherche d’une action préventive.

Première idée évidente, configurer Eclipse pour que celui-ci effectue ce genre de nettoyage lors d’une sauvegarde d’un fichier. Facile, il suffit de paramétrer ceci dans Properties -> Java Editor -> Save Actions (Plus de détails ici).

Cependant, à quoi bon le faire uniquement sur mon Eclipse ? Quel intérêt, si les autres membres de l’équipe ne bénéficient pas eux aussi de la même configuration ? Comment faire en sorte que ma configuration soit facilement partagée avec les autres ?

Le projet étant un projet maven, le maven-eclipse-plugin semble offrir la solution.

Lire la suite de cet article »

Adepte de longue date de Fitnesse, j’ai toujours aimé l’aspect collaboratif du wiki permettant de sortir les tests du code et de les exposer à d’autres populations moins technique. Cependant, malgré le succès du projet et la grande communauté qui l’entoure, Fitnesse reste compliqué à mettre en place et certaines fonctionnalités de bases font cruellement défaut. De plus, le passage de Fit à Slim a fortement contribué à complexifier le projet.
Pour moi, Fitnesse est un projet passionnant et porteur de nombreuses innovations. Cependant, l’absence de structuration et le manque de documentation le rend très difficile à mettre en oeuvre et demande une réelle expérience. Je vous conseille tout de même de garder un oeil sur celui-ci, car, depuis l’année dernière, le projet est redevenu très dynamique (pas moins de sept releases) et semble gagner en maturité (je vous conseille notamment cet article sur les nouveautés).

J’ai plusieurs fois dans le passé eu l’occasion de voir des présentations de GreenPepper par les équipes de Pyxis. GreenPepper partage le même concept que Fit/Fitnesse mais a fait le choix de s’appuyer sur un Wiki existant robuste et mature : Confluence. Ce choix est un des gros atouts de GreenPepper, mais c’est aussi la raison qui m’a toujours fait écarter cette alternative. En effet, j’ai toujours trouvé difficile de promouvoir un logiciel en expliquant qu’il faudrait non pas acheter une mais deux licences (pour les entreprises non équipées en Confluence) et qu’il faudrait configurer et maintenir les deux logiciels.

Cependant, ce point de blocage a été adressé lors de la version 2.6 sortie en novembre 2009, qui permet désormais de pouvoir faire reposer GreenPepper sur XWiki qui est gratuit et open source.

Je vous propose donc de m’accompagner dans le test de cette nouvelle version au travers de cet article qui aborde :

• l’installation de GreenPepper et la configuration de XWiki,
• la création des premiers tests,
• la configuration de Maven et Eclipse pour GreenPepper,
• la création des fixtures,
• un petit retour d’expérience,
• mes espoirs pour le futur.

Avant de vous lancer dans la lecture de cet article, notez que celui-ci est purement technique et nullement philosophique. La présentation de l’ATDD (Acceptance Test Driven Development) ne sera pas abordée ici.

Lire la suite de cet article »

Une question récurrente pour les équipes qui commencent à industrialiser leur build avec du Maven et qui utilisent de manière intensive JUnit. Au bout d’un moment, les tests d’intégrations ralentissent de manière conséquente le build et parfois découragent les développeurs à cause de leurs pré-requis plus importants que les tests unitaires.
Comment les séparer des tests unitaires et comment éviter qu’ils soient lancés à chaque build Maven?

Lire la suite de cet article »