vendredi 29 février 2008

Techdays 2008 : GreenPepper

Retour d'expérience Méthodes agiles

Session présentée par François Beauregard (GreenPepper Software) et Messaoud Oubechou (Octo Technology)

Un constat simple: beaucoup de documents produits à chaque étape de la vie d'un projet par des personnes différentes avec une compréhension différente entre les spécifications générales, fonctionnelles détaillées, techniques détaillées, les test d'intégration, de non regression...
Comment garder ce volume de documents synchronisés dès lors qu'il y a des modifications? Par un seul référentiel documentaire.
Comment lever l'ambiguité des spécifications? Par l'exemple.
Comment synchroniser ces documents avec le code? En testant ces exemples .

Voici quelques points qu'essayent d'adresser les spécifications exécutables, que ce soit Greenpepper ou d'autres outils comme Fitnesse.
Lever l'ambiguité par l'exemple est une pratique d'eXtreme Programming: fournir au développeur les tests fonctionnels plutôt que de les réserver aux testeurs, qu'il s'agisse de tests de non régression, de tests aux limites, ..
Un seul référentiel documentaire, un wiki en l'occurence, est donc utilisable à la fois par des développeurs, des testeurs, des fonctionnels. Pour cela, il faut avoir une syntaxe utilisable par ces profils différents mais également par un framework de tests.

Les tests peuvent être plus complexes que de simples tables, notamment avec des séquences d'actions ou des collections.

Le wiki en tant qu'outils permet de générer de la documentation, de versionner, de faire des exports à mettre dans un controleur de version type subversion.

Ces outils adressent une autre pratique XP au travers l'intégration continue, que j'avais déjà testé avec Fitnesse. Le bénéfice est de pouvoir livrer souvent une version intègre fonctionnellement.

Nous n'avons pas eu le temps d'avoir une démo de GreenPepper pendant la session mais on peut en trouver une sur le site.
Comme on l'a vu, ces outils s'inscrivent dans une démarche agile en focalisant plus spécifiquement sur la couche spécifications et tests fonctionnelles:
Cette approche améliore la collaboration dans l'équipe. Cependant le retour d'expérience des speakers montre qu'un outils de communication est pertinent lorsqu'il y a déjà de la communication au sein de l'équipe sinon il peut au contraire desservir l'équipe.
Les spécifications executables ne supplantent pas les tests unitaires, elles les complètent.

Les méthodes agiles remettent toujours sur le tapis la question de la contractualisation d'un tel mode de fonctionnement: la réponse principale est de ne pas contractualiser un coût mais un mode de fonctionnement puis une enveloppe budgetaire basé sur une nombre de sprints avec des clauses de sortie à chaque livraison. On peut également lire la présentation d'Aubry Conseil sur le mode forfait et l'agilité.

Cette approche permet de partager les risques entre le client et le fournisseur.
Il est important que comprendre que passer sur des méthodes agiles est impactant et doit s'accompagner d'une conduite du changement et doit lui aussi se traiter par étapes.

Et .Net dans tout ça?
Il existe un pluggin GreenPepper pour valider les tests depuis Visual Studio et pour suivre les résultats via un portail SharePoint.

Quelques livres sur le sujet:
user stories applied - Mike Cohn
Fit for developping software - ward cunningham

un autre retour sur insideIt.

Aucun commentaire:


Laurent Morisseau, auteur de ce blog, pour me contacter