Manually searching the Web is not a sustainable model, long term
Eric Schmidt, CEO Novell inc. (1998)
Mois : juin 2013
Scrum Boat 2013, 1ère partie (en images)
Tu d’abord reportée, nous avons crains un moment être dans l’impossibilité de tenir notre Scrum Boat. Finalement, cela a tenu. Il faisait beau mais pas trop afin de ne pas étouffer dans la péniche. Les ateliers étaient prêts, ainsi que le buffet et la bonne humeur. Enfin les participants étaient au rendez-vous. Bref, tous les auspices étaient réunis !
Un petit cocktail attendait les participants à l’arrivée. On va commencer les ateliers bien chauds, c’est bien.
C’est l’heure, mise en place des ateliers !
Bertrand Dour et son frère nous proposaient “le petit poucet”.
Avec une assistance très nombreuse, pas nécessairement facile pour ce genre d’atelier
Dans l’assistance, Alexis et bien d’autres habitués.
Faute de cailloux, nous autre agilites avons des post-its !
… Beaucoup de post-its !
Oana nous proposait un atelier illustrant le “A3 problem thinking”
L’affluence n’a hélas pas permis à tout le monde de participer activement. Ca fait toujours plaisir de voir et revoir Dragos, Elisabeth et les autres…
Au programme, du lancement d’avions en papiers !
Ensuite, il faut améliorer !
Et pour cela reconstruire une nouvelle série d’avions en papier
Le A3, qui fait plus qu’un A3 résume les mesures d’améliorations.
Et c’est reparti pour une nouvelle série de lancers !
Sur le pont numéro 1, l’open-space rassemble un petit groupe de réflexion
Pour être honnête, nous pensions intéresser un peu plus de monde avec l’open-space. Pas grave.
Je n’étais pas seul à faire la couverture photo. Saluez la performance de la prise de vue faite à l’envers au-dessus de l’épaule. Je suis moi-même surpris du résultat, il me faut l’avouer.
La première série d’ateliers vient de s’achever, à très bientôt pour la suite.`
Note de lecture : La pratique du Lean Management dans l’IT, par Marie-Pia & Christian Ignace, Régis Medina & Antoine Contal
Note : 8 ; Comprendre l’application du Lean à l’informatique. Vraiment.
Il ne faut pas se leurrer : comprendre le Lean, c’est difficile. On nous parle de la maison Toyota, d’un certain nombre de pratiques, le tout cimenté avec des mots Japonais … Très bien. Mais ça reste très flou. Et comme de plus, le Lean passe pour être un peu l’aristocratie de l’agilité, ça ne fait pas très bien de dire qu’on a pas pigé ! Ce que l’on appelle parfois le « Lean Software Development » n’aide pas non plus tant que ça. Difficile de comprendre en quoi cela est différent de nos pratiques actuelles.
Il y a peu de textes qui m’ont permis de prendre conscience de la nature du Lean. En fait, il n’y en a que deux. Le premier est le « système Lean » de Womack et Jones, mais il portait sur l’application du Lean à la production. Le second est celui-ci !
On dit que l’on apprends mieux quand on nous raconte des histoires. C’est ce que font les auteurs ici. Au long des 11 chapitres complétant les 240 pages de cet ouvrages, ils nous enseignent par l’exemple les pratiques Lean au service de l’IT.
En Lean, tout part de la valeur et c’est ce que les auteurs abordent au premier chapitre. S’il ne s’appuie pas sur des exemple il expose efficacement les deux facettes de la valeur (on oublie souvent que pour le Lean il y en a deux) et les sources de gaspillage.
Le chapitre 2 « un idéal de fonctionnement » poursuit sur cette description du Lean qui reste ici encore un peu théorique en décrivant la « maison Toyota ». Un grand classique, serait-on tenté de dire, mais présenté avec une grande clarté. Même si je vois le sujet abordé pour la 3 ou 4ème fois, j’ai eu l’impression de voir la lumière s’allumer…
Le chapitre 3 « la pratique du Lean » est à lire et à relire, tel un kata que l’on répète afin de s’imprégner du message sans qu’il ne soit plus besoin d’y réfléchir. On n’y évoque pas seulement les différentes pratiques, mais aussi de la façon dont elles s’articulent, par où on commence… Une vingtaine de pages de pur enseignement.
Notre premier cas pratique arrive au chapitre 4, avec la gestion d’incidents. On y part d’une situation à laquelle on applique une démarche Lean. On expose celle-ci, notre plan d’action. Puis on déroule celui-ci avec ses découvertes ses progrès etc.… Le tout abondamment illustré est parfaitement limpide.
L’amélioration venant de la répétition, nous abordons un nouveau cas client au chapitre 5, une équipe support plus précisément. Si le chapitre 4 avait mis en pratique certains concepts comme le lead time ou le bac rouge, le chapitre 5 permet de voir plus précisément le PDCA.
De la réparation de la valeur, on passe à la création de valeur au chapitre 6 qui aborde la question du projet. D’autres outils sont illustrés ici comme l’Obeya room, la voix du client ou encore la résolution de problèmes (bien que le A3 soit mis de côté) ou encore le takt time. On le voit, un chapitre bien rempli !
C’est à la mise en flux que se consacre le chapitre 7. Parmi les thèmes qui y sont abordés, on trouve la restauration de la confiance avec le client et le management visuel.
Le chapitre 8 est entièrement consacré à l’un des piliers du Lean : le Kaisen, c’est à dire l’amélioration continue. C’est dans le cadre de l’amélioration de l’expérience utilisateur que le sujet est abordé. On y croise chemin faisant le modèle des 5 attentes client du Lean. Aspect déjà largement abordé dans les autres chapitres, le « go & see », prends une large part ici. Les concepts de « get out of the building » et d’expérimentation nous sont plus familiers dans la littérature Lean Startup mais ils figurent aussi au programme.
Il aurait été difficile de traiter pour cet ouvrage d’éluder le sujet de l’agilité. D’autant qu’Antoine et Régis sont parmi les plus anciens praticiens de l’agilité de l’hexagone car ils ont débuté avec XP dans les années 90 ! Lean y est présenté comme une approche permettant de doper la mise en œuvre de l’agilité avec XP et Scrum.
Le chapitre 10 est une occasion de reprendre de la hauteur. On y passe en revue les pratiques essentielles du Lean et ce qu’elles apportent.
Déployer le Lean ne se fait pas d’un coup de baguette magique. C’est au contraire un chemin difficile. Les auteurs évoquent leur expérience de la chose et les différents biais par lesquels cela peut être fait.
La pratique du Lean Management dans l’IT est un texte qui se lit très bien. Ne soyez pas surpris de le boucler dans la semaine. La plupart des chapitres racontent une histoire, une introduction du Lean dans un contexte particulier avec les actions menées par les coaches. Mais lecture aisée ne signifie pas texte creux ou chemin facile. De nombreuses pratiques sont mises en œuvre, beaucoup de concepts sont expliqués et nécessitent de revenir sur le contenu.
J’ai coutume d’aller écouter Régis et Antoine quand j’en ai l’occasion. Les sujets qu’ils présentent sont riches et intéressants. Mais comme disent les jeunes : on prends cher ! Les coaches Lean qui ont écrit cet ouvrage ont un très haut niveau de maturité, ils nous montrent le chemin et nous laissent comprendre que nous avons encore beaucoup à progresser en plaçant la barre très haut. Cela aussi nous vient du Lean. Et cela peut nous aider à progresser mais aussi nous décourager. C’est probablement le prix à payer.
La discrétion avec laquelle ce livre est sorti ne doit pas en occulter la valeur. Il a raté de peu mon classement du “book of the year”. C’est un texte de haut niveau dont la matière est illustrée avec talent par des cas réels et le déroulement d’une véritable transformation. Ne le ratez pas !
Référence complète : La pratique du Lean Management dans l’IT, agilité et amélioration continue – Marie-Pia Ignace, Christian Ignace, Régis Medina & Antoine Contal – Pearson France 2012 – ISBN : 978-2-7440-6544-6
Done or done-done ?
- T’as finis ton US ?
- Ouais, ça y est, c’est bon !
- Donc, t’es done ?
- Oui, elle est “done” !
- On peut la mettre en prod ce soir ?
- Ah ben non, y’a encore des trucs à faire …
- Donc, elle est pas “done” ?
- Ben si, le dev est terminé. Mais il reste des trucs à faire, mais c’est pas moi. Elle est pas “done-done"…
Le concept de "definition of done” de Scrum est souvent interprêté comme une licence à ne pas aller jusqu’au bout de l’action (la mise en production, même seulement “potentielle”) mais comme un niveau d’accomplissement:
- Developpement terminé.
- Acceptance tests terminés.
- End user tests / beta testing terminé.
- Qualification opérationelle terminée.
Ce n’est pas le cas. Ce n’est pas de cela dont Scrum Parle quand on parle de “definition of done”. Le “done” de Scrum signifie toujours que mon développement peut être déployé en production sans autre forme de procès, que je le fasse effectivement ou pas !
Cela signifie simplement qu’en fonction de l’organisation, le paquet-cadeau pourra contenir différentes choses :
- Une documentation utilisateur.
- Un audit de conformité au plan d’urbanisation.
- Une formation utilisateur.
- Un outillage de monitoring pour les équipes de production
- etc…
Votre imagination peut être sans limite, mais il en ira alors de même du coût de votre “definition of done” !
Mais on voit les équipes abdiquer par rapport à ce critère et inventer des niveaux de “done” intermédiaires ! Pourquoi ?
le plus souvent parce que les organisations font peser sur elles des contraintes de fonctionnements qui ne leur permettent pas d’avoir le contrôle sur toute la chaine jusqu’à la mise en production.
- Ce peuvent être des cellules de test séparées, avec des plannings indépendants du projet et générant ainsi du délais.
- Très souvent, sont concernées les équipes de productions, avec leurs propres plannings de mise en production transverses à de nombreuses équipes.
- De manière générale tout ce qui créé des silos dans l’entreprise est un frein à avoir un véritable “done” !
Impuissants face à ces choix d’organisation, les équipes Scrum préfèrent s’adapter et aligner leur définition de terminé à ce qu’ils peuvent réellement contrôler, donc le périmètre de leur équipe. Mais cela ne corresponds pas à un réel accomplissement. Ce “terminé” va juste prendre la poussière sur une étagère avant d’être testé / qualifié, etc… et ensuite seulement être réellement utilisé !
Cette définition de terminé est un leurre. Il nous donne (peut-être) bonne conscience. Mais surtout il dissimule les lacunes du système !
Ne faites pas cela ! Conservez, augmentez même la visibilité des lacunes du système ! N’abdiquez pas sur la définition de terminé : ce doit toujours être un produit qui peut être passé en production, là tout de suite, maintenant !
N’oubliez pas que d’autres vont plus loin encore dans l’appréhension du done : en Lean Startup, même si cela n’est pas explicitement exprimé ainsi, on est “done” quand on a eu le feedback des utilisateurs et qu’on en a tiré les leçons !
Le constat mis en évidence est souvent douloureux, peut paraitre insurmontable, mais c’est le véritable chemin qui vous reste à parcourir pour arriver à un réel processus agile.
The search for a scapegoat is the easiest of all hunting expeditions.
Dwight D. Eisenhower
Note de lecture : Open Source ESBs in Action, par Tijs Rademakers & Jos Dirksen
Note 5 : Un propos qui serait clair s’il n’était alourdi par la présentation de 2 ESBs et qui a prématurément vieilli.
Pour bien comprendre ce qu’est un ESB, le mieux reste encore de le mettre en pratique. C’est l’objet de ce livre : mettre en œuvre non pas un mais deux ESB et de comparer leurs cas d’utilisation. 11 chapitres sur 235 pages regroupées en 3 parties auxquelles il faut ajouter les 50 pages d’annexes sont nécessaires à ce défi.
La première partie est dévolue à la découverte du monde de l’intégration en général et de l’ESB en particulier. Le premier chapitre nous parle des cas d’utilisation des ESBs dans le monde des architectures J2EE. En fait, il va plus loin que cela en nous proposant un « hello world » avec chacun d’entre eux. C’est une bonne mise en jambe.
Après la présentation générale, vient l’architecture. Mule et ServiceMix (car c’est d’eux dont on parle) sont présentés du point de vue des concepts architecturaux, en empruntant largement les représentations officielles. Mais les auteurs montrent aussi les différents concepts en illustrant avec des fragments de code. Là aussi, c’est tout bon.
Présenter 2 ESBs présente aussi des difficultés. Ce chapitre 3 consacré à la mise en œuvre jongle entre les 2 plateformes. Cela rends la lecture compliquée et les 35 pages de ce chapitres semblent denses, sinon fouillis. Il eut été préférable de consacrer un chapitre à chacune des cibles.
Cette première partie se conclut par le chapitre 4 au cours duquel on va réaliser un mini-projet d’intégration avec Mule et avec ServiceMix. On y trouve aussi une évocation de Spring Intégration, encore balbutiant au moment de l’écriture de l’ouvrage mais qui soulève apparemment l’enthousiasme des auteurs.
La seconde partie est une plongée en profondeur dans les fonctionnalités des ESB. Il compte également 4 chapitres. On débute par le chapitre 5 où il est question de traitements sur les messages. On y évoque bien entendu le content-based routing, la validation et la transformation des messages. Le tout abondamment illustré de code avec en complément de Mule et surtout de ServiceMix : Apache Synapse et Camel.
Le chapitre 6 traite des connecteurs, de la manière dont ils s’intègrent et ils s’utilisent. On y passe en revue la connexion aux fichiers, à JMS, l’accès aux données via JDBC au mail, à JNDI ou au FTP. Chaque fois ServiceMix semble un peu mieux traité que son rival. Les 50 pages de ce chapitre ont un peu des allures de catalogue mais tout est clairement expliqué, illustré de schémas et de code, donc c’est O.K.
Le sujet peut paraître désuet aujourd’hui, pourtant il reste important : l’accès aux services Web SOAP est le thème du chapitre 7. Les deux plateformes s’appuient sur CXF aussi bien pour invoquer que pour être appelés. Le WSDL est déjà lui-même un peu touffu, il ne faut pas s’étonner que ce chapitre ne soit pas très simple d’accès. Last but not least, ce chapitre évoque aussi quelques normes WS telles que WS-Security ou WS-Adressing. Ca ne fait rien pour alléger le propos.
Cette seconde partie se conclut par un chapitre dévolu à la gestion d’erreurs et à la sécurisation des ESBs. C’est pratiquement un challenge d’y comprendre quelque chose. Mais c’est surement un sujet sur lequel on peut revenir plus tard, une fois que l’on s’est réellement approprié le sujet. Car les explications ne sont pas évidentes quand on débarque…
La 3ème partie est consacrée à des « case studies » qui s’avèrent en fait être un peu plus que des études de cas, mais des sujets avancés dans la mise en œuvre d’ESB. Le premier chapitre de cette dernière partie qui en compte 3 est consacrée aux Enterprise Integration Patterns de Gregor Hope. Après une courte introduction au sujet, on plonge dans la réalisation d’un système de réservation pour 3 restaurants en intégrant progressivement différents patterns des EIP. On passe ainsi du CBR au publish-subscribe tout en allant chercher des données en base… cela devient plutôt complexe surtout qu’il faut de surcroit faire cela sur 2 plateformes.
Je me demandais à quel moment on allait parler de monitoring. La réponse est : c’est au chapitre 10 ! On continue avec notre cas d’utilisation sur les restaurants et c’est aussi l’occasion d’aborder d’autres patterns comme le Message Store (c’est une base de données XML, eXist qui est utilisée ici). Comme on pouvait s’y attendre, on aborde aussi JMX. Là aussi devoir traiter 2 plateformes complique terriblement le propos. C’est d’ailleurs Mule qui tient la corde ici, il est mieux outillé pour gérer les instances de production. Pour ServiceMix, il faut en gros se tourner vers JConsole…
L’ouvrage se conclut sur le chapitre 11 et l’intégration d’un moteur de workflow ! Ca ne rigole plus et c’est même un peu trop pour le livre. Logiquement, c’est jBPM qui a été choisi. Mais on consacre aussi quelques pages à Apache ODE (qui semble aujourd’hui moribond). Je pense qu’on aurait pu faire l’économie de ce chapitre pour mieux traiter séparément les deux ESBs dans le reste du livre.
Les sujets abordés deviennent parfois ardus, mais le texte est globalement de bonne qualité et bien illustré. Comme je l’ai dit, il est rendu complexe par le traitement parallèle, je dirais presque schizophrénique de deux plateformes. Plus gênant, les exemples de code ne semblent pas fonctionner directement. Ils demandent au minimum un peu de bricolage. Trop pour que l’on s’amuse à tous les tester. Autre grand regret : la vitesse d’obsolescence. Le texte traite de ServiceMix 3.x au moment même ou ServiceMix (qui est très différent) apparaît. On en est aujourd’hui à la version 4.5.x ! Il en va de même pour Mule qui était en version 2.0 au moment de la rédaction et qui est aujourd’hui en 3.4 !
Pour ces raisons, je ne saurais conseiller ce texte aujourd’hui. Il mériterait une mise à jour, car les évolutions de ces deux ESBs sont maintenant en rythme de croisière, avec le travail de fond nécessaire sur les exemples. Malheureusement, je ne pense pas que cela arrivera…
Référence complète : Open Source ESBs in Action – Tijs Rademakers & Jos Dirksen – Manning 2009 – ISBN : 1933988215 ; EAN13: 9781933988214
ScrumBeer de Juin
C’est devenu traditionnel, pour connaitre le nombre de participants à une ScrumBeer, on prends le nombre d’inscrits sur Meetup et on divise par 4 ! Donc nous étions 6. Que croyez-vous que cela nous fasse ?
Eh bien, rien du tout ! Comme on dit à propos des open-spaces : “les personnes qui sont là sont les bonnes personnes”. Il manque juste Yannick sur cette photo, il n’est arrivé qu’après, tant pis pour lui.
Chaque ScrumBeer nous amène au moins un nouveau venu à l’agilité. Ce soir-là c’était Eric. Nous nous sommes cette fois encore livrés à l’exercice de faire comprendre ce qu’est être agile plutôt que comme faire de l’agile ! C’est toujours un plaisir quand l’auditoire est bon. Peu importe qu’il soit restreint.
Pas d’agenda comme d’habitude à ces soirées (est-ce pour cela que nous sommes peu nombreux ?). Arnaud a commencé par nous montrer les post-it électrostatiques Zapsense. A essayer absolument !
D’ailleurs, on a essayé : On a marqué notre territoire ; c’est nous le French SUG, et on est méchants !
La discussion a aussi porté sur l’innovation : Agilité et innovation fonctionnent-ils en synergie ou sont-ils antinomiques ? Personnellement je pense que la nature fondamentalement émergente de l’approche agile en fait un moteur naturel de l’agilité. Il parait qu’en peinture, on ne saurait être créatif si l’on sait déjà où on veut arriver … c’est probablement vrai en bien d’autres domaines. J’en suis convaincu concernant notre propre domaine.
Arnaud (encore lui, le traitre) en a lâchement profité pour m’asséner un article sur le sujet que je dois donc lire. Je vous l’assène à mon tour !
Autre sujet qui est venu sur la table : le plaisir au travail. Pour moi, c’est un facteur important, essentiel même. En fait c’est en partie lui qui nous permet de faire du bon travail. Alors si atteindre nos objectifs professionnels et prendre du plaisir sont deux objectifs qui ne convergent pas, quelles décisions devons-nous prendre ?
Je vais clore ce nouveau chapitre des Scrum Beer avec Martine : une habituée des évènements agile sur Bordeaux qui nous a fait le plaisir de se joindre à nous ce soir !
A la semaine prochaine, pour le Scrum Boat !
Yesterday I was clever, so I wanted to change the world. Today I am wise, so I am changing myself.
Agile France 2013, bonus track
J’ai couvert tout ce à quoi j’ai assisté … mais il y a en a beaucoup auxquelles je n’ai pas assisté. J’ai essayé de rassembler ici le matériel éparse sur lequel j’ai pu mettre la main.
J’en rate beaucoup, j’en suis sûr. Si vous avez d’autres liens, faites suivre ! Je les ajouterais.
Blogs et autres liens utiles
- Mon premier Agile France, par Olivier Azeau
- L’agile France d’Alexis Monville.
- Agile France, c’était les 23 et 24 Mai par Simon Jallais.
- Agile France 2013 : J’étais là ! Par Emilie Esposito
- Agile France 2013, impressions de voyage par Thierry Cros
Les autres présentations
Ne cherchez pas un ordre corrélé au programme, ce n’est pas le cas. Have fun !
L’agilité en maintenance logicielle
Communautés de pratiques en pratique
Sport et théatre avec Christophe Keromen
Christophe nous proposait 2 présentations. Tout d’abord, ce que le sport m’a appris de l’agilité
Puis la même déclinaison à propos du théâtre
Peter Stevens : Agile values, French values
Les paradoxes du leadership
Les articles qui parlent des autres présentations
- Scrum Métal Jacket (la présentation)
- Travailler oui, avec plaisir, le blog de Soat
- Usages de la CNV en agilité, sur le blog de Soat
- Mener le changement, les 8 étapes de Kotter, sur le blog de Soat
- Software Ball (le site)
IP v6 par pigeons voyageurs, c’est possible et c’est prévu : RFC 6214
Bien sûr, c’est une plaisanterie. Au départ c’était même un poisson d’avril lancé en 1990 sous la dénomination RFC 1149. Il n’en reste pas moins que cette RFC émise en bonne et dû forme (la traduction française est disponible ici) est parfaitement implémentable … et implémentée !
Une mise à jour de cette norme eu lieu en 1999 sous la dénomination RFC 2549, y ajoutant la notion de qualité de service.
Cette dernière mouture de la RFC, la 6214 émise en 2011 prends en charge l’IP v6.
Chaque version de la RFC devient plus élaborée que la précédente, et en développe les concepts. Est ainsi développé le cas du “tunelling” lorsque certains porteurs en mangent d’autre emportant leur “payload” dans leur système digestif. Pour autant que celui-ci ait été écrit sur un support résistant aux sucs gastriques…
IP v6 par pigeons voyageurs, c’est possible et c’est prévu : RFC 6214
Software Freethinker 
