Présentation Ippon Technologies Rex Méthodes Agiles du jeudi 25/03/2010 www.ippon.fr blog.ippon.fr

1. Open-REX – Utilisation des méthodes agiles
25/03/2010
Clément BERTHELOT

2. Licence d'utilisation
• Cette présentation vous est fournie sous licence Creative Commons
Attribution Share Alike
• Vous etes libres :
– De reproduire, distribuer et communiquer cette création au public
• Selon les conditions suivantes :
– Paternité. Vous devez citer le nom des auteurs originaux mais pas d'une
maniere qui suggérerait qu'ils vous soutiennent ou approuvent votre
utilisation de l'œuvre.
– A chaque réutilisation ou distribution de cette création, vous devez faire
apparaitre clairement au public les conditions contractuelles de sa mise a
disposition sous licence identique Creative Commons Share Alike.
– Chacune de ces conditions peut etre levée si vous obtenez l'autorisation
du titulaire des droits sur cette œuvre.
– Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur
ou des auteurs.

3. Open-REX – Utilisation des méthodes agiles
• Contexte du projet
– Présentation rapide du projet
– Organisation de l'équipe projet
– Quelques pré-requis pour faire de l'agile
• Focus sur une itération en mode agile
– Principales phases d'une itération
– Organisation de l'équipe MOE
– Les outils
• Retour sur l'utilisation des méthodes agiles
– Au fil des itérations
– Les phases de livraison

4. Présentation du projet
• Portail web d'un grand opérateur d'internet et des
annuaires
– Gestion des produits
– Gestion de leurs comptes
– Suivi des audiences de leurs produits
– Informer les professionnels de l'entreprise
• Application tres évolutive
– Mise en production tous les 3 mois
– Besoin tres changeant; nécessité de reprioriser fréquemment les
tâches a faire
– De nombreux partenaires
• Organisation de l'équipe

5. Organisation de l'équipe

6. Quelques pré-requis
• Une équipe motivée et acceptant de changer les habitudes
• Des processus clairs, établis par tous et connus de tous
• Une MOE et une AMOA tres rapprochées
• Une plateforme d'intégration continue fonctionnelle

7. Les phases du mode agile
• Quelques définitions de base :
– Chaque livraison en recette est un sprint
– Un sprint est une succession de n itérations
– Une itération débute par une présentation de User Stories et se
termine par une rétrospective de l'itération

8. Les phases du mode agile
• Schéma du cycle d'une itération

9. Les phases du mode agile
• Quelle durée pour une itération ?
• Plus c'est court, plus c'est bon
– Vrai au début
– 1 semaine pendant la phase d'initiation
– Permet de répéter rapidement les différents rituels de l'agile
• Ensuite, nous sommes passés sur 15 jours

10. La présentation des User Stories
• Ensemble limité d'exigences qui répondent a un besoin
spécifique
– En tant que « utilisateur », je veux « action » pour « resultat »
• Chaque US a une valeur métier MOA et une complexité
estimée (estimation grosse maille) par le TechLead et le
Bureau d'Etude
• Toute US est livrée avec un lot de tests automatisés
souhaités par la MOA

11. Evaluation de la complexité
• Pas d'évaluation en jours/homme (trop dépendant de la
personne qui va développer)
• Deux nouveaux indicateurs
– La complexité
• 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ?
– La vélocité
• Nombre de points réalisés pendant une itération
• Principe : une tâche a la meme complexité pendant toute
la durée du projet. C'est la vélocité qui varie
• La complexité est évaluée par toute la MOE

12. Choix des US par la MOE
• C'est la MOE qui « choisit » le nombre de US qu'elle peut
traiter (en respectant la priorisation MOA)
• La MOE s'engage a terminer les US choisies
– Définir ensemble MOA/MOE ce que « terminé » signifie
– Ex : commité, tests unitaires OK, couverture de test OK, tests
fonctionnels automatisés OK, Environnement de démonstration
bouchonné, ...
• Prise en compte des tâches techniques supplémentaires
– Ex : Portlets d'administration, Mise en place d'une PIC,
amélioration de performances, ...
• Répartition des tâches dans l'équipe
– Faire tourner les sujets, binomage, ...

13. Agile au quotidien – Organisation plateau
• Le backlog indexe toutes les US
• Les US sont documentées dans un wiki, accompagnés des
tests de recette
• Toute évolution est faite sous forme de US
• Tout bug est répertorié dans un bugtracker
• Les tableaux post-it
– Road map
– Tableau de suivi
– Planning de livraison
– Zoom suivi MOE
• Question : de quels tableaux se sert-on vraiment ?

14. Agile au quotidien – Organisation plateau
• De quels tableaux se sert-on vraiment ?
– Road map [AMOA]
– Tableau de suivi [personne]
– Planning de livraison [tout le monde]
– Zoom suivi MOE [MOE]
→ Presque tous
• Quels avantages
– Une vision du projet en grand format partagée par tous
– Facile de gérer le travail a faire de l'équipe sur une itération

15. Agile au quotidien – Organisation MOE
• Ensemble des tâches affichées sur le tableau de suivi
– Zoom détaillé sur les tâches MOE proche de l'équipe
• Stand-up meeting tous les matins
– Uniquement MOE + coach AMOA si une annonce a faire
– Chaque développeur indique ce qu'il a fait hier, ce qu'il prévoit de
faire aujourd'hui, s'il rencontre des problemes
– Proposition de binomage (Diffusion de la connaissance, meilleure
ambiance)
– Tres bon suivi au quotidien pour le TechLead et le chef de projet

16. Agile au quotidien – Les outils
• La météo du projet avec Hudson.

17. Agile au quotidien – Les outils
• Les Tests Unitaires
– Implémentation fake de tous les services extérieurs et des services
Liferay « service buildé »
– Services bouchonnés au plus proche de la réalité
• Bases de données de test
• Fichiers xml ou html pour les requetes http
• Utilisation de yaml pour les webservices

18. Agile au quotidien – Les outils - yaml

19. Agile au quotidien – Les outils - yaml
• Classe de mapping DTOYml

20. Agile au quotidien – Les outils - yaml
• Exemple de bouchon
– Méthode remplaçante du service réel

21. Agile au quotidien – Les outils - yaml
• Exemple de bouchon
– Méthode de lecture du fichier yaml

22. Agile au quotidien – Les outils - yaml
• Exemple de bouchon
– Mapping vers l'objet reel

23. Agile au quotidien – Les outils - yaml
• Exemple de classe Manager

24. Agile au quotidien – Les outils
• Les Tests Unitaires
– Implémentation fake de tout les services extérieurs et des services
Liferay « service buildés »
– Services bouchonnés au plus proche de la réalité
• Bases de données de test
• Fichiers xml ou html pour les requete http
• Utilisation de yaml pour les webservices
• Les bouchons ont une double utilité
– Bouchons pour les tests unitaires
– Bouchons pour l'environnement de démo (données AMOA)
• Possibilité de switcher entre environnements bouchon ou
réel par fichier properties. Utilisation de Managers

25. Agile au quotidien – Les outils
• Les tests fonctionnels automatisés avec GreenPepper
– Tests écrits en collaboration MOE/AMOA
– Fixtures GP rédigées dans un wiki et transformées en java
– Tests principalement selenium [Projet d'agrégation de données –
l'IHM permet de valider un grand nombre de regles fonctionnelles]
• Attention :
– On ne peut pas tout tester, mais ça réduit la charge de l'équipe qui
s'occupe de la recette
– Question a se poser avant l'écriture d'un test :
• La répétition manuelle de ce test en recette sera-t-elle toujours plus
rapide que le temps passé a l'automatiser ?
• Cette fonctionnalité ne sera-t-elle pas déja testée autrement ?
• Fonctionnement basique de GP
– Ecriture des fixtures grâce a quelques mots clés

26. Agile au quotidien – Les outils - GP
• Do with : permet de créer une fixture = un test java
• Check : Vérifie une ou plusieurs valeur
• List of : permet au check de tester une liste de valeur

27. Agile au quotidien – Les outils - GP
• Do with : permet de créer une fixture = un test java
• Check : Vérifie une ou plusieurs valeurs
• Set of : permet au check de tester un ensemble de valeurs

28. Agile au quotidien – Les outils
• Les tests fonctionnels automatisés avec GreenPepper
– Tests écrits en collaboration MOE/AMOA
– Fixtures GP rédigées dans un wiki et transformées en java
– Tests principalement selenium
• Fonctionnement basique de GP
– Ecriture des fixtures grâce a quelques mots clés
– Enrichissement par notre propre grammaire complémentaire
• Plus simple pour l'AMOA

29. Agile au quotidien – Les outils - GP
• Grammaire specifique au projet

30. Agile au quotidien – Les outils
• Les tests fonctionnels automatisés avec GreenPepper
– Tests écrits en collaboration MOE/AMOA
– Fixtures GP rédigées dans un wiki et transformées en java
– Tests principalement selenium
• Fonctionnement basique de GP
– Ecriture des fixtures grâce a quelques mots clés
– Enrichissement par notre propre grammaire complémentaire
• Plus simple pour l'AMOA
– injection des données utiles et exécution dans un environnement
fermé.

31. Fin d'itération - Démo
• Préparation de la démo
– Vérification sur la PIC des exigences demandées avec l'AMOA
concernée
– Déploiement sur une machine spécifique a partir de la PIC
– La machine de démo servira de plateforme de test, bouchonnée
avec les données de la MOA pendant l'itération suivante
– Présentation démo dans la MOE pour partage de connaissances
• Démo + Ptit dej = tout le plateau réuni
– US pour validation / US pour background avancement
– Validation des exigences MOA
– Calcul du niveau de complexité développé sur l'itération
– Report de la complexité dans le burndown chart

32. Burndown chart

33. Fin d'itération - Rétrospective
• Note d'itération → humeur de l'équipe
• Annonces du pilote du projet
• Keep/drop/start/ ?

34. Fin d'itération - Rétrospective
• Note d'itération → humeur de l'équipe
• Annonces du pilote du projet
• Keep/drop/start/ ?
• PDCA
• Exemple d'action a suivre:
– Chaque développeur relit avec l'AMOA concernée par la US les
exigences demandées avant de passer la US a « FAIT »

35. Fin de sprint - Livraison
• Par la livraison de chaque sprint, le mode agile doit
permettre d'aller en production avant l'ouverture de
service.
– Éprouver les processus de mise en production
– Ouverture de flux
• Difficulté majeure :
– L'intégration, la recette, la préprod et la prod sont faites par trois
équipes différentes
→ Nécessité d'avoir des processus clairs et d'automatiser le plus
de traitements possible
– Pb : pour résoudre de nombreux problemes lors des mises en
préprod/prod la MOE devrait avoir beaucoup de droits sur un grand
nombre de machines → Droits impossibles a obtenir et énorme
perte de temps lors des mises en production

36. Ma conclusion sur l'utilisation de l'agile
• Les avantages
– Dév au fil de l'eau → Idées de la MOA encore fraiches
– Peu de gros bugs livrés
– La majorité des développeurs connaissent bien plus que ce qu'ils
ont développé
– Avancement régulier et visible du projet
– Communication facilitée. Problemes rapidement remontés au plus
haut niveau de hiérarchie
– Conception émergente – on fait au plus simple
• Les inconvénients
– Environnements de développement complexe
– Conception émergente – refactoring parfois dangereux
– Rythme différent de celui de beaucoup de partenaires
– Difficultés a amener de l'agilité au dela du plateau de dév.