Upload
xavier-warzee
View
2.085
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
AGILITÉ ET DÉVELOPPEMENT DISTRIBUÉ
Xavier WarzeeEmail: [email protected]
Mathieu SzablowskiEmail: [email protected]
AU FAIT, C’EST QUOI POUR VOUS « DISTRIBUÉ » ?
AGENDA
Challenges de l’agilité en équipe distribuée
Bonnes pratiques
Retour d’expériences
CHALLENGES DE L’AGILITÉ EN ÉQUIPE DISTRIBUÉE
CHALLENGE DE L’AGILITÉ EN ÉQUIPE DISTRIBUÉE Travail en équipe ?
Décalage horaire Comment échanger sur les besoins fonctionnels ?
Équipe on-shore souvent occupée Équipe off-shore reste dans le flou
Communication ? Ligne téléphonique => qualité de communication basse ! Accent, culture, approche des problèmes différents
Effet 24h Si une action doit être faite par une équipe pour que l’autre équipe
avance et que l’action n’est pas faite à la fin d’une journée, l’autre équipe reste bloquée une journée complète !
Pas de vision commune des enjeux business du projet Équipe off-shore sans visibilité sur les attentes métier
Þ peu de contextes Þ Pas de vision globaleÞ Actions techniques sans signification
L’AGILITÉ AVEC SCRUM
Itération courte : le « sprint » de 2 à 4 semaines
Les rôles : ScrumMaster, ProductOwner
Le « Product Backlog »
Communication intensive : le « Daily Scrum »
Petites équipes
Distribution des développements par fonction
CHALLENGES SUPPLÉMENTAIRES
Mise à disposition d’un niveau suffisant de support pour mettre en place l’environnement de travail : outils, serveurs, …
Mise à disposition des accès aux infrastructures nécessaires au projet en off-shore
Référentiel de gestion de configuration, …
Représentant de l’équipe off-shore dans l’équipe on-shore => faciliter la communication
Manque de confiance Bien comprendre les méthodes de travail de l’équipe offshore
Style de rédaction des documents, …
Manque de visibilité
BONNES PRATIQUES
EQUIPE OFF-SHORE
Construire l’équipe offshore incrémentalement Supporter activement l’équipe offshore Mettre en place un environnement Ajouter ensuite de nouveaux membres à l’équipe
offshore
Intégrer un proxy leader de l’équipe offshore par projet dans l’équipe onshore Échanges côté onshore plus facile à créer Échanges côté offshore compensés par connaissance
des équipes offshore par le proxy leader
MULTIPLIER LES CANAUX DE COMMUNICATION
Email, IM, Webcams, Vidéo conférences (round table), Tableaux blancs électroniques.
Dépasser la communication verbale !
INTÉGRATION CONTINUE
Construire, tester, déployer systématique
Vélocité des développements grandement améliorée !
Partage facilité et commun de l’état du projet
Pour des équipes très éloignées, définir 2 « builds » principaux (alternance jour/nuit) :
1 « build » le matin 1 « build » le soir
Augmentation de la stabilité du code
Facilite l’ajout de nouvelles fonctions et la gestion des releases
Partager une même perception de l’état « concret » du projet !
BIEN DÉFINIR LE NOTION DE « TERMINÉ »
« Terminé » pour une « story »
• Répondre aux critères d’acceptation définir au début d’un sprint
• Tous les codes et tests dans le référentiel de gestion de version
• Tous les tests de « story » écrits et passés avec succès
• Tous les tests fonctionnels applicables pour une “story” sont identifiés, écrits et passés avec succès
• Approbation du PO / Stakeholder
« Terminé » pour un « sprint »
• Tous les critères pour les « stories » sont à jour et/ou adressés
• Tous les « Critical/Error Breaking » détectés par FxCop sont corrigés
• Code coverage >= 70%• 0 erreurs détectées par
StyleCop• Utiliser un Profiler et
analyser les résultats• Démonstration au PO
DÉMARCHE D’AMÉLIORATION CONTINUE Rétrospectives à chaque fin de
« sprint » permettant de remonter les suggestions d’amélioration (+ de temps pour les tests, …)
Objectif : améliorer les pratiques durant chaque « sprint »
INVESTIR EN INFRASTRUCTURE ET PROCESS
Solution permettant de construire, déployer, tester automatiquement
Développer des émulateurs pour l’ensemble des dépendances externes
Passer du temps à échanger sur la définition de « Terminé » pour les « stories », « sprints »
Passer du temps à échanger sur l’amélioration du processus de développement
MÉTRIQUES POUR MESURER L’AVANCEMENT
Mesure du nombre de bugs trouvés par release Mesure du nombre de bugs résolus par release Mesure du nombre de bugs par priorité, par fonction Résultats des tests Complexité du code Couverture du code par les tests Pourcentage des « stories » terminées par sprint
Mesures particulières : % up-time des services, % de retour positif des clients, Latence moyenne des transactions, etc.
MÉTRIQUES D’ESTIMATION POUR LES SPRINTS
STATIQUES CONCERNANT LES BUGS
STATISTIQUES CONCERNANT LES TESTS AUTOMATISÉS
RETOUR D’EXPÉRIENCE AVEC PYXIS
PROJET CLIENT
PARIS 3 développeurs 1 Scrum Master 1 Product Owner Sponsor Utilisateurs
GRENOBLE 2 développeurs
INFRASTRUCTURE PROJET CLIENT
PARIS GRENOBLE
WEB
MailWikiDocuments
IntégrationPré-Production
URBAN TURTLE
MONTREAL3 développeursProduct Owner
PARIS1
développeur
OUTILS DE COLLABORATION
Simple et pratique Voir l’état du sprint
Qu’avons-nous réalisé? Sur quoi puis-je m’engager? Qu’avons-nous livrer au client
Accès distant Temps réel Intégré
Intérêt dans une équipe distribuée
ATELIER : OUTILS VS PRATIQUES
VISUAL STUDIO TEAM SYSTEM
Un serveur pour la collaboration
Des outils clients
URBAN TURTLE
Extension de Visual Studio Web Access Faciliter la gestion de projet agile
Itératif, incrémentale, transparence…