Article tagué XP
Martin Fowler, utilisation d’un processus agile dans le développement offshore (Part 1)
24/03/08
Martin Fowler, une pointure du développement informatique et un pionnier des méthodes agiles a écrit il y a quelques temps de cela un article très intéressant sur l’utilisation des méthodes agiles pour le développement offshore. Les images utilisées pour illustrer cet article sont tirées d’une présentation réalisée par ThoughtWork (société où travail Martin Fowler) disponible ici.
L’article date un peut (Il a été écrit en 2003 et mis à jour pour la dernière fois en Juillet 2006) à l’époque les bienfaits des méthodes agiles sur le développement offshore n’étaient pas encore reconnus et certains disaient même qu’ils étaient incompatibles.
L’article étant d’une taille assez conséquente, je diviserais sa traduction en plusieurs posts.
Partie 1 :
- Introduction
- Leçons apprises
- Utiliser l’intégration continue pour éviter les migraines lors de l’intégration.
- Que chacun des bureaux est un ambassadeur de l’autre site.
- Des visites pour instaurer la confiance.
Introduction
Durant les quatre dernières années, ThoughtWorks, a fonctionné avec un laboratoire situé à Bangalore afin de soutenir le développement de ses logiciels en Amérique du Nord et en Europe
L’un des principes de base de toute méthodologie agile est l’importance portée à la communication entre les différents protagonistes du projet. « Le moyen le plus efficace et efficient de transmettre l’information au sein d’une équipe de développement, c’est le face-à-face ». Le livre d’Alistair Cockburn parle beaucoup de l’importance de la proximité physique dans les méthodes agiles.
Une autre tendance a récemment bousculé le monde du développement logiciel. C’est le passage au développement offshore. Celui-ci semble opposé au développement agile. Pour commencer, l’offshore va à l’encontre de la notion de proximité physique, puisque, par définition, les développeurs offshore sont loin. Deuxièmement la plupart des organisations faisant de l’offshore utilisent une approche prédictive (non agile) dans laquelle les documents de conception sont envoyés en zone offshore pour être réalisés.
ThoughtWorks a ouvert un bureau à Bangalore en 2001 et plusieurs des projets que l’entreprise a réalisés y ont eu recours. ThoughtWorks a utilisé autant que possible une approche agile, car pour eux cela est dans le plus grand intérêt des clients.
Il était également très important pour ThoughtWorks de conserver leur très grande exigence en matière de recrutement (généralement ils proposent un emploi à environ 1 candidat sur 100). Une grande partie des développeurs ont été recrutés à la fin de leurs études. On y a ensuite rajouté des développeurs plus expérimentés. Au début, plusieurs développeurs américains et britanniques ont rejoint le bureau de Bangalore, pour encadrer les nouveaux développeurs, à la fois sur le développement de logiciels mais aussi sur l’agilité et les pratiques XP appréciées par ThoughtWorks. Actuellement le centre de Bangalore compte environ 150 développeurs.
Utiliser l’intégration continue pour éviter les migraines lors de l’intégration.
Il y a de nombreuses histoires sur les problèmes rencontrés lors de l’intégration des travaux réalisées dans des équipes multi sites. Même en définissant des interfaces avec beaucoup de soins, les problèmes d’intégration font toujours leur apparition. Souvent même si toutes les signatures des méthodes sont correctes, il est toujours difficile de prévoir ce que l’implémentation fera réellement
La première pratique XP utilisée chez ThoughtWorks a été l’intégration continue. Ils y étaient tellement habitués qu’ils étaient déterminés à l’utiliser pour leurs développements offshores. Donc, dès le début, tout le monde travaillait sur le même serveur de source, avec CruiseControl réalisant les builds et les tests.
L’intégration continue et l’exécution automatique des tests permet de détecter très rapidement les éventuels problèmes et, de ce fait, ils peuvent être fixés avant que cela ne devienne trop difficile.
Tous les matins, les développeurs se connectent à l’interface web de CruiseControl pour voir les modifications faites par l’autre site. Il fournit un moyen facile de savoir ce qu’il s’est passé de l’autre côté du monde.
Mais l’intégration continue exige une grande discipline. Les développeurs s’efforcent de ne pas avoir de build failled et doivent réparer immédiatement si cela était le cas. Si un commit est effectué, on ne quitte pas le bureau tant que la confirmation du succès du build n’a pas été reçu. Un build failed de fin de journée à beaucoup plus de conséquence lorsque l’équipe offshore doit prendre le relais des développements.
Cependant des problèmes dus à la qualité du réseau de communication ont été rencontrés. En général, le serveur de build se trouve sur le même site que la majorité des développeurs, cela peut être ennuyeux pour l’équipe distante qui devra attendre longtemps lors d’un check-out complet. De plus le fait d’avoir un serveur devant être accessible 24h/24 n’est pas pratique pour pouvoir réaliser des backups. Tous ces problèmes pourraient être résolus en utilisant un cluster de serveur de sources mais l’équipe de ThougthWork n’avait pas les connaissances nécessaires à l’époque.
Que chacun des bureaux est un ambassadeur de l’autre site.
Comme dit plus haut, les méthodes agiles soulignent l’importance de la communication face-à-face. Même si tout le monde ne peut pas être sur le même site, le fait de déplacer certaines personnes aide énormément. Dès le début, un membre de l’équipe américaine était en permanence en Inde pour faciliter la communication. Un tel ambassadeur connaissant l’équipe américaine partage ses contacts ce qui facilite la communication.
Nous avons par la suite jugé utile d’envoyer un développeur américain et un analyste américain en Inde pour communiquer à la fois sur les exigences techniques et fonctionnelles. Il est également utile d’envoyer un membre de l’équipe Indienne en Amérique. Le coût du transport aérien est vite amorti par l’amélioration de la communication.
L’utilisation d’ambassadeurs dans l’équipe Offshore permet de partager le contexte du projet. Construire un logiciel sur une liste de fonctionnalités ne permet pas au développeur de savoir ce qu’il est prioritaire et important de faire. Le fait de connaître le « pourquoi » permet souvent de mieux choisir le « comment ».
Une partie importante du travail qui devra être effectuée par l’ambassadeur, est la diffusion « des bavardages ». Sur un projet il y a beaucoup de communication informelle. Même si en majorité cette information n’est pas importante, une partie l’est. Donc le travail de l’ambassadeur sera de rapporter des morceaux choisis de cette information qui n’a pas été jugée assez importante pour être transmise par les canaux officiels.
Les ambassadeurs changent en générale tous les mois. Si un ambassadeur passe trop de temps à l’étranger, il perd le contacte avec son site d’origine. Etre ambassadeur permet de passer du temps avec l’équipe distante et ainsi de mieux connaître les équipes. Lors du choix des ambassadeurs il est très important de prêter attention aux besoins et aux préférences des individus. Certaines personnes ne veulent pas passer plusieurs mois à des milliers de kilomètres de chez eux, de sorte qu’ils ne devraient pas être ambassadeur.
Nous avons également constaté qu’il est important pour les chefs de projet de passer un peu de temps en tant qu’ambassadeur. Une grande partie du travail du chef de projet est d’aider à résoudre les conflits et d’éliminer les problèmes avant qu’ils ne deviennent graves. Le fait d’avoir travaillé des deux côtés de la ligne téléphonique est vraiment important pour travailler efficacement.
Il est essentiel d’envoyer le plus tôt possibles des ambassadeurs. Si un projet se déroule pendant un certain temps sans ambassadeur, les malentendus et les mauvais sentiments vont se développer et cela demandera beaucoup de travail pour réparer les dégâts.
Des visites pour instaurer la confiance
En plus des ambassadeurs qui passent plusieurs mois dans le site distant, il y a d’autres types de visites qui contribuent à créer et à maintenir la communication nécessaire pour travailler efficacement à distance.
Les visites de lancement doivent être prévues le plus tôt possible dans le projet et doivent être d’une durée de deux semaines minimum. Le but premier de ces visites est d’habituer les gens à travailler ensemble.
- Envoyer les représentants du client et les chefs de projet pour créer un planning de livraison.
- Les analystes offshores doivent venir onshore pour participer aux sessions de recueil des besoins.
- Des développeurs onshore doivent rendre visite à l’équipe offshore pour travailler avec elle sur la première itération.
- L’équipe offshore doit visiter le site « onshore » surtout si il se trouve chez le client.
Il ne faut pas oublier que le but principal de cette visite n’est pas de faire le travail, mais de construire les relations de travail. C’est une erreur fréquente de vouloir faire entrer le plus de tâches possibles durant ses visites et de se retrouver au final avec très peu de temps pour les relations humaines. Le rythme de travail doit y être relax et il ne faut pas avoir peur de planifier des réunions informelles où l’on présente à l’invité l’environnement de travail.
Une variante de la visite de lancement est importante si des développeurs sont présent sur les différents sites. Dans ce cas il est important que les développeurs, au moins les séniors, travaillent ensemble sur les premières itérations. C’est durant ces itérations que les décisions d’architectures cruciales sont prises. Il est important d’avoir une forte proximité durant cette période sinon il pourrait y avoir une scission entre les deux équipes lorsque des décision ne sont pas partagées ou non comprises.
Une fois le lancement du projet terminé, des visites moins intenses doivent être utilisées pour garder le contact. Ces visites peuvent être plus courtes, mais assez fréquentes (au moins tous les deux mois). Il est important de prendre plus de temps lorsque des changements significatifs apparaissent dans le projet.
Des présents, en particulier ceux qui participent à l’échange culturel, comme les spécialités locales, sont toujours important.
C’est la fin de cette première partie. La suite devrait arriver prochainement.
Le radiateur d’informations
15/02/08
Simple et efficace, voici les deux adjectifs que j’utiliserais pour décrire le radiateur d’informations. Un mur, des stylos, des post-it et le tour est joué. Le but est d’afficher sur le mur les informations importantes pour que tous les acteurs du projet puissent y avoir accès à tout moment.
Un bon radiateur d’informations doit être :
- A jour et complet
- Précis et facile à interpréter
- Visible par tous
- Facile à manipuler.
Les informations affichées diffèrent selon les projets et les besoins mais il y a quelques grands classiques.
Le Task Board
Il présente les tâches à réaliser durant le sprint en cours.
Sur la gauche sont affichés sur des post-it verts les user story (et leur charge de travail) à réaliser pendant le sprint.
Pour chacun d’eux on trouve sur la même ligne les tâches nécessaires à leur réalisation. Elles sont représentées par des post-it jaunes sur lesquels sont indiqué le nom de la tâche, le temps restant et la personne qui en à la charge. La tâche passera successivement de la colonne « A faire », à « En cours » puis « Terminés »
On sait ainsi à n’importe quel moment qui travaille sur quoi et quelles sont les tâches restantes pour le sprint.
Le Burn Down Chart
Il permet de visualiser graphiquement l’avancement du travail et de savoir si le contenu du sprint pourra être réalisé dans les temps ou si certaines tâches devront être reportées au sprint suivant. Il permet également de détecter les ralentissements de production ou tout autres problèmes pouvant intervenir.
Il est placé au dessus du TaskBoard et est mis à jour tous les matins après le daily scrum.
En ordonnée on trouve la charge de travail restante dans l’itération et en abscisse les journées présentes dans le sprint. Le but étant que chaque jour, la charge de travail restant diminue.
Le Project Progress Poster
C’est une vue du projet dans sa globalité. Y est représenté le contenu des différents Sprints.
Pour chacun d’eux est indiqué l’objectif (Post-it orange) et la liste des user story qu’il faudra réaliser (Post-it en vert).
La colonne du sprint en cours a été déplacée dans le Task board. Les colonnes à gauche de celle étant vide représentent donc les sprints terminés alors que celles à droite représentent ceux restant. Une fois qu’un sprint est terminé on place son burndowChart au dessus de sa colonne.
Autres informations utiles pouvant être affichées
- Les « impediments » : Les problèmes identifiés qui pourraient entraver la progression du projet.
- Le calendrier des livraisons.
- Le burndownChart du projet total.
Développement offshore, un besoin d’agilité
19/01/08
Lorsque l’équipe (ou une partie de l’équipe) est éloignée, que ce soit avec des équipes offshores en Inde ou nearshores en Roumanie, de nouveaux problèmes liés à l’éloignement vont apparaître
- Problèmes de communication.
- Suivi de l’avancement du projet.
- Assurer la qualité.
A chacun de ces problèmes les méthodes agiles vont apporter des réponses.
- La communication : Les méthodes agiles mettent l’accent sur l’importance de la communication. Cette attention devra être encore plus forte avec l’éloignement des équipes. Heureusement, de nos jours, de nombreux outils sont disponibles pour nous faciliter la tâche.
- Le wiki : L’utilisation de wiki est un moyen simple et pratique de regrouper l’information et de la rendre disponible à tous les membres de l’équipe. C’est la que, par exemple, on trouvera les bonnes pratiques, les conventions de code, le processus de build, la description de l’architecture technique… C’est l’équipe qui l’alimente et qui y ajoute tous ce qui lui semble utile. De plus lors de l’intégration de nouvelles ressources sur le projet, l’information contenu dans le wiki se trouve être une vrai mine d’or pour le nouveau venu.
- La messagerie instantanée : C’est un très bon moyen de communication qui permet d’obtenir rapidement des réponses sur des problèmes pouvant être bloquant. Son grand avantage est qu’il n’est pas intrusif et qu’il n’est pas nécessaire de cesser toutes activités pour l’utiliser (contrairement au téléphone). Il ne remplace pas le téléphone mais lorsque s’agit d’éclaircir des points pouvant prêter à confusion, il fait très bien son boulot.
- Le téléphone : Avec l’apparition de la VoIP, le coût des communications internationales devient pratiquement nul. De plus elle apporte un plus grand confort d’utilisation en permettant à l’utilisateur d’avoir les mains libres, de pouvoir dans un même temps transférer des fichiers ou des urls par messagerie instantanée. Il est également très simple de mettre en place des conférences.
- La visoconférence : Même si sont utilisation n’est pas encore parfaite, la visioconférence peut permettre de recréer un peu les rapports humains « francs », face à face qui manque lorsque l’on travaille à distance. Deux développeurs qui travaillent à 10 000 km de distance peuvent ainsi « se voir » et mettre un visage sur l’autre.
- Les voyages : Il est essentiel, surtout en début de projet que de nombreux voyages aient lieux. Au minimum un responsable doit se déplacer au près des équipes offshore, pour les rencontrer et présenter le projet et ses objectifs. Il est aussi important que les équipes « on-site » et « distante » se rencontrent (au moins une fois) pour ainsi créer « un lien » et ainsi faciliter le travail avec « l’autre ».
- Suivi du projet : L’utilisation d’itérations courtes permet de montrer rapidement aux utilisateurs des fonctionnalités qui marchent, d’avoir des retours fréquents et donc de corriger le tir si besoin est. L’utilisation de Scrum permet de faire cela très bien. Les daily scrum permettent d’avoir un retour rapide sur le travail restant avant la fin d’une itération. Les « BurndownCharts » (graphiques d’avancement) permettent de visualiser graphiquement l’avancement du travail. Une interprétation simple permet d’avoir une idée sur les échéances futures.
- La qualité : Il est essentiel de garantir la qualité du produit développé. Pour cela il faut respecter certains principes forts comme ceux prônés par L’eXtreme Programming (voir article précédent pour plus de détails).
- Intégration continue
- Livraisons fréquentes
- Tests unitaires et tests de recette automatisés
- Conception simple
- Refactoring
- Appropriation collective du code
- Convention de nommage
L’eXtreme Programming
4/01/08
Lorsque les équipes de développement sont éloignées, il est important que la qualité du produit soit irréprochable. L’application de certains principes simples permet de réduire grandement les risques de dérapage.
L’eXtreme Programming (XP) est une méthode agile qui a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries lorsqu’ils travaillaient sur un projet de calcul des rémunérations chez Chrysler.
Cette méthode pousse à l’extrême des principes simples et connus de l’industrie du logiciel.
- puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme)
- puisque les tests sont utiles, ils seront fait systématiquement avant chaque implémentation
- puisque la conception est importante, elle sera faite tout au long du projet (refactoring)
- puisque la simplicité permet d’avancer plus vite, nous choisirons toujours la solution la plus simple
- puisque la compréhension est importante, nous définirons et ferons évoluer ensemble des métaphores
- puisque l’intégration des modifications est cruciale, nous l’effectuerons plusieurs fois par jour
- puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous adapter au changement.
L’Extreme Programming repose sur 5 valeurs fondamentales :
- La communication : La communication, quelle soit avec le client ou au sein de l’équipe permet d’éviter les dérapages possibles d’un projet.
- La simplicité : Privilégier un code simple et épuré. Ne pas faire plus que nécessaire. Utilisation d’outils simple.
- Le feedback : Si des points ne sont pas clair, agir, expérimenter ou questionner pour obtenir des réponses.
- Le courage : Affronter les difficultés plutôt que de les ignorer ou de repousser à plus tard leur prise en compte.
- Le respect : Du client, de l’équipe, des processus.
Ces 5 valeurs se déclinent en 12 pratiques :
- Client sur site (ou tout du moins une incarnation du client) : La personne jouant le rôle du client doit avoir les connaissances de l’utilisateur final et avoir une vision globale du résultat à obtenir. Ils doit répondre aux questions fonctionnel que pourrait se poser l’équipe.
- Jeu du Planning : Le client donne une priorité aux scénarios. Les développeurs discutent du contenu de ces scénarios, estiment la charge de travail nécessaire et les risques relatifs. Le client sélectionne ensuite les scénario en fonction des priorités et du temps disponible.
- Intégration continue : Le projet est fréquemment compilé et testé. Permet de réagir et de débusqué d’éventuelles erreurs.
- Livraisons fréquentes : Rassure le client et lui permette de réagir rapidement si l’application livrée ne correspond pas à ses attentes. Maintient la motivation de l’équipe.
- Rythme soutenable : L’équipe ne fait pas d’heures supplémentaires deux semaines de suite. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal.
- Tests unitaires et tests de recette : De préférence automatisés.
- Conception simple : L’applicatif doit répondre aux critères de lisibilité, de concision, de modularité, de cohérence, de maintenabilité.
- Utilisation de métaphores : Des analogies sont utilisés pour faciliter la compréhension des utilisateurs.
- Refactoring (ou remaniement du code) : On retravaille le code pour l’améliorer tout en gardant les mêmes fonctionnalités. (Les tests unitaires permettent de s’assurer que le fonctionnel n’est pas affecté par les changements effectués sur le code)
- Appropriation collective du code : Le code appartient à tout le monde et chaque développeur peut modifier toutes les parties du code si le besoin s’en fait sentir.
- Convention de nommage : Le code doit respecter une convention de nommage et ainsi être lisible par tous les membres de l’équipe.
- Programmation en binôme : Le pilote tient le clavier et tape. Le co-pilote suggère de nouvelles solutions et relis le code pour éviter d’éventuelles erreurs.
Même si certaines pratiques sont assez contraignantes (comme le binomage) d’autres sont essentielles au bon déroulement d’un projet (intégration continue, livraisons fréquentes, refactoring, convention de nommage, les tests…). C’est pourquoi les pratiques de d’XP sont souvent utilisées avec d’autres méthodes agiles comme SCRUM, on parle alors de SCRUM XP.