Télécharger en tant que PDF, PPTX
![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](https://image.slidesharecdn.com/presentation-rex-methodesagiles-100328143712-phpapp01-111020083746-phpapp01/85/Presentation-Rex-Methodes-Agiles-14-320.jpg)
![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](https://image.slidesharecdn.com/presentation-rex-methodesagiles-100328143712-phpapp01-111020083746-phpapp01/85/Presentation-Rex-Methodes-Agiles-25-320.jpg)
Téléchargé parIppon
Presentation Rex Methodes Agiles
La présentation aborde l'utilisation des méthodes agiles dans le cadre d'un projet de portail web pour un opérateur d'Internet, avec un focus sur l'organisation de l'équipe et les phases d'itération. Elle met en avant les avantages, tels qu'une meilleure communication et une visibilité accrue sur l'avancement du projet, tout en reconnaissant des défis comme la complexité des environnements de développement et le besoin d'intégration claire. Des outils pour la gestion agile, ainsi que des méthodes de tests et de suivi, sont également détaillés pour illustrer le processus.
Contenu connexe
Similaire à Presentation Rex Methodes Agiles
![[Scrum Day 2011] Outillage Agile dans un environnement Microsoft](https://cdn.slidesharecdn.com/ss_thumbnails/prsentationscrumday2011-111121122132-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Presentation Rex Methodes Agiles
- 1. Open-REX – Utilisationdes 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 – Utilisationdes 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.
- 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 dumode 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 dumode agile • Schéma du cycle d'une itération
- 9. Les phases dumode 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 desUser 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 lacomplexité • 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 USpar 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.
- 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 surl'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.