Je vous avais laissé à la fin de la pause déjeuner lors de mon précédent post. Nous allons débuter cette seconde moitié d’Agile Grenoble de nouveau dans le grand amphi.
Retour dans le grand amphi
J’ai oublié de vous parler de Jérôme Bourgeon. Il est … magicien ! Il introduira ce début d’après-midi et j’aurais aussi l’occasion de reparler de lui plus tard.
Puisque l’on en est aux animateurs de cette journée, nous ne pouvons pas passer sous silence les organisateurs de cet Agile Grenoble, qui est quand même la plus grande manifestation agile en France ! Ils sont nombreux et nous avaient préparé une petite animation à base de fausses pizzas …
La keynote qui suit sera, elle, confiée à Pascal Van Cauwenberghe.
Pascal Van Cauwenberghe : Comment écrire du code legacy plus rapidement
Comme souvent, Pascal nous présente ce qui sera ma session préférée de cet Agile Grenoble. Ca fait aussi parfois un peu mal, car l’orateur ne fait pas trop de concessions.
Outre le sens toujours aiguë de l’auto-dérision de l’agiliste Belge, on voit aussi de nouveau apparaitre nos Scribers prêts à l’action, chacun indépendamment d’un côté de la scène !
Il est surprenant de voir à quel point les résultats obtenus sont différents. Ils me laissent néanmoins toujours admiratifs
Revenons à la session de Pascal.
En bref, cette session est de “techniques” pour dégrader le code plus rapidement ! Le tout découpé en 4 catégories.
Pour le développeur : travaillez votre talent sur la dette technique !
Soyons clairs : ce que l’on nomme avec pudeur “dette technique” n’est ni plus ni moins que du code pourri ! Quelques techniques (sournoises) pour progresser (ou régresser, selon votre point de vue) en ce sens :
- IDD ou “if driven développement” : J’ai un nouveau cas à prendre en compte ? Hop ! Un nouveau if, un nouveau cas spécifique … plutôt que de généraliser !
- Des commentaires pour leurrer : Il suffit d’écrire une intention en commentaire et ne pas la respecter lors de l’écriture du code. Mais le plus souvent le commentaire devient simplement obsolète en n’étant pas mis à jour lors du “bug fixe”.
- Du refactoring qui rend le code plus mauvais ! Là aussi à l’occasion de multiples bug fixes…
- Désactiver les tests qui échouent (on les corrigera au prochain sprint). Evidemment, ce n’est jamais corrigé car il y a toujours mieux à faire…
- Les tests sont une perte de temps : il y a du code à développer … mais comment sait-on qu’il marche ?
- Le framework du jour. Ou comment faire sombrer un projet sous le poids des bibliothèques que l’on a envie d’essayer…
- La collaboration c’est pour les nuls ! Et chacun bosse dans son coin en développant ses trucs de sioux qui nous font paraitre tellement plus intelligents…
Des techniques pour les testeurs
- La loi de Pascal : La qualité du code est inversement proportionnelle à la taille de l’équipe de test ! Quand on est blindé par une équipe de test, pourquoi produire du code de qualité ? La solution ? Retirer l’équipe de test !
- Ajouter la qualité en testant ! Bien entendu, les tests ne font jamais progresser la qualité.
- Semer la confusion sur “la qualité”. Chacun peut interpréter “qualité” comme il l’entend. Mais quelle type de “qualité” attend-t-on en fait ?
Des techniques aussi pour le PO et les managers !
- Je veux tout ! Le meilleur moyen d’avoir du travail bâclé en abdiquant ses responsabilités.
- C’est pas ça ! … ou le syndrome du PO distant. Un rôle bien confortable, où l’on se désengage du produit en rejetant la faute sur ceux “qui ne comprennent pas”.
- C’est trop cher ! Essayer de faire “une bonne affaire” en rentrant dans une logique de négociation … ça se paie toujours à un moment ou à un autre !
Des techniques pour les managers, coaches, etc.
- Protéger l’équipe. Malgré ce que dit Scrum, ce n’est pas une si bonne idée. L’équipe doit être au diapason des problèmes, des mécontentements, etc.
- Isoler l’équipe. C’est le syndrome extrême. Les développeurs travaillent sans appréhender les utilisateurs.
- Optimiser le développement de bugs avec une équipe de maintenance. Ou comme le dit Pascal : une équipe pour écrire les bugs, l’autre pour les corriger !
- Obtenir l’engagement. Très bien pour mettre l’équipe au pied du mur et obtenir l’un des 3 résultats suivants :
- Hacking de fin de sprint.
- Presque done. Un travers dont j’avais déjà parlé.
- Mentir sur sa vélocité pour garder un matelas de secours.
Ne pas suivre ses propres règles. Rétrospectives sans résultat. Pas la peine de faire croire que l’on va s’améliorer si l’on ne fait rien. Réécriture complète. Le genre de projet qui n’aboutit jamais … et peut même faire couler une boite !
L’énoncé des symptômes fait plutôt mal, surtout si l’on considère que j’ai bien eu au moins l’un d’entre-eux sur la plupart de mes projets ! Mais cela fait réflechir aussi pour m’aider à être plus exigeant. Merci Pascal !
Et pendant ce temps, chez Zenika …
Je l’avais évoqué, Zenika était sponsor de l’évènement. Nous avions donc un stand pour nous représenter.
Avec la présence active d’Hervé Jacob, notre directeur d’agence sur Lyon.
Et Christophe Campan en complément de la fine équipe.
Etre sponsor d’un évènement, est une expérience nouvelle pour moi. C’est juste la seconde fois après Rennes. Nous pouvons nous améliorer à cet égard (car on peut de toute façon toujours s’améliorer). Nous aimerions essayer de courtes animations agiles autour de notre stand. A réflechir et essayer pour les prochaines fois.
Service IT Agile, agilité managériale, agilité entrepreneuriale ? Par Michel Cezon
J’aurais voulu m’essayer au Visual Thinking, mais hélas la session a débuté avant l’heure avec une audience au complet ! Je me suis donc rabattu sur cette session.
L’introduction est un peu longue à mon goût : qu’est-ce que l’agilité, etc. Et même le manifeste agile ! C’est presque 20 minutes qu’il faut patienter pour en arriver au coeur du sujet !
Le coeur du sujet, en l’occurrence, c’est la définition du manager agile selon Jérôme Barrand. Selon ce modèle (dont il serait beaucoup dire que je l’adopte) il y a 4 principes de base de l’agilité :
- L’effisens (c’est un mot ?) : donner du sens, responsabiliser et optimiser la performance organisationnelle. Même si j’adopte certaines parties, cela fait un peu fourre-tout et je perçois mal la corrélation entre ces 3 éléments…
- Coopération. Un classique. J’achète.
- Anticipation : prévoir des plans d’action. Pourquoi pas, mais en quoi est-ce lié à l’agilité ?
- Innovation : Mais pourquoi “avec parcimonie” et je ne vois pas le rapport avec la “performance durable”.
N’étant pas spécialement ébloui par les 4 principes agiles, voyons les 6 comportements, qui sont liés à 3 des 4 principes agiles :
- Coopération
- Empathie systémique : c’est favoriser la performance collective. On est d’accord !
- Synchronisation : Agir pour ne pas bloquer la situation. Un bon sens que j’approuve.
Anticipation
- Intelligence de situation : On en a plein la bouche, mais cela signifie simplement agir en fonction des informations disponibles. Je ne peut qu’abonder mais aussi remarquer que c’est pratiquement l’inverse de l’anticipation !
- Proaction : Mettre en place une analyse des risque, des plans d’actions, bref tous les machins pas agiles. Et oui, là c’est bien de l’anticipation.
Innovation
- Rebellion constructive : J’aime bien cette expression. Et en gros, c’est “sortir du cadre”.
- Pédagogie relationnelle : agir comme un leader qui donne du sens correspond bien à ma vision des choses. J’aurais bien classé cela dans “effisens”.
Dans ce modèle de management agile, les outils du manager se classent en 2 catégories :
- Les outils liés à la structure de personnalité. Ici on utilise surtout la Process Com.
- La perception de l’environnement en utilisant un radar type “Agile Profile” avec une détermination en mode normal et en mode “sous pression”.
Le dernière partie avait trait à l’entreprenariat. Je vous laisse regarder les slides, mais je ne m’étendrais pas dessus, là moins qu’ailleurs, le propos me convainc.
Bref, assez déçu par cette session qui n’aura eu d’intérêt pour moi que l’évocation du modèle de Jérôme Barrand dont Véronique Messager avait parlé dans son ouvrage sur le coaching Agile. Je ne pense pas encore prendre ma carte du fan-club…
Petit break de l’après-midi
A Agile Grenoble, c’est café et boissons toute la journée. Mais aussi tours de magie à l’occasion !
Un impromptu drôle et réussi ! Finalement, je vais d’ailleurs rester avec Jérôme Bourgeon sur le créneau suivant.
Petits conseils aux orateurs, par Jérôme Bourgeon
Notre magicien de service est un artiste de scène chevronné et il nous fait partager quelques conseils à propos de nos prestations de présentateurs.
Première règle : Y’a pas de règle ! Bon, ça commence bien…
L’espace de scène est en gros divisé en 6 :
- Horizontalement : gauche, milieu, droite ; on entre à gauche, on s’arrête au milieu. A la fin, on sort par la droite. Sauf Steve Jobs qui fait l’inverse.
- En profondeur : l’avant-scène permet de prendre une position dominante pour faire passer des idées, tandis que l’arrière scène permet au public de souffler, pour faire réfléchir.
Il faut se déplacer sur scène pour éviter la monotonie, mais ne JAMAIS tourner le dos au public ! La monotonie, c’est aussi faire attention à ne pas parler d’une voie monocorde ou ne pas agacer l’assistance avec des tics corporels (aka “la savonnette”, le “mal de mer”, etc.). D’ailleurs, si on doit présenter le matin, il faut penser à chauffer sa voie (je ne savais pas cela…).
Pour une présentation longue, on ne peut (ni ne doit) garder le même niveau d’énergie. Surtout pour un moment crucial, il faut faire monter la sauce, donc, comme dit Jérôme, “gérer sa chiantitude” !
Ah ! Il y a un point sur lequel j’ai bon, de toute évidence : penser à se créer une identité visuelle. Si vous voyez ce que je veux dire…
Enfin, avant de sortir : penser à remercier !
End of AG13
Il reste encore une session, mais déjà c’est l’heure des premiers départs.
Pas de session non plus pour moi sur ce créneau, surtout parce que je commence à fatiguer.
Sur le stand Zenika, on plie les gaules, car on va avoir un peu de route pour rentrer sur Lyon (toujours pas de trains pour Paris en départ de Grenoble).
Mais on n’est quand même pas pressés au point de refuser le cocktail de fin offert par les organisateurs, ce serait mal poli. De plus, on va quand même pas rouler à jeun, c’est très déconseillé…
Agile Grenoble, c’est terminé pour cette année. Je suis satisfait de l’accueil fait à ma session. Moins satisfait de moi-même sur mon parcours de session : il y avait beaucoup de sujets de qualité, mais je n’ai pas su bien sélectionner ceux qui me correspondaient. C’est un peu dommage, mais la faute m’en incombe.
Il s’agira de faire mieux l’an prochain : l’ambiance et les échanges étaient géniaux, j’espère revenir. Un grand merci aux organisateurs !
Software Freethinker 