Petit coup de pub à nos collègues de Xebia India, avec qui nous travaillons sur les projets ADDM, ils viennent de lancer leur blog : Xebee.

A l’image de ce que nous faisons sur ce blog, ou sur le blog de nos collègues hollandais, vous pourrez y retrouver dans la langue de Shakespeare des articles :

• Sur la plateforme Java / Java EE, sur Flex, etc.
• Sur les méthodes agiles.
• Sur des sujets plus locaux à Xebia India.
• Sur les visites des collègues de Xebia France ou Xebia Hollande à Gurgaon.

Longue vie à Xebee !

« En combinant agilité et offshore », nous répond Stéphane Coussement, directeur technique de Coach Club, site de vidéos sportives sur-mesure. Il répond aux questions de Cyril Dhénin sur TV4IT.

Retour sur la démarche et premier bilan.

Les méthodes agiles à proprement parler ne fournissent pas de solution clé en main dans ce domaine. C’est donc au travers du système de valeurs et des retours d’expérience que l’on cherchera à répondre à cette question.

Le premier élément de réponse provient de l’une des pratiques issues de l’eXtreme Programming et nommée la métaphore. Une métaphore est une abstraction de niveau élevé destinée à décrire les principes d’architecture mis en oeuvre dans un système ou un sous-système. Difficile à mettre en forme, le principe de métaphore se traduit souvent par un bref dossier d’architecture – 10 pages maximum – que chaque équipe est chargée de maintenir et de publier (généralement dans un wiki).
Un très bon exemple illustrant ce principe de la métaphore a été récemment fourni par l’équipe Chrome de Google, qui a publié sa métaphore sous la forme d’une BD de 38 pages. Y sont expliqués la vision du produit et les principes architecturaux qui guident sa mise en oeuvre, ainsi que les raisons des choix réalisés.

La seconde réponse à la question de l’architecture est dérivée d’une pratique d’ingénierie héritée du Lean Manufacturing, et que l’on retrouve dans la plupart des méthodologies, agiles ou non : les standards de développement.

Les systèmes organiques mis en place par certains acteurs majeurs du Web fonctionnent sur ce principe : une myriade d’équipes de petite taille sont chargées de développer des services ou composants fortement intégrés. Chaque équipe inclut un technicien chevronné qui prend le rôle de « Architecture Owner ». Elle conservent une totale autonomie technique et la maîtrise de leur cycle de vie mais sont soumises à un ensemble de règles qui régissent la façon dont ces composants sont interfacés avec le reste du système.

Ces règles couvrent, sans exhaustivité :

• l’exploitabilité (socle technique pris en charge par les équipes d’exploitation)
• la supervision (indicateurs, alertes, traces, journaux, etc.)
• l’assemblage (afin d’automatiser les déploiements)
• la qualité de service (charge, temps de réponse, sécurité, etc.)
• l’interopérabilité (protocoles et paradigmes d’échange, modalités d’intégration, etc.)

Ces règles sont mises au point par le collège des architectes (architecture owners) et consolidées par un « Chief Architect » dont le rôle est de les diffuser et d’en garantir la consistance. Des ateliers sont régulièrement organisés, réunissant les architectes des différents produits, afin d’échanger sur les solutions aux problématiques transverses qui peuvent se poser.

Au besoin, certains concepts d’architecture éprouvés peuvent être encapsulés dans des composants partagés. On peut, par exemple, mettre à disposition des équipes une API de persistance qui encapsule les stratégies de partitionnement des bases de données et la gestion transactionnelle. Une autre API prendra en charge les paradigmes d’échange (essentiellement asynchrone) mis en oeuvre dans l’architecture. Ces développements sont idéalement pris en charge par des équipes ad hoc, et placés sous la responsabilité collective. Si le contexte l’exige, on peut constituer une équipe dédiée (cf. un peu plus bas).

Notons que cette approche n’est envisageable que si l’architecture globale est fortement modulaire.

Une autre approche possible est mise en place sur certains projets agiles de grande taille. Cette solution consiste, au sein d’un projet nécessitant plusieurs équipes, à spécialiser une équipe dans les aspects architecturaux (on parle d’ « Architecture Team », en complément de « Feature Teams » chargées de développer les fonctionnalités du produit). C’est une telle organisation que nous vous avons présentée dans ce retour d’expérience. Sur des projets de très grande taille, d’autres équipes spécialisées peuvent émerger : intégration du système, équipe de tests dédiée, etc.

Quelle que soit la structure choisie, on retiendra un certain nombre de principes, exprimés par Scott Ambler (Practice Leader Agile Development chez IBM Rational) dans un article parut en 2006 dans le Agile Journal :

• Modéliser à plusieurs – l’architecture et la modélisation devraient être réalisées en groupe, afin de bénéficier de l’expérience de chacun et de consolider une vision commune, une culture collective
• Se focaliser sur la collaboration plutôt que sur la documentation – un architecte agile est un membre actif des équipes de développement, et non un simple producteur de documents à destination des dites équipes ; cela ne signifie pas qu’il ne faut pas documenter, mais la documentation doit être vue comme un effort secondaire
• Prouver par le code – le prototypage doit être systématisé afin de lever les risques au plus tôt
• Rester simple – une des pierres angulaire du développement agile : le modèle et l’architecture n’ont besoin de satisfaire que les besoins identifiés
• Utiliser les outils les plus simples – bien souvent, un simple tableau et quelques marqueurs suffisent
• Adresser les grandes problématiques très tôt – les paradigmes d’architecture doivent être identifiés dès les phases initiales du projet, sous la forme d’une vision (ou d’une métaphore, pour reprendre la terminologie XP) ; à l’échelle du SI, cela peut se traduire par un plan d’urbanisme de très haut niveau, assorti de règles d’intégration de type SOA (mise en place de services HTTP, mode de communication prioritairement asynchrone, politiques de gestion de versions et d’adressage, modalités d’intégration des IHM, etc.)
• Penser aux détails « just-in-time » – les détails du modèle et de l’architecture sont élaborés le plus tard possible par les équipes de développement ; au même titre que le développement, la conception est une activité continue
• Permettre à l’architecture d’émerger avec le temps – même si une vision est conçue au départ, les détail émergerons au rythme des évolutions du système
• Voyager léger – ne pas écrire 50 pages quand 5 suffisent ; ne pas écrire 5 pages quand un diagramme suffit ; ne pas faire un diagramme si une métaphore suffit.
• Maintenir quelques diagrammes de haut niveau – voyager léger ne signifie pas que toute documentation disparaît ; quelques diagrammes permettant de naviguer dans l’architecture sont utiles
• Rester flexible – le type de diagramme de haut niveau dépend du système et du contexte ; ils ne devraient pas faire l’objet d’une règle rigide
• Publier les modèles d’architecture – ils doivent être accessibles aux membres de l’équipe et à tous ceux qui souhaitent les consulter
• Piloter l’architecture par les besoins

Intervenants :

• M. Guillaume Bodet, Directeur Technique, Xebia
• M. Patrick Anfossi, RSI Services, Direction des Systèmes d’Information, Plastic Omnium
• M. Stéphane Coussement, Directeur des Systèmes d’Information, CoachClub

Informations utiles :

• Adresse : L’Atelier – 14, Rue Bergère – 75009 Paris
• Date : Mercredi 30 Septembre 2009 à 9h00
• Durée : 2H00
• Inscription : http://www.atelier.fr/inscriptionEvenement.php?artid=38651

Intervenants :

• M. Guillaume Bodet, Directeur Technique, Xebia

Informations utiles :

• Adresse : L’Atelier – 14, Rue Bergère – 75009 Paris
• Date : Jeudi 8 Octobre 2009 à 9h00
• Durée : 2H00
• Inscription: http://www.atelier.fr/inscriptionEvenement.php?artid=38668

Rappelons rapidement les principales techniques de teamicide décrites dans Peopleware :

• Le management défensif – résultat direct d’une défiance irréfléchie envers l’équipe, et qui se manifeste sous diverses formes plus ou moins spectaculaires, mais toujours avec le même objectif : réduire autant que possible les degrés de liberté des membres de l’équipe.
• La bureaucratie, qui, dans le développement logiciel, prend souvent la forme d’une méthodologie formelle impliquant un grand nombre de documents d’étape dont l’intérêt douteux n’en entame pas moins le caractère sacré. Dans les organisations les plus avancées dans le domaine, on observe souvent une cellule spéciale qui agit en tant que police de la Méthode et vérifie scrupuleusement qu’aucune équipe n’a enfreint les tables de la Loi. Cette approche permet de cumuler bureaucratie et management défensif.
• La séparation physique des individus, dont on comprend sans peine qu’elle réduit mécaniquement les relations interpersonnelles entre eux.
• La fragmentation du temps – demander aux gens de travailler à temps partiel sur plusieurs projets simultanément est l’une de ces recettes magiques qui, outre qu’elle réduit fortement l’efficacité des individus, interdit à coup sûr l’émergence du moindre esprit d’équipe (quelle équipe, au fait ?).
• La réduction de la qualité, qui est une technique plus subtile mais non moins efficace et populaire de teamicide. Il n’est tout bonnement pas imaginable qu’une équipe émerge formée d’individus honteux de leur travail …
• Les délais arbitraires et intenables, qu’un nombre encore impressionnant de cadres s’acharnent à considérer comme un moyen astucieux de conserver une équipe sous pression. Mettre d’emblée une équipe en situation d’échec, en lui fixant des objectifs qu’elle n’a aucune chance d’atteindre, est pourtant le plus sûr moyen de voir s’évaporer toute trace de motivation, tant collective qu’individuelle …

Fort de ces quelques indices, on comprend aisément que le développement offshore est un terrain spontanément très propice au teamicide. Tellement propice au demeurant que la plupart des organisations offshore baissent d’emblée les bras et ne cherchent même pas à construire des équipes – elles se contentent d’agréger des jours-homme au meilleur coût dans l’espoir souvent déçu que cette masse d’effort pourra être canalisée vers un résultat tangible. Elles utilisent pour cela des techniques de management qui pour la plupart finissent par achopper, précisément parce qu’elles sont de nature teamicidaires et que l’on n’échappe jamais vraiment à l’impératif de constituer d’authentiques équipes pour réussir un projet.

Depuis plus de trois ans maintenant, Xebia mène des projets agiles distribués, grâce à des équipes transcontinentales dont une partie des membres est localisée à Gurgaon, dans la banlieue de Delhi. Rappelons que la construction d’équipes de petite taille et fortement autonomes est une condition sine qua non de succès dans un projet agile, fût-il mené en offshore. Tout l’enjeu de l’approche ADDM (Agile Distributed Delivery Model) est donc précisément de parvenir à constituer de véritables équipes dont les membres sont distants de 6000 km les uns des autres et issus de substrats culturels radicalement différents.

Cet impératif nous a permis de découvrir, parfois dans la douleur, tout un jeu de techniques teamicidaires inédites. Attention : l’usage d’une ou plusieurs de ces techniques constitue le meilleur moyen d’échouer rapidement dans un projet agile distribué. En voici les 10 principales, :

1. Impliquer l’équipe offshore après quelques sprints, une fois que l’équipe locale a bien compris les enjeux du projet, réalisé les principaux choix techniques et élaboré une road-map
2. Une fois l’équipe offshore intégrée, continuer de prendre localement les principales décisions en matières d’architecture et de conception. Communiquer fréquemment sur l’incapacité de l’équipe offshore à bien comprendre ces choix, et sur les erreurs qui en découlent.
3. Attribuer à l’équipe offshore tous les problèmes du projet, fussent-ils dus à des exigences floues, à de la dette technique ou encore à des choix technologiques erronés. Vous serez surpris de constater à quel point il est aisé, aux yeux de vos commanditaires, de faire porter le chapeau à l’équipe distante.
4. Rester condescendant lors des rétrospectives, sans jamais donner de feedback honnête à l’équipe offshore. Lui assurer systématiquement que son travail est excellent, quelle qu’en soit la réalité.
5. Ne jamais colocaliser toute l’équipe et maintenir l’équipe offshore à distance du Product Owner, des utilisateurs, et plus généralement de toutes les parties prenantes du projet. Invoquer le coût du voyage permet très aisément de convaincre le management du bien fondé de cette mesure.
6. Si malgré tout une période de colocalisation est organisée, s’assurer que les développeurs offshore ne programment jamais en binôme avec leurs pairs locaux. Si possible, placer les premiers dans un bureau distinct.
7. Confier à l’équipe offshore les tâches dont personne d’autre ne veut, et réserver les user stories les plus stimulantes pour l’équipe locale.
8. Remanier le code durant le weekend, ou en l’absence de l’équipe offshore (l’après-midi, si ce sont des Indiens), en se gardant de l’informer sur ce refactoring.
9. Ré-écrire le code produit par l’équipe offshore, sans communiquer avec elle sur les raisons de cette mesure. En complément, faire en sorte que le management soit informé du retard pris par le projet en raison de cette ré-écriture.
10. Ne jamais permettre à l’équipe offshore de corriger les problèmes qu’elle a elle-même introduits.

Néanmoins, les déconvenues sont monnaie courante et les projets d’externalisation en échec sont nombreux. Manque d’appropriation du fonctionnel pour des raisons de trop grande distance et de différences culturelles importantes, faibles compétences des équipes de réalisation, turn-over trop élevé pour assurer une continuité des équipes dans les projets sont quelques unes des difficultés les plus fréquemment évoquées.

C’est dans ce cadre que L’Atelier et Xebia se sont associés pour un Atelier durant lequel, Xebia présentera sa solution pour éviter les écueils liés à l’externalisation : son modèle Offshore Agile Distribué (ADDM -Agile Distributed Delivery Model).

Intervenants :

• M. Guillaume Bodet, Directeur Technique, Xebia
• M. Patrick Anfossi, RSI Services, Direction des Systèmes d’Information, Plastic Omnium
• M. Stéphane Coussement, Directeur des Système d’Information, CoachClub

Informations utiles :

• Adresse : L’Atelier – 14, Rue Bergère – 75009 Paris
• Date : Mercredi 30 Septembre 2009 à 9h00
• Durée : 2H00
• Inscription : http://www.atelier.fr/inscriptionEvenement.php?artid=38651

Notre client, CoachClub, premier site vidéo de Coaching Sportif personnalisé a accepté de témoigner ici sur son expérience du modèle Xebia ADDM (Agile Distributed Delivery Model). Voici quelques unes des réactions que nous avons pu collecter émanant de la part du Management :

« La maîtrise des technologies Java / J2EE et des architectures distribuées acquises par les consultants de Xebia était de ce point de vue un gage de réussite.
J’avais déjà pu expérimenter leur savoir faire quand j’étais Directeur Technique de voyages-sncf.com. »
Stéphane Coussement, DSI de CoachClub

« Il est absolument nécessaire d’instaurer des relations de pair et non de client / fournisseur entre les membres français et indiens de l’équipe. »
Olvier Bergeret, Responsable des développements chez CoachClub

« Les fonctionnalités attendues par le marketing de CoachClub peuvent évoluer très rapidement.
Seules les méthodes agiles nous garantissaient une réactivité suffisante. »
Aurélie Chomont Garbier, Directrice du Marketing de CoachClub

« Nous avons choisi pour construire notre site Web, le modèle Agile Offshore de Xebia qui nous garantit un prix très compétitif, une approche de développement par la valeur, des délais courts et une très grande qualité de code applicatif. »
Thierry Pépin, Président de CoachClub

Télécharger le témoignage complet de CoachClub.

Suite au franc succès rencontré en France par les premiers projets Java/J2EE menés en Offshore Agile Distribué avec sa filiale indienne, Xebia a le plaisir d’annoncer la disponibilité de son modèle ADDM (Agile Distributed Delivery Model) en France.

Commentaire de Luc Legardeur, Président de Xebia :
« La crise incite les DSI a devoir faire autant ou plus qu’en 2008 avec moins de budget et cela en n’acceptant aucun compromis sur la qualité.
En nous appuyant sur l’expérience de nos collègues hollandais qui mènent depuis de nombreuses années des projets de ce type avec succès, nous avons décidé de travailler à l’implémentation de ce modèle en France. Nos expériences menées entre Xebia India et Xebia France étant très probantes, nous avons décidé de rendre disponible cette offre en France. Ce paradigme permet à nos clients de mener des projets en méthodes agiles tout en réduisant très sensiblement les coûts avec la garantie que l’Etat de l’Art des technologies Java/J2EE sera respecté. »

Pour en savoir plus sur Xebia ADDM, rendez-vous sur notre site web.