Journée spéciale conférences ce mardi avec en plat principal l’Agile Tour à Grenoble et en dessert la soirée Lyon JUG. Tout ça en bonne compagnie d’Alexis Hassler (sewatech). Quelques impressions :
L’Agile Tour
Planning serré : 2 keynotes et 4 sessions aux choix suivant différentes thématiques : Retours d’expériences, Management, Méthodologie, Lean, Pratiques d’ingénierie et Jeux (car l’agileur aime gonfler des ballons de baudruche ou jouer au poker menteur).
Keynote d’Henri Kniberg
On a loupé la moitié des slides suite aux embouteillages liés à la grêve SNCF. J’étais malgré tout content de voir le bonhomme car c’est grâce à lui que j’ai mieux appréhendé Scrum il y a quelques années ans grâce à son excellent retour sur expérience Scrum and XP from the Trenches (apparemment c’est enrichi et devenu un bouquin).
Rien de nouveau dans ce que j’ai vu, mais super synthèse avec des messages, schémas et exemples toujours percutants. Par exemple la méthaphore de la perte des clés appliqué à la gestion des tests : plus le temps passe après la perte des clés / l’apparition d’un bug, plus il est difficile de retrouver les clés / la cause du bug.
Retour d’expérience Scrum
J’ai ensuite opté pour un retour d’expérience d’un projet au (semi-)forfait mené par Osiatis (SSII) pour Schneider Electric. C’est la première fois que j’entendais les conclusions d’une telle expérience, et elles me paraissent assez intéressantes. Je ne suis pas le seul, la séance question/réponses a duré aussi longtemps que le présentation.
Intervention très préparée sur la forme : passage de relais régulier entre la directrice d’agence de la SSII, son responsable opérationnel, et un représentant du client. Discours bien rôdé. Sur la question de savoir si le projet est un succès, on perçoit bien la petite gêne du client pour donner le quitus à ce stade, mais il semble globalement satisfait et prêt à continuer.
Le contexte :
- projet de 1000j/h sur 10 mois avec 6 développeurs
- objectif : production de rapports d’analyses sur des appareils type onduleurs
- refonte d’un existant
- projet toujours en cours (démarré en mars 2009)
- des sprints d’une dizaine de jours
- date de livraison fixée dans le marbre
Ce que je retiens :
- le choix d’une méthodologie Agile découle ici du manque de spécifications du client. Sachant que l’existant facilitait les choses
- il y avait clairement une relation de confiance entre le client et la SSII, un bon niveau de maturité du client sur le processus de développement en général et une grosse disponibilité du client sur les phases d’études et de test. Des éléments indispensables mais qui me semblent assez rares par ailleurs
- ce qui m’étonne le plus : le client accepte dès le début du projet le fait que toutes les fonctionnalités ne seront pas livrées à la date prévue (d’où la notion de semi-forfait). Ce qui rompt avec l’hypocrisie des projets au forfait réalisés avec des méthodologies traditionnelles et qui débordent sur la date de livraison, mais ce qui demande quand-même une grosse confiance vis à vis de la SSII
- la backlog a été entièrement chiffrée conjointement par les 2 parties. Avec quelques étonnements de la part du client qui n’a évidemment pas toutes les billes pour apprécier les charges de dev et probablement des éliminations d’inconnues sur la partie métier.
- un gros point noir : la qualité du développement. Déjà parce qu’ils n’ont pas utilisé le Cockpit Kalistick
Mais aussi, en livrant une release toutes les 2 semaines, il n’est pas surprenant que la partie test soit critique. La réponse de la SSII est de rallonger les sprints pour ajouter des tâches de test sur chaque sprint et de réaliser un sprint de test en fin de release. A noter que cette problématique de test est ici accentuée par le fait que l’environnement est difficilement testable (nombreux équipements à tester).
Témoignage intéressant, assez humble de la part de la SSII, et à mon avis payant parce que je ne suis pas sûr que beaucoup puissent se prévaloir de ce type d’expériences.
Soigner sa schizophrénie MOA/MOE – Voyage au pays des spécifications exécutables
Par E. Hugonnet (Silverpeas) et H. Lourdin (Octo)
Des bonnes accroches dans l’intro pour montrer les décalages entre :
- ce que veut la MOA
- ce qu’elle exprime à la MOE
- ce que la MOE en comprend
- ce que la MOE en traduit dans l’implémentation
D’où l’objectif : que la MOA définisse ses besoins à l’aide d’un formalisme qui sera exploité automatiquement pour réaliser des tests sur l’implémentation. Une ancienne version des slides est disponible ici : http://www.agiletour.org/fr/Soigner_schizophr%C3%A9nie_MOA_MOE.html.
Même si je trouve l’idée de base séduisante, je reste encore sceptique sur sa mise en oeuvre, bien que ce concept semble être déjà appliqué sur différents projets (mais il faudrait avoir l’avis de la MOA). Il y a quand-même un choc des cultures entre une MOE qui a besoin de ces specs exécutables avec un formalisme hyper strucuré pour que ça passe les tests automatisés, et une MOA qui est rarement habituée à ces contraintes fortes de formalisme.
Par exemple, sur un outil comme FitNesse qui est un Wiki et qui demande à l’utilisateur de formaliser ses données avec des syntaxes du type :
| celulle 1 | *cellule 2 en gras* | _cellule 3 en italique_ |,
je vois mal certains profils MOA capables de produire ce type d’écriture (expérience vécue). D’ailleurs, les speakers ont bien reconnu que ce travail était plutôt conseillé en binôme MOA/MOE
A noter une petite crispation quand le sujet des tests d’IHM a été soulevé : certains soutenaient que ces tests sont parfois préférables aux tests de la couche services/métiers car ils couvrent un spectre plus large et plus fidèle à ce que voit l’utilisateur, d’autres avançant que ces tests sont trop coûteux à maintenir et pas forcément pertinents. Ma position, c’est que sur un produit comme le notre, nos tests fonctionnels nécessitent de passer par l’IHM, sinon leur pertinence devient assez douteuse en raison des traitements qui se passent sur l’IHM. Et notre outil de test, Tellurium, supporte également l’externalisation des jeux de données.
Je ne suis donc pas encore convaincu de la plus-value de ce type d’outils pour notre cas, même si c’est sûrement une piste à creuser pour d’autres.
Keynote d’Elisabeth Hendrickson
Je ne connaissais pas le personnage, apparemment une star de la communauté Agile, et elle vaut effectivement le détour. Présentation à l’américaine, percutante et avec une bonne dose d’humour.
Niveau contenu, surtout des pratiques de bon sens (intégration continue, automatisation des tests, tests sur la version déployée, stockage des tests sur un SCM, tests exploratoires, …) mais clairement synthétisées. Expliqués par quelqu’un comme Elizabeth, c’est sûr que ça intègre mieux les neurones.
La gestion des défauts et besoins non fonctionnels avec SCRUM
Par L. Jeanniard (Varian) et E. Mignot (Pyxis).
Je fais court parce que j’avoue avoir fait un blocage complet sur cette session dont le sujet m’intéressait pourtant. A cause de la forme, les 2 intervenants étant assis et dialoguant essentiellement entre eux (c’était la base du jeu), un iphone à la main. Et aussi du fond, que j’ai trouvé diffus et pour lequel j’avoue ne pas avoir bien compris s’il y avait d’autres messages que « faites selon votre contexte et votre bon sens », …
Integration et System Testing dans le contexte agile
Par P. Davan (Yahoo)
Patrice est responsable des tests chez Yahoo/Europe, il proposait une vision très opérationnelle de leurs processus de tests qui s’intègrent à un contexte Agile. J’ai particulièrement apprécié sa vision humble, avec des questions auxquelles il ne sait toujours pas répondre précisément (du type : à quel moment effectuer les tests ? A la fin de chaque sprint ? Au début du sprint suivant ?).
Ce que je retiens :
- le point central : le test qui doit porter sur le produit déployé, pas seulement sur le développement
- le focus sur la complexité à tester une IHM web. Chez Kalistick, on connait, mais chez Yahoo c’est évidemment à une autre échelle : support des différents navigateurs (et notamment l’arrivée des mobiles ces dernières années), le supports des plugins type Flash/Silverlight/Java, les accès directs par URL hors cheminement attendu, …
- un sprint donne toujours lieu à un livrable pour faire une démo, mais pas forcément un livrable totalement testé et stable. Aux équipes de communiquer sur l’état du livrable.
- automatiser les tests c’est bien, mais c’est extrêmement coûteux, il faut donc trouver le bon équilibre
- multitude de critères pour décider quand réaliser les tests : quantité de code modifié, criticité du code, processus/contenu des tests mis à jour, bugs chez le client, …
- il y a généralement un sprint de test en fin de release
- difficulté à éviter les doublons dans les tests mis en place
- à quel moment déterminer que la release est terminée ? Claude Aubry vient d’ailleurs de publier un billet à ce sujet.
- définition de l’équipe de test : il préconise la participation des développeurs aux tests mais insiste également sur le rapprochement avec l’équipe de support afin d’être plus proche des besoins/retours clients au niveau des scénarios de test.
Je dois dire que j’ai particulièrement apprécié cette présentation avec ce côté terre-à-terre qui tranchait avec certaines visions de « coach agiles » qui me semblent parfois un peu trop théoriques et éloignées de la réalité, même si pleines de bon sens.
Conclusion
Journée vraiment intéressante, excellente organisation (notamment sur la ponctualité des sessions, irréprochable), choix varié de sujets intéressants, bons speakers, … Parfois un peu décontenancé par le paradoxe entre le côté humble et souple « piochez ce que vous voulez chez nous, il n’y a pas de méthode universelle qui marche à tous les coups », avec un aspect prédicatoire voire gourouficatoire qu’on ressent parfois à l’écoute des « coachs agile », mais plein de bonnes choses à retenir.
NB : chez Kalistick, nous avons mis en place depuis près de 3 ans une méthodologie essentiellement inspirée de SCRUM+XP. Nos principales sources étant le sus-cité Scrum and XP from the Trenches, d’Henri Kniberg, des articles Wikipédia, des discussions avec d’autres acteurs, et nos expériences passées.
Le Lyon JUG
Retour à Lyon avec Alexis pour assister à la soirée JPA2/JavaEE6. Enfin juste JPA2 parce qu’Antonio Goncalves était grippé. A la place de la présentation JavaEE6, ceux qui ont participé à l’Agile Tour ont fait une synthèse à chaud, échange sympa.
C’est Noël Perez (Hinnoya), qui semble bien maîtriser le sujet, qui a assuré la présentation JPA. Clair, intéressant et synthétique. Je reste toujours dubitatif sur les démos de codage en live, j’ai toujours pas compris ce que ça apportait, mais apparemment, c’est une demande récurrente des participants du JUG, donc Noël a bien fait…
Salle pleine, plus de 60 personnes qui ont rapidement descendu le buffet. Ca devrait être encore plus couru le mois prochain avec une intervention de Didier Gérard, créateur du mythique a19s.com, blog avant l’heure (près de 10 ans ?) sur les technos Java, et maintenant expert sur les technos Google, qu’il viendra présenter. Rendez-vous le mois prochain…
[Mise à jour - 5/11/2009] : les supports des présentations de l’Agile Tour Grenoble sont disponibles ici : http://clubagile.org/evenements/conferences-2009/
