jeudi 28 octobre 2010

AgileTour 2010

Agile Tour Toulouse 2010


La journée était divisée en quatre parties (séparées par des pauses) :
  • 09h30 – 10h30 : que des conférences
  • 10h55 – 12h30 : que des conférences
  • 14h05 – 15h40 : des conférences, un atelier TP sur les TDD et les BDD et un ateliers TD sur la « priorisation » des User Stories et la planification des Sprint
  • 16h05 – 17h40 : des conférences et un atelier de TD sur Scrum
Plus de la moitié du public était composée d'étudiants. Il y' avait aussi des enseignants et beaucoup d'acteurs du monde informatique, notamment des développeurs, des chefs de projets, des DSI, des architectes, des commerciaux, …
Voici les conférences et ateliers auxquels j'ai assistés :

Scrum et IceCrum

L'objectif de la présentation était de faire un exposé sur Scrum à travers IceScrum, un outil de gestion de projet Agile développé par des étudiants de l'Université Toulouse III. L'accent était plus mis sur l'Agilité que sur les aspects technique de IceScrum. Pour la deuxième partie de l'exposé le présentateur invitait le public à prendre part à l'exercice de simulation d'un Sprint. Les questions posées sur le sujet de la présentation étaient inscrites sur IceScrum comme des User Stories. Ensuite pour « prioriser » ces questions on avait à notre disposition des cartons verts (pour) et des cartons rouges (contre) pour voter. Les questions étaient ainsi classées par ordre décroissant du nombre de points (cartons verts) attribués. La phase suivante sera consacrée à la planification, les questions les mieux notées seront traitées et rangées dans la colonne « terminée » .

Atouts et faiblesses de Scrum


Le présentateur de cette conférence était un enseignant. Les points qu'il a soulevés comme faiblesses de Scrum sont à mon avis assez discutables et déjà traités dans certains livres comme « Scrum depuis les tranchées ».
Il a noté en particulier que Scrum ne propose rien dans les situations suivantes :
- Quand des efforts nécessaires au bon fonctionnement de l'application n'attirent pas l'attention du PO. Par exemple : « Une architecture en couche de type MVC exige beaucoup d'efforts qu'il n'est pas toujours évident de valoriser devant le PO ».
- Quand des fonctionnalités demandées à la dernière minute par le PO exigent une refonte totale ou partielle de l'application. Par exemple : « On arrive presque à la fin du développement, le PO veut que son application soit internationalisée ».
- Quand une partie du projet se fait en « offshoring »

Planification et priorisation avec Scrum

Un projet Scrum doit être potentiellement livrable à la fin de chaque Sprint. Il est donc nécessaire de s'assurer qu'au cas où les contraintes de délais ne sont pas satisfaites, l'essentiel du projet a été réalisé. Le but de cette séance, de loin la plus dynamique malgré l'accent québécois du présentateur, était de donner des techniques qui aident à investir dans les bons stories.

Elle a débuté par la détection d'un User Storie :
  • En tant que (Qui)
  • Je désire (Quoi)
  • Afin de (Pourquoi) …
… ensuite la définition d'un Story de qualité qui doit avoir les propriétés suivantes :
  • I : Indépendant
  • N : Négociable
  • V : Valuable
  • E : Estimable
  • S : Small (pour que ce soit facile à estimer)
  • T : Testable

… des indicateurs de qualité d'un Sprint :
  • Nombre de stories ajouter/supprimer/modifier
  • Nombre d'anomalies (classés par criticité)
  • Temps moyen de solution d'une anomalie
  • Ecart moyen entre les estimations des tâches

… et enfin une méthode de « priorisation » des User Stories (MoSCoW)
  • Must Story : les Stories qui ont le plus grand Business Value (BV)
  • Should Story : les Stories qui possèdent un grand BV
  • Could Story : les Stories qui ont des BV faibles
  • Would Story : les Stories avec les plus petits BV

Scrum Toute de suite !

L'objectif de ce TD programmé à la dernière partie de la journée était d'expérimenter SCRUM à travers un problème simple, il fallait réaliser en deux itérations le prototype d'une plaquette pour l'Agile Tour 2011. On s'était organisé en groupe de 5 personnes au minimum composés d'un PO, d'un ScrumMaster et des développeurs. Pour chaque Sprint on avait 5 minutes pour la planification, 15 minutes pour la réalisation des prototypes papier, 5 minutes de Review et 5 minutes de Rétrospectives.
L'évolution constatée au niveau du second Sprint, enrichi par les Rétrospectives du premier Sprint, n'était pas négligeable. On découvre aisément, avec preuve à l'appuie, que le manifeste Agile n'est pas un simple texte inspiré pour faire le marketing des méthodes Agile.