Vendredi dernier a eu lieu le 10ème séminaire sur les méthodes agiles organisé par la SigmaT. Au programme, nous avons eu le droit à :

• une réflexion sur l’approche Model Driven et l’agilité
• une présentation de la gouvernance agile d’une organisation
• un retour d’expérience sur les tests dans un projet agile

Des news de la SigmaT – Claude Aubry

Claude commence le séminaire par quelques chiffres concernant la SigmaT

• 10 : 10ème séminaire (depuis décembre 2006)
• 37 : adhérents à l’association
• 40 : inscrits aujourd’hui
• 89 : taux de satisfaction des développeurs qui ont essayé l’agilité (résultat d’une enquête à paraître)
• 1 : la 1ère présentatrice à un SigmaT

Agile Model Driven – David Brocard et Romain Bernard

Les principes du Modèle Driven

Romain attaque cette présentation en rappelant que le Model Drive (MD) ne se réduit pas au Model Driven Architecture (MDA) même si cela en est la version la plus documentée. MDA c’est des pratiques lourdes largement dominées par l’aspect commercial.

Le MD, c’est l’utilisation de modèles qui seront :

• exploitable immédiatement
• adapté aux processus de résolution de problèmes
• exploitable automatiquement par des composants MD (des générateurs de codes par exemple). Ces composants permettent de capitaliser l’expertise.

Aux principes de base du MD, Romain rajoute trois principes clés :

• Adaptation : s’adapter au contexte en définissant des Domain Specific Language (DSL) et des composants MD dédiés. Le DSL permet de définir le bon vocabulaire pour décrire le domaine, il sera la base pour décrire le système.

  Les composants MD sont des générateurs de code ainsi que les vérificateurs, simulateurs, transformateurs, etc. Romain précise que dans sa vision du MD, le code généré n’est pas figé, il est possible (et prévu) de le modifier. En fait, la génération produit 70-100% des fichiers nécessaires.

  Cette adaptation est l’une des différences majeurs avec le MDA. Le MDA passe par des outils non spécifiques et génériques, qui nécessitent donc des phases d’adaptation pour faire rentrer les modèles du contexte dans les concepts que savent manier les outils du MDA. Dans l’approche de Romain, on construit ses propres outils spécifiquement adaptés au contexte.

• Simplicité : besoin de plus d’explication ? :)

• Agilité : il ne s’agit pas de l’agilité dont on parle habituellement ici. Dans la cadre du MD, l’agilité c’est le fait de se permettre de faire évoluer les générateurs et l’appli. La démarche classique est plus figé, un tampon est souvent nécessaire sur les générateurs avant d’arriver à la phase de dev. Ils n’est alors plus question de modifier les outils.

Intégrations dans les concepts agiles

David reprend la parole pour voir comment tout cela s’intègre dans un contexte agile. À partir du tableau des valeurs défini par XP, il étudie les points clés.

• Communication : les principes agiles restent applicables. Ils en sont même facilités et formalisés par le modèle et les DSL. L’important c’est de ne pas considérer le modèle comme de la doc, mais comme du code en devenir.
• Conception/refactoring/modif : les incréments peuvent se faire selon deux axes : la technique (générateur, composant md) et le modèle. David explique que ces deux axes peuvent être attaqués en parallèle (par deux équipes mêmes).
• Qualité du code : le code est majoritairement généré. Si le générateur fait bien sont boulot, alors il n’y a pas de soucis.
• Propriété collective : DSL et générateur doivent être vus comme du code comme un autre.

Conclusion

Une première conclusion par Romain : cette approche permet de créer rapidement de la valeur. Elle a également l’avantage de pouvoir être intégrer progressivement, en remplacement d’un autre, un élément/couche après l’autre pour diminuer la prise de risques. Cette approche est intéressante/rentable dès que l’on a plusieurs fois le même type de chose à faire.

La conclusion de David sera que le MD est au service de l’agilité et pas en conflit.

Ma conclusion

Bon… je ne connaissais pas vraiment ce qui se cachait derrière le Model Driven. La présentation de Romain m’aura fait un point sur les grande lignes. Après, son rapport à l’agilité… bof… Ce que je veux dire c’est que l’Agilité est soluble dans tout, c’est juste une façon de prendre les choses. Dans le même esprit, Jeff Sutherland présentera ‘Scrum in church’ à Agile 2009. À partir de là, il n’y a pas de raison que ça ne marche pas non plus avec le Model Driven, après encore faut il le vouloir et être prêt à mettre en place ce qu’il faut pour y parvenir.

Gouvernance Agile – Thierry Cros

##Gouvernance ? Thierry commence par nous dire un peu ce qu’est la gouvernance. A ce que j’en ai compris, c’est l’ensemble des relations et structures mises en oeuvre pour que l’outil informatique soit au service de la société¹. Ca paraît simple comme ça, mais noyé dans le contexte d’une DSI avec des contraintes budgétaires, juridiques, de time to market… on voit vite le paquet de noeuds que ça peut devenir.

##Agile ? Thierry revient ensuite sur les bases fondamentales de l’agilité :

• l’équipe : la collaboration quotidienne entre dev et utilisateur, rythme de livraison viable, auto-organisation, communication face à face.
• planification : livraison régulière au plus tôt, accepter les changements, livrer une appli qui fonctionne

Il résume la science de l’économie agile en 2 clés :

• ROI au plus tôt
• investissement au plus tard

##Gouvernance Agile Tout cela finalement n’est qu’une question d’alignement. Alignement dans le sens harmonie, aller dans le même sens. Alignement de la DSI, des équipes, des outils. Et finalement, une DSI agile ça doit être faisable.

La différence peut-être, c’est la clé de l’agilité : ‘‘Les personnes et les interactions sont plus importantes que les processus et les outils’’. Pour le dire autrement :’‘Les personnes et les interactions sont plus importantes que les processus et les outils’’, voir même :’‘Les personnes et les interactions sont plus importantes que les processus et les outils’’.

Alors, le passage à l’agilité d’une DSI, ça implique quoi ?

• livraison : passer de 2 mises en exploitation par an à 4. De gros impacts sur les équipes d’exploitations, sur les utilisateurs qui ne veulent/peuvent pas forcement se former aussi régulièrement.
• manuel : un manuel qualité en constante évolution
• il faut passer de la vue projet (une fois finie, on y touche plus à part la maintenance) au produit (en constante évolution)

##Conclusion En fait, cela va au-delà du dev et de la DSI. C’est au niveau de l’organisation que tout cela se passe.

Test dans un projet agile – Arielle Ruellé (Anywhere Technology)

Arielle est responsable des tests chez Anyware Technology. Elle nous explique comment ils ont intégré les tests dans l’équipe de développement en utilisant SCRUM.

Les rôles !

• Product Owner : il écrit toutes les user stories ainsi que les smoke tests. Pour chaque user story, il s’agit de la description de la fonctionnalité. C’est le premier niveau de test.
• Le dev : il écrit et exécute les tests unitaires. Les tests sont lancés automatiquement sur une machine d’intégration continue (qui utilise Hudson)
• Responsable équipe test : spécifie les tests d’acceptation. Elle organise l’équipe de test et produits les rapports de test. Elle travaille en collaboration avec le PO sur la définition des user stories (pour les rendre testable).
• Testeurs : exécutent les tests. Les testeurs sont des membres de l’équipe Scrum. L’équipe compte 12 personnes dont 3 testeurs. Ils participent à toutes les cérémonies.

Organisation des tests

• pendant une release :
  • à l’itératioin N-1 : écriture des cas de tests pour les US prévues à l’itération N. Cette opération est complexe car le backlog est vivant :) Ces cas de tests pourront ainsi être fournis aux devs lorsqu’ils commenceront le développement.
  • itération N :
    • exécution des tests : les bugs trouvés sont ajoutés directement comme tâches dans le sprint pour la US concernée. Une fois corrigé, le test est réexécuté pour vérifier la correction.
    • écriture des tests automatiques et des tests de charge
    • test de non regression : réexécution tous les tests des itérations précédentes
    • génération du rapport de test
  • la dernière itération : on rejoue tous les test automatiques + tous les tests de charges

Test d’acceptation

• smoke test = le comment démontrer du backlog
• rajout des cas de test. Il s’agit surtout de vérifier que tous les cas d’erreur sont correctement gérés.
• les cas de test sont stockés dans un wiki confluence. Pour chaque tests, le rapport (stockés dans le wiki) contient : le numéro de l’itération, US, cas de test, pré requis, action, résultat Le document de rapport de test peut potentiellement être fourni au client.

Campagnes de test

Chaque User Story fait l’objet d’une campagne de test. Les bug relevés sont ajoutés aux tâches. Quand ils sont corrigés, une deuxième campagne est lancé. Quand tous les tests passent, ils sont scriptés pour pouvoir être rejoués automatiquement.

Pour gérer tout cela, TNT est utilisé (une intégration entre JIRA et Confluence).

Tests de charge

Les métriques sont définis avec la direction des opérations : CPU / tps de réponse / nb de requêtes / données reçues/envoyées / … ². Ils sont réalisés en étroite collaboration avec les dev qui connaissent bien les points critiques.

Rapports de test :

A chaque itération, un rapport est présenté contenant, par US, le nombre de tests et les pourcentages de réussite/échec. Si il y a des tests en échec, la US n’est pas considérée comme fini. Le rapport contient également les résultats des tests de non régression. Les bugs issus de ces tests sont reportés à l’itération suivante.

##Conclusion La technologie (FLEX) utilisée empêche encore d’automatiser complètement les tests. L’idéal serait de pouvoir les scripter directement dans le code pour qu’ils soient rejoués par l’outil d’intégration continue. Les bugs relevés pendant l’itération doivent être traités dans l’itération, ce n’est pas encore le cas mais ça progresse.

L’un des points importants que relève Arielle c’est le travail collaboratif entre le test et l’équipe de dev. Test et dev travaillent ensemble pour faire avancer le produit, le test n’est pas là pour casser le travail des devs.

Ma conclusion

Un très intéressant retour d’expérience à mon avis. Dans la pratique, les tests³ sont souvent un cas épineux à gérer dans une mise en place de Scrum. Dans ‘‘Scrum and XP from the trenches’’ Kniberg évoque ce problème et botte honteusement en touche. Arielle nous a présenté une intégration des tests dans l’équipe de dev qui fonctionne et ça fait plaisir à voir. D’autant qu’elle est très simple et pourra s’appliquer dans beaucoup d’endroit.

Agile Tour 2009 – Equipe d’organisation de Toulouse et Bordeaux

Toulouse

L’étape Toulousaine de l’Agile Tour 2009 se tiendra le 22 octobre. Elle sera hébergée par l’IUT Blagnac - Université Toulouse II. Cette année, le séminaire se déroulera sur la journée entière.

Si vous souhaitez sponsoriser cette édition toulousaine, c’est le bon moment pour contacter les organisateurs au SigmaT⁴

Bordeaux

Nouvelle venue dans ce tour, Bordeaux accueillera, pour une demi-journée, une étape le 29 octobre.