UPDATE : Cette formation se déroulera finalement le 12 et 13 mai

Si vous êtes en train de lire ce post à 23h, au travail, devant votre écran d’ordinateur, à corriger les bugs de votre application dont vous aimeriez bien terminer la mise en production, alors sauvez vos qualités de vie, gagnez en sérénité, ne vous énervez plus contre vous-même, ni votre ordinateur, venez vous avez sûrement besoin d’une formation sur le développement piloté par les tests.

Le « Test Driven Development » est une pratique de développement issue d’eXtreme Programming, dont le but consiste à améliorer la productivité et la qualité des développements en écrivant les tests avant l’implémentation d’une fonctionnalité. Ceci permet de construire conjointement et justement le logiciel ainsi que sa suite de tests de non-régression. Le principe du TDD est le suivant: écrire un test qui échoue, écrire du code pour que le test fonctionne, remanier le code écrit, puis recommencer.

Nous vous proposons une formation de deux jours pour pratiquer le TDD, par le biais de différents ateliers de programmation.

La prochaine session aura lieu le 12 et 13 Mai. Inscrivez-vous sur notre site dédié à la formation : http://formation.octo.com/methodologie/tdd/inscription-tdd

OCTO étant un organisme de formation, ce stage peut être pris en charge par le DIF.

Programme

1ère journée

• Présentation de TDD, premier atelier de programmation collectif
• Présentation Acceptance Test Driven Developpement (ATDD), puis deuxième atelier de programmation collectif
• Bilan de cette première journée

2ème journée

• Premier atelier pour apprendre comment continuer à pratiquer TDD, même avec des frameworks complexe (type Spring et Hibernate)
• Présentation des problématiques de code « legacy », et atelier de programmation collectif pour apprendre à tester ce genre d’application. Le code étudié pourrait être le vôtre ! Contactez nous deux semaines à l’avance pour en savoir plus.
• Bilan de cette deuxième journée

Suggestion d'articles :

1. Formation TDD le 24 et 25 Octobre
2. Formation au Test Driven Developpement le 5 et 6 juillet : Apportez votre Code !
3. Formation Silverlight Tour à Paris – 22, 23 et 24 Novembre

Les méthodes agiles recommandent la colocalisation des acteurs (i.e. une localisation physique dans un même bureau) pour une meilleure communication, une meilleure collaboration et globalement une équipe ou un processus projet plus performants. Par exemple Ken Schwaber dans The Enterprise and Scrum :

« High-bandwidth communication is one of the core practices of Scrum… The best communication is face to face, with communications occurring through facial expression, body language, intonation, and words. »

Que disent les sciences de ce sujet aujourd’hui âprement discuté dans la communauté agile et ô combien toujours délicat à mettre en œuvre dans les faits ?

Ce principe de colocalisation fait débat dans la communauté agile, maintenant que les méthodes agiles, en passe de devenir « mainstream », sont déployées bien au-delà de « petites » équipes colocalisées.
Même dans le cas d’équipes « colocalisables » dans les faits, on mesure la distance de la coupe aux lèvres lorsque les organisations doivent faire le pas et que les obstacles se dressent, notamment :

• une remise en cause délicate des frontières organisationnelles dès lors que des acteurs de différents silos sont amenés à partager au quotidien un même espace de travail (ex : MOA/MOE/marketing/intégration/exploitation…);
• des demandes d’aide pour le moins fastidieuses vis-à-vis des tout puissants « services généraux » ;
• un impact sur l’ensemble des acteurs projet, au-delà de la population des développeurs, seule astreinte aux nouvelles disciplines comme le pair programming, TDD ou l’intégration continue.

Les multiples réticences à la mise en place d’équipe colocalisées ou le débat au sein de la communauté agile doivent nous inciter à étayer notre discours plus solidement que « c’est une bonne pratique agile qui est indispensable/facultative » ou « la colocalisation/non-colocalisation a bien/mal marché dans nos projets précédents ».

A cette fin, les très nombreuses études scientifiques dans ce domaine sont une source quasi jamais explorée dans les communautés agile et lean. Par exemple, la psychologie sociale, discipline hautement empirique ou des disciplines plus spécialisées comme le domaine du Computer Supported Collaborative Work (CSCW), ont accumulé depuis plus de 30 ans les expériences, études et publications sur l’efficacité de la communication et de la collaboration en fonction de la distribution physique des membres de l’équipe.

Un résultat classique : la courbe d’Allen

Thomas Allen, professeur au MIT et auteur de l’ouvrage de référence Managing the Flow of Technology en 1977, a étudié la probabilité de communication au sein d’une équipe en fonction de la distance.

Le profil de la « courbe d’Allen » est une décroissance exponentielle dont on peut extraire quelques points représentatifs :

• au-delà de 9 mètres, il y a moins d’une chance sur 10 pour que 2 acteurs communiquent une fois dans la semaine ;
• il y a deux fois plus d’échanges pour 2 acteurs séparés de 10 mètres que pour 2 acteurs séparés de 20 mètres.

Par exemple, 2 acteurs situés dans deux bureaux même proches (disons à 20 m) auront 2 fois moins d’échange que 2 acteurs à 10 m de distance sur un même plateau.

Et chez vous ?

• Quels sont vos 3 interlocuteurs privilégiés ? A quelle distance sont-ils de vous ?
• Dans vos équipes projet, quelles sont les distances entre des interlocuteurs proches dans la chaîne de valeur (par exemple : marketing=>MOA=>MOE=>intégration=>exploitation) ?

Oui mais l’email, l’instant messaging, la vidéo ?

Les moyens de communication modernes (email, IM, vidéo conférence) largement déployés depuis les premiers résultats de Allen ont-ils remis en cause l’importance de la distance ?

Pas vraiment… voire c’est tout le contraire qui apparait au fil des études puisque la probabilité d’interaction par ces nouveaux moyens de communication est corrélée à la distance. Ainsi, Allen dans son ouvrage récent (2008), The Organization and Architecture of Innovation :

« We do not keep separate sets of people, some of which we communicate in one medium and some by another. The more often we see someone face-to-face, the more likely it is that we will telephone the person or communicate in some other medium. »

Google, encore Google…

Une étude à grande échelle basée sur un marché de prédiction et menée dans les centres de Google, confirme les résultats classiques de Allen.

Un des auteurs de l’étude, Justin Wolfers, commente les résultats de l’étude :

« Sitting within a few feet of a workmate has a big effect. (Our data includes the exact GPS coordinates of each person’s desk, as well as their previous desks.)
Beyond this, sitting on the same floor as someone barely has any effect.
[…]
The overwhelming importance of “micro-geography” was quite striking, particularly as this is the sort of organization in which Instant Messaging and e-mail (plus blogs and wikis) might have otherwise suggested the death of distance. »

Eric Schmidt, CEO de Google, n’a pas attendu les résultats de cette étude pour souligner l’importance de la colocalisation. Pour preuve la 3ème règle (« Pack them in ») des Google Ten Golden Rules.

« The best way to make communication easy is to put team members within a few feet of each other. The result is that virtually everyone at Google shares an office. This way, when a programmer needs to confer with a colleague, there is immediate access: no telephone tag, no e-mail delay, no waiting for a reply. »

A cet égard, le modèle Google et sa confirmation par l’étude expérimentale éclaire d’autant plus nos propres contextes IT :

• Les employés Google ont a leur disposition tous les outils de communication technologiques possibles et imaginables (faisons l’hypothèse qu’ils savent les utiliser correctement) ;
• Le métier de Google ressemble de près ou de loin au métier de nos équipes projets (i.e. concevoir et construire vite et bien de nouveaux produits IT) ;

Effet de la distance sur la collaboration, le mensonge et la recherche de compromis

Les résultats évoqués jusqu’ici concernent la probabilité de communication en fonction de la distance. D’autres études en psychologie sociales se sont attachées à mesurer les effets de la distance sur la propension à collaborer, tromper son interlocuteur ou trouver efficacement des compromis.

Ainsi, dans l’étude Why Distance Matters :

« First, the data strongly indicates that the geographic distance between collaborating and previously unacquainted partners matters. The ability to persuade another and the willingness to initially cooperate decrease with distance while deception of another person increases with distance. »

Au passage, cette étude balaie aussi l’espoir parfois mis dans des outils technologiques plus « riches ». Ainsi, la qualité de la collaboration, la propension au mensonge et aux compromis, sont sensiblement les mêmes que les acteurs utilisent un simple « instant messaging » ou la vidéo conférence.

Conclusion

Les résultats cités dans ce post dépassent le cadre des méthodes agiles ou même du développement logiciel : tous les « jeux » collaboratifs, créatifs et innovants (notamment tous les types de « new product development ») retireront énormément de la co-localisation.

Les disciplines scientifiques comme la psychologie sociale peuvent nous fournir des résultats expérimentaux probants à la fois dans le débat au sein de la communauté agile mais surtout comme argument de poids dans la mise en place d’équipe colocalisées. Le lecteur intéressé par les détails des protocoles et des données expérimentales recueillies pourra se reporter aux études pointées tout au long du post.

Suggestion d'articles :

1. Devons-nous changer de paradigme pour le développement d’applications informatiques?
2. Espace détente
3. Et si nous définissions simplement le Cloud Computing !

Parce que XPDays est un rendez-vous phare de l’agilité en France, on se devait d’être présent pour cette quatrième édition. Le temps d’arriver tranquillement dans le Chalet de la Porte Jaune sous un joli soleil matinal, on se demande par quoi commencer dans le copieux programme de cette première journée.

Notre premier choix se porte sur l’atelier « Blanche Neige et les Sept Nains : Le miroir magique vous aide à mieux travailler en équipe » présenté par Portia Tung et Pascal Van Cauwenberghe. « Miroir miroir, dis moi pourquoi ? », c’est avec cette question que démarre l’atelier, avant que toute l’assistance ne se lance dans un « TurboNetworking » (une sorte de speed-dating orienté réseau professionnel) où chaque participant dispose de 3 minutes pour découvrir 3 choses intéressantes chez 3 personnes. Exercice, où j’ai eu l’occasion de croiser un SCRUMMaster, un praticien de Crystal et un jeune développeur agile qui a travaillé sur divers Plugin Eclipse.

Après cette introduction, Portia et Pascal nous racontent l’histoire de « Blanche Neige et les sept nains », version Tarantino, toute ressemblance avec des projets informatiques étant volontaire … En effet on apprend que Blanche Neige est une bonne équipière, travaille dur et est un petit peu naïve ; le chasseur est discipliné, pragmatique, mais mercenaire ; Prof est savant, axé sur les solutions, mais arrogant ; ou encore Timide est attentif aux besoins des autres, calme, mais n’aime pas les conflits. Chaque personnage étant donc un type de personne que vous avez sûrement déjà croisé sur un projet.

La suite du jeu consiste à se regarder dans le miroir : on tire au hasard un des personnages (pour ma part j’ai eu Timide, le Chasseur et Blanche Neige), on choisit quelqu’un qui ressemble à ces personnages (non je ne vous dirais pas qui j’ai choisi) et on donne les raisons de ces ressemblances. Ensuite on recherche ce que ces raisons nous apprennent sur nous-mêmes et quelles actions nous pouvons  tirer de ces leçons apprises.

On continue en groupe, le but est de maintenant trouver un projet et de constituer une équipe avec ses personnages. Quels vont être leur rôle, leur place dans ce projet ? Comment va-t-on pouvoir tirer parti des richesses de ses gens malgré certains traits de caractères qui les opposent ? Blanche Neige, Grincheux et Timide vont-ils constituer une équipe qui déchire grave ? On termine la session en partageant avec le reste du groupe nos projets, et nos actions individuelles, le temps de récupérer les deux dernières leçons données par Portia et Pascal :

• Dans le monde des adultes il y a MBTI (Myer-Briggs Type Indicator) et Belbin. Mais n’oublions pas que cela reste des modèles, la réalité et les dynamiques d’équipes étant plus complexes.
• On ne change pas les autres, on ne peut changer que soi-même

Après ce superbe workshop, je pars coder pendant 30 minutes dans l’atelier de développement Xtrem Miles. Objectif ambitieux puisque nous nous retrouvons avec du code que nous n’avons pas écrit, et qui n’est pas entièrement testé. Cette contrainte nous oblige a effectuer une opération d’archéologie par le biais de tests dont le but est de nous permettre de comprendre comment le code existant fonctionne.

Ensuite, je me rends à la session « XP 2.0 : Améliorer l’amélioration continue avec Lean », présentée par Régis Médina et Antoine Contal. Sujet très à la mode, le Lean Management est ici présenté avec les raisons et motivations des orateurs, à savoir pour aller plus loin que XP en terme d’amélioration continue. Cette session est l’occasion d’avoir une présentation rigoureuse du système de management de Toyota, basé sur la satisfaction des clients, la réduction des coûts en éliminant les gaspillages et le développement des collaborateurs.

On y apprend comment le projet WebTV d’Orange, développé avec SCRUM, travaille sur son amélioration continue en y installant des pratiques issues du Lean Management, notamment le Kaizen (mesure de ses performances, rendre les problèmes visibles, résoudre les problèmes et en tirer les bonnes leçons). Pour mesurer ces performances, il faut identifier son client et identifier ce qu’il veut, quand et où, et sans problème. Une fois son client identifié, Antoine nous explique comment il a corrigé certains problèmes en installant des contre-mesures, en se basant sur le cycle d’amélioration de Deming, le PDCA. Parmi les leçons tirées on note l’émergence de standards de travail, projetés sur les murs en format A3. Ayant travaillé sur le projet d’Antoine, je m’aperçois alors que mon nom apparaît sur son A3 décrivant le processus du Stand Up Meeting de l’équipe WebTV. Me voilà dans le processus … Cette session nous apporte de nombreuses pistes pour appliquer cette démarche auprès des équipes de développement, mais on aimerait voir aussi d’autres chemins pour installer le Lean sur toutes la chaine de valeur du SI, incluant aussi la production par exemple. C’est d’ailleurs l’occasion de faire un peu d’autopromotion sauvage, où le Lean à la dimension du SI (chaîne de valeur partant de l’idée d’un MOA jusqu’à la production) sera aussi abordée à l’Université du SI 2009, avec, on l’espère, autant de talent.

Après la pause déjeuner, on part voir « La Théorie des Centres, une nouvelle façon de voir la conception incrémentale des logiciels » présentée par Régis Medina. On ne vous présentera pas la Théorie des Centres de Christopher Alexander (il nous faudrait plus d’un article de blog). Le célèbre architecte et auteur de « Notes on the Synthesis of Form » nous apprend que concevoir consiste à retirer des erreurs sans en créer d’autres ; et de « A Pattern Language » et « The Oregon Experience » où de nombreuses pratiques ont été reprises par Kent Beck pour XP. Après avoir pas mal plané avec une certaine euphorie lysergique, Régis Medina nous fait redescendre en nous montrant une démonstration de refactoring de code (comment faire émerger un FormBuilder dans un formulaire SWING) en utilisant la Théorie des Centres. Exercice particulièrement intéressant, prônant pour une certaine beauté du code, dont on regrette juste qu’il ne soit pas appliqué aussi sur la conception d’IHM.

La journée se termine avec quelques conversations autour d’un verre, avant de repartir content de cette journée, et on espère que les prochaines éditions de XPDays seront toutes aussi réussies.

Suggestion d'articles :

1. Compte rendu CITCON Paris 2009
2. 1er Compte rendu du séminaire « Lean dans les services »
3. 2ème compte rendu du séminaire « Lean dans les Services »

Lors de l’inauguration du French SUG, un élément important avait été soulevé : il n’existe pas aujourd’hui de chiffres concrets sur l’utilisation des méthodes agiles en France. Luc Legardeur avait donc indiqué qu’un questionnaire était en cours de rédaction et arriverait prochainement …

Eh bien c’est désormais chose faite, le questionnaire est en ligne !!

Un mécanisme de parrainage pour gagner une wii pourra vous motiver à inciter vos connaissances à répondre à ce questionnaire. Il suffit de demander à ce que le champ parrain soit rempli avec vos noms et prénoms.

A vos claviers !

Suggestion d'articles :

1. Compte-rendu de la soirée d’inauguration du French Scrum User Group
2. Participez au Green Challenge !
3. Participez à l’Université du SI – 2 et 3 juillet 2008 à Paris

L’objet de cet article est de faire état des synergies possibles entre CMMI et les méthodes agiles, celles-là même qui ont poussé Jeff Sutherland (co-auteur de Scrum) à écrire récemment l’article « Scrum and CMMI Level5 : The Magic Potion for Code Warriors » et le SEI (Software Engineering Institute) à publier le rapport « CMMI and Agiles : Why not Embrace Both !« .

• Le point sur CMMI
• Préjugés et idées reçues
• Utilisation conjointe de CMMI et des méthodes agiles

Le point sur CMMI

Dans les années 80, le Département de la Défense des Etats-Unis demande l’élaboration d’un référentiel de critères permettant d’évaluer ses fournisseurs de logiciels : Cette tâche est confiée au SEI.

Pendant la maturation du modèle, le SEI fait deux constats. Les personnes changent d’entreprise tout au long de leur vie et les outils évoluent rapidement. Ainsi, des trois dimensions critiques pour la création de logiciels, il ne reste qu’un levier d’actions permettant de maximiser l’utilisation des ressources humaines et technologiques : Les procédures et les méthodes.

Trois dimensions critiques

C’est sur ces fondations que naît le CMM en 1991 qui deviendra en 2001 le CMMI (Capability Maturity Model + Integration). CMMI est un modèle intégrant des exemples de bonnes pratiques permettant d’appréhender, d’évaluer et d’améliorer les activités de l’entreprise d’ingénierie.

CMMI propose une échelle de mesure de maturité (c’est-à-dire de la capacité à produire des produits correspondant aux besoins exprimés avec des contraintes de budget et de temps respectées) pour les entreprises. Comme l’explique le SEI, CMMI est un modèle. Il doit être implémenté au sein de l’entreprise pour améliorer les processus. Ce n’est pas un standard et ne doit/peut pas être appliqué tel quel. En particulier, CMMI ne contient pas de processus, ni de procédures à appliquer mais des exemples de pratiques permettant d’atteindre les buts préconisés. CMMI autorise l’utilisation de pratiques alternatives pour atteindre un but mais ne les définit pas.

Synergies entre CMMI et Méthodes Agiles

Nous ne présenterons pas ici les méthodes agiles, le lecteur assidu d’Octo Talks pourra se référer aux articles décrivant ces méthodes.

Préjugés et Idées reçues

Les méthodes agiles et le CMMI partagent les mêmes objectifs qui sont bien sûr ceux de toutes les méthodes, pratiques et outils visant à produire du logiciel (satisfaction du client, respect du planning et des coûts, …). Cependant les préjugés d’une communauté contre l’autre font que les agilistes et les adeptes de CMMI s’entremêlent peu. Ces préjugés sont tout d’abord historiques, CMMI a été mis en place dans de grandes structures où le besoin de confidentialité est important tandis que les méthodes agiles ont d’abord pénétré de petites structures dans lesquelles le besoin de confidentialité est faible. Ils sont aussi lexicaux, CMMI parle de maturité et de responsabilité tandis que les méthodes agiles utilisent le vocabulaire de la souplesse et de la performance. Ces idées reçues font que les agilistes dénigrent la rigueur et la documentation jugée excessive de CMMI, tandis que la communauté CMMI n’imagine pas que l’efficacité et la flexibilité agile puissent être compatibles avec les exigences CMMI.

Utilisation conjointe de CMMI et des méthodes Agiles

Pourtant les articles décrivant l’utilisation des deux paradigmes en synergie se multiplient. De nombreux mappings entre CMMI et les méthodes agiles ont été publiés récemment [5,4]. Un résumé rapide permet de penser que SCRUM et XP intègrent respectivement les exigences du CMMI à 46% et 60%. Certaines pratiques génériques (fournir les ressources nécessaires, définir et affecter les responsabilités, identifier et impliquer les parties prenantes, conduire et maîtriser le processus, rendre compte aux dirigeants) sont déjà implémentées par SCRUM. D’autres (organiser la planification des processus, planifier le processus, construire puis gérer la documentation du processus, évaluer l’exécution du processus) ne sont pas traitées par SCRUM tout en étant compatibles. Enfin, l’implémentation de la collection d’informations d’amélioration nécessite un aménagement de SCRUM, par exemple en modifiant le déroulement du Sprint Retrospective Meeting.

Au delà des préjugés et des idées reçues, nous observons que ces méthodes sont défendues par des populations différentes. Les méthodes agiles sont portées par des personnes qui construisent des applications informatiques, du développeur au responsable MOA (bottom up), tandis que CMMI est soutenu par la hiérarchie de la DSI et ses cellules transverses (top down), souvent dans le but de fournir un point de comparaison entre les DSI. Ainsi on entendra un DSI ou un manager de cellule transverse se féliciter d’être certifié CMMI, ce n’est pas le discours d’un développeur ou d’un chef de projet. Le premier apport observé de la cohabitation entre méthodes agiles et CMMI est donc la création d’un climat apaisé entre opérationnels, managers et cellules transverses.

Ce premier bénéfice de l’utilisation conjointe de CMMI et des méthodes Agiles permet par ailleurs de comprendre l’un des « prérequis » à l’implémentation réussie de toute démarche d’amélioration: Tout le monde doit avoir décidé d’y participer.  On observe que l’agile « télécommandé depuis le haut » n’est jamais aussi efficace que l’agile dont les pratiques émergent du « bas de l’échelle ». C’est d’ailleurs l’une des « recettes » culturelles du succès de Toyota, qui possède une forme de bureaucratie « bottom up » très puissante, dans laquelle les équipes opérationnelles mettent à jour elles mêmes leur standard.

Ainsi, l’implémentation des méthodes Agiles conjointement à CMMI permettra de ne pas ignorer la correlation entre la qualité des interactions dans l’équipe et la qualité du produit, celle-ci échappant à nombre d’experts (un coach me confiait avoir géré des projets pendant 10 ans en se figurant que la qualité de l’équipe devait essentiellement au hasard des recrutements et aux bonnes manières). Il faut donc un processus pour le produit et un processus pour l’équipe, sans oublier un alignement de l’équipe sur les processus et le produit. Et pour assurer cet alignement : du leadership!

Enfin, en ce qui concerne les évaluations CMMI, elles ont pour but de valider l’implémentation des objectifs imposés, les méthodes utilisées sont à choisir. Ce choix peut être en partie celui des méthodes agiles. Celles-ci guideront l’entreprise vers une implémentation plus efficace de CMMI [2] : le CMMI impose un « Quoi ? », les méthodes agiles implémentent un « Comment ? » acceptable pour CMMI permettant souvent une amélioration de la productivité et de la qualité. En outre, une approche Lean permettra d’éviter à l’implémentation de CMMI de devenir trop bureaucratique et de produire trop de documentation, ce qui est plus souvent le fait des « implémentateurs » que de CMMI lui-même. En conséquence, cela permettra aux organisations désirant atteindre un certain niveau de maturité de mieux percevoir les apports de CMMI. Quant aux entreprises agiles, CMMI les aidera à institutionnaliser les méthodes agiles avec plus de consistance.

Références

1. « CMMI or Agile : Why Not Embrace Both » Hillel Glazer [Entinex Inc.], Jeff Dalton [Broadsword Solutions Corporation], David Anderson [David J. Anderson & Associates Inc.], Mike Konrad et Sandy Shrum [SEI]
2. « Scrum and CMMI Level 5 : The Magic Potion for Code Warriors » Jeff Sutherland [Patientkeeper Inc.], Carsten Ruseng Jakobsen [Systematic Software Engineering], Kent Johnson [AgileDigm Inc]
3. « An Approach for Using CMMI in Agile Software Development Assessments: Experiences from Three Case Studies » Minna Pikkarainen et Annukka Mäntyniemi [VTT Technical Research Centre of Finland]
4. « Mapping CMMI Project Management Process Areas to SCRUM Practices » Ana Sofia C. Marçal et Arnaldo D. Belchior [ University of Fortaleza],  Bruno Celso C. de Freitas et Felipe S. Furtado Soares [C.E.S.A.R - Recife Center of Advanced Systems and Studies]
5. « Agile Methods and CMMI: Compatibility or Conflict ? «  Martin Fritzsche et Patrick Keil [Technische Universitat Munchen]
6. « Stretching Agile to fit CMMI Level 3″ David J. Anderson [Microsoft Corporation]

Suggestion d'articles :

1. Plan Assurance Qualité et Méthodes Agiles
2. Pourquoi les méthodes agiles peinent-elles à pénétrer l’entreprise ?
3. Retour sur la première session Open Space praticiens agiles

Bonjour.

Je vous propose de nous retrouver pour une soirée des Praticiens XP le 3 Décembre (à partir de 18h30) dans les locaux d’OCTO Technology (au 5 eme étage).

Les objectifs de cette soirée sont de partager nos connaissances et nos expériences avec d’autres praticiens.

Le format utilisé pour cette soirée sera le format Open Space.

pour résumer : tout le monde peut proposer des sujets (il y aura 6 espaces donc 12 sessions) tout le monde participe aux discutions. et si une session ne vous intéresse plus momentanément ou définitivement, vous êtes invité à « voter avec vos pieds » et à aller rejoindre une autre session !

plus d’informations ici : http://www.openspaceworld.org/french/

Voici le programme de la soirée :

• 18h30 Accueil, présentation, choix des sujets.
• 19h15 1ère session
• 20h00 pause
• 20h10 2ème session
• 21h00 buffet

Les inscriptions se font sur le Wiki d’Xp France :
http://xp-france.net/cgi-bin/wiki.pl?PraticiensDeParis/Mercredi03Decembre2008

Suggestion d'articles :

1. Octo soutient : Agile Open France 2009
2. Soirée Spring au Paris JUG
3. Octo présente cinq sessions dans le cadre de la conférence Agile France

 » Encore une sale journée qui s’annonce  » pensa Bertrand, de bon matin en sirotant son café. Bertrand est directeur de projet, il gère une équipe de développement d’un grand site internet stable et rentable. Mais ses développeurs croulent sous les demandes d’évolutions et de corrections d’anomalies provenant de différentes équipes : tentation du Web 2.0 du marketing, corrections de bugs pour la relation client, Urls à reformater pour le référencement Google, sans oublier ses satanés bugs qui proviennent en masse et de façon aléatoire. C’était trop ! Tout était urgent, développé à l’arraché, et mis en production aux forceps.  » Comment améliorer ce bazar ?  » se demanda Bertrand, tout en prenant un sachet de sucre.


Bertrand pensa alors à Marc. Son projet avait un objectif clair : Remonter les chiffres de fréquentation du site. Marc avait demandé à un ScrumMaster d’apporter des notions d’agilité à son équipe. L’équipe au complet avait demandé plus de communication entre les acteurs, des coups de main pour les tests (leur application était elle aussi bourrée de code existant méconnu et vérolé), et de délivrer régulièrement.

En quelques mois, l’équipe avait appliqué différents patterns issus de SCRUM et XP : itérations de deux semaines, un backlog mis à jour régulièrement, des réunions de planification, des rétrospectives, des stand-up meetings, des tests fonctionnels, des tests unitaires, des informations sur l’état d’avancement du projet affichées sur les murs avec des post-its, les développeurs binômes et sont investis collectivement de l’architecture et du design. Et le meilleur dans tout ça était que chaque release tenait la date.  » Bon sang, c’est le jour et la nuit avec moi, c’est ça qu’il me faudrait pour que ça marche sur mon projet ! » pensa Bertrand, quand il eut finit de mélanger son sucre dans son café avec sa touillette.

Mais soudain, Bertrand se remémora le site internet d’Antoine : Même profil pour les développeurs ; le même ScrumMaster était venu, et effectivement l’équipe s’était réappropriée les mêmes pratiques agiles. Mais ce projet n’avait pas d’objectif clair : Les différentes personnes de l’équipes n’étaient pas alignés sur ce qu’il fallait faire de ce site internet. Résultat : Le projet n’avance pas, l’équipe se démoralise progressivement, et les travers que rencontrait Bertrand se retrouvaient sur le projet d’Antoine.

 » Alors la différence entre les deux tenait seulement sur un alignement d’objectif ?  » se demanda Bertrand, tout en buvant sa dernière gorgée de café. Ca sonne comme du bon sens, mais lorsqu’il quitta la cafétéria, Bertrand commença à se demander quel pouvait être le but de son produit ? Il se dit alors qu’il était temps de voir toute son équipe pour commencer à parler d’un objectif commun …

Suggestion d'articles :

1. L’agilité et vous : participez à l’enquête du French SUG
2. Ce que la science nous dit de la colocalisation

Goldratt nous invite à poser trois questions face à une technologie :

Quelle est sa force, qu’apporte-t-elle de nouveau ?
Pour une entreprise qui souhaite la mettre en place, quelle limitation de ses performances permet-elle de diminuer ?
Quelles sont les règles, tacites ou explicites, qui permettent à cette entreprise de vivre avec cette limitation ?

Je choisis comme sujet une méthode de développement agile, disons XP.

1) Quelle est sa force, qu’apporte-t’elle de nouveau ?

Elle maximise l’usage des boucles de feedback dans le processus de création de logiciel, en offrant la possibilité de livrer régulièrement et sans régression un système correspondant aux besoins actuels, et dont la connaissance est partagée par toute l’équipe.

2) Pour une entreprise qui souhaite la mettre en place, quelle limitation de ses performances permet-elle de diminuer ?

Elle diminue le niveau d’entropie d’une équipe appliquée à résoudre un problème complexe.

Cette entropie se manifeste sous trois aspects :

2.1) Perte d’information et/ou bruit : Dans son travail de résolution du problème, l’équipe oublie ou néglige des informations vitales concernant le problème, se désaligne (visions divergentes du problème) et perd en cohérence. Exemple: « Ce n’est pas un bug ! C’est une demande d’évolution par rapport à la spécification ».

2.2) Ralentissement : Lorsque les données du problème changent, le temps de réadaptation de l’équipe (et de son produit) devient un facteur limitant particulièrement pénalisant. Exemple : « Ils ont d’abord dit que ce serait une application, maintenant ils veulent du web service. Il nous faudrait 6 mois. Ca va pas le faire. »

2.3) Cristallisation : L’entropie se matérialise dans les artefacts du projet sous forme de « dette technique » : code sans tests, redondant, illisible, technologie inadaptée ou obsolète, design trop complexe, etc. L’incapacité de l’équipe à résorber cette dette technique ralentit le processus de résolution du problème, parfois jusqu’à l’arrêt complet. Exemple : « Il n’y a plus personne ici qui comprend ce que fait ce code. »

3) Quelles sont les règles, tacites ou explicites, qui permettent à cette entreprise de vivre avec cette limitation ?

Ce sont habituellement des règles qui visent à diminuer l’entropie du système en le contraignant de manière à conserver ou rétablir l’information, quitte à le ralentir et à le refroidir encore plus. Voici les règles le plus souvent constatées dans mon expérience :

3.1) Fixer à l’avance et contractualiser le périmètre fonctionnel, l’effort à engager ainsi que les délais et tenter de se tenir à ces décisions coûte que coûte. Exemple : « Toute demande d’évolution émise après la validation du document de Spécifications Fonctionnelles Détaillées fera l’objet d’un avenant; sa mise en oeuvre devra faire l’objet d’une nouvelle estimation après réception du Système Principal « .

3.2) Produire une documentation exhaustive pour chaque artefact afin de limiter les pertes d’informations ou de tracer les décisions. Exemple : « La conception détaillée devra être entièrement documentée au format UML (diagramme de classe et de séquence) afin de faciliter la prise de connaissance du projet par l’équipe de maintenance. »

3.3) Capturer le processus de décision du groupe dans une structure hiérarchique visant à limiter les risques d’erreurs. Exemple : « Le projet est en retard. A partir de maintenant, je serai présent au comité de suivi hebdo, et je veux un rapport de statut par jour. Je souhaite également que tous les congés fassent l’objet d’une demande écrite avec copie DUPANLON et ROBERT. »

3.4) Spécialiser les tâches afin de faire reposer l’intégrité du produit sur l’intégrité de quelques individus plutôt que de l’équipe. Exemple : « On a Bert comme DBA à l’intégration, et en plus il s’entend assez bien avec Gus (qui est un crack du java) alors je pense qu’on ne devrait pas avoir trop de problèmes de modèles. C’est l’essentiel, le modèle ! »

Conclusion

Que peut on tirer de ces réponses quand à l’adoption d’une méthode comme XP dans l’entreprise ? Personnellement, elles m’ont permis de mieux comprendre pourquoi la mise en place d’XP dans un contexte où ces règles existantes sont maintenues se traduit par un abandon de la méthode, jugée non rentable.

La conclusion que je tire de cette compréhension est que pour réussir avec XP, une entreprise doit non seulement identifier et expliciter les limitations qu’elle rencontre sur ses projets, mais également les règles qu’elle a mis en place au cours du temps afin d’y pallier, quitte pour cela à créer des conflits :

- Mais avec cette méthode il faudrait travailler tous dans le même bureau !
- Eh bien, pourquoi pas ?

Suggestion d'articles :

1. Trois cas d’usage des fermetures
2. XDepend : 3 questions à Marc Cherfi