Tags

, ,

L’Elsass JUG s’est réuni le jeudi 19 Mai pour une soirée ‘Atelier Agile‘, avec Oana Juncu, scrum master et membre du board de l’Agile Tour. La soirée est à guichet fermé: le format ‘atelier’ ne permet d’accueillir que 35 personnes.

Agile c’est agile

Nous avons commencé par une présentation de quelques principes fondateurs de l’agilité, que je vous présente librement:

  • le client c’est le client: l’objectif est de livrer un produit fonctionnel correspondant aux besoins. Ceci ne peut se faire que par une communication régulière avec le client du produit.
  • le développeur développe: une communication régulière permet de maximiser le temps de développement efficace. De plus, seul le développeur sait quelle est la complexité des fonctionnalités à réaliser, il est donc associé pleinement à la planification du projet.
  • l’heure c’est l’heure: chaque ‘sprint’, c’est à dire chaque étape du projet telle que définies par Scrum, est définie par son ‘backlog‘, l’ensemble des fonctionnalités à implémenter, et par une date de livraison. Les fonctionnalités livrées peuvent être réduites, mais les délais sont toujours respectés.
  • fini c’est fini: un produit livré ne doit plus être modifié. S’il est nécessaire de le modifier encore, il n’est pas possible de le livrer.
L'agilité, c'est l'engagement

L'agilité, c'est l'engagement

La deuxième partie de la soirée s’est déroulée en deux ateliers: ‘Ball Point’, et ‘les concepteurs et les artistes’. Les participants sont réunis en quatre équipes.

Ball Point

Premier jeu: trois itérations de deux minutes chacune. L’objectif technique: une balle doit passer par tous les membres de l’équipe, et ce le maximum de fois, durant le temps imparti. Une balle qui tombe est perdue. Chaque équipe dispose de six balles.

Le challenge consiste avant tout à estimer le nombre de parcours réalisés. Au cours de différentes itérations, l’estimation s’affine, comme celle de la charge de travail impliquée par un backlog. Les équipes améliorent leur collaboration – les trajectoires deviennent plus précises – optimisent les process – certains lancent les balles en hauteur, d’autres plus bas – et gagnent en régularité – moins de prise de risque – quand le jeu est maîtrisé.

Des ratés apparaissent aussi: dans les équipes qui se connaissent mal, les balles se perdent, même après plusieurs minutes. Ou les décisions conservatrices, par exemple n’utiliser que deux ou trois balles sur les six, empêchent rapidement la progression de l’équipe.

Un enseignement se dégage: estimer la performance visée est un travail d’équipe, qui devient plus précis au fil du jeu, comme il le devient aussi lors de la maturation d’un projet de développement.

Les concepteurs et les artistes

Deuxième jeu: deux concepteurs visualisent un dessin, qui doit être reproduit par un groupe d’artistes.

La communication est très limitée: lors des deux premières itérations, elle ne se fait que par écrit. Les spécifications sont transmises, et mises en oeuvre. Les questions se font par écrit uniquement. La difficulté du travail sur spécifications est mise en évidence à plusieurs niveaux: faut-il fournir des spécifications incomplètes ? Des spécifications riches qui grignotent le temps de mise en oeuvre ? Comment est-il possible de créer efficacement quand le feedback est limité ? Les concepteurs comme les artistes luttent avec les règles du jeu, bien plus qu’ils se ne focalisent sur la réalisation d’un dessin.

La troisième itération modifie profondément les règles du jeu: le dessin n’est visible qu’une fois par les concepteurs, au début du sprint. La communication est ensuite libre entre les concepteurs et les artistes.

La réalisation est certes moins fidèle à l’original dans les détails. Mais les dessins sont cette fois complets, cohérents. Et ils sont le résultat d’une collaboration forte entre les membres du projet, qui peuvent se concentrer pleinement sur leurs objectifs.

Le développeur redevient maître du jeu

Au travers de ces deux jeux, deux leçons fondamentales sont présentées:

  • le travail en équipe se fonde sur la communication et l’expérience, et permet de maîtriser avec finesse la vitesse de réalisation du logiciel,
  • l’objectif des projets est de créer un logiciel, pas d’imposer aux équipes des structures inadaptées.

L’agilité encourage le dialogue direct entre le client et le développeur. Elle place le besoin client au centre des préoccupations du développeur. Et consacre le développeur comme l’interlocuteur incontournable dans le process de création de logiciel.

Prochain rendez-vous sur l’agilité ? Des rumeurs annoncent l’Agile Tour à Strasbourg à l’automne 2011. Affaire à suivre.

Advertisements