mardi 29 novembre 2011

Story Map : commentaires et exemple

Voilà, comme promis, une version plus complète de ma présentation sur le story mapping. Avec mes commentaires et un exemple.

Story map : objectif feed back (version longue)

Ma story map finale comporte une 'erreur' : le contenu de la première itération n'est pas optimal, à vous de jouer ! Faites vos commentaires, corrigez, critiquez, suggérez !

Merci !

lundi 28 novembre 2011

Agile Grenoble : bilan #2

Quelques extraits que j'ai pu glaner au cours de ces 2 jours (Agile Grenoble et Agile Innovation) :

- La conception, ça se fait après le développement et ça s'appelle du refactoring. Voir la présentation de Laurent Bossavit, de l'Institut Agile.

- Le backlog produit dans Excel, en liste : on n'y comprend rien, sauf si on l'a écrit soi-même. Mack Adams.

- Si on demande qui va gagner, c'est que quelqu'un va perdre.  Mack Adams, encore.

- Un musicien ne passe pas sa vie en concert, il s'entraîne la plupart du temps. Et un développeur qui passe sa vie à produire, il s'entraîne quand ? Thierry Cros.

- La valeur : un système complexe, piloté par le "why" (voir Karl Scotland : "Les gens n'achètent pas ce que vous faites mais pourquoi vous le faites"),  ce qui lui donne du sens. Signé : les participants à la session "Qu'est ce que la valeur", avec Rémi Sanlaville.



Session Open Space sur le TDD en JavaScript, avec Jean-Michel Garnier


C'était vraiment bien (surtout Agile Innovation !), des rencontres très intéressantes, tout ça est très stimulant, vivement la prochaine fois !

Agile Grenoble : bilan #1

J'ai animé avec Laurence Hanot l'atelier "Story map : objectif feed-back". Ci-dessous la présentation que nous avons utilisée (merci à Céline pour les jolis post-its !)
Story map : objectif feed-back

Merci à Laurence de son aide, et merci à tout le staff d'Agile Grenoble !

Je suis plutôt content de cette première expérience d'intervention dans une manifestation agile, c'était intéressant et instructif. Bon, 55 minutes c'est trop court pour ce type d'atelier, un Kata aurait été plus adapté. Et puis nous étions nombreux... Je vais publier prochainement ici un peu plus d'infos sur ce que j'ai dit lors de cet atelier.

J'ai appris par Mack Adams que Jeff Patton préparait un livre sur le story mapping, bonne nouvelle !


mercredi 23 novembre 2011

Agile Grenoble, c'est demain !

Demain, j'anime avec Laurence Hanot l'atelier "Story Map : objectif feed-back !".



De quoi nous allons parler ? De story map, bien sur, mais surtout de vitesse. La vitesse est importante, elle entretient la motivation et la vision. Et une story map est un bon moyen d'aller vite.

Par aller vite, j'entend "livrer rapidement aux utilisateurs une première version du produit".

On en parle demain ? Vous n'y serez pas ? Vendredi, alors, à Agile Innovation ? Non plus ? Alors rendez vous ici dans quelques jours...

Menuiserie agile

Après en avoir essayé une, j'ai décidé de me fabriquer une pagaie groenlandaise. Ce n'est pas tout à fait comme développer un logiciel. C'est un peu plus compliqué de recommencer quand on s'est trompé. Ou alors il faut être prêt à gâcher beaucoup de bois...



Alors j'ai fait un plan. Avec des mesures et tout. Vite fait, mais fait quand même. Je me suis servi d'indications trouvées sur internet. Et bonne nouvelle ! Celui qui a rédigé ce "manuel pour faire une pagaie traditionnelle" est un menuisier agile !

Pour construire sa pagaie, il faut tenir compte d'éventuelles erreurs de mesure ou de coupe, mais surtout, surtout, une pagaie traditionnelle doit être adaptée à la morphologie de son utilisateur. Et là, pas de recette miracle, il faut... tester !

Il conseille donc de tailler une pagaie un peu trop grande et trop épaisse, puis de faire des essais et de rectifier ensuite...

En avant pour l'itération 1 de ma pagaie !

jeudi 3 novembre 2011

Des logiciels et des hommes. Part Two

Un sujet récurrent dans le développement logiciel, c'est l'architecture.

Il y aurait de bonnes et de mauvaises architectures. Ou plutôt, il y aurait des architectures bien adaptées à tel ou tel produit ou environnement technique, et d'autres qui le seraient moins.

Mais est-ce l'essentiel ? N'oublierait-on pas quelque chose ?

Imaginons que je veuille construire ma maison moi-même. J'étudie tout ça, me plonge dans différents ouvrages ou sites sur le sujet, puis je décide finalement de construire une maison bio-climatique, avec toutes les caractéristiques qu'une maison du XXI° siècle devrait avoir. Je conçois la maison idéale. La maison avec la bonne architecture.

Bon il n'y a plus qu'à la fabriquer, alors. Oups. Moi, en dehors de clouer quelques planches... Heureusement, mon cousin m'a dit qu'il m'aiderait. Il est maçon. Le hic, c'est que ma maison à l'architecture parfaite, elle doit être en bois et en paille... Et puis mon cousin, tous ces trucs bio-machin... Lui, il monte des parpaings.




La bonne architecture, c'est un compromis entre l'architecture "idéale" et celle que l'on est capable de réaliser. Et surtout celle qui reçoit l'adhésion de ceux qui vont l'implémenter, "pour de vrai" !

La bonne architecture, c'est celle que l'équipe "sent" le mieux. Pas celle impos.. pardon, proposée par l'architecte en chef ou je ne sais quel expert.

Et vous savez quoi ? Il y a une méthode infaillible pour qu'une équipe adhère à une architecture. C'est qu'elle la définisse elle-même...

Et vous savez quoi (bis) ? Si cette équipe a des compétences variées, des jeunes prêts à tout changer, des vieux expérimentés (ou l'inverse) et que tout ce monde a envie de réussir... ils trouveront certainement l'architecture idéale.