Product Delivery – Equipe Distribuée

• 3 semaines d’initialisation pour construire le Product Backlog Initial et une conception sommaire de Architecture
• Une équipe co-localisée au Pays-Bas mena 2 sprints (sprint de 2 semaines sur tout le projet)
• Dès le troisième sprint, les membres de l’équipe néerlandaise et ceux de l’équipe indienne furent regroupés au sein d’une même équipe, co-localisée, partageant un seul et même Product Backlog et des pratiques d’ingénierie d’XP
• Durant les itérations co-localisées, les membres de l’équipe ont scellé des relations interpersonnelles qui ont perdurées jusqu’à la fin du projet et les équipes indiennes ont pu ainsi s’approprier pleinement le contexte du client
• Cela a aussi permis d’aligner tout le monde sur des pratiques, des standards, des rôles et des outils communs

Le meilleur moyen d’illustrer le modèle distribué est de prendre un cas réel – le projet ProRail mené par Xebia

• Le Projet
  ProRail, la branche infrastructure et logistique des chemins de fer néerlandais devait développer un nouveau système d’informations voyageurs. Les informations sur les horaires des trains sont centralisées et mises à jour par le réseau ferroviaire lui même. Quand un train est en retard ou en avance, l’information est collectée par des capteurs disséminés dans l’infrastructure ou dans certains cas, manuellement. Xebia a donc mené le projet d’affichage de ces informations aux voyageurs pour l’ensemble des Pays Bas.
• Le temps était le critère majeur car des projets antérieurs, menés en cascade, n’avaient pas respecté leurs engagements.
• La transparence et la recherche de l’amélioration continue ont été des critères déterminants pour le client dans le choix de Xebia.
• Le choix du développement Offshore a été guidé par les coûts et la capacité à monter en charge rapidement
• La taille totale du projet fût de 20 années/homme, 100.000 lignes de code sur une période de 11 mois

• Après 3 itérations, l’équipe indienne retourna en Inde. Force est de constater qu’en 5 itérations (10 semaines), l’équipe avait atteint le niveau de l’hyper-productivité
• Le Pair Programming furent largement utilisées pour accélérer l’apprentissage des nouveaux
• Les équipes partagèrent le même Product Backlog mais chacune avait son propre Sprint Backlog.
• A la fin du projet, les équipes furent peu à peu réduites et fusionnées entre elles.
• La maintenance est prise en charge par des ingénieurs néerlandais (sans l’Inde)

• Le tableau ci-dessous montre aisément que les équipes Scrum Distribuées surperforment les équipes de projet classique.
• Les résultats d’une équipe Scrum distribuée Xebia sont équivalents à ceux d’une équipe Scrum co-localisée et les performances de Xebia et SirsiDyniax sont équivalentes.
• Ce tableau montre que la performance d’une approche Scrum distribuée est reproductible et non spécifique à SirsiDynix.

• Les Scrum Meetings facilitent grandement la communication. Cela est rendu possible dans une équipe Scrum distribuée par le fait que les objectifs sont complètement partagés.
• Toutes les cérémonies de Scrum furent tenues en mode distribué en utilisant le système de vidéo conférence de Skype à l’exception des démos.
• Des salles de réunion séparées furent créées avec l’équipement de conférence ad ’hoc.
• Un outil de planification utilisant une version électronique du BurnDown Chart permettait d’avoir une vision partagée du statut du Sprint en cours pour l’ensemble de l’équipe.
• Un microphone passait de main en main pour des raisons d’audibilité. Nous avons découvert que les face à face visuels accroissaient l’efficacité de la communication et permettaient d’améliorer les relations interpersonnelles.
• Les Sprint Planning impliquaient tous les membres de l’équipe, utilisant les Planning Poker Cards afin que les équipiers des deux continents participent aux estimations.
• Les Daily Stand Up meetings démarraient quand les européens arrivaient au travail (pas plus de 15mn)
• Le Rétrospective Meeting était mené comme le Sprint Planning Meeting et durait environ 2 heures.
• La démonstration, elle, n’était pas partagée afin de garder un maximum d’emphase et de réactivité face au client. Les Européens briefaient les indiens après la démo.
• Les meetings Scrum de Scrum avaient lieu juste après les Daily Scrum afin de synchroniser les éventuelles dépendances entre les équipes, et d’identifier les obstacles ou les points techniques.
• L’ensemble de ces meetings étaient donc conformes au cycle officiel. Les face à face étaient aussi tenus si nécessaires ainsi que les revues de conception.
• Il n’y avait donc rien de différent par rapport à l’utilisation de Scrum co-localisée si ce n’est l’outillage

• Durant tout le projet, une attention toute particulière a été portée à la qualité.
• La notion Scrum « Definition of Done » sur ce projet était la suivante:
  • couverture à 80% des tests unitaires,
  • chaine de tests fonctionnels complètement automatisée,
  • tests de non régression complets, tests de charge et de performance mis en place pour toutes les récits et production de la documentation nécessaire.
• Pour chaque fonctionnalité, l’intégralité de l’équipe était impliquée afin de débattre de la conception et de refactorer si nécessaire.
• En complément à cette propriété collective de la conception, chaque équipe employait un « Gardien de la Qualité».
• Il s’agissait d’un membre de l’équipe responsable de la qualité et de la consistance des travaux menés.
• Chaque fois qu’il soulevait un problème, il était traité par l’intégralité de l’équipe.
• Tous les membres de l’équipe partageaient la même pièce et des membres d’une équipe participaient systématiquement aux phases de conception des autres équipes afin de maintenir une consistance architecturale de l’ensemble.
• Le Pair Programming et la rotation entre les équipes servaient à éviter l’appropriation du code et maintenir la polyvalence

Même si Scrum est facile à comprendre, le développement distribué ajoute une couche de complexité et le projet, comme tout projet, rencontra un certain nombre de difficultés dans ce domaine.