AGILITÉ ET DÉVELOPPEMENT DISTRIBUÉ

Xavier WarzeeEmail: xavierw@microsoft.com

Mathieu SzablowskiEmail: mszablowski@pyxis-tech.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É »

« 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…