Ma gallerie de photo lors d’Agile France 2013
agile-france, un album sur Flickr.
Étiquette : enImages
Scrum Boat 2013, dernière partie (en images)
Retour au Scrum Boat !
Dans un premier post, je vous avais montré quelques images de la première partie de soirée ; passons à la suite.
Courte pause avant le second atelier.
La poupe du navire est un endroit très apprécié, on a plutôt de la chance avec la météo aujourd’hui…
Sure le premier pont, on est désormais plus en mode “networking” qu’en Open-Space. Cela fait aussi partie des raisons pour lesquelles on vient aux rendez-vous du SG.
Premier atelier de seconde partie : SOS Titanic, avec Philippe Houssin et Xavier Warzee
Le soleil rasant complique terriblement la prise de vue. J’ai aussi passé pas mal de temps à échanger sur cette seconde partie, donc moins de photos !
Voir Philippe Houssin à l’oeuvre, c’est toujours assez impressionnant. Ou comment le physique donne des informations sur le mental…
Parallèlement, Michel Zam nous proposait une session sur l’expérience utilisateur avec le DDD.
Assistance curieuse et attentive ici aussi
Pendant ce temps, en bas ça picole sec !
Fini les ateliers, on lève l’ancre. Une ballade sur la Seine pour terminer la soirée : l’air est doux, la nuit éclairée de mille feux. Quoi d’autre ?
Ah oui, peut-être aussi un verre de Champagne !
Les fresques du quai de Seine
Le Musée d’Orsay
Dernière vue sur la Seine
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.`
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 !
Agile Playground #8 (en images) !
Pour changer un peu, l’Agile Playground de ce mois ne déroulait pas chez Valtech, mais dans les locaux de CLT Services. Un espace un peu plus réduit, donc une contrainte de places plus importante. Elle avait été fixée à une trentaine de personnes. Je m’étais dépêché de m’inscrire. Youpi, tant pis pour les autres …
3 jeux étaient en lice. J’avais fixé mon choix sur celui de Yannick Ameur
Atelier RH Team
Comment recruter agile ? Peut-on recruter agile ?
Yannick était ce soir-là le maitre de cérémonie pour ce défi !
Votre mission, si vous l’acceptez consiste à créer la fiche poste de votre job que l’on va afficher et trier.
S’en suivent les entretiens avec les candidats. Tout d’abord en mode “old school”. Avec vôtre serviteur pour être honnête… Puis en mode “agile” en faisant participer toute l’équipe.
Après, c’est le débriefing et les leçons tirées de l’exercice.
Yannick nous fait le plaisir de mettre à notre disposition le support servant de trame à l’atelier. Le voici donc.
Cocktail
On termine comme à l’acoutumée autour d’un verre et de longues discussions qui nous font toujours rentrer bien tard dans nos penates !
Nos discussions ont pas mal tourné autour du coaching : qu’est-ce qu’un coach agile ? Est-ce un coach sportif, un coach miroir “posture basse”, un expert, un mentor, etc… ou un mixte de ces différents rôles ? Le question est trop large pour que je m’étende dessus aujourd’hui. Un autre jour peut-être dans ces colonnes …
Retours sur Agile France 2013, 3ème partie (en images)
Après avoir couvert le début de matinée et le milieu de journée, il est temps de nous intéresser à la fin de cette première journée de conférence.
On commence par un Lightning Talk. Ou ce qui aurait dû être un lightning talk, car il est joyeusement passé de 15 minutes à 25 ! Mais c’est sans importance. C’était intéressant.
Egor Sviridenko – Je vois !
Ou comment la visualisation non conventionnelle contribue à des projets agiles
Une bonne visualisation fait la différence et permet de mettre en évidence une information importante qui sinon resterait cachée.
La visualisation par l’exemple
Pour illustrer cela, Egor nous parle de l’épidémie de choléra à Londres en 1854. En quelques semaines cette épidémie fit des centaines de victimes. Le mode de transmission de cette maladie n’était pas encore connu à cette époque (on pensait à tord qu’il s’agissait d’une transmission aérienne).
Les autorités se sont révélées incapables d’endiguer l’épidémie, jusqu’à ce qu’un médecin, John Snow, ait l’idée de reporter le nombre de personnes atteintes sur une carte. Cela permit d’abord de délimiter l’extension de l’épidémie, puis d’en localiser l’épicentre. Et enfin d’en déterminer la cause probable : une pompe à eau dont John Snow obtiendra le démontage de la poignée, mettant ainsi un terme à l’épidémie !
La visualisation permet de rendre mieux interprêtable des informations. Encore faut-il utiliser la représentation adaptée !
D’autres visualisations
Egor a regroupé les principes de visualisation en 4 familles. Nous venons d’en voir la première : les cartes.
Si l’utilité de la carte dréssée par John Snow est indéniable, les données y sont superposées de manière plutôt classique. Mr Minard a utilisé une représentation bien plus originale afin de stigmatiser le désastre de la campagne de Russie de Napoléon 1er.
Les réseaux permettent de représenter des informations corrélées entre elles. McLaren utilise un backlog converti en mindmap afin de déterminer les évolutions à réaliser sur ses logiciels embarqués. Comme vous pourrez le voir sur le support de présentation, c’est assez impressionnant. A mon grand étonnement, ils paraissent être capables de s’en servir !
Les timelines permettent de construire des histoires où l’on voir l’évolution d’un ou plusieurs facteurs au fil du temps. La timeline du “seigneur des anneaux” nous permet d’appréhender les tribulations des personnages, leurs séparations et leurs rencontres. Celle de Jurassic Park nous montre que les différents personnages se font bouffer au fur et à mesure de l’intrigue. Mais ça on le savait déjà.
La représentation à plusieurs variables permet de représenter des facteurs non corrélés sur une même représentation. Un exercice dans lequel il est préférable de se restreindre afin de ne pas rendre cette visualisation illisible. Le Kanban que nous utilisons de plus en plus sur nos projets agiles rentre dans cette catégorie.
Je ne saurais trop vous recommander le support de présentation d’Egor : il regorge littéralement d’exemples de ces visualisations. Rien ne saurait être plus parlant !
Conclusions et conseil de lecture
Quel est la qualité principale d’une bonne représentation ? Elle doit raconter une histoire !
Un conseil de lecture principal :
- Envisionning Information d’Edward Tufte
-
Semiology of Graphics, par Jacques Bertin et William Berg
Antoine Contal – Coacher des managers
Sur mon premier compte-rendu, j’avais évoqué 4 orateurs que je vais systématiquement écouter. Mon carré d’as en quelque sorte. Le premier était Pascal Van Cauwenberghe, Antoine est le suivant. Vous découvrirez les deux autres lors de la seconde journée.
L’heure est grave ! De nombreuses équipes améliorent leur façon de faire et leur productivité, et ce qui les handicapent, c’est parfois le management intermédiaire, celui qui devrait au contraire les aider à être plus efficaces ! Comment changer cela ?
Le management au quotidien
En Lean, on commence toujours par aller observer. Donc, il faut aller voir la bête dans son habitat naturel. Celui-ci se trouve en deux endroits principaux :
- Son bureau
- La salle de réunion
Quelle sont ses activités principales ?
- Avaler et produire des rapports
- Assigner des tâches
- Eteindre des incendies
Ah ! Nous allions oublier son péché mignon : entamer des projets pharaoniques. Ce qu’en Lean on appelle des “ultrasolutions”.
L’idéal du management
En Lean, celui-ci se construit autour d’un certain nombre de valeurs et de principes.
- L’amélioration continue : Le Kaisen. C’est progresser à petits pas en construisant des expérimentations.
- Le Genchi Gembutsu : retourner sur le terrain, pour se baser sur des faits, plutôt que sur des opinions (ce qui est souvent le cas du travail fait en salle de réunion).
- Construire des challenges : oser rêver l’idéal. Motiver par rapport à l’excellence. Le but est de créer l’adhésion, mais aussi de placer la barre haut afin de faire progresser.
- Respect des personnes : croire dans le potentiel des personnes. Comprendre que les problèmes sont personnalisés et doivent donner lieu à un apprentissage.
- Teamwork : savoir travailler et collaborer au-delà des frontières organisationnelles.
Pour Antoine Contal, le manager Lean est à la fois un chercheur et un entraineur sportif !
Comment réussir en sachant ce qui rate
- Les critères de réussite : ils doivent être clairs. On peut coacher une équipe de développement sans définir clairement ce qu’est le succès et s’en tirer. Ce n’est pas possible avec des managers !
- Etre sur un mauvais sujet. Par exemple : améliorer le délai de production des rapports d’activité !
- Etre purement dans l’humain.
C’est bien d’avoir une idée de comment rater, mais c’est mieux si l’on a une idée de comment contrer ces travers.
- Il faut définir le succès proprement. Il n’y a pas de raccourcis par rapport à cette étape. Le faire c’est déjà du coaching !
- Choisir les bon sujets. Comment ? Ce sont ceux qui sont bon pour le manager et pour les équipes !
Le coaching fonctionne si la performance et les conditions de travail des équipes s’améliorent.
Petits exercices
Antoine Contal nous en propose 3.
Exercice 1 : Ecouter l’utilisateur
On en revient à la question de la valeur.
L’orateur illustre cela avec un manager confronté à un usager d’une application pour laquelle un lourd projet vient de se terminer. A la question “que pensez-vous des nouvelles fonctionnalités ?” ce dernier répond … “oh ! Elles ne me gênent pas…”.
Las, l’histoire se termine mal : le manager ne fera rien par rapport à cela et finira par être remplacé !
Exercice 2 : Définir la performance
Cela passe par la mise en place d’indicateurs (lead time, en cours, stock), d’enquêtes de satisfaction.
Le rôle du management intermédiaire est aussi de reconnecter l’opérationnel avec la stratégie. Antoine évoque pour nous l’histoire de cet urbaniste SI qui découvre que ses indicateurs d’urbanisation ne sont pas ce qu’il croit simplement parce que les cellules opérationnelles en charge d’arrêter les systèmes remplacées (et qui ne dépendent pas de lui) ne l’ont pas fait !
Exercice 3 : Aller voir
Encore et toujours aller sur le terrain. Pas seulement celui des utilisateurs, mais aussi celui des équipes de développement pour identifier ce qui nuit à leur travail.
“Comment je fais…”
Pour l’orateur, le rôle de coach de managers est un rôle de coach sportif !
Le manager est passé d’une situation où il accomplit son travail dans son bureau ou dans les salles de réunion à une situation où il est présent sur le terrain, pour voir ce qui se passe.
Le coach fait s’enchainer les exercices d’entrainements faits sur mesure, afin d’adresser les points où il s’y prend mal, ce qu’il doit apprendre.
Une session de coaching typique se découpe ainsi :
- 30 minute : préparation ; où allons-nous, que voulons-nous tester.
- 1h30 : Aller sur le terrain ; le manager doit apprendre à voir. Le coach reste silencieux, observe et prend des notes (pour le débrief). Il se permet une et une seule question !
- 1h : Debrief ; Qu’avons-nous vu ou pas ? Que doit améliorer le manager. Que doit-il répéter avant la prochaine session.
Typiquement, le rythme est d’une ou deux sessions par mois.
L’ingrédient secret duu coach Lean, ce sont les “3 R” :
- Relate : c’est la relation interpersonnellle que le coach doit construire avec le manager. Celui-ci doit apprendre à faire confiance à son coach.
- Repeat : Faire répéter le même geste, encore et encore.
- Reframe : Le coach donne “une autre lecture” de ce que le coaché a vu.
A vous de jouer
Pour synthétiser, quel doit être le rôle du manager ?
- C’est “l’étoile du nord” des équipes de développement.
- On fait progresser le manager en lui donnant de “petits exercices”.
- La manager doit devenir un développeur de talents.
Une dernière chose : Il est rare que la demande de coaching de manager soit formalisée ou même demandée. Si la nécessité apparait, Antoine utilise le mode “stealth” et intègre cela au coaching de l’équipe !
Ce que j’en ai pensé
Difficile de rendre justice à la présentation d’Antoine par un simple compte rendu. Disons que, malgré le nombre appréciable de présentations de bonne qualité auxquelles j’ai assisté, c’est pour moi le point fort de cet Agile France 2013 !
Antoine Contal ne garde rien pour lui dans ses présentations. Son niveau de maturité fait qu’il est assez à l’aise pour procéder ainsi. On repart avec pas mal d’éléments à mettre en oeuvre, des éléments de reflexion pour nous faire progresser. En fait, comme disent les jeunes j’ai toujours un peu l’impression de “prendre cher” avec les présentations d’Antoine et de son comparse. Pourtant j’y retourne. Comme il l’a si bien dit, il place la barre haut et c’est grâce à cela que l’on progresse. C’est un peu déprimant pour moi de voir la marge de progression qu’il me reste, j’ai l’impression d’avoir si peu progressé, de rater tellement de choses … Mais nul doute que nous avons besoin de personnes du niveau d’excellence et de maturité d’Antoine pour nous y aider.
Lectures recommandées
- Déployez vos stratégies Lean par Pascal Dennis
- La pratique du Lean Management dans l’IT, par Marie-Pia et Christian Ignace, Antoine Contal et Régis Médina
- Change or Die, d’Alan Deutschman
Autres resources :
- European Lean IT summit
- Institut Lean France.
- CES Lean Management (Telecom ParisTech).
- Le compte rendu d’Olivier Le Lan (meilleur que le mien) sur le blog de Soat.
- Sébastien Bonvoisin a aussi publié un retour sur le blog de Novedia où figure la session d’Antoine.
Pascal Van Cauwenberghe et Pierre Hervouet – Vous pouvez ignorer les contrôleurs de gestion, les contrôleurs de gestion eux ne vous ignoreront pas !
L’agilité, c’est l’adaptation au besoin, l’émergence du changement ! Mais bon, une entreprise a quand même besoin de savoir où aller et surtout de savoir où va son argent. Alors, on peut dire que l’on se focalise sur la valeur, des gens ont besoin de se focaliser sur les dépenses. Ces gens sont le contrôleurs de gestion. On les connait à peine, on les ignore (peut-être même les méprisent-on) le plus souvent. Ce n’est pas raisonnable.
Pascal et Pierre viennent nous faire prendre conscience de cette dure réalité. Nous allons suivre pour cela les pas de Dora l’exploratrice (en plus de ceux de Pascal et Pierre) !
Cost accounting
Puisque l’on est en atelier, on va se mettre aux travaux pratiques. Des travaux pratiques bien sympathiques, car on va préparer des cocktails ! On mélange des ingrédients, on a 2 tailles de cocktails et il faut calculer le coût de chacun.
Le cost accounting, c’est comme faire des cockatils (mais on a pas le droit de l’avouer). On a des ingrédients (des centres de coûts) et il faut les saupoudrer sur des lignes budgétaires !
C’est une approche analytique détaillée qui est très précise … mais précise ne veut pas dire exacte. En fait la ventilation de coûts comme les frais généraux peut montrer les faits sous des jours différents selon la façon dont on l’opère.
Attention ! On ne peut échaper complètement à cette approche, car c’est celle qui est de toute façon demandée règlementairement par les services publics.
Dernier travers du “cost accounting” : les stratégies budgétaires tendent à emmener ce type de gestion vers une sorte de “cycle en V” de la gestion budgétaire. C’est comme ça que l’on se retrouve à préparer le budget de l’année suivant dès le mois de Juillet !
Throughput Accounting
Ce mode de gestion prend un angle différent : celui de gérer l’investissement en fonction des goulots d’étranglement ! C’est une sorte de vue systémique de l’investissement.
L’un des avantages par rapport au cost accounting : c’est de sortir du cycle en V ! Mais ce n’est pas encore parfait, car l’investissement n’est pas rapproché de la valeur du flux auquel il est subordonné.
Lean Accounting
Le Lean Accounting adresse ce dernier reproche. Ici, le point de départ est la valeur client, ce qui va déterminer un prix au produit. En fonction de celui-ci on décide de la marge, donc du coût ! C’est le “target costing”. Pierre et Pascal semblent confiants sur l’approche, mais j’ai quand même l’impression que ça peut vite tourner à la quadrature du cercle…
Un autre point différenciateur important, c’est que le contrôleur de gestion lean fait partie de l’équipe !
Beyond Budgeting
Cette approche est plus difficile à appréhender, plus proche de l’agilité tel que nous l’entendons (donc plus intéressante, il faut donc que j’y travaille). Elle s’appuie sur 12 principes qu je ne vais pas répéter ici, car ils figurent dans le “hands out” ci-dessous.
L’idée est de sortir des comportements biaisés introduits par le contrôle de gestion.
Ce que j’en ai pensé
Nous avons tout un univers à explorer ici.
Les références bibliographiques du hands-out lèvent un coin du voile. Hélas cette session est un peu courte pour vraiment nous permettre de saisir les 4 approches. Elles montrent, dans leur progression, une “agilification” croissante des concepts. C’est excellent ! J’ai un peu l’impression cependant que ces concepts m’ont filé entre les doigts. Il faudrait que je révise.
L’idée de faire un atelier est excellente. Et le cocktail pour le “cost accounting” a bien marché. Hélas le côté atelier s’est arrêté ici. Il faudrait imaginer la suite des exercices pour chacune des 4 étapes…
Comme je l’ai dit : c’est relativement nouveau pour moi … mais aussi important. Je ne regrette pas d’avoir choisi cet atelier.
A demain !
Une journée bien remplie, comme vous avez pu le voir. Il est temps de cloturer celle-ci
A très bientôt pour la journée de Vendredi !
Retours sur Agile France 2013, 2nd partie (en images)
Nous avons évoqué, il y a peu le début de matinée de la conférence Agile France 2013. Il est temps de reprendre notre bâton de pellerin et de poursuivre plus avant.
Mais avant cela, j’aimerais saleur l’équipe d’organisation. Je n’ai pu les prendre en photo tous. En fait, c’est la photo que j’ai où ils figurent !
Grand merci à Eric, Ellène, Stéphanie, Caroline, Damien, Jonathan et Frédéric. Ils essaient tant de se faire discrets qu’il est difficile d’avoir la liste exacte !
Je dois vous avouer une chose : il y a certains orateurs que j’essaie de voir coûte que coûte. Je ne regarde pas le résumé de leur session, en fait je n’en regarde même pas le titre. Je viens sans me poser de question et je n’ai jamais été déçu. Quatre d’entre eux étaient présents sur ces 2 jours, bien répartis : 2 le Jeudi et 2 le vendredi. Coup de chance, pas de chevauchement entre leurs sessions. Vous découvrirez les autres plus tard, mais Pascal est l’un d’entre-eux.
Pascal Van Cauwenberghe : Real options
Quand et comment (ne pas) prendre des décisions
Les options réelles sont le pendant des options financières. Elles permettent :
- D’exercer un décision à une date future
- C’est un droit (et non un devoir) d’exercer ce choix à cette date future.
- Ce droit s’achète cash à l’instant présent (c’est la prime).
- L’exercice de l’option s’accompagne d’un coût (le prix de l’option) et d’un bénéfice éventuel.
Pour illustrer tout cela, Pascal va nous raconter des histoires. Il y en aura 3.
Un choix de design embarrassant
Notre première histoire nous emène dans le monde du jeu video en ligne pour les enfants. La date de sortie est fixée, la période de Noel est cruciale, on ne saurait la rater. Le contenu du jeu est à peu près dans les rails. Mais les créatifs veulent changer d’identité visuelle, mais ils ne sont pas sûrs, mais…
C’est là que rentrent en compte les options réelles : on veut pouvoir décider aussi tard que possible. Mais cela a un prix.
Ici, l’idée consiste à rendre la décision facile à changer. Le prix est donc un refactoring permettant un changement facile du design. Ce prix nous donne droit de retarder le moment ou il faudra arrêter la décision définitive. Une leçon importante à retenir :
Il faut payer le prix pour des options qui ont de la valeur.
Cette démarche débouche sur plusieurs conséquences :
- La réalisation des tranches fonctionnelles est pensée en terme de rétro-planning par rapport à la date à laquelle on doit opérer le changement de design.
- Une question pour le développement : est-on obligé d’appliquer le design dès le début ? En fait non. Le développement sera entièrement fait en noir et blanc. En fait, cette situation embarassante aura débouché sur une évolution du processus de développement: dorénavant, tous les développement seront fait en noir et blanc avec application du design à la fin !
- Nécessité de traquer l’évolution de cette option toutes les deux semaines afin de voir si on dispose de plus d’information quand à son exercice ou non.
Le processus de suivi de ces options est le Real Options Optimal Decision Process décrit dans le livre Commitment.
Set-based development
Dans ce second projet, le challenge est différent : un service doit être développé, le temps est critique (comme toujours). Hélas le choix de la plateforme n’est pas encore arrêté. Mais on ne peut se permettre de mettre le projet en stand-by en attendant ce choix, le projet est trop critique !
Comment faire ?
Il suffit d’implémenter toutes les options ! En clair cela signifie :
- Faire le développement sur des API isolant la plateforme. Ces API sont mises en places au fur et à mesure de l’avancement du projet.
- Opérer parallèlement l’implémentation de ces APIs sur toutes les plateformes qui forment l’ensemble de nos option (deux dans le cas présent)
Un effet de bord positif est que cette approche simplifie le test du service, car parallèlement on va implémenter un “test server” qui est en fait un “mock” de la plateforme.
Plus tard le choix de la plateforme est arrêté. On se focalise alors sur l’une des implémentations de l’API.
L’histoire ne s’arrête pas là. Par le jeu des fusions / acquisitions d’éditeurs, l’éditeur de le seconde plateforme rachètera la plateforme A … et demandera à ses clients de migrer vers la plateforme B. Le Set-Based design rendra cela facile !
Plus tard, cet éditeur B sera lui-même … vous m’avez compris !
Une histoire d’intégration
La troisième histoire est celle d’un projet en retard. Le retard est déjà de 3 mois, il en faut encore 6 ! Arrêter ou poursuivre ?
Il y a des décisions à prendre, et celles-ci ne doivent pas tenir compte de l’investissement déjà réalisé : il faut le considérer comme perdu. C’est le Sunk Cost Fallacy. On a pratiquement toujours tendance à surestimer la valeur de ce que l’on a. La valeur n’est pas le coût.
Une histoire d’EDI, une question d’architecture
L’EDI permet d’interconnecter des vendeurs et des fabricants. De chaque côté de la plateforme, vendeurs et fabricants doivent implémenter l’API avant que l’éditeur customise celle-ci.
Malheureusement pour chaque partie prenante, l’implementation de l’API est un gros projet, donc subordonné aux retards qui sont le lot des gros projets. Comme la customisation de la plateforme est tributaire de l’implémentation des API de chaque côté, la planification de ce travail ne sert à rien !
L’intégration dure longtemps, car elle est conséquente et n’intervient qu’une fois que chacun a fait son travail. Que faire ?
Ne plus faire de gros projets ! Au lieu de mettre en production toute une connexion vendeur / fabricant, ne peut-on déployer flux par flux ? Les objets métiers nécessaires à ces flux seront développés de manièreincrémentale, et seulement ceux dont on a besoin pour le flux en cours. Par contre ils pourront être réutilisés pour les flux suivants.
Pour Pascal, changer d’architecture, de plateforme ou de langage implique les points suivants:
- Faire un prototype pour maitriser le concept ou la technologie.
- Commencer par les aspects les moins critiques.
- Garder l’ancien composant.
- Opérer un déploiement incrémental.
Vous l’aurez peut-être remarqué, cela rejoint certains points de la présentation de Cyrille Martraire (voir mes retours dans la 1ère partie).
Avec l’éclairage des options, Pacal nous soumet ce qu’il juge être les vertus d’une bonne architecture :
- Elle doit nous permettre de prendre tôt les décisions faciles à changer.
- Elle doit permettre de prendre tard les décisions difficile à changer. Ou encore : rendre les décisions difficiles à changer pour qu’elles deviennent faciles à changer !
- Elle permet l’effort minimal, c’est le YAGNI d’extreme programming.
- Elle créé des options pour l’équipe et/ou pour l’entreprise.
- Elle se construit et s’améliore tous les jours, à petits pas. Sinon, on crée du legacy !
Il ne faut pas mésestimer la valeur des conditions contrariantes que l’on nous impose. Elles nous servent et nous apprennent souvent quelque chose.
Dans les mauvaises décisions se cachent de bonnes décisions.
Les techniques utiles
Une simple liste des techniques et principes abordées dans cette session :
- Cost of Delay
- Creative Process
- Real Options
- Optimal Decision Process
- Séparation de la variation
- Set-based design
- Sunk Cost Fallacy
- Créer des options pour nos clients
Pascal avait déjà donné cette présentation lors de Devoxx France, fin Mars. Voici le support de présentation qu’il avait alors utilisé. Le contenu est identique à la présentation faite ici.
Lectures recommandées
- Creativity today, par Ramon Vullings et Godelieve Spaas
- Commitment, par Olav Maassen, Chris Matts & Chris Geary
- The principles of product development Flow, par Donald Reinertsen
- Predictably Irrational, par Dan Ariely
Pierre Pezziardi – Agilité : do the wrong thing faster
Pierre Pezziardi n’est pas n’importe qui : co-fondateur d’Octo Technology, puis DSI de la BRED, puis actuellement start-uper, on peut dire qu’il a de l’envergure. C’est aussi un orateur de grande qualité, comme j’avais pu le constater lors d’une soirée organisée par l’institut agile : pertinent, incisif, riche d’enseignements. Je n’ai donc pas vraiment hésité à aller l’écouter.
Sans aller jusqu’à m’avouer déçu, je dois dire que la session a été un peu en-deça de mes attentes. L’orateur a voulu cette session interactive, ce qui est en principe une bonne chose. Peut-être les interventions de la salle plus souvent conotées “coach / consultant” que “retour terrain” ont-elles participé à cette impression mitigée ? Honnêtement, j’ai un peu de mal à le dire.
Plutôt que de tenter retracer cette session (ce que je serais bien en peine de faire), je vais plus simplement livrer mon “take away” de cette session.
On peut faire de l’informatique et créer zéro valeur
Qui décide quel projet faire ?
A quel point les vrais utilisateurs sont impliqués ?
Le logiciel qui est produit va-t-il faire la différence chez les utilisateurs ? Hélas pas si souvent que ça…
L’unique mesure de la valeur, c’est le regard de l’usager
Des applications en pré-production que les utilisateurs détournent pour un usage en production. Des utilisateurs déclarant que l’application X a changé leur façon de travailler ou qu’elle leur permet de consacrer leur temps à des tâches plus valorisantes…
Des exemples venus de l’assistance ont permi d’illustrer ce point.
La pensée systémique est différente de la pensée analytique
Pierre a évoqué des grands projets publiques permettant des améliorations … pour une catégorie de population, hélas au prix de plus de souffrances pour d’autres population !
Apporter de la valeur ne doit pas se mesurer localement, il faut prendre en compte l’ensemble de l’écosystème concerné, donc avoir une approche systémique par opposition à l’approche purement analytique.
Etre acteur du changement
Sommes-nous trop petits, trop insignifiants pour pouvoir changer les choses. La réponse de Pierre est claire : Non ! Pierre est engagé dans une démarche entrepreunariale pour changer les choses, mais tout le monde n’est pas dans cette logique là. Et l’on peut tenter des choses, même petites pour les améliorer. Par exemple en collaborant avec des personnes au-delà des frontières organisationnelles. Je citerais Pierre concernant l’alternative:
Tu peux rester où tu es à te plaindre et à souffrir. Dans ce cas, bonne chance car t’as encore 30 ans à tirer !
Je ne rends pas justice à Pierre avec mes notes, car son intervention était bien plus intéressante qu’il n’y parait ici. Soyez certain que je retournerais l’écouter quand j’en aurais l’occasion !
A table !
On est toujours bien reçu à Agile France, et déjeuner autour d’une table avec un vrai repas et un service tranche avec les conférences auxquelles nous sommes habitués. Et puis, ça a de la gueule, jugez-en !
Bien sûr, ce moment de convivialité est l’occasion de nouer des contacts. N’esperez-pas que je vous en dise plus : ça va rester entre moi en mon LinkedIn !
Fin de la pause, retour aux affaires. Ca va parler coaching pour débuter l’après-midi
Jean-François Hélie : Votre nouveau défi, déployer l’agilité dans votre organisation
Votre organisation est-elle agile ?
A cette question on est souvent tenté de répondre “oui” (de toute façon, répondre “non” fait désordre). Souvent parce que l’on a déployé Scrum sur un, plusieurs, voir la totalité des projets. Généralement, ça marche un peu mieux qu’avant. Mais on est loin des améliorations radicales escomptées.
Voyons la démarche que Jean-François Hélie nous propose.
Opérer des rapprochements
Si on peut juger de seulement une “petite” amélioration, force est de constater que certains projets stratégiques marchent nettement mieux. Pourquoi ? Essentiellement parce que leur nature stratégique fait qu’ils ont moins de contraintes. Ils ont d’avantage le droit de franchir les frontières organisationnelles.
Tout cela est insuffisant, mais ces projets stratégiques nous donnent des indications :
- Trop de cloisonnement interne DSI / Marketing / Métier
- Pas de remise en cause fondamentale du processus projet
- L’agilité reste cantonnée au niveau de la réalisation
- Les projets sont mal cadrés et démarrent trop vite.
Sur ce dernier point, enfin tel qu’il est exprimé, je crains de ne pas être d’accord sur le fond. Je pense que Lean Startup a quelque chose à nous enseigner de ce côté. Sans doute devrais-je discuter avec Jean-François précisément là-dessus…
La difficulté fondamentale à faire tomber les cloisonnements a hélas une origine plus profonde.
Comprendre la culture
Comprendre les organisations, c’est comprendre leur culture. Celle-ci est étroitement liée aux niveaux de maturité :
- De l’équipe
- De l’organisation
Comme on aime bien les modèles, Jean-François nous propose celui de Richard Barett qui décrit 7 niveaux de conscience. Ce modèle étend en fait la célèbre pyramide de Maslow. La voici.
Pour Jean-François Hélie, l’agilité se situe au niveau 4, les niveaux au-dessus sont, disons, du bonus ! Pour arriver à ce niveau, 2 challenges :
- La manager doit devenir facilitateur
- L’ambition agile : comment se réaliser individuellement, en interaction avec les autres ?
Conjuguer le changement au présent
Jean-François n’a pas d’hésitation à ce propos : Le changement ne s’opère pas en planifiant ce qu’on pourra faire plus tard. Pas plus qu’il ne se construit en regardant ce que l’on a fait dans le passé. L’un sert à rêver, l’autre à se lamenter.
Seul compte l’instant présent, ce que l’on peut faire dans le contexte actuel.
Autre point important : le changement culturel s’amorce par le haut de la pyramide. En fait la dynamique des comités de direction reflète celle de la société.
- Un comité de direction hésitant, qui ne sait dans quel direction aller donnera une société où les employés sont peu engagés et n’osent pas aller de l’avant.
- Un comité de direction energique et focalisé engendrera une société dynamique avec des employés volontaires.
D’accord, c’est peut-être un peu caricatural, mais c’est l’idée.
Pour changer les projets, changeons les réunions
C’est le “take away” de cette session. Jean-François Hélie veut partager une de ses convictions avec nous et nous propose ses outils. A l’image de ce que l’on vient de dire pour les comités de direction, les réunions de projet sont le poul du projet.
A l’inverse, on peut agir sur un projet en agissant sur la dynamique des réunions ! Une idée un peu déconcertante pour moi, mais intéressante. En tout cas, je n’y avais jamais pensé. Voyons comment réunions et projets sont les reflets l’un de l’autre :
- La participation en réunion : Elle reflète l’energie et la motivation sur le projet.
- La gestion du temps en réunion : Elle caractérise la façon dont est appréhendé le respect des délais.
- La relation à l’animateur : Elle est un indicateur du respect de la hiérarchie.
- La gestion des l’espace de la salle de réunion : Elle donne des informations sur les stratégies territoriales des uns et des autres.
- Le processus de communication au cours de la réunion : Elle est un miroir des circuits d’information (qui parle après qui, etc..)
- Le désir de quitter la réunion ave un résultat : Il est significatif de ce que peut délivrer le projet.
Pour amorcer les changements en réunion, le premier pas est la prise de conscience à la fin de celle-ci :
- Qu’est-ce qui a bien fonctionné ?
- Qu’est-ce qu’on peut améliorer ?
- Qu’est-ce que l’animateur a bien fait ?
Dans la plupart des réunions “classiques” l’animateur de la réunion :
- Définit l’objectif de la réunion
- Dirige la discussion
- Recadre celle-ci
- Et la plupart du temps monopolise 80% du temps de parole.
Cela n’est pas très constructif, et en réalité ce genre de réunion est surtout informatif. Les autres participants ne sont pas engagés et en fait participent peu. D’où la généralisation des ordinateurs portables en réunion.
Lorsque l’animateur gère la réunion en mode participatif, les différences sont :
- L’animateur invite les participants à prendre la parole
- L’animateur ne garde le temps de parole que 20% du temps.
Dans la version Intelligence Collective (le nirvana des réunions, en quelque sorte), les rôles deviennent distribués :
- Un facilitateur qui invite à participer et délègue les rôles.
- Un pousse-décision qui suit les actions arrêtées et incite les participants à conclure une discussion par une action.
- Un gardien du temps.
- Un “meta” qui observe la dynamique du groupe et la posture des participants
- Un leader. C’est toujours un peu le même, celui qui a une autorité naturelle sur le groupe du fait de son charisme ou de sa connaissance du sujet.
Déployer l’agilité dans l’organisation
Jean-François Hélie voit deux approches possibles :
L’approche structurelle : Elle débouche sur de grands efforts pour de petits effets.
L’approche culturelle et systémique : Elle permet d’obtenir de grands effets avec de petits efforts. Pour en résumer les clés :
- Ne pas chercher à changer la culture en elle-même.
- Changer la culture dans les réunions
- Créer et partager une vision
- Faire participer les collaborateurs
Et c’est tout !
Lecture recommandée
Un seul ouvrage ici :
- Coaching d’équipe, par Michel Moral
A suivre…
Nous avons bien avancé dans notre première journée, il nous reste 2 sessions pour la compléter. A très bientôt !
Retours sur Agile France 2013, 1ère partie (en images)
J’avais fait l’impasse sur l’édition 2012, je suis revenu pour l’édition 2013. Cette année encore Agile France promettait un programme attrayant : promesse tenue ! Le “take away” de ces 2 jours de conférences ne rentre guère dans mon sac à dos, c’est un semi-remorque qu’il va me falloir. Une fois de plus, je vais vous distiller cela en plusieurs parties.
Place à l’action, ou plus précisément à la première session de la journée.
Peter Stevens : From Value to Values
Why management has to change and how IT is inspiring the solution
Nous étions quelques un à avoir eu l’occasion de croiser Peter Stevens lors d’une Scrum Beer il y a environ 2 ans. Cette fois, il nous faisait la keynote de la conférence et venait nous parler du Stoos Network. J’avais une première fois évoqué ce mouvement à l’annonce du Stoos Connect, puis plus récemment pour parler du Stoos Satellite Paris.
C’est bien du Stoos Network dont Peter Stevens est venu nous parler. Selon lui, le monde se divise en 2 types de sociétés:
- Celles qui enchantent leurs clients.
- Les autres.
Vu comme ça, c’est un peu simpliste. Creusons un peu. Aujourd’hui, les compagnies ayant un fort “focus client” sont celles qui gagnent de l’argent. Car il n’a jamais été aussi facile de changer de fournisseur ou de service. Votre service de téléphonie ne vous plait plus, résiliez-le dès aujourd’hui pour prendre un nouveau plan ! Il y a 30 ans, Peter Stevens nous confiait qu’en Suisse, un abonnement téléphonique nécessitait un dépot de garantie équivalent à un demi-mois de salaire ! Nous avons donc changé de logique :
- Autrefois : “you take what we make”.
- Aujourd’hui : “I choose what I want”.
Pour autant, ce changement de polarité ne s’est pas accompagné d’un changement de paradigme dans la logique de l’entreprise.
L’entreprise moderne continue de choisir son cap en fonction des dividendes qu’elle peut reverser à ses actionnaires. C’est une logique qui n’est en fait pas celle permettant d’obtenir les meilleurs résultats car elle part du mauvais point.
Pour enchanter le client, il faut augmenter la vitesse de réactivité, faire grandir la capacité d’innovation. L’économie d’aujourd’hui est une économie de la créativité. Toutes choses que le mode de fonctionnement “commande / contrôle” hérité du Taylorisme et du Fordisme ne permettent pas.
Il doit y avoir une meilleure façon de faire, c’est le constat que différents courants de pensée du réseau Stoos (radical management, tribal leadership, beyond budgeting, management 3.0, etc…). Et elle s’inspire de l’agilité.
Pour Peter Stevens, l’élément le plus important du manisfeste agile se situe en haut de celui-ci :
We are uncovering better ways of developing software by doing it and helping others do it.
Stoos Network est un “mouvement de mouvements” qui promeut l’entreprise non comme une structure pyramidale, mais comme un réseau “apprenant” de personnes, dont les managers seraient les servants.
Aujourd’hui, l’agilité dans les projets informatiques est confrontée à une frustration de par les conflits qui l’opposent à un management classique. Stoos est la continuité de ce mouvement vers l’organisation de l’entreprise.
Je n’ai pas trouvé la présentation de Peter Stevens, mais un support qui s’en approche de très près.
J’ai été un peu déçu par cette keynote. Bien que quelques exemples (visibles sur les supports) aient pu nous donner à réfléchir, elle est pas mal resté dans les généralités.
Géry Derbier : Le leader en tant qu’hôte
J’avais suivi de loin l’intérêt de Géry pour le host leadership, mais sans m’y intéresser plus avant, car on ne peut pas être partout, n’est-ce pas ? Mais Géry étant mon futur collègue, j’essaie de le pister un peu…
Déjà, ça commence par le coincer en face de mon objectif !
Cette session était en fait un atelier participatif. On parle toujours du “servant leadership” par opposition au “leader command & control”. Certes, mais comment cela peut-il se matérialiser ? Il y a-t-il des parallèles avec de choses que nous connaissons qui pourraient nous aider ?
Il se trouve que oui !
Que se passe-t-il quand nous participons à une fête que nous jugeons réussie, que fait l’hôte pour rendre cela possible ? C’est à ce travail de reflexion que nous a invité Gery aujourd’hui. Par petits groupes, nous avons cherché à décortiquer les ingrédients d’une fête réussie
Une reflexion pas très facile à mener en un temps limité. Je vous livre en vrac les points qui sont remontés :
- Favoriser l’émergence, laisser de la liberté pour permettre la créativité.
- Avoir une (des) réactions en chaine. A l’image de ce qui se passe quand on commence à danser.
- Créer le lien entre les personnes. C’est vrai surtout quand nombre d’entre elles ne se connaissent pas. C’est moins le cas dans des réunions de famille.
- Le pouvoir de l’invitation. On ne vient pas sous la contrainte, c’est un acte volontaire.
- Donner la permission, ou comme le dira Olivier Pezziardi “pas faire chier les gens”.
- Ne pas chercher à obtenir un résultat. On créé les conditions, le résultat vient en second.
Mais est-il possible de considérer un projet de la même manière ? Sommes-nous invités à nous joindre à un projet ? J’aurais tendance à répondre “oui”. En fait, cela se passe beaucoup dans la tête: nous sommes invités si nous avons envie de nous sentir l’être. Mais c’est juste un avis personnel. Je vous invite à lire le white paper accessible sur le site host leadership.
Cyrille Martraire : Code legacy : Faire évoluer ou réécrire ?
Cyrille est un adepte fervent du DDD et un membre actif de la communaute du software craftmnship. Aujourd’hui il vient évoquer avec nous les stratégies de travail sur le code hérité (legacy code). Cette présentation s’appuie sur un projet mené chez Sungard autour d’un système d’asset management. Nous parlons ici d’une application vieille de 20 ans lourde de 20 millions de lignes de code avec des procédures stockées, des EJB2, etc…
Mais qu’appelle-t-on “code legacy” ? Pour Michael Feathers, du code hérité n’a pas de tests. Si l’on se calque sur cette définition, du code hérité n’a pas besoin d’être vieux pour être considéré ainsi !
Alors, faire évoluer ou récrire ?
Il faut regarder les choses avec lucidité: espérer que tout soit “beau” un jour est illusoire. Ca n’arrive pas !
Le postulat de départ est donc : on garde tout ! Mais pour faire évoluer en gardant l’existant, il faut se munir de tests, d’une manière ou d’une autre. Comment faire ?
Je vous présente le “Software Testing Ice-Cream Antipattern” ! On commence par le haut: si on a rien, on fait des tests manuels. Puis on essaie d’automatiser les tests par l’IHM. Dès que le découpage en couches devient à peu près présentable, on passe à des tests d’intégration pour tester les API. Enfin quand le niveau de découplage interne le permet (le plus souvent jamais) on met en place des tests unitaires !
Bien sûr, c’est très coûteux, et l’orateur évalue le différentiel de vélocité de 1 à 4 par rapport à du code neuf écrit en TDD.
Et s’il faut réécrire, doit-on réécrire ?
Pas toujours. C’est la fameuse question du “make vs buy”. Si le processus métier habillé avec le logiciel est un différenciateur de l’entreprise, alors il faut faire ! Comment se différencier en pratiquant la même chose que les autres ? Si ce n’est pas différenciateur, alors il faut essayer d’acheter. Oui, mais le logiciel sur étagère ne corresponds pas exactement à ce que je fais … N’essayez pas d’adapter, même si l’éditeur dit que l’on peut, même si de nombreuses société qui sont prêtes à vous vendre du conseil disent que l’on peut (et qu’elles peuvent vous “aider”). Ou alors, faites-le à minima, faites votre possible pour plutôt adapter vos processus au logiciel. De toute façon, ce ne sont pas eux qui vous rendent différenciant, ce sont des centres de coût.
Visualiser
Il est bien rare que l’on doivent intervenir partout en même temps dans du code hérité. En fait cela concerne le plus souvent un volet précis de l’application : une phase de traitement, de nouveaux instruments financiers, etc…
La première étape que nous propose Cyrille est de visualiser le flux métier. A l’image de ce que l’on montre lorsque l’on construit une story map (là c’est moi). Il s’agit de donner de la structure. Sur celle-ci s’appuient des fonctions secondaires et des concepts. C’est le travail péparatoire qui va nous permettre de passer à la suite. Ce que Martin Fowler appelle l’Asset Capture.
A partir de là, il va falloir identifier le ou les assets concernés par l’évolution.
Comment intervenir
Quand on part d’un legacy à priori inconnu, il y a une démarche logique pour aborder la bête :
- Lire la documentation
- Interroger les anciens qui la connaisse peu ou prou.
- Utiliser l’application.
- Lire le code.
- S’essayer dessus en fixant des bugs.
Le principe de base des évolutions, est de ne pas essayer de faire plusieurs choses en même temps. Il faut y aller prudemment, s’insérer dans l’existant même si on n’aime pas ce que l’on voit. Des conseils souvent prodigué dans les Reengineering Patterns.
Comment s’organiser
Comment pensez-vous procéder : en opérant une réécriture iso-fonctionnelle ? Sachez-le, personne ne paie pour cela.
Une réécriture s’accompagne toujours d’une certaine dose d’évolutions. Oubliez l’idée d’une équipe refonte constituée de pur techos, il va falloir une vrai équipe projet regroupant des compétences diversifiées (analystes, testeurs, etc…).
Maintenant il faut se mettre au boulot !
Strangler application
Le pattern préféré de Cyrille est le Strangler Application Pattern, lui aussi décrit par Martin Fowler. Comme son nom l’indique, ce pattern consiste à “étrangler” progressivement l’application existante en envoyant les traitements qui ont été réécrits vers la nouvelle application. Le point faible étant ce dispatching qui doit alors exister dans l’ancienne application, nécessitant un refactoring pas nécessairement négligeable… Les deux points clés de l’approche sont:
- Le décomissionement des concepts : on travaille concept par concept, et on switch complètement l’un d’entre-eux quand il est prêt dans la nouvelle application. C’est donc mieux quand les concepts sont assez atomiques.
- Le “feature toggle” qui doit permettre le basculement vers la nouvelle application. Attention, parfois cela se passe mal, il est alors souhaitable dans ce cas de pouvoir revenir en arrière.
Bubble context
Le développement de nouveaux concepts s’opère dans une “bulle” isolée des adhérences avec l’existant, du moins autant que faire se peut. C’est l’Autonomous Bubble Context décrit par Eric Evans.
Isolé du monde legacy, le développement s’opère comme un nouveau développement, en TDD & BDD. Entre l’ancien et le nouveau monde, une Anti-Corruption Layer isolée vers le haut par une API et par le base par une SPI, opère comme un sas entre les deux environnements.
Quelques points clés à ne pas oublier :
- Se faciliter la vie en ayant un certin niveau de mapping avant l’existant. On pense surtout ici au mapping avec la base de données.
- Décréter le “freeze” de l’existant : toute évolution doit s’opérer dans une Bubble Context. On touche seulement à l’existant pour opérer des renvois vers la bubble context.
- Ne pas oublier qu’une bulle n’a qu’un temps. Avec le passage du temps, elle-même deviendra du legacy à son tour un jour.
Pour résumer la stratégie de réécriture, l’orateur nous résume la chose :
Réécriture = Frontières clairement définies + stratégie d’étranglement + intégration minimale.
Je n’ai pas exactement le support que Cyrille a utilisé, mais un très proche. Le voici
Lectures recommandées
Essentiellement 3 ouvrages à connaitre. Ils sont tous sur mes étagères mais n’ont pas encore fait l’objet d’une note de lecture publiée :
- Domain-Driven Design, par Eric Evans
- Object-Oriented Reengineering Patterns, par Serge Demeyer, Stéphane Ducasse & Oscar Nierstrasz
- Working Effectively with Legacy Code, de Michael Feathers
Vous pouvez également lire l’excellent retour de Vincent Uribe sur cette session, sur le blog Soat.
Break !
Le début de matinée a déjà été bien rempli. Il est temps de faire une pause. C’est une occasion pour reprendre contact avec les uns et les autres. On est là aussi pour ça.
C’est aussi la pause pour la publication de mon retour d’Agile France. Nous sommes agiles, on va faire tout ça de manière itérative, que diable ! Rendez-vous bientôt pour la suite de mes périgrinations agilistes.
Software Freethinker 