Développement distribué agile

1,709 views
1,516 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,709
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
42
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • sss
  • Développement distribué agile

    1. 1. Agilité et développement distribué<br />MathieuSzablowski<br />Email: mszablowski@pyxis-tech.com<br />Xavier Warzee<br />Email: xavierw@microsoft.com<br />
    2. 2. Au fait, c’est quoi pour vous « distribué » ?<br />
    3. 3. Agenda<br />Challenges de l’agilité en équipe distribuée<br />Bonnes pratiques<br />Retour d’expériences<br />
    4. 4. Challenges de l’agilité en équipe distribuée<br />
    5. 5. Challenge de l’agilité en équipe distribuée<br />Travail en équipe ?<br />Décalage horaire<br />Comment échanger sur les besoins fonctionnels ?<br />Équipe on-shore souvent occupée<br />Équipe off-shore reste dans le flou<br />Communication ?<br />Ligne téléphonique =&gt; qualité de communication basse !<br />Accent, culture, approche des problèmes différents<br />Effet 24h <br />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 !<br />Pas de vision commune des enjeux business du projet<br />Équipe off-shore sans visibilité sur les attentes métier <br /><ul><li>peu de contextes
    6. 6. Pas de vision globale
    7. 7. Actions techniques sans signification</li></li></ul><li>L’agilité avec Scrum<br />Itération courte : le « sprint » de 2 à 4 semaines <br />Les rôles : ScrumMaster, ProductOwner<br />Le « Product Backlog »<br />Communication intensive : le « Daily Scrum »<br />Petites équipes<br />Distribution des développements par fonction<br />
    8. 8. Challenges supplémentaires<br />Mise à disposition d’un niveau suffisant de support pour mettre en place l’environnement de travail : outils, serveurs, …<br />Mise à disposition des accès aux infrastructures nécessaires au projet en off-shore<br />Référentiel de gestion de configuration, …<br />Représentant de l’équipe off-shore dans l’équipe on-shore =&gt; faciliter la communication<br />Manque de confiance<br />Bien comprendre les méthodes de travail de l’équipe offshore<br />Style de rédaction des documents, …<br />Manque de visibilité<br />
    9. 9. Bonnes pratiques<br />
    10. 10. Equipe off-shore<br />Construire l’équipe offshore incrémentalement<br />Supporter activement l’équipe offshore<br />Mettre en place un environnement <br />Ajouter ensuite de nouveaux membres à l’équipe offshore<br />Intégrer un proxy leader de l’équipe offshore par projet dans l’équipe onshore<br />Échanges côté onshore plus facile à créer<br />Échanges côté offshore compensés par connaissance des équipes offshore par le proxy leader<br />
    11. 11. Multiplier les canaux de communication<br />Email, <br />IM, <br />Webcams,<br />Vidéo conférences (round table),<br />Tableaux blancs électroniques.<br />Dépasser la communication verbale !<br />
    12. 12. Intégration continue<br />Construire, tester, déployer systématique<br />Vélocité des développements grandement améliorée !<br />Partage facilité et commun de l’état du projet <br />Pour des équipes très éloignées, définir 2 « builds » principaux (alternance jour/nuit) :<br />1 « build » le matin<br />1 « build » le soir<br />Augmentation de la stabilité du code <br />Facilite l’ajout de nouvelles fonctions et la gestion des releases<br />Partager une même perception de l’état « concret » du projet !<br />
    13. 13. bien définir le notion de « terminé »<br />
    14. 14. Démarche d’amélioration continue<br />Rétrospectives à chaque fin de « sprint » permettant de remonter les suggestions d’amélioration (+ de temps pour les tests, …)<br />Objectif : améliorer les pratiques durant chaque « sprint »<br />
    15. 15. Investir en infrastructure et process<br />Solution permettant de construire, déployer, tester automatiquement<br />Développer des émulateurs pour l’ensemble des dépendances externes<br />Passer du temps à échanger sur la définition de « Terminé » pour les « stories », « sprints »<br />Passer du temps à échanger sur l’amélioration du processus de développement<br />
    16. 16. Métriques pour mesurer l’avancement <br />Mesure du nombre de bugs trouvés par release<br />Mesure du nombre de bugs résolus par release<br />Mesure du nombre de bugs par priorité, par fonction<br />Résultats des tests<br />Complexité du code<br />Couverture du code par les tests<br />Pourcentage des « stories » terminées par sprint<br />Mesures particulières :<br />% up-time des services, <br />% de retour positif des clients, <br />Latence moyenne des transactions, etc.<br />
    17. 17. Métriques d’estimation pour les sprints<br />
    18. 18. Statiques concernant les bugs<br />
    19. 19. Statistiques concernant les tests automatisés<br />
    20. 20. Retour d’expérience avec pyxis<br />
    21. 21. Projet client<br />PARIS<br />3 développeurs<br />1 Scrum Master<br />1 Product Owner<br />Sponsor<br />Utilisateurs<br />GRENOBLE<br />2 développeurs<br />
    22. 22. Infrastructure PROJET CLIENT<br />Intégration<br />Mail<br />Wiki<br />Documents<br />Pré-Production<br />WEB<br />PARIS<br />GRENOBLE<br />
    23. 23. UrbanTurtle<br />MONTREAL<br />3 développeurs<br />Product Owner<br />PARIS<br />1 développeur<br />
    24. 24. Outils de collaboration<br />Simple et pratique<br />Voir l’état du sprint<br />Qu’avons-nous réalisé?<br />Sur quoi puis-je m’engager?<br />Qu’avons-nous livrer au client<br />Accès distant<br />Temps réel<br />Intégré<br />
    25. 25. Intérêt dans une équipe distribuée<br />Atelier : outils vs pratiques<br />
    26. 26. Visual studio team system<br />Des outils clients <br />Un serveur pour la collaboration<br />
    27. 27. Urbanturtle<br />Extension de Visual Studio Web Access<br />Faciliter la gestion de projet agile<br />Itératif, incrémentale, transparence…<br />

    ×