productivité des développements

Productivité des développements Java

On pourrait résumer la session de Guillaume Duquesnay ainsi : la productivité des développement Java, ou comment adopter des pratiques qualité sans prononcer ce mot qui fait peur.
Une démonstration des tâches avilissantes et peu créatrices de valeur auxquelles s'est plié chaque développeur dans sa carrière au moins une fois a été exécutée par l'orateur. Il a expliqué que pas à pas, on peut améliorer la productivité de tous les membres de l'équipe. Simplement en étant à l'écoute des souffrances et des plaintes, on détecte les failles du processus de développement à corriger.
En effet, la productivité ne devrait pas être vue comme un mot taboo, mais devrait pouvoir remplacer dans la vision des managers le centre de coût que représente la qualité en une source de valeur. Là où le mot productivité dans l'industrie classique est associé à l'augmentation des cadences de travail, pour le développeur, cela rend son travail quotidien moins laborieux et plus agréable.
Du point de vue pérénité de la démarche, les procédures de qualité sont les premières pratiques à être abandonnées lorsque les contraintes projet se tendent. On peut penser au contraire que les pratiques visant a améliorer la productivité sont adoptées pour de bon.
pragmatic.jpg

Clés du succès

  • pas de religion : ne pas croire aux miracles : la solution universelle n'existe pas. Au contraire, les solutions d'amélioration de productivité doivent être adaptées au niveau de maturité de l'équipe.
  • pas de révolution : un changement progressif à petits pas est le garant de l'adoption des pratiques.
  • pas de procrastination : les tâches d'amélioration de la productivité ne doivent pas être remises à plus tard, l'expérience montre qu'on perd plus de temps à continuer une pratique improductive que de passer le temps qu'il faut à la résoudre.
J'ai retrouvé dans cette présentation une mise en pratique de nombreux conseils lus dans le livre : The Pragmatic Programmer: From Journeyman to Master. Paru il y a un peu moins de 10 ans déjà, la démarche décrite reste d'actualité et est en accord avec le discours de Guillaume.

maven à la demande

Une scéance de réponses aux questions préalablement posées par les inscrits à Arnaud Héritier.
Ce qui m'a particulièrement étonné dans l'intervention d'Arnaud fut la coloration très "commerciale" du discours. On pouvait entendre notamment les termes : Concurrence, challenge, rester sur ses acquis, niveau de service ergonomique. On a plus l'habitude d'entendre ça de la part de commerciaux ! Le cliché du développeur open-source s'est envolé immédiatement.
Il a aussi évoqué les problèmes relationnels au sein du projet. J'ai toujours supposé qu'il pouvait y avoir des tensions au sein d'une communauté Open-source. Avec maven, on est servit : un chef despotique et intransigeant (Jason van Zyl), des sociétés rivales qui se créent... Arnaud lui-même a parlé de projet à la Dallas ; ne mentionnons pas le terme "jasonification des équipes" qui m'a fait bien sourire.
filthyrichclients.jpg Il a rappelé que l'influence des entreprises est vraiment non négligeable. En effet, comment rivaliser contre des personnes qui travaillent 8h rémunérées sur le projet là où les développeurs bénévoles donnent deux heures de minuit à 2h pas très frais (attention, cliché ;-) ). Ce fut l'objet de ma question (qui m'a vallu le livre Filthy Rich Clients offert par ParisJUG et dédicacé par Chet Haase) sur ce qu'apportait au niveau personnel à Arnaud sa participation à ce projet. Pour lui, le moteur premier est la récompense d'avoir trouvé une solution satisfaisante au problème du build.
Côté infos, j'étais venu pour me renseigner sur un support du build des plug-in eclipse par Maven. Arnaud nous a renvoyé vers l'expert maison Carlos Sanchez qui a exposé ses slides durant 2h sur le sujet à la dernière eclipsecon.
Je résumerai également la rivalité des deux projets qui entrent en concurrence pour devenir le plugin de référence apportant (enfin) le support de maven dans eclipse. Notez qu'IBM a toujours mis des bâtons dans les roues à maven pour s'intégrer (à la différence d'IntelliJ ou NetBeans dans lesquels maven est très bien supporté). Ils utilisaient ant et ne voyaient pas de raisons d'en changer.
Q4em2eclipse
+ support WTP+ support WTP
pas JasonJason
+ ergonomie- peu intégré
+ support eclipse 3.3 (sous modules maven = sous projets eclipse)+ support de Nexus (indexation artefacts)
La course est féroce entre les deux projets qui sont au coude à coude. Impossible pour l'instant de les départager... Comme toujours dans ce cas là, les essayer et juger par soi même.

Une session très intéressante, encore un succès pour ParisJUG.