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 !
Publicités
Étiquette : craftsmanship
It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it.
Steve McConnell
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 !
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.
Carnet de route : Agile France 2014 (3/4)
Suite du compte rendu d’Agile France, après la journée de Jeudi disponible ici et ici.
De bon matin…
De bon matin, ce n’est pas moi. J’arrive à temps pour le café et discuter un peu avec les autres. Mais quand j’arrive, un petit groupe se livre déjà à des exercices de Qi Gong.
Je retrouve les autres dans la salle commune. On discute, Alex Tweet. Business as usual…
Assez plaisanté ! La journée va commencer, place à la keynote !
Coaching Teams Through Change
Rachel Davies nous avait déjà gratifié d’une session il y a peu lors du ScrumDay. Fort heureusement, ce ne fut pas la même. J’ai d’ailleurs préféré cette keynote.
Rachel travail pour Unruly, une société spécialisée dans le « social media advertising ». C’est un domaine où les spécifications changent véritablement tous les jours. L’objectif est ainsi de déployer effectivement tous les jours !
Le début d’un changement
Au début les départements produit et développement étaient deux directions séparées. C’est le départ du directeur produit qui a permit d’enclencher un changement de structure.
Ce changement, c’est l’organisation en équipes de 3 à 5 personnes pour développer le produit. Et pas seulement développer : ces équipes prennent en charge la totalité des activités entourant le développement : l’écriture des user stories, les tests, etc. Ce sont eux qui vont solliciter les différents interlocuteurs (produit, marketing, commercial) quand cela s’avère nécessaire. Pas de product Owner qui est la seule voix du client, l’équipe va parler directement à tous les interlocuteurs ! Parmi ces interlocuteurs, nombre d’entre-eux ne sont accéssibles qu’à distance : l’équipe utilise Google Hangout pour communiquer. La conversation s’engage avec les interlocuteurs pour trouver la plus petite chose utile à construire, ce qui nécessite de prendre en compte tous les point de vue.
Lone rangers et development owners
Tout le développement est réalisé en binômes. Mais les équipes sont constituées d’un nombre impair de personnes ! En fait, par rotation, l’une d’entre-elle est le « lone ranger ». Elles s’occupe de diverse choses dans l’équipe, mais pas du code de production. C’est aussi à cette personne que les intervenants extérieurs à l’équipe s’adressent, afin de ne pas perturber les binômes en train de travailler.
L’équipe a aussi développé l’idée de « owner of the development area » : un développeur plus expert au sein d’un sous-ensemble fonctionnel. C’est lui qui élabore une proposition par rapport à un besoin exprimé.
Les propositions sont traitées en planning meeting. Celui-ci n’est pas un planning meeting classique XP : seule la priorisation des propositions y est traitée, il n’y a pas d’engagement de charge. Ces planning sont donc très courts : ils n’excèdent pas 30 minutes !
Gold card
A l’image de ce que Kniberg décrit pour Spotify, Unruly fait des efforts particuliers par rapport au bien être des équipes. Outre divers évènements sociaux, la société applique la politique du 20% free time inspirée de Google (bien qu’elle disparaisse progressivement de Google, justement). Ici elle s’appelle « gold card day » et sert de sources d’inspiration pour creuser de nouvelles idées.
Ce que j’en ai pensé
Sans être exceptionnelle, cette présentation nous offre l’opportunité d’avoir un retour sur une organisation d’équipe différente de ce que l’on voit aujourd’hui :
- Les itérations s’estompent au profit de la déliverie continue, mais des points de priorités réguliers contrebalancent l’effet « court terme » du flux.
- Pas de « product owner » ici : c’est l’équipe qui fait le lien avec les divers interlocuteurs. Le périmètre de responsabilité de l’équipe s’accroit, mais on évite ainsi l’effet paravent du PO !
Je change mon programme à la dernière minute. Je choisis en 15 secondes d’aller à une présentation résolument technique. Grand bien m’en a pris !
Le mythe du framework agile
Jean-Baptiste Dusseault vient mettre fin à quelques idées reçues concernant ces frameworks qui doivent nous agilifier / faciliter la vie. Au départ de ce « ras le bol » un titre de livre : Agile Web Developement with Rails ! Même co-écrit par l’un des signataires du manifeste agile (et par l’auteur de Rails), ll y a un problème ici. Probablement plusieurs même. Le premier est la taille du livre : près de 500 pages !
Le framework maison
Mais commençons par le commencement. Et le commencement, puisque nous parlons ici de frameworks « full stack », c’est le fameux framework d’entreprise. Un bon point : nous n’avons que trop rencontré ces pantalonnades. Lâchons-nous, ça va faire du bien !
Le but de ces frameworks, c’est d’avoir le « meilleur du moment », tout bien branché ensemble. On met les pantoufles, on débranche le cerveau, et l’on peut tranquillement produire plein d’applications en un tournemain !
Sauf que ça ne se passe pas comme ça. Ces braves frameworks transforment notre vie en enfer !
Citons dans le désordre :
- Prévus pour être simples, ils s’avèrent en fait ultra-compliqués ! Peut-être leur conception et leur réalisation par des « équipes transverses » explique-t-elle quelque chose ?
- Ils sont difficiles à tester et très bugués. Là encore, leur réalisation détachée des projets n’a pas contribué à leur testabilité. Utilisés uniquement par quelques projets de l’entreprise (au mieux) le « durcissement » du framework n’a jamais vraiment eu lieu…
- pas de support : souvent les équipes ayant réalisé le framework sont parties depuis longtemps…
Qu’en est-il des « full stack » reconnus ?
Ici on parle des rails, Play, etc… Ils nous font la même promesse d’accélérer les développement du sol au plafond. En vérité, ils prennent des décisions d’architecture pour nous ! Jean-Baptiste va plus loin : en déléguant les choix d’architecture au framework, on laisse celui-ci nous utiliser !
Nous n’utilisons pas les frameworks “full stack” : ce sont eux qui nous utilisent.
Ce biais a des conséquences, on va le voir bientôt.
D’où vient leur succès ? Ils permettent de faire très vite 80% de l’application. Mais on galère sur les 20% restant ! Généralement, la réalisation en suivant le tutorial va vraiment vite.
Hélas, ils encouragent certains comportement. La partie « basse » entité et persistance est plus ou moins câblée. Il n’est pas possible d’y intervenir facilement. Et les entités ressemblent beaucoup aux tables de la base de données (ça rappelle les outils RAD client/serveur). On hérite donc d’un couplage vertical sur la base de données.
En fait, le seul endroit où l’on peut réellement raccrocher du code, c’est le contrôleur ! On l’accroche comme on peut. Et si des comportements communs apparaissent dans le code tartiné sur deux contrôleurs, le seul moyen efficace de le partager est le copié-coller ! Beurk !
Bref nous obtenons :
- Des architectures monolithiques.
- Des frameworks optimisés pour l’écriture de code … mais pas pour sa maintenance !
- Des couplages forts avec la représentation et la base de données.
- De grosses difficultés pour sortir des clous via des « plugins » et autres joyeusetés du genre qui ont de grosses courbes d’apprentissage.
- Une testabilité rarement au rendez-vous.
Mais alors, c’est quoi un framework agile ?
Plutôt que de framework agile, parlons d’architecture agile, et des propriétés qu’elle devrait avoir.
- Elle doit nous permettre de retarder les décisions
- Elle minimise les couplages.
- Elle est facile à changer.Elle est testable (via TDD et ATDD)
Une proposition et des inspirations
Pour Jean-Baptiste Dusseault, une telle architecture c’est :
- Au centre un véritable modèle du domaine d’inspiration DDD, comme les proposent l’architecture hexagonale d’Alistair Cockburn ou la Clean Architecture de Bob Martin. Ce modèle ne dépend de rien et ne connait pas la persistence ni aucun système tiers, mais expose une API métier.
- Une couche « commandes » implémentant les cas d’utilisation du modèle du domaine. Des idées que l’on retrouve dans la Lean Architecture de Jim Coplien.
- Au-dessus un couche d’accès type CQRS dialoguant en asynchrone avec la couche commande et routant différemment les évènements commande (vers la couche commande) des requêtes qui sont adressées directement à la couche d’accès à la base de données.
Bien sûr le postulat de cette architecture, c’est que le métier est au centre des préoccupations. On n’évoque pas non plus l’architecture en micro-services qui me semble pourtant adaptée mais peut-être pas facile à concilier avec une architecture hexagonale…
La présentation de Jean-Baptiste est évidemment en HTML5 et elle est accessible en ligne ici.
Ce que j’en ai pensé
Cette session est une agréable surprise. Si le bashing des « frameworks agile » ne fait que confirmer ce que je pensais, les idées développées sur l’architecture agile me font beaucoup plus réfléchir, pour ne pas dire qu’elles soulèvent mon enthousiasme !
Comment j’ai développé mon muscle de l’amélioration continue en faisant mes courses
Ayant décidé de bouleverser mon programme, je n’ai de nouveau que 2 minutes pour changer mon programme. De nouveau, c’est une bonne pioche avec la session de Cyrille Deruelle !
Tout d’abord : pourquoi faire des exercices d’amélioration ? Pour que cela devienne une habitude, rendre cela naturel. Et Cyrille s’est livré à cet exercice en faisant ses courses du Samedi : c’est drôle et instructif !
Bien sûr tout ça n’a pas très bien marché du premier coup (d’où la nécessité de s’améliorer). Au départ, Cyrille a essayé d’impliquer son épouse (Product Owner des courses) dans la résolution des problèmes qu’il rencontrait. C’est une première leçon :
Les gens se foutent de la manière dont nous résolvons les problèmes.
Au hasard des améliorations, on va trouver :
- « t’as rien oublié » … où comment suivre que l’on a tout acheté ? A l’aide d’une liste de courses et d’un gros feutre noir (le stylo fin ne convient pas).
- Grouper les courses par catégorie : afin d’optimiser le parcours dans le magasin.
- Prendre une photo des rayonnages pour les produits compliqués … afin de permettre à son épouse d’indiquer le produit souhaité. Le choix de la lessive a été vaincu ainsi !
- Gérer les dates limites de consommation en les pré-calculant par rapport aux courses suivantes : afin d’éviter les erreurs pendant les courses.
- Sortir des éléments du process : Les packs d’eau, c’est ingérable ! Alors on ne les sort du processus standard et on fait de temps en temps des ravitaillements en eau (en grande quantité) !
Les conclusions de Cyrille
- Mes problèmes sont mes problèmes : Il n’est pas possible de s’en décharger sur d’autres personnes.
- Il n’y a pas de choses simples : l’amélioration continue est une quête !
- Les actions d’amélioration sont fragiles et difficiles ; c’est une discipline de tous les jours.
- Mesurer l’impact d’un problème, c’est déjà 50% de la résolution
Enfin parfois, les améliorations ne sont pas possible, c’est le CCMCCC : C’est Con Mais C’est Comme Ca !
Grâce aux actions d’amélioration, Cyrille n’a pas seulement rendu son processus de meilleure qualité et plus efficace, il l’a aussi rendu fun !
Ce que j’en ai pensé
Une très bonne session : amusante et instructive. Bravo !
Refactorer du Legacy
Pas besoin de changer de salle pour la session de Johan Martisson. J’ai rencontré Johan lors du ScrumDay 2014. Ou plus exactement, Jean-Laurent de Morlhon me l’avait présenté. D’ailleurs Jean-Laurent était là à cette session résolument intimiste orientée craftmanship, avec des vrais morceaux de « live coding ».
Johan nous parle et nous démontre son approche de la reprise en main du code legacy, à l’aide de la librairie ApprovalTests. Pour résumer l’approche en quelques points :
- On construit un harnais de tests résolument temporaires de manière rustique mais rapide.
- On construit de manière assez brutale des combinaisons de conditions d’entrée pour couvrir une combinatoire de cas couvrant l’espace du problème.
- On exécute une première fois les tests pour constituer la référence, sans se soucier de la justesse des résultats : il s’agit juste du comportement courant de la librairie.
- On vérifie la stabilité du comportement du soft en comparant les résultats par rapport à la référence.
- Au fur et à mesure du refactoring, on construit des tests unitaires définitifs. On peut envisager de se débarrasser définitivement des tests temporaires, de manière progressive.
Ce que j’en ai pensé
Au début de la présentation, je mes suis demandé où Johan essayait de nous emmener et j’ai pris conscience avec un peu de retard de l’efficacité et de la rapidité avec laquelle Johan mettait en place son harnais de tests ! Je dois dire que c’est très convainquant. Une petite vidéo pour vous en convaincre.
J’avais prévu d’être un peu plus long sur le descriptif de ce que Johan nous a montré avec l’outil, mais il le fait mieux que moi sur son blog. Je vous invite donc à le lire.
Pause déjeuner
Par une curieuse coïncidence, c’est de nouveau avec Jean-Luc Lambert que j’ai échangé lors de cette pause. Et nous avons parlé éducation et « génération Y ». Jean-Luc évoque avec enthousiasme le challenge que représente l’enseignement avec cette population.
- Elle ne prend pas pour acquis les propos de l’enseignant. Le cours magistral a une vertu pour le moins limitée.
- Ils sont « multi-tâches ». C’est assez déroutant, mais il faut faire avec !
- Ils sont réceptifs aux jeux et aux exercices libres. Les techniques type « from the back of the room » leur sont bien adapté.
- Ils ont beaucoup d’autonomie et sont entreprenant.
- Ils ne se sentent pas beaucoup d’attache ni de fidélité pour la société pour laquelle ils travaillent.
Voilà pour cette dernière matinée. Je vous retrouve très bientôt pour la dernière partie de cet Agile France 2014 !
Note de lecture : Deal with It, par Gavin Davies
Note 6 ; L’attitude avant l’aptitude et l’hygiène de vie du développeur
Ce livre est plutôt un « mini livre » car il ne totalise que 60 pages ! Cet essai se lit donc rapidement, il m’a pris moins de 2 heures. Car non seulement le nombre de pages est compté mais il n’est constitué que d’articles (qui ressemblent plutôt à des blog post qui tiennent tous sur une page, titre compris ! Et encore, on parle là d’une page pas bien grande.
C’est aussi la qualité de cet opuscule car il s’agit là en fait d’une contrainte de taille que s’est donné l’auteur lui-même. Chaque sujet devant alors être exposé avec le maximum d’efficacité. Une sorte de « lean » de l’écriture, si on veut bien.
Intéressons-nous maintenant au contenu. Ce mini-livre est découpé en 5 parties.
La première partie « overall attitude » regroupe 11 essais. L’auteur développe ici les question d’état d’esprit : être courageux, ne pas avoir honte de son ignorance, être curieux et savoir chercher, etc…
La seconde partie « tools, learning et techniques » concerne plus un savoir « tactique pour faire face aux différentes situations. On y parle tests, déploiement et … lire des livres ! Par exemple… Ce sont 13 essais qui forment cette partie
La troisième partie « wisdom for the Long Haul » comporte 7 essais. Il évoque les questions de relations entre personnes et d’hygiène de vie. En fait : comment tenir la distance !
La quatrième partie « communication is key » comporte juste 7 essais. Zut, justement un des essais nous apprend à ne pas utiliser le mot « juste » ! On y évoque la documentation, les emails et les relations entre les managers, mais finalement peu de choses sur les relations entre collègues. Donc c’est un peu décevant.
La cinquième partie « closing advices » ne compte que 5 essais. C’est un peu dans le style « allez en paix ».
L’auteur m’avait prévenu : je ne serais pas d’accord avec tout et ce serait même curieux que je le sois. Cela a bien été le cas, mais j’avoue être en accord avec une grande partie de ses positions. Ce livre s’adresse sans ambiguïté aux développeurs. Et pourtant, l’auteur focalise son propos sur les « savoir être » plutôt que sur les « savoir faire » ! A ce titre, il me rappelle un peu le « pragmatic programmeur » d’Andrew Hunt et Dave Thomas. Rappel justifié, car l’auteur y fait référence vers la fin de son texte.
Au final, il ne s’agit pas d’une lecture indispensable. Elle est juste intéressante : la concision de l’expression de l’auteur et la rapidité avec laquelle on avale le texte sont des plus. Je la classerais en lecture d’agrément en sus de textes plus solides tels que le Pragmatic Programmer suscité, ou encore les Clean Code / Clean Coder de Robert Martin et quelques autres.
Référence complète : Deal with It, attitude for coders – Gavin Davies – Leanpub 2012
Carnet de route : Agile France 2014 (1/4)
Agile France, c’est un rendez-vous incontournable. Enfin disons : sauf cas de force majeure. Le lieu reste le même et surtout fidèle à lui-même : le chalet de la porte jaune !
En arrivant, on est certain d’y trouver du café, mais surtout des connaissances et des amis. Ca commence bien !
L’organisation se fait aussi un point d’honneur d’être dans le timing. Et ça, ce n’est guère évident ! C’est Damien Thouvenin qui officie comme que maître de cérémonie cette année.
Avant de laisser place à la Keynote de Régis Médina, je voudrais souligner la formidable présence de Romain Couturier pour animer un scribing en continu lors de cet Agile France. Il a également initié plusieurs groupes à son art, qui se sont aussi jeté à l’eau pour capturer les sessions de l’open-space !
Le produit, prochaine frontière de l’agilité
Le Product Management, c’est un sujet plutôt « trendy » en ce moment. Régis va l’évoquer pour nous avec sa sensibilité Lean.
Le bon vieux temps
Autrefois, avant l’agile, on produisait les logiciels en phase. Arrivait la phase de tests. En fait, le moment où commençait vraiment le projet. Parfois, tout était purement et simplement jeté à la poubelle. mais on sait maîtriser cela désormais. Hélas, la récompense pour un problème résolu, c’est un nouveau problème !
Le nouveau problème, c’est que nos utilisateurs veulent plus et plus vite : ils ont des services en ligne accessibles depuis partout, des applications mobiles … Ils ne sont plus dupes ! Le niveau monte, il n’y a plus le choix : il faut produire un SUPER logiciel !
Obtenir le whaou effect !
Et déjà, deux trucs pour ne pas l’obtenir:
- « design par comitee ». Ici les Product Owner ne servent que d’aiguillage entre des besoins plus ou moins divergents.
- Fonctionner en flux à l’extrême. Le revers du flux, ce de ne porter son attention sue sur des petits bouts.
Alors quelle solution ?
Le Lean Startup offre une partie de la solution, mais il n’offre pas de réponse aux points de vue antagonistes, ni à la résolution des contraintes. Régis préfère orienter son regard vers le Lean Engineering, où un chef d’orchestre (et un seul) porte la vision du client (vous avez dit « product owner » ?). Bien. Mais quels caractéristiques, quelles aptitudes doit posséder ce chef d’orchestre.
Si l’on regarde les grands chief engineers, on voit que l’une de leur caractéristique commune est leur capacité à dire « non ». Mais comme on s’en doute, cela ne suffit pas. L’orateur évoque pour nous trois compétences clé.
Trois compétences
Positionner le challenge : c’est le chief engineer qui donne la direction et place la barre. S’il ne le fait pas, les personnes de l’équipe se trouveront individuellement leur propres challenges ! Positionner le challenge, c’est aussi identifier les paramètres clé, ceux que l’on aura déterminés en allant voir sur le terrain.
Cultiver le désaccord : Lister les options s’offrant à nous de manière crédibles et les attaquer de front (set based design).
Dénicher les erreurs : En ayant un niveau d’exigence élevé, obligeant à voir et revoir sans cesse les solutions adoptées. La voie empruntée ici est celle de la résolution des problèmes.
Ce que j’en ai pensé
C’est toujours un plaisir d’écouter Régis. Et ses interventions sont toujours d’excellente qualité. Je ne peux qu’abonder dans le sens qu’il évoque, même si je trouverais certains autres points à appuyer, comme l’importance du feedback (bien couvert par le Lean Startup dans ce cas).
Cela ne révolutionne pas non plus mon image du product management, j’y trouve les éléments que j’avais déjà, à l’exception sans doute du « cultiver le désaccord » qui donne un peu à réfléchir. Curieusement ce point sera aussi abordé dans une autre session ! Mais c’est aussi un aspect que l’on retrouve aussi dans le design thinking…
Le mot de l’organisation
Avant d’aborder la suite du programmes, nous avons droit aux pitches de la première journée : 30 secondes par orateur, c’est vraiment court ! On a aussi le mot de l’association, par la voix de son président, Emmanuel Gaillot.
L’an dernier, Emmanuel nous avait gratifié d’une tirade pour le moins asez sèche, assis sur une chaise. Pas terrible. Je ne sais s’il a lu mon compte-rendu, mais cette année c’est débout qu’il s’est exprimé, avec un verbe moins acerbe et nettement teinté d’humour, et avec le même message. Ca change tout ! Kudo, Emmanuel !
Il est temps de rejoindre la session suivante. Moi, je ne change pas de salle car Pascal Van Cauwenberghe fait son talk avec Jacques Couvreur dans celle-ci.
La simplicité : Pas facile !
Je ne savais pas à quoi m’attendre pour cette session (dont je n’avais même pas pris la peine de lire le résumé). La simplicité, ce n’est effectivement pas facile, car elle nécessite avant tout de définir ce qu’est la simplicité !
Pour nous aider dans notre quête, Pascal et Jacques vont plonger dans la substance proposée dans deux ouvrages.
The Laws of simplicity
Le livre de John Maeda nous propose 10 lois que nous passons revue.
1 – La réduction : Ne laisser apparents que la fonction et le message.C’est donner une apparence de simplicité.
2 – Organisation : Ranger les éléments pour donner une impression de simplicité.
3 – Lutter contre les temps d’attente : l’attente donne une impression de complexité. Exhiber un élément dynamique comme une barre de progression atténue cela.
4 – L’apprentissage : Elle couvre deux niveaux :
- L’apprentissage immédiat : c’est permettre la découverte.
- La maîtrise, qui intègre une notion de dynamique.
5 – La différence (Jacques est resté sec là dessus)
6 – Le contexte : un concept difficile à saisir, mais qui tempère d’un « ni trop, ni trop peu » cette notion de simplicité.
7 – L’émotion : La simplicité est aussi un facteur non rationnel.
8 – La confiance : C’est offrir un contexte sécurisé, permettant de faire et défaire sans crainte.
9 – L’Echec : Parfois, on ne peut pas tout simplifier. Mais essayer permet d’apprendre.
10 – La loi cardinale : Moins d’évidence et plus de sens.
Bon, je reste un peu sur a fin avec cet énoncé de concepts. Certains éléments de la liste me parlent un peu, mais cela manque de substance. Passons au second opus.
The Laws of Substraction
Le livre de Matthew E. May livre à son tour 6 règles.
1 – Ce qui n’est pas là est parfois plus important que ce qui est là. Pascal rapproche ce point de la loi de Conway. Améliorer l’environnement (en éliminant des barrière) peut améliorer le produit.
2 – Les règles simples produisent les expériences les plus productives. Pascal nous propose deux choses à essayer en ce sens :
- Quelles règles (qui protègent) peut-on supprimer ?
- « abandonner » l’application aux utilisateurs.
4 – Ajouter des contraintes. Pour déclencher de nouveaux comportements, on peut par exemple : réduire la durée des itérations, réduire la durée entre 2 commits, etc..
5 – Parfois, il faut casser pour percer. Ne pas avoir peur des crises…
6 – Parfois, ne rien faire c’est mieux !
Je sais, il me manque l’item numéro 3 : désolé !
Ce que j’en ai pensé
Je suis un fan des présentations de Pascal. Cette fois, je suis resté sur ma faim. Mais néanmoins, je serais bien là aux prochaines présentations de Jacques et Pascal !
Le prochain créneau nous propose des lightning talks. Mon choix est fait depuis longtemps !
Tim Gallwey ou comment le coaching a commencé
Christophe Keromen nous a proposé une session une session de 20 minutes passionnante commençant par un échec : celui de Tim Gallwey, alors champion de tennis, ratant la balle de match d’une demi-finale de championnat (et le match par la même occasion). Ainsi commence le constat : nous sommes tous nos propres saboteurs ! Nous avons du potentiel, mais nous faisons moins que ce que nous sommes capables de réellement faire. D’où l’équation :
Performance = potentiel – interférences
Quand « self 1 » gêne « self 2 »
Nous interférons avec nous-même.
Notre « self 1 » représente l’égo, le moi rationnel, tandis que « self 2 » représente le corps et l’inconscient. Lorsque nous laissons « self 1 » interagir, nous provoquons un ralentissement, une diminution de notre probabilité de réussir. Ce point est appuyé par les neuroscience qui affirment que la quasi-totalité des informations dont nous disposons est inconsciente.
A quoi cela peut-il me servir ?
Christophe nous propose deux axes.
L’apprentissage. Les images sont supérieures aux mots. On apprend mieux par mimétisme sans chercher à décrire ou à rationaliser ce que nous faisons (sinon nous rappelons « self 1 »).
Les habitudes. Nous créons des habitudes pour répondre à un contexte qui est souvent la marque du passé, bien que répondant à une intension positive. Il faut remplacer ces habitudes par de nouvelles, répondant aux mêmes intentions, mais adaptées au contexte présent.
Ce que j’en ai pense
Christophe a superbement abordé le sujet. Me voici avec encore un sujet à potasser. Je retiens dans l’immédiat la prédominance de l’exemple sur la formulation littéraire.
Pas la peine de bouger de place pour la prochaine présentation qui se déroulera dans la même salle. Tant mieux pour moi, car ça se bouscule !
La rétrospective continue
C’est en duo et dans une salle comble que Régis Médina et Antoine Contal nous ont proposé leur session. Toutes les places sont prises et une partie du public est debout !
Evidemment, comme on peu s’y attendre, Antoine et Regis nous parleront de Lean. La clé des retrospectives réussies, celles qui progressent au lieu de s’enliser se situe hors des rétrospectives : c’est créer un environnement où l’équipe progresse. Continuellement.
Dans ce cadre, le rôle du coach devient celui du coach sportif : il aide à poser le challenge.
Le challenge !
Forcément, sur un projet, le challenge est un concept plus flou que pour un sportif. Mais c’est posible en prenant en compte ce qui est important pour le projet. Il n’y a pas de recette miracle.
- Le sourire du client
- Le lien avec l’argent. Le flouze, quoi !
- La stratégie
Pour un manager, les dimensions à prendre en compte pourront être :
- Qualité du code.
- Délai de livraison.
- Productivité (même si ce facteur est à prendre avec prudence).
Finalement, il faut trouver le moyen de rendre ce challenge visuel (indicateur, progression…).
Un apprentissage individuel
Une fois posé le challenge, il faut le décliner en petits exercices d’amélioration individuel : chaque action d’amélioration doit avoir son porteur. Ce porteur devient expert du sujet, et il profite ensuite des rétrospectives pour partager son savoir !
Chaque action d’amélioration se décline en expérimentations suivant le cycle PDCA : ce sont des Katas.
Finalement une bonne nouvelle, mais…
La bonne nouvelle, c’est que l’on peut garder les rétrospectives. Elles deviennent un lieu d’échange des nouvelles pratiques.
Il y a aussi un prix à payer :
- Ecouter les managers
- Ecouter la réalité plutôt que ses envies
- Persévérer
Les bénéfices en contrepartie :
- On peut avoir un impact
- Quand ça marche, le comportement des personnes change.
Enfin, Antoine et Régis nous proposes des exercices à faire en rentrant
- Aller voir et écouter le client
- Construire le modèle économique du produit
- Questionner un directeur sur les objectifs stratégiques
- Mettre en place un indicateur
- Commencer avec un problème dont nous (en tant que coach) connaissons la réponse.
Ce que j’en ai pensé
Comme d’habitude, avec Antoine et Régis, c’est du lourd comme disent les jeunes. On prend cher au passage aussi : leur sessions sont aussi intéressantes que déprimantes. Mais ça tombe bien, les actions d’amélioration sont au centre de ce que j’ai à faire en ce moment !
Pause déjeuner
Je ne reviens pas sur la qualité de la la restauration d’Agile France, j’en ai déjà longuement parlé l’an dernier !
Le déjeuner, c’est surtout l’occasion d’échanger avec les personnes que l’on apprécie (il y en a beaucoup !). Ce midi, ce sera avec Nathaliel Richand et Jean-Luc Lambert. Bien sûr, nous évoquons un peu le Printemps Agile, mais nous parlons surtout enseignement : Nathaniel voudrait développer des MOOCs agile, ce qui est dans les tendances du moment, mais peu compatible avec un enseignement de plus en plus par le jeux et « from the back of the room »…
Sans doute il y a-t-il complémentarité entre les deux modes, en utilisant les MOOCs pour des sujets plus étroits, pour lesquels il serait difficile d’organiser des sessions, donc plus avancés.
Voilà, ce sera tout pour aujourd’hui. Je vous donne rendez-vous très bientôt pour le déroulement de l’après-midi.
Carnet de route : Le ScrumDay 2014 (4/4), Bonus track !
Après avoir couvert mon parcours de ces 2 jours de ScrumDays (ici, ici et ici), une question reste en suspens : et les autres sessions ? J’ai donc été rechercher du mieux que j’ai pu les supports de présentation des sessions auxquelles je n’ai pu assister. Il en manque encore hélas beaucoup, sans compter la mise en ligne des vidéos. Si vous avez des liens vers les supports manquants, faites m’en part, je les rajouteraient.
Pour commencer, voici le livret des sessions, en mode présentation
La transformation numérique de France Télévision
France Télévision fut le premier sponsor « client final » du French SUG ! Ils nous partagent leur retour d’expérience.
Vous retrouverez aussi cette présentation via le blog d’Alain Buzzacaro.
Le Lean Startup au service du Product Owner, par Jérôme Guenver
J’ai entendu dire beaucoup de bien de cet atelier animé par Jérôme. Un atelier que Jérôme a imaginé suite à une discussion que nous avons eu ensemble chez Zenika. Je suis donc plutôt heureux d’avoir eu un petit rôle pour inspirer un collègue !
Des outils du monde de la psychologie… par Bruno Sbille
On ne présente plus Bruno, en tout cas on ne devrait plus ! Bruno est l’un des piliers de l’imposante communauté agile Belge. Il est aussi l’organisateur de l’Agile Tour Bruxelles auquel je participe depuis sa création (et j’espère continuer). Lors de ce ScrumDay, il proposait cet atelier en plus de son rôle dans la « coach clinic » !
Dans cet atelier, Bruno présentait et permettait d’expérimenter divers outils tels que la PNL, le VAK, etc. Je me souviens encore que Bruno avait fait le déplacement depuis Bruxelles pour la soirée de création du French SUG il y a 6 ans de cela. C’était justeent pour nous parler de PNL !
Let’s Sketch together, par Alvin Berthelot
L’atelier d’Alvin était articulé autour de la création visuelle de produits. Je sais qu’il le produit régulièrement, j’aimerais bien avoir l’opportunité d’y participer…
The big payoff, par Alexandre Boutin
J’avais eu l’occasion de pratiquer ce jeu lors des premiers Agile Game France. Alex remet le couvert pour ce très bon agile game. Vous pouvez en trouver le descriptif en anglais ici. Et mieux encore le descriptif en Français ainsi que le matériel de jeu sur le blog d’Alex.
Faites Revivre vos spécifications
Un autre sujet orienté BDD issu d’une expérience récente de Yannick. Il m’en avais parlé lors d’un déjeuner, plus tôt dans l’année. Une optique de l’acceptance testing qui diffère un peu de la mienne, mais sans être incompatible (si, si !).
Open Agile Adoption, par Pablo Pernot et Oana Juncu
Encore une session à laquelle j’aurais aimé pouvoir assister si j’avais pu me dédoubler. Too many sessions, so little time…
Ici, Oana et Pablo nous dévoilent (en partie) le framework de Dan Mezik.
Créer le bon produit avec le Lean Canvas, par Romain Couturier
Romain a vécu un ScrumDay mouvementé, avec une panne de sonorisation suivi d’un changement de salle. Ici Romain nous parle du Lean Startup et plus précisément de l’outil de référence développé par Ash Maurya .
Les nouveaux outils du Product Owner
Story Mapping, Impact Mapping, Lean Canvas et Kanban : ce sont les « nouveaux » éléments que nous propose Claude pour le Product Owner.
Agilité : la fin du middle management ? Par Kevin Maccioni et Fabien Barbaud
Avec le passage à Scrum, le retour d’expérience des deux orateurs les amènent à répondre oui !
Introduction to Visual Management, par Natalie Yadrentseva
Je ne suis pas certain de joindre ici le bon support, je l’avoue…
Certains éléments de cette présentation me rapellent furieusement le Lightning Talk d’Igor Sviridenko à l’Agile France 2013…
Devops Game, par Vincent Daviet
Le troisième atelier Zenika de ce ScrumDay nous était proposé par notre nouveau venu Lyonnais avec ce Devops Game que je n’ai hélas pas pu expérimenter.
Podojo : PO, viens t’améliorer par la pratique avec nous ! Par Guillaume Duquesnay et Nicolas Verdot
A défaut d’un support de présentation, voici une petite vidéo avec une interview de Dominique Lequepeys sur cet atelier
Le Product Owner est-il un Product Manager agile ? Par Sébastien Saccard
Sébastien Saccard n’est pas un inconnu pour moi : tout d’abord il fut à l’initiative du workshop d’Ash Maurya à Paris, ensuite en tant que président de l’association We Do Product Management, il fut à l’instigation de la rencontre avec Gojko Adzic hébergée chez Zenika.
Sébastien cherche à développer le métier de Product Manager en France. Sa présentation va dans ce sens.
Vous pouvez aussi retrouver la présentation de Sébastien sur son Blog.
Agile-Lean-Kanban : Le guide du routard 2014, par Christophe Keromen
Bien rodée, j’avais eu l’occasion d’assister à cette très vivante présentation de Christophe à l’Agile Tour Rennes 2013. Mais était-ce réellement la même ?
My Product is a James Bond Movie – part V, par Pierre Neis
Les présentations de Pierre ne ressemblent à rien de connu ! Elles sont difficile à raconter, et je doute que le support ci-dessous lui rende justice. J’avais assisté à la « part I » de cette série « James Bond Movie » lors de l’Agile Tour Bruxelles 2013 … nous voici rendu au 5ème opus !
Développer en mode Kick-Ass, par Samuel Le Berrigaud
Le Kick-Ass de Samuel, cela me fait penser au « programming motherfucker » ! D’ailleurs en fait, il en parle dans sa présentation. Je vous recommande ce support pas mal du tout … en attendant la vidéo !
De la culture projet à la culture produit, par Céline Stauder et Gregory Alexandre
La présentation de Céline et Grégory est tout à fait dans le thème de ce ScrumDay. Par contre le support ne vous permettra guère de saisir la substance de la présentation !
Le prétotyping, avec Elalami Lafkih
Le prétotyping, c’est du prototypage « low cost », plus tôt donc avec un feedback anticipé. Elalami nous en expose un certain nombre de techniques. J’ai repris le support de l’orateur utilisé durant l’Agile Tour. Je suis parti du principe qu’il s’agissait du même…
Kapla Challenge, avec Dragos Dreptate
Construire un pont par itération (avec des Kapla), c’est le challenge que nous propose Dragos durant cet atelier
Faire Agile, c’est bien…, par Aurélien Morvant et Simon Jallais
Simon et l’homme aux chaussures de couleurs différentes nous proposent de découvrir ce qu’est « vivre agile ». Une session plutôt décalée !
DSL et refactoring pour les tests d’acceptation, par Laurent Py
Laurent nous fait partager son expérience ATDD / Devops chez Smatesting. En fait, la session ressemble terriblement à une promotion de l’outil Zest’ qui est, oh surprise, développé par la société dont Laurent Py est CEO !
Bon, voici quand même cette présentation…
Les reportages du ScrumDay
Une petite séquence « fun », tournée en bonne partie durant la pause déjeuner du second jour.
Et le reportage du ScrumDay, avec quelques interviews et des interventions de Xavier Warzee et Alistair Cockburn
Ils en parlent aussi…
Quelques liens vers des articles de blog que j’ai peu glaner à droite et à gauche. Si vous avez d’autres liens, n’hésitez pas à m’en faire part.
Il y avait une Coach Clinic, mise sur pied par Fabrice Aimetti et Bruno Sbille. Côté Zenika, Géry Derbier y participait ainsi que Laurent Sarrazin pour Rupture 21. Un compte-rendu est disponible sur le site d’Ayeba.
Alex Boutin nous livre sur son Blog la manière dont il a vécu ce ScrumDay.
Un retour de Laurent Sorin sur la table ronde menée par Véronique Messager
Autre retour également en provenance d’Ippon, un feedback sur la session de Rachel Davies par Victoria Pedron.
Dominique Lequepeys nous adresse les points forts des sessions auxquelles il a participé. Youpi, ceci inclut la mienne !
Christophe Deniaud fait aussi son billet de Blog sur les sessions qu’il a vu, ainsi que sur l’open-space. Lui aussi donne son feedback sur mon atelier. Pas sûr que mon message principal sur l’écriture collaborative des tests soit bien passé…
Coactiv nous livre aussi ses retours.
Carnet de route : Le ScrumDay 2014 (2/4)
Je vous avais laissé au moment du déjeuner. La pause n’aura pas été si longue. Sur le créneau suivant, j’ai coché la session de Véronique Messager sur mon programme.
En tant que Scrum Master, je veux m’améliorer pour mieux coacher mon équipe
Cette session de Véronique Messager, n’en est pas une : c’est une table ronde à laquelle elle a convié des Scrum Masters allant du néophyte à l’expérimenté, qu’elle-même coach chez Orange. Cet aréopage de Scrum Masters vient partager avec nous leurs points de vue sur leur travail, leurs manières d’aider les équipes et leurs sensibilités qui peuvent varier.
Le contexte
A l’origine, il y a un groupe d’échange de pratiques se réunissant tous les mois. Le produit de ce groupe d’échange est aujourd’hui une check-list de 52 bonnes pratiques. Véronique nous propose de les aborder regroupées en 3 thèmes, avec le panel de Scrum Masters. Hélas, les contraintes de temps nous limiteront à deux de ces thèmes.
Le changement dans la posture du Scrum Master
Un premier constat partagé est la perte de connaissance sur le code ! Le travail de Scrum Master tient ceux-ci de plus en plus éloigné de cette matière première. De cette perte de connaissance nait un certain sentiment de culpabilité : Suis-je toujours légitime dans mon rôle ? Le travail du Scrum Master n’est pas quantifiable, il n’est même pas visible car il n’a pas de raison d’être évoqué en stand-up. Une crainte qui n’est pas nécessairement étayée : il n’y a guère de remarques sur le fait que le Scrum Master développe beaucoup moins.
Malgré tout, le Scrum Master peut-il continuer à développer ? Les avis sont un peu plus partagés, mais des « oui » s’élèvent, toutefois tempérés :
- Pas question de prendre des tâches critiques ! A cet égard, binômer ou prendre en charges des corrections d’anomalies s’avèrent de bonnes idées.
- En tout état de cause, les tâches de Scrum Master doivent rester prioritaires.
- Rester impliquer dans le développement peut induire un travers de partialité lorsque des discussions s’engagent sur l’architecture, les solutions, etc. Il faut y prendre garde.
La maturité de l’équipe allant croissant, peut-on un jour se passer de Scrum Master ? Une question réccurente, que l’on a aussi trouvé sur Quora. Ici la réponse est unanime : non, le Scrum Master reste indispensable !
Par contre la question reste ouverte sur le Scrum Mastering à temps plein ou à temps partiel ! Si certains par ailleurs pensent qu’au final ce rôle peut tourner (ce que j’ai expérimenté), Bruno Margueritat ne suit pas cet avis, par exemple.
Motiver les membres de l’équipe
Comment s’appercevoir que cette motivation baisse ? En regardant la productivité de l’équipe (donc les « retards »). Véronique a une affinité particulière pour la Process Com, il n’est donc pas étonnant que les Scrum Masters présents évoquent cet outil pour comprendre le fonctionnement des membres de l’équipe.
Ils évquent aussi le temps libre : l’importance d’en ménager (par exemple entre les itérations), mais aussi d’observer comment ce temps libre est utilisé.
Donner du sens et visualiser l’avancement : c’est bien entendu un leitmotiv bien connu et pourtant souvent négligé. Mais il s’agit aussi d’impliquer activement les membres de l’équipe. Pour l’un des Scrum Masters cela passe par la délégation d’une partie des tâches … du Scrum Master ! Par exemple lors des rétrospectives. J’aime bien l’idée et l’état d’esprit !
Ce que j’en ai pensé
Nombreux sont les experts prêts à nous expliquer le rôle et la posture du Scrum Master. Tous ces experts ne sont d’ailleurs pas tous d’accord entre-eux (j’en fais partie !). Ici, ce ne sont pas des experts, mais des vrais praticiens de terrain avec différents niveaux d’expérience et une certaine variété de point de vue.
Du coup, je pense que l’échange aurait pu être encore plus riche avec des Scrum Masters venant d’autres horizons. Les débats auraient été plus intense, ce qui ne serait possible qu’avec un format un peu plus long toutefois.
La culture du programmeur, par Jean-Laurent de Morlhon
J’avais une double raison d’assister à cette session : tout d’abord J’aime bien Jean-Laurent qui est aussi un ancien collègue (double ancien collègue, devrais-je dire). Et ensuite le sujet éveille mon intérêt, même si ma propre crédibilité en tant que programmeur s’étiole certainement de jour en jour… Jean-Laurent est certainement la bonne personne pour transmettre cette culture, sans compter l’humour et le dynamisme qu’il met dans ses interventions. Celle-ci ne fera pas exception !
Pourquoi programmeur ?
Jean-Laurent nous explique quel était son plan pour devenir maître du monde et partir à la retraite à 35 ans. Cela n’a pas marché. Pour moi non plus, d’ailleurs. Car sa passion c’est programmeur (qu’il préfère à « développeur » ou « codeur »). Donc c’est « programmeur ». Et ça veut dire quoi ? Le Larousse dit qu’il s’agit « d’une personne de la préparation, de l’écriture et de la mise au point d’un programme pour ordinateur ». Pour les personnes en-dehors de notre domaine, ils sont souvent perçus comme des personnes aptes à faire des choses mystiques (t’es dans l’informatique ? Tu peux m’aider à brancher mon imprimante ?).
Mais hélas, dans notre milieu professionnel, nous sommes confrontés à un problème de jeunisme. Programmeur n’est pas considéré comme un métier au-delà d’une certaine tranche d’âge. Pour de nombreuses entreprises et écoles, l’évolution normale du programmeur est de devenir chef de projet !
Une culture
La culture, c’est ce qui lie les gens entre eux. Quels sont donc les éléments de cette culture ? L’une d’entre-elle est le « craftmanship ».
C’est avant tout une attitude de pragmatisme, un rééquilibre entre processus et technique. C’est aussi un état d’esprit d’amélioration qui passe par l’entrainement (les dojo, les code retreat, les kata). C’est évidemment utiliser les ressources en ligne : les MOOC sont partout, sur tous les sujets. La culture du programmeur, c’est aussi :
- Disposer des meilleurs outils que l’on puisse acheter : aujourd’hui, c’est disposer de grands écrans, de CPU puissants, ne pas être limité par la mémoire, booster les I/O avec des disques SSD, des environnements d’intégration, les bons IDEs, etc..
- Vivre en permanence avec de la frustration : nous passons un temps considérable à essayer de faire marcher des trucs … ou à essayer de comprendre pourquoi ils ne marchent pas !
Ce que j’en pense
Une session de « J-Lau », ça vaut toujours le déplacement. Certes, je n’y ai pas appris grand chose, mais je n’étais pas non plus le public visé. Mais la présentation fait un très bon boulot à faire toucher du doigt cette culture du développeur. A voir absolument pour les PO / MOA / Managers à qui sont étranger ces aspects.
Acceptance Tests Workshop
Voilà, c’est mon tour ! J’avais préparé cet atelier avec Benoit Nouyrigat afin de transmettre par la pratique un aspect du développement agile qui nous semble avoir un impact crucial : l’écriture de tests d’acceptance collaborativement entre les différents intervenants d’un projet. Nous avions donc structuré notre atelier en petites équipes, l’atelier lui-même nous conduisant depuis l’écriture de user stories sur notre étude de cas jusqu’à l’implémentation des acceptance tests en BDD avec Cucumber JVM !
Je ne vais pas détailler l’atelier ici, je réserve cela pour un futur post !
Ils ont aimé
- Clarifier les specifications en les « instanciant » avec des cas de test.
- Découvrir les cas aux limites qui font émerger des règles métier.
- Travailler collaborativement autour des cas de test.
Ils pensent que l’on peut améliorer
- La phase initiale, avec l’écriture des user stories par les équipe qui apporte peu.
- L’absence de temps pour s’approprier les persona.
- La brièveté du temps consacré à la partie « outils ».
Ce que j’en pense
Nous devons ajuster certaines parties, c’est tout à fait normal, compte tenu qu’il s’agissait d’une première. Je pense toutefois que les conditions ne nous ont pas permis de juger de l’atelier de manière adéquate : nous avions été programmé en toute fin d’après-midi (avec en plus un démarrage en retard), ce qui équivaut pratiquement à une garantie d’échec pour un atelier très intense comme celui-ci.
La première heure s’est très bien passé, mais la fatigue a rattrapé le groupe dans la seconde. En fait, je suis plutôt satisfait d’avoir eu une bonne moitié d’atelier, car je m’attendais à un échec complet. Les participants se sont même déclarés très satisfaits !
J’aimerais toutefois pouvoir jouer cet atelier dans de bonnes conditions pour avoir un meilleur aperçu de son impact.
Nous avons joué l’écriture des acceptance tests en deux temps, avec ou sans le style « given when then », mais nous n’avons pas donné d’indications suffisantes pour marquer la différence. A retravailler.
Une certaine déception de Benoit et moi-même sur la demande d’avoir plus sur la partie outil ! Notre expérience commune est que la différence se fait dans l’écriture collaborative (d’ailleurs la collaboration est à gauche et les outils à droite, si vous voyez ce que je veux dire…). Soit nous ne sommes pas parvenus à être assez marquants sur l’importance de cet aspects, soit notre public est incorrigible sur l’idée que les outils sont ce qui importe le plus. Nous avons là un sujet de reflexion pour la version 2.0 de notre atelier…
Le diner
J’ai fait l’éloge du lunch du midi, je dois les mêmes au diner auquel j’étais convié n tant qu’orateur. C’est bien sûr une belle occasion d’échanger avec les membres de la communauté…
… Ainsi qu’avec les joyeux membres du bureau.
J’ai aussi passé un très agréable moment avec Alex Boutin, à échanger sur ce que l’un et l’autre nous aimons faire, les questions que nous nous posons… Alex est l’une des personnalités de la communauté agile que j’apprécie le plus, pour son sens du partage et de l’invitation. Je n’en apprécie que plus ce genre d’opportunités.
Il est maintenant temps de retourner dans mes pénates. Rendez-vous bientôt pour la seconde journée de ces Scrum Days !
Agile France Open Space
Le mois de Février est généralement calme : un ou deux Meetup et bien sûr l’Agile Games France qui est pour moi l’évènement marquant de ce début d’année. Yannick Ameur a eu la bonne idée d’organiser un Open Space durant cette période calme.
Nous étions une petite vingtaine réunis pour cette soirée sous la houlette de l’association Agile France. Emmanuel Gaillot qui était des nôtres a d’ailleurs rappelé la mission de l’association.
Deux sessions au programme de cette soirée, entrecoupé d’un interlude. On y reviendra.
Comment convaincre sur la qualité du code
J’étais à l’initiative de cette première proposition. Enfin, deux autres sessions avaient lieu aussi en parallèle.
Mon problème :comment faire prendre conscience à une équipe “contente d’elle-même” de l’intérêt de chercher à s’améliorer, à perfectionner son code. Ma situation de départ : un code review où personne n’a rien à dire !
Des idées ont jailli. Je ne les essaieraient probablement pas toutes. Mais certaines méritent indiscutablement l’attention.
Mais l’échange me laisse à penser que lorsque l’on a pas encore éveillé l’intérêt, l’étincelle a bien du mal à prendre. Et il n’y a pas de solutions miracle. Seulement des choses à essayer qui marcheront peut-être, ou peut-être pas…
Interlude
Nicolas nous a gratifié d’un rapide jeux agile entre les deux sessions : le nombre secret. Il me rapelle celui sur les dates de naissances auquel nous avions joué durant le premier Agile Games France ().
Ca n’a pas trop mal marché.
Tester en agile
Pour ce second round, je me suis joins au groupe discutant des tests. Des discussions passionnées et des avis très partagés dans le groupe.
D’un côté les défenseurs de la séparation des pouvoirs : développeurs d’un côté, testeurs de l’autre. Les développeurs se limitent aux tests unitaires, les tests fonctionnels sont essentiellement exploratoires et fait par l’équipe de tests après la fin d’itération. Lorsque l’écart d’interprêtation entre développeurs et testeurs a fait son oeuvre (environ 10 secondes après que les testeurs aient reçu le système à tester), on saisie de gentilles anomalies et le tout peut retourner chez les développeurs pour une nouvelle itération. Itération au terme de laquelle on recommence le cycle. Ca booste à mort.
Autant dire que ce n’est pas ma vision des choses.
Les défenseurs de l’ATDD proposent de regrouper développeurs et testeurs au sein d’équipes pluridisciplinaires, de couvrir aussi bien que possible les items à développer de tests définis en amont (ce qui a aussi la vertu de les raffiner), et de tester “just in time” et non après la fin d’itération. Les tests exploratoires sont là seulement pour compléter les AT réalisés au début et pour, en quelque sorte, tester les tests !
Bref, deux visions inconciliables. Pour ma part, je pense que la première appartient à une époque révolue située quelque part dans le siècle précédent et n’a rien à voir avec l’agilité, ni dans son exécution, ni dans son état d’esprit. Mais cela me donne aussi une petite idée de billet, pour un de ces jours
Pendant ce temps, les sessions se déroulent dans d’autres salles
Fin de soirée
Les résultats de nos cogitations sont visible sur les murs. Ici le fruit d’une discussion sur le story mapping.
Les idées proposées pour cette soirée
Et bien sûr les inévitables discussions de fin de soirée. Peut-être le meilleur moment d’ailleurs !
