2008, l'envol de l'agilité

Ce rite quotidien constitue un point de rencontre entre tous les membres de l’équipe pour garder la focalisation sur l’objectif du sprint en cours.

Hier soir à Labège, avec bières et flammeküches, nous avons préparé le programme du cinquième séminaire sur les méthodes agiles de Toulouse.

Finalement, après avoir délibéré, nous proposerons uniquement des retours d’expérience sur la mise en œuvre de méthodes agiles. Quatre. Ce qui est bien : ça veut dire qu’il y en a des expériences.

Cette importance de l’humain est bien connue mais pas toujours appliquée dans nos organisations hiérarchiques. Les méthodes agiles cherchent à favoriser absolument cette idée de collectif, à travers, notamment, les réunions et les travaux en groupe. Comment savoir si ça fonctionne ? Evaluez votre niveau…

Dans les applications Web, il existe souvent un rôle secondaire qui a accès à des informations seulement en lecture et qui a besoin d’une ergonomie particulière, soit parce que les personnes qui jouent le rôle ne sont pas expertes dans l’utilisation de l’outil informatique, soit parce que les informations doivent constituer un tableau de bord facilement lisible et permettre d’avoir une vue synthétique. L’ergonomie est essentielle et fait que ces exigences ne sont pas des histoires comme les autres.

Un test, c’est une expérimentation menée pour révéler des informations, ou en réponse à une question précise sur un logiciel ou un système.

Dans le cadre d’une approche agile basée sur les histoires d’utilisateur (user stories), un test d’acceptation est un test qui permet au client (ou au Product Owner) de dire s’il accepte, en fin d’itération, une histoire d’utilisateur développée par l’équipe. Un test est accroché à une story, qui en possède généralement plusieurs.

Pour décrire les tests d’acceptation, ma préférence va à une technique orientée comportement, le BDD.

Mercredi, lors de la réunion de planification du sprint que j’animais, nous avons inclus dans le sprint plusieurs spikes. On utilise un spike pour mener des travaux d’étude, d’exploration technique d’un élément (user story) du backlog.

Par Infoq, je viens de lire un article Well Formed Teams and Agile: An Opportunity to Thrive qui définit 3+2 attracteurs pour penser efficacement et constituer des équipes hyper-productives, comme dit Jeff Sutherland.

Les SigmaT sont destinés aux personnes qui pratiquent les méthodes agiles mais aussi à celles qui ne le font pas encore et souhaitent s’y mettre. Cela se passe à Toulouse, mais au delà des Toulousains, les SigmaT accueillent des participants du grand Sud-Ouest : le 28 mars, nous aurons des visiteurs de Montpellier et Bordeaux ainsi que de Montauban.

Les SigmaT abordent l’agilité sous toutes ses facettes et s’adressent à toutes les personnes impliquées dans le développement ou le management des projets. Ils incluent également l’aspect enseignement avec la participation d’étudiants qui apprennent les Méthodes Agiles et les appliquent sur leurs projets.

Au cours du sprint, bien avant la fin, l’équipe a produit un build, permettant de passer des tests d’acceptation. Le product owner (ou un testeur) a du temps pour tester ce build. Le problème, c’est qu’il n’est pas physiquement proche des développeurs quand il utilise le build et passe ces tests. C’est dommage mais that’s life.

Je fais partie d’un club de tarot et j’y joue les vendredis soirs.

Nous avons eu une partie qui a engendré de nombreuses discussions enflammées. André prend une garde, il récupère 2 atouts au chien. C’est lui qui entre. Atout, du 13. Juste après lui, Bernard met le 20. Derrière Pierre met un petit atout et moi aussi. Bernard fait donc le pli et rejoue dame de coeur. Pierre a en main 6 coeurs dont le roi. A votre avis, que doit-il jouer ?

Il se trouve que Pierre n’a pas mis son roi et qu’André a fourni. Bernard a fait le pli avec la dame et été obligé de faire une nouvelle entrée. André a fait le pli et a rejoué atout, prenant le petit de Bernard.

Une discussion récente avec un acheteur d’une grande administration m’a conforté dans l’idée que le contrat au forfait n’est pas un obstacle à l’introduction de l’agilité. Au contraire, l’agilité apparaît comme une voie à suivre pour éviter les difficultés rencontrées dans les contrats actuels.

Voici un petit résumé des quelques idées que je lui ai présentées, reprises de ma contribution au livre de Véronique Rota :

Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l’hypothèse d’une équivalence entre les tests et les exigences.

La connaissance attendue de Scrum n’est pas la même pour des personnes qui participent à un projet que pour celles qui le suivent et, dans une équipe qui applique Scrum, pour un ScrumMaster que pour un simple membre de l’équipe. La stratégie de formation doit tenir compte des rôles et des projets.