8. 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é
10. 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
11. Multiplier les canaux de communication Email, IM, Webcams, Vidéo conférences (round table), Tableaux blancs électroniques. Dépasser la communication verbale !
12. 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 !
14. 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 »
15. 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
16. 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.
24. 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é
25. Intérêt dans une équipe distribuée Atelier : outils vs pratiques
26. Visual studio team system Des outils clients Un serveur pour la collaboration
27. Urbanturtle Extension de Visual Studio Web Access Faciliter la gestion de projet agile Itératif, incrémentale, transparence…
Notas do Editor
Mise en place :PARIS est central, les réunions auront lieu à Paris (Planning, maintenance, démo, rétro)Les grenoblois sont présents et se déplacent sur ParisLes daily se font par téléphoneRésultats :Tout le monde s’engage en présence de l’ensemble de l’équipeCommunication efficaceMais inégalité dans l’engagement (les grenoblois se déplacent beaucoup)D’où la dégradation de la communication et de l’infrastructure locale parisienne
Mise en place :Réajustement du daily pour coïncider avec les horaires du développeur en FranceActivation et ajout de la mise à jour de l’outil de collaboration dans le donePrise en compte du décalage dans les horaires(votre horaire et mon horaire)Résultats :Les réunions sont longues et difficile à suivre (planning, maintenance)Planning Poker quasiment impossibleDéveloppement difficile (ratio de code churn / site disproportionné)ECHEC -> modification du découpage du travail, on essaie d’isoler et d’encapsuler les stories