Les prévisions vous en disent beaucoup sur ceux qui les font, elles ne vous disent rien sur l’avenir.
Warren Buffet
Rendez-vous au Scrum Day 2014 !
Cette année le ScrumDay change de lieu ! La belle affaire me direz-vous : il a changé de lieu presque chaque année ! Mais cette fois, il quitte le centre de Paris pour aller chez Mickey.
Rassurez-vous, je suis presque sûr que nous ne serons pas obligé de nous coiffer d’une paire d’oreilles signées Walt Disney. J’animerais pour ma part un atelier avec mon collègue Benoit Nouyrigat. Allons-y pour une petite présentation : c’est l’Acceptance Tests Workshop !
Teaser, teaser…
Le développement guidé par les acceptance tests devient un standard dans le monde agile. Cela signifie que les tests fonctionnels seront au moins décrits avant le début des développement.
Mais partant de là, il existe de nombreuses façons de procéder, de multiples variations.
Cet atelier s’articule autour d’une pratique que nous utilisons régulièrement : l’acceptance test workshop. Il s’appuis sur l’intelligence collective pour faire émerger les tests fonctionnels pour valider le développement et assurer la compréhension partagée des fonctionnalités attendues.
Cet atelier vous donnera l’opportunité de pratiquer cette nouvelle technique sur des exemples que vous aurez construit.
Comment ça marche ?
Les participants à cet atelier forment des équipes de 4 à 5 personnes. A partir d’une courte étude de cas, ils devront élaborer quelques users stories sur la base desquels ils devront décliner des tests d’acceptance en groupe en revêtant des Personna (développeur, Product Owner, Testeur, etc.).
Lors d’une première phase, on cherchera à décrire les tests sous forme libre, en se concentrant sure la couverture de la specification en cas passants et non-passants.
La seconde phase accentuera l’aspect formel des spécification de tests via la formalisation Given / When / Then utilisée pour les tests BDD (Behavior Driven Development).
Voilà, vous savez (presque) tout sur ce quii se passera durant cette atelier. Libre à vous de vous joindre à moi et à Benoit !
ScrumBeer de Mars (en images)
Cela aurait dû être une ScrumBeer de Février, mais une collision de dates avec l’Agile Playground en a décidé autrement. C’est donc début Mars que nous nous sommes retrouvés en petit comité d’agilistes !
C’est dans un bar faisant la place belle aux jeux (et à la bière, bien sûr) que nous nous sommes retrouvés.
Outre nos discussions de comptoir habituelles, Arnaud nous proposait d’apporter notre contribution aux revues des propositions du ScrumDay 2014.
J’ai dit : le ScrumDay 2014 !
Après une rapide selection initiale, revue des propositions en binômes.
J’ai eu le plaisir de me livrer à l’exercice avec Pablo Pernot dont je dois dire que je le croise trop peu souvent !
L’exercice est intéressant, mais je le vois plutôt dans ce contexte comme une agréable récréation. J’espère que le comité de sélection ne regardera pas le résultat de nos cogitations de manière trop appuyée, d’autant que le filtrage initial a été particulièrement arbitraire !
Il faut un peu varier les plaisirs lors de nos rencontres. Mais pas trop quand même : les discussions, le p’tit verre de rouge ou la bière et la charcuterie, ça reste notre fond de commerce !
You have to make the rules, not follow them.
Isaac Newton
Note de lecture : IT Gouvernance, par Frédéric Georgel
Note : 7 ; Une très honnête introduction au sujet.
Si il est un sujet qui a le vent en poupe, c’est bien la gouvernance du SI ! Surfant sur cette nouvelle popularité, ce livre a pour but de nous en révéler tous les aspects. Et très franchement, je ne pense pas que ce livre puisse faire de nous le gourou de la gouvernance, mais il atteint très honorablement son but. Avec beaucoup de simplicité, il nous expose les domaines clés de la gouvernance IT et nous en explique les grandes lignes :
- L’alignement sur la stratégie
- Le management des ressources et des infrastructures
- La gestion de la gouvernance et des ressources humaines
- La maîtrise des risques sur le plan technologique et structurel
- La gestion de la performance des services délivrés
- Contrôle et audit des processus et des systèmes
- Valeur économique des ressources informatiques
- Maturité des infrastructures et des processus
Si la première partie nous dresse un sympathique contexte historico-culturel de l’émergence de la gouvernance IT (qui eut cru à l’importance du Colt 45 dans la façon d’appréhender l’égalitarisme pour nos voisins américains), les sujets évoqués ci-dessus font l’objet du seul chapitre 2. Et quel chapitre ! Il fait plus de 100 pages, donc plus de la moitié du livre ! C’est l’un des quelques reproches que je puis faire à cet ouvrage, par ailleurs moins sujet aux reproches récurrents que je peux faire à la qualité éditoriale des livres Dunod.
La troisième partie est dédiée à l’introduction aux 2 célèbres référentiels de la gouvernance IT : les incontournables ITIL et Cobit ! C’est bien sûr une excellente idée, mais hélas j’ai trouvé cette introduction confuse (même si un chapitre est consacré à chacun des référentiels). Peut-être devrais-je leur accorder une seconde lecture ?
En bref, je n’ai pas été déçu, ayant terminé les 180 pages du texte, j’ai la sensation de comprendre le sujet, sinon de la maîtriser. Je dois dire en outre, qu’il y a pas mal de références externes, et que le style de l’auteur, sans être extraordinaire nous fait grâce du style pédant qui est souvent la marque de fabrique des ouvrages français. On attend de l’auteur qu’il donne son avis et prenne position : il le fait !
Référence complète : IT Gouvernance, maîtrise d’un système d’information – Frédéric Georgel – Dunod 2005 – ISBN : 2-10-008312-0
Agile Playground #13
Retour chez Valtech pour cette nouvelle édition des Playgrounds. Aujourd’hui nous avions le choix entre deux jeux aussi attrayants l’un que l’autre : la Pompafric (présentée à l’Agile Game France 2014) mais que je n’avais pas expérimenté et le Values Advocacy. C’est Pierrick qui nous présente le programme.
Ice-Breaker
Pour amorcer joyeusement cette soirée, on a droit à un “nombre secret”, le même jeux que nous avions pu essayer lors de l’Open Space Agile France. Du coup, me voici exclus du jeu, c’est pas juste ! J’observe les efforts plus ou moins vains des participants pour se faire comprendre…
L’alignement final est assez étrange : on y a des “ordonancements locaux” signe qu’il a manqué une vérification de cohérence entre les groupes. Une mention spéciale à celui qui a tenté de se faire comprendre en convertissant son nombre en “taille de Schtroumph” !
Values Advocacy
Finalement, je me décide pour le Values Advocacy. En entrant dans la salle, on découvre le déroulement de la session affiché au mur, sous forme de fresque !
Le principe est assez simple : 4 équipes et les 4 valeurs agiles … et leurs “opposés”. On effectue une série de batailles : deux équipes s’affrontent pour défendre une valeur du manifeste et leur contraire. Les deux autres équipes forment le jury. Ensuite on tourne. C’est donc une sorte de tournante, mais en tout bien tout honneur. A la fin du jeu, chaque équipe aura eu l’opportunité de défendre une fois une valeur, une fois l’opposé d’une valeur, et de faire partie du jury deux fois. Il y a ensuite un système un peu compliqué pour compter les points, mais ce n’est pas très important.
Action !
Round 1 et 2
Chaque équipe prépare son plaidoyer. Pendant ce temps les membres du jurés circulent pour évaluer les idées qui émergent.
Un premier tour de vote a lieu à la fin du temps de préparation des plaidoyers.
Chaque équipe doit ensuite défendre ses idées et convaincre. Comme le fait ici Pascal.
Ou Corina
Un second tour de vote a lieu à l’issu de cette étape. La note final est une aggrégation un peu curieuse des deux votes.
Le second round se fait selon le même modèle (mais pas les deux mêmes équipes).
Rétrospective
A l’issu des deux premiers round : une rapide rétrospective.
Nous remontons essentiellement deux points :
- Le temps de préparation des plaidoyers devrait être raccourcis
- Il serait sympa de scénariser un peu le volet délibération / jury
Pas possible d’adresser le second point dès maintenant. Mais le premier est pris en compte : nous diminuons le temps de préparation de 8 minutes à 5.
Rounds 3 et 4
C’est donc reparti avec un rythme un peu plus soutenu. On prépare les argumentaires…
On s’active pour défendre ses positions.
L’une des équipes se trouve réduite à 3 membres, mais visiblement le nombre ne fait pas la force…
Et de nouveau, bien sûr, les plaidoyers !
Résultats et conclusions
Par deux fois les antithèses agiles ont battu les valeurs du manifeste et l’inverse est aussi arrivé par deux fois ! Que doit-on en penser ?
- Tout d’abord que les équipes ont fait du bon boulot à défendre les idées auxquelles elles sont opposées. Pour tout avouer, c’est même beaucoup plus drôle !
- Le Jury ont fait du bon boulot à juger en toute impartialité.
Au fur et à mesure du jeu, les plaidoyer ont aussi évoluer pour donner plus d’impact à la forme. Cela a finalement peu joué. Une équipe est d’ailleurs tombé dans le travers d’articuler complètement l’argumentaire autour de la forme, mais la faiblesse de cet argumentaire a joué en leur défaveur (alors même qu’ils défendaient les valeurs du manifeste) !
La réduction du temps de préparation a donné plus de rythme à la seconde partie, mais comme vous le voyez ci-dessous, l’impact sur le nombre d’arguments développés, bien que visible, n’est pas si important que cela.
Le jeu est réellement plaisant et nous oblige à réfléchir honnêtement non seulement à nos valeurs agiles que nous prenons pour acquises, mais aussi à ce que peuvent apporter leurs opposés. Ou au moins à comprendre à ce que les anti-agilistes y trouvent.
Curieusement d’ailleurs, je me suis retrouvé confronté dès le lendemain à ce cas de figure ! Nicolas a évoqué l’usage de ce jeu dans des groupes composés d’agilistes et d’anti-agilistes (ou de nouveaux venus). Je ne suis pas certain que l’on y obtienne les résultats escomptés. Notre population a fait un bon travail à argumenter solidement les deux côtés. Des anti-agilistes feraient-ils de même ?
Bref, j’ai passé un très bon moment. Mais je m’interroge encore sur l’usage que l’on peut faire de ce jeu. Vous retrouverez le vécu de la session sur le billet de blog de Nicolas.
Fin de soirée
Comme à l’accoutumé, on termine notre soirée de manière informelle autour d’un petit verre ou d’une bière.
Je ne m’éternise pas ce soir, j’ai une journée chargée le lendemain. Justement avec des agile games !
You only live once, but if you do it right, once is enough.
Mae West
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 !
La galerie de mes photos à Agile Grenoble 2013
Je vous avais infligé mon point de vue sur Agile Grenoble qui avait eu lieu fin novembre 2013 ici et ici ; Voici maintenant la galerie complète de mes prises de vue lors de cette journée
agile-grenoble2013, un album sur Flickr.
I think I should understand that better, if I had it written down: but I can’t quite follow it as you say it.
Lewis Carroll
Software Freethinker 
