Cet article n’est pas comme l’autre… Pas le temps en ce moment d’écrire une grosse réflexion sur tout ce que j’ai pu entendre à Valence. En plus, ça commence à faire longtemps !
D’une manière générale, on a encore appris plein de choses en ce jour du 23 octobre. Et surtout j’ai adoré l’organisation au top (avec un ManuChenu en pleine forme !) qui a rendu l’après midi très efficace, sans temps mort, et surtout sans un seul blabla inutile. (un prochain article parlera des Microsoft Days, c’était pas pareil)
Bon, voilà simplement ce qu’il y avait écrit sur mon petit bloc notes agiletour… A savoir : les trucs qui m’ont interpellée, les sujets à creuser, et les trucs qu’il faudrait qu’on fasse.
Spécifieurs et artistes
Je n’ai rien noté car c’était un atelier. Ce que j’en retiens c’est que la communication entre les spécifieurs et les développeurs (j’ai beaucoup aimé le parallèle avec “artistes” d’ailleurs) est très difficile dans la plupart des cas, et que la solution qui paraît la plus évidente c’est bien de la communication et de la collaboration fréquente et facile entre les 2 entités. (et donc on démontre que l’agilité c’est tout naturel. Ben oui…)
Retour d’expérience Yahoo! international
- Avant d’essayer quoi que ce soit, il faut obtenir l’amont du management.
- Aider l’équipe Produit à faire le backlog. Dans le cas du retour d’expérience de Monsieur Boutin, 3 jours de dialogue ensemble.
- Les métriques… Je voulais chercher à quoi ça correspondait, il suffisait d’attendre un peu
- Approche “framework” pour laisser la porte ouverte au choix de la “gestion de projet” / pratique. Standardiser les pratiques logicielles n’est pas incompatible avec les pratiques actuelles. –> c’est étonnant, mais quand je relis, j’ai du mal à comprendre =)
- Petite pensée qui n’a rien à voir: penser à faire des “burndown charts”
Le Refactoring
*waouh, complètement bluffée par les outils de refactoring utilisés dans cette démo !*
- C’est quoi ? du remaniement (ça fait plus classe que “nettoyage”, le terme qu’on utilise chez nous). Changer la structure du code pour en faire apparaître la conception, et donc pour qu’on soit capable de le partager ou de le faire lire à quelqu’un.
- Un grand principe de XP qui rend le refactoring incontournable : “Chaque chose ne doit être exprimée qu’une fois”.
- Refactoring vs documentation. Eh oui, je l’ai toujours soutenu et voici une preuve, Les commentaires qui redisent exactement ce que fait la fonction alors qu’elle est bien écrite et qu’elle utilise des identifiants explicites, ça sert à rien !!!
- http://www.uispec4j.org (pas encore eu le temps d’aller voir).
Crystal – méthodologie du jeu coopératif
- Contexte de ce retour d’expérience:
- Beaucoup de facteurs de découverte
- Industrie
- Alistair Cockburn est à l’origine de Crystal
- Idée générale: 1 projet = 1 méthode de dev différente. Même si toutes les méthodes ont le même “code génétique”:
- théorie
- propriétés
- stratégies
- techniques
- 2 objectifs: 1) livrer, 2) être prêts pour après (doc…)
- L’information est un parfum
- Quitte à ne pas faire tout dans XP, autant savoir lesquels faire et pourquoi.
- Miyamoto Musachi, Samurai
Voilà, un compte-rendu peu exhaustif, mais qui reflète ce que j’ai retenu.
Vivement l’édition 2009 !
