Note de lecture : ATDD By Example, par Markus Gärtner
Note : 3 ; Mélange des genres…
Je sors assez désappointé de la lecture de ce livre assez succinct de 185 pages. Heureusement la lecture n’en est pas trop longue, d’une part du fait du nombre de pages et d’autre part du fait du format plus réduit que d’habitude. L’ouvrage est découpé en 3 parties, les deux premières sont dévolues à des études de cas tandis que la dernière évoque les principes de l’ATDD.
La première partie est consacrée à la gestion d’un parking d’aéroport. Elle couvre 50 pages environ sur 4 chapitres. Ca commence relativement bien au premier chapitre, sous la forme d’un dialogue entre le développeur et le responsable métier. Bien que cela n’ait rien de grandiose et ne m’ait rien appris, cela m’a même semblé assez basique. Et puis rapidement aux chapitres 2 et 3, on cause outils, Selenium pour être précis. Je ne m’attendais pas vraiment à un cours (pas terrible de surcroit) sur les fixtures Selenium. Tant pis ! Le dernier chapitre évoque la collaboration et le wishful thinking sur 4 pages, c’est assez creux. Cela ira peut-être mieux sur la prochaine partie ?
En fait non, c’est pire ! Cette partie déroule également sur 4 parties, mais sur 75 pages cette fois, la gestion de feux de croisement tricolores. Le chapitre 5 est une description du fonctionnel. Comme tout ça reste assez simple, on va être autonome : on ne va pas s’encombrer d’un spécialiste fonctionnel qui va trainer dans nos pieds pendant qu’on code, n’est-ce pas ? Et hop ! Dès le chapitre 6 on saute à pied joints dans des fixtures Fitness. Un peu de code… un peu de refactoring… c’est franchement brouillon, difficile à suivre mais l’auteur à l’air très fier de lui. On se souvient au chapitre qu’on est sensé écrire des cas de test. On gribouille donc quelques tables et c’est reparti pour une très ennuyeuse tirade de code et de refactoring. Le chapitre 8 conclut cette partie : testez votre « glue code » ! Ah ouais ? OK…
Tous mes espoirs reposent donc sur la 3ème partie. Vais-je y trouver ce que j’étais venu chercher ? Elle compte 5 chapitres sur 60 pages. Au chapitre 9, l’auteur évoque la nécessité de s’appuyer sur des exemples. En résumant (visiblement) tant bien que mal les propos de Gojko Adzic. Au chapitre 10 il parle de la nécessité de spécifier en collaboration en reprenant péniblement la prose de Mike Cohn qui l’a lui même emprunté à Suzanne et James Robertson (je fais référence au « trawling requirements » par exemple). Mais cela l’auteur semble l’ignorer. Sur les deux chapitres suivants (automatisation des tests et « clean tests ») l’auteur est un peu plus chez lui, ça va mieux. Le dernier chapitre ? Ah, bah…
Ce livre est une déception. Il est à côté de son sujet et s’intéresse plus au refactoring ou au TDD et au mieux aux interfaçage avec les outils de test d’acceptance. La presque totalité du travail avec les acceptance tests est passé sous silence. Pire, j’ai eu l’impression que l’auteur « s’écoute coder », mais même ces trop longues parties ne parviennent pas à être intéressantes. Peut-être cela l’est-il d’avantage en « live »…
La seule conclusion valable de cette lecture est qu’il faut donc que je m’attaque au fameux « specification by example » pour rattraper tout ça.
Référence complète : ATDD By Example, A practical guide to acceptance test-driven development – Markus Gärtner – Addison Wesley / Signature series 2013 – ISBN : 978-0-321-78415-5
Note de lecture : Agile Metrics in Action, par Christopher W. H. Davis
Note : 3 ; L’agilité à mi-chemin.
Ce livre est une déception, je n’ai hélas pas d’hésitation à cet égard. Il est vrai que l’on manque souvent sur les projet agile à mesurer des choses alors que la collecte de faits tangibles est la base d’une démarche Lean ! L’origine de cet ouvrage est un système de collecte de mesures pensé et développé par l’auteur et déployé sur les équipes dont il était le manager. Ce système collecte des données depuis Jira, Github, Jenkins, la plateforme de déploiement et Google Analytics, pour ensuite consolider cela. Une idée tout à fait brillante. Malheureusement, comme nous allons le voir, le livre ne parvient pas à valoriser cela.
La structure de l’ouvrage suit en grande partie les 5 grandes « travées » que l’auteur voit dans le développement agile. Il est organisé en 10 chapitres format 3 parties, le tout totalisant 220 pages. A cela il faut ajouter les 2 annexes qui ajoutent près de 20 pages : celles-ci apportent quelques éclaircissements sur la chaine de collecte conçue par l’auteur. La première de ces parties ne compte qu’une trentaine de pages sur deux chapitres. Le premier d’entre-eux « Measuring Agile Performance » dresse sur près de 20 pages un tableau du problème que l’on s’efforce de résoudre. Je ne suis que partiellement d’accord avec l’auteur, par exemple quand il prétend que l’on a pas une vue claire de nombreux concepts comme celui de « bonne qualité » ou qu’il pointe du doigt le focus sur le produit plutôt que sur le projet comme un problème !
Le second chapitre « observing a live project » nous donne un éclairage sur le fonctionnement du projet s’appuyant sur les collectes de métriques. On y voit que les mesures de productivité ont une part prépondérante (vélocité, nombre de lignes modifiées). On voit aussi que la peinture agile du projet présente de nombreuses craquelures : l’utilisation des mesures ressemble à du contrôle en bonne partie, destiné à un « leadership team », joli contresens pour appeler ce qui n’est autre qu’une équipe pilotage (a.k.a. « papa-maman »). Une autre observation, qui sera récurrente, est que la plupart des diagrammes sont difficiles à interpréter. La plupart du temps, je ne suis pas parvenu à comprendre comment l’auteur parvenait à ses conclusions…
La seconde partie « collecting and analysing your team data » est nettement plus importante, avec 90 pages et 4 parties. Il débute avec la chapitre 3 « trends and data from project-tracking system » qui occupe 24 pages. On commence fort avec une orientation forte : abandonnez votre management visuel physique pour ne garder que l’outil électronique (ici Jira). La capacité de tracking semble avoir le pas sur le bien-être de l’équipe… C’est néanmoins l’un des chapitres les plus clairs. Mais les mesures tournent beaucoup autour de la productivité et des temps de développement.
Le chapitre 4 évoque sur 20 pages les métriques issues du système de versionning, en l’occurrence Github. Comprendre comment extraire des données de Github est réellement intéressant. Ici, c’est surtout le volume de lignes modifiées, l’activité de l’équipe autour des commits, le délai entre pull request et commits ou la présence de commentaires qui sont regardés. Je ne suis pas certain que le CLOC soit une mesure si pertinente, alors que la corrélation entre tâche et impact des changements dans l’espace (nombre de classes, nombre de packages) aurait donné un éclairage en terme de qualité. J’ai bien aimé l’idée de la mesure du « lagging pull », de l’interprétation des commentaires, et aussi la corrélation avec Jira, mais en fait guère plus.
Au chapitre 5, ce sont intégration continue et déploiement continu qui sont à l’honneur, et c’est Jenkins qui illustre cela. La chaine de build et les informations exploitables de Jenkins sont bien abordés, apparemment cet aspect est l’un des points forts de l’auteur. Malheureusement encore, l’auteur échoue à produire des diagrammes traduisant clairement son propos. J’imagine qu’ils sont moins hermétiques quand on est dans le projet, mais c’est assez douloureux pour le lecteur…
Cette seconde partie se referme sur la chapitre 6 qui se focalise sur la surveillance de la santé du système en production. C’est sur New Relic et StatsD que la collecte de ces informations repose. Un chapitre très intéressant aussi bien sur la finalité des mesures que sur quelques clés de mise en place. Dommage qu’il n’y ait pas de corrélation avec les autres mesures. Je pense que l’on aurait pu faire quelque chose, ne serait-ce que pour montrer l’évolution des tendances entre 2 mises en production…
La troisième partie agrège ce qui a été vu précédemment pour donner de l’information de plus haut niveau. Du moins est-ce l’idée. 4 chapitres sur 95 pages sont consacrées à cela. On commence par le chapitre 7 qui explore l’agrégation des données collectées sur 25 pages. Plutôt que donner des mesures standard, l’auteur y expose sa méthode pour créer des mesures agrégées. C’est un peu ennuyeux, à part l’utilisation de mind map pour explorer les questions. Le cas d’étude sur la « continuous release quality » n’est pas aussi passionnant qu’il devrait.
Le chapitre 8 traite de la qualité interne du logiciel, les fameuses « illités » au long de17 pages. Il s’agit surtout de métriques de maintenabilités, s’adossant essentiellement à des mesures de temps de cycle et de couverture de code, ce qui n’est pas génial, car il s’agit là d’indicateurs « proxy ». L’usability est abordée, mais de manière franchement superficielle.
Le chapitre 9 traite d’un sujet d’un peu plus haut niveau : la publication de métriques. La question occupe 23 pages qui rassemble des aspects tels que : quelles informations pour quels acteurs ? Comment publier ? Comment adapter le mode de publication et la fréquence aux acteurs ?
La 3ème partie se referme sur le chapitre 10 qui évoque les métriques par rapport aux principes agiles. Encore une fois l’auteur interprète les choses assez singulièrement. Par exemple, on utilise des informations de Jira pour mesurer le « face to face conversation ».
Au global, le livre est une déception. J’ai été aussi pugnace que possible, mais l’ennui m’avait déjà largement gagné au chapitre 7. Pourtant, on part de bonnes idées, celle de collecter des informations de différentes sources et de les corréler. Mais d’une part, ces idées prennent une direction qui n’est agile qu’à moitié. Et d’autre part la forme échoue à être intéressante. J’aurais d’avantage imaginé un découpage par domaine de pratique et des propositions de métriques sous la forme de patterns, ciblant à chaque fois une nature d’information actionnable et les corrélations de données nécessaires à sa construction.
Référence complète : Agile Metrics in Action – Christopher W. H. Davis – Manning 2015 – ISBN : 978 1 617292 48 4
Note de lecture : Workflow Management, par Wil Van der Aalst & Kees Van Hee
Note : 6 ; Une référence, certes, mais aussi un texte aride !
Soyons clair dès le début : ce livre fait autorité sur les fondamentaux des Workflow et est écrit par la plus grande autorité reconnue en le domaine. D’ailleurs le livre débute ses deux premiers chapitres en posant les bases des concepts fondamentaux des Workflows : tâches, work items et activités, mais aussi les réseaux de Pétri, bien entendu.
Le chapitre 3 s’attaque à la gestion des workflows : l’alignement des ressources et de l’organisation sur les workflows, ainsi que l’adéquation de ceux-ci par rapport aux objectifs et aux coûts. Cette étude est complétée par le chapitre 4 qui couvre l’analyse de pertinence et de performance des workflows.
Si ces 4 premiers chapitres couvrent la théorie, la pratique arrive avec le chapitre 5 qui présente les architectures de systèmes de Workflow, le chapitre 6 qui lui fait suite s’attaque à l’aspect méthode. Une partie qui aurait aussi bien pu être oubliée car elle apporte assez peu ici. L’étude de cas qui termine l’ouvrage est une bonne idée, mais elle est peu passionnante aussi bien par le fond que par la forme.
On notera enfin les 2 annexes : la première destinée aux fondamentaux mathématiques ravira les plus courageux (je n’en fais visiblement pas partie) et la seconde assez courte dédiée à la représentation des workflows avec UML.
Cet ouvrage fait 300 pages, ce qui est assez raisonnables. Toutefois le style n’en fait pas un roman de gare ! Il est au contraire aride à la lecture et souvent très technique. C’est donc une lecture difficile qui réservera ce texte aux lecteurs certainement motivés, mais surtout en nécessité de cette connaissance de base.
Référence complète : Workflow Management : Models, methods and systems – Wil Van der Aalst & Kees Van Hee – MIT press 2002 – ISBN : 0-262-01189-1 (V.O. : Workflow Management : Modellen, Methoden en Systemen, Academic Service 1997)
Une façon classique de présenter le sujet est de commencer par le manifeste, puis d’évoquer le « parapluie agile » et les différentes approches qu’elle abrite : Scrum, XP, Kanban, etc.
Mais c’est surtout : délivrer tôt de la valeur métier et « moins de bureaucratie ». Pour illustrer cela, Kniberg nous trace le Value Stream Map d’une entreprise développant des jeux : un temps de cycle de 25 mois pour 3 mois de travail utile seulement ! La logique de telles entreprises est de minimiser les coûts en maximisant l’utilisation des ressources.
Optimiser l’utilisation des ressources
Il s’agit d’une illusion à plusieur titres. Tout d’abord occuper au mieux l’équipe ne garanti pas une meilleure productivité, au contraire. Preuve nous en est donnée lors des week-end de départ en vacances...
Par ailleurs, notre travail n’est pas de produire du logiciel … mais de résoudre des problèmes. Et si possible en produisant le moins de logiciel possible pour ce faire !
Et Scrum, dans tout ça ?
J’ai déjà longuement parlé de Scrum dans ce blog. Il se séfinit par quelques règles simples. Et aussi du Shu Ha Ri qu’évoque également Kniberg. Hélas, de nombreuses organisations sont « bloquées dans le Shu » !
Scrum, c’est une structure très simple, une Scrum Team composée d’un PO qui fait le lien avec le monde extérieur et une équipe de développement pluri-disciplinaire. Des artéfacts réduits au minimum, avec un Product Backlog et un Sprint Backlog.
Le Sprint, l’unité de temps de Scrum a une structure bien définie, elle commence avec le planning meeting et se conclut par le Sprint Review, puis la rétrospective. Mais ce n’est pas la seule façon de faire ! La cadence des rétrospective peut être décorrélée des sprints. De même, si les Sprint Reviews donnent la cadence, le planning meeting peut suivre une autre régularité. D’ailleurs en Kanban, ce dernier disparait pratiquement !
Pourquoi ça marche ?
Parce que l’approche agile diminue les risques ! Les gros projets ont une méchante habitude : ils échouent ! Pour l’auteur, un gros projet s’assimile à un tir au canon : de longs calcul, un seul essai… qui a toutes les chances de rater la cible.
Le projet agile serait plutôt un missile à tête chercheuse, capable de réajuster sa direction en permanence !
Le « big risk » du projet classique est transformé en « mini-risques » qui sont autant d’incréments. Des incréments qui ne sont pas des étapes de construction mais des tranches de fonctionnalités, des niveaux d’accomplissement du besoin. Les éléments principaux de la recette ?
Des équipes pluridisciplinaires, où les membres travaillent ensemble et se complètent.
Un focus sur l’optimisation de la valeur, et non des fonctionnalités livrées (et encore moins de l’occupation).
Revenir au « pourquoi » et identifier les options qui s’offrent à nous, comme nous le faisons avec l’impact mapping
Parlons planning
Le planning classique, c’est le « big bang », le grand pari d’être dans les clous, sans aucun « plan B ». A contrario, le planning agile, c’est sécuriser un périmètre en continu. C’est aussi s’adapter en continu avec une boucle de feedback plus rapide. Celle-ci se prolongera vers l’utlisateur final avec la mise en place d’un déploiement continu.
La gamification était bien le thème de cette nouvelle rencontre. Avec 2 interventions très enlevées.
Siffler en travaillant, avec Anna Livia Gomart-Cardin
Anna Livia nous vient du marketing du jeu video, et elle va décortiquer pour nous certains mécanismes du jeu ! Pour commencer, elle distingue 2 notions :
« play » : sans règle
« game » : avec des règles
Les raisons principales qui nous conduisent à jouer sont aussi au nombre de deux :
On est très bon à ce jeu : on joue pour le plaisir, parce que cela met en avant nos compétences.
Pour apprendre, acquérir des compétences ; pour une vision de soi une fois ces compétences acquises.
Le jeu, c’est également le fun. Il provient de la vision, du sens que l’on donne à notre travail. Les chants de marins symbolisent l’engagement, le plaisir de l’action. Ce sont 4 types de « fun » que distingue Ann Livia :
« easy fun » : un moment sympa, facile.
« hard fun » : des moments qui nous grandissent. C’est la raisons pour laquelle on peut faire des mots-croisés, par exemple.
« fun social » : pour apprendre des autres
« fun sérieux » : des apprentissages qui servent hors du contexte d jeu.
L’entreprise est un milieu différent, plus difficile. Il nécessite certaines règles. En effet, on va impliquer dans des jeux des collègues mais surtout des supérieurs hiérarchiques dont notre salaire dépend ! Livia nous propose 2 axes :
Le « cercle magique » : On fait du lieu et du temps de jeu un espace où les règles du monde extérieur ne s’appliquent pas.
Faire du « hors site », pratiquer les jeux dans un contexte différent pour signifier le changement de contexte.
Enfin l’oratrice nous expose comment le savoir-faire de la création de jeu peut aider à construire la vie et la progression professionnelle en entreprise. C’est l’attitude du « game designer ».
Tout d’abord, le parcours professionnel peut être conçu comme un parcours de jeu, avec des niveaux (débutant, régulier, enthousiaste), avec des moments de repos ménagés entre ces étapes.
Il faut aussi concevoir et prendre en compte l’échec, qui sera plus fréquent que le succès.
S’appliquer à aller vers une logique de volontariat.
Considérer la notion d’équité : il n’y a pas de hiérarchie dans le jeu.
Pourquoi les jeux sérieux, avec Raphael Goumot
La première réponse de Raphael est : créer une vision en fabriquant de la cohésion, et ainsi permettre la création d d’un plan d’action. Le jeu sérieux s’oppose au « blah blah meeting », il améliore la qualité de ce qui est produit et brise les biais cognitifs.
Les ateliers proposés par les jeux sérieux (la référence « gamestorming » en propose 80 !) permettent d’impliquer le client, de la faire participer pour qu’il apporte les éléments de réponse qu’il détient.
Au-delà d’organiser le travail en groupe, les jeux sérieux nous permettent de revenir à l’émotion, à visualiser et imaginer. Les relations entre les participants deviennent plus symétriques, ce qui nous permet de passer de la participation à la co-production.
Fin de soirée
Ce n’est pas très facile de transcrire l’énergie et la passion des 2 orateurs de la soirée. Sans parler du « fun » de Raphael qui s’est évertué de m’appeler « Stéphane » sans discontinuer.
Bref, venez au prochain Praoduct Tank ! Justement, c’est très bientôt...
L'édition de l'Agile Tour 2015 à Lille réunit 32 conférenciers dans un cadre unique. Inscrivez-vous, c'est gratuit !
Agile Tour Lille 2015, j’y serais !
Les retours d’expérience sont rarement aussi passionnant qu’ils devraient l’être ! Ils me donnent trop souvent l’impression d’être pour une entreprise, un projet, l’occasion de vanter leur réussite. Une opportunité de raconter une histoire dont ils sont les héros et dont il sera difficile de tirer parti une fois rentrer chez nous.
C’est donc à partir de vécu, mais sous forme de « patterns » , de recettes venues du terrain, que je vous proposerais cette session qui n’a rien de théorique.
Voici le « teaser » de cette session.
Teasing, teasing...
Basculer en agile un très gros projet est un challenge, pour certains cela peut même apparaitre comme une ineptie. Pourtant c’est que le projet Linky a décidé de faire ! Un tel choix fait émerger des difficultés souvent absentes de projets plus petits : culture « cycle en V » omnisciente, grandes équipes, intégration dans l’architecture du SI, etc.
Mais si la route reste longue, les signes de succès sont réels. Plutôt que d’exposer l’histoire du projet, nous allons voir ensemble 12+1 leçons apprises, sous forme de « patterns » opérationnels : des recettes que vous ne trouverez dans aucun livre. Les patterns que nous vous proposons sont tous directement utilisables pour votre propre transition agile dès demain.
Note : 8 ; Réflexions sur la transition de Scrum à Kanban, la vraie nature d’un processus agile et les moyens de l’adapter.
J’entends beaucoup de personnes parler du Scrumban, mais bien peu ont lu les essais de Corey Ladas compris dans ce volume, car il ne s’agit pas de ce dont ils pensent. Car avant tout, Scrumban est une compilation d’essais (souvent des reprises de posts de blog) sous la forme d’un livre au format très court, moins de 175 pages, celles-ci étant par elle-même assez courte, du fait de la mise en page. Mais court ne signifie pas sans valeur, car le texte de ce praticien très chevronné de l’agilité nous propose des réflexions très profonde sur le passage de Scrum à Kanban et la vrai nature des processus que nous utilisons !
Il n’y a pas vraiment de chapitres au livre, mais plutôt des espèces de thèmes qui sont au nombre de 7. Le premier d’entre-eux concerne Kanban lui-même. L’auteur y explore les mécanismes fondamentaux : le WIP et le flow, bien sûr, mais aussi la synchronisation et les buffers. On termine avec une réflexion sur la notion d’itération : pourquoi son avènement était inévitable, tout comme maintenant … sa disparition !
Le workflow est le second thème. C’est l’occasion de réfléchir sur la vrai nature d’un processus, en commençant par souligner qu’un workflow n’est pas une planification (les 2 concepts sont orthogonaux). L’auteur va plus loin en étudiant le PSP du SEI par rapport à Kanban et en mettant en relief les … similitudes ! Enfin l’auteur termine cette partie en dénaturant le kanban en le transformant en un processus à un ticket : c’est un cycle en « V » !
Notre troisième thème a trait à l’organisation. Il s’agit en fait d’une étude mettant en perspective l’organisation Lean (articulée autour d’expertises), la division du travail (c’est à dire le Taylorisme) et le mode agile, donc cross-fonctionnel. Ce qui nous amène doucement au Scrumban !
La quatrième partie s’articule autour du Scrumban. L’idée du Scrumban est surtout celle d’une transition de Scrum vers Kanban. Elle démarre avec le Scrumboard que l’on migre vers un flux tiré, en s’aidant de WIP. Avec le Scrumban niveau 2, on travail autour de petites tâches, rendant inutile l’estimation et la « prochaine chose utile à faire » qui rend obsolète le planning meeting. La fin de cette partie avec ses considérations autour du flux, de la bande passante et de l’architecture est un peu ardue.
La 5ème partie nous propose de considérer le fonctionnement d’un système Kanban. On commence par le Daily Standup Kanban, très différent de celui de Scrum. On s’intéresse au mode de fonctionnement avec le business qui s’axe sur la priorisation « on demand » et le SLA de l’équipe de développement. La gestion des défauts fait le lien avec la partie suivante.
C’est à la gestion des queues et des buffers qu’est consacrée la sixième partie. Un propos assez technique qui évoque les notions d’asynchronisme, de buffer partagé et de WIP regroupant buffer et traitement (comme dans le getkanban) ! Le fonctionnement des features / bucket brigades n’est pas facile à suivre, même si l’auteur fait un effort important de nous y conduire progressivement par son raisonnement.
Enfin, la 7ème partie est consacrée à la planification. L’auteur y développe plusieurs concepts tels que l’IFR (Ideal Final Result) et le priority filter. Le plus utile reste cependant le « perpetual multivote » !
Ne vous laissez pas leurrer par le format réduit de cet ouvrage. Il s’agit d’agilité niveau Jeidi ! Dans ses essais, l’auteur porte une grande attention à nous faire suivre son raisonnement pour nous amener à un fonctionnement final. On regarde au long du texte le Kanban sous plusieurs angles, en amenant des techniques de fonctionnement complémentaire au Kanban que nous connaissons. Bref, un beau condensé d’expertise pour nous aider à réfléchir et à aller plus loin !
Référence complète : Scrumban, Essays on Kanban systems for lean software development – Corey Ladas – Modus Cooperandi Press 2008 – ISBN : 978 0578002149
La ScrumBeer, c’est un peu le freestyle du Scrum User Group. Petit rappel subliminal sur notre dernier rassemblement Parisien afin d’envoyer un signal subliminal pour la rentrée !
Agilité et formule 1
Une ScrumBeer apporte souvent son lot de discussion surprenante. Ces soir-là j’ai eu l’opportunité d’apprendre des choses passionnantes sur Renault F1.
Car un motoriste de Formule 1 doit faire face aux mêmes défis qu’une équipe agile. Elle cherche la performance encore et toujours. Cette saison encore, Renault F1 fait face à des difficultés, son bloc propulseur concède pas mal de puissance par rapport aux champions en titre (Mercedes) et même par rapport à Ferrari qui a mieux progressé durant l’hivers.
Ce n’est visiblement pas l’équipe d’ingénieur qui en est la cause : elle est hautement qualifiée et n’a pas à rougir face à ses compétiteurs. Seulement la nouvelle règlementation qui est dans sa seconde année a donné naissance a de nouveaux groupes propulseurs très complexes où tout est à apprendre.
Renault F1 a abordé cette nouvelle ère en continuité de la période précédente, qui fut une relativement longue période de stabilité avec des moteurs classiques. Renault faisait alors appel à des sous-traitants spécialisés pour produire nombre de composants du moteur. Le manufacturier Français a misé sur un travail de conception très élaboré en amont et une planification précise des fournitures par les sous-traitants passant par un service achats.
Mercedes pour sa part fabrique elle-même la quasi-totalité de ses composants. La marque Allemande s’est ainsi donné les moyens d’expérimenter et d’itérer très rapidement, bref d’être très performant sur son cycle d’apprentissage.
Un nouvel exemple que face à un territoire méconnu, optimiser l’acquisition de connaissance est plus performant qu’optimiser la production (surtout quand celle-ci est principalement handicapé par le processus d’achats).
Il y a eu un peu de mouvement au French SUG, j’espère toutefois que l’on pourra perpétuer la tradition de la ScrumBeer. Comme vous le voyez, on y apprend des choses...
Le stand-up, ou scrum meeting, quelque soit le nom que vous lui donniez, est un élément prépondérant du framework Scrum (et d’autres approches agiles également). C’est lui qui permet de maintenir le cap de l’itération et de s’assurer que tout reste dans les clous de ce qui a été prévu en début de Sprint et de faire des choix ou des actions correctrices le cas échéant.
Vous connaissez sans doute le principe : à heure fixe chaque jour, les membres de l’équipe se rassemblent, souvent devant leur Scrum Board. C’est un rendez-vous court d’une dizaine de minutes (c’est pourquoi tout le monde reste debout) et chacun répond à 3 questions :
Qu’ai-je fait hier ?
Qu’ai-je l’intention de faire aujord’hui ?
Quelle problème ai-je rencontré ?
Tout est dans l’efficacité. Qu’est-ce qui pourrait mal tourner ?
De l’équipe à l'individu
Scrum insiste beaucoup sur la notion d’équipe et l’auto-organisation. C’est la raison principale pour laquelle il n’y a pas d’autre rôle qu’équipier au sein de l’équipe de développement. On doit travailler ensemble pour traiter une User Story et c’est ensemble que l’on escompte atteindre l’objectif de Sprint.
Et soudain, au stand-up, c’est à l’accomplissement individuel que l’on s’intéresse. Pas à la user story si on y a travaillé à 3, mais à la part que chacun y a pris. Une bonne façon d’induire les comportements individualistes dont on voulait se débarrasser en premier lieu. Plus souvent, cela conduit les équipier à s’approprier individuellement des items de backlog. Autant pour l’esprit d’équipe !
Mais ce n’est pas fini.
Les auteurs de Scrum nous suggèrent aussi de mettre à jour le reste à faire des tâches. En heures. Nous nous éloignons encore un peu plus du regard vers l’objectif de sprint. De la valeur ou de l’impact, nous portons maintenant notre attention sur la quantité de travail.
Du Scrum praticien au Scrum Zombie
La mise à jour du reste à faire induit aussi une autre logique : celle de la justification. Finalement notre logique du reporting, celle que nous avions sorti par la porte, est de nouveau rentrée par la fenêtre. Une logique encore agravée par les fameuses 3 questions. Car la première d’entre-elle est : « qu’ai-je fait hier ? ». Comme il s’agit de la première question, ce sera celle à laquelle on accordera le plus de temps et d’attention. Pourtant ce point est purement informatif, et ce sont bien les deux autres questions qui doivent nous aider à prendre des décisions et à nous organiser. Ce devrait être le but premier du stand-up. cette adhésion aveugle à une consigne est aussi la manifestation d’un autre phénomène : Le Scrum Zombie.
Le Scrum Zombie dévoile sa face hideuse lorsque la forme prends le pas sur le fond. Ses lieux de manifestation favoris sont la rétrospective et le stand-up. En focalisant sur la routine et la tyrannie du chronomètre, l’équipe finit par perdre de vue le contenu lui-même :
Quel intérêt offre l’information sur ce que j’ai fait ? En quoi cela va aider un de mes équipier à prendre une décision ? Cela va-t-il leur permettre de me donner un feedback qui va m’aider ?
Les informations sur les problèmes que j’ai rencontré ou sur ce que je compte faire peuvent-ils influer d’une manière ou d’une autre sur l’adaptation tactique de notre plan d’action ? Cela peut-il aider mes collègues à me proposer leur aide, ou à moi-même de proposer la mienne ?
Quand pour la dernière fois avez-vous pensé à l’une des questions ci-dessus en prenant la parole lors du stand-up ?
C’est bien, vous utilisez le stand-up pour synchroniser l’information au sein de l’équipe. L’information échangée a de la valeur. Hélas, même là le stand-up peut dégrader la qualité de l’interaction au sein de l’équipe !
Quand le stand-up retarde la circulation de l'information
Pour certains, le stand-up est le moment réservé pour parler avec les collègues afin de ne pas déranger ceux-ci durant la journée. C’est plutôt une bonne idée : ne pas déranger ses collègues et ne pas perturber leur concentration pour une information qui peut attendre.
Mais toutes les informations ne peuvent pas attendre. Il y a des choix de conception qui peuvent impacter ce que font vos coéquipiers si ils dépendent du module sur lequel vous travaillez. Certains refactoring assez larges entrainent des modifications qui ne sont pas anodines pour vos voisins. Vous avez pu obtenir une information importante pour l’ensemble de l’équipe et qui remet en cause un de vos postulats. On pourrait trouver bien d’autres exemples.
Dans les cas que nous avons cité, attendre pour informer le reste de l’équipe est le meilleurs moyen pour générer du gâchis et du délais, sans parler de la frustration générée...
Bref le stand-up se transforme parfois en mécanisme pour traiter l’information en mode batch au sein de l’équipe. C’est exactement l’effet inverse de ce que nous souhaitons obtenir.
Alors le stand-up, c’est mal ?
Nous n’avons même pas évoqué le stand-up détourné, par exemple comme outil de pouvoir. Même utilisé dans son but premier, le stand-up peut avoir des effets contre-productif. Mais qu’essayons-nous de faire réellement avec le stand-up, au-delà du folklorique petit cercle ?
L’un des principes majeurs de Scrum, c’est « inspect and adapt ». Le stand-up est notre boucle de feedback journalière, comme je l’avais déjà évoqué. C’est un point de synchronisation qui nous permet d’adapter continuellement notre plan d’itération à une maille qui n’est pas plus longue qu’une journée. Et ce mécanisme est réellement important.
Pourrait-il prendre d’autres formes ? Sans doute. Déjà, lorsque les situations sont tendues il n’est pas rare de voir des équipes opérer spontanément des stand-up deux fois par jour. Des équipes très matures peuvent aussi développer leur propre protocole de resynchronisation au fil de l’eau, rendant le stand-up inutile.
La forme la plus simple à mettre en oeuvre du protocole de synchronisation reste le point journalier. Quand il opère son rôle de synchronisation et d’adaptation du plan d’itération, il est une pratique importante de n’importe quelle approche agile. Mais pas quand la forme prends le pas sur le fond et qu’il se transforme en une pantalonnade ou en reporting.
Note de lecture : Serial Communications, A C++ Developer’s guide, par Mark Nelson
Note : 7 ; Bien que désormais obsolète (car concerne surtout Windows 16 bits), reste intéressant sur les principes de gestion des ports série.
Tant que je suis dans les antiquités…en voici une tout à fait honorable ! Certes ce livre a perdu une grande partie de son intérêt, d’abord avec l’arrivée du Windows 32 bit et de TAPI puis des infrastructures et librairies qui rendent aujourd’hui transparente les vicissitudes des protocoles de communication.
Cet ouvrage nous permet, aujourd’hui encore, de nous ressourcer sur la mise en œuvre des communications à bas niveau, là où les caractéristiques du matériel ne peuvent être ignorées ! Mais la bête est imposante : ce sont 600 pages qui se présentent à nous sur ce seul sujet, le tout en 11 chapitres ! Le premier d’entre-eux rappellera des souvenirs aux plus anciens d’entre nous, il aborde l’interface RS 232 C sur 64 pages. Tout y passe, depuis la norme du connecteur, la signification des signaux et les protocoles de transmission modem. L’électronique sous-jacente, les fameux UART sont évoqués, mais leur gestion fera l’objet d’un chapitre à part. Finalement les protocoles d’échange de fichier (Kermit, ZModem, etc.) clôturent le chapitre. C’était en quelque sorte le tour du propriétaire.
Le chapitre 2 s’articule autour de la définition de la classe C++ RS232 ; il s’agit d’un wrapper abstrait sur lequel peu de méthodes concrètes « intelligentes » sont implémentées. Essentiellement les fonctions de lecture et écriture. C’est un bel exemple de mise sous forme de classe d’un protocole, car tous les signaux de la norme apparaissent sous forme de méthodes virtuelles. A part cela le chapitre est peu passionnant, essentiellement constitué de listings.
Ce sont près d’une centaine de pages qui sont dédiées au chapitre 3, dévolu à l’implémentation de RS232C sur l’UART 8250. Toute la première partie expliquant le fonctionnement de l’UART est réellement très intéressante même si je regrette le peu qui est consacré au 16550, certes nettement moins rependu à l’époque, mais nettement plus intéressant. Hélas la seconde moitié du chapitre est de nouveau consacré à de fastidieux listings bien peu expliqués…
Le chapitre 4, shared interrupt device rompt la monotonie avec seulement 25 pages. Il est consacré à l’accès aux ports COM dans l’architecture PC via les 2 interruptions qui leurs sont dédiées (pour 4 ports en principe accessibles). Le code du handler et les principes de gestion sont clairement appréhendés. Des informations par ailleurs rares dans la littérature, pour ne pas dire plus.
C’est à un périphérique plus exotique qu’est consacré le chapitre 5 : le Digiboard ! C’est donc une nouvelle sous-classe de RS232 qui nous attend. Un chapitre dont je soupçonne qu’il tenait à cœur à l’auteur, mais qui n’a pas retenu mon attention.
Plus intéressant pour moi, mais hélas plus légèrement traité, le chapitre 6 nous propose une nouvelle sous-classe de RS232, mais cette fois en s’appuyant sur les primitives disponibles dans le BIOS. Seul 30 pages y sont consacrées et l’auteur aurait pu faire plus d’effort pour développer plus clairement les interruptions du BIOS et leur exploitation.
Au chapitre 7, le FOSSIL driver se voit lui aussi consacrer une trentaine de pages. La profondeur de traitement est à peu près la même que pour l’implémentation BIOS. Mais j’avoue encore une fois que l’aspect exotique de cette norme fait que le chapitre n’a pas retenu mon attention.
Nouvelle alternative au chapitre 8 : une implémentation sur les API Windows. Près de 50 pages sont noircies sur le sujet. Cela paraît mieux, mais à l’époque où ces informations étaient vitales pour moi, la profondeur des informations restait bien insuffisante. Mais au moins le livre fournit des informations d’exploitations de ces APIs, choses pratiquement indisponibles par ailleurs en 1993 !
Le chapitre 9 est long de 40 pages. C’est un changement, car on quitte la couche RS232 pour s’attaquer à la gestion des modems, avec les fameuses normes V24, V32 et autres et bien sûr le protocole Hayes. La question est bien traitée et fort clairement. C’est probablement la meilleure source d’information que j’ai pu croiser sur la question.
Au chapitre 10, on s’attaque aux transferts de fichier, avec les protocoles XModem, YModem et ZModem. La question ne m’intéresse guère et j’ai du mal à avoir un avis sur le chapitre. Le sujet semble bien traité et le listing de fichier une fois encore un peu longuet.
Le dernier chapitre du volume va s’intéresser à l’émulation de terminal. Le thème remplit 60 pages et ne semble guère passionnant tel qu’il est traité ici. On est beaucoup dans l’explication de texte du listing, fort peu sur la déconstruction du problème.
L’auteur a développé une petite librairie de classes multiplateformes, multi-modems et multi contrôleurs qui, ma foi, m’a bien fait de l’usage à son époque. Le livre gravite entièrement autour de cela ce qui rend parfois le propos un peu rébarbatif et les listings ennuyeux. Mais le volet technique est très affuté et ce fut très clairement la meilleure source d’information sur bon nombre de sujets qui y sont traités. Difficile de faire valoir une pertinence après presque 25 ans, pourtant le volume mérite d’être conservé à titre d’archive !
Référence complète : Serial Communications : A C++ Developer’s guide – Mark Nelson – Prentice Hall / M&T Books 1992 - ISBN : 0-13-011776-1
En ce début Avril, le Lean Kanban France nous conviait à une rencontre avec Bjarte Borgsnes, le pape du Beyond Budgeting, si je puis dire. Tout d’abord, je dois saluer l’initiative de Samuel Retière qui a fait l’entremetteur entre le LKFR et la Société Générale pour rendre possible cette rencontre. En effet, Bjarte était en visite à la SG, non seulement il a su tirer parti de l’opportunité pour monter cette rencontre, mais celle-ci a pu être hébergé dans les locaux de la banque.
Seconde chose à noter, le LKFR qui jusqu’ici limitait son activité à la conférence du même nom qui a lieu chaque année à l’automne, se met à organiser des rencontres en soirées. D’autres sont d’ailleurs à suivre.
Beyond Budgeting
Bjarte n’est pas venu seul. D’autres intervenants sont au programme. A commencer par Anders Olesen, l’actuel directeur du Beyond Budgeting Institute !
Le Beyond Budgeting, c’est à la fois le nom d’un réseau et d’un modèle de management. Ce n’est pas non plus quelque chose de nouveau, car le Beyond Budgeting Institute existe depuis maintenant 15 ans !
Le Beyond Budgeting Round Table est une émanation de cette organisation, dont le but est de rassembler les organisations mettant en œuvre le Beyond Budgéting, de permettre et organiser le partage d’expérience.
Bjarte Borgsnes
Il y a un problème avec le management. Les organisations qui font la transition vers l’agilité ont besoin que change la posture du management. Le Beyond Budgeting est un moyen pour cela.
L’orateur nous propose une métaphore, celle des feux de circulation. Dans cette situation, la performance du système est entre les mains du programmeur (ou du managers, dans le cas présent). Son intention est bonne, mais hélas il n’est pas sur place. C’est un management basé sur les règles.
Le rond-point est sensé être plus efficace. Ici, on cherche à créer les conditions d’une bonne performance. C’est ce dont les entreprises agiles ont besoin : créer plus de « self-direction ». Le beyond budgéting s’oppose au management traditionnel orienté vers les systèmes statiques et la « théorie X » de McGregor (le contrôle) en étant orienté vers les systèmes dynamiques et la « théorie Y ».
Le contrôle est en fait de l’illusion de contrôle. Avoir l’information n’est pas synonyme d’être capable d’influencer. La transparence est un meilleur levier. L’exemple que nous donne Bjarte est assez connu : la gestion des notes de frais.
Chez Roche, plutôt que fixer des règles ou des limites aux notes de frais (cela me rapelle « cherchez les bottes » dans Liberté & Cie), on rend toutes les notes de frais de tout le monde (jusqu’au sommet de la pyramide) visibles à tout le monde (jusqu’en bas de la pyramide). Cela a fait baisser les coûts liés aux déplacements sans qu’il soit nécessaire d’édicter la moindre règle...
Le Beyond Budgeting combine 3 idées majeures :
Pas de budget.
Pas de cible budgétaire
Transparence totale
Il y a 12 principes sous-jacent. Comme le dit Bjarne, c’est assez volumineux, mais on n’est pas obligé de tout faire en même temps !
Gouvernance et transparence
Valeurs : rassembler les personnes autour d’une cause commune, pas d’un plan central.
Gouvernance : Diriger au travers de valeurs partagées et d’un jugement éclairé, et non par le biais de règles détaillées ni de régulations.
Transparence : L’information doit être ouverte et transparente ; Ne pas la contrôler ni en restreindre l’accès.
Des équipes responsables
But : Placer des but moyen-terme ambitieux, pas de buts court-terme fixes.
Récompenses : Baser les récompenses sur les performances relatives et non sur l’atteinte d’objectifs fixes.
Planning et contrôles
Planning : Faire du planning un processus continu et inclusif et non un évènement annuel imposé par le hiérarchie.
Coordination : Coordonner les interactions de manière dynamique et non au travers de budgets annuels.
Ressources : Opérer l’allocation de ressources « juste à temps », et non « au cas où ».
Contrôles : Baser le contrôle sur une boucle de feedback fréquente et rapide, pas sur des écarts de budgets.
A l’image du manifeste agile, ce sont de grandes recommandations, et non des recettes.
La question du budget est bien évidemment au centre du Beyond Budgeting. Quelle est sa finalité ? En fait, elle n’est pas unique, elle est plurielle :
Fixer une cible
Établir un prévisionnel
Permettre l’allocation de ressources.
Pour Bjarte Borgsnes, cette vision budgétaire étriquée porte nombre de défauts.
Tout d’abord, les 3 dimensions citées ci-dessus doivent être décorrélées. Ce sont 3 données différentes.
Le processus budgétaire annuel est un non-sens. Une entreprise n’est pas ouverte un seul mois par an !
Les mesures seules ne valent rien. La façon dont nous délivrons la valeur a autant d’importance que ce que nous délivrons.
L’évaluation doit être holistique, ce qui n’est pas facile.
La transparence est un moyen de régulation beaucoup plus puissant que le contrôle, il fait appel à l’auto-régulation. Mais cela ne signifie pas pour autant avoir une posture naïve.
Jean-Michel Segui
Notre second orateur nous parle de l’adoption du Beyond Budgeting chez Schneider Electric. Disons simplement que ce n’est pas la PME de quartier, avec 25 milliards de CA et 70000 employés !
Tout d’abord 2 constats :
Le management du groupe se plaint de la lourdeur du processus budgétaire.
Il y a des réflexions sur les objectifs, qui sont fixés « en descendant », chaque strate de l’organisation ayant la responsabilité de reformuler ces objectifs à son niveau.
Le processus budgétaire doit faire 7 choses (j’ai oublié la 7ème) :
Fixer une cible
Établir un prévisionnel
Permettre la Planification
Fourbir un plan d'action
Planifier des actions
Gérer les récompenses
Il y a 2 phases dans ce processus : une phase stratégique et une phase opérationnelle.
La phase stratégique se déroule en 2 temps :
Le programme d’entreprise (sur 3 à 5 ans) issu de la direction générale et représentant l’engagement de l’entreprise par rapport au marché, mais sans un grand niveau de détail.
La stratégie opérationnelle, plus détaillée mais sans être exhaustive.
La phase opérationnelle concerne les objectifs que se donnent les départements, qui donne lieu à des itérations avec la direction sur 6 mois. Ces objectifs se déclinent jusqu’au objectifs individuels. Ils s’expriment sur plusieurs axes tels que :
La satisfaction client
L’augmentation du chiffre d'affaire
L’augmentation du cash
Le prévisionnel est géré séparément de l’objectif. Il fait l’objet d’une vision glissante à 5 trimestre (le carnet de commande couvre lui 3 à 4 mois).
Il m’a semblé que nombre d’éléments restent très conventionnels dans la façon dont Schneider Electric à mis en œuvre le Beyond Budgeting. C’est sans doute lié à une logique grand groupe difficile, voir impossible à casser et une logique marché / actionnariat qui va elle, complètement à l’encontre. Mais on voit qu’un certains nombre d’éléments vont dans le bon sens, comme la définition des objectifs par les entités qui en sont responsable.
En conclusion
Les grands principes du Beyond Budgeting s’inscrivent dans la mouvance du Stoos Network. Ce meetup me permet surtout de prendre la mesure de ma méconnaissance du sujet, et de me souhait de la combler...
ScrumDay 2015 : Scaling Dilemna, par Mary Poppendieck
Quand nous étions petits, nous étions fantastiques ! Maintenant que nous sommes plus gros … nous avons cessé d’être fantastiques. En fait, on ne communique plus aussi bien.
Quels sont les problèmes ?
La coopération
La complexité
L’état d'esprit
Le focus
Ce sont ces 4 points que Mary Poppendieck va développer dans sa keynote de ce second jour du ScrumDay.
Coopération
Quand l’entreprise grandit, on tend à l’organiser en silo. Et ça ne marche pas si bien que ça ! On peut prendre le problème dans l’autre sens, et mettre les fonctions (ou les fonctionnalités) en silo. Ce n’est guère mieux.
Bref, nous sommes plutôt doués pour fabriquer des silos, mais médiocre à franchir les franchir ! Ce que l’on cherche avec ces silos, c’est l’autonomie. Et elle apparait alors plus importante que la coopération. Coopération et autonomie apparaissent antinomiques : lorsque l’on travaille sur quelque chose de gros, on perd de l’autonomie. Si nous privilégions l’autonomie, la coopération est le facteur clé pour aborder la complexité, comme Yves Morieux le souligne dans sa conférence TED
Mary Poppendieck nous emmène vers les communautés auto-organisées et vers Elinor Ostrom qui identifie 8 règles de gouvernance des biens communs :
Définir une limite du groupe claire
Faire coïncider les règles gouvernant l’usage du bien commun avec les besoins et les conditions locales.
S’assurer que ceux qui sont affectés par les règles peuvent participer à la modification de ces règles.
S’assurer que le droit d’édicter des règles des membres de la communauté est respecté des autorités extérieures.
Développer un système, porté par les membres de la communauté, permettant de surveiller le comportement des membres.
Faire usage de sanctions graduées envers les violateurs de ces règles.
Donner accès à des moyens de résolution de problèmes à faible coût.
Une gouvernance à multiples niveaux.
Quelle taille de groupe est la plus pertinente ? C’est au nombre de Dunbar qu'évoque l’oratrice, celui évoqué dans le Tribal Leadership, et ses variantes :
Le cercle d’intimité : 3 à 5 personnes
Le groupe de sympathie : 7 à 10 personnes ; c’est la taille d’un groupe pouvant accomplir « quelque chose ».
Le groupe de chasse : de 30 à 70 personnes ; c’est la taille nécessaire pour construire un sous-système indépendant et indépendemment.
Le clan : de 100 à 150 personnes ; C’est la taille d’une compagnie, dans les organisations militaires.
Complexité
Pour aborder la question de la complexité, Mary Poppendieck nous parle de micro-services, en évoquant le livre de Sam Newman (que je n’ai pas encore lu).
Les micro-services fractionnent les ensembles complexes en petits systèmes indépendants (jusqu’à la base de données) qui ne font qu’une seule chose, mais bien. « small » est bien le mot d’ordre pour les micro-services :
Petit services qui font une seule chose, mais bien. Nous l’avons dit.
Petites équipes, capables de prendre en main un service, depuis la compréhension du besoin avec les équipes métiers, jusqu’au suivi en production, en passant bien évidemment par la construction et le déploiement. qui s’effectue indépendamment des autres briques du SI.
Petites itérations et petit coût de démarrage: de zéro à une première étape en 3 semaines !
L’aptitude à réaliser des microservices a des corolaires.
Pas de couplage avec les autres briques du SI (nous l’avons évoqué).
Automatisation extensive des opérations : tests, intégration, déploiement.
« canary release » qui permet de pré-tester le système en situation réelle.
Continuous delivery et aptitude a être toujours « prêt au déploiement ».
Equipes pluridisciplinaires.
Etat d'esprit
Le focus sur le projet a fait son temps ! Place au focus sur le produit !
Vous êtes focalisés sur « le métier » ? Ce n’est même pas un concept … et pendant ce temps on laisse filer le focus sur le client… Il faut changer de regard.
Passer du focus métier au focus client
Passer du gestionnaire de projet à l’entrepreneur leader.
Migrer du développement qui execute les commandes à une équipe proposant des réponses.
Ne plus faire des choix sur les planning, mais sur les marchés.
Abandonner la mentalité « centre de coût » pour un état d’esprit « centre de produit ».
Dans son livre Inspired, Marty Cagan localise la création de grands produits à l’intersection de la valeur, de l’utilisabilité et de la faisabilité ! Pour donner vie à cette vision, il faut 3 personnes d’agal statut, l’un d’entre-eux est le « product manager », qui n’est pas un Product Owner : son rôle n’est pas d’écrire des User Stories ou de concevoir la solution, mais d’être un canal direct avec le client.
Focus
C’est se focaliser sur les bonnes questions. Et comme l’a popularisé Simon Sinek, cela commence par « pourquoi ? ».
La bonne question n’est plus « comment maximiser la valeur » ? » mais « comment maximiser l’impact » et trouver les métriques qui nous montreront que nous allons dans la bonne direction. C’est l’essence même du Lean Startup.
