Presentation Rex Methodes Agiles

3,716 views

Published on

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

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,716
On SlideShare
0
From Embeds
0
Number of Embeds
380
Actions
Shares
0
Downloads
53
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Presentation Rex Methodes Agiles

  1. 1. Open-REX – Utilisation des méthodes agiles 25/03/2010 Clément BERTHELOT
  2. 2. Licence dutilisation• 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 dune maniere qui suggérerait quils 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 lautorisation du titulaire des droits sur cette œuvre. – Rien dans ce contrat ne diminue ou ne restreint le droit moral de lauteur ou des auteurs.
  3. 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 lagile• Focus sur une itération en mode agile – Principales phases dune itération – Organisation de léquipe MOE – Les outils• Retour sur lutilisation des méthodes agiles – Au fil des itérations – Les phases de livraison
  4. 4. Présentation du projet• Portail web dun grand opérateur dinternet et des annuaires – Gestion des produits – Gestion de leurs comptes – Suivi des audiences de leurs produits – Informer les professionnels de lentreprise• 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. 5. Organisation de léquipe
  6. 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 dintégration continue fonctionnelle
  7. 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 litération
  8. 8. Les phases du mode agile• Schéma du cycle dune itération
  9. 9. Les phases du mode agile• Quelle durée pour une itération ?• Plus cest court, plus cest bon – Vrai au début – 1 semaine pendant la phase dinitiation – Permet de répéter rapidement les différents rituels de lagile• Ensuite, nous sommes passés sur 15 jours
  10. 10. La présentation des User Stories• Ensemble limité dexigences 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 dEtude• Toute US est livrée avec un lot de tests automatisés souhaités par la MOA
  11. 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. Cest la vélocité qui varie• La complexité est évaluée par toute la MOE
  12. 12. Choix des US par la MOE• Cest la MOE qui « choisit » le nombre de US quelle peut traiter (en respectant la priorisation MOA)• La MOE sengage 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 dadministration, Mise en place dune PIC, amélioration de performances, ...• Répartition des tâches dans léquipe – Faire tourner les sujets, binomage, ...
  13. 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. 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. 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 quil a fait hier, ce quil prévoit de faire aujourdhui, sil 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. 16. Agile au quotidien – Les outils• La météo du projet avec Hudson.
  17. 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. 18. Agile au quotidien – Les outils - yaml
  19. 19. Agile au quotidien – Les outils - yaml• Classe de mapping DTOYml
  20. 20. Agile au quotidien – Les outils - yaml• Exemple de bouchon – Méthode remplaçante du service réel
  21. 21. Agile au quotidien – Les outils - yaml• Exemple de bouchon – Méthode de lecture du fichier yaml
  22. 22. Agile au quotidien – Les outils - yaml• Exemple de bouchon – Mapping vers lobjet reel
  23. 23. Agile au quotidien – Les outils - yaml• Exemple de classe Manager
  24. 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 lenvironnement de démo (données AMOA)• Possibilité de switcher entre environnements bouchon ou réel par fichier properties. Utilisation de Managers
  25. 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 dagrégation de données – lIHM 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 soccupe de la recette – Question a se poser avant lécriture dun test : • La répétition manuelle de ce test en recette sera-t-elle toujours plus rapide que le temps passé a lautomatiser ? • 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. 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. 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. 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 lAMOA
  29. 29. Agile au quotidien – Les outils - GP• Grammaire specifique au projet
  30. 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 lAMOA – injection des données utiles et exécution dans un environnement fermé.
  31. 31. Fin ditération - Démo• Préparation de la démo – Vérification sur la PIC des exigences demandées avec lAMOA 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 lité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 litération – Report de la complexité dans le burndown chart
  32. 32. Burndown chart
  33. 33. Fin ditération - Rétrospective• Note ditération → humeur de léquipe• Annonces du pilote du projet• Keep/drop/start/ ?
  34. 34. Fin ditération - Rétrospective• Note ditération → humeur de léquipe• Annonces du pilote du projet• Keep/drop/start/ ?• PDCA• Exemple daction a suivre: – Chaque développeur relit avec lAMOA concernée par la US les exigences demandées avant de passer la US a « FAIT »
  35. 35. Fin de sprint - Livraison• Par la livraison de chaque sprint, le mode agile doit permettre daller en production avant louverture de service. – Éprouver les processus de mise en production – Ouverture de flux• Difficulté majeure : – Lintégration, la recette, la préprod et la prod sont faites par trois équipes différentes → Nécessité davoir des processus clairs et dautomatiser 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. 36. Ma conclusion sur lutilisation de lagile• Les avantages – Dév au fil de leau → Idées de la MOA encore fraiches – Peu de gros bugs livrés – La majorité des développeurs connaissent bien plus que ce quils 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 lagilité au dela du plateau de dév.

×