La conférence Européene de référence sur le Software Craftsmanship se tiendra cette année à Milton Keynes, en Grande Bretagne, non loin de Londres, ce Jeudi 26 mai. Aprés un conférence 2010 réussie, réunissant les pionniers du mouvement Craftsmanship, cette année s’annonce tout aussi prometteuse.
Ordinateur portable avec IDE obligatoire pour cette journée qui s’organisera autour de
4 tracks en paralléles, essentiellement des sessions hands-on. On va voir du code.

Voici quelques sessions issues du programme :

• Is TDD Slower In The Short Term?
• Enhancing Legacy Test Suites
• How Object Oriented Are You Feeling Today?

Plus de détails sur les sessions se trouvent sur le site de jotform

Nous serons 3 sur places et vous retrouverez sur notre blog nos retours sur cette conférence différente et vous pourrez suivre en live sur le compte Twitter de  @morlhon.

Ceci est une fiction. Toute ressemblance avec des personnes existant ou ayant existé serait totalement fortuite.

Palais de justice de Paris, lundi 21 mars.

Une fois n’est pas coutume, des développeurs sont assis sur le banc des accusés! Ils sont inculpés de faire perdre des millions d’euros à nos chères compagnies du CAC40 en écrivant du code voué à crouler sous son propre poids.

Mr Tedd, praticien du Test Driven Development, est aujourd’hui jugé ainsi que quelques uns de ses collègues : Mr Whatever, Mr Guru, Mrs Clickaway et Mr Testafter.

Prévoyant et confiant, il sera défendu par son avocat : Maître Darrow. Ils ont convenu ensemble de la stratégie à adopter: il faudra pointer du doigt les mauvaises habitudes souvent utilisées et mettre en avant les bonnes pratiques qu’il a appliqué tout au long des projets qui lui ont été confiés.

L’audience est ouverte

Le Président, Mr Beck, ouvre la séance en rappelant les chefs d’accusations aux jurés:

• Le code applicatif contient trop de bugs
• Le code applicatif n’est pas testé
• Le code applicatif est pour la plupart du temps incompréhensible et reste trop volumineux pour le nombre de fonctionnalités
• La modification et l’amélioration du code applicatif existant est trop risqué à entreprendre

La parole est à la défense. Maître Darrow, soucieux de capter l’attention de son audience, rappelle le contexte:

Nous sommes en 2011. Dans les missions dans lesquelles mon client, Mr Tedd, intervient, écrire du code représente 80% de son temps. Ce code capture des règles métiers plus ou moins complexes et qui évoluent dans le temps. Visuellement son travail se traduit souvent par ce qu’on appelle un front end sur lequel un utilisateur tel que vous et moi pouvons interagir. Un bon exemple serait un site de réservation de billets de train au niveau Européen. Vous voyez donc, Messieurs et Mesdames les jurés que l’enjeu est de taille, l’erreur coûte chère et qu’elle n’est donc pas acceptable.

Aujourd’hui, je vais vous démontrer que mon client, Mr Tedd, adopte les pratiques adéquates pour rendre son code fiable, évolutif et pérenne.

Laissez-moi d’abord vous présenter quelques types classiques de développeurs. Si je n’enlève rien aux connaissances techniques et aux talents d’ingénieurs de ces personnes, je leur reprocherais cependant une attitude trop laxiste quant à la fiabilité et la pérennité du code qu’ils soumettent mais aussi une négligence au regard des méthodes qui permettraient d’améliorer considérablement la qualité globale des projets auxquels ils participent.

Permettez-moi de commencer par le cas de Mr Whatever.

Mr Whatever

Tous les regards se tournent vers ce grand gaillard assis au bout du banc des accusés.

Mr Whatever, si vous me permettez de vous citer, vous m’avez dit :

« Moi je fais juste confiance à mon code. Il compile c’est donc qu’il fonctionne. »

Je pense que Mr Whatever n’est jamais resté assez longtemps dans les entreprises pour lesquelles il travaillait pour savoir que son code en production posait plus de problèmes qu’il n’en résolvait. Je rappelle pour les profanes dans l’assistance, que la production est la plateforme exposée au grand public donc aux vrais utilisateurs. C’est dans cet environnement que la charge sur le système se révèle soutenue et que, potentiellement, tous les chemins possibles dans le code écrit sont réalisés en concurrence !

Le problème de Mr Whatever est qu’il ne sait réellement si son code fonctionne que lors de la phase de tests intensifs. Pour lui, tester c’est la tâche de ce que l’on appelle l’équipe de QA, tiré de l’anglais Quality Assurance, et qui s’assure de la qualité du logiciel fournit. Si son code ne fonctionne pas, ils le lui indiqueront et il corrigera. On voit bien que sa responsabilité de fournir du code qui fonctionne lui échappe.

L’avocat se tourne vers l’audience et continue :

Nous ne nous attarderons pas plus sur le cas de Mr Whatever, il appartient à une génération un peu dépassée par les événements.

Cette dernière phrase entraine de légers gloussements dans l’assistance.

Mr Guru

Maître Darrow, après avoir jeté un rapide coup d’œil aux papiers étalés sur son bureau, se tourne vers la personne assise aux côtés de Mr Whatever.

Passons au cas de Mr Guru. Cas intéressant puisqu’il représente l’archétype de l’informaticien auquel on accorde toute sa confiance !

Ses connaissances et son expérience en font un expert dans l’écriture du code. Cependant, il ne teste jamais ce qu’il écrit. Il n’introspecte pas. Perte de temps pour lui ! Il a écrit assez de plateformes pour savoir comment écrire la vôtre. Très bien. Nous aurons alors un code de qualité. Cette affirmation est correcte si votre équipe n’est formée que de Mr Guru ! Situation atypique s’il en est, et bon courage pour les batailles d’ego. Mais bon … passons.

L’avocat lève le bras pointant l’index vers le plafond et lance :

Si notre postulat de départ est que les entreprises ne travaillent qu’avec des profils tels que celui de Mr Guru, voici les problèmes que cela entrainerait :

Maître Darrow marque un silence pour permettre aux jurés de bien se concentrer sur ce qui va suivre.

Le premier problème serait une pénurie rapide de Mr Guru sur le marché. Toutes les entreprises ne pourraient pas en recruter et seraient dans l’incapacité de produire des applications de qualité. Un peu fantasque je vous l’accorde, mais totalement valide avec le postulat de départ.

Le deuxième problème impacterait le budget de l’entreprise. Un Mr Guru cela coûte cher ! Combien seriez-vous prêt à dépenser pour une armée de Mr Guru ?

Le dernier souci, et non des moindres, serait de s’assurer qu’on ne recrute que des Mr Guru. S’il y a un responsable des ressources humaines dans la salle, il m’accordera que la tâche se révélera ardue. Par ailleurs, je note aussi qu’il arrive à Mr Guru d’être fatigué ou d’être ennuyé, Guru ou pas, il reste humain. De ce fait, il est toujours possible qu’un expert introduise des erreurs dans votre code de production sans le vouloir.

De plus une question se pose. Faut-il bannir les développeurs juniors de votre équipe de développement ? Avons-nous peur qu’ils insèrent des erreurs dans le code ? Un bon manager vous dira que cela serait une faute. Une équipe doit être hétérogène en caractère. Pourquoi se couper du dynamisme des développeurs juniors, de la facilité avec laquelle ils manient les dernières technologies et de leur passion encore verte pour la programmation ?

Après une longue pause, l’avocat fixe chaque membre du jury tour à tour, et conclut :

Nous voyons bien qu’en réalité une équipe est constituée de profils différents et hétérogènes en compétence. Il nous faut donc une pratique commune de développement qui nous assure que Mr Guru et son collègue, plus junior, écrivent leur code d’une manière uniforme et testée sans porter atteinte à leur créativité.

Dans la salle, quelques personnes opinèrent du chef. Sûrement des développeurs!

Mrs Clickaway

L’avocat se rapproche de quelques pas du jury tout en désignant de la main la jeune femme assise au milieu du banc des accusés.

Maintenant le cas touchant de Mrs Clickaway. Mrs Clickaway est bien intentionnée. Elle veut savoir si son code fonctionne. Pour cela elle adopte un cycle rapide d’écriture de code, et de déploiement de son application dans son environnement local. Pour tester, elle clique et re-clique jusqu’à ce qui lui semble avoir parcouru tous les recoins des fonctionnalités qu’elle a implémentées. Pourtant, Mrs Clickaway utilise très mal son temps de développement. Pour les plus techniciens d’entre vous, je dirais qu’elle oscille entre stacktrace, long démarrage de serveur et debuging en tous genres !

En effet, alors qu’elle aurait l’opportunité d’écrire son code tout en l’introspectant, grâce aux trés bonnes librairies logicielles mises à disposition aujourd’hui, elle choisit de tester en mode boite noire. Pour les profanes dans la salle, le mode boîte noire est une série de tests qui se fait à un haut niveau de l’application sans se préoccuper réellement de la structure et du fonctionnement interne.

Je reproche donc à Mrs Clickaway de ne pas se concentrer sur son coeur de métier qui est la production d’un code propre et fiable. Pour être franc, je pense que Mrs Clickaway n’est jamais sûre de ce qu’elle écrit et qu’elle veut se donner bonne conscience avant de livrer son code à l’exploitation.

Je vous le dis, ne pas choisir l’introspection, c’est ne pas choisir de réfléchir sur ce que l’on produit et c’est ne pas choisir l’amélioration de son propre code. Mesdames et Messieurs les jurés, vous m’accorderez que c’est un peu surprenant et relève d’un comportement irresponsable pour un développeur.

Sur le banc des accusés Mrs Clickaway semble anéantie et confuse par cette série d’accusations.

Mr Testafter

Passons maintenant à mon cas favori. Mr Testafter.

Mr Testafter est sur la voie de la rédemption, seulement il a pris à gauche alors qu’il fallait prendre à droite ! Que je vous explique. Mr Testafter a bien compris qu’il fallait tester son code. Cependant, il écrit les tests après avoir écrit ce fameux code de production. Normal vous me direz. Eh bien non ! Cela pose plusieurs problèmes:

Comme tous les développeurs, Mr Testafter passe beaucoup de temps à écrire son code. Quand il en a enfin fini, c’est un soupir de soulagement avec une pause café bien méritée. Enfin jusqu’à ce qu’il réalise qu’il n’a écrit aucun test ! Pour ne rien arranger, il a déjà indiqué fièrement à son manager que son travail était fini. Qu’à cela ne tienne, il va ajouter rapidement les tests, parce qu’après tout, il n’a pas que ça à faire.

C’est à ce moment qu’il doit faire un effort non négligeable: se remémorer les spécifications, imaginer des cas d’utilisations pour finalement… relire son code afin de savoir quoi tester !

L’avocat lance un regard vers Mr Testafter sur le banc des accusés. Ce dernier fixe le plafond.

Idéalement, s’il veut que ses tests soient utiles, c’est-à-dire compréhensibles par un autre développeur, clairs, découpés en spécifications et couvrant toutes les fonctionnalités, il doit reprendre sa réflexion à zéro.

Cependant, Mr Testafter à ce moment précis est pressé. Il n’adoptera pas une démarche d’écriture « fonctionnalité par fonctionnalité ». Plus grave, il ne pensera pas aux effets de bord, car puisque son code est déjà écrit, il est censé fonctionner ! Summum du contre-sens, pour les praticiens du TDD dans la salle, Mr Testafter ne passe pas par la phase d’un test qui échoue. En réalité, Mr Testafter ne voit aucun test échouer ! Bizarre pour quelqu’un qui veut savoir si son code fonctionne.

Une fois les tests ajoutés, laissez-moi vous décrire le résultat, cela se vérifie presque à chaque fois. Il y a toujours plus de code généré qu’il n’en faut et le code contient de la duplication. Mr Testafter n’est pas dans une optique de code minimal pourtant si importante dans les énormes bases de code d’aujourd’hui. Les tests sont désordonnés, ne sont pas organisés en terme de fonctionnalités et contiennent eux aussi de la duplication.

Invariablement aussi, une fois les tests ajoutés, le code restera tel qu’il a été écrit à l’origine. Pas d’optimisation, de minimalisation ou de recherche d’expressivité du code. Le plus grave cependant est d’obtenir ce que l’on appelle un effet gruyère sur la classe testée: des bouts de code resteront non testés. Pour ceux qui me suivraient encore dans l’assistance, je ne vous conseille pas de refactorer du gruyère !

Sur cette dernière phrase, l’audience se partage entre face crédules et sourires.

Mr Tedd – Vers un code agile

Il est l’heure maintenant pour Mr Darrow de défendre son client. Il tient à expliquer aux jurées les principes fondamentaux sur lesquelles repose la méthode que son client Mr Tedd utilise. Il enchaine alors :

A travers les différents profils que je vous ai présenté, nous avons pu voir les insuffisances de certaines techniques de développement.

Laissez-moi donc maintenant vous résumer la manière d’écrire du code applicatif la plus à même à répondre à la problématique de tolérance au changement du monde du logiciel. C’est celle que pratique mon client. C’est le Test Driven Development. Cette méthodologie se résume avec la phrase suivante :

Tout code de production a été écrit pour faire passer un test qui au départ échouait.

Ce postulat pour certains peut sembler abstrait, cependant il se met en pratique tous les jours avec succès. Laissez-moi maintenant énumérer les corollaires directs de ce postulat.

Dans la salle on aurait pu entendre une mouche voler. L’avocat commence à énoncer :

Tout code de production est donc testé. Il n’y a pas plus de code que de fonctionnalités voulues et votre base de code est donc minimale. Toute fonctionnalité étant couverte par un test, vous savez instantanément lorsqu’un test échoue qu’une fonctionnalité n’est plus respectée et vous pouvez prendre aussitôt les mesures appropriées.

Ce code, proprement testé, vous pouvez le simplifier, l’améliorer et le nettoyer sans risque. C’est ce que l’on appelle le refactoring. Votre code devient par conséquent malléable, flexible et donc agile. C’est le moyen d’éviter que votre code ne s’effondre sous son propre poids !

L’avocat continue :

Mesdames et Messieurs les jurés, je vous le demande : Pour ceux qui connaissent le monde du logiciel, quel est le mot le plus important dans l’agilité?

Au vu des visages dubitatifs du public, et de cette femme âgée assise au premier rang qui avait commencé à tricoter, Maître Darrow comprit qu’il aurait à apporter lui-même la réponse.

Le Feedback ! Voilà le concept le plus important à mettre en place. Le Test Driven Development vous permet de mettre en place la plus petite boucle de feedback du monde agile. Instantanément vous savez si votre code répond à vos exigences.

Alors que Mr Darrow est au beau milieu de la défense de son client, le président Mr Beck, avec un geste d’impatience de la main, déclare :

Merci Mr Darrow. Cependant, avant que vous poursuiviez, l’avocat de la partie civile souhaite interroger maintenant votre client Mr Tedd. Et exceptionnellement, je ly’autorise.

Mr Darrow ne peut qu’abdiquer et Mr Tedd se dirige alors vers la barre pour être interrogé. C’est alors qu’un petit homme au front suintant, très agité, s’avance au centre. C’est Mr Pascal, l’avocat de la partie civile. Le contre interrogatoire peut commencer.

La suite du procès dans un prochain article.

Les rétrospectives pourront ainsi aider les équipes à améliorer leur productivité mais aussi les compétences de ses membres ou encore la qualité de ce que l’équipe produit. Leur but va donc bien au delà d’une analyse post-mortem d’une itération de développement de laquelle découlerait une amélioration des processus de développement.

Dans cet article, nous allons vous donner quelques clés pour vous aider à comprendre les enjeux et à mieux piloter vos rétrospectives.

L’origine des rétrospectives : le Kaizen ou la pratique Lean de l’amélioration continue

La rétrospective telle que nous la connaissons dans les méthodologies de développement agile tire son inspiration dans le milieu industriel et plus particulièrement automobile avec l’outil nommé Kaizen venant du Japon et faisant partie de l’outillage de la méthodologie Lean. Le Kaizen, littéralement « changement bon » est une méthodologie d’amélioration continue dont Toyota fut l’un des précurseurs.

Le Kaizen repose sur différents principes :

• tenter d’améliorer chaque règle de travail (working agreements),
• développer les compétences et l’implication de toute l’équipe,
• se focaliser sur la cause racine des problèmes,
• améliorer les processus afin de gagner en productivité.

Cette démarche de développement continu introduit le changement de manière graduelle et ne repose donc pas sur des réformes complètes et brutales du système du type «on efface tout et on recommence». Dans cette démarche, chaque travailleur est impliqué et est force de proposition pour améliorer sa manière de travailler.

Les méthodes agiles ont repris ce principe pour l’intégrer au sein du cycle de développement. Dans la méthodologie agile Scrum par exemple, une itération de développement, est constituée de différentes cérémonies :

• une session d’estimation en début d’itération,
• un stand up meeting chaque jour,
• une démonstration des fonctionnalités développées,
• une rétrospective.

La rétrospective est donc une partie intégrante du cycle de développement, et du travail de l’équipe.

Pourquoi mettre en place une démarche d’amélioration continue ?

Nous vivons dans un monde où les besoins de nos clients, les technologies ou encore la concurrence évoluent en permanence. Dans ce contexte, il est donc nécessaire de faire évoluer nos méthodes de travail afin de rester en phase avec les attentes du marché.

De plus, le fonctionnement d’une équipe est rarement parfait, il peut exister des tensions, des malaises, des regrets et d’autres sources de démotivation que les rétrospectives peuvent aider à découvrir et à traiter. La motivation d’une équipe est effectivement quelque chose qui s’entretient en supprimant les causes de démotivation, et non en essayant de motiver coûte que coûte en faisant fi des problèmes.

Différents axes de progression sont possibles lorsque l’on cherche à améliorer le fonctionnement d’une équipe de développement comme par exemple :

• la productivité de l’équipe,
• les compétences et les connaissances de chacun,
• la cohésion de l’équipe et la collaboration de ses membres,
• la communication interne ou externe,
• la qualité de ce qui est produit,
• l’intérêt et la motivation des collaborateurs,
• les règles de travail (working agreements),
• etc.

Cette liste est loin d’être exhaustive et bien d’autres axes de progression peuvent être abordés au cours des rétrospectives.

Les rétrospectives permettent d’explorer différents axes de progression et permettent aux équipes de s’accomplir au mieux dans chacun d’eux. Avant de continuer, nous allons nous intéresser à la manière dont l’un de ces axes pourrait être abordé et ce qui pourrait en découler.

L’amélioration de la productivité de l’équipe

Avec l’évolution actuelle des méthodes de développement, qui portées par des mouvements tels que le Craftsmanship tendent à nous orienter vers une culture du travail bien fait, la recherche de la productivité pourrait être perçue comme allant à contre courant. Bien évidemment il n’en est rien si on part du principe que cette recherche de productivité ne va pas à l’encontre de la qualité et si elle s’inscrit dans la durée. En effet, une mauvaise productivité peut être le signe de nombreux problèmes que les rétrospectives peuvent aider à mettre en exergue et à résoudre.

Pour commencer, qu’appelle-t-on « mauvaise productivité » et qu’est ce qu’une « bonne productivité » ? Ces notions sont particulièrement subjectives et il est difficile d’établir une règle permettant de les définir. Nous recommandons donc de s’attacher à étudier l’évolution de la vélocité de l’équipe de développement plutôt que sa valeur absolue. Cette notion de vélocité est utilisée dans des méthodes de développement agile comme Scrum. Elle représente la somme de travail effectuée sur des tâches terminées (selon la Definition of Done de l’équipe).
Une évolution à la hausse de cette vélocité peut indiquer une prise de maturité de l’équipe par rapport au projet, un projet sain etc.
En revanche, une évolution à la baisse pourra soulever des problèmes de qualité (probablement dûs à une dette technique élevée), des conflits au sein de l’équipe, des problèmes d’organisation, etc.

L’étude de cette évolution devra se faire sur plusieurs itérations afin de permettre à l’équipe d’en tirer des conclusions pertinentes. En effet, une vélocité en dents de scie pourrait par exemple mettre en avant des développements rapides mais de piètre qualité, suivis d’itérations où l’équipe corrige les anomalies qui en découlent.

Une fois les problèmes détectés et les causes analysées, l’équipe cherchera des idées afin d’y remédier et mettra en place des actions permettant d’améliorer la productivité. Nous verrons dans la suite de cet article les méthodes permettant de conduire cette réflexion et d’établir les actions à entreprendre.

Pourquoi ne pas se contenter d’appliquer les « bonnes pratiques » ?

Dans le but de rester performant et concurrentiel, pourquoi ne pas se contenter d’un peu de veille et d’appliquer les différentes pratiques reconnues comme efficaces et développées par les experts des méthodologies de développement ?

Premièrement, il existe un nombre très important de bonnes pratiques et il est impossible de toutes les appliquer. De plus, les méthodologies n’étant pas toujours compatibles entre elles, nous nous retrouverions souvent à devoir faire un choix cornéliens entre telle ou telle méthodologie. Enfin, ces méthodologies elles même évoluent en permanence et nous incitent par la même occasion à faire de même, nous plongeant dans une spirale sans fin d’adoption de nouvelles méthodes de travail à appliquer « by the book ».
Une approche plus pragmatique est donc conseillée. Elle consiste à essayer et adapter tout ou une partie de ces méthodes, en réponse à un besoin ou à un problème. Ce dernier point est particulièrement important, les réponses apportées par une méthodologie doivent effectivement découler d’un problème levé par l’équipe de développement. Il n’est donc pas nécessaire d’apporter une réponse (nouvelle méthodologie) s’il n’y a pas de problème.

Deuxièmement, les équipes de développement sont différentes les unes des autres. Les personnes qui les constituent, le contexte du projet, les technologies employées, la culture de l’entreprise etc. sont autant de paramètres à prendre en compte dans le choix d’une méthodologie plutôt qu’une autre. Il est donc impératif que l’adoption d’une méthodologie soit unanime et non imposée. Prenons l’exemple du pair programming, cette méthodologie qui consiste à développer en binôme est assez peu répandue malgré ses vertus. Son adoption est souvent difficile pour plusieurs raisons : incompréhension de la direction, acceptation nécessaire du regard critique de son binôme sur notre manière de développer, adoption d’un rythme différent, etc. Sans un engagement complet de l’équipe, il ne sera pas possible de mettre en œuvre ce genre de méthodologie. Si les membres de l’équipe n’y adhèrent pas, il sera difficile de la mettre en place.

Devant l’opulence des méthodologies et les différences entre les équipes de développement, il est nécessaire de continuellement adapter nos méthodes de travail et d’en expérimenter de nouvelles. C’est précisément le but des rétrospectives, que nous allons étudier dans la suite de ce document.

Le principe « inspecter et adapter »

L’amélioration continue fait appel à la rétrospective comme outil d’analyse et de prise de décision. Elle repose globalement sur les phases suivantes :

• identification des problèmes,
• détermination des causes d’origine ( root cause analysis ),
• définition des actions à entreprendre pour remédier à la cause racine.

Cette méthodologie nécessite une importante dose de courage afin d’aborder les problèmes et leurs causes racines. Il peut en effet être éprouvant d’effectuer cet exercice – qui est malgré tout nécessaire – car si les problèmes de fond ne sont pas abordés, l’équipe est condamnée à ne plus progresser.
Cette constatation rejoint le paradoxe de Stockdale qui peut être défini de la manière suivante :
« Nous devons croire en nos capacités à réussir » et en même temps « être capable de se confronter à la plus brutale des réalités, quelle qu’elle soit ».

La démarche d’amélioration continue nécessite donc que les problèmes ne soient pas « cachés sous le tapis » mais bien au contraire, exposés au grand jour afin de trouver leur origine et les actions à entreprendre afin de les régler.

Les working agreements

Un peu plus tôt dans cet article, nous avons parlé des règles de travail ou working agreements et nous allons maintenant les définir.

Les working agreements sont des valeurs et accords érigés par l’équipe de développement. Ils appartiennent à l’équipe et ont pour rôle de responsabiliser chaque membre. Certains accords définissent des interactions et processus entre les différents acteurs du projet dans le but d’optimiser l’efficacité de l’équipe. Ces working agreements se développent et s’ajustent au fil du temps. Afin que tout le monde les ait en tête, on peut les afficher sur un tableau à la vue de tous.

Voici quelques exemples de valeurs : qualité, simplicité, travail d’équipe, courage. Ou encore quelques exemples de règles: heure et lieu du stand-up meeting, définition d’une* user story “done”, disponibilité du product owner, etc. Il peut être utile, voir nécessaire de définir des workings agrements dans le cadre d’une rétrospective lorsque l’équipe manque de discipline.

Structure d’une rétrospective

La rétrospective fait partie intégrante du cycle de développement. Elle se déroule à la fin de chaque sprint ( ou itération). Au démarrage de la rétrospective, l’animateur définit l’agenda, les enjeux et les objectifs de la rétrospective, et peut être amené à rappeler les working agreements. Le début de la réunion peut aussi être propice pour faire une petite synthèse du dernier sprint et remercier l’équipe pour ses efforts.

Basées sur le principe Inspect and Adapt présenté précedemment, les rétrospectives sont structurées en cinq étapes amenant l’équipe à identifier les problèmes et dysfonctionnements et à trouver des solutions afin d’améliorer le processus de développement. La rétrospective est une réunion timeboxée, la gestion du temps est très importante.
Ci-dessous, vous pouvez observer les cinq étapes d’une rétrospective, ainsi qu’un pourcentage de répartition de chacune sur la durée totale de la réunion:

• définir la réunion (5%) : définir l’agenda, les enjeux et les objectifs de la rétrospective, et rappeler les working agreements si nécessaire,
• collecter les données (30-50%) : créer une vision globale et partagée de tous,
• trouver des idées (20-30%) : identifier les forces et les faiblesses, analyser les causes et trouver des solutions,
• décider des actions à mener (15-20%) : sélectionner quelques actions à mener aux prochains sprints,
• conclure la rétrospective (10%) : dé-briefer sur la réunion, noter les décisions et remercier les participants.

Par ailleurs, il peut être utile de garder du temps (5-10%) en réserve pour se prémunir des débordements.

L’organisation spatiale de la salle de réunion est aussi une donnée à ne pas négliger. En effet, une barrière physique peut rapidement devenir une barrière mentale. Éviter les salles de type « théâtre” et privilégier un espace circulaire ou semi-circulaire pour que tout le monde puisse se voir et communiquer facilement.

Les activités

A chaque étape d’une rétrospective sont associées des activités. Armé de papiers, de crayons, et de post-its, l’équipe travaille et réfléchit dans un cadre ludique et studieux. Selon la taille de l’équipe, et afin de favoriser la participation de tous, des sous-groupes peuvent être formés temporairement pendant la réalisation d’une activité. D’autre part, les activités sont sensées permettre d’apporter de nouvelles perspectives et un cadre pour aider les participants à réfléchir ensemble. Il peut y avoir plusieurs activités par étape.

Les activités sont étudiées pour répondre aux principes ARCS :

• Attention : Garder la concentration des participants,
• Relevant : Pertinent par rapport aux objectifs,
• Competence : Tous les participants peuvent accomplir les tâches,
• Satisfaction : Ne pas avoir le sentiment d’avoir perdu son temps.

Un prochain article présentera de manière plus détaillée chacune des étapes d’une rétrospective, et nous verrons aussi des exemples d’activités.

Les rôles du retrospective leader

L’animateur de la rétrospective (ou retrospective leader) n’est pas nécessairement le Scrum Master. Ce rôle peut tourner entre les différents membres de l’équipe.

Préparer la rétrospective

La première fonction du leader est de préparer la rétrospective. Pour deux heures de réunion, il faut parfois compter la même durée pour la préparation. Il définit alors les activités de la rétrospective en fonction de divers paramètres comme la taille de l’équipe, la complexité du projet, et choisit les activités. Pour se prémunir des débordements durant la réunion, une astuce est de sélectionner en seconde option des activités plus courtes.

Animer le groupe de travail

La seconde fonction du leader est d’animer la réunion. Tout d’abord, il contrôle le temps passé sur chaque activité. Cette tâche peut aussi être déléguée à un autre participant. Par ailleurs, il est le garant des Working Agreements et s’attache à les faire respecter par tous.
Avant de commencer une activité, l’animateur présente son déroulement et rappelle les objectifs de celle-ci (exemple: collecter un ensemble de données réparties sur une période afin d’obtenir une vision partagée par tous). Pendant l’activité, il répond aux questions et observe attentivement le niveau de participation. Il peut aussi être amené à recadrer l’activité en cas de débordement.

Le facilitateur

En tant qu’animateur d’un groupe de travail, le leader a aussi un rôle de facilitateur. Le facilitateur est une personne neutre qui ne prend pas parti, et n’expose pas son point de vue durant la réunion. Il met en place des méthodes pour aider le groupe à travailler efficacement. Pour parvenir à cela, il encourage la participation de tous, favorise la compréhension mutuelle et cultive la notion de responsabilité partagée.

L’art de gérer le « facteur humain »

Les individus d’une équipe en tant qu’êtres humains ont des émotions et sentiments. Les rétrospectives exposent un certain nombre de problèmes d’origines variées. Elles sont parfois sources de tensions et de conflits au sein de l’équipe. Chaque individu étant unique, celui-ci réagira différemment à une situation donnée. La manière de gérer les rapports humains et la communication avec les autres sont des enjeux importants pour que la réunion apporte une réelle valeur à l’équipe et au projet. On comprend alors la nécessité pour l’animateur de faire preuve d’empathie, d’avoir un sens de l’observation, et une certaine maîtrise de soi.
Son rôle consiste alors à désamorcer les tensions et attaques directes, qui n’apportent rien aux problèmes de fond. Il peut aussi amener les individus à exprimer leurs émotions de manière subtile, afin de libérer en eux des ressentiments inexprimés. Par exemple, au lieu d’employer la question directe à un membre: « Qu’as-tu ressenti durant ce dernier sprint ? », utiliser plutôt celle-ci: « Quels sont les moments importants qui t’ont le plus marqué négativement et positivement ? ». Bien sur l’animateur n’est pas responsable des émotions de chacun. Il ne peut pas les contrôler, mais il doit faire en sorte que la réunion reste productive.
Par ailleurs, il peut s’appuyer avec parcimonie sur des méthodes et techniques psychologiques. Sans rentrer dans le détail de cette science, voici deux exemples pour illustrer notre propos.

Le langage Je/Il

Version Il: « Julien n’a pas arrêté de casser le build ! »
Version Je: « J’avais peur que nous rations notre objectif, car nous avons eu beaucoup de build cassés. »
Encourager l’emploie du pronom « Je » plutôt que « Il ». En effet, le « Je » centre le débat sur l’observation et l’expérience de l’intervenant, plutôt que de blâmer une personne. Lorsque quelqu’un critique ou attaque personnellement une autre personne, il faut intervenir et recadrer la discussion sur le contenu, afin de découvrir les causes réelles d’un problème.

Le triangle de Karpman

Le triangle de Karpman représente trois rôles: La victime, le persécuteur, et le sauveteur.
C’est un modèle qui tend à exprimer, que si une personne utilise un de ces rôles (par exemple la victime), elle entraîne l’autre à jouer un rôle complémentaire (le Sauveur ou le Persécuteur). Il peut aider à comprendre les mécanismes ayant généré un conflit. Ainsi, L’animateur avisé pourra éviter de rentrer dans le rôle du sauveteur, chose qui arrive bien souvent quand un membre s’en prend à un autre.

Conclusion

Dans ce premier article, nous avons introduit ce que sont les rétrospectives et leur utilité. Nous avons vu que les rétrospectives s’inscrivent dans une démarche d’amélioration continue. Elles permettent aux équipes et aux membres qui les composent de progresser et de mieux collaborer.
Nous avons aussi vu que les rétrospectives s’articulent autour du principe Inspect and Adapt qui nous force à réaliser une analyse en profondeur des problèmes avant de leur apporter des solutions.

Ces rétrospectives sont animées par un Leader ayant pour rôle de faire en sorte que le temps investi dans la rétrospective soit rentabilisé au mieux (ceci commence par le respect du temps imparti). Le retrospective leader est aussi responsable du choix des activités et du bon déroulement de la séance de travail.

Dans le prochain article, nous détaillerons les différentes phases des rétrospectives et nous vous proposerons quelques activités inspirées du livre d’Esther Derby et de Diana Larsen, Agile Retrospectives: Making Good Teams Great.

Agile 2010 est la principale conférence internationale sur les méthodes agiles dans le développement logiciel. Elle se tiendra du 9 au 13 août 2010 à Orlando en Floride.
La conférence Agile 2010 réunit de nombreuses disciplines dans les domaines des Systèmes d’Information et du développement logiciel. Elle crée ainsi des ponts entre des communautés qui ont rarement l’occasion d’échanger autour de leurs idées.

Lors de l’édition 2010, 3 Xebians auront le plaisir d’être sur scène pour vous faire partager leurs expériences et leur vision :

• Guido Schoonheim (CTO du groupe Xebia) présentera une session intitulée « Mind the Gap! Principles of hyperproductive fully distributed Scrum ».
• Maurits Rijk (Consultant senior chez Xebia) présentera une session intitulée « A graphical approach to improve the cost/benefit ratio of user stories ».
• Wilco Koorn (Scrum Master et Team Member chez XebiaLabs) présentera une session intitulée « Unleash the Agile power: bridge the Gap between Development and Operations ».

Mind the Gap! Principles of hyperproductive fully distributed Scrum

• Presenter: Guido Schoonheim (CTO of Xebia Group)
• Level: Practicing
• Presentation: The author and Jeff Sutherland previously showed (at Agile2008,2009) Scrum teams using XP practices achieved distributed velocity equal to local velocity with multiple distributed teams. This was shown under extreme timezones and at large scale development. The authors have formalized the principles & practices that are the foundation for hyperproductive fully distributed Scrum. This framework has been published as free e-book and is the subject of this presentation. New experiences and figures on recent projects will be shared to illustrate the pitfalls and success points.

A graphical approach to improve the cost/benefit ratio of user stories

• Presenter: Maurits Rijk (Senior Consultant at Xebia)
• Level: Practicing
• Short summary: User stories are a great way to capture requirements and are successfully used in many projects. Every user story comes with a business value and a effort needed to implement the story, usually in software. Since there are almost always more requirements than budget (or any other limiting factor like time, available resources, etc) decisions have to be made on which stories to pick up in which order. Usually the stories are prioritized by the product owner and put on a textual product backlog. We will show how a graphical overview will stimulate the right side of our brains.

Unleash the Agile power: bridge the Gap between Development and Operations.

• Presenter: Wilco Koorn (Scrum Master and Team Member XebiaLabs)
• Level: expert
• Short summary: Enterprises traditionally distinct Development focusing on the creation of software and Operations focusing on the infrastructure. A natural gap between the two is caused by their key interest: change versus stability. Introducing Agile in Development confronts Operations with more work due to increased productivity and release frequencies. The power of Agile is not unleashed. A case study at KLM/Air France shows how this impediment was overcome and huge savings were achieved by implementing a self-service change control process for Development still under full control of Operations.

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

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

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.

Le Scrum User Group France, organe affilié à la SCRUM ALLIANCE, a mené, pendant deux mois, une enquête nationale, ouverte à tous, par l’intermédiaire de son site (www.frenchsug.org) afin de collecter des données qualitatives et quantitatives sur l’adoption en France des méthodes agiles les plus utilisées par ceux qui ont décidé d’emprunter le chemin de l’agilité.

Pour télécharger les résultats de cette enquête, suivez le lien suivant.

Pour qu’elle soit significative, il faut qu’un maximum d’entreprises utilisatrices répondent.

Il y a une WII à gagner lors du tirage au sort organisé à la prochaine soirée, « Le World Café » organisé par le French Scrum User Ggroup, le 18 Juin 2009 à l’École EPITA (s’inscrire à la soirée).

Alors, participez-y afin d’aider la communauté Agile francophone à avoir de vrais chiffres sur Scrum et XP.

Vous êtes en quête d’idées neuves pour rendre plus efficaces vos projets de développement logiciels ?

Vous souhaitez en savoir plus sur les méthodes agiles, leurs bénéfices, leurs limites …
Vous avez mis en place des pratiques agiles au sein de vos projets et vous souhaitez confronter vos retours d’expérience à ceux d’autres praticiens …

Rendez-vous les 25 et 26 mai 2009 pour la conférence XP Day France 2009.

Une conférence pour tous les intervenants des projets logiciels

Chefs de projet, clients, décideurs, développeurs …
Loin des conférences « académiques » ou des événements commerciaux, le succès du format XP Day s’explique par son orientation pragmatique.
Avec plus de 160 inscrits pour sa troisième édition en 2008, XP Day France est le rendez-vous à ne pas manquer si vous souhaitez des réponses concrètes, des idées que vous pouvez immédiatement mettre en pratique.

De nombreux thèmes sont abordés

Le programme 2009 est en cours de finalisation. Consultez les programmes précédents pour vous faire une idée des types de sessions proposées :

• Construction logicielle (TDD, refactoring, binomage, intégration continue …).
• Animation d’équipe et leadership.
• Outils.
• Agilité : performance et culture d’organisation.
• L’impact dans l’entreprise et l’organisation.
• Expérience utilisateurs.

Edition 2009 : un décor hors du commun !

Situé sur une île en plein milieu du bois de Vincennes, Le Chalet de la Porte Jaune est noyé dans la verdure. Une pause sous un arbre du jardin ou une promenade en barque entre deux ateliers … A vous de planifier vos journées au rythme des lieux.
Bâtiment classé monument historique, le Chalet est aussi réputé pour sa restauration de très haute qualité. Tous vos déjeuners, pauses et dîners seront concoctés par l’ancien chef du Train Bleu dont la réputation n’est plus à faire.

Avez-vous remarqué l’influence étonnante que peut avoir un Manager sur son équipe, sur une organisation, sur le comportement de ses collaborateurs, sur une culture d’entreprise et cela à quelque niveau hiérarchique que ce soit ?

L’équipier de chez Mac Donald sera d’une efficacité redoutable dans la préparation de votre Big Mac préféré car dans cette entreprise, le souci du Management est le respect du process. Aux antipodes de ce paradigme, l’ingénieur de développement de chez Google, lui, n’est pas contraint par les process, car au contraire, là bas, on pense que moins il y en a et plus la créativité des individus sera mise à contribution.

Réussir à transformer son organisation pour la rendre agile est donc avant tout, une question de mise en conformité en profondeur de l’état d’esprit collectif par une dynamique et volontaire impulsion managériale.
Le Boss doit donc mouiller sa chemise et vivre l’agilité de l’intérieur. Il doit avoir cela dans son code génétique (inné ou acquis), dans son ADN.

Justement, à propos d’ADN…vous rappelez vous les cours de Sciences Naturelles du collège ?

Un petit rappel. L’Acide Désoxyribonucléique (ADN) stocke l’information génétique ; information qui détermine le développement et le fonctionnement d’un organisme.

Pour faire simple, cette information génétique est transmise de génération en génération. Ce message (génétique) est transporté par l’ARNm (le messager) grâce à une vaste combinaison de nucléotides identifiés par des lettres T, A, G, C, …

Essayons maintenant d’établir un parallèle les lois de la génétique humaine et le fonctionnement d’une organisation.

Notre théorie consiste à affirmer que le fonctionnement d’une organisation est lui aussi, directement lié à l’ADN du Big Boss, à ses habitudes et à ses principes de Management.

Livrons nous donc à un exercice amusant : égrenons le chapelet de quelques principes Agiles (mais aussi quelques principes fondamentaux de Management) en empruntant le chemin de l’alphabet et mettons en face de chacun le bénéfice attendu. Vous suivez toujours ?

Sans vouloir jouer les apprentis sorciers ou les donneurs de leçons, nous pensons sincèrement que les quelques principes édictés ci-dessus sont propices à créer des organisations efficaces (des OGM -Organisations Génétiquement Modifiées- sous, nous en sommes sûrs, dans le cas présent, la bénédiction de José Bové).

Toute l’équipe Xebia vous présente ses meilleurs vœux pour 2009.

Agilité

• Scrum et XP depuis les tranchées
• Scrum de scrums

RIA

• FlexMonkey 0.5
• Sortie de SmartGWT

Le coin de la technique

• Améliorez la testabilité de votre code
• Nexus pour chercher dans les repositories Maven
• Distribuez vos tests JUnit avec GridGain
• Tomcat : Trucs et astuces des pros de SpringSource

Evènements de notre communauté en France et à l’étranger

• Sacha Labourey au Paris JUG mardi pour une soirée JBoss

Agilité

Scrum et XP depuis les tranchées

Le livre référence de Henrik Kniberg, disponible sur InfoQ, vient d’être traduit en français (disponible en pdf ici).
Guillaume Mathias (Xebia) a participé à cette aventure aux côtés de Bruno Orsier, Emmanuel Etasse et Christophe Bunn.
Merci aux auteurs pour ce formidable don à la communauté Agile francophone.

Scrum de scrums

Une des questions récurrentes concernant l’adoption des démarches agiles sur une large échelle est celle de la synchronisation de nombreuses personnes. À ce sujet, InfoQ revient sur l’un des outils proposés par la méthode, le Scrum de Scrums. Allan Shalloway expose les problématiques d’un ‘grand’ projet Scrum, où plusieurs équipes interviennent sur la réalisation de modules inter connectés :

• Problématique technique : adopter une démarche agile, c’est éviter de réaliser des fonctionnalités non nécessaires. Ainsi, si une sous équipe ‘A’ créé un service, dont l’équipe ‘B’ aura peut-être besoin dans une itération ultérieure, rien ne l’oblige à exposer ce service. Quand ‘B’ aura besoin du même type de service, plusieurs questions surgiront : ‘B’ est-il au courant de l’existence de ce service. Si oui, qui doit le modifier pour qu’ils répondent aux besoins de ‘A’ et de ‘B’ ?
• Synchronisation d’équipe : les Scrums Masters et les Product Owners ne sont pas les mêmes pour les équipes ‘A’ et ‘B’. Les problématiques de synchronisation sont évidentes si on se place du point de vue du product owner (Cette fonctionnalité existe t’elle déjà ? Est elle est prévue ? …)
• Intégration du produit final : il n’est pas simple de délivrer un produit final fonctionnant de bout en bout juste en accolant les composants développés par les différentes équipes.

C’est pour cela qu’a été pensé le Scrum of Scrums.
Allan Shalloway, dans le cadre de la rédaction de son livre « Lean Software Development: Scaling Agile to the Enterprise » a collecté les retours d’utilisateurs sur ce ‘super’ daily scrum.
Pour Mike Dwyer, le SoS sert à gérer la décomposition des users – stories afin de veiller à ce qu’une fonctionnalité ne soit pas réalisée en double.
Pour Ilja Preuß, le SoS permet d’identifier les points d’entraide possibles, les impacts des différentes équipes sur le système, mais surtout, cette réunion permet de renforcer le sentiment d’appartenance à un seul et même projet.
Christophe Louvion a utilisé le SoS pour gérer l’intégration des sous composants au jour le jour. Il a aussi utilisé le SoS pour maintenir une méta-équipe, composée de membres seniors de chacune des sous équipes, et chargée de gérer les problématiques transverses du projet (rédaction des normes, intégration end to end, revues d’architecture…)

Enfin, Walter Bodwell partage sa recette secrète pour un SoS pleinement opérationnel : il faut qu’il soit court (15 minutes), concis, centré autour de l’information qu’on veut communiquer aux autres. Toutes les problématiques particulières doivent être abordées dans des réunions en tête à tête. Le SoS doit permettre d’identifier les points bloquants, et de les rappeler à tous (tous les jours s’il le faut) jusqu’à leur résolution.
Enfin, comme la problématique des SoS est attenante à celle des équipes de développement distribuées, il peut être utile, afin de conserver au SoS une pertinence maximale, de préparer quelques notes pour la réunion.

RIA

FlexMonkey 0.5

Lors de l’une de nos revues de presse, nous vous présentions FlexMonkey (framework de tests automatisés OpenSource pour Flex).
Ce projet vient de voir arriver la version 0.5 et permet :

• Une configuration afin de pouvoir lancer FlexMonkey par des systèmes de build (et plus particulièrement Ant).
• Un refactoring de l’API afin de séparer l’UI et le core.
• Une séparation entre la gestion des tests automatisés (FlexMonkey.swc) et le runner FlexUnit (FlexMonkeyUI.swc).

Pour un produit aussi jeune, ce dernier permet d’effectuer des tests convenables sous une application Flex. L’automatisation des tests sous Flex lève une barrière à son adoption, alors qu’attendez-vous ?

Sortie de SmartGWT

Sanjiv Jivan, ex-auteur de GWT-Ext a annoncé hier la sortie de SmartGWT, un nouveau Wrapper GWT au dessus d’un Framework Javascript très complet : SmartClient.

Les plus de SmartGWT par rapport à GWT-Ext :

• La richesse des composants fournis par l’api.
• L’amélioration des performances (peu de temps de latence, utilisation de l’asynchrone systématique …).
• Un code Java plus léger et plus consistant.
• Une intégration avec des services REST et à base de WSDL.

Les moins :

• Un style visuel par défaut moins attrayant que celui de son rival.
• Le niveau d’abstraction est le même que sur GWT-Ext. Dès qu’on souhaite customiser un composant ou créer un comportement différent, il faut la plupart du temps mettre le nez dans le code Javascript.

Le code source du projet est fourni sous licence LGPL.
Une démo de SmartGWT en action est disponible.
Notons aussi, pour cette occasion, un petit jeu de questions / réponses chez InfoQ.

Le coin de la technique

Améliorez la testabilité de votre code

Misko Hevery, coach Agile à Google, partage sur son blog quelques-unes des recommandations et alertes que Google suggère à ses développeurs afin de garder le code le plus propre et le plus testable possible. Rien de bien étonnant, la majorité des points abordés sont connus et relèvent du bon sens. Cependant, une piqûre de rappel ne fait jamais de mal.

Misko a donc regroupé ceux-ci en ‘fléaux’. Ces 4 thèmes permettent de vérifier ou d’améliorer simplement la testabilité d’une application (la liste ne se veut pas exhaustive) :

• Assurez-vous que vos constructeurs n’effectuent aucun véritable traitement. Alertes : utilisation du mot clé new, appel à des méthodes statiques, présence de conditions ou de boucles, utilisation de blocs d’initialisation, initialisation trop complexe.
• Contentez-vous d’utiliser les objets attributs de vos classes. Alertes : invocations chaînées trop profondes du type getObject1().getObject2().getObject3(). Objets avec des noms suspects comme ‘context’, ‘environnement’, ou ‘manager’.
• Utilisez les objets stateful à bon escient. Alertes : utilisation d’un singleton, utilisation d’un champ ou d’une méthode statique, présence de bloc statique d’initialisation. Misko est d’ailleurs l’auteur d’un projet sur Google Code permettant de détecter différents types de singletons.
• Découpez votre code, évitez les classes trop volumineuses. Alertes : les objets qui ont plusieurs fonctions distinctes, les classes difficiles à comprendre rapidement, les classes possédant des attributs qui ne sont utilisés dans aucune méthode.

Misko est également l’auteur d’un autre projet permettant l’analyse de la testabilité de votre projet à partir de son bytecode. Il a d’ailleurs passé celui-ci sur quelques-uns des frameworks Open Source de votre quotidien et regroupé les résultats sur son site dédié : Testability Explorer.

Nexus pour chercher dans les repositories Maven

On avait l’habitude d’utiliser http://www.mvnrepository.com (ou google, ou le plugin m2eclipse) lorsque l’on partait à la recherche de son jar favori, Sonatype (dont le fondateur et CTO est Jason Van Zyl, le père de Maven) a mis à disposition une instance publique de Nexus, son manager de repository Maven : http://repository.sonatype.org.

L’interface est propre, facile à utiliser, et est développée à l’aide du framework Ext JS.

Distribuez vos tests JUnit avec GridGain

Tester une application déployée sur plusieurs machines : quelle galère ! N’avez-vous jamais eu besoin d’effectuer des tests en environnement distribué ? Comment effectuez-vous vos tests d’intégration impliquant des communications clients-serveur ? Cet article nous propose une solution originale pour effectuer ce type de tests multi-jvm utilisant certaines fonctionnalités de GridGain, framework Open Source permettant la création d’applications distribuées de type grid computing. L’auteur de l’article n’utilise pour faire ses tests qu’une des fonctionnalités offertes par ce framework : la distribution des tests sur plusieurs nœuds.

Pour ce faire, vous aurez besoin, en plus de vos tests, de 3 ‘TestSuite’ configurées avec des annotations et runners GridGain :

• Une première ‘Remote TestSuite’ chargée de lancer les tests sur le serveur. Les tests de cette suite seront exécutés sur la grille.
• Une seconde ‘Local TestSuite’ pour lancer les tests sur le client local.
• Une troisième et dernière ‘Distributed TestSuite’ servant de point d’entrée unique au lancement de deux premières séries de tests.

Cela vous déplaît certainement d’utiliser un tel framework uniquement pour une de ses plus petites fonctionnalités, et vous avez probablement raison. Maintenant quelles autres options aussi puissantes et rapides à mettre en place proposeriez-vous en remplacement ?

Tomcat : Trucs et astuces des pros de SpringSource

SpringSource continue sa série de webinars sur Tomcat avec Apache Tomcat Tips and Tricks from the Pros (cf. Tuning et optimisation de Tomcat : mod_jk est mort ! Longue vie à mod_proxy_http ! et Améliorer les performances de Tomcat en production). Nous avons cette fois retenu :

• setEnv(.sh|.bat) est le fichier à utiliser pour configurer le lancement de Tomcat (afin de préciser le JDK, les options de la JVM, etc). startup.sh et catalina.sh peuvent le plus souvent rester inchangés.

JAVA_HOME=/usr/local/jdk_1.6.0.10/
CATALINA_OPTS=-Xmx512m
CATALINA_HOME=/usr/local/apache-tomcat-6.0.18
CATALINA_BASE=/usr/local/tomcat-instance-01
CATALINA_PID=$CATALINA_BASE/logs/tomcat.pid

Dans cet exemple, un JDK 1.6.0.10 avec 512 Mo de Heap démarre un Tomcat 6.0.18 avec une configuration située sous /usr/local/tomcat-instance-01 ; le pid sera stocké sous /logs/tomcat.pid.

• Le port de shutdown de Tomcat existe pour des raisons historiques [1] et présente une faille inutile de sécurité. Il doit être désactivé en précisant le port « -1″. On remplacera alors shutdown.sh et catalina.sh stop par le classique kill unix.

<Server port="-1" shutdown="SHUTDOWN" >

• L’Access Log Valve permet de générer des logs d’accès similaires à celles d’Apache. Ces informations sont très importantes pour la supervision et le troubleshooting. L’ExtendedAccessLogValve supporte le W3C Extended Log File Format et surtout facilite le troubleshooting en permettant d’afficher les paramètres et les attributs de requête (même en POST).

<Valve className="org.apache.catalina.valves.AccessLogValve"
    pattern="combined" directory="${catalina.base}/logs" prefix="tomcat_access_" suffix=".log" />

• Le fichier catalina.properties permet d’utiliser des variables de substitution. Exemple avec une variable engine.jvm-route :

<Engine ... jvmRoute="${engine.jvm-route}">

• Tomcat offre plusieurs méthodes pour déployer les applications (définition de <context> dans server.xml, auto deploy de .war/répertoires/context.xml, déploiement scripté). Si toutes ces options sont utilisables en production, il est important de n’en utiliser qu’une seule pour éviter les collisions.

[1] Les JDK 1.0, 1.1 et 1.2 n’offraient pas de graceful shutdown. Depuis, le mécanisme de Shutdown Hook des JVM permet un arrêt élégant de Tomcat sur commande kill.

Evènements de notre communauté en France et à l’étranger

Sacha Labourey au Paris JUG mardi pour une soirée JBoss

Sacha Labourey, CTO de JBoss et General Manager de JBoss Europe, présentera JBoss AS 5.0 à la soirée JBoss du Paris JUG mardi 2 décembre. Saheb Malik, JBoss France, présentera ensuite JBoss Seam.
C’est l’occasion rêvée de mieux comprendre l’agenda de JBoss. Nous avons notamment en tête les questions suivantes :

• JBoss MicroContainer et OSGi : quel positionnement tenir quand Sun a mis en retrait HK2 au profit d’Apache Felix.
• JBoss Messaging vs. RedHat MRG : quelles synergies ? Interopérables à l’instar de Websphere MQ (aka MQ Series) et Websphere Embedded Messaging Engine ? AMQP plaît à RedHat, JBoss est-il aussi intéressé ?
• JBoss AS 5 : comment le précurseur des implémentations EJB 3 et JPA se retrouve t’il parmi les retardataires des certifiés Java EE 5 ? Le chantier de refonte a-t-il été trop ambitieux ?
• Data Grids : pourquoi JGroups, le coeur de communication de JBoss Cache est-il un projet extérieur à JBoss ? Les Data Grids font-elles parties des priorités de JBoss ?
• JBoss, Fondation Apache et brique HTTP de JBoss AS : JBoss semble moins impliqué qu’auparavant dans Tomcat et vient de lancer son mod_cluster à l’extérieur du projet Apache HTTP Server et de son mod_proxy_balancer. À l’heure où les architectures Comet imposent des évolutions importantes des moteurs de Servlet, JBoss compte-t-il s’éloigner de Tomcat ?

L’argent dette, monnaie virtuelle, créée à profusion par les banquiers, sous la bénédiction des états complices, a servi à accélérer artificiellement nos économies, à soutenir un rythme de croissance plus que déraisonnable. Tant pis, c’est fait. Nous devons désormais payer un lourd tribut à cette hallucination collective.

Le 2 janvier 2009, nous aurons donc tous la gueule de bois ; non pas à cause des abus d’alcool et de bonne chère dans lesquels nous ne pouvons nous empêcher de sombrer pendant la trêve des confiseurs mais plutôt parce que cette hypothétique crise dont nous ne voyons pas encore les effets (au point des fois de mettre en doute son existence) sera bel et bien là.
Par voie de conséquence, 2009 sera une année difficile pour les prestataires de services puisque nos clients seront tous contraints, nous le savons, à réduire leurs investissements informatiques.

Nous avons mangé notre pain blanc, nous allons manger notre pain noir. Les agapes finies, la période de vaches maigres va commencer.

Et bien tant mieux !

Tant mieux car c’est en période de manque que nous prenons les décisions les plus judicieuses, celles qui ne sont destinées qu’à assurer la survie de nos entreprises, c’est en période de difficultés que nous nous surpassons, que nous devenons créatifs, que nous sommes efficaces, que nous affûtons nos meilleures décisions.

En 2009, les DSI s’interrogeront certainement sur le meilleur moyen d’utiliser un budget réduit.
Elles stopperont, quand cela sera possible, les chantiers pharaoniques de type refonte en SOA à l’échelle de l’entreprise pour ne se concentrer que sur le ROI, le Quick Win, bref la suppression du gaspillage.

Dans ce contexte, les méthodes agiles que nous prônons tombent à point nommé. Basées sur le principe de travail itératif et incrémental, sur le principe de la priorisation par la valeur, sur la qualité plutôt que la quantité, elles seront, nous en sommes sûrs, le nouvel eldorado de l’ingénierie logicielle.
Nous avons d’ailleurs d’ores et déjà constaté un réel engouement pour les méthodes agiles (nous avons cette année, certifié 100 ScrumMasters, participé à 10 projets agiles et accueilli dans nos ateliers agiles du mercredi plusieurs dizaines d’entreprises).

Alors y aura-t-il une relation de cause à effet ? La crise sera t’elle le « compelling event » de l’adoption des méthodes agiles ?

Posons-nous la question : que pourront apporter Scrum et XP à nos clients en période de crise ?

Voici une liste (certainement incomplète), de 6 facteurs améliorant la rentabilité des projets informatique :

• La disparition des fonctionnalités inutiles grâce à une meilleure utilisation des efforts de développement, ce qui engendrera une économie substantielle (au moins 20%) dans les coûts des projets.
• La suppression de la documentation à outrance, finissant dans un placard électronique appelé référentiel, les réunions interminables, finalisées par le sacro-saint compte rendu de réunion qui ne donnera lieu à aucune décision ou bien les reporting fallacieux destinés à se donner l’illusion que tout est under-control.
• L’augmentation de la productivité des équipes de développement (par deux, par trois, et même par dix !) grâce à un nouveau paradigme de management basé sur la confiance, la motivation, l’amélioration continue (voir nos comparaisons de productivité de développement constatées dans le cadre du projet Prorail mené par Xebia).
• La baisse faramineuse des coûts de maintenance grâce à l’élimination de la dette technologique accumulée à cause du manque de compétence des équipes ; ce n’est d’ailleurs pas de leur faute, un développeur à 350-400 Euros est forcément un débutant, un quart d’architecte partagé entre plusieurs projets est forcément insuffisant.
• La suppression de la perte financière sèche liée à l’arrêt brutal de projets pour cause de manque de maîtrise des risques inhérents aux projets menés en cascade (le phénomène du puit sans fond si souvent constaté).
• L’avantage concurrentiel, traduit en monnaie sonnante et trébuchante, apporté à l’entreprise par un logiciel qui, pour une fois, sera conforme aux besoins des utilisateurs, qui sera capable d’intégrer au fil de l’eau les changements de contexte commercial, juridique ou légal plutôt que de les décaler à la prochaine release.

Nous nous devons de faire une nécessaire mise en garde : Les bénéfices (ou les droits) apportés par les méthodes agiles sont contrebalancés par de réels devoirs auxquels on ne peut pas se soustraire.
Ne pas les respecter revient à sombrer dans la Wanabisme agile, c’est-à-dire le pire des mondes.

Nous vous le promettons, 2009 sera une année très faste pour ceux, qui comme nous, croient fondamentalement au bien fondé intellectuel des méthodes agiles et qui les mettent en place, une année comme une autre, une année passionnante.

Actualité éditeurs / SSII

• OSGi : Spring dm Server standardisé pour l’été 2009 ?

Agilité

• La fin de l’Agilité ?

SOA

• SOA : de la crise de doute à la désillusion ?

Le coin de la technique

• Seam 3 : les futures orientations de Seam
• Sortie de Netbeans 6.5
• Sortie de SOAP UI 2.5
• Survol de l’architecture MySpace
• Oracle sort son Incubateur Coherence

Actualité éditeurs / SSII

OSGi : Spring dm Server standardisé pour l’été 2009 ?

Eric Newcommer, OSGi Enterprise Expert Group (EEG) co-chair, présente dans « OSGi for the Enterprise Gets a Bit Closer & LinkedIn Too » l’avancement de l’EEG qui a pour ambition de faire coïncider la fin de ses travaux avec la sortie d’OSGi R4.2 annoncée pour Juin 2009.

On y apprend que la « RFC 124 / Blueprint Component Model » est quasiment finalisée, son implémentation de référence (RI) est SpringSource dm Server dont elle a repris les principes ; le Test Compatibility Kit (TCK) est développé par le projet Apache Geronimo. Souhaitons que cette standardisation de dm Server permette à SpringSource de reverser le contenu de son Enterprise Bundle Repository dans l’officiel OSGi Bundle Repository de l’OSGi Alliance et que la prolifération de bundles customisés par les grands acteurs de l’OSGi prenne fin.

Par ailleurs, « RFC 119 / Distributed OSGi » serait elle aussi prête. Apache CXF est en charge de la Reference Implementation (Cf. First Ever Demo of Distributed OSGi) et Tibco s’occupe du Test Compatibility Kit. Nous remarquerons que Distributed OSGi reprend certains principes de Service Component Architecture (SCA) et que le positionnement des deux technologies manque encore de clarté. De plus, à la différence de « Blueprint Component Model » avec Spring dm Server, Distributed OSGi ne connaît pas encore de « vraie » implémentation.

Agilité

La fin de l’Agilité ?

Le prix du buzz de la semaine revient incontestablement à James Shore pour son article The Decline and Fall of Agile. « Jim » raconte qu’il a noté un changement dans son métier : avant on l’appelait pour introduire les méthodes agiles sur les projets, aujourd’hui on l’appelle pour secourir des projets soi-disant « agiles ».
Et par « agile » la plupart des clients entendent Scrum, la méthode la plus répandue. Il reproche à Scrum son silence sur les pratiques d’ingénierie logicielle à mettre en place (contrairement à XP), pourtant indispensables à la viabilité d’un projet. Il critique également la Scrum Alliance et son système de certification ScrumMaster qui donnent l’impression que l’agilité est facile. La nature humaine nous incite à ne choisir que les côtés agréables (les sprints et les daily scrums) mais nous ignorons les côtés plus difficiles, qui sont aussi les plus importants : équipe co-localisée, auto-organisée, produit livrable à chaque fin d’itération, élimination des obstacles.

Cet article a déclenché de vives réactions dans la communauté agile, certaines un peu puériles, d’autres plus constructives. Sur InfoQ par exemple, le Gartner Hype Cycle est évoqué pour expliquer ce déclin. Après un pic d’attentes irréalistes concernant une technologie, celle-ci traverse un creux de désillusion avant de remonter pour atteindre son plateau de productivité. Les méthodes agiles traverseraient-elles actuellement ce creux ?

Le Touilleur cite Rob Bowley qui fait le rapprochement entre la déception de Scrum et l’engouement récent pour le Lean Software Development. Il prédit pourtant que le Lean subira le même sort que Scrum, pour les mêmes raisons. Selon lui peu importe la méthode, il y a toujours des personnes qui se concentrent sur les outils plutôt que sur les vrais problèmes. Ces personnes, qui échouent avec Scrum aujourd’hui, échoueront avec le Lean demain.

SOA

SOA : de la crise de doute à la désillusion ?

Nous évoquions en Mars dernier dans « 2008, annus horribilis de la la SOA ?«  la crise de doute qui s’emparait du Burton Group, grand chantre de la SOA. La crise s’accentue aujourd’hui avec l’autre évangéliste de SOA, le Gartner Group, qui nous gratifie de Ahh Shucks, SOA Is A Failure (Frank Kenney). À croire que le Gartner Group s’applique son célèbre Hype cycle et, après avoir loué SOA, tombe en pleine phase de désillusion.

Est-ce pour autant la fin de SOA ? Certainement pas, des ouvrages comme Enterprise Integration Patterns ou Developing in a Service-oriented World (Gregor Hohpe, Google) ont beaucoup apporté à l’intégration des Systèmes d’Information.

Quant aux cabinets de conseils qui ont parfois manqué de pragmatisme, ils ont trouvé des nouvelles marottes avec les architectures du moment : Representational State Transfer (REST) et Web Oriented Architecture (WOA) (Cf. Gartner – WOA: Putting the Web Back in Web Services ou Burton Group : The Tao Of REST), sans oublier les promesses mirobolantes du Software As A Service (SaaS) et du Cloud Computing !

Le coin de la technique

Seam 3 : les futures orientations de Seam

Gavin King, créateur d’Hibernate et Seam, présente les futures orientations de Seam3.

Il indique que Seam 2 était une première couche. Cette couche a pour responsabilité de gérer des composants à état, configurables et injectables pour le développement d’applications Web riches. Il permet de s’abstraire du code « glue » que l’on doit faire pour intégrer différentes technologies (JSF, JPA, …). Cette première couche est focalisée sur l’intégration de services à état côté serveur et sur la réalisation d’interface graphique (par défaut avec JSF).

Seam 3 ajoutera une seconde couche, qui aura pour responsabilité de faire de WebBeans le coeur de Seam, d’améliorer l’intégration de la sécurité, de Drools et jBPM. L’idée est de faire de Seam 3 un framework d’infrastructure basé sur Web Beans. Seam 3 permettra donc l’intégration de moteur de workflow et de moteur de règles qui devrait apporter de nouveaux outils pour la conception et la réalisation d’applications.

Seam 3 pourrait conduire à une réécriture de Seam 2 afin d’intégrer Web Beans.

A noter que le 2 décembre 2008 se tiendra une soirée JBoss au Paris JUG, dont la deuxième partie sera entièrement consacrée au framework Seam.

Sortie de Netbeans 6.5

Netbeans.org annonce la sortie de son IDE NetBeans 6.5 : NetBeans.org is proud to announce the availability of NetBeans IDE 6.5!.

Cette nouvelle version met à disposition des développeurs :

• le debug Javascript dans Internet Explorer et Firefox,
• le développement JavaFX (compilation, déploiement, prévisualisation, édition, …),
• l’intégration de Glassfish V3 Prelude (possibilité de scripter en JRuby),
• un plugin pour le développement en python : NetBeans IDE for Python EA Download,
• l’amélioration et l’intégration de nouvelles technologies de développement : PHP, Groovy / GRails, Ruby (RoR – Ruby On Rails, rake),
• et bien d’autres : NetBeans IDE 6.5 Release Information, NewAndNoteWorthyNB65.

Netbeans s’avère une alternative de plus en plus crédible à Eclipse. Il possède des avantages non négligeables par rapport à ce dernier : meilleur support Javascript (et du développement Web avec PHP), support de Python, JavaFx, etc.

Pour plus d’informations, voici quelques screencasts qui montrent le fonctionnement de Netbeans : NetBeans IDE 6.5 Released; Introductory Screencast Released.

Sortie de SOAP UI 2.5

SoapUI est un outil graphique pour tester les services web. Il permet d’inspecter, invoquer, développer, créer des tests de charges et des tests fonctionnels sur des services web. Il apporte aussi des plugins pour Eclipse, IntelliJ IDEA et NetBeans.

SoapUI 2.5 apporte un grand nombre de fonctionnalités :

• Inspection et invocation :
  • Importation et analyse de fichiers WSDL.
  • Appel des différentes opérations d’un service web.
  • SSL / authentification / sécurité WS.
• Développement et validation :
  • Génération de stubs client et serveur pour les frameworks les plus populaires : Axis 1.x/2.x, XFire / CXF, JWSDP, Oracle, .NET, GSoap, JBossWS.
  • Génération de XML bindings pour JAXB et XMLB.
• Tests fonctionnels :
  • Génération de séries de tests et de testcases sur la base du WSDL.
  • Utilisation de scripts « Groovy » pour l’exécution de tests.
• Tests de charge :
  • Établissement de tests de charge à partir de testcases fonctionnels.
  • Établissement d’assertions, tant au niveau de la performance que de la fonctionnalité.
  • Analyse de performance pour des scénarios variés..

Pour voir la liste complète des fonctionnalités, rendez-vous sur le site du projet.

Très facile d’utilisation, SoapUI devient de plus en plus un leader incontournable dans le test des services web en open source. Il existe en version gratuite et open source et en version payante appelée « SoapUI Pro ».

Vous pouvez télécharger l’outil, ou l’utiliser directement avec le déploiement Java Web Start. Java 1.5 est indispensable à son utilisation.

Survol de l’architecture MySpace

InfoQ poursuit sa série sur les architectures des grands du Web 2.0, avec l’interview de Dan Farino, architecte principal du site communautaire MySpace.

Nous entrerons probablement moins dans les détails de cette architecture pour la bonne et simple raison que MySpace est l’un des seuls site internet de cette taille à tourner sous .Net. Cependant, les grands principes de performances qui permettent au site communautaire de gérer plusieurs millions de visiteurs par jour, et un contenu en constante augmentation, s’appliquent à n’importe quelle technologie.

• Mettre l’accent sur l’automatisation : avec des fermes comportant plusieurs centaines de serveurs (300 serveurs web IIS frontaux par exemple), il est vital que toutes les opérations d’administration des serveurs soient automatisées à une large échelle.
• La détection des anomalies est la première étape nécessaire à l’amélioration des performances : à cette fin, Dan Farino a dû écrire un outil de supervision sur mesure permettant de ‘tracer’ chaque requête à travers les centaines de serveurs de l’architecture. Cette problématique est relativement courante.
• Pour chaque problème de performance ou de scalling détecté, l’équipe d’architectes de MySpace a favorisé la solution sur mesure aux nombreux outils ‘génériques’ proposés par Microsoft. On notera en particulier :
  • Le développement d’un système de cache spécifique, afin de s’affranchir des problèmes (connus) de GarbageCollection en .Net, et afin d’alléger la charge pesant sur les serveurs de DB.
  • Le développement d’un serveur de fichiers, en Linux, permettant d’adresser les fichiers aux utilisateurs finaux directement en HTTP, et gérant la redondance des fichiers audio, video (qui sont la vraie valeur ajoutée de MySpace).
  • Le développement d’un système d’introspection du code .Net en temps réel (mesure des temps d’appels, des allocations mémoire, levée d’exception, …) écrit en C++ (afin de monitorer le code .Net de la manière la plus indépendante possible).
  • La création d’un système de ‘load balancing’ spécifique, permettant de rapidement isoler un serveur défaillant et de n’impacter qu’un minimum d’utilisateurs.

Et bien sûr, MySpace respecte un principe que nous avons maintenant rencontré dans tous les sites gérant un trafic ou un contenu important, le partitionnement horizontal et vertical des bases de données, en fixant une limite d’un million d’utilisateurs par DB.

Les autres épisodes de la série disponibles sur notre blog :

• Ebay
• LinkedIn
• InfoQ

Oracle sort son Incubateur Coherence

Oracle tente d’élargir la communauté ‘Coherence’ après l’ouverture du mois dernier de son nouveau site web Coherence Incubator. Veillez à ne pas comparer celui-ci à l’incubateur Apache, son fonctionnement est tout autre. ‘Coherence Incubator’ a été créé dans le but de regrouper un ensemble de projets d’exemples, chacun d’entre eux proposant une implémentation de référence pour un cas d’utilisation standard de l’outil. Il s’agit donc d’un ensemble de bonnes pratiques validées par Oracle. Oracle espère par ce biais faciliter l’accès à son outil.

Pour mémoire, Oracle Coherence se positionne comme l’une des solutions les plus complètes de grilles de données distribuées. Il permet de clusteriser vos applications sur un environnement hardware évolutif. Par exemple, l’ajout et la suppression de machine s’effectuent sans contrarier la réplication, la distribution et le cache de données au sein du cluster.

Un mois après sa sortie, l’incubateur Coherence contient les projets suivants :

• coherence common : un regroupement de classes utilitaires et bonnes pratiques. Utilisés par les autres projets de l’incubateur.
• Implémentation distribuée du command pattern.
• Implémentation du functor pattern. Il s’agit d’une extension au ‘command pattern’ qui permet de renvoyer à l’appelant des valeurs de retour et des exceptions.
• Implémentation partielle du pattern messaging. Messages non persistés, managés en mémoire par Coherence.
• Implémentation du pattern Push Replication. Propagation des modifications des données, réplication.

Si le contenu de cet incubateur n’est pas encore très impressionnant, il aura le mérite de servir de bon point de départ aux futurs nouveaux utilisateurs de Coherence. Le nombre de cas d’utilisation est encore très faible ; reste à savoir à quelle vitesse Oracle enrichira-t-il celui-ci. Après un mois d’utilisation, seul un nouveau projet a été créé.

En particulier, la vélocité d’une équipe locale peut elle être maintenue voire même augmentée si elle est distribuée au travers de plusieurs continents ?

Xebia mène depuis mi 2006 des projets agiles distribués entre l’Europe et l’Inde. Après avoir atteint le stade de l’hyper productivité en Europe, les membres indiens de l’équipe ont été réinstallés dans leur pays d’origine. Dans le cadre de cette distribution, nous avons constaté que la vélocité de l’équipe a même augmenté. L’utilisation des pratiques d’ingénierie de XP (eXtreme Programming) au sein de projets Scrum a permis à Xebia de répliquer de manière durable un modèle de développement Offshore distribué de grande qualité identique à celui de SirsiDynix [1].

Introduction

Le but de cet article est donc de décrire un modèle de développement dont la productivité augmente linéairement avec la distribution des équipes sur plusieurs continents et dont la vélocité est comparable à celle d’équipes co- localisées.
Ce modèle est reproductible, éprouvé et est particulièrement recommandé aux équipes aguerries, maîtrisant Scrum et XP.
Les méthodes agiles héritent des meilleures pratiques de sociétés comme Fuji, Xerox, Canon, Honda et Toyota. Combiner Scrum à XP a permis d’atteindre des niveaux de productivité de 5 à 10 fois supérieurs à la moyenne de notre industrie [3] [5]. En 2005, deux sociétés agiles, SirsiDynix (E.U) et Exigen Services (Russie) ont utilisé des équipes Scrum distribuées afin d’atteindre des performances linéaires dans le cadre d’un grand projet de plus d’un million de lignes de code. L’équipe distribuée entre les Etats Unis et la Russie a atteint une vélocité équivalente à celle d’une équipe co-localisée et a réussi à construire une liste de fonctionnalités équivalente à celle d’une équipe de 350 personnes d’un projet mené traditionnellement en cascade (Waterfall).
De 2006 à 2008, Xebia a mis en place des équipes distribuées pour moitié en Europe et pour moitié en Inde dans le cadre de différents projets. Ces équipes ont utilisé le processus de développement de Scrum avec les pratiques d’ingénierie de XP.
Nous aborderons donc au cours de cet article les stratégies Offshore à adopter pour lever les obstacles géographiques, linguistiques et culturels traditionnellement rencontrés dans les projets Offshore et les techniques permettant de les mettre sur la voie de la réussite.
La distribution des équipes Scrum au travers de plusieurs continents élimine les problèmes de communication, les pratiques XP résolvent les problèmes d’intégration et les réunions quotidiennes (Daily Scrum Meetings) maintiennent l’emphase sur les priorités du client.
Les expériences menées dans d’autres sociétés ont démontré que la proximité géographique peut doubler la productivité des équipes agiles [8]. Ici, le modèle Agile distribué rend transparent l’éloignement géographique pour atteindre des performances équivalentes ou supérieures aux équipes agiles co-localisées.

Les challenges de l’Outsourcing Offshore

Que ce soit aux Etats Unis, en Europe et au Japon, de plus en plus d’entreprises font appel au développement logiciel Offshore dans des pays d’Europe de l’Est et en Asie. Pour autant, les équipes opèrent localement et les problèmes de communication altèrent le niveau de productivité de celles-ci.
La plupart des organisations Offshore exigent des spécifications détaillées avant le démarrage des projets. Il est prouvé que ces méthodes de planification atteignent des niveaux élevés d’échecs.
Les coûts cachés du développement Offshore sont significatifs et cela dès le début.
Barthelemy [8] a mené une étude auprès de 50 sociétés et a démontré que 14% des opérations menées en Offshore sont des échecs. Son rapport démontre que les coûts de transition liés à l’établissement de relations avec un nouveau fournisseur engloutissent souvent l’intégralité des économies attendues par le faible coût de la main d’œuvre. Le temps moyen entre l’étude d’opportunité de l’Offshore et l’atteinte de la vitesse de croisière chez le fournisseur est de 18 mois pour des petits projets.
Par conséquence, la MIT Sloan Management Review conseille à ses lecteurs de ne pas outsourcer les projets critiques.
Les trois objectifs que poursuivent les projets Offshore sont les suivants:

1. faible coût de la main d’œuvre
2. recherche de compétences locales
3. accroissement ou au contraire la diminution des projets sans avoir à licencier son propre personnel

Le premier objectif n’est pas facilement atteignable. Chez PatientKeeper (une société du MIT, fondée en 2000 où travaille Jeff Sutherland), entre 2004 et 2007, le point mort des projets Outsourcés n’était atteint que lorsque les développeurs indiens ne coûtaient que 10% du prix de leurs homologues américains. Le comité de Direction de PatientKeeper décida alors de stopper définitivement les projets Offshore.
Attirer les compétences locales peut aussi s’avérer être un problème. Jack Blunt, Président de Dynix et ancien Directeur des Opérations de Borland refusa d’outsourcer ses projets en Inde ou en Chine lorsqu’il découvrit que le Turn Over dans ces pays était entre 30% et 50% [9].
Tenir les promesses du développement Offshore requiert de faire de vraies économies, d’avoir des équipes Offshore stables et d’élaborer une stratégie destinée à la connaissance en interne.
Cela n’est possible que si les équipes Offshore ont atteint le même niveau de productivité que les équipes internes et si les équipes internes et les équipes Offshore maintiennent le même niveau de connaissance.

Les modèles de distribution de Scrum

Considérons les trois modèles d’équipes Scrum suivants :

• Equipes Scrum isolées : Les équipes Scrum sont isolées les unes des autres géographiquement.
• Les Scrum de Scrum distribuées : Les équipes Scrum sont isolées les unes des autres et intégrées par un Scrum de Scrum [6] qui se réunit régulièrement.
• Equipes Scrum distribuées : Les équipes Scrum sont cross fonctionnelles et distribuées au travers des continents.

Les équipes Scrum isolées du projet Google AdWords ont exprimé le besoin de meilleures pratiques de communication. La bonne pratique recommandée par la Scrum Alliance est le modèle Scrum de Scrum distribué. Ce modèle divise le travail au travers d’équipes Scrum isolées cross fonctionnelles tout en éliminant la plupart des dépendances entre celles-ci. Les équipes Scrum sont reliées par des Scrum de Scrum où les ScrumMasters des différentes localisations se rencontrent régulièrement.
Le modèle Scrum distribué, comme le montre le modèle OneTeam de Xebia, distribue intégralement toutes les équipes et chaque équipe Scrum a des membres à plusieurs endroits.
Même si, de prime abord, cela semble alourdir le processus de communication et de synchronisation, les Daily Scrum aident à supprimer les barrières culturelles et à lisser les disparités dans le mode de travail tout en améliorant l’emphase sur les besoins clients et leur compréhension par les équipes Offshore.
A l’échelle d’une entreprise, ce modèle organise le projet autour d’une seule base de code intégrée.
Le maximum de valeur métier est délivré par Scrum en implémentant les fonctionnalités du Product Backlog dans l’ordre des valeurs métier.
Les fonctionnalités du produit sont représentées par Xebia en User Stories et la taille d’une User Story est évaluée en Story Points [5].
Les équipes de Xebia mesurent le coût en Euro par User Story.
La valeur de la fonctionnalité divisée par le coût est l’indicateur principal de la valeur métier ainsi délivrée et est directement proportionnelle à la vélocité de l’équipe, calculée en Story Points par itération.
Xebia contrôle sans cesse que la vélocité d’une équipe distribuée équivaut à celle d’une équipe co-localisée.
Le modèle Scrum distribué n’est conseillé qu’aux équipes agiles expérimentées.
Il s’avère que les équipes distribuées ont un meilleur focus que les équipes co-localisées.
La métrique la plus communément admise pour comparer la productivité entre projets est le Function Point puisqu’il représente directement les fonctionnalités délivrées.
Capers Jones démontra il y a quelques années que le nombre de fonctionnalités délivrées par les Function Points peut être estimé par le « sacro saint » nombre de lignes de code.
Même si la mesure de la valeur métier est moins directe, c’est la meilleure manière de mesurer des équipes à l’échelle de l’industrie informatique.
On peut toujours argumenter du fait qu’écrire un grand nombre de lignes de code ne garantit pas de produire de la valeur métier. Les équipes Scrum utilisent également les pratiques d’ingénierie xP produisent plus de lignes de code qu’une équipe standard de l’industrie car :

• Scrum priorise le Product Backlog en fonction de la valeur métier, garantissant ainsi que les lignes de code produites optimisent la valeur métier délivrée.
• La pratique XP consistant à refactorer élimine des milliers de lignes de code qui seraient restées statiques dans un projet en cascade.

Le message de ce document est donc que les équipes Scrum/XP de Xebia délivrent les Function Points sept fois plus vite qu’une équipe standard dans un projet en cascade.

Le cas ProRail de Xebia

Le meilleur moyen d’illustrer le modèle distribué est de prendre un cas réel : le projet ProRail mené par Xebia.
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.
Les développements portaient sur la construction du système d’agrégation et de distribution de l’information (incluant le routage d’informations ad’hoc pour chaque gare pour l’ensemble des trains la concernant), le client d’affichage, le système audio ainsi que le contrôle et le monitoring des interfaces.
Dans ce type de projet très visible et très sensible et nécessitant une très haute disponibilité, les besoins non fonctionnels sont nombreux.
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.

Structure projet et montée en charge

Xebia a initialisé le projet par une courte phase de construction du Product Backlog, une conception sommaire de l’Architecture ainsi qu’un plan qualité. La recette et les spécifications étaient laissées à la charge du client.
Après 3 semaines d’initialisation de projet, une équipe co-localisée mena deux itérations.
La longueur d’une itération avait été fixée à 2 semaines pour l’ensemble du projet.
Les équipes indiennes furent introduites sur site dès la troisième itération.
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.
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 projet est ensuite monté en charge après le retour des indiens chez eux.
Des développeurs furent ajoutés au dispositif pour ainsi former deux équipes supplémentaires, chacune avec des membres distribués dans les deux pays.
Une attention toute particulière fût portée au partage de l’expérience avec les nouveaux au sein des équipes et des pratiques comme le Pair Programming furent largement utilisées pour accélérer leur apprentissage.
La division cellulaire fut ainsi répétée jusqu’à atteindre la taille désirée.
Le projet grossit donc jusqu’à atteindre 3 équipes distribuées et une équipe Scrum locale, avec au total 25 personnes. 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.
Comme le client préféra que la maintenance soit prise en charge par des ingénieurs néerlandais, les équipes indiennes furent les premières à disparaitre du dispositif.
La taille totale du projet fût de 20 années/homme, 100.000 lignes de code sur une période de 11 mois.

Les avantages de la démarche constatés

L’approche OneTeam prônée par Xebia dans le cadre de développements Offshore Agiles distribués atteint les mêmes résultats qu’une équipe co-localisée.
Les différents aspects du projet sont décrits ci-dessous :

Productivité
Durant le projet, la vélocité fut déterminée par le nombre de Story Points qu’une équipe pouvait réaliser dans le cadre d’une itération.
Comme les Story Points ne peuvent pas être convertis d’un projet à l’autre, le projet fut estimé en Function Points.
Cette estimation fut faite pour l’ancienne implémentation et la nouvelle implémentation, et les chiffres correspondent.
Même si cette mesure de la valeur métier n’était qu’approximative, elle fut le seul moyen de faire des comparaisons entre projets.

Schéma 1 : Productivité d’équipes Scrum co-localisées, équipes projet classique, d’équipes SirsiDynix distribuées, et Xebia One Team.

Le Schéma 1 montre aisément que les équipes Scrum 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 schéma montre que la performance d’une approche Scrum distribuée est reproductible et non spécifique à SirsiDynix.
Afin d’évaluer l’effet de la distribution des équipes sur la productivité, nous pouvons examiner le coût de la réalisation par Story Point tout au long du projet.

Il est important de noter qu’il y a une augmentation graduelle du coût de réalisation d’un Story Point dans la plupart des projets classiques dès que complexité grandit et que le code devient important, ce qui n’est pas le cas dans le diagramme ci-dessus.
La transition d’une équipe co-localisée à une équipe distribuée survint à la 6ème itération.
Nous pouvons voir sur le schéma que le nombre d’heures nécessaires à l’implémentation d’un Story Point n’a pas été affecté par cette transition.
Les estimations des Story Point ont été faites en début de projet pour l’ensemble du Product Backlog et au fil de l’eau quand ils naissaient.
Les itérations 18 et 19 montrent une augmentation significative du nombre d’heures nécessaires par Story Point : une dette technique s’était formée dans lors des itérations précédentes.
A partir de l’itération 20, cette dette fut systématiquement réduite pour aboutir finalement à augmentation constante de la productivité.

Une communication claire au travers de Scrum.
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 Burn Down 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.
Planifier un Sprint prenait environ 4 heures.
Les Daily Stand Up meetings démarraient quand les européens arrivaient au travail. Un Stand Up meeting ne durait pas plus de 15 minutes.
Le Retrospective 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.

Consistance et qualité
Durant tout le projet, une attention toute particulière a été portée à la qualité.
La notion Scrum de  » 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 User Stories 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.

Tous les bugs détectés et leur résolution ont été scrupuleusement comptabilisés tout au long du projet.
Le Schéma ci-dessus montre que le nombre de bugs est resté constant tout au long du projet (environ 50) évitant ainsi à l’équipe de constituer ce que l’on appelle une dette technique.
Le nombre de bug par KLOC (KiloLineOfCode) a même décru au fur et à mesure de l’avancée du projet.
Nous avons aussi constaté que 90% des bugs étaient résolus au sein même de l’itération où ils avaient été produits.
En nous basant sur ces chiffres, nous pouvons en conclure que le processus de vérification et de validation isolait 6 bugs par KLOC avant les phases de recette, laissant environ un bug par KLOC.

Ces résultats sont bien meilleurs que la moyenne de l’industrie qui est de 5 bugs par KLOC [10].
Une équipe Scrum distribuée, utilisant les pratiques xP délivre donc un travail d’excellente qualité.

Transparence et contrôle
L’équipe projet put donner des estimations pertinentes sur le temps et le budget nécessaires au projet grâce à l’utilisation du Backlog et un calcul précis de la vélocité de l’équipe [11].
Cela permit de mettre à disposition du client toute les informations nécessaires au contrôle total du projet. La transparence et la production d’un logiciel ‘fini’ à la fin de chaque itération permettaient de donner de la visibilité et de construire ainsi une totale relation de confiance.

Les problèmes rencontrés

Même si Scrum est facile à comprendre, l’implémenter l’est beaucoup moins.
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.

Les différences culturelles
Les équipes européennes et indiennes ont des parcours et des cultures très différents.
Cela est particulièrement vrai dans le domaine de la communication.
Prenons un exemple : un européen est bruyant et direct alors qu’un indien est précautionneux et discret.
Les indiens sont plus hiérarchisés que les européens.
La meilleure arme pour outrepasser ces différences consiste à travailler sur les relations entre les individus. Les échanges qui ont été maintenus tout au long du projet, le contact visuel quotidien à l’occasion des Daily Scrum et l’appartenance à une seule et même équipe sont autant de facteurs qui ont permis de construire des relations interpersonnelles très fortes.
Ensuite une culture de la communication franche et ouverte a été instaurée par les ScrumMasters ce qui a permis d’adresser tous les problèmes lors des Retrospectives et de supprimer les barrières culturelles.
Enfin, le partage d’une culture d’entreprise commune, de part et d’autre a grandement facilité la construction d’une équipe soudée.

Partage du contexte et des priorités
Dans un contexte de développement distribué, il est parfois difficile de communiquer à l’équipe Offshore les nuances du contexte et des priorités du client. Afin de distribuer activement une telle connaissance du contexte client, nous avons prévu des voyages réguliers dans les deux sens, des connections Skype permanentes, la mise en place d’une  » gazette projet  » envoyée à la fin de chaque itération et des contacts informels avec le Product Owner.

Gérer un client qui fait de l’agile pour la première fois
Même si Scrum ne nécessite pas la présence d’un chef de projet, Xebia ajoute un tel rôle au sein du projet.
Ce chef de projet est responsable de la négociation financière avec le client. Il gère ses attentes et fait tout ce qui est possible pour que Scrum fonctionne.
Comme le client n’avait aucune expérience Agile, le chef de projet agit comme un coach responsable de mener l’organisation du client sur la voie de l’Agilité et servit aussi de Proxy Product owner.
Cela permit à l’équipe et aux ScrumMasters d’avoir, dès le premier jour, un Product Backlog clair et d’avoir quelqu’un faisant l’interface avec le client.
Le Proxy Product Owner /Chef de Projet s’assurait de la pertinence du planning Agile et était en contact permanent avec le client pour discuter des jalons, du périmètre et opérer le suivi du projet.
Les ScrumMasters étaient donc en charge des Sprints, des processus agiles et de la qualité.

Une partie du travail doit se faire localement
Même si l’ensemble des développements peuvent être distribués, certaines tâches du projet ne peuvent l’être aisément et doivent être traitées localement.
La 4ème équipe Scrum (cf 4.1) était purement locale, constituée d’européens et dédiée à certaines activités impliquant des interactions physiques avec le client. Des exemples de tâches locales sont : écrire de la documentation en néerlandais, se coordonner avec les Responsables de l’Architecture du client, discuter des spécifications techniques avec la MOE du client ou bien encore établir la liste des dépendances techniques.

Les outils nécessaires à la communication et aux processus
Sur le projet, ScrumWorks a été utilisé pour gérer le Product Backlog et le Sprint Backlog au format électronique.
Les Burndown Charts étaient imprimés quotidiennement et accrochés aux murs des pièces où travaillaient les équipes.
Afin d’obtenir un partage global de l’information, un Wiki fut utilisé de manière intensive.
Les discussions d’Architecture étaient tenues autour de WhiteBoard électroniques.
Parmi quelques uns des outils accessibles par l’ensemble des équipes (co localisées et distantes) nous pouvons énumérer un référentiel de code unique, un système d’intégration continue, des serveurs et des mailing lists.

Conclusion

En résumé, nous pensons qu’il est possible de faire du Scrum distribué avec la même vélocité et la même qualité qu’en situation co-localisée et cela dans la majorité des projets.
La stratégie OneTeam abaisse les coûts, utilise au mieux les talents des membres Offshore tout en permettant une augmentation (ou une diminution) de la taille de l’équipe sans perte de la connaissance.
Nous recommandons cette stratégie aux équipes agiles aguerries.

Références

• [1] Sutherland J., Viktorov, A. and Blount J.: « Adaptive Engineering of Large Software Projetcs with Distributed/Outsourced Teams ». Proc. International. Conférence Complex Systems, Boston, MA, USA, 25-30 Juin 2006.
• [2] Sutherland J.: « Future of Scrum »: Parallel Pipelining of Sprints in Complex Projects’. Proc. AGILE 2005, Conférence de Denver, CO, 24-29 Juillet 2005.
• [3] Beck, K.: « Extreme Programming Explained: Embrace Change », Addison-Welsley, Boston, 1999.
• [4] Takeuchi, H. et Nokata, I. « The New New Product Development Game », Harvard Business Review, 1986 (Janvier-Février).
• [5] Cohn, M.: « User Stories Applied : For Agile Software Development », Addison-Wesley, 2004
• [6] Sutherland, J., et Schwaber, K.: « The Scrum Papers: Nots, Bolts, and Origins of an Agile Method », Scrum Inc, Boston, 2007
• [7] Jones, C.: « Software assessments, benchmarks, and best practices », Addison Wesley, Boston Mass, 2000
• [8] Teasley, S. Covi, L., Krishnan, M.S., and Olson I.S.: « How does radical collocation help a team succeed? », Proc CSCW’00, Philadelphie, PA, 2000, pp. 339-346.
• [9] Sutherland J, Viktorov, A. Blount J., et Puntikov, N.: « Distributed Scrum: Agile Project Management with Outsourced Develoment Teams ». Proc HICSS’40, Conférence International d’Hawaii, 2007.
• [10] Humphrey, W.S.: « Introduction to the Personal Software Process », Addison Wesley, 1996
• [11] Cohn, M.: « Agile Estimation and Planning », Adison Wesley, 2005

Actualité éditeurs / SSII

• Microsoft se rapproche de la fondation Eclipse
• Eclispe 4, une refonte du socle ?
• SpringSource Application Management Suite (AMS)

Agilité

• Polémique : Scrum aliène-t-il XP ?

RIA

• Adobe AIR pour Linux

Le coin de la technique

• SCA Java EE Integration specification : v0.9
• IBM annonce Websphere MQ V7 pour Juin
• Complexité cyclomatique optimale : 11 selon Enerjy !
• Java Module System (JSR-277) et OSGI, un silence pesant

Evènements de notre communauté en France et à l’étranger

• Poissons d’avril

Actualité éditeurs / SSII

Microsoft se rapproche de la fondation Eclipse

A l’occasion d’EclipseCon 08, Sam Ramji, leader de la communauté Open Source chez Microsoft, a annoncé le début d’une collaboration entre La fondation Eclipse et Microsoft.
Le principal but de ce rapprochement concerne une meilleure intégration du toolkit graphique d’Eclipse SWT avec Windows Presentation Foundation (WPF).

Eclispe 4, une refonte du socle ?

Voulant conquérir de nouveaux horizons, notamment côté serveur, la fondation Eclipse annonce la création d’un nouveau composant appelé e4. Le but principal de ce projet est de poser les bases du futur Eclipse 4.0. Partant de zéro, son rôle sera de simplifier la plateforme Eclipse et d’être résolument tourné vers le web.
Prévu au mieux pour fin 2009, Eclipse 4 sera développé en parallèle d’Eclipse 3.4 (Ganymede) et devrait assurer le compatibilité des plugins existants.

SpringSource Application Management Suite (AMS)

SpringSource vient de livrer une solution de monitoring des applications basée sur Spring. Voyons ici un système concurrent de Glassbox. Cependant, cet outil tire partie des nouvelles possibilités de configuration par annotation offertes par Spring 2.5. Il comprend automatiquement les annotations @Controller, @Repository, @Transactional, @Component et @Service. L’avantage donc par rapport à Glassbox finalement c’est la prise en compte automatique des beans gérés par Spring dans le monitoring.

SpringSource AMS est basé sur Hyperic’s HQ Enterprise Edition, fruit du récent partenariat entre les deux sociétés.

Un outil résolument à suivre ….

Agilité

Polémique : Scrum aliène-t-il XP ?

Notre collègue Vikas Hazrati a résumé sur InfoQ: Do Extreme Programming Folks Care about Scrum? une discussion très « animée » initiée par Michael James à propos de Scrum vue par les praticiens d’XP (eXtreme Programming). Ce dernier pense que Scrum et XP sont des alliés, mais ce n’est pas l’avis de tout le monde.

Comme Guillaume Bodet l’expliquait dans Scrum ou XP ? Scrum et XP !, nous pensons que Scrum et XP sont complémentaires, Scrum se positionne au niveau de la gestion/organisation de projet tandis que XP concerne les activités de développement.
Mais comme le dit Bruce Robinson, XP n’est pas la seule méthode de développement et elle n’est pas forcément la plus adaptée dans tous les cas, on peut par exemple préférer la revue de code au pair programming.

Alistair Cockburn répète que les pratiques préconisées par XP sont utiles mais pas nécessaires, des projets fonctionnent très bien sans XP.
Peu importe la méthode, mais tous sont d’accord qu’un projet nécessite des pratiques de développement pour réussir. Effectivement Scrum fournit un cadre méthodologique mais elle nécessite d’être complétée, « implémentée » par des pratiques de développement.

Wayne Mack propose l’approche du menu chinois : apprenez les 2 méthodes, choisissez ensuite les éléments qui vous semble intéressants parmi le menu.
Attention toutefois, Vikas Hazrati nous rappelle à travers le ShuHaRi que choisir les éléments du menu et créer sa propre méthode demande de la maturité, il conseille de commencer par expérimenter une méthode telle que préconisée, et seulement une fois à l’aise avec la méthode vous pouvez essayer de la personnaliser.

Pour en revenir aux valeurs de l’agilité, la méthode n’est pas le principal, les personnes et leurs interactions sont plus importantes. Car même si vous appliquez de bonnes pratiques, cela ne vous protège pas contre une « mauvaise » équipe (manque de compétences techniques, mauvais relationnel, esprit compliqué…). Quelle que soit la méthode il faut des gens talentueux et motivés pour mener à bien un projet selon J. B. Rainsberger, cependant un processus peut aider et XP semble le mieux adapté pour compléter Scrum.

Même si le groupe n’a pu se mettre d’accord au final, certains ont mentionné avoir utilisé Scrum et XP ensemble avec succès !

La discussion originale est sur Yahoo! Extreme Programming: How is Scrum alienating the eXtreme Programming folks?.

RIA

Adobe AIR pour Linux

Adobe AIR est enfin disponible pour la plateforme Linux. Seul bémol, celui-ci est une version alpha. Néanmoins, cette version contient le runtime, un exemple d’application et le AIR SDK. Par ailleurs, Flex Builder 3 a aussi été mis à jour afin de supporter la mise en place d’applications AIR sous Linux.
Adobe continue son ascension et remporte de plus en plus de succès et d’adhésion. Va t-on vers une ère Adobe ?

Le coin de la technique

SCA Java EE Integration specification : v0.9

Pendant que le Java Community Process tarde à statuer sur le modèle de composants de bas niveau OSGI, la communauté SCA continue à avancer les pions de son standard d’assemblage de composants de haut niveau avec la publication d’une première ébauche de la SCA Java EE Integration specification. Cette spécification a le mérite d’apaiser le monde Java EE après la tonitruante déclaration de Michael Rowley (BEA) : « EJB session beans, MDBs, JAX-WS and even JMS aren’t usually necessary in an SCA universe » dans Does SCA define a new programming model for Java?.

Quel impact pour le quotidien des développeurs Java ? Quasiment aucun pour le moment ; SCA est une spécification à l’utilisation encore confidentielle (SCA est principalement présent dans Websphere ESB et Process Server).

IBM annonce Websphere MQ V7 pour Juin

Le marché des middlewares de messages est lui aussi modifié par l’émergence d’offres open source matures (Apache ActiveMQ, etc ). Dans cette atmosphère dynamisée, IBM Websphere MQ, le leader du marché, tourne la page de trois ans de V6.0 avec l’annonce de WMQ V7.0 pour Juin 2008.
Les principales améliorations :

• Amélioration des performances (particulièrement publish/subscribe, réception sur selector et messages non persistents).
• Simplification de l’administration du mode publish/subscribe et des ressources JMS.
• Bridge HTTP pour directement exposer les queues à des clients Web 2.0/Ajax.
• Intégration native du mode publish/subscribe au Queue Manager [1].

Nous aurions espéré :

• Un mécanisme de relivraison différé des messages équivalent à la redelivery policy d’ActiveMQ.
• Une amélioration des performances des temporary queues similaire à celle apportée aux selectors. L’utilisation de files temporaires est un modèle encore plus simple que les selectors pour réaliser des invocations synchrones avec un middleware de messages (cf pattern request/reply).

Plus d’informations dans Redbook: WebSphere MQ V7.0 Features and Enhancements (Draft).

[1] En v6.0, un broker périphérique était utilisé.

Complexité cyclomatique optimale : 11 selon Enerjy !

Les outils d’analyse statique de code fleurissent avec l’essor des serveur d’intégration continue. L’éditeur Enerjy, après avoir étudié des projets open source réputés à la loupe de son analyseur, révise la valeur optimale de la complexité à 11. On notera que cette valeur est légèrement supérieure à celle retenue par CheckStyle, le leader de l’analyse statique, qui estime que 10 est déjà excessif.

Si la valeur exacte est sujette à débat, c’est l’occasion de se rappeler que la complexité cyclomatique est un indicateur pertinent de qualité du code et que les environnements de développement et serveurs d’intégration continue rendent aujourd’hui facile le suivi de ces indicateurs.

Java Module System (JSR-277) et OSGI, un silence pesant

Nouveau rebondissement dans le feuilleton « JSR-277 : Java Modules System versus OSGI ».

La JSR d’assemblage des composants menée par Sun prenait un retard inquiétant pour être intégrée à la version 7 de Java (Dolphin). Un petit répit s’annonce avec le décalage de la sortie de Dolphin désormais planifiée pour Janvier 2009.

Si cette prolongation donne une chance à la JSR-277 de figurer dans la prochaine version de Java, il reste néanmoins un problème de gouvernance de fond sur cette spécification. Peter Kriens (OSGI Alliance) expliquait en Septembre dernier qu’il a été refoulé de l’expert group sans raison convaincante. Dalibor Topic (kaffe.org) a demandé en Janvier l’éviction de 9 membres de ce même expert group sur une mailing list du projet Open JDK. Les déclarations fusent et l’expert group de la JSR 277 qui ne communique toujours rien de concret sur la position du très important OSGI, laissant la place à la rumeur et au mécontentement …

Evènements de notre communauté en France et à l’étranger

Poissons d’avril

Premier jour d’avril oblige, certains ont annoncé de fausses nouvelles, surprenantes ou amusantes. Voici une liste des poissons d’avril que nous avons recensés :

• Microsoft rachète SpringSource
• Microsoft rachète TheServerSide.com (décidément Microsoft est en forme)
• Google et Richard Branson (Virgin) s’associent pour lancer la 1ère colonie sur Mars
• De l’ASCII Art dans le bytecode Java
• Le projet JavaRebel intègre une Intelligence Artificielle qui code à votre place pendant vos pauses-cafés
• Cédric Beust lance le projet Toledo : un générateur de code multi-langage
• Eclipse e4 déjà disponible
• TSS devient multilingue

La conférence agile sur les méthodes Agiles ! http://www.xpday.fr

Vous êtes en quête d’idées neuves pour rendre plus efficaces vos projets de développement logiciels…
Vous souhaitez en savoir plus sur les méthodes agiles, leurs bénéfices, leurs limites…
Vous avez mis en place des pratiques agiles au sein de vos projets et vous souhaitez confronter vos retours d’expérience à ceux d’autres praticiens…

La conférence XP Day s’adresse à tous les intervenants des projets logiciels: chefs de projet, clients, décideurs, développeurs… Loin des conférences « académiques » ou des événements commerciaux, le succès du format XP Day, déjà présenté au Royaume-Uni, Benelux, Allemagne, Italie, etc. s’explique par son orientation pragmatique. XP Day vous apporte des réponses concrètes, des idées que vous pouvez immédiatement mettre en pratique, des sessions interactives, démonstrations et débats sur les sujets suivants et bien d’autres encore:

• débuter avec Extreme Programming
• débuter avec l’intégration continue
• le TDD avec des frameworks: Spring, etc.
• contractualiser les projets agiles
• mieux communiquer avec les clients
• outils et langages favorables à l’agilité: Erlang, Javascript…
• comment aborder l’analyse en XP
• retours d’expérience sur Scrum, XP, etc…

Xebia est partenaire et sera présent, je présenterai une session le 6 Mai sur l’utilisation des librairies de Mock dans les tests unitaires:

• tour d’horizon des différents frameworks
• exemples concrets d’utilisation avec le framework EasyMock,
• utilisation dans le cadre d’une approche TDD.

XP Day est organisé avec le concours de l’Association Extreme Programming France (loi 1901). La conférence est à but non lucratif, votre participation aux frais permet de financer d’autres événements du même type. Elle est fixée pour 2008 à 120€, pour les adhérents de l’association au 31/12/2007 le tarif appliqué est de 90€. L’inscription au dîner est fixée à 20€ supplémentaires.

Pour vous inscrire ou consulter le programme : http://www.xpday.fr

Scrum ou XP ? Scrum ET XP !

Lors des Rencontres Agiles, que nous avons co-organisées en décembre dernier – et qui, soit dit en passant, ont rencontré un fort et encourageant succès -, plusieurs personnes m’ont demandé si, pour démarrer un projet agile, il était préférable de choisir eXtreme Programming (XP) ou Scrum. La réponse est simple : il faut adopter les deux !
La complémentarité de Scrum et XP est communément admise. Scrum se positionne au niveau de la gestion et de l’organisation de projet là où XP se positionne au niveau des activités de développement. C’est la raison pour laquelle ces deux approches fonctionnent si bien ensemble : elles adressent des problématiques différentes et se complètent mutuellement.

Cet article propose une présentation sommaire de Scrum et de la façon dont elle (il? non, allez, c’est plutôt une fille) s’articule avec eXtreme Programming… Bonne lecture !

Lire cet article »

L’analyse de couverture de code en Java

Il ne reste plus grand’monde pour soutenir que l’écriture de tests unitaires automatisés est une perte de temps sur un projet logiciel – la notion de dette technique entre dans les moeurs. Cette prise de conscience salutaire se heurte pourtant souvent à deux grandes catégories de difficultés :

• Le conservatisme – pour ne pas dire la stupidité – de certains chefs de projet, qui persistent à voir dans l’écriture des tests une activité contre-productive, qui servira de variable d’ajustement au moindre coup de grisou
• L’existant : quand le projet n’a pas systématisé la pratique du test dès son origine et que la multiplication des anomalies tardives le pousse à la réintroduire. Par où commencer ?

Pour le premier point, la solution passe par un effort pédagogique, ou, pour les cas désespérés, par une reconversion imposée ou un congé sabbatique.
Pour le second, il faut un peu de bon sens, et un peu d’outillage.

C’est sur le deuxième aspect qu’interviennent les outils d’analyse de couverture de code (ou « code coverage » en anglais). Dans la suite, nous verrons que ces outils ne permettent pas d’évaluer les tests unitaires d’un point de vue qualitatif, mais qu’ils peuvent en revanche apporter au bon sens un précieux appui en répondant aux questions suivantes :

• Quels sont les tests unitaires déjà en place ?
• Les tests sont-ils en phase (à jour) avec le code qu’ils testent ?
• Les fonctions critiques de l’application sont-elles couvertes par les tests ?

Lire cet article »

Un nouveau type d’architecte: l’Architecte Agile

On observe ces derniers temps de multiples débats sur le fait de savoir si une équipe agile a besoin d’un architecte en son sein, et sur la valeur ajoutée de ce dernier sur un projet agile alors que l’architecture évolue à chaque itération.
Les architectes « Tour d’Ivoire » se révèlent petit à petit être le maillon faible des projets agiles. Les responsabilités des architectes traditionnels sont distribuées ci et là au sein des équipes agiles, leur supprimant au passage des tâches qui leur étaient auparavant attribuées.
Une nouveau genre est en train d’apparaître et de sortir du lot comme le prédit la théorie de l’évolution de Charles Darwin – question d’adaptation. Le rôle d’un Architecte Agile ne doit pas susciter de questions et tout membre d’une équipe agile vous le confirmera: ce sont des équipiers qui apportent l’une des plus grandes valeurs ajoutées.

Alors qui est cet Architecte Agile ? Comment savoir si l’architecte de votre équipe est un Architecte Agile ?

Lire cet article »

Actualité éditeurs / SSII

• Microsoft et Yahoo! : quels impacts pour l’écosystème Java ?
• Consolidation des stacks open source Java : Spring Source rachète Covalent
• MySQL sort un nouveau moteur de stockage
• Spring Security supporte OpenID

Agilité

• 10 façons de se planter malgré Scrum et XP

RIA

• Librairie de composants Flash/Flex par Yahoo!

Le coin de la technique

• Debate: Is Maven the right tool for builds?

Actualité éditeurs / SSII

Microsoft et Yahoo! : quels impacts pour l’écosystème Java ?

La proposition de rachat de Yahoo! par Microsoft pour 44 milliards de dollars concerne avant tout les aspects médias et publicité des deux entreprises.

L’absorption du portail par la firme de Redmond aurait des effets limités sur l’écosystème Java auquel Yahoo! préfère LAMP (excepté Yahoo! Bix qui utilise massivement Java).
On notera qu’un doute plane sur l’avenir de Yahoo! UI, framework Ajax que Yahoo! met à disposition sous la conciliante licence open source BSD mais dont il conserve la gouvernance exclusive (« Copyright (c) 2008, Yahoo! Inc. All rights reserved. »). La gouvernance partagée des projets Open Source à la Apache ou Eclipse a parfois du bon pour les utilisateurs

Par ailleurs, Yahoo est le premier sponsor ex-aequo avec Google de la Fondation Apache. La fondation Open Source devra peut être chercher un soutien financier ailleurs.

Enfin, ce rachat est encore très hypothétique et l’irruption de Google en chevalier blanc de Yahoo! ajoute au suspens.

Consolidation des stacks open source Java : Spring Source rachète Covalent

Les stacks open source Apache et Spring Framework convergent avec le rachat par SpringSource de Covalent, le leader du support et des services sur les projets de la Fondation Apache. Covalent est notamment un acteur clef du projet Tomcat.

C’est pour les clients la perspective d’une meilleure intégration de Tomcat à Spring et d’offres de support tout-en-un. A plus long terme, on peut, entre autre, espérer l’apparition d’OSGI dans Tomcat comme le sous-entend Rod Jonhson (le fondateur de Spring).

On regrettera que cette annonce ait été marquée par des réactions agressives de la communauté JBoss. Marc Fleury a débuté avec une critique très acerbe sur son blog et les employés JBoss secondés par quelques zélotes ont inondé l’annonce sur The Server Side de commentaires aussi virulents que discutables sur le fond.
Cette attitude rappelle une période que l’on croyait révolue après le rachat de JBoss par le très sérieux et professionnel RedHat. C’est vraiment dommage pour la qualité du portfolio JBoss (Hibernate, JBoss AS, Drools, etc) qui risque de creuser son isolement.

MySQL sort un nouveau moteur de stockage

Michael Widenius, CTO de MySQL, annonce la sortie de Maria, un nouveau moteur de stockage pour MySQL [1] visant directement le remplacement du moteur InnoDB.
Si la version 1 de Maria ne remplace fonctionnellement que le moteur MyIsam, la version 2 supportera les transactions (commit/rollback et ACIDité) et sera alors une alternative à InnoDB.

On peut y voir le souhait d’indépendance de MySQL face à Oracle qui a racheté InnoDB en octobre 2005.

[1] Ressources complémentaires : MySQL docs : MySQL Pluggable Storage Engine Architecture, Mike Peters : MySQL Storage Engines

Spring Security supporte OpenID

L’offre grand public autour d’OpenID continue sa progression (cf Techcrunch). Après Microsoft, récemment Yahoo, c’est maintenant au tour du secteur des entreprises de voir arriver une offre autour d’OpenID : Spring Security.

Allez voir l’annonce sur la mailing list ou l’annonce de Ray Krueger, mainteneur du projet

Avec le support de Spring, OpenID va-t-il conquérir les entreprises ?

Agilité

10 façons de se planter malgré Scrum et XP

Henrik Kniberg liste les principales erreurs à éviter dans un projet Scrum et XP dans 10 ways to screw up with Scrum and XP, qu’il a présenté lors de la conférence Suédoise JFokus.
Il a également publié une Scrum checklist qui donne une vision synthétique des pratiques à mettre en oeuvre dans Scrum, classées selon 3 niveaux d’importance.

En recoupant les 2 documents, vous pouvez porter un regard critique sur votre projet Scrum afin de vous améliorer.
A lire avant votre prochaine rétrospective !

RIA

Librairie de composants Flash/Flex par Yahoo!

Yahoo! met à disposition de la communauté un ensemble de composants Flash et Flex, ASTRA destiné à étendre la liste (déjà bien riche) de composants de base de Flash et Flex. Yahoo! continue sa politique de générosité, l’excellente librairie AJAX Yahoo! UI a récemment fêté ses 2 ans, et se positionne intelligemment sur les deux fronts RIA, AJAX ET Flex, en attendant la prise de parts de marché du bulldozer SilverLight (Microsoft dispose d’un outil qui devrait lui permettre de déployer assez aisément des dizaines de millions de plugins SilverLight…).

Le coin de la technique

Debate: Is Maven the right tool for builds?

Dans cet article d’infoQ, l’utilisation et l’utilité de Maven fait débat. D’un côté, il en ressort que beaucoup de projets n’arrivent pas à mettre en place cet outil car jugé trop complexe, ou bien que certains plugins du repository central de Maven sont buggés… D’un autre côté, nous voyons que d’autres projets sont très satisfaits de cet outil, et préfèrent Maven à Ant par exemple. Bien entendu parmi ceux qui sont pour Maven, tout n’est pas rose… Matt Raible explique pourquoi le projet Grail n’utilise pas Maven en soulignant certains problèmes et propose même des pistes de solutions.
Enfin il en ressort que beaucoup de personnes ne savent pas utiliser Maven d’où une certaine reticence. Pour finir, nous pouvons dire que certes Maven requiert un certain coût d’entrée, mais une fois celui-ci passé il devient vraiment très simple de mettre en place cet outil avec tout les bénéfices que l’on peut en tirer !

On observe ces derniers temps de multiples débats sur le fait de savoir si une équipe agile a besoin d’un architecte en son sein, et sur la valeur ajoutée de ce dernier sur un projet agile alors que l’architecture évolue à chaque itération.
Les architectes « Tour d’Ivoire » se révèlent petit à petit être le maillon faible des projets agiles. Les responsabilités des architectes traditionnels sont distribuées ci et là au sein des équipes agiles, leur supprimant au passage des tâches qui leur étaient auparavant attribuées.
Une nouveau genre est en train d’apparaître et de sortir du lot comme le prédit la théorie de l’évolution de Charles Darwin – question d’adaptation. Le rôle d’un Architecte Agile ne doit pas susciter de questions et tout membre d’une équipe agile vous le confirmera: ce sont des équipiers qui apportent l’une des plus grandes valeurs ajoutées.

Alors qui est cet Architecte Agile ? Comment savoir si l’architecte de votre équipe est un Architecte Agile ?

La réponse n’est pas aisée ; néanmoins l’Architecte Agile présente des signes distinctifs, des aptitudes qu’il exercera au quotidien. Un Architecte Agile doit savoir jongler entre ces différentes caractéristiques. Si l’architecte de votre équipe possède la plupart des caractéristiques qui suivent, et que vous le voyez jongler entre celles ci, c’est certainement un bon Architecte Agile.

Petit avertissement, la description faite ci-dessous peut certes paraître un peu idéaliste, mais elle donne sans aucun doute la direction qu’un Architecte Agile doit prendre.

Le but premier d’un Architecte Agile : délivrer une solution qui fonctionne avec une qualité optimale

Il y a deux aspects à aborder ici. Premièrement, la solution doit être de qualité optimale. Idéalement, sur un projet agile, les exigences de qualité (souvent appelées exigences non fonctionnelles) doivent faire partie intégrante de chaque itération. Les aspects tels que la sécurité, la performance, la qualité du code, etc. font partie intégrante d’une User Story [1] existante dans le backlog ou forment une user story distincte. Cependant, force est de constater que l’équipe agile, impliquée dans l’implémentation des fonctionnalités oublie bien souvent ces exigences de qualité. L’Architecte Agile doit alors s’assurer que le serveur d’intégration continue communique bien, à tous les membres de l’équipe à la fin de chaque cycle de build, différentes métriques, telles que des statistiques sur la qualité du code, la performance du système, les anomalies dans le code détectées par les tests unitaires… Il doit garder un œil sur ces données et attirer inlassablement l’attention de l’équipe agile sur celles-ci.

Le deuxième but est de délivrer une solution qui fonctionne. L’Architecte Agile évalue différentes options d’implémentation avec l’équipe afin de parvenir à une solution qui fonctionne et qui génère de la valeur métier pour le client. Il s’assure non seulement que la solution fonctionne de manière isolée mais également qu’elle s’intègre également parfaitement dans l’architecture de l’entreprise déjà en place, et qu’elle est suffisamment robuste pour être modifiée et étendue dans le futur. Il se concentre sur la solution qui fonctionne, non sur des documents et des livrables qui ne contribueraient pas directement à la mise en place de la solution.

L’Architecte Agile est garant de l’intégrité conceptuelle

Il s’assure que, dans le coeur de l’action, personne n’oublie la mission initiale. Sous la pression du calendrier et des obstacles techniques, les développeurs prennent parfois des décisions qui éloignent le projet de ses objectifs métiers. L’Architecte Agile maintient dans un esprit collectif les objectifs de la mission.
L’intégrité conceptuelle est atteinte lorsque le système développé démontre consistance et uniformité de ses éléments ainsi que la fluidité de leur intégration.
Prenons pour exemple la métaphore du Drag and Drop présente dans tous les systèmes d’exploitation modernes. Si le système d’exploitation a été bâti avec une bonne intégrité conceptuelle, le Drag and Drop devrait fonctionner partout. Ainsi, pour ouvrir un fichier on doit pouvoir le prendre et à le glisser sur l’application adéquate, et supprimer un fichier doit être aussi simple que de le prendre et de le glisser/déposer dans la corbeille. En résumé, l’intégrité conceptuelle consiste à créer un système sans surprise.

Un Architecte Agile travaille réellement au sein de l’équipe

Il est impliqué durant la totalité du projet. Des tâches de programmation lui sont affectées, et il implémente des User Stories, comme n’importe quel autre développeur. L’implémentation des User Stories ne constitue pas son unique tâche dans la journée, mais représente une part non négligeable de son travail.
Il fait profiter le projet de son expérience, et donne les grandes directions sur les différents choix d’architecture effectués tout au long de la vie du projet. L’architecture n’est pas figée durant les premières itérations, et continue à évoluer lors de chaque itération, ce qui signifie que contrairement aux architectes « traditionnels », il ne quitte pas le projet pour en rejoindre un nouveau après la traditionnelle phase projet de « mise en place de l’architecture ».

Un Architecte Agile écrit les tests systèmes qui permettent de tester les performances de l’architecture

Il écrit les tests d’infrastructure qui permettent de tester l’architecture du système. Si un mauvais choix d’architecture provoque un problème de performance, celui-ci doit être détecté par le test d’infrastructure. Puisque les méthodes agiles recommandent d’écrire les tests en premier lieu (Test Driven Development), il écrit les tests qui prouvent que le système n’offre pas la qualité de service attendue, puis effectue ensuite les modifications nécessaires afin de faire passer ce test. Dans les cas les plus rares où l’écriture d’un test peut s’avérée être difficile, il réfléchit à d’autres manières de tester l’architecture.
Tout ceci permet de s’assurer que des efforts ne sont pas vains, donnant lieu à un design non éprouvé. Le test confirme la viabilité d’un bon design dans lequel les efforts de développement vont êtres portés. N’importe quelle décision d’architecture, qu’elle soit majeure ou mineure, doit donc être précédée par un test.
Par exemple, si le système est supposé supporter une charge de 10 000 utilisateurs simultanés, l’Architecte Agile écrit des scénarios JMeter (ou à l’aide de n’importe quel autre injecteur) qui vont générer la charge adéquate sur le système, afin de s’assurer que tout fonctionne normalement en charge. Si le test échoue, il convient ensuite de modifier l’architecture pour faire en sorte que le test passe (NDT: ou de corriger les anomalies de développement qui ont fait échouer le test). Après ces modifications, le test est à nouveau exécuté cette fois ci avec succès.

Un Architecte Agile participe et travaille en équipe, avant tout

Il n’effectue pas seul les choix techniques et de conception: ces décisions doivent être prises de manière collégiale par l’équipe. Il a l’esprit ouvert, est totalement conscient du fait qu’il n’est pas omniscient, et n’est jamais obtus et fermé à propos de ses propres idées.
Les meilleures idées viennent de l’équipe, lorsque ses membres réfléchissent tous ensemble; n’importe qui est capable d’avoir une bonne idée ou de donner un point de vue intéressant. Une communication ouverte et honnête permet aux gens de prendre de meilleures décisions basées sur une information plus précise. L’Architecte Agile doit faire preuve d’empathie, doit traiter les gens avec respect, et montre qu’on apprend en permanence les uns des autres. Il favorise le consensus et permet à tous les membres de l’équipe de contribuer à l’élaboration de la solution, et par la même de tous les responsabiliser.
Si le client présente la problématique du projet et que l’architecte propose seul dans la foulée une unique solution, vous ne travaillez probablement pas avec un véritable architecte…

Un Architecte Agile est un mentor sur lequel on peut se reposer

C’est une des caractéristiques les plus importantes. Il travaille en permanence avec l’équipe afin d’améliorer sa capacité à prendre des décisions. Ce travail pédagogique est évidemment également une corde supplémentaire à son arc. Il utilise au mieux les capacités de l’équipe en la guidant sur les nouvelles technologies, en lui apportant son soutien sur les frameworks techniques. Il s’assure par exemple qu’elle ne va pas rejeter un choix de design par facilité, manque de motivation ou d’expérience sur certaines techniques ou technologies. Si tel est le cas, il comble le déficit technique de l’équipe afin de lui permettre de prendre les décisions en toute connaissance de cause.
Comme Martin Fowler le dit, « Ceci établit la règle empirique que la valeur d’un architecte est inversement proportionnelle au nombre de décisions qu’il ou elle prend ».

Un Architecte Agile est un habile médiateur

Une équipe agile comprend des membres qualifiés et passionnés. On observe fréquemment des divergences d’opinion sur certains choix de design, sur la meilleure manière d’implémenter une fonctionnalité, sur les façons d’améliorer le processus de développement, etc. Ces différences d’opinion, si elles ne sont pas prises en compte rapidement et de manière efficace, peuvent mener à de houleux échanges et de sérieux différents au sein de l’équipe. Dans ces cas précis, l’équipe a besoin d’un médiateur mature et plus expérimenté, qui saura aider l’équipe et régler ces différents. L’Architecte Agile convient parfaitement par son niveau de maturité et d’expérience.

Un Architecte Agile ne fait jamais de « Big Modeling Up Front » (BMUF)

La plupart du temps il n’utilise pas les outils de génération de code qui permettent de modéliser les grandes décisions d’architecture. A la place, il ne modélise juste « ce qu’il faut », généralement sur un tableau. Le premier modèle simple imaginé grandit et s’enrichit ensuite à chaque itération. L’Architecte Agile suit les concepts du Agile Modeling, et pour lui « le modèle, c’est le code ». S’il est nécessaire de générer le modèle à des fins documentaires, il peut par exemple être généré par un outil de reverse engineering.
Les modèles, les documents, le contenu, et la manière de communiquer doivent être les plus simples et concis possibles. L’idée est de se concentrer sur le contenu, et non sa représentation ou sa « mise en forme » qui ajoutent peu de valeur métier.

Un Architecte Agile cherche à faire du refactoring à grande échelle

Il est en permanence à la recherche de problèmes qui pourraient s’avérer par la suite être de sérieux obstacles techniques, et nuire à l’architecture du projet. Au fur et à mesure que le système s’étend, il s’assure que l’architecture suit le rythme. Il est en permanence à l’affût de changements importants qui pourraient avoir un plus fort impact que prévu. Par exemple, si l’application n’utilise pas assez de CPU, et que les performances globales ne sont pas ce qu’elles devraient être, il va introduire du multi-threading dans l’application afin qu’elle utilise ces ressources disponibles, afin de délivrer de meilleures performances. Il démarre par la solution la plus simple possible, et refactor ensuite en permanence la solution afin de garder le niveau de qualité requis tout en implémentant les nouvelles fonctionnalités.
L’Architecte Agile aide également à rendre le système modulaire. Au lieu de l’approche « Diviser pour mieux régner », il recommande de « Régner pour mieux diviser ». Au démarrage du projet, un système le plus simple possible qui fonctionne va être implémenté par une petite équipe. Par la suite, grâce à l’expérience de l’Architecte, l’équipe divisera le système en sous composants naturels, en gardant la vision globale, et on ajoutera si nécessaire de nouveaux membres à l’équipe pour le développement de chaque nouveau sous composant.

Un Architecte Agile est une « super glue »

Il se comporte comme une « super glue » entre l’équipe, les différents fournisseurs et les clients en leur communiquant les différentes décisions prises sur l’évolution de l’architecture et du design, les obstacles techniques rencontrés, etc. C’est l’intermédiaire entre les mondes métier et technique (NDT : dans la méthode SCRUM, c’est plutôt le ScrumMaster qui prend en charge ce rôle de suppression des obstacles rencontrés).
Il a la capacité de voir les obstacles métiers d’un point de vue technique, et les problèmes techniques à travers un contexte métier. Il sait expliquer la valeur métier de tel ou tel choix technique au client. Par exemple, s’il s’agit de choisir une technologie par rapport à une autre, il doit être capable d’expliquer au client la valeur métier ajoutée en terme d’utilisation des ressources, de capacité de changement, d’économies réalisées, etc. Il pense au « comment » mais aussi au « pourquoi » lorsqu’il travaille sur un projet où il faut répondre à la fois à des problématiques métiers et techniques.
La plupart des architectes traditionnels vont se concentrer sur la manière d’implémenter une solution, sans prendre le recul nécessaire qui permettrait de se demander si la solution est la meilleure possible. L’Architecte Agile s’efforce de travailler avec le client et cherche à savoir pourquoi une solution donnée est nécessaire, s’il y aurait une manière plus simple et plus efficace de répondre au besoin exprimé que la solution proposée par le client.

Dernier signe, mais pas des moindres, l’Architecte Agile embrasse le changement

Il embrasse le changement à la fois pour l’architecture et pour son propre rôle. La vraie architecture agile consiste à supporter le changement rapidement et facilement sans la dégrader, et avec le minimum d’impact sur les systèmes externes. Afin de s’en assurer, l’Architecte Agile démarre avec un design correct, et le fait évoluer constamment tout au long du cycle de vie du projet. Il implémente de façon modulaire les composants communs, masque derrière des interfaces ceux qui sont susceptibles de changer le plus souvent afin de minimiser les impacts lorsqu’ils évoluent.
Enfin, un vrai rôle agile consiste à pouvoir jouer de multiples rôles. Il prend les rôles de programmeur, de testeur de performance, de mentor, de médiateur, de membre de l’équipe, de « glue », et potentiellement celui de manager, tout ceci peut-être dans une seule journée de travail.

Conclusion

Les fondations de la tour d’ivoire des architectes sont ébranlées. Le nouveau type d’architecte appelé Architecte Agile grandit, s’affirme, travaille, et contribue aux équipes. Elle adhère totalement au principe numéro 12 de Toyota : « Allez et voyez par vous-mêmes afin de totalement embrasser la situation ». Ils sont des membres de premier ordre de l’équipe de développement et ne travaillent pas pour l’équipe mais dans l’équipe. Pour pouvoir prétendre au rôle d’Architecte Agile, il convient ainsi de faire preuve de maturité, d’expérience, et par-dessus tout d’être capable de jongler entre différents rôles et caractéristiques au sein de l’équipe de développement.

Alors, possédez-vous déjà un Architecte Agile au sein de votre équipe?

[1] Une « User Story » est une exigence définie par le « Product Owner » (dans le « Backlog » avec la méthode SCRUM)

La complémentarité de Scrum et XP est communément admise. Scrum se positionne au niveau de la gestion et de l’organisation de projet là où XP se positionne au niveau des activités de développement. C’est la raison pour laquelle ces deux approches fonctionnent si bien ensemble : elles adressent des problématiques différentes et se complètent mutuellement.

Je vous propose, dans cet article, une présentation sommaire de Scrum et de la façon dont elle (il? non, allez, c’est plutôt une fille) s’articule avec eXtreme Programming… Bonne lecture !

Scrum

Davantage qu’une méthode formelle, Scrum peut être vu comme un framework méthodologique – ses fondateurs parlent d’organisationnal pattern – dont l’implémentation doit être ajustée en fonction des caractéristiques techniques, organisationnelles et culturelles des projets qui souhaitent la mettre en oeuvre (Scrum, au demeurant, ne limite pas son champ d’application aux seuls projets informatiques : ses principes sont applicables pour toute activité visant à produire un résultat).

Dans ses grandes lignes, Scrum définit un jeu minimal d’acteurs, de cérémonies et d’artefacts qui permettent de relever les défis principaux du développement incrémental : la planification, la gestion du temps et la gestion des obstacles. Scrum est entièrement piloté par la Valeur Métier – la gestion des risques, en particulier, est réalisée au travers de ce prisme. Scrum identifie trois acteurs :

• le Product Owner (Directeur de Produit), qui possède l’expertise fonctionnelle et est à même de réaliser les arbitrages nécessaires à la priorisation des développements. Son rôle est absolument essentiel, et son respect des règles du jeu est la pierre angulaire du succès d’un projet agile.
• le Scrum Master, membre de l’Equipe, et dont la tâche principale est d’optimiser la capacité de production de l’Equipe en l’aidant à travailler de façon autonome et à s’améliorer constamment. Il est également le garant de la bonne implémentation de Scrum.
• l’Equipe, dont la taille doit être réduite (7 à 9 personnes est généralement admis comme une borne supérieure), et qui prend en charge le développement du produit (planification, conception, codage, tests, documentation) sans spécialisation des rôles. La particularité d’une Equipe Scrum est d’être « auto-organisée », et donc dépourvue de hiérarchie. Cet aspect constitue une rupture radicale avec les approches managériales traditionnelles, qui privilégient un contrôle centralisé généralement incarné par le Chef de Projet.

L’unité de temps, dans Scrum, est le Sprint. Un sprint est une itération courte (de l’ordre de 2 à 4 semaines) dont le périmètre est garanti et défini lors d’une cérémonie de planification initiale.

Le schéma suivant décrit l’articulation générale de Scrum :

Scrum définit également trois artefacts (nous conservons les noms anglais pour rester consistant avec la littérature sur le sujet) :

• le Product Backlog, que nous décrivons plus loin
• le Sprint Backlog, également décrit plus loin
• le Burndown Chart, qui est une représentation graphique très simple de l’avancement du projet (un Burndown Chart est produit pour chaque Sprint, un autre pour la version du produit)

Le Product Backlog est fondamental à Scrum – sans lui, rien n’est possible.

Le Product Backlog est la liste des fonctionnalités du logiciel. Les éléments du backlog sont rédigés sous forme de « User Stories » (une User Story est une forme simplifiée et faiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métier du produit. A minima, un élément du backlog (ou une histoire) comporte typiquement les informations suivantes :

• un identifiant – unique, il permet de tracer l’élément quand on le renomme
• un nom – court et descriptif, suffisamment clair pour que le Directeur de Produit et l’Equipe comprennent approximativement de quoi il est question
• l’importance – un chiffre permettant de hiérarchiser l’importance de l’élément aux yeux du Directeur de Produit. Sa valeur absolue ne signifie rien, seule la valeur relative compte
• l’estimation initiale – exprimée en points de complexité, et dont la valeur est déterminée par l’Equipe. Pour établir cette estimation, on utilise le plus souvent une technique issue de l’eXtreme Programming : le Planning Poker.
• comment faire la démo ? – cela correspond globalement à la spécification d’un test fonctionnel simple.
• des notes – aussi brèves que possible, visant à clarifier certains points ou à renvoyer vers d’autres ressources

Le Product Backlog peut également contenir des éléments techniques – mais il est indispensable alors qu’ils soient libellés selon un angle métier, afin que le Directeur de Produit puisse lui affecter une valeur.

Le Product Backlog peut être conservé sous différentes formes, la plus fréquente – et probablement la plus efficace – étant un simple tableau Excel partagé.

Le Product Backlog n’est pas un document figé : tout au long du projet, les histoires peuvent être modifiées, fusionnées ou segmentées (celles bien sûr qui ne sont pas encore achevées) ; de nouvelles histoires peuvent être ajoutées, d’autres supprimées ; l’importance et l’estimation initiale peuvent être revues, à la hausse ou à la baisse.Au début de chaque Sprint a lieu la cérémonie qui est probablement la plus importante de Scrum : le Sprint Planning (planification du Sprint). Le Sprint Planning réunit l’Equipe et le Directeur de Produit pour déterminer l’objectif et le contenu du Sprint à venir. C’est durant cette cérémonie que l’estimation fine de la charge de développement de chaque histoire est déterminée. Ces histoires sont découpées en tâches dont chacune fait l’objet d’une estimation de charge – exprimée en heures ou en jours. Il est important de noter que c’est l’Equipe qui détermine la charge afférente à chaque tâche. Le principal résultat de cette cérémonie est le Sprint Backlog, qui regroupe l’ensemble des fonctionnalités que l’Equipe s’engage à produire durant l’itération naissante, et liste les tâches correspondantes.

La charge totale du Sprint Backlog ne doit pas excéder la capacité de production de l’Equipe (il existe plusieurs techniques que nous n’aborderons pas ici pour établir cette capacité de production, ou vélocité estimée).

Au terme de chaque sprint, le produit partiel est livré avec le niveau de qualité attendu pour son exploitation en production – cette caractéristique est à l’origine du qualificatif « incrémental » souvent associé aux méthodes agiles. Les histoires implémentées font l’objet d’une démonstration publique.

Les méthodes agiles sont inspirées des pratiques industrielles de la production en flux tendus et du zéro-défaut – un ensemble de pratiques désignées dans l’industrie par le terme Lean. L’une des caractéristiques de cette approche est de ne jamais figer les méthodes de travail, mais d’intégrer dans l’activité une introspection permanente sous-tendue par la recherche systématique d’axes d’amélioration. Une autre caractéristique est de ne jamais utiliser la qualité comme variable d’ajustement. Dans Scrum (et d’une façon générale pour toutes les méthodes agiles), la qualité du produit est de la responsabilité de l’Equipe, et ne fait pas l’objet de négociations.

Afin de faciliter cette démarche, Scrum intègre un certain nombre de cérémonies additionnelles – une cérémonie est une réunion dont la durée est fixée et dont les produits en entrée et en sortie sont définis. La limite de temps pour chacune des cérémonies fait partie de l’ADN de Scrum (on parle de time boxing).

Voici les principales cérémonies préconisées par Scrum :

• le Sprint planning, que nous avons déjà abordé
• la mêlée quotidienne (Daily Scrum), courte cérémonie (de l’ordre de 15 minutes) menée chaque jour avec les membres de l’Equipe et le Directeur de Produit, et dont l’objectif est de maintenir chacun au courant de l’activité de tous, de déterminer les tâches de la journée et d’identifier les éventuels obstacles qui ralentissent ou empêchent la progression du sprint
• la revue de sprint (Sprint Review), qui consiste pour l’essentiel, au terme de chaque itération, à faire une démonstration publique du résultat du sprint ; cette cérémonie permet de garantir le caractère incrémental du développement (pour être démontré, le produit doit être utilisable) mais aussi de recueillir un retour régulier des commanditaires aux fins d’ajuster le contenu du backlog de produit
• la rétrospective (au moins 1 heure), qui réunit l’équipe et le Product Owner au terme de chaque sprint afin d’identifier les erreurs commises lors du sprint précédent et de définir un plan d’actions (concret et affecté) en vue d’améliorer le processus ; la rétrospective est une cérémonie capitale qui incarne l’un des principes fondamentaux énoncés par le Manifeste Agile : « A intervalles réguliers, l’équipe réfléchit sur les moyens de devenir plus efficace, puis adapte et ajuste son comportement en conséquence ».

Une dernière question peut se poser : quels outils utiliser pour assurer le suivi de projet ? Il existe un certain nombre d’offres logicielles dans ce domaine. Dans la pratique, nous préconisons de débuter avec l’outillage le plus élémentaire : une feuille Excel, des post-it et un mur. Avec l’expérience, et en adhérant aux principes généraux de la méthode (inspecter et s’adapter), le Scrum Master pourra choisir d’utiliser d’autres outils. Dans la pratique, une telle démarche n’est que rarement nécessaire.

Scrum, on le voit, adresse la problématique du processus de production du logiciel, l’organisation et la dynamique du projet. Le développement incrémental, néanmoins, suppose des pratiques d’ingénierie logicielle rigoureuses et efficicaces, que Scrum ne couvre pas – rappelons que Scrum est avant tout un style organisationnel. C’est précisément sur ce terrain des techniques de génie logiciel incrémental que l’eXtreme Programming trouve tout son sens, en proposant un certain nombre de pratiques reconnues aujourd’hui comme l’état de l’art.

eXtreme Programming – XP

La première des pratiques de l’eXtreme Programming, la plus fondamentale également, est le test automatisé.

L’approche incrémentale suppose une vision minimaliste – on aurait envie de dire zen – du développement : seules les fonctionnalités effectivement nécessaires sont développées, et le design adopté doit être le plus simple imaginable permettant d’implémenter intégralement la fonctionnalité (ce principe est souvent désigné sous l’acronyme KISS : Keep It Simple and Stupid). Le Manifeste Agile définit au demeurant la simplicité comme « l’art de maximiser le volume de ce qui ne doit pas être fait ». Conséquence de cette recherche de simplicité, certains choix de design, suffisants à un moment donné, peuvent s’avérer inadaptés lors de développements ultérieurs. L’ajustement se fait alors par refactoring (ou ré-ingénierie), qui consiste à modifier le design voire l’architecture d’un composant sans changer son comportement. Le refactoring – une opération techniquement triviale avec les environnements de développement java, plus délicate lorsqu’il s’agit de la base de données – comporte un risque de régression évident, risque couvert en principe par la pratique des tests unitaires. L’équation est alors simple : sans tests unitaires, le refactoring devient rapidement impossible ; sans refactroring, les choix d’implémentation ne peuvent plus être remis en question ; sans remise en question, le développement incrémental devient illusoire, et c’est tout l’édifice du développement agile qui s’écroule.

Le test automatisé n’est pas seulement une bonne pratique du développement agile : il en est l’épine dorsale.

XP inclut la systématisation des tests automatisés – unitaires, fonctionnels, d’intégration, de performance, le plus est le mieux. Poussée à l’extrême, cette pratique a donné naissance au principe du TDD (Test Driven Development). Le TDD modifie sensiblement la pratique du développement. Son principe est d’une redoutable simplicité, mais sa mise en oeuvre est un véritable défi. Voici comment Henrik Kniberg résume le TDD :

Test-driven development means that you write an automated test, then you write just enough code to make that one test pass, then you refactor the code primarily to improve readability and remove duplication. Rinse and repeat.

Traduction : le développeur écrit en premier lieu un test automatisé de la fonctionnalité qu’il souhaite implémenter, développe ensuite juste assez de code pour satisfaire le test et finalement remanie le code pour améliorer le design et supprimer la duplication.

Outre les bénéfices classiques des tests unitaires, le TDD possède deux vertus cardinales : il permet de maintenir le focus du développeur sur les fonctionnalités réellement utiles ; il a des effets spontanés et profonds sur la qualité du design.

Au delà du TDD, XP comprend un certain nombre de pratiques dont la mise en place est souvent associée à l’adoption des méthodes agiles – sans pour autant sue cette mise en place soit obligatoire.
Voici, sans exhaustive, les plus importantes de ces pratiques :

• le Refactoring ; nous l’avons déjà rapidement abordé, c’est une pratique intrinsèque du développement incrémental et qui mériterait un billet à part entière. Pour une bonne introduction aux technique de refactoring objet, je vous invite à consulter le site que Martin Fowler a consacré au sujet : refactoring.com.
• l’Intégration Continue ; cette pratique consiste à déclencher de façon systématique le système de build – qui comprend notamment la compilation et l’exécution des tests automatisés – chaque fois qu’un membre de l’équipe valide des sources dans le référentiel projet ; c’est une pratique essentielle pour détecter et corriger au plus tôt les problèmes d’intégration des développements (principe de fail fast)
• la Propriété Collective ; la propriété collective du code consiste à ne pas spécialiser certains membres de l’équipe sur certains composants – et donc à favoriser la polyvalence au sein de l’équipe. Elle est évidemment favorisée par des pratiques telles que la programmation en binôme qui favorise l’appropriation d’une base commune de code. Les équipes avec un haut niveau d’appropriation collective de code sont réputées pour être plus robustes : un sprint ne sera par exemple pas forcément menacé par l’absence ponctuelle d’un membre de l’équipe.
• les Normes de développement ; sans être une particularité de l’eXtreme Programming, les normes de développement en sont un élément clé, facilitant les tests, l’intégration continue et l’appropriation collective de la base de code. Elles renforcent également la consistance des APIs.
• la Programmation en binôme (Pair Programming), qui consiste à développer à deux sur un même poste ; cette pratique, souvent mal comprise, n’est que rarement systématisée. Il ne faut par contre pas s’interdire son utilisation ponctuelle, par exemple sur une nouvelle technologie, une problématique pointue, un fonctionnel plus complexe, ou plus simplement, si l’un des membres de l’équipe demande de l’assistance. C’est aussi une pratique utile lors des montée en charge de l’équipe : elle permet d’intégrer plus rapidement les nouveaux développeurs et de leur communiquer la culture de l’équipe.
• un Rythme soutenable ; ce principe est commun à toutes les méthodes agiles, et directement issu du heijunka Lean ; il part du principe qu’il n’y a rien de plus contre-productif à moyen terme que de maintenir une équipe de développement sous la pression d’une charge de travail supérieure à sa capacité de production – cela revient à étrangler la poule aux œufs d’or et se traduit généralement par une baisse massive de la qualité et de la motivation.

Certaines des pratiques de l’eXtreme Programming ont irrigué Scrum (ou le contraire, peu importe) : « une équipe », « une même pièce », la notion de « stories », le « rythme soutenable » ou encore le « planning game », raison pour laquelle ces deux approche sont très complémentaires.

Cet article vous a proposé un rapide aperçu de Scrum et XP et aura, je l’espère, contribué à mettre en exergue la complémentarité des deux approches. Beaucoup de notions ont été évoquées de façon trop brève, et je reviendrai dessus dans de prochains billets… N’hésitez pas à laisser vos commentaires et questions !