Maîtriser son environnement de développement, le premier pas vers une plus grande productivité

J'ai eu l'occasion en l'espace d'une journée d'intervenir dans deux environnements différents, mais dans le cadre de la phase pré-production : assister 2 équipes dans la résolution de problèmes de dernières minutes avant le lancement !

Le premier cas : le matin, auprès d'une équipe de jeunes développeurs motivés maitrisant Eclipse version ganymade, l'outil de gestion de version Subversion intégré à Spring, l'outil Jira pour le suivi des bugs, cruisecontrol pour le build continue, … tous les plugins nécessaires ont été installés (SVN, Maven, SpringIde, Hibernate tools, ).

Le second cas : l'après midi, une équipe exploitant l'IDE Jdeveloper 11g, pas d'outil de suivi de bugs …

Les équipes avaient le même niveau d'un point de vue conceptuel, la maitrise même du langage Java et de la plateforme Java EE,

Dans les 2 cas on trouve les mêmes sujets: application de gestion en mode web, exploitant les framworks classiques Spring, Hibernate, pour l'un c'est du JSF et pour l'autre c'est du JSP/Struts, il ne s'agit ni de SOA, ni de SaaS, ni de PaaS ou d'un autre Buzz, les choses s'articulaient simplement autour de la notion de CRUD.

De point de vue productivité, le contraste, était frappant :

• la première équipe a réalisé plus du double du travail que la seconde (et ça ne pourrait pas être expliqué par la lenteur de Jdeveloper),

Cela m'a permit de prendre valider, encore une autre fois, les constats suivants :

- Maitriser les raccourcis clavier (shortcut keys) de votre IDE , connaitre toutes les techniques de navigation efficace dans votre code, trouver un élément à la vitesse de la pensé ! ,

- Lier directement l'IDE à l'outil de gestion de version permet de gagner un temps appréciable (surtout en temps de crise)

- Automatiser les tâches répétitives (pas seulement la compilation, mais aussi le transfert de fichiers du développent vers de la pré-prod par exemple, rend le travail des équipes plus fluides en éliminant les phases d'hésitations et de vérifications …

- Dans le développement du code source, observer scrupuleusement la règle des 30secondes (on doit être capable de comprendre la logique d'une méthode en mois de 30s) permet d'aller plus vite pour fixer un bugs (même sous le stress)!

En plus, lorsque l'équipe est habituée à la responsabilité collective "du code source", les choses vont mieux..

En théorie, il n'y pas de différence entre pratique et théorie

Dans la pratique si.