Antoine.Guiral.Info

Jeudi 22/10/09, se tenait à Toulouse une étape de l’agiletour. Plein de conférence, de retour d’expérience, d’atelier et de présentations d’outils (le programme).

Tout d’abord un petit mot sur l’accueil : parfait. (J’avais dit un mot ) Plus sérieusement, nous étions reçus à l’IUT informatique de Blagnac. Bâtiment splendide, deux amphi super confortables. Entre chaque atelier, café, thé, chocolat chaud, jus d’orange et eau à volonté ainsi que viennoiseries le matin et pâtisseries l’après-midi. Un petit tour au RU le midi (là aussi, bien mangé) Bref, que du bonheur. Ceci dit, je n’ai pas fait que manger :p

Au programme :

• atelier : modélisation agile
• conférence : gouvernance agile
• retour d’expérience : scrum sur un projet critique
• conférence : estimations, mesures et indicateurs agiles
• retour d’expérience : les tests dans un projet agile
• retour d’expérience : forfait scrum en équipe distribuée.

Modélisation agile (ou « agile modeling »)

Peut être la déception de la journée, je m’attendais à de nouvelles manières de modélisation de projets informatique. En fait ce fût surtout une présentation d’UML (voir même un cours condensé). Or, on peut avoir deux points de vue vis à vis d’UML. Le premier qui consiste à le mettre en opposition à Merise. On note alors que hormis les diagrammes qui ne sont plus les mêmes, UML est itératif. Le seul lien avec l’agilité (et scrum en particulier)? Je le pense. Parce que même si UML est itératif, il reste ni plus ni moins qu’un paquet de document à rédiger et maintenir. Certes cela fait intervenir la valeur « courage » de l’eXtreme Programming (et il en faut pour maintenir tout les diagrammes ). Mais cela va à l’encontre du principe « individus et interactions plutôt que processus et outils ». Et, vous l’aurez compris, ma pensée penche plutôt de ce coté ci. Attention à ne pas trop dévier le sens de la valeur « courage »…

Gouvernance agile

Première conférence de la journée. A priori plutôt destinée au top management des entreprises. Cependant, de bonnes clés pour la mise en place d’un contexte agile avec une impulsion venant « d’en bas » (bottom-up). De manière générale, la gouvernance agile c’est d’appliquer les valeurs du manifeste agile non seulement à l’équipe mais à toute l’entreprise. Par exemple, de la même manière que dans un projet, le client et l’équipe doivent travailler dans le même sens puisque l’objectif est le même. Le management et l’équipe doivent lier un vrai partenariat puisqu’ils ont un objectif commun : créer de la valeur ajoutée. Une bonne partie de la conférence sur cette question « d’alignement entre les services ». Puis sur les intérêts commun à être agile :

• retours sur investissement au plus tôt (livraisons rapides et régulières)
• investissements au plus tard (ne faire que ce qui est strictement nécessaire)
• application évolutive (qualité du code, test unitaires,…)
• création de valeur ajoutée
• indicateurs de performance
• …

Scrum sur un projet critique

Peut être les points de la journée les plus intéressants : les retours d’expériences. On peut mesurer à quel point on est dans le coup (ou pas…) par rapport à des entreprise qui utilisent depuis peu l’agilité. La criticité du projet se situait à plusieurs points :

• équipe distribuée (Paris / Toulouse)
• projet sensible (gestion d’assurance vie)
• utilisation de prestas pas forcement familiarisés à l’agilité

Le fait que l’équipe soit distribuée n’a pas posé beaucoup de problème. L’utilisation de quelques outils remplaçant le fait d’être dans le même bureau (même si…) :

• skype pour la communication orale (réunion toussa) et les daily scrum
• rally pour la gestion de projet scrum
• svn pour gérer les versions
• basecamp, google docs, wiki pour la communication de l’équipe

Deux extraits interessants :

Le client est intégré dans le dispositif

• participation aux démos, à la rédaction des US
• redéfinition périmètre et/ou fonctionnalités en permanence
• intégration systématique des remarques issues de la démo (sprint suivant)
• intégration exceptionnelle de certaines demandes critiques (en cours de sprint – modification du backlog à chaud)
• insertion des defects issus de la recette directement dans l’outil Rally

Conclusion

• MOE (équipe de réalisation)
  • implication dans toutes les phases du dév et responsabilité
  • charge soutenue et durable
  • justesse et robustesse du projet
• MOA (client)
  • collaboration étroite et efficace
  • respect des attentes fonctionnelles et des délais

Autrement dit : un succès basé sur l’application des méthodes agiles grâce à une relation de confiance entre client et prestataire.

Estimations, mesures et indicateurs agiles

Conférence réalisée par Claude Aubry (un des gourous toulousain de l’agilité, amateur de rugby en plus! bon ok c’est presque un pléonasme..), juste après manger : grosse perf’ pour tenir un auditoire en éveil! Ce que j’en retiens, c’est principalement l’utilité de…l’utilité. Quand on utilise scrum on se penche plutôt sur les indicateurs tels que la vélocité, les points de story (un peu liés les deux quand même),.. voir même, au delà des indicateurs, sur les rituels et le vocabulaire lié à la méthode (scrum, release, features, daily scum/meeting (ou encore stand up), user story, backlog, burn up/down, point, planning poker, revue de sprint, sprint, rétrospective de sprint,etc…). Alors qu’on passe presque à coté de l’essentiel (sans l’oublié pour autant, puisqu’il y a toujours « priorisation » des stories) : l’utilité (je préfère utilité à valeur ajouté, ca fait moins business, plus centré sur l’utilisateur).

Donc, plus qu’une simple priorisation, on parle vraiment d’un pilotage par l’utilité. Avec, au moment des planification, un « utility poker » (similaire au planning poker, les rôles nécessaires étant différent même si le plus, le mieux) qui vise à ordonnancer features par utilité relative.

Ensuite, il devient facile d’identifier les priorités en plaçant les features sur un graphique (taille en abscisse, utilité en ordonné). Deux cas triviaux :

• à utilités égales, la feature la plus petite sera la plus prio.
• à tailles égales, la feature la plus utile sera la plus prio.

Bref, l’impression d’avoir franchi un cap en ce début d’aprem, merci

Les tests dans un projet agile

Dans l’agilité plus qu’ailleurs, on porte de l’importance à la qualité de ce que l’on produit (attention! je n’ai pas dit que les autres n’y font pas attention ). La raison principale est que pour pouvoir répondre rapidement au changement (d’une itération à l’autre) et pour limiter les docs il faut avoir un code super méga hyper ultra-maintenable. Et là, ben il n’y a pas 15 façon d’y parvenir, il faut automatiser les tests. C’est ce que nous a expliqué Arielle Ruellé durant ce retour d’expérience. Elle différencie 2 types de test :

• les tests unitaires, ceux réalisés par les développeurs (voir le TDD)
• les tests d’acceptations.

Sa prez’ s’étendait plus longuement sur les tests d’acceptations. On pourrait aussi les appeler tests fonctionnels. Ce sont ceux qui vont être rédigé avec le product owner (a minima) au moment de la constitution du backlog (bien sûr on peut en rajouter a posteriori). Apparait alors un nouveau rôle, ou une nouvelle fonction dans l’équipe : le ou les testeur(s). Ils vont être charger de réaliser ces tests fonctionnels (la recette?) et de les automatiser (imaginez un peu apres 4/5 itérations…). Les testeurs font donc partis intégrante de l’équipe, avec tout ce que cela importe…communication!

Après, je ne sais pas si c’est appliquable dans toutes les structures…imaginons une équipe de 3 dev, un testeur à temps plein représente 25% du coût de l’équipe. Difficile à faire passer dans le cadre d’une petite structure et encore plus pour un produit en propre. Même si je pense qu’il vaut mieux en faire un peu moins mais mieux…on en revient à l’utilité Peut être un début d’équation? Qualité + Utilité = Victoire (pas encore trouvé mieux pour le « Victoire » :p) Efficacité (merci Chris ).

Forfait scrum en équipe distribuée

Nicolas nous a présenté comment sur un projet en scrum, ils ont pu mettre en place un fonctionnement au forfait (c’était la conclusion de mon rapport de stage, dommage il est classé top secret ). Petite mise en situation : équipe sur deux sites, l’une agile l’autre non mais ouverte et motivée. Beaucoup d’échange et de confiance puisque le principe était le suivant :

• un contrat basé sur 3 itérations
• facturation à la fin de chaque itération
• contrat résiliable à la fin de chaque itération.

Cela peu paraître « fou » à première vue. Cependant, j’y trouve plusieurs intérêts :

• on se rapproche du « win fast, fail fast »
• le client sait pourquoi il paie
• cela ne coute pas plus cher à l’entreprise (dans le cas d’une sous estimation initiale)
• cela ne coute pas plus cher au client (dans le cas d’une sur-estimation initiale)
• cela pousse vers l’excellence : si on veut que le client continue il faut être bon, le meilleur.

Voilà, plus qu’un pari, c’est une question d’alignement : le client et le prestataire unis par les liens sacrés de la réussite (huhu facile celle là).

Claude en parle très bien ici : retour sur un projet au forfait en scrum.

Pour conclure

Une très bonne expérience à renouveler.

Rassuré sur mon « niveau » en agilité.

De nouvelles clés pour continuer à « évangéliser » .

Et vous, agile? pas agile?

PS : les prez’ dispo sont ici : sigmaT