Publié par
Il y a 5 années · 5 minutes · Agile, Events

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

Le coin de la technique

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

Agilité

La fin des story points?

Deux publications ont récemment retenu mon attention ces derniers jours.
Le premier est un article de Joshua Keriesky, coach agile aux Etats-Unis depuis de nombreuses années. Fort de son expérience de transition d’équipes vers l’agilité avec Scrum, il s’étonne des dérives que peuvent avoir certaines équipes avec la gestion de la vélocité, et cela quelqu’en soit leur maturité. Les dérapages les plus courants sont d’utiliser la vélocité pour les comparer différentes équipes ou encore d’augmenter la taille des story points pour avoir une vélocité plus importante. Si le respect de l’engagement du spring est voulu coûte que coûte, la qualité des projets est souvent sacrifiée pour pouvoir terminer le sprint dans les temps impartis. L’auteur nous rappelle qu’une estimation reste un paris sur l’avenir. Joshua propose alors de travailler par itération à charge variable et n’utilise plus de story points ni de notion de vélocité! La vision d’échéance de grandes fonctionnalités est réévaluée à chaque début d’itération.

Le second article en relation est publié sur le site InfoQ. L’auteur revient sur la gestion des métriques dans un contexte d’agilité et leur utilisation pour mesurer le succès d’une équipe. Pour lui, observer un processus c’est l’influencer. Fixer des objectifs individuels peut nuire à la qualité globale du produit. Cela favorise la course à l’objectif et ne favorise pas la collaboration. Il reprend l’exemple d’imposer une métrique d’écriture de tests unitaires aux développeurs. Vous risquez d’avoir ensuite plus de tests écrits, mais bien souvent de moins bonne qualité, voire même inutile. Il en est de même avec les objectifs sur la vélocité (personnelle ou au niveau d’une équipe). L’agilité a pour fondement une confiance mutuelle. Si elle est correctement motivée, l’équipe fera tout pour produire de la valeur à un rythme soutenable et réagir en cas d’imprévu.

Mais que mesurer alors pour connaitre le progrès d’une équipe? L’auteur précise alors que l’élément qui devrait attirer l’attention, c’est le produit fini en lui-même. Convient-il aux clients? Correspond-il aux attentes des clients ainsi qu’aux enjeux de la société ? Est-il fiable? Est-il à temps sur le marché?

Je suis étonné de voir que des coaches agiles recommandent de ne plus utiliser ces notions basiques. Leurs visions démontrent qu’elles peuvent desservir l’équipe plutôt que l’inverse. Ce sont certes les notions les plus controversés de Scrum. La notion d’estimation et de vélocité est en effet la partie la plus subjective, fortement dépendante du fonctionnement chaque équipe. Ces métriques sont-elles des reliques pour d’anciens chefs de projets? Sont-elles vraiment nécessaires? N’est-il pas plus intéressant de se demander comment délivrer plus des valeurs que comment faire la même chose plus vite? Etes-vous prêts à vous passer des story points si on vous fait subir trop de pressions sur les chiffres?

Le coin de la technique

Optional déchaîne les passions sur la mailing-list du projet Lambda

Le projet Lambda a pour but d’intégrer les littéraux de fonctions dans Java 8. Une classe Optional a récemment fait son arrivée dans la base de code : empruntée à certains langages fonctionnels, elle encapsule une référence qui peut être soit présente, soit absente. Cette construction oblige le code client à gérer explicitement tous les cas, au lieu de renvoyer un null que l’on risque d’oublier de traiter :

// Actuellement :
Country result = getCountryByName("Wonderland");
String capital = result.getCapital(); // NullPointerException possible !

// Avec Optional, cela pourrait ressembler à :
Optional<Country> result = getCountryByName("Wonderland");
String name = result
    .map(Country::getCapital)
    .orElse( () -> "Country not found" )

Mais ce nouveau type a déclenché un débat enflammé entre deux camps :

  • les pragmatiques, pour qui il se limite à l’utilisation évoquée ci-dessus.
  • les adeptes des langages fonctionnels, qui souhaitent pousser plus loin le concept, en ajoutant en particulier la capacité de composer de manière transparente plusieurs Optional ; il s’agit là de la fameuse notion de monade, précédemment abordée sur ce blog.

Après de longues discussions, Brian Goetz, le responsable du projet, a tranché pour la version simple, en expliquant que le but n’était pas de transformer Java en Scala ou Haskell, d’autant que les discussions autour d’Optional avaient déjà largement consommé le budget initialement prévu pour cette fonctionnalité.

Évidemment, cette réponse ne plaît pas à tous, et conduit même certains à accuser les ingénieurs d’Oracle de ne pas être à l’écoute de la communauté. Dans une dernière réponse, Brian Goetz — que l’on sent un peu las — présente sa vision d’architecte du langage ; un message intéressant qui résume bien les défis liés à l’évolution de Java.

Et vous, voyez-vous l’utilité du type Optional dans votre code ? Quelles fonctionnalités en attendriez-vous ?

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

Webinar Intégration Continue

Mercredi 7 Novembre 2012, Mark Prichard (CloudBees) et Andrew Phillips (XebiaLabs) vous montreront comment mettre en place rapidement et facilement une intégration continue avec Jenkins et Deployit.

Il est encore temps de vous inscrire ici  http://go.xebialabs.com/1112CBWorkshop_3RegistrationPage.html

Xebia France
Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 11 ans nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *