Cette présentation a été fait par Henrik Kniberg en 2010 à Kiev. Elle reprend les points essentiels de l’approche agile et fait le tour d’horizon des principales méthodes qui en sont issues (XP, Scrum, Kanban), avec toutefois un focus particulier sur Kanban.
Étiquette : agile
L’agilité à grande échelle chez Spotify, par Henrik Kniberg & Anders Ivarsson
Dans cet article, les auteurs décrivent la façon dont Spotify est parvenu à maintenir une dynamique agile malgré une montée en taille importante et rapide sur les 6 dernières années. Elle s’appuie sur un petit nombre de concepts organisationnels
Les squads
A mi-chemin entre la Scrum Team et la Feature Team, le squad est doté d’une mission sur le long terme, possède un espace de travail en propre et regroupe toutes les compétences nécessaires à sa mission. Son mode de travail s’inspire du Lean Startup, mais ici on appelle cela “think it, build it, ship it, tweak it”. Les squads bénéficient aussi des 10% hack days inspirés des 20% ou des exploration days de Jurgen Appelo (c’est la même chose).
L’objectif, sinon la clé est d’avoir des squads autonomes.
Les tribus
Les squads sont nombreux : il y en a 30 chez Spotify. Ils sont regroupés en tribus. Une tribu est focalisée sur une problématique métier particulière est fonctionne un peu en “incubateur de startup”. Elles sont de taille variées mais ne dépassent pas 100 personnes.
Les tribus organisent leur propres rassemblements et partagent outils, idées, etc…
Les chapitres
Ce sont des regroupements “transverses” de personnes de même domaine d’expertise. Ils se rencontrent régulièrement pour partager outils, expérience, challenges, etc.. Chaque chapitre est géré par un manager qui est de fait le responsable hiérarchique de ses membres … mais est lui-même membre d’un squad avec des responsabilités opérationnelles ! Les chapitres sont locaux aux tribus.
Les guildes
Ce sont des communautés d’intérêt, plus informelles que les chapitres. Elles sont transversales à l’entreprise et regroupent souvent les chapitres correspondant des différentes tribus. L’animateur d’une guilde l’est à temps plein.
Là aussi, la lecture du Management Workout de Jurgen Appelo peut être instructive…
L’organisation dans son ensemble
Elle est en quelque sorte matricielle. La dimension dominante est celle du “quoi”, l’axe opérationnel, donc les squads et les tribus. Il y a une seconde dimension, celle du “comment” qui correspond aux chapitres et aux guildes.
Et bien d’autres choses…
Voilà, il s’agit juste de l’apéritif pour vous encourager à lire cet article par ailleurs fort bien écrit et illustré. Il y a de nombreux éléments que j’ai passé sous silence, comme la gestion des dépendances entre les squads.
Spotify est une entreprise dont la structure dominante est tournée vers l’opérationnel. Elle rompt avec les structures traditionnelles orientées compétences qui fragmentent l’organisation en silos, obligeant les projets à franchir les obstacles entre ces silos, consommant temps et énergie et souvent aussi hélas, vidant les projets de leur substance !
User Stories … What else ?
Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !
Le teaser
Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.
Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.
Ce que vous allez en retirer
Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !
Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !
Carnet de route : Agile Grenoble 2013 en Images (2/2)
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 !
Carnet de Route : Agile Grenoble 2013 en images (1/2)
Agile Grenoble 2013, cela commence par des chutes de neige ! Elles ne sont peut-être pas très conséquentes entre Paris et Lyon…
Mais il en va autrement entre Lyon et Grenoble, à tel point que je ne peux poursuivre mon voyage comme prévu le mercredi soir : plus aucun train ne circule ! Pire encore, pas moyen de trouver une chambre d’hôtel, je vais donc loger chez l’habitant !
Here we are
Après un trajet eneigé en voiture au petit matin, nous y sommes. J’y suis moi pour la première fois, à cet Agile Grenoble ! Hop, perception du badge.
Et du sac à dos “Agile Grenoble”. Il est réservé aux orateurs, et il est bien mieux que le sac à ds promo standard ! C’est cool !
Dans la foulée, montage du stand Zenika. Au vu des intempéries, on craint le pire en ce qui concerne la fréquentation de l’évènement et surtout la présence des orateurs. Finalement il y aura bien eu quelques absents, mais on ne s’en sort pas trop mal. Idem avec les participants : au total 90 personnes n’auront pu venir. Mais les organisateurs auront eu fort à faire pour réajuster le programme en temps réel !
Mot d’ouverture
Le grand amphi du WTC de Grenoble a belle allure. Il autorise les 540 inscrits à cette conférence (la plus grande de France sur l’agilité), même s’il n’est pas totalement rempli aujourd’hui.
Le traditionnel mot des organisateurs ouvre ce nouvel opus d’Agile Grenoble.
Place à la Keynote de Neal Ford !
Keynote de Neal Ford : When geeks leak
Neal Ford est un orateur de très bonne tenue. D’ailleurs il est l’auteur d’un ouvrage sur les patterns de présentation. Toutefois sa prestation du jour ne m’a pas laissé un souvenir impérissable.
Sans doute le propos était-il un peu trop décousu à mon goût, même si Neal Ford est un orateur de premier ordre. Mélant histoire des sciences (avec une prédilection pour Richard Feynman), application des sciences au monde moderne et techniques de présentations, le propos est difficile à syntéthiser ici. Je doute hélas que le support de présentation ci-dessous aide beaucoup : la présentation m’a aussi aidé à comprendre la différence entre un support de présentation et un “info deck”. Et ce n’est pas un info deck.
Premier créneau des présentations
J’ai aussi séché le créneau horaire suivant : j’ai pris pour habitude de passer l’heure précédent mes présentations à passer en revue celle-ci, afin de me remémorer l’ordre de passage de mes slides, la teneur de mon propos et surtout les transitions entre eux. C’était d’autant plus important aujourd’hui que je n’avais pas eu le temps de faire ne serait-ce qu’une répétition !
Le hall se vide, on n’y croise plus que les organisateurs qui profitent de ce moment de répis pour souffler…
Users stories … what else ?
C’est mon tour de passer sur scène. On m’avait réservé une salle pouvant contenir 55 personnes. Finalement il faudra rajouter des chaises, des personnes resteront debout, d’autres finiront par terre. On était plutôt aux alentours de 70, sans compter celles qui feront demi-tour, rebutées par la foule ayant investi le lieu !
Je posterai bientôt mon support de présentation. Et plus tard, si j’ai le courage, cette présentation sous forme d’article. Mon but était d’éveiller l’intérêt des Product Owners envers les techniques de structuration et de recueil des besoin et aussi aux sujets annexes : vision, stratégie, marketing, etc… Je souhaitais aussi vérifier si l’approche consistant à venir étayer le métier de PO avec le corpus de connaissance de l’ingénierie des exigences et autres domaines non familiers des agilistes attirait l’intérêt. C’est ce qu’il me semble au vu des réactions très positives. Il va bientôt falloir enclencher la seconde étape !
Pause déjeuner
L’heure du repas arrive et l’espace centrale est rapidement envahi de tables où l’on déjeune en échangeant sur ce début de conférence. Les cartons-déjeuner sont très pratiques, je dois dire !
Du côté de l’espace partenaires, on peut opter pour un mange-debout.
J’opterais moi-même pour cette solution pour déjeuner en compagnie de Caroline Damour-Nobi et Pascal Van Cauwenberghe. Ah oui : nous avons aussi reçu la visite des hommes invisibles pendant notre déjeuner !
Les scribers !
Peu de personnes étaient au courant du hacking planifié par Romain Couturier et Jacques Couvreur. Je crois même que j’étais le seul à être au courant avant le début de la conférence. Romain et Jacques sont des “scribers” très talentueux : Ils prennent toutes leurs notes sous forme graphique. Ils ont eu la fantastique idée de se balader dans la conférence ainsi équipés en hommes-sandwiches, scribant à tour de rôle l’un sur l’autre les conversations qu’ils écoutaient en tant qu’hommes invisibles !
Ils poursuivront cet exercice durant les sessions. C’était leur première tentative. Il y a fort à parier que nous les reverront dans cet équipage lors de prochaines manifestations ! Pour ce premier essai, Alexandre Boutin n’était pas du tout au courant, il a été aussi surpris que les autres (sauf moi).
Un grand merci à Romain et Jacques pour cette animation vraiment différente et d’excellente qualité !
Passer à la suite…
La pause déjeuner touche à sa fin.
Vous êtes peut-être un peu déçu, car j’accorde souvent bien plus de place pour parler des sessions ?
Je vais essayer d’un peu me rattraper lors de mon prochain post !
L’agilité, une question de feedback
J’avais évoqué, lors d’une présentation en 2012, la question du feedback et son rôle majeur en tant que moteur de l’émergence.
J’aimerais revenir sur ce sujet qui me tient à coeur et le développer plus avant ici. Je vais aussi tenter de lui donner, modestement, un petit éclairage historique.
Les boucles du feedback
Pourquoi focaliser sur le feedback ? En fait, nous pouvons interpréter une grande partie des pratiques d’ingénierie et de projets agiles sous forme de boucles de feedback imbriquées. c’est ce que j’avais fait lors de mon lightning talk sur l’émergence. En voici l’illustration.
Nous reviendrons sur cette illustration un peu plus tard. Car on peut aussi présenter ces boucles de feedback autrement. Elles ne sont pas le fruit de ces 10 dernières années. L’émergence progressive de ces boucles de feedback a commencé il y a bien longtemps. Longtemps avant que l’on parle d’agilité.
Un regard historique sur les boucles de feedback
Compilation interactive
La plupart d’entre-vous n’avez pas connu cette époque, mais vous savez certainement qu’il fut un temps on l’on saisissait les programmes sur ceci
Chaque carte représente une ligne de code, plus exactement 80 colonnes de texte. Le processus est le suivant :
- On écrit son programme sur papier.
- Dès qu’on l’a rédigé (et vérifié, croyez-moi, c’est mieux), on va le saisir sur un terminal produisant une carte par ligne de texte.
- On donne la pile de cartes au centre de calcul. Ce dernier va programmer sa compilation et son exécution. Ce ne sera pas pour tout de suite, probablement dans quelques jours.
- Quand le job est passé … on vous donne le résultat … ou pas !
Une de mes anciennes collègues m’a ainsi racontée qu’elle a reçu un jour en retour sa pile de cartes entourée d’un élastique et d’une note rageusement libellée : “fait planter la machine !”.
Une anecdote hélas probablement pas si rare que ça…
J’ai à peine connu cette époque. mais à mes début, j’empruntais un ordinateur de poche 2 jours par semaine. Je n’avais que ce créneau à ma disposition pour saisir et tester les programmes que j’avais écrit sur papier pendant le reste de la semaine. C’est un peu le même cas de figure.
Cette période est révolue depuis longtemps. Au début des années 80 nous sommes passé de la compilation batch à la compilation interactive. Ou à peu près. On est passé de délais de feedback de quelques jours à quelques minutes (et quelques heures dans le cas de gros projets)
Coloration syntaxique
Il y a certes eu de discrets essais sur des environnement confidentiels dans les années 80 et même avant, mais comme beaucoup j’ai découvert la coloration syntaxique avec un IDE mainstream : Borland C++, au début des années 90.
Je me souviens avoir assisté à la présentation de lancement de l’IDE. Le public a littéralement réagit à la seconde où le présentateur a dévoilé la fonctionnalité.
C’est le feedback sur la syntaxe d’écriture du programme que cette fonctionnalité adresse. Passer de quelques minutes, c’est à dire le délai entre deux compilations, à quelques secondes est une amélioration conséquente.
Complétion de code
De la coloration à la complétion, il n’y a qu’un pas. C’est le feedback sur notre implémentation que cette fonctionnalité adresse en nous proposant les méthodes disponibles.
Vous allez me dire qu’il ne s’agit pas de feedback ici. Vous avez raison. C’est mieux, cette fonctionnalité anticipe le feedback, le rendant inutile. Disponible assez tôt dans les environnements Smalltalk, il faudra attendre la moitié des années 90 pour voir cette fonctionnalité se démocratiser.
Compilation continue
Egalement amorcé par Smalltalk, c’est dans Visual Age Java que j’ai vu pour la première fois cette fonctionnalité faire son apparition, vers la fin des années 90. Cette fois c’est la justesse grammaticale sur laquelle le feedback passe de quelques minutes à quelques secondes.
Agilité et feedback
J’ai dit que nous reviendrions sur l’illustration des boucles de feedback. Nous allons le faire. Mais pourquoi s’intéresser au feedback, en quoi ce mécanisme est-il important et si particulier à la pensée agile.
Parce qu’en tant qu’être humain, et même en fait en tant qu’organisme vivant, c’est notre principal mécanisme d’adaptation. Et l’adaptation au changement, ça figure quelque part dans notre manifeste agile, j’en suis pratiquement sûr…
La rétrospectives
Cette pratique n’est pas à proprement parler nouvelle. les rétrospectives de projets (alors appelés post-mortems) ont probablement plusieurs décennies d’existence. En quoi est-ce différent ici ? Pourquoi faire des rétrospectives plus souvent ?
La rétrospective est le mécanisme d’adaptation de notre processus. Un post-mortem de projet sert surtout à se lamenter, la rétrospective d’itération sert à adapter notre processus et nos pratiques agiles.
Cycles itératifs
J’entends souvent les équipes parler de “lotir” les itérations. C’est ce que l’on fait dans les processus itératifs. Seulement le lotissement n’a rien à voir avec l’adaptation.
Le cycle itératif agile utilise ce que l’on a appris de l’itération qui vient de se dérouler pour réévaluer les priorités et la pertinence des items figurant dans le backlog ou comme opportunité d’émettre de nouvelles idées, d’aller plus loin dans les fonctionnalités venant d’être développées.
Acceptance tests
Nouveau venu de nos pratiques agiles, le test d’acceptance nous permet d’avoir du feedback sur l’implémentation des stories, lorsqu’ils sont exécutés. Mieux encore lorsqu’on les écrit, ces tests d’acceptance donnent du feedback sur les user stories elle-même ! Ecrire des tests d’acceptance, c’est instancier les spécifications, lever les ambiguïtés, se décider sur les cas aux limites, générer de nouvelles questions.
Integration continue
Il y a un temps pas si lointain où l’intégration représentait une phase majeure, longue et risquée des projets. Le feedback sur le fonctionnement conjoint des différentes briques se faisait alors sur des cycles allant de 3 mois à deux ans.
C’est avec émotions que nous repensons parfois à ces périodes particulières des projets qui occupaient nos soirées et nos week-ends avec enthousiasme, au lieu de manger des chips et boire de la bière devant un match de foot…
Avoir la température, non seulement sur l’intégration, mais sur la qualité du code et la couverture de test, cela fait aujourd’hui partie de notre quotidien. Next !
Tests unitaires
En parlant de quotidien, en voilà un sur lequel je ne vais pas non plus m’attarder : les tests unitaires nous donnent du feedback sur le fonctionnement du code : fait-il ce à quoi nous nous attendons qu’il fasse ? C’est aussi de l’acquis : next again !
Pair programming
On pense souvent au pair programming comme à une technique de collaboration. C’est vrai. Mais c’est aussi et surtout une technique de peer review en temps réel et en continue. Un feedback sur l’écriture de code et les choix de conception fait en temps réel.
Mais aussi …
Le feedback des pratiques agiles ne s’arrête pas là. Après tout, toutes ces techniques sont plus ou moins déjà identifiées comme des techniques de feedback.
Management visuel
Les projets agiles aiment s’afficher. C’est aussi une forme de feedback
- De la part de chaque membre de l’équipe envers tous les autres.
- De la part de l’équipe vers tous ceux qui souhaitent savoir ce qu’il s’y passe.
Lean startup et le validated learning
A plus grande échelle, le cycle agile peut servir à donner du feedback, non plus à l’échelle du projet, mais à celle du business. Lean Startup étend la portée des cycles de feedback au-delà du déploiement, jusqu’à l’usage du produit afin de vérifier les hypothèses produit : persévérer ou pivoter.
De la seconde à l’entreprise
L’agilité fonctionne en harmonie avec le feedback. Mieux, elle guide chaque action par cette simple interrogation : comment vais-je évaluer que je suis satisfait du résultat ? C’est la mise en oeuvre du PDCA de Deming depuis les cycles les plus courts jusqu’aux décisions les plus impactantes.
De l’agilité pour mon projet, pour quoi faire ?
J’avais évoqué lors de mon teasing de la DevFest 2013 la présentation que Martin Mouterde et moi-même y ferions. Vous trouverez le support de cette présentation ici.
Préparer une présentation à quatre mains n’est pas un exercice facile. Comme j’ai des idées tranchées et personnelles (mais pas nécessairement bonnes, toutefois) de ce à quoi devraient ressembler des présentations, il reste improbable que je sois réellement satisfait du résultat. Ne comptez toutefois pas sur moi pour dire qui a engendré quoi.
J’ai hésité à modifier cette présentation avant de la poster. Finalement je me suis dit qu’elle devrait figurer telle qu’elle a été jouée () . Même si je la modifie de manière substantielle si je sui amené à la rejouer…
Carnet de route : DevFest 2013 à Nantes, en images (2/2)
Pause déjeuner
Suite de notre parcours de la DevFest. La pause déjeuner à la DevFest, c’est standing. Ca change des sandwiches qui sont le quotidien de certaines autres conférences que l’on ne nommera pas…
Le service ne semble pas en reste.
D’un autre côté, il semble qu’il nous faille mériter notre pitance. La file d’attente s’allonge terriblement.
Passant sur le second créneau de l’après-midi, j’ai courageusement choisi de sauter la première séance d’après-déjeuner afin d’être fin prêt. Nous avons une salle “réservée orateurs” à cet effet.
Christophe Addinquy & Martin Mouterde : De l’agilité pour mon projet, pourquoi faire ?
C’est notre tour, à Martin et moi-même. Notre session d’introduction à l’agilité n’est pas vraiment un thème “mainstream” de cette DevFest, il est donc peu surprenant qu’elle n’attire pas foule. Une trentaine de personnes environ.
Je ne vais pas faire de résumé de notre session ici. Je posterais le support plus tard.
Why Google+ Sign In ? Par Ian Barber
Gros fail pour cette session. J’aurais pu me douter qu’elle était en Anglais (et j’avoue que le sujet ne me passionne pas assez pour avoir envie de faire un effort). Mais pire, elle était retransmise par Hang out !
Pour être honnête, je n’ai pas fait d’effort et me suis laissé décrocher assez rapidement. Pas de résumé, donc pour cette session. Je ne suis même pas sûr que le préposé au Hang out ait trouvé cela palpitant !
Break de l’après-midi
Une pause avant la dernière ligne droite. C’est l’occasion de faire un petit tour.
D’aller s’intéresser au paysage, aussi.
Ou de voir ce que j’ai bien pu rater au programme (et essayer de ne pas rater la dernière session).
Web Components, l’avenir des développeurs Web, par Julien Vey
Pour ma part, ce fut la meilleure session de la journée, par son contenu et la maitrise du sujet par Julien. Par exemple, on crée des <div> que l’on masque ou l’on crée du DOM via du Javascript…
Demain, il suffira d’utiliser la balise <template> pour créer des fragments HTML qui seront parsés mais ni chargé, ni exécuté, mais qui pourront l’être en instanciant ce fragment d’arbre en Javascript via cloneNode().
Le shadow DOM est un nouveau moyen d’encapsuler un élément. Il est utilisé par exemple dans le cadre de la balise <video>. Mais ce concept est aujourd’hui fermé. Il sera disponible demain aux développeurs, via la méthode createShadowRoot() qui crééra un élément auquel il suffira d’accrocher des sous-éléments. L’un d’entre-eux pourrait d’ailleurs être une balise <content> pour injecter du contenu dans ce shadow DOM.
On peut apparemment mixer DOM et CSS, mais comme je suis imperméable à ces considérations, le mieux sera pour vous d’aller gambader dans les la vidéo de le session de Julien !
Enfin, les Web Components permettent de créer ses propres balises, via la balise <content>.
Bref, les Web Component, c’est l’avenir. Du moins, ce le sera quand la norme sera finalisée, ce qui n’est pas encore le cas. On pourra alors intégrer des Widgets d’un nouveau genre qui ne ressembleront plus à un amas sordide de <div> et de Javascript ! Toutefois, il n’est pas nécessaire d’attendre ce jour béni. On peut déjà utiliser Polymer qui émule l’état actuel de la norme.
Outre l’excellente présentation de Julien, on peut aller vers le site de référence sur HTML5, à savoir htmlrocks pour en savoir plus et surtout trouver les bons tutoriaux !
Check out
La DevFest touche à sa fin, quelques irréductibles s’essaient encore au zPilot et il sera temps de plier les gaules.
Un bon DevFest en ce qui me concerne. Si les sessions front-end sont assez loin de mon habitat naturel, j’ai réussi à ne pas être trop largué, ce qui est déjà pas mal pour moi…
Andy Hunt: Uncomfortable with Agility: What has Ten+ Years got us?
La propriété fondamentale de l’agilité est l’aptitude au changement, la capacité d’évoluer en utilisant le feedback comme moteur de cette évolution.
Nous découvrons de meilleures façon de travailler … tels sont les premiers mots du manifeste agile. Ils ne disent pas “nous connaissons”. Alors pourquoi l’agilité a si peu évolué ces 12 dernières années ? Nous restons ancrés sur XP et Scrum, peut-être un peu mâtiné de Lean…
Andrew Hunt revient sur ce que signifie être agile, et non “faire agile”. Une présentation qui retourne au coeur de l’état d’esprit agile, par l’un des auteurs du manifeste.
(Source: https://player.vimeo.com/)
The benefit of allowing a team to self-organize isn’t that the team finds some optimal organization for their work that a manager may have missed. Rather, it is that by allowing the team to self-organize, they are encouraged to fully own the problem.
Mike Cohn
Software Freethinker 