1. Agilité et développement distribué MathieuSzablowski Email: mszablowski@pyxis-tech.com Xavier Warzee Email: xavierw@microsoft.com

2. Au fait, c’est quoi pour vous « distribué » ?

3. Agenda Challenges de l’agilité en équipe distribuée Bonnes pratiques Retour d’expériences

4. Challenges de l’agilité en équipe distribuée

6. Pas de vision globale

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é

9. Bonnes pratiques

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 !

13. bien définir le notion de « terminé »

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.

17. Métriques d’estimation pour les sprints

18. Statiques concernant les bugs

19. Statistiques concernant les tests automatisés

20. Retour d’expérience avec pyxis

21. Projet client PARIS 3 développeurs 1 Scrum Master 1 Product Owner Sponsor Utilisateurs GRENOBLE 2 développeurs

22. Infrastructure PROJET CLIENT Intégration Mail Wiki Documents Pré-Production WEB PARIS GRENOBLE

23. UrbanTurtle MONTREAL 3 développeurs Product Owner PARIS 1 développeur

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…