Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Agilité

• Craftsmanship, le débat fait rage dans la blogosphère!
• Les dangers qui guettent Scrum

Actualité éditeurs / SSII

• JAX-RS 2.0

Evènements de notre communauté en France et à l’étranger

• Code retreat à Grenoble

Agilité

Craftsmanship, le débat fait rage dans la blogosphère!

Bien que facilement traduisible, littéralement artisanat, le terme Craftsmanship, son application au développement logiciel, son sens profond, son implication au quotidien semblent échapper au plus grand nombre, et même susciter la perplexité ou la controverse. Pour preuve, la multitude d’articles postés sur les blogs ces dernières semaines qui en débattent.

Petit résumé des faits marquants:
Tout a commencé le 11 janvier par le post d’un article de Dan North, Programming is not a craft, dans lequel ce dernier exprime ses craintes et son scepticisme au sujet du Craftsmanship. Ses craintes tout d’abord d’un égocentrisme exacerbé de la part des développeurs ne s’identifiant plus à des créateurs de logiciels mais à une sorte de caste de supercodeurs intéressés uniquement par la beauté intrinsèque du code et non plus par les besoins du client. Il rappelle que les craftsmen doivent être sans égo, humbles, avec comme focus les livrables plutôt que le processus.
Il insiste enfin sur la nécessité de fournir des réponses adaptées au besoin. A un besoin simple, une réponse simple, pas de fioritures, de décorations inutiles, l’objectif est la production de logiciels, pas de l’art. Il ne voit pas d’intérêt dans le Craftsmanship ou plutôt aimerait voir le manifeste réécrit en terme d’obtention de résultats et de satisfaction client.

Robert C. Martin, une des figures emblématiques du mouvement, réplique le 17 janvier dans Software Craftsmanship: What it’s all about et tente une explication de ce qu’est ou n’est pas le mouvement Craftsmanship.
La lassitude d’écrire du code de mauvaise qualité, de faire du « mauvais » boulot, et par ailleurs la volonté de faire les choses bien.
Il réaffirme que le mouvement ne prône pas le fait de mettre le code au centre de tout, d’oublier que notre travail est avant tout de satisfaire le client.
La différence réside dans la non acceptation de faire les choses « mal ». La seule façon de faire les choses vite est de les faire bien.
On atteint la satisfaction des clients en écrivant le meilleur code possible, en faisant la meilleure conception, en testant, en pratiquant pour devenir meilleur chaque jour dans notre travail.
Toutes ces résolutions ont pour objectif la satisfaction client, via un travail personnel, une attitude humble, de remise en question.

Suit le retour de Martin Fowler dans Craftsmanship And The Crevasse dans lequel il s’inquiète également du fait que le mouvement puisse rouvrir la fossé entre le développement et le client que l’agilité avait comblé. En se concentrant trop sur le développement proprement dit, il voit un risque de minimiser le rôle de la communication avec le client, de ne pas atteindre les objectifs.

Réponse de Robert Martin dans Brining Balance to Force dans lequel il rappelle le 4e point du manifeste « We value not only customer collaboration but also productive partnerships » qui selon lui devrait suffire à rassurer et atténuer les craintes. Il insiste également sur la nécessité d’un bon équilibre entre les considérations techniques et non-techniques comme la communication. Tout est une question d’équilibre, les deux sont importantes, il ne faut négliger ni l’une, ni l’autre.

Nous le voyons, les craintes sont importantes sur le sujet et certainement légitimes si l’on regarde les personnalités qui s’en inquiètent. Il y a une grande incompréhension sur l’intérêt même du mouvement par rapport au mouvement agile, avec une peur forte de délaissement des problématiques client. Mais ce qui frappe dans les échanges est le fait que tout le monde est finalement d’accord sur le rôle central du client. On est plus dans l’incompréhension que réellement dans la discorde, Robert Martin s’efforçant d’expliquer que le mouvement Craftsmanship ne va pas à l’encontre de ces préoccupations.

Les risques de dérives existent forcément et il ne faut surtout pas les négliger. Les différentes réactions illustrent un manque de clarté sur la définition même du Craftsmanship, et les interprétations qui peuvent en être faites. Il faut être vigilant et ne pas sombrer dans le tout technique et un faux sentiment de supériorité, néfaste pour tout le monde. Le « JE fais le choses bien. Les autres font n’importe quoi » est à bannir, et est à l’opposé des principes même du mouvement.

D’ailleurs pourquoi opposer qualité des développements avec satisfaction client et résultats ? Est-ce satisfaisant de délivrer une fonctionnalité qui, en terme de fonctionnement général, répond aux attentes de l’utilisateur, mais n’est pas fiable, ne peut évoluer, est difficilement maintenable ? Il est pourtant bien connu que le manque de qualité coûte cher, très cher au final. Alors pourquoi ? La question mérite elle aussi d’être posée.

Nous assistons, depuis quelques années, à une percée très forte des méthodes agiles (Scrum par exemple) dans le développement logiciel. Cet assainissement des pratiques de développement est un vrai succès mais il cache aussi un autre phénomène. Là où les premières heures de l’agilité étaient plutôt orientées sur la pratique du développement avec l’eXtreme Programming, les principales méthodes utilisées aujourd’hui (Scrum et Lean) ne se préoccupent plus trop de la programmation mais plus des processus, la qualité du produit devant en émerger tôt ou tard… ou jamais.
S’ajoute à cela l’arrivée massive de chefs de projet traditionnels, de concepteurs, d’architectes, non convaincus par l’agilité mais persuadés d’y trouver une reconnaissance, une ligne sur un CV. Le problème est que petit à petit, l’agilité est de moins en moins bien appliquée. On fait du Scrum avec des cahiers des charges, des backlogs figés et des vélocités prédéfinies, sans rétrospective… Tests et conceptions sont négligés au profit de la production immédiate… on s’éloigne simplement de l’objectif principal, la production d’un logiciel de qualité, la relation client, pour aller vers moins de pragmatisme, plus de processus.

Le Craftsmanship tend au contraire à revenir aux fondamentaux, prônant la qualité et la productivité face à la production, l’apprentissage et la transmission du savoir, sans pour autant rejeter le mouvement agile dont il est issue.
 Comme l’écrit Robert Martin, le Craftsmanship n’est pas en désaccord avec les méthodes et pratiques agiles, bien au contraire. Si nous regardons un peu l’historique du mouvement, il est issu majoritairement d’agilistes convaincus. Pour parvenir à produire un logiciel de qualité, il est fort probable qu’un craftsman optera pour un processus de développement agile et des techniques issues de l’agilité comme celles contenues dans l’eXtreme Programming. Alors pourquoi ce mouvement?

Tout comme l’agilité, le Craftsmanship est un mouvement de pensée. Il existe, de même, plusieurs écoles, plusieurs façons de l’appréhender. Contrairement à l’agilité, il n’existe pas de méthodes, de pratiques, bien définies du Craftsmanship. C’est avant tout une attitude, un état d’esprit, et c’est à mon avis ce qui complique sa compréhension mais qui le différencie également. Là où les méthodes agiles parlent de travail en équipe, de processus, d’ensembles de techniques, le Craftsmanship est axé sur le développeur en tant que personne. En plus d’un cadre favorable au développement logiciel, le développeur doit être à même de fournir, avec une productivité maximale, le logiciel attendu avec une qualité optimale. Pour ce faire, il se doit de progresser continuellement, d’apprendre de nouvelles techniques pour les utiliser de manière appropriée en fonction du contexte. Les techniques utilisées sont des conséquences de l’attitude, pas un pré-requis. Les craintes exprimées sur l’égo du développeur sont, de mon point de vue, à l’opposé des valeurs mêmes du Craftsmanship qui prône, au contraire, l’humilité, seule à même de permettre la remise en question nécessaire à l’apprentissage, l’évolution continue, le perfectionnement. Avant toute chose, un craftsman, est une personne capable de remettre en question son travail dans le but de progresser et de fournir toujours le meilleur à son client. Ça ne l’empêche pas d’être pragmatique, ni de faire des choix.

Pour résumer: le Craftsmanship ne doit pas nous détourner du client qui doit rester au centre de nos préoccupations. Le perfectionnement des techniques de développement, la remise en question de nos pratiques et l’humilité doivent nous aider à être plus efficace dans la livraison de logiciels de qualité, sans nous détourner du reste.

Les dangers qui guettent Scrum

John Clifford revient, dans un article publié sur le site de la Scrum Alliance, sur une tendance observée assez régulièrement. Nous pourrions appeler cette tendance « on fait du Scrum mais… ». Par exemple :

• On fait du Scrum mais l’équipe ne s’auto-gère pas et le Scrum master assigne les tâches
• On fait du Scrum mais pas de sprint review. L’équipe décide au jugé quand un élément est done

Pour Clifford, Scrum est constitué de 3 rôles, 4 meetings et 4 artefacts. C’est simple. Que dire alors d’une compagnie qui voudrait « faire du Scrum » sans suivre ce carcan minimum ? D’autant qu’il donne aussi des exemples détaillant pourquoi on ne peut pas faire de Scrum à la carte:

• Pourquoi une revue de sprint ? Du code qui fonctionne et qui le prouve est la seule mesure d’avancement qui soit (et pas une TODO liste ou un diagramme de Gantt)
• Pourquoi une rétrospective ? Sans regard en arrière sur nos propres processus, comment pourrons nous les améliorer et devenir meilleurs ?

Pour ajouter à sa thèse, dans l’absolu, il sera sans doute mieux de faire un artifact « de type scrum » plutôt que de ne rien faire. Par exemple, tenir une rétrospective après une échéance projet sera toujours mieux que rien. Tenir une réunion journalière d’un quart d’heure avec l’équipe permettra toujours d’améliorer la collaboration entre ses membres. Mais il ne faudra pas croire que l’on fait du Scrum et blâmer le process si le succès n’est pas à l’arrivée: Scrum est un tout.

Parmi les problèmes de Scrum également rencontrés sur le terrain, on pourra faire le parallèle avec ce post d’Uncle Bob, What Killed Waterfall Could Kill Agile. Il nous rappelle que la mise en place de Scrum implique aussi d’avoir un vrai Scrum Master. Et un Scrum Master n’est pas un chef de projet ! Ce ne sont pas tant les certifications Scrum qui en prennent pour leur grade que l’élitisme de ceux qui les passent pour ajouter cette Certification à leur panel de compétences et espèrent ainsi pouvoir manager des équipes Scrum… Or, c’est l’équipe qui se manage en Scrum ! De la même façon, cet article d’InfoQ paru hier semble mettre tout le monde d’accord sur le fait qu’on ne peut pas être à la fois Scrum Master et Product Owner. Ca semble logique.

Bref, vous l’aurez compris, Scrum n’est pas si compliqué. Et si le projet a la moindre valeur, sans doute, sa réussite vaut-elle le coup de s’impliquer dans Scrum.

Actualité éditeurs / SSII

JAX-RS 2.0

JAX-RS, l’API Java pour les Web Services RESTful a eu une activité riche cette semaine :

JSR-339
Le vote du démarrage de la spécification 2.0 de cette API sous la JSR 339, qui est planifiée pour être intégré avec JEE 7. La date de sortie planifiée est Q2 2012.
La JSR contient quelques pistes pour comprendre la portée de cette seconde version, notamment :

• API Cliente
• Meilleur support des liens entre les ressources (HATEOAS)
• Architecture MVC, avec support de quelques moteurs de template.
• Intégration de bean validation
• Intégration de @Inject (JSR 330)

Plus de détails dans la page de description de la JSR.

Jersey 1.5
La version 1.5 de l’implémentation de référence de JAX-RS 1.x est sortie. Cette version contient essentiellement des correctifs et est destinée à être associée à la future livraison de GlassFish 3.1 (ChangeLog)

Byebye Paul
Enfin, Paul Sandoz, la figure de proue de Jersey, quitte Oracle et son rôle de co-spec lead.

Evènements de notre communauté en France et à l’étranger

Code retreat à Grenoble

C’est souvent sous la contrainte que l’on devient créatif: l’improvisation dans le jazz, isolé sur une île de déserte. On trouve toujours une nouvelle voie! C’est ce qu’il s’est passé au code retreat de Grenoble organisé par CARA (Club Agile Rhône Alpes) et le JUG. La journée était animée par Johan Martinsson, Rémy Sanlaville et Miguel Moquillon.

Nos contraintes:

• Après 45 minutes de programmation en binôme, effacez ce que vous avez codé et changez de partenaires.
• Les règles à respecter lors du codage sont celles du simple design :
• Tous les tests passent.
• Pas de duplication de code.
• Le code exprime toutes les idées que veut exprimer l’auteur (bon nommage).
• Minimaliser les classes et méthodes.

L’exercice à traiter était le jeu de la vie, dans un langage librement choisi. Principalement réalisé en Java, il y avait aussi Pharo: une implémentation de Smalltalk, et Ruby.

L’intérêt du jeu de la vie est qu’il peut être abordé de plusieurs façon et avec plusieurs implémentations et choix de structures de données possibles. Pour les plus téméraires on peut même commencer à introduire des formes animées dans le jeu.

Croyez moi qu’en 45 minutes vous n’avez pas le temps d’arriver jusque là. Alors bien sûr cela crée une frustration qu’il faut apprendre à gérer en focalisant son énergie ailleurs.

En effet, tout au long de la journée, l’intérêt de chaque session (aux nombres de 7), est d’oublier ce que l’on a fait précédemment et de coder le problème d’une manière différente avec un nouveau binôme. Un autre avantage est que parfois, passant par la même implémentation, vous trouvez une façon d’aller plus vite ou une amélioration.

A souligner que le time boxing, de la plus haute importance dans ce genre de session, a été très bien géré par l’équipe d’animation.

Une rétrospective de 15 minutes à la fin de chaque session permettait de discuter autour de solutions qui avaient émergé, de la démarche de test, de nouveaux raccourcis IDE et d’ébauches de futures solutions.

A la fin de la journée, une rétrospective générale a permis de dégager un consensus autour de certains points :

• Une frustration de ne pas pouvoir aller plus loin dans l’implémentation! Mais là n’était pas le but de l’exercice.
• Une reconnaissance que le non attachement à son code (obligation d’effacer le code) aide à rester ouvert, à se remettre en question

et donc à progresser.

• Qu’il faut écrire des tests unitaires simples et rapides.
• Qu’il faut écrire les tests unitaires de façon incrémentale (baby steps). Cela permet de ne pas se perdre dans de longues périodes de rouge.
• Que l’on apprend toujours quelque chose sur soi-même ou de nouveau quand on programme en binôme.
• Que la pratique du TDD se transmet et s’apprend très bien en binôme.