Journée Agile à Namur. De bonnes pratiques à se mettre sous la dent mais certaines de mes questions n'ont pas trouvé de réponse.

Mon programme

  • Agilité 3.0. Luc Bizeul démonte quelques mythes ou nuance certains principes agile. Il préfère parler d'ajustement plutôt que d'amélioration. Les objectifs et les valeurs sont évolutives. Discussion en petits groupes avec d'autres participants qui m'a donné l'occasion de me rendre compte à quel point je suis agile. :)
  • Retour d'expérience, Yves Labotte et Adrien Rami. As adverstised, un retour d'expérience (positif) mais je reste sur ma faim (pas de détails sur les pratiques qui marchent et celles qui posent problème).
  • Kanban game par Michel Coens. La partie "game" a l'air plus compliquée que les cérémonies Scrum, mais Kanban en lui-même est très peu prescriptif. J'ai prendrais bien une part.
  • TDD par Mathieu Gandin Pierre-Emmanuel Dautreppe. Intéressant Kata. Exposé ciblé et structuré. Jamais été convaincu que TDD est applicable à tout projet et, pour un projet donné, à tout le développement. Typiquement, pour un composant idiomatique, ça me semble contre-productif. Par contre, même sur une simple logique métier, l'influence du TDD sur les assomptions de départ est flagrante. Mais l'exemple débouche finalement sur un test d'intégration, pas sur un test unitaire. L'auteur avait assez de recul que pour ne pas emprunter les formules péremptoires de certains extrémistes du TDD (si vous faites autrement, c'est mauvais, si ce n'est pas testé, ça ne sert à rien, ...). De quoi me donner l'envie de retenter le TDD!
  • Comment faire des retrospectives, par Norman Deschauwer. De son propre aveu, il s'agissait de principes de bon sens, mais il est bon d'insister le rôle du coach (facilitateur) ou de montrer le chemin pour qu'une retrospective ne tourne pas au règlement de compte. 5M, 5 Whys : très didactique.

Observations

1. Curieusement, pas mal de commentaires conservateurs émanent de jeunes qui ont été enrolé à la vieille école.

2. Le mythe de l'équipe agile polyvalente est tenace! Je n'y ai jamais cru. L'idée est que chaque individu dans l'équipe doit être à même de faire évoluer une tâche vers "DONE". Certains sont certes plus qualifiés ou plus à l'aise mais chacun devrait pouvoir y arriver.

Avec des développeurs seniors impliqués et motivés, c'est en partie possible, mais ça implique de toucher, en plus du développement, à de l'infrastructure, à l'analyse, aux tests, au design web, au back-end, à la DB, ...

Au mieux, c'est perçu comme inefficace, le développeurs étant une denrée rare et couteuse. Il semble naturellement plus indiqué qu'ils se consacrent aux tâches pour lesquelles ils sont les plus efficaces.

Si vous avez un business analyst, pensez-vous qu'il soit à même de développer? Même question pour un testeur (qui ne fait que ça et qui le fait bien), ou un web designer? Et d'après ce que j'entends, la plupart des développeurs veulent uniquement développer (ou programmer) et n'ont aucune envie d'interagir avec le client.

3. KANBAN peut apporter des réponses là où SCRUM n'offre pas pleinement satisfaction.

Par exemple, la tendance à terminer à tout prix des stories à la fin d'un sprint, quitte à prendre des raccourcis, plutôt que de reporter une ou deux stories entamée. Ou la tendance perverse à transformer en user stories des activités qui ne le sont pas, pour afficher une belle vélocité.

Les activités de refactoring sont mal prises en compte et les initiatives du genre "jours réservés" ("hack day", "creativity day", "bug squashing day", "refactoring day", "support day") fonctionnent à petite dose mais sont en porte-à-faux avec le reste et sont mal comptabilisées. C'est à mon avis trop rigide : quid si une personne est absente, pas de bol, deux "hack day" d'affilée sur deux sprints? Si le jour réservé est interrompu par un imprévu? Trop souvent, ces jours passeront à la trappe, rattrapés par le pragmatisme du backlog.

Un combo des deux pourrait être pas mal, mais avec le risque d'être "hors piste" (soit sans pratique validée).

Mais tout cela est finalement fort peut satisfaisant. Je progresse en ce moment sur une méthodologie de type KICKASS PROGRAMMING qui mettra un terme définitif aux errements de l'Agilité. Ca nous a bien servi, mais il est temps de passer à autre chose :-)