XP Days 2008 : Jeu du Leadership

Session animée par Yves Hanoulle de PairCoaching

Un workshop de 3 heures avec trois mises en situation de groupe avec un chef, sans chef et avec un coach.

Le tour de salle était intéressant: chacun devant se présenter par ses différences bien que personne ne se connaisse.

Au cours de tous ces workshops, je me fais souvent la réflexion que l'on a, en tant que groupe, à chaque fois la capacité de s'auto analyser et les ressources nécessaires pour s'améliorer avec l'aide d'outils simples comme la rétrospective par exemple.

Cependant il faut savoir faire face à ses faiblesses ou ses erreurs et à chercher à s'améliorer. Ce qui marche bien dans un groupe ou il n'y a pas d'enjeux est plus difficile dans notre réalité professionnelle: car il faut du courage et savoir respecter les autres, des valeurs fortes de l'agilité.

C'est en particulier l'un des enjeux du leader qui doit s'occuper de tous, leur donner la parole. Mais s'il doit être directif sur le processus, il ne doit pas intervenir sur le contenu.

Autre chose assez systématique est l'émergence rapide de leaders dans des groupes auto gérés ou lorsque le chef n'a pas su s'imposer au groupe. Et conclusion connexe, ces leaders peuvent être différents entre une situation de réflexion/conception et une situation de réalisation.

Pour lire le support de cette session, c'est ici et les photos (avec les légos) sont là.

Mise à jour 26/06/08:

Le jeu du Leadership est maintenant téléchargeable ici.

XP Days 2008: TDR

Session animée par Gilles Mantel de Valtech sur le Test Driven Requirements

Pour ceux qui n'ont pas pu assister à cette session, on peut retrouver la première partie de la présentation ici et la source de la seconde partie par Jennitta Andrea ici.
Après cette présentation, On peut s'intéresser au Behaviour Driven Developement
et, entre autre, à une implémentation .Net NSpec.

Le manager agile

"vers un nouveau management pour affronter la turbulence" Ce livre tente de répondre aux questions: Pourquoi l'agilité? Qu'est-ce qu'une entreprise agile? Comment faire un diagnostique d'agilité? J'attendais beaucoup de cette lecture, surtout après la séance de réflexion sur un sujet très proche aux XP days: SSII & Agilité, qui finalement a porté sur notre vision de l'entreprise agile. Mais la lecture de ce livre est sans trop de surprise lorsque l'on est sensibilisé à l'agilité: On retrouve une vision par valeur, principes et pratiques mais avec une portée entreprise et axé management; Et non dédié à l'ingénierie logicielle, ce qui m'a un peu dérouté car il n'y a pas d'écho avec le Lean Software Development pourtant orienté stratégie d'entreprise. Je suis également resté sur ma faim concernant leur outils de diagnostique d'agilité: l'auteur donne le principe de la méthode, les critères avec suffisamment de détails pour s'y intéresser mais pas suffisamment pour l'utiliser. Contrairement à la présentation du livre "cas concrets, exemples et ratios confèrent un aspect très opérationnel à cet ouvrage", ce n'est pas très opérationnel, même si ça reste instructif.

XP Days 2008 : Les neuf cases

Les neuf cases pour bien comprendre son client

session animée par Portia, Bernard et pascal (lire son compte rendu)

Comme je l'avais écrit dans la rétrospective, il y avait beaucoup de sessions sur la communication, l'échange; Celle-ci en fait partie car c'est une technique de dialogue '9 boxes' du solution Selling pour interviewer un client.

L'application directe pour l'agilité est l'écriture des user stories:
On a tous connu un client qui exprime son besoin en terme de solution et qui découvre finalement une implémentation qui ne répond pas à son besoin.

Cette technique permet d'obtenir le besoin réel du client et de l'aider à avoir la vision de la solution réalisable. La technique s'appuie sur des questions ouvertes (son histoire), de contrôles (factualisation de l'histoire) et de confirmation (reformulation).
Il y a 9 étapes à passer avant de pouvoir conclure: le jeu de rôles de la session a montré que c'est plutot difficile d'y arriver dans les temps.
En tout cas, encore bravo à l'équipe pour avoir su animer le jeu dans une salle bondée en cette fin de première journée (et non pascal, nous ne sommes pas venu que pour les chocolats...)

On peut se servir du modèle des "5 Why" de Toyota pour connaitre les causes profondes d'un problème. On peut lire à ce titre la note du très bon blog de QualityStreet à ce sujet.

XP Days 2008 : Laboratoire Extreme Programming

Le labo XP

Atelier animé par Pyxis d'un projet XP Java

Les itérations étant calées sur le rythme des sessions de la conférence, on pouvait entrer dans le projet à n'importe quelle moment de la journée. Les itérations duraient 1h30 avec 3 sprints complets.

J'étais excité à l'idée de participer à cet atelier car je me demandais comment être acteur sur un projet, une techno et avec des gens que l'on ne connait pas sur une durée si courte. Et pour tout dire, je pensais plutôt être spectateur.

Ce sont des conditions idéales pour voir toute la puissance d'XP/Scrum à l'oeuvre, mais je pense que l'équipe de Pyxis y est également pour beaucoup car ils ont de grands talents d'animateurs (déjà vus aux Techdays sur greenpepper), donc merci à eux.

Je passe sur la mise en oeuvre des différentes pratiques pour aller directement à la conclusion: En 1h30, je suis rentré dans le projet, fait un spike, du pair programming, du TDD, intégré tout ça pour livrer un item qui marchait!

Le lendemain, embarquée par la dynamique de la première journée, l'équipe de Pyxis a remis ça et commencé par dédier la première itération à une séance de refactoring, rendue possible par l'ensemble des tests que les membres du projet avaient écrits.

C'est vraiment une belle expérience, complémentaire à un XP Game.

Refactoring Improving the Design of Existing Code

Il est certain que ce livre est une référence sur la pratique du remaniement (Refactoring): L'étude est exhaustive, les patterns de refactoring sont très clairs, les exemples aussi, en java. Au-delà d'un catalogue de pattern et des cas de refactoring, Martin Fowler nous donne une position de compromis entre une conception amont et une conception emergente: la conception réaliste en amont, pouvant être remaniée pendant le développement. Mais bon, ce livre est aussi passionnant qu'un livre de cuisine: lire un pattern me fait saliver les papilles synaptiques autant qu'une bonne recette, mais lire tout le livre est un peu rébarbatif... Pendant la lecture, je me suis fait la réflexion que le remaniement est finalement très analytique: on recherche les invariants (duplication de code par exemple "Once and Only once") d'un système puis on suit la méthodologie pour remanier le code. D'ailleurs, une partie de ces patterns est implémentée dans nos IDE. Qu'est-ce qui fait qu'une pratique analytique (et répandue hors de la communauté agile) devient une pratique agile? Et d'abord qu'est-ce qu'une pratique agile (je n'ai pas trouvé de définition, donc je me lance)? "Une pratique agile applique concrêtement des principes spécifiques au métier (le développement logiciel pour XP) en regard des valeurs de l'agilité" (j'ai bon?) A ce titre le refactoring répond aux critères puisqu'il applique les principes d'amélioration (improvement), des petits pas (baby steps), des similitudes (self-similarity), de qualité... Cette pratique est facilitée par une démarche XP grâce à la pratique des tests d'abord (test-first programming) et permet la conception incrémentale (incrementale design). De même, le remaniement est indispensable au TDD pour garder son code de tests utilisable. Et enfin, toujours dans un contexte XP, ce qui rend cette pratique extreme est que le remaniement doit être permanent. On peut lire sur le site de vanderburg une analyse de dépendances des pratiques XP. Donc cette pratique, bien que plutôt analytique, prend une dimension agile si on la considère d'un point de vue systémique (c'est à dire dans sa dynamique avec d'autres pratiques) dans un contexte XP.

XP Days 2008 - XP Game

Session présentée par Olivier Lafontan

Au départ, ce jeu a été mis au point par Pascal pour expliquer simplement un projet XP:
En 3 heures, les équipes déroulent 3 itérations de 3' après avoir été tour à tour développeurs et clients. Pas de code pour ce jeu mais des ballons, des cartes et des pliages.
Chaque user story est associée à une valeur business et l'équipe qui produit la plus forte valeur business en euro gagne le jeu. Chaque itération commence par une phase d'estimation puis de planning, de réalisation, de livraison et enfin de rétrospective.

C'est assez rapide, la vélocité est calculée en dizaines de seconde. Un des gimmick XP

"If you're going to fail, fail fast"

prend ici to son sens!

Le but est de sentir la dynamique d'un projet XP, comprendre les enjeux de l'estimation et de la planification, des tests d'acceptation, comment passer de la vélocité en seconde à une unité de compléxité propre à l'équipe.

Olivier a fait une analogie très parlante du TDD, de l'intégration continue avec de simples ballons.



Pour avoir plus d'informations sur le jeu, vous pouvez lire ici la description ou bien télécharger les documents ici.


Pour lire une autre rétrospective de cette session par Pascal de Nayima.

XP Days 2008 - Rétrospective

Avant de commencer à rentrer dans le détail des sessions des XP Days, un petite rétrospective:

Bien organisés, nous étions 170 pendant deux jours. L'interêt d'une communauté francophone (France, Belgique, Québec, Suisse romande, ...) émergente est son ouverture, pourtant on y rencontre des références de l'agilité et des gens intéressants. Finalement peu de présentations (en tout cas pour les sessions que j'ai suivi) mais beaucoup d'ateliers , jeux de rôles, labo. Il y était beaucoup question de communication, de compréhension, de collaboration.

Mais, les sessions en parallèle, c'est toujours aussi frustrant...

Je suis un peu passé à côté de la session sur les real options, mais je reviendrais dessus.

Mes actions:

• Blogger sur les sessions
• Adhésion à XP France et sa ML
• Aller voir le site de pascal van cauwenberghe
• Faire un post sur la métaphore de la course au large suite à une discussion que j'ai eu un midi
• Digérer tout ce que j'ai vu

Test-Driven Development: By Example

Ce livre est complémentaire au dernier livre que j'ai lu, mais devrait être lu en premier. Un livre par l'exemple que l'on suit de bout en bout. On regarde Kent beck par dessus l'épaule faire du beau travail... Il met bien en évidence l'interêt des métaphores, la manière d'avoir une interface (API) et un design émergents. Kent montre également la souplesse qu'il faut savoir garder dans la mise en pratique du TDD. Les exemples de la première partie du livre sont en Java, la seconde en Python pour xUnit, ce qui ne facilite pas la lecture du livre. Et la troisième partie est constituée de patterns pour le TDD, les patterns de refactoring associés au TDD. Si Kent est très radical sur les tests unitaires, il n'aborde pas les tests sur les IHM, les bases de données. Ce livre est écrit avec pas mal d'humour ce qui aide à le parcourir. Pour finir on peut retenir que TDD est l'opposé de ce que l'on apprenait "Code for today, design for tomorrow" mais bien "Code for tomorrow, design for today"