Programme 2008

Développer des applications d'entreprise est très difficile même avec des outils efficaces. Spring est apparu fin 2002 pour répondre à la complexité et la lourdeur des applications J2EE.



Aujourd'hui, le framework Spring est un incontournable dans le développement d'applications Web car il met en avant les bonnes pratiques de développement (Injection de dépendances) et permet de gérer des appels transactionnels de manière non-intrusive. Spring vient avec un module de test, Spring Test (ex Spring Mock), qui permet de tester simplement de manière unitaire les différentes couches applicatives d'une application web. Cette session propose de montrer comment il est possible de développer une application web J2ee en TDD.

Le fameux XP Game: un atelier ludique et percutant pour découvrir les bases de la planification en Extreme Programming.

(A venir)

Les SSII sont le quotidien de bon nombre d'entre nous. L'eveil à l'agilité s'accompagne souvent d'un autre regard porté à son entreprise, la simple frustration peut alors devenir un cahier de doléances bien rempli. Pourquoi les SSII ont par nature des comportements non agiles ? Qu'est-ce qui peut faire qu'une SSII évolue ? Qu'est ce qui peut éventuellement caractériser une SSII agile ? Qu'est-ce que nous pouvons faire ? Au travers un retour d'expérience de 4 ans au sein de la SSII Hortis et à l'aide des retours d'expériences des participants, l'objectif est de partager des clefs de compréhension et d'action pour concilier l'inconciliable.

Il s'agit du fruit de recherches personnelles sur l'utilisation de principes de conception des interfaces homme-machine pour rendre le code plus facile à appréhender, donc plus agile. En termes XP, il s'agit de guider l'activité de refactoring pour accélérer les tâches de développement.

La peur du conflit est un frein puissant à la remise en question - et donc à l'amélioration - du fonctionnement d'une équipe. Au mieux, une équipe qui craint le conflit stagnera dans le conformisme. Au pire, elle se consumera sous l'effet des tensions intériorisées.

Pourtant, le conflit n'est pas mal en soi. C'est un moyen de dénouer des divergences naturelles porteuses d'innovation. Ce qui rend le conflit si effrayant, c'est le déchaînement d'émotions incontrôlées qui nous font perdre nos moyens et obtenir des résultats médiocres.



Nous pouvons faire mieux que cela.



Dans le livre "Aikido in everyday life", Terry Dobson et Victor Miller explorent la forte ressemblance qui existe entre le conflit verbal, celui dont nous parlons ici, et le conflit physique étudié de manière systématique depuis plusieurs centaines d'années dans le monde des arts martiaux.



En effet, pour le conflit verbal comme pour le combat :


1. il existe des techniques

2. on peut s'entrainer, s'améliorer, et devenir bien meilleur avec le temps

3. le but n'est pas nécessairement de détruire l'adversaire



Dans cette session, nous partons de cette analogie, nous l'enrichissons d'outils et de modèles issus d'autres auteurs (Weinberg, The Arbinger Institute, etc.), et nous y mêlons notre propre expérience pour proposer une démarche à utiliser en situation de conflit. Le parallèle avec le combat rend cette démarche très visuelle, facile à retenir et à communiquer.

Nous illustrons cette démarche de manière vivante, à travers des saynètes de travail en binômes plus vraies que nature qui ne manqueront pas de vous rappeler des choses !

L'objectif de cette présentation est de montrer que l'intégration continue est une pratique XP simple à mettre en place sur les projets, y compris ceux qui n'appliquent pas encore XP. Elle abordera son positionnement par rapport aux autres pratiques XP, les exigences sur l'industrialisation d'un projet et sur les habitudes de programmation.

Une démonstration sera effectuée avec l'outil Hudson.

Erlang est un langage agile, simplifant le développement en général, le TDD en particulier, et jusqu'aux livraisons fréquentes grâce aux capacités de mise à jour à chaud. Ce laboratoire permet de découvrir Erlang par la pratique.

Cela fait maintenant plus de six ans que j’ai découvert XP, et j’ai depuis eu de nombreuses occasions d’en parler autour de moi, que ce soit avec des collègues, des amis ou des recruteurs. Selon le profil des personnes (développeurs, testeurs, managers ou ressources humaines) la vision qu’ils ont d’XP et de l’agilité est différente, mais au sein d’un groupe on retrouve bien souvent les mêmes idées reçues qui sont malheureusement autant de freins à l’adoption. Cette session aura pour but de reprendre les plus répandues afin de les analyser pour voir si elles sont vraies, fausses ou s’il faut nuancer le propos.

Un format typique pour écrire des User Stories est "Comme un <rôle> je veux <quelque chose> pour <atteindre un but>". Est-ce que vous avez des difficultés à trouver les rôles, quelque choses et buts? Est-ce qu'il vous est déjà arrivé qu'un client vous demande d'implémenter une solution pour se rendre compte qu'il a bien recu ce qu'il a demandé, mais pas ce dont il avait besoin? Est-ce que vous voulez mieux comprendre vos clients et vos utilisateurs? Est-ce que vous voulez découvrir les vrais problèmes?

La technique de dialogue '9 boxes' du Solution Selling vous donne une structure pour interviewer des utilisateurs et clients. Cette technique vous permet de bien comprendre le problème du client et qui est impacté comment par ce problème. Pendant l'interview on crée une vision commune, avec le client, du monde après que ce problème soit résolu. A la fin d'un tel interview votre client est enthousiaste pour participer au projet.



Après une interview '9 boxes' vous avez tout pour écrire les user stories qui résoudent vraiment le problème du client.



Apprenez cette technique simple mais efficace à travers un jeu.

Notre constat est simple: nous supposons que les projets échouent non pour des raisons techniques, mais en raison de problèmes de communication. Nous démontrerons quelques-uns de ces problèmes de communication à travers divers jeux et simulations.

Les Real Options nous aident à prendre des decisions difficiles dans nos projets et dans la vie de tous les jours. Les options nous permettent de prendre plus souvent la bonne décision, au bon moment.



Les real options expliquent pourquoi les méthodes Lean et Agiles marchent. Ils expliquent pourquoi le Just-In-Time, les User Stories, la planification avec des iterations courtes, etc... apportent de meilleurs résultats. Les Real Options expliquent pourquoi ces techniques qui vont contre le bon sens et qui font peur, rapportent gros.



Venez découvrir cet outil remarquable à travers le jeu d'aventure dans l'espace "Real Options: l'Ultime Frontière". Apprenez à appliquer les Real Options pour prendre de meilleures decisions. Apprenez à expliquer l'agilité dans le langage des dirigeants de vos sociétés.



Après cette session, vous verrez toutes vos decisions d'une facon différente!

Un atelier interactif pour mieux comprendre les mécanismes de "l'auto-organisation", censé être le principe de fonctionnement des équipes XP: est-ce réaliste ? Comment y arriver ? Que faut-il en attendre ?

Le Toyota Production System comporte trois fondamentaux : satisfaire pleinement le client et réduire les coûts via le développement des collaborateurs. Cette synthèse structure toute la démarche Lean et l’idée de l’atelier est de proposer aux participants d’obtenir une expérience personnelle de l’amélioration Lean via une simulation.

Par la force des choses, tous les sujets proposés ou espérés ne pourront être présentés à XP Day. Certains sont trop spécialisés, d'autres trop éloignés des besoins de la majorité des participants pour occuper 60, 90 ou 180 minutes. La plupart des conférences agiles proposent donc des formats comme les forums ouverts ("open space") ou les sujets éclair ("lightning talks") pour traiter de sujets dictés par les besoins des participants au moment même de la conférence, en fonction de leurs passions du jour.



Le principe est le suivant: dans une première phase d'organisation, les participants décident, parmi des sujets proposés préalablement ou d'autres qui peuvent être proposés au moment de la session, ce dont ils voudraient entendre parler. Chaque orateur a ensuite 10 minutes montre en main pour s'exprimer !

Depuis des décennies les sociologues constatent invariablement la perte des valeurs humaines en partie dû à la dissociation du tryptique « Politique – Culture – économie ». La révolution de l’agilité apparaît non seulement comme un bienfait sur la productivité des équipes mais elle tend également à réintroduire ces valeurs en voie de disparition au sein de l’entreprise. On peut se poser légitimement la question : L’agilité pourrait-elle être une référence pour faire évoluer notre société ?



Ainsi, à travers cet exposé, pour envisager sortir un jour de ce monde de plus en plus contractuel et possédant de moins en moins de valeur, je vous propose de nous arrêter quelques instants sur les modifications sociales et psychologiques introduites par les méthodes agiles. Je vous présente les modifications à attendre pour les entreprises lorsqu’elles se transforment en organisation agile et jusqu’où il faudra aller pour rééquilibrer ce système « Société » divergeant ? Et même si toutes les réponses ne pourront être données lors de cet exposé, quelques idées maîtresses pourront être illustrées avec de récentes découvertes sur les aspects cognitifs.

L'objectif de cette présentation est d'illustrer les grands principes du "Behaviour Driven Development" (BDD) à travers d'exemples écrits en Ruby.

* Analyse des outils et méthodes à l'origine du BDD; nous évoquerons la multitude de frameworks (java, ruby, js, ...) apparus ces dernier temps.

* Spécification du comportement d'une classe Ruby avec le framework RSpec; du TDD avec en prime la documentation qui s'écrit toute seule!

* Un exemple de tests d'acceptation d'utilisateur d'une application web avec RSpec et selenium, en utilisant le format de "Story" de Dan North

Plus de détails: la mindmap de la présentation

Drame dans une équipe de développement. Deux développeurs expérimentés discutent violemment quelle solution de conception satisfera mieux les demandes client auxquelles ils font face. Trois autres développeurs, un peu dépassés, réfléchissent à qui donner raison. L'un d'entre eux se dit que c'est peut-être politiquement le bon moment pour suggérer de tout réécrire, dans un langage de programmation qu'il affectionne particulièrement. Le chef d'équipe intervient et tranche brutalement, donnant une orientation qui ne satisfait personne, "parce qu'il faut bien avancer".



Le travail en groupe est souvent le théâtre de négociations de territoire -- compromis avec les autres, compromis avec soi-même. "Suis-je au niveau ? Ai-je ma place ? Comment contribuer ? Vais-je parvenir à imposer ma vision ?" se dit-on. Pour peu que plusieurs membres du groupe soient dans un tel schéma de pensée, on assiste rapidement à un déluge d'informations, contradictoires, non exploitées par manque de temps, chacun attendant le moment où il pourra placer "sa" contribution, sans écouter celle des autres. Paradoxe : ce n'est pas parce qu'on sait (ou qu'on pense savoir) ce que le groupe cherche que le dire va l'aider dans sa quête.

En tant que membres de divers groupes -- professionnels, familiaux, etc. -- nous pouvons faire mieux.



Cet atelier propose d'explorer une alternative à la "poussée d'information" : chercher chez les autres, avec un esprit curieux, les histoires et les idées qu'ils peuvent avoir, et les combiner avec celles qui ont déjà été formulées. Cette écoute attentive et bienveillante, cette investigation sans jugement, aide à mieux saisir les opportunité d'intégrer les idées qui nous entourent et à satisfaire efficacement les attentes du groupe tout entier.



Nous expérimenterons l'utilisation de plusieurs outils (Soft Focus de Tadashii Suzuki, approche émique de Marvin Harris, Investigate de Jim & Michele McCarthy) qui aident à prendre cette posture d'écoute. Nous discuterons ensemble des découvertes que nous aurons faites.

Les méthodes agiles sont de plus en plus utilisées au sein de tous types d'organisations pour les équipes de développement internes. Cela est beaucoup moins vrai pour les développements sous-traités. Le premier obstacle, et peut-être le principal, est l'impossibilité par nature de contractualiser un projet en méthodes agiles pour un coût fixe. Quelles alternatives à la pure régie peut-on proposer à nos acheteurs ? Comment rendre compatible un projet agile avec un appel d'offre public ? Doit-on choisir un sous-traitant uniquement sur des critères de prix ? Voici autant de questions auxquelles nous tenterons de trouver une réponse.

La présentation retrace l'origine et l'historique des méthodes agiles. En allant chercher des travaux bien loin de ces courants de pensée que l'on imaginait, l'exposé dévoile l'incontournable apparition de ces méthodes face à une réalité non préparée à les accueillir. L'exposé ne manquera pas de vous surprendre avec des points de convergence dont tout semblait provenir d'une simple concaténation de bonnes pratiques ou le fruit d'esprits créatifs et pragmatiques mais qui en réalité pourraient bien être basées sur des concepts bien plus complexes.

Monteriez-vous dans un avion dont les logiciels de vol sont écrits par des praticiens de l'eXtreme-Progamming?

L'objectif de ce retour d'expérience est de présenter comment nous avons procédé pour introduire le développement Agile dans un contexte industriel à priori peu réceptif à ces pratiques. En effet, ce secteur est caractérisé par de nombreuses contraintes:


* technologie temps-réel embarqué;

* logiciel critique certifié pour vol;

* peu de développeurs disponibles;

* grande organisation;

* sous-traitance;

* développement multi-site;

* cadre CMMi niveau 3;

* tradition du cycle en V;

* culturellement, le savoir-faire logiciel n'est pas stratégique



La présentation évoquera la progression vers l'Agilité, les obstacles surmontés et ceux qui résistent.

Le paradigme de la programmation fonctionnelle - tout est fonction - est historiquement le plus ancien modèle de programmation. Il a connu son heure de gloire dans les années 60-70 avec la famille de langages Lisp et Scheme et les promesses de l'intelligence artificielle, au point que certains ont envisagé de construire des machines Lisp.

Après une longue éclipse, pendant laquelle ces langages, devenus les jouets favoris des universitaires et théoriciens, ont éclos en une multitude de dialectes, une nouvelle génération connaît un renouveau - limité certes, mais perceptible - de popularité. Haskell, OCaml, Scala, Erlang: ces noms sont désormais connus au-delà des symposiums académiques.



Depuis longtemps fasciné par l'expressivité de ces langages, nous cherchons à comprendre comment articuler les pratiques XP - TDD, Binômage, remaniement du code, itérations - et le paradigme fonctionnel; à identifier les points faibles et forts de ces langages par rapport au paradigme dominant - l'objet - dans le cadre de processus de développement agiles; à convaincre le plus grand nombre, enfin, de la pertinence de modifier nos modes de pensée dans le sens où ces langages nous y invitent.



Cette session pratique met en parallèle les deux paradigmes au travers du développement - dirigé par les tests - de deux solutions, fonctionnellement identiques (ie. répondant aux mêmes tests de recette).



L'accent sera mis sur l'identification de motifs de conception fonctionnels: fonctions d'ordre supérieur, types abstraits de données, pliage/dépliage de structures, monades...

Les spécifications dirigées par les tests, ou Test-Driven Requirements (TDR), représentent l’étape ultime dans l’adoption d’un processus de développement dit « lean ». La présentation se propose de dresser un état de l’art du Test-Driven Requirements après avoir parcouru ses principes fondateurs que sont le Lean Software Development et le Test-Driven Development. Je détaillerai différentes pratiques de TDR, telles que l’écriture de spécifications "exécutables", la génération de tests basée sur l’interprétation de modèles, ou l'utilisation d'un DSTL (Domain Specific Testing Language). Les impacts sur l’organisation et la redistribution des rôles seront également mis en lumière. Cette présentation a eu un vif succès aux derniers Valtech Days (10/07). Je propose de dérouler une version mise à jour.

Un test unitaire doit tester uniquement la classe et méthode visée, en isolation complète, et doit s'exécuter très rapidement. Il est donc nécessaire de bouchonner tous les appels à des classes et services extérieurs. Les librairies de Mock telles que JMock ou EasyMock? facilitent grandement cette tâche. Elles sont également recommandées dans le cadre du Test Driven Development.



Comment les utiliser efficacement? Pourquoi l'utilisation de Spring sur un projet facilite ensuite grandement la tâche de mocking? Qu'apporte le framework Unitils en tant que surcouche à ces différentes librairies? Qu'apportent-t-elles au TDD?

Certains contextes peuvent rendre l'adoption des méthodes agiles particulièrement délicates : ce retour d'expérience présentera les écueils rencontrés lors de la mise en place de Scrum au sein d'une (très) petite équipe (2-3 développeurs) travaillant sur plusieurs projets concurrents. En outre, elle s'efforcera de démontrer que le langage PHP, malgré une mauvaise réputation, peut dans les mains de développeurs consciencieux être un outil très efficace.

En Extreme Programming "user stories" sont le point focal du projet: tout à la fois cahier des charges, élément de planification, point de départ des tests automatisés... Ce qui se résume en "règle des 3 C": Carte, Confirmation, Conversation. Comment, justement, aborder efficacement cette Conversation avec le client dont le projet dépend ? La suite de l'atelier "Dites-moi, Mr le Client", très apprécié lors de XP Day 2007, fournit de nouvelles pratiques utiles et l'opportunité de les mettre en application.

Devenez participant d'un projet Extreme pendant une journée !

Objectif: s'éclater en codant un truc de dingue tout en mettant en pratique XP; vivre une expérience de collaboration avec des membres de la communauté.



Des itérations calées sur la durée des autres sessions. Cela permet aux participants de rentrer-sortir aux rythmes de la conférence. A l'intérieur des itérations on fait le planning game, on vit les pratiques de dévelopement XP, une rétro à chaque fin de session, etc.

Qu'attendez-vous d'un leader ? Qu'il s'efface ? Qu'il vous prenne par la main ? Qu'il soit le garant de "l'esprit d'équipe" ? Cette simulation nous permettra d'explorer ensemble ces questions et d'y apporter des réponses concrètes. Nous y verrons quelle influence le style d'un leader peut avoir sur les résultats obtenus, le rôle que jouent les orientations personnelles et la dynamique des groupes, et expliquerons quels modèles permettent d'anticiper ces influences pour mieux les maîtriser.