presentation rex methodes agiles

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

Upload: ippon-technologies

Post on 14-Jun-2015

2.542 views

Category:

Documents


1 download

DESCRIPTION

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

TRANSCRIPT

Page 1: Presentation Rex Methodes Agiles

Open-REX – Utilisation des méthodes agiles

25/03/2010

Clément BERTHELOT

Page 2: Presentation Rex Methodes Agiles

• 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.

Licence d'utilisation

Page 3: Presentation Rex Methodes Agiles

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

Page 4: Presentation Rex Methodes Agiles

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

Page 5: Presentation Rex Methodes Agiles

Organisation de l'équipe

Page 6: Presentation Rex Methodes Agiles

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

Page 7: Presentation Rex Methodes Agiles

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

Page 8: Presentation Rex Methodes Agiles

Les phases du mode agile

• Schéma du cycle d'une itération

Page 9: Presentation Rex Methodes Agiles

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

Page 10: Presentation Rex Methodes Agiles

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

Page 11: Presentation Rex Methodes Agiles

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

Page 12: Presentation Rex Methodes Agiles

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, ...

Page 13: Presentation Rex Methodes Agiles

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 ?

Page 14: Presentation Rex Methodes Agiles

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

Page 15: Presentation Rex Methodes Agiles

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

Page 16: Presentation Rex Methodes Agiles

Agile au quotidien – Les outils

• La météo du projet avec Hudson.

Page 17: Presentation Rex Methodes Agiles

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

Page 18: Presentation Rex Methodes Agiles

Agile au quotidien – Les outils - yaml

Page 19: Presentation Rex Methodes Agiles

Agile au quotidien – Les outils - yaml

• Classe de mapping DTOYml

Page 20: Presentation Rex Methodes Agiles

Agile au quotidien – Les outils - yaml

• Exemple de bouchon– Méthode remplaçante du service réel

Page 21: Presentation Rex Methodes Agiles

Agile au quotidien – Les outils - yaml

• Exemple de bouchon– Méthode de lecture du fichier yaml

Page 22: Presentation Rex Methodes Agiles

Agile au quotidien – Les outils - yaml

• Exemple de bouchon– Mapping vers l'objet reel

Page 23: Presentation Rex Methodes Agiles

Agile au quotidien – Les outils - yaml

• Exemple de classe Manager

Page 24: Presentation Rex Methodes Agiles

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

Page 25: Presentation Rex Methodes Agiles

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

Page 26: Presentation Rex Methodes Agiles

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

Page 27: Presentation Rex Methodes Agiles

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

Page 28: Presentation Rex Methodes Agiles

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

Page 29: Presentation Rex Methodes Agiles

Agile au quotidien – Les outils - GP

• Grammaire specifique au projet

Page 30: Presentation Rex Methodes Agiles

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é.

Page 31: Presentation Rex Methodes Agiles

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

Page 32: Presentation Rex Methodes Agiles

Burndown chart

Page 33: Presentation Rex Methodes Agiles

Fin d'itération - Rétrospective

• Note d'itération → humeur de l'équipe

• Annonces du pilote du projet• Keep/drop/start/ ?

Page 34: Presentation Rex Methodes Agiles

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 »

Page 35: Presentation Rex Methodes Agiles

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

Page 36: Presentation Rex Methodes Agiles

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.