• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Développement distribué agile
 

Développement distribué agile

on

  • 1,858 views

 

Statistics

Views

Total Views
1,858
Views on SlideShare
1,834
Embed Views
24

Actions

Likes
0
Downloads
30
Comments
0

4 Embeds 24

http://blogs.msdn.com 21
http://www.slideshare.net 1
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Développement distribué agile Presentation Transcript

  • Agilité et développement distribué
    MathieuSzablowski
    Email: mszablowski@pyxis-tech.com
    Xavier Warzee
    Email: xavierw@microsoft.com
  • 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é »
  • 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
    Intégration
    Mail
    Wiki
    Documents
    Pré-Production
    WEB
    PARIS
    GRENOBLE
  • UrbanTurtle
    MONTREAL
    3 développeurs
    Product Owner
    PARIS
    1 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
    Des outils clients
    Un serveur pour la collaboration
  • Urbanturtle
    Extension de Visual Studio Web Access
    Faciliter la gestion de projet agile
    Itératif, incrémentale, transparence…