Note de lecture : Growing Object-Oriented Software Guided by Tests, par Steve Freeman & Nat Pryce

Note : 8 ; Craftmanship en grandeur réelle

Quand on évoque le craftmanship, on montre des exemples de code, sinon cela n’a pas de sens ! Généralement, il s’agit de 2 ou 3 classes qui se battent en duel que l’on refactore afin d’améliorer les abstractions, éviter les duplications de code et tout et tout… Ce livre-là est différent, car il va faire du design émergent en TDD une réalité en l’appliquant sur la construction d’un logiciel complet, le tout suivi pas à pas ! Pour mener à bien sa mission, le texte compte un peu moins de 330 pages hors annexes, le tout découper en 5 parties très inégales. Je ne vais pas vous compter par le menu les 27 chapitres de l’ouvrage, mais plutôt les 5 parties.

La première partie est introductive (comme on peut s’en douter). Elle ne compte que 3 chapitres sur 25 pages. Il s’agit avant tout de considérations générales, mais non dénuées d’intérêt. On y évoque des principes nouveaux ou anciens comme le cycle ATDD imbriqué dans le cycle TDD, les cartes CRC ou le « tell, don’t ask ».

La seconde partie, longue d’un peu plus de 40 pages sur 5 chapitre, adresse spécifiquement la façon de travailler en TDD sur un projet réel. Cette partie évoque la question du style des tests, comment ils doivent être conçu pour être lisibles et tester des comportements. Mon sujet préféré dans cette partie a trait à l’architecture agile : les auteurs y développent l’architecture hexagonale (Cockburn) ou en oignon (Martin). Cette partie s’étend jusqu’à l’évocation du test logiciel avec les parties tierces (en utilisant des mock), mais il reste léger là-dessus.

La troisième partie occupe la majeure partie du livre. Il compte en effet 150 pages découpées en 11 chapitres, au long desquelles nous allons construire un « auction sniper » ! On ne commence pas par le plus facile, d’ailleurs. Car s’il y a bien un choix discutable, c’est bien de s’être fixé sur une application Swing ! On passe donc les 3 premiers chapitres à faire passer notre premier test ! Par contre, malgré la « glue Swing », on a bel et bien un premier test au sein d’un design simplifié au maximum où la logique métier côtoie l’IHM et les aspects techniques de communication. Et on a aussi une « todo liste » qui nous guidera au long des chapitres suivants ! Les chapitres suivant font progressivement émerger le design, en utilisant les tests comme signal d’alerte de confusion et en s’appliquant à ce que ces refactorings n’aient pas d’effets de bord sur les autres tests. On y introduit aussi les fonctionnalité de JMock. Ou plutôt nous laisse-t-on deviner comment ça marche (les annexes comprennent un tutorial JMock). Les règles de design telles que la gestion du NULL, la gestion des types métier sont introduits progressivement en faisant émerger le design. Au fur et à mesure, le système s’étoffe aussi de nouvelles fonctionnalités. Régulièrement, en plus du code, les auteurs nous livrent des morceaux de modélisation « à main levée ». Toute cette saga ne se lit pas avec la même fluidité d’un bout à l’autre et globalement elle demande pas mal d’attention et de concentration. Mais c’est un sacré exercice riche d’enseignements.

La 4ème partie couvre une cinquantaine de pages sur 5 chapitres. On y aborde des sujets récurrents de tout développements logiciels et souvent éludés en terme de design. Pas de ça ici : les auteurs proposent des positions et des idées qui font honneur au mouvement craftmanship » ! Le sujets abordés sont le logging, les diagnostiques, la lisibilité des tests, la construction de cas de tests avec des structures de données complexes. Entre autre choses. Bref, une partie que j’ai particulièrement appréciée.

La dernière partie occupe 3 chapitres sur 50 pages environ et se focalise sur des sujets avancés en terme de tests unitaires : la persistance, le multithreading et l’asynchronisme. Je le voie plutôt comme du matériel complémentaire, pas réellement nécessaire au propos, mais évidemment intéressant.

Le craftmanship ne recèle pas de tant de titres de qualité. Celui-ci se démarque par son focus sur le design d’application et non sur une vue zoomée de code, comme c’est trop souvent le cas. Le livre est resté longtemps à prendre la poussière sur mes étagères, c’est bien dommage ! N’en faites pas autant.

Référence complète : Growing Object-Oriented Software, Guided by tests – Steve Freeman & Nat Pryce – Addison Wesley / Signature series 2010 – ISBN : 978 0 321 50362 6

Growing Object-Oriented Software, Guided by Tests


https://www.goodreads.com/book/add_to_books_widget_frame/0321503627?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Meetup Craftsmanship de Février

Déjà mon deuxième meetup Craftsmanship ! La formule reste inchangée mais le contenu se renouvelle : 3 lightning talk et une partie atelier ! C’est Cyrille qui ouvre le bal.

La progressivité dans le code, par Cyrille Martraire

Cyrille nous invite à prendre conscience de la notion de « progressivité » lors de nos refactorings. Certains remaniements se font en douceur… jusqu’à se heurter à des remaniements qui s’avèrent plus brutaux !

image

Ainsi passer d’un if au for se fait en douceur. Dans un SGBDR, une entités qui était comprise dans la même table que l’entité maître va pouvoir migrer dans une table séparée lorsque sa cardinalité augmente. Cette déformabilité est facilitée par les outils, des IDE proposant des fonctions de refactoring, ou bien entendu la présence de tests unitaires.

Hélas cette déformabilité rencontre des limites, dont les frameworks sont régulièrement responsables : ceux-ci proposent des conforts d’usage selon un cadre nominal, mais la sortie de ce cadre engendre alors une forte augmentation de la complexité.

Enfin, déformabilité ne signifie pas flexibilité anticipée !

Docker pour le développement logiciel, par Mario Loriedo

Peut-on de manière simple gérer ses environnements de développement indépendamment de la machine ? C’est ce que Mario nous propose via un plugin Sublime Text qui nous permet la compilation directe dans un conteneur Docker !

image

Ce petit projet open-source a vu le jour lors du Docker Hackathon, il est hébergé sur Github. si vous souhaitez y contribuer, vous êtes le bienvenu !

Qu’est-ce que l’isomorphisme ?

Bien sûr, ici on parle de l’isomorphisme en programmation. De l’usage d’anciens mots pour de nouveaux usages, en quelque sorte…Ici, on parle avant tout d’utiliser le même langage et les mêmes API côté client et côté serveur. Cela réduit terriblement les technologies que l’on peut considérer. C’et donc essentiellement Javascript à la base, même si on a de petites choses en Ruby.

image

La plateforme la plus avancée en l’état est Meteor, qui propose ses API Java côté serveur, client Web et mobile ! Bien entendu, les API se comportent différemment en fonction de la localisation, un concept que l’on n’a pas trop de mal à imaginer si l’on pense au stockage…

Teasing des sessions

Nous arrivons à la seconde partie de la soirée, celle ou des ateliers ou des sujets d’open-space vont être proposés.

Java 8

Une première session pour évoquer Java 8 et les bonnes pratiques de programmation à mettre en oeuvre avec cette nouvelle mouture de Java. On pense aux lambdas, bien sûr.

Docker pour l’intégration

C’est aussi un open-space qui nous est proposé ensuite : peut-on utiliser Docker pour les tests d’intégration et comment ? Pour quels apports ?

Cycle de vie et versionning des applications

Un autre open-space proposé ici avec une nette coloration devops…

TDD en mission : oui, non, comment ?

Ca fait toujours classe de dire que l’on fait du TDD. Mais dans le contexte réel du client, ce n’est pas toujours si évident : pression des deadlines, fort legacy, etc. Est possible et comment faire ?

Cette session sera retenue lors des votes.

Atelier BDD

Stéphane Bagnier avait prévu son coup. Il propose un atelier des capture des besoins en ATDD, sur papier via l’interview d’un client.

Cet atelier sera également retenu.

Randori de code

Au dernier moment, cette proposition de session de « live coding » en mode Randori, autour de la résolution d’un jeu ! En l’occurence le tic-tac-toe, que j’appelle personnellement « Morpion ».

Ce sera la 3ème session retenue.

Il est maintenant temps de voter.

image

Grand amateur d’ATDD, je me jette bien entendu sur l’atelier de Stéphane !

Atelier BDD

L’animation proposée par Stéphane est très différente de l’atelier ATDD que je propose. Elle est aussi plus ludique. Le « sujet métier » est un jeu. Il s’agit d’un jeu des plus bizarre : le cul de chouette, issu de la série Kaamelott ! Nos 2 animateurs (car ils sont deux) répondent de manière imprécises et évasives aux questions que nous leur posons destinées à éclairer les spécifications du jeu ! Quand aux tentatives d’abstractions, ils s’y montrent carrément hermétiques !

image

L’idée est bien sûr de nous mettre face à des comportements réels ou exagérés d’utilisateurs et de les aborder par le biais d’exemples à l’aide de l’approche BDD.

En phase 1, le réflexe « écriture de tests » de prends pas, les participants rebondissent de questions en questions, sans les approfondir et en cherchant prématurément des généralisations. Bref, quelques concepts sont dégagés, mais cela reste très superficiel

image

Le second round est dédié à l’écriture de tests en binômes, en se concentrant sur des sous-parties du problème. Le résultat est beaucoup plus encourageant, d’ailleurs on découvre des pièges de l’énoncé. Le travers le plus souvent constaté est l’écriture de tests pas suffisamment univoques, parfois même abstraits ! Ce fut d’ailleurs l’objet d’une petite discussion assez intense dans mon propre binôme.

En conclusion : un bel atelier pour faire découvrir le BDD comme technique de spécification agile.

Et pendant ce temps…

Deux autres ateliers se déroulaient durant cette période. Tout d’abord la discussion autour du TDD en entreprise.

image

Je n’avais jamais vu le Randori pratiqué. Il m’a fallu un petit moment pour en comprendre le fonctionnement. Pour tout dire, il m’a aussi fallu un petit moment pour saisir que tests et code fonctionnels étaient mélangés au sein du même fichier source. Un peu de refactoring, que diantre !

image

On termine la soirée (au moins pour moi, car je ne suis pas resté pour la 3ème mi-temps) par un débrief des différentes sessions. Voici celle du TDD, justement.

Dev4Fun première !

Un nouveau Meetup, encore un ! Celui-ci est organisé par Xavier Detant et cette première édition se déroulait dans les locaux de Zenika !

Un beau succès pour cette première édition, car elle a rassemblé environ 30 personnes, c’est bien plus que ce que j’aurais parié. Et le groupe Meetup compte déjà 150 inscrits !

image

Ce meetup se veut une introduction douce aux coding dojos. Et pour que ce soit en douceur, c’est via la plateforme codingame. Le choix de langages est large et nous avons eu des amateurs pour Java (bien sûr), mais aussi Python, Scala, Haskell, Go et Dart ! En fait, il y a même eu du C !

image

L’une des choses sympathique de cette plateforme, outre son interactivité, c’est de fournir un canevas de code qu’il suffit de modifier. On a immédiatement une vue du résultat et les sorties pour trouver les erreurs ! Même au niveau simple, certains exercices deviennent ardus du point de vue algorithmique et l’on aurait certainement dû plus rapidement s’atteler à mettre ça sur papier. Chose que nous n’avons pas fait.

En fait, les problèmes à résoudre ne sont pas nécessairement si simple que cela. Pas évident si l’objectif est d’attirer des nouveaux venus. Par contre, j’ai trouvé le concept plutôt sympathique pour se familiariser avec de nouveaux langages.

image

Et moi, me demanderez-vous ? Eh bien j’ai fait du C ! Je ne me souvenais plus à quel point c’est bien plus bas niveau que le C++, il faut dire que la dernière fois que j’en ai fait remonte à plus de 22 ans… Pour être honnête, je n’ai pas tellement bossé (un peu quand même). Notre binôme était plutôt mal assorti, ni l’un ni l’autre n’étant probablement des binômeurs dans l’âme. Je ne pourrais être là au prochain rendez-vous, mais pour le suivant je pense plutôt recruter mon binôme à l’avance pour voir ce que cela peut donner en Go ou en Dart.

image

Les rendez-vous devraient en principe avoir lieu les 3ème jeudi de chaque mois. Les quelques prochains meetups devraient se poursuivre sur la plateforme codingame. Mais déjà il est question de varier un peu la formule afin de ne pas tomber dans la monotonie. Quoi qu’il en soit, cette première édition est incontestablement un succès !

Meetup Craftsmanship : où il est (aussi) question de documentation…

C’est dans les locaux de Zenika que s’est déroulé ce nouveau meetup Craftsmanship, en fait le premier pour moi ! Cyrille Martraire sera le maître de cérémonie, il introduit le déroulement de la soirée, à savoir : 2 lightning talks, 1 talk moins light et enfin le coeur de cette soirée, l’open-space

image

Alors, Dev4Fun, qu’est-ce que c’est ?

Xavier Detant est venu nous présenter un nouveau meetup, non pas concurrent, mais complémentaire à Software Craftsmanship : Dev4Fun !

image

Dev4Fun, c’est un « coding dojo », mais sans le mot « dojo », car ciblant plus les débutants. Pour rendre cela Fun, on s’appuiera, au moins pour la prochaine rencontre planifiée pour le 22 Janvier, sur une plateforme dédie au développement de code sur des jeux : codingame.

Bref cette rencontre a pour but de faire découvrir, comme le dit Xavier « pourquoi on kiffe sur les barres vertes » !

Comment amener les changements techniques dans l’entreprise ?

Cette présentation avait pour but de donner un coup de projecteur sur ce sujet issu du livre de Sandro Mancuso sur le Software Craftsmanship. Plus précisément, il est question ici de classifier les profils d’une équipe afin d’adopter la bonne stratégie en fonction des interlocuteurs !

image

On trouvera ainsi :

  • Le Non-Informé : Il ignore tout du sujet, on peut l’amener à bord en partant de zéro.
  • Le mouton : Pas la peine de s’en préoccuper. Si on embarque les autres, il suivra.
  • Le cynique : Il va prendre le contre-pied juste pour le plaisir de se montrer plus malin. Attention de ne pas perdre trop de temps avec lui.
  • Le désabusé : Il a essayé des choses et s’en est mordu les doigts, il n’a plus le goût à essayer.
  • Le surbooqué : Il n’a pas le temps de vous écouter
  • Le boss : Ne pas perdre de temps avec lui, car de toute façon, il n’y cmprendra rien.
  • L’irrationnel : c’est le cynique mais en pire ! Il va contre-argumenter sans but et va vous faire perdre du temps.
  • L’indifférent : Il ne se sent pas impliqué, mais attention ! Il peut être la source de mauvaises implémentations de bonnes idées.
  • Le persécuté : Il nuit au projet en attendant sa prime de licenciement. A écarter à tout prix.
  • L’inapte : Simplement pas à sa place. A éviter.
  • L’architecte « tour d’ivoire » : Il croit tout savoir mais ne touche plus au code. Attention, il peut avoir beaucoup d’influence…
  • L’inscure : Il s’est construit son petit confort, mais il est « has been » et a peur que l’on s’en rende compte.
  • Le fan boy : Implémente le pattern « golden hammer » avec une technologie qu’il admire et connait très bien. Mais si on peut le convertir…

Dans ce tableau idylique, il manque bien sûr le gars normal ! Comme le souligne l’orateur, identifier les profils, c’est déjà 50% du travail. Sur le fond, je trouve ici une matière un peu intéressante mais pas révolutionnaire. En fait, c’est une vision très simplifiée de ce que l’on peut trouver dans Fearless Change. Quand au livre, vous pouvez en voir un excellent résumé ici.

Does your code speak business ?

Pas un lightning talk ici, mais plutôt une présentation de 30 minutes (avec les petits soucis techniques qui l’ont émaillée). Maxime énonce le problème qu’il veut traiter ainsi : comment ajouter de la valeur si votre code ne parle pas métier. A titre de contre-exemple, il nous assène le syndrome de l’homme fort ! Vous savez, celui qui écrit un code incompréhensible plus vite que son ombre, qu’il ne faut jamais déranger et qui au final livre une usine à gaz à côté de la plaque ?

image

L’homme fort n’est pas le seul syndrome. De manière générale, on rencontre nombre d’équipe où le business et l’équipe de développement utilisent des vocabulaires différents ! Un problème encore amplifié par les modèles de développement en silos où le besoin initial fait l’objet de traductions successives…

image

La solution ? Le fameux « ubiquitous language » du DDD. Mais l’orateur nous invite à ne pas en rester là : pour découvrir ce vocabulaire, parlons Event Storming ! Il s’agit d’une approche proposée par Alberto Brandolini, elle prend la forme d’un workshop dans lequel on invite « des personnes avec des questions (les développeurs) et des personnes avec des réponses (le business) ». On part de « l’évènement le plus important dans le système » et on remonte dans le temps. A chaque évènement correspondra une commande et au final on sura comment le système doit se comporter.

Je ne connaissais pas l’Event Storming, un nouvel outil à considérer sérieusement !

Open-space : alors, cette doc ?

Oui, c’est un open-space, vous savez celui où on forme des groupes, on propose des sujets et on vote sur ceux-ci. Le zLocalHost de Zenika a fait le plein et nos 3 cercles sont un peu enchevêtrés…

image

Donc, on propose des sujets…

image

Puis on vote ! Je vais m’incruster dans le groupe qui parlera de documentation !

image

La discussion démarre sur les chapeaux de roues : moi j’utilise Sharepoint, moi un Wiki … Mais un instant : La documentation n’est qu’un moyen, non ? Quelle finalité cherche-t-on à atteindre avec cette documentation dont on pense implicitement qu’elle est indispensable ? Car là, on commence à parler du moyen du moyen !

Visiblement, la finalité, c’est souvent de transmettre de l’information quand quelqu’un part ou qu’un nouveau membre de l’équipe arrive. Un bien pauvre substitut au partage du savoir que l’on obtient en travaillant ensemble. On évoque aussi les tests, plus précisément les acceptance tests en tant que « living documentation ».

image

Pour en revenir à la documentation sensu-stricto, je relève :

  • Que je ne suis pas le seul à avoir des problèmes pour m’y retrouver dans les Wiki. Cyrille semble avoir le même problème que moi. Donc un bon moteur de recherche full-text y est indispensable.
  • Coupler la documentation avec la gestion de version, une option importante.
  • Les nomenclatures de noms de documents ou de répertoire, ça fait peut-être « old school », mais ça marche !
  • Le problème de la divergence de la documentation avec la réalité : un obstacle sur lequel on finit toujours par arriver. Pourtant on reste câblé sur l’idée de la documentation qui sauve de tout…
  • Les docs de haut niveau sont finalement celles qui sont le plus souvent demandées et utiles. Outre qu’elles ne sont pas trop volumineuses, elles souffrent moins du phénomène d’obsolescence, donc plus faciles à maintenir.

Cet échange n’a pas révolutionné mais idées, mais il était agréable. Les 2/3 choses que j’ai notées au passage ne feront pas de mal !

Assez bossé, il est temps de migrer vers le buffet pour conclure la soirée !

image

La résistance contre l’ISO 29119 s’organise !

Au départ…

Les agilistes ne sont guère friands de normes et autres standards. Généralement, nous nous contentons de les ignorer. Néanmoins ils sont souvent utiles.

C’est en proclamant l’utilité des standards, de la plupart des standards que James Christie commence sa présentation lors de la conférence CAST 2014, celle par laquelle tout a commencé. Car c’est contre les standard de test que s’élève le présentateur. Son propos rappelle celui de Dominique Dupagne dans La revanche du rameur qui clame que standardiser les processus n’assure en aucun cas la qualité du produit, qu’en fait il s’agit même d’une bonne occasion pour s’en désintéresser !

La question de considérer l’activité de test comme un « commodité » tend à donner une dimension directement économique à ce travail, ce que l’orateur juge trop simpliste (il a lui-même un diplôme en économie). De manière générale, il est d’ailleurs toujours possible de trouver une théorie économique correspondant à ce que l’on cherche à prouver ! James Christie nous ramène lui à Adam Smith, le père du capitalisme et ses 3 facteurs économiques : le travail, le capital, la propriété.

En alignant les processus de tests, les organismes de normalisation servent les cabinets de conseils qui pourront ainsi vendre du conseil sur ces processus normalisés. Les éditeurs devront eux dépenser de l’argent pour se conformer aux normes. Finalement, le consommateur y perdra aussi, car le focus des éditeurs se déplacera de la qualité du produit vers le respect des normes de processus !

La standardisation de l’activité de test nous amènerai vers une « licence » de testeur qui ne serait en aucun cas gage d’efficacité, ce que l’orateur trouve effrayant ! Imaginez un chirurgien : elles-vous jugez de sa qualité du fait du suivi d’un standard ou du nombre de personnes qu’il tue ? Le focus de ces standard est la documentation plutôt que le test réel !

Un autre point soulevé par James Christie est celui de l’asymétrie de la connaissance : plutôt que de communiquer la connaissance à celui qui en a besoin, le standard masque celle-ci par un écran de fumée. Il se réfère aussi aux pratiques d’audit : celles-ci disent qu’il n’y a pas 2 contextes IT semblables, ce qui rend caduque toute idée de checklist générique (institute of internal auditors). Les standards promeuvent plutôt une idée de « sauver ses fesses » en suivant celui-ci à la lettre afin d’être irréprochables !

Finalement l’orateur exhorte le publique à garder ouvert ce début contre l’ISO 29119, car l’absence de consensus seulement permettra de le remettre en cause.

Au fait, c’est quoi l’ISO29119 ?

Tout d’abord, la parole à l’avocat de la défense, Stuart Reid, avec cette introduction à l’ISO 29119

L’ISO 29119 se veut un consensus sur la manière de procéder des tests, c’est une démarche normalisée comprenant définition des processus et de la documentation. Elle est déjà mise en oeuvre par certains cabinets de conseil.

La résistance s’organise

Tout d’abord avec un manifeste, initié lors de cette même conférence CAST 2014 !

image

Une pétition fait suite à cet acte de foi. Difficile toutefois de s’opposer au corporatisme, mais cette communauté a choisi aujourd’hui de ne pas se laisser faire !

Je voulais saluer ce mouvement, bien que n’étant pas testeur, non seulement pour leur courage de défendre leurs idées, mais surtout parce qu’ils ont raison !

Autres ressources

Le FKUG offre un tour de chauffe à Lean Kanban France !

Beau programme pour cette rentrée du FKUG ! En effet, cette soirée hébergée par Wemanity proposait pas moins de 4 sessions sur 2 tracks. Nous serons donc hélas frustrés de 2 sessions !

image

Un petit mot sur le FKUG tout d’abord :

  • Les choses avancent, avec maintenant un site pour l’association.
  • La taille de la communauté augmente aussi progressivement : elle compte 330 inscrits sur meetup ! La j’en suis sûr, nous étions moins nombreux chez notre hôte…
  • On est rentré et bien rentrés : le prochain meetup se profile déjà pour le mois de novembre…

Assez bavardé, place aux présentations !

Apprendre à apprendre pour le 21ème siècle, par Yannick Grenzinger

Cette session, seul Yannick pouvait nous en gratifier ! Sur la dernière année, Yannick a suivi 30 cours en ligne, les fameux MOOCs, il est en quelque sorte un « boulimique du savoir » !

Cette présentation, que Yannick propose par ailleurs au format Brown Bag Lunch s’articule sur 3 niveaux : l’individu, le produit, l’organisation.

image

Apprendre pour les individus

Ici, Yannick nous propose quelques « hacks » :

  • Déconstruire pour mieux reconstruire : faire des tranches d’une dizaine de minutes. Cette déconstruction est déjà une étape de l’acquisition de la connaissance !
  • Des répétitions fréquentes, mais espacées (!)
  • S’appuyer sur l’utilisation de modèles mentaux et de métaphores. Tiens ? Cela ne vous rappelle-t-il pas XP ?
  • Eliminer les bloquants.
  • Utiliser une boucle de feedback rapide. Nous autres agilistes sommes en terrain connu…

Bien sûr, pour faire bonne mesure, Yannick sait aussi nous proposer quelques bonnes lectures :

L’un des points majeurs est qu’il n’est pas besoin d’avoir une « connaissance parfaite ». Les fameux 80% sont largement suffisants et s’acquièrent comparativement rapidement !

Apprendre sur les produits

Et déjà, sur la construction de produits, quel est l’inverse de l’apprentissage ? Le « cycle en V » bien sûr ! Et bien entendu, notre objectif est bien d’apprendre en permanence. Notre attirail d’agiliste possède ce qu’il faut à ce égard : Rétro, A3, Kaizen, etc…

Apprendre, c’est aussi utiliser le pouvoir de la collaboration et les techniques de co-création.

Enfin, apprendre c’est aussi accepter l’échec et penser à « aller plus vite sur l’échec ». C’est ce que nous enseigne le Lean Startup.

Apprendre en tant qu’organisation

De nouveau la même question : quel est l’inverse de l’apprentissage ? C’est le Taylorisme : un travail codifié devant être exécuté sans reflexion par des executant dont réfléchir n’est pas le rôle !

image

Apprendre au sein d’organisation, c’est d’abord savoir organiser pour la complexité, plutôt que chercher à la maîtriser ou le réduire à tout prix. Le Stoos Network a pour but de faire progresser ce mode de pensée, bien que force soit de constater qu’il peine à prendre de l’ampleur.
Le rôle du management est à repenser dans une organisation apprenante. C’est ce que nous enseigne le Management 3.0, mais aussi les militaires dans le manuel Warfighting !

Ce que j’en ai pensé

Je sors un peu frustré par cette session. De l’aveu même de Yannick, la partie « organisation » nécessite d’être renforcée. Mais c’est surtout sur la partie « individu » que l’on attendait l’orateur, et malheureusement il ne développe pas assez ses « hacks ». Nous aurions aussi aimé une reflexion sur la nature (et l’objectif) différent de l’apprentissage au 21ème siècle, à l’ère de l’information à haute valeur disponible au bout des doigts !
Toutefois, je sors aussi avec quelques pointeurs de lecture (encore). Connaissant Yannick, ils valent sans aucun doute le détour !

Continuous Delivery : A Plug-in for Kanban, par Samuel Retière

Il s’agit en fait d’une présentation qui serait fait à 3 voix au LKF, ici il n’y avait que celle de Samuel. Je ne vais pas paraphraser la présentation de Samuel, car vous pouvez y accéder ici.

Ce que Samuel nous présente ici, ce sont les « patterns de transformation » appliqués à la SGIB et organisé en 3 niveaux. Les thèmes s’articulent beaucoup autour du Kanban Thinking de Karl Scotland : valeur, flux et potentiel

image

Le niveau 1 n’a peut-être l’air de rien, mais on y parle déjà cycle TDD et flux !

Le second niveau correspond déjà à une maturité acquise par bien peu d’équipe. On y trouve pèle mêle une pensée produit épaulée par du Lean Canvas, du BDD, du Flux « end to end », donc avec du devops à la clé !

Au niveau 3, on trouve des choses bien plus rares telles que la maximisation de la valeur « infrastructure as code ».Et le seul élément que j’ignorais de la présentation : le Black Swan Coaching ! Plus curieusement, on y trouve le DDD que j’aurais mis personnellement au niveau 2 au maximum. Peut-être même au niveau 1 !

Le programme inclut un cocktail de cours, de workshops et de katas. Le tout épaulé par 3 coaches qui permettent de couvrir le spectre de compétences évoqué. Impressionnant !

<

Fin

Hélas, il n’était pas possible de tout voir. J’aurais par exemple aimé assister au retour d’expérience sur SAFE chez JC Decaux. Il s’agit d’un buzzword qui monte et il faut que j’en sache plus sur le sujet. Celui-ci au demeurant me semble complexe, trop pour être honnêtement agile et j’y perçois des reminiscences d’Unified Process… Qu’importe, il me faudra bien appréhender correctement ce dont il s’agit.

Agile Playground #16

L’Agile Playground ne se repose jamais … ou si peu ! Après une rencontre organisée mi-Juillet, on reprend nos bonnes habitudes dès mi-Septembre. Pierrick fait office de grand orchestrateur aujourd’hui. Et il nous propose un mode d’organisation inspiré de l’open-space, avec 2 catégories de propositions :

  • Les jeux que l’on souhaite proposer.
  • Les jeux auxquels on souhaiterait participer.

Le formule marche bien, nous recueillons quelques propositions, largement assez pour animer la soirée, pas trop pour ne pas être obligé de rentrer dans une gestion compliquée ! Voilà dejà une formule que l’on pourra rééditer !

image

Pour cette reprise nous étions un peu plus d’une trentaine de personnes, à vue d’oeil. Comme on dit lors des open-space : les personnes qui sont là sont les bonnes personnes !

image

Le « software ball » que propose Pierrick m’intrigue, ne serait-ce que par son nom : allons-y !

Le Software Ball

Le principe de ce jeu est simple et curieux et finalement pas si facile à saisir ! Les participants sont invités à se lancer une balle selon un schéma défini par le maître de jeu (nous ferons 5 itérations en complexifiant ce schéma). Pour exécuter cela, il faut « programmer » chaque participant avec des instructions en français à suivre très précisément. Elles sont inscrites sur des post-it que l’on colle sur soi.

A chaque itération, nous gagnons 10 points, moins le nombre d’instructions nécessaire pour programmer tout le dispositif (les instructions sont les verbes des phrases). C’est là que ça se gâte, n’est-ce pas ? Ce n’est pas fini ! On a droit au copier-coller et c’est gratuit ! Si 2 participants (ou plus) ont les mêmes instructions, on ne décompte que les instructions d’un seul participant. De même, si l’on garde des instructions entre 2 itérations, c’est aussi gratuit !

image

Bref, c’est quand même compliqué, vous pouvez toujours faire un tour sur le site du Software Ball. Pas mal de perte de temps au début : nous essayons un peu vainement de « bien » conceptualiser la chose avant de commencer. En fait, il est plus simple de se lancer et d’expérimenter sur le tas : nous nous lançons donc à deux pour commencer. Rapidement, après une paire d’itération, nous nous rendons compte que notre implémentation initiale génère des coûts exponentiels, car toute la complexité est sur le rôle du « lanceur-dispatcheur » qu’il faut réimplémenter à chaque fois ! Peitit moment de reflexion.

image

Nous galérons un peu pour passer du mode « push » au mode « pull » où les recepteurs appellent la balle et où il n’y a plus d’intelligence sur le dispatcheur. En effet, les règles stipulent de l’on ne peut pas faire de réutilisation partielle d’implémentation. Nous finissons par trouver le contournement !

Ce jeu a pour but de mettre le doigt sur des pratiques de Craftsmanship. En cela il est tout à fait original ! Il nous permet de reflechir à la réutilisation, au moment adéquat pour changer de stratégie et c’est franchement pas mal. Par contre il est frustrant sur le peu de libertés qu’il nous laisse pour faire des choix de cinématiques de circulation de balle. Je pense aussi qu’il devrait permettre la réutilisation partielle. En synthèse, voici le résultat du débrief.

image

Bref, j’ai bien envie de l’essayer, mais en hackant légèrement les règles !

La balle supersonique

Petite originalité de cette édition : un jeu frugal durant le buffet de fin ! Nous avons pu expérimenter une balle supersonique. Enfin, l’ayant déjà joué à Agile Game France, j’ai passé mon tour !

image

Mention spéciale à Julien qui l’a animé en n’ayant expérimenté la chose qu’une seule fois à Agile France. Il a d’ailleurs un peu hacké les règles en permettant de tenir la balle pendant qu’elle circule ! Je pense ne pas le suivre dans cette voie. Mais il bon d’essayer des choses. Voici de que cela donne

See you later

Toutes les bonnes choses ont une fin. Je coupe court à l’un de mes moments préférés : le buffet et la discussion qui terminent la soirée. Rendez-vous le mois prochain !

image

Agile France 2014, Bonus Track

Comme chaque année, il y a de nombreuses sessions que je n’ai pu voir. Je vais tenter d’y remédier en partie dans ce post.

Pour rappel les autres présentations, celles auxquelles j’ai assisté, sont couvertes ici et ici pour la journée du Jeudi. Elles sont ici et ici pour le Vendredi.

Projets Agiles, arrêtez les dérives

Cyrille Deruelle, en plus de sa présentation sur l’amélioration continue, a proposé ce sujet sur les projets agiles. Quelques clés et rappels pour ne pas pervertir nos pratiques et garder le cap sur ce qui est important.

Patrick Bobo a par ailleurs développé le contenu de cette session dans un post.

Comment Cadrer un projet agile ?

Pas de support pour la session de Guillaume Duquesnay et Jean-Claude Grosjean, mais un très bon post de Pascal Poussard !

Désapprendre à « bien faire », pour « faire juste à temps »

Le support est un peu déroutant, plutôt « zen » comme j’aime bien. Mais il n’aidera pas nécessairement à comprendre la substance du propos de François.

L’holacracy, un “système d’exploitation” pour des entreprises agiles et sociocratiques

Damien nous parle d’un nouveau mode de gouvernance des entreprises. Tout est dans le titre. Regardez le teaser pour voir si vous y voyez un sujet d’intérêt !

Son lightning talk a par ailleurs été enregistré.

Le support de la présentation de Damien est aussi accessible.

Si l’holocracy vous intéresse, vous pouvez consulter sa constitution.

Devenir une organisation apprenante dans l’IT

Eric Siber était absent, mais Nathaniel a présenté le sujet pour deux. Nathaniel nous parle durant cette session entretien et montée en compétence : comment faire ? Quel est le cadre légal ou ce que l’entreprise peut concéder ? Quels moyens se donner soi-même ?

Penser nos organisations

Pablo nous propose une session dont le moins que l’on puisse dire est que son teaser est décallé !

La présentation de pablo nous parle de communication, de théorie des catastrophe et de bien autre chose. Toutefois le support sans le « live » de Pablo n’est pas évident…

Doublures en folies

Le teaser d’Olivier Azeau n’est pas mal non plus, dans le genre décallé !

La présentation elle-même… eh bien, ce n’est pas vraiment une présentation, mais plutôt une scènette ! Bref, ça devait valoir le coup d’oeil en live !

Product ownership dans le brouillard

Ce n’est pas vraiment la première fois que Gilles nous gratifie de cette présentation. Mais elle est de bonne qualité

Vendredi matin…

Un petit coup de Pablo Pernot pour nous mettre en jambes…

Je veux tester avec les utilisateurs – Je fais comment ?

Je voulais au départ assister à l’atelier de Sophie Freiermuth, puis j’ai changé d’avis a dernier moment ! J’espère que ce n’est que partie remise. En attendant, voici son teaser.

Petits Outils de Management Agile à l’usage des… Honnêtes Managers!

Pas vraiment de teaser pour la session de Jean-Claude en mode « show and tell » ! Mais il l’introduit néanmoins sur son blog.

Par ailleurs je vous recommande ce billet de blog qui en parle.

Lean Agile Camp

Dominique de Prémorel évoque l’élaboration du « petit guide du management lean » lors du Lean Agile Camp

Expérience d’un maître de donjons et dragons sur le management, ou comment trouver son style

Pas de support de présentation pour la session de Guillaume Duquesnay, mais un excellent billet de blog !

La culture du programmeur

Jean-Laurent de Morlhon nous avait déjà gratifié de cette présentation très dynamique au Scrum Day. En voici la présentation

Mon projet est plus gros que le tien

Seulement le teaser pour la présentation de Cyrille : désolé !

Retour d’expérience sur Coding Dojo et Mob Progamming en entreprise

Sujet à la mode s’il en est, Bernard Notariani évoque le coding dojo mais surtout le Mob Programming, le dernière tendance. Voici son teaser

Au secours, le Père Noël a perdu ses rennes !

Simon Jallais nous propose une session créative autour du thème du Père Noël. A la lecture du support, je n’ai rien compris ! Ferez-vous mieux que moi ?

Let’s sketch together

Cette session d’Alvin était également présente au ScrumDay 2014. En voici le support

On en parle aussi ailleurs

Sans avoir relevé tous les blogs parlant d’Agile France (loin s’en faut), en voici quelques uns :