$30 off During Our Annual Pro Sale. View Details »

L'approche « Centrée Artefacts »

L'approche « Centrée Artefacts »

Vidéo : http://tv.octo.com/videos/bof-approche-centree-artefact-matti-schneider/
Une conceptualisation des manières de mettre les outils au service des interactions.
Des moyens pour ancrer l'amélioration continue dans les pratiques agiles.

Matti Schneider

May 23, 2014
Tweet

More Decks by Matti Schneider

Other Decks in Research

Transcript

  1. Petit board devien!a grand
    Matti Schneider
    @matti_sg
    14h – 14h25
    Salle 1 (Le Belvédère)
    #AgileFrance
    1
    Présenté le 23 mai 2014 à Paris à AgileFrance.
    CC-BY-NC-SA
    You can quote, reuse and remix this presentation as long as you cite me, but you may not make money out of it, including from training classes. If you include parts of this
    work in yours, you must make your own work available to the public for reuse too. Also, it would be nice from you to let me know about it :)
    If you want to use this material otherwise, please contact me.

    View Slide

  2. Matti Schneider
    @matti_sg
    2
    Je m’appelle Matti Schneider, je suis ingénieur et étudiant en anthropologie, et je vais vous parler d’amélioration
    continue.
    L’amélioration continue, qu’est-ce que c’est exactement ? Comment est-elle habituellement présentée ?

    View Slide

  3. L’amélioration continue
    3
    L’amélioration continue est une démarche qui permet à une structure de réfléchir à ses modalités de production, et de
    produire mieux de manière progressive.
    La définition de « mieux » reste à l’évaluation de la structure en question : peut-être produire plus vite, peut-être
    produire plus proche de l’utilisateur…

    View Slide

  4. 4
    Démarche différente de la démarche d’innovation, qui vise une rupture brutale, la « disruption » (réf). À l’opposé,
    l’amélioration continue est incrémentale et se met en place par des cycles PDCA répétés.
    Historiquement mis en œuvre au Japon (culture orientale peut-être, mais aussi et surtout d’après les travaux de
    Deming…), d’où le terme « Kaizen ».

    View Slide

  5. 5
    L’amélioration continue est parfois présentée comme un effet de bord de l’agilité, parfois comme un de ses objectifs, et
    surtout souvent fantasmée (accélération permanente, hypervélocité…).

    View Slide

  6. À vous !
    6
    Merci ;-)
    Généralement, les introductions à l’amélioration continue se terminent là : c’est la solution à tous nos maux, à vous de la
    mettre en place grâce à l’agilité !

    View Slide

  7. 7
    Sauf que, merci, le lien avec l’agilité est évident : itératif vs. big-bang.
    Tellement que c’en est un des principes.

    View Slide

  8. 8
    « À intervalles réguliers, l'équipe
    réfléchit aux moyens de devenir plus
    efficace, puis règle et modifie son
    comportement en conséquence. »
    — Manifeste Agile
    Principes, 2001
    Généralement, ce principe est respecté par le biais des rétrospectives. Mais leur impact est souvent limité dans le temps
    et dans l’étendue des actions possibles. On aboutit à des optimisations, certes, mais des optimisations locales et non
    globales.
    Et on reste donc avec la question.

    View Slide

  9. 9
    Comment, en tant que praticien agile, intégrer l’amélioration continue dans tout le cycle de production ?
    Je vais vous faire une proposition.

    View Slide

  10. 10
    Je vais vous présenter une approche « centrée artefacts ».
    Nous allons voir comment modéliser le système de production par des artefacts, et comment les mettre en résonance
    pour travailler aussi facilement sur l’équipe que sur son modèle.

    View Slide

  11. 11
    Avant toute chose, un peu de contexte.
    Ce dont je vais vous parler relève de l’expérience d’une startup dans laquelle j’ai travaillé jusqu’au mois d’avril 2014.

    View Slide

  12. 12
    Avec de grandes ambitions : application web dans le domaine médical.

    View Slide

  13. 13
    Comme toute startup avec de grandes ambitions, elle avait très peu de ressources. Une équipe technique de trois
    personnes à temps plein, et deux personnes à temps partiel pour les aspects financiers, administratif…

    View Slide

  14. YMMV
    Your Mileage May Vary
    Votre Kilométrage Peut Varier
    14
    Ce qui nous est arrivé n’est pas obligatoirement ce qui vous arrivera.
    Les éléments d'analyse théorique que nous verrons dans cette session me semblent parfaitement généralisables, mais
    certaines propositions que je vous ferai, comme tout élément pratique, devront être adaptées à votre contexte spécifique.
    Seul vous connaissez votre projet, votre équipe… et pouvez donc choisir les morceaux qui font sens.

    View Slide

  15. Nous façonnons nos outils et
    15
    Généralement, on renâcle à entendre parler d’outils dans le contexte de l’agilité, on préfère se focaliser — à juste titre —
    sur les interactions. Mais il y a médiation de nos interactions par nos outils !
    Je vais vous proposer une manière de tirer profit de cette médiation.

    View Slide

  16. 16
    Voici l’un des murs de notre bureau. Il est couvert d’artefacts (des objets investis d’une signification particulière par ceux
    qui les utilisent).
    Je vais m’attacher au type d’artefact le plus commun et le plus malléable : le board.
    Mais d’abord, qu’est-ce qu’un « board » ? Combien y en a-t-il sur cette image ? 1 ? 4 ? 5 ? 6 ? Plus de 30 ?

    View Slide

  17. Radiateur
    d’informations
    interactif
    (low-tech ?)
    17
    Personnellement, j’en compte 4. Mais il est normal que chacun en ait une définition différente. Je vous en propose une,
    que je conserverai pour la durée de cette présentation : un radiateur d’informations interactif, a priori low-tech.
    Traduit de l’anglais, cela signifie : machin sur lequel on colle des post-its… et sur lequel on peut faire des dessins.

    View Slide

  18. 18
    Le board le plus utilisé est le « task board », ce qui, traduit de l’anglais, signifie « tableau des tâches ». Si vous êtes en
    Kanban, c’est le kanbanboard, si vous êtes en Scrum, c’est le scrumboard, si vous êtes en machin, c’est le machinboard…
    bref, c’est là que vos stories avancent et c’est là qu’on suit l’avancement de la production.

    View Slide

  19. 19
    Le tableau des tâches minimal, c’est trois colonnes : À faire, En cours, Fait.
    Généralement, pour paraître plus cool, on dit “Todo”, “Current” et “Done”.
    Nous avons nous aussi commencé avec cette base.

    View Slide

  20. To-do Current Done
    20
    Nous avons fixé une limite de WIP (Work In Progress, nombre de story sur lesquelles il est possible de travailler en parallèle) à 3 pour
    « current » puisque trois personnes dans l’équipe technique.
    Exemple de story : « En tant que médecin,
    Je peux imprimer une ordonnance,
    Pour prescrire du paracétamol à un patient »
    On passe donc de « à faire » vers « en cours », où un générateur de PDF est implémenté pour que l’ordonnance puisse être imprimée,
    rendu disponible à l’utilisateur et validé, puis enfin la story est « faite ».
    Faire passer cette story dans ces trois étapes fonctionne, mais ne rend pas l’état de la production très lisible.

    View Slide

  21. To-do
    Implém
    entation
    Revue Déploiement Validation Done
    21
    Nous avons voulu rendre visible la manière dont le travail avait été effectué lors de l’itération précédente. Nous avons
    donc mis à jour le board pour qu’il reflète la réalité de l’organisation de l’équipe.
    Mais tout n’est pas toujours aussi fluide.
    Par exemple, imaginons que la bibliothèque de génération de PDF choisie soit mauvaise. Dans le processus présenté ici,
    ceci n’est détecté que lors de la revue de code.
    Étant souvent confrontés à ce type d’inefficacité, les membres de l'équipe finissent par se concerter informellement avant
    chaque étape d’implémentation.

    View Slide

  22. To-do Analyse
    Implém
    entation
    Revue
    Déploie
    ment
    Validation Done
    22
    Cette pratique devenant habituelle, elle est rendue visible dans le tableau des tâches. WIP1 puisque toute l’équipe doit être présente, pour minimiser le temps
    passé à la revue.
    Mais après quelques itérations, il apparaît que cette nouvelle phase d’analyse est elle-même source de pertes : toute l’équipe est mobilisée pour un temps
    potentiellement long. Notamment, la recherche de documentation ou la validation expérimentale peuvent être chronophages.
    Les membres de l’équipe sont agacés de perdre du temps à discuter des possibilités d’implémentation sans avoir toutes les billes techniques nécessaires. D’où
    frustration, ennui, désengagement… et adaptation spontanée : on convient qu’une personne est suffisante pour accumuler de l’information sur les possibilités
    techniques avant de prendre une décision.
    Cette pratique se généralisant et son efficacité étant avérée après quelques itérations, l’artefact est mis à jour pour refléter la nouvelle organisation.

    View Slide

  23. To-do
    Exploto
    typage
    Concept
    ion
    Implém
    entation
    Revue
    Déploie
    ment
    Valid
    ation
    Done
    23
    La phase d’analyse est donc éclatée en deux phases.
    La première, l’explototypage, combine deux approches pour récolter le maximum d’informations permettant d’alimenter la conception. Ce
    néologisme permet d’exprimer l’usage combiné de l’exploration (enrichissement en largeur de l’espace des solutions possibles) et du
    prototypage (enrichissement en longueur de l’espace des solutions possibles).
    La seconde, la conception, consiste en une prise de décision collégiale au sein de l’équipe, sur la base des informations accumulées lors de
    l’explototypage.

    View Slide

  24. 24
    Nous façonnons nos outils et
    Je vous ai donc présenté un outil que nous avons mis en place, mais surtout la manière dont nous l’avons fait.

    View Slide

  25. 25
    Nous façonnons nos outils et
    Le point fondamental à retenir est que nous pouvons façonner nos outils à travers nos interactions.
    Et il se trouve que cette conception émergente est particulièrement pertinente.

    View Slide

  26. 26
    En effet, on retrouve le double diamant du design.
    Ce modèle de la résolution créative de problèmes explique que l’espace des solutions est exploré en quatre phases.
    Tout d’abord, sur la base du problème exprimé, l’espace des solutions possibles s’élargit pour en inclure autant que possible.
    Ensuite, les plus coûteuses et les moins pertinentes sont éliminées, jusqu’à converger sur un plan, un accord d’implémentation.
    Ce plan est ensuite confronté à la réalité, et l’espace des possibles s’élargit à nouveau pour faire face aux difficultés imprévues qui apparaissent.
    Enfin, l’implémentation converge vers la solution qui est réellement livrée.
    L’approche descriptive du système de production permet de faire coïncider son modèle avec ce modèle provenant d’une autre discipline.

    View Slide

  27. Explototypage Conception Implémentation Revue
    27
    Le lien entre les deux modèles étant établi, on peut à présent mobiliser celui hérité du design pour proposer une solution
    à une difficulté rencontrée dans le système de production.
    En effet, on observe que les phases explototypage et d’implémentation ne sont parfois pas « réellement finies ». Par
    exemple, il peut apparaître lors de la phase de conception qu’une story nécessite de l’explototypage supplémentaire.
    On ne peut pas accepter de faire reculer le ticket, sinon le suivi d’avancement de la production n’a plus aucun sens.

    View Slide

  28. 28
    Le modèle en double diamant montre clairement qu’il n’existe que trois points dans le temps où il est possible de
    discuter d’une proposition précise et non d’un ensemble : lorsqu’une solution est pressentie, lorsqu’un plan
    d’implémentation est proposé, et lorsque l’implémentation est finalisée.

    View Slide

  29. 29
    Les phases d’élargissement de l’espace des possibles sont absolument nécessaires à la résolution créative de problèmes.

    View Slide

  30. 30
    Mais déterminer leur état de finition est impossible.
    Est-ce qu’avoir essayé 5 bibliothèques de génération de PDF est suffisant ? Pourquoi pas 10 ? Est-ce que 3 n’auraient pas
    suffi ?

    View Slide

  31. Explototypage Conception Implémentation Revue
    31
    On remarque donc qu’il est impossible de déterminer si une des étapes de divergence (d’élargissement) est allée assez
    loin sans évaluer la finition de la phase de convergence suivante.

    View Slide

  32. Explototypage Conception Implémentation Revue
    32
    La solution est donc de considérer la phase de convergence comme une condition de validation de la phase de
    divergence, même si le processus idéal ne fait qu’une seule passe.

    View Slide

  33. To-do
    Exploto
    typage
    Concept
    ion
    Implém
    entation
    Revue
    Déploie
    ment
    Valid
    ation
    Done
    33
    DoD DoD
    Concrètement, cela signifie que les étapes de conception et de revue de code deviennent des conditions de validation des
    étapes d’explototypage et d’implémentation. Celles-ci ne sont considérées comme terminées que lorsque l’équipe s’est
    accordée sur un point fixe.

    View Slide

  34. To-do
    Exploto
    typage
    Implém
    entation
    Déploiement Validation Done
    34
    L’idée était de limiter l’exploration au strict nécessaire pour aboutir à un plan d’implémentation. De la même manière,
    l’implémentation est limitée à ce qui est nécessaire pour passer la revue de code.
    Cette modification du tableau a effectivement eu l’impact voulu sur le système de production, puisqu’une nette
    fluidification a été remarquée, entraînant une accélération et une baisse de la frustration.

    View Slide

  35. 35
    Nous façonnons nos outils et
    Nous avons vu en premier lieu que nous pouvons façonner nos outils à travers nos interactions.

    View Slide

  36. Descriptif
    Prescriptif
    — Marshall Mc Luhan
    Understanding Media: The Extensions of Man, 1964
    36
    ceux-ci à leur tour nous façonnent.
    Nous façonnons nos outils et
    Nous venons à présent de voir que nous pouvons tirer profit du fait que nos outils influencent nos interactions.
    Erratum : l’attribution à McLuhan de cette citation exacte est erronée. Voir http://quoteinvestigator.com/
    2016/06/26/shape/ pour la discussion. Merci Thibaut Kemper !

    View Slide

  37. Descriptif
    Prescriptif
    37
    Nous façonnons nos outils et
    ceux-ci à leur tour nous façonnent.
    C’est la combinaison de ces deux aspects qui peut libérer la puissance d’un artefact.

    View Slide

  38. Descriptif
    Prescriptif
    38
    ceux-ci à leur tour nous façonnent.
    Il est donc possible de représenter la relation entre les artefacts et le système de production éminemment complexe
    (individus, logiciels, connaissance accumulée…) qu’ils modélisent sous la forme d’une boucle de rétroaction.

    View Slide

  39. Descriptif
    Prescriptif
    39
    Dans un premier temps, un artefact peut être descriptif : il rend visible certaines caractéristiques du système.

    View Slide

  40. Descriptif
    Prescriptif
    40
    Dans un second temps, un artefact peut être prescriptif : il commande, ou du moins influence, certaines caractéristiques
    du système.
    Lorsque les deux aspects sont réunis pour un même couple artefact / système de production, la boucle de rétroaction est
    complète.
    Le système entre alors en résonance avec son modèle.

    View Slide

  41. Descriptif
    Prescriptif
    41
    Résonance
    Dans l’état de résonance, toute modification du système impacte au moins un artefact, et toute modification d’un artefact
    modifie l’état du système.

    View Slide

  42. 42
    Et donc, on atteint l’hypervélocité !!!
    Je plaisante, mais il s’agit effectivement de la clé à la mise en place de l’amélioration continue. Je vais à présent vous
    montrer un second exemple.

    View Slide

  43. 43
    Les artefacts de suivi de la production, comme le tableau des tâches, ne sont pas les seuls types de board qu’on peut
    construire.
    Je vais à présent vous présenter un autre artefact, dédié exclusivement à l’influence des interactions.

    View Slide

  44. 44
    Il s’agit d’un artefact de type « Reflection workshop output », tel que défini par Alistair Cockburn dans Crystal Clear.
    C’est-à-dire qu’il est mis à jour lors des moments où l’équipe « réfléchit aux moyens de devenir plus efficace », pour lui
    permettre de « régler et modifier son comportement en conséquence » (cf. principe agile).
    En Scrum, ça signifie « à la fin des rétrospectives ».

    View Slide

  45. 45
    À la fin de chaque rétrospective, l’équipe crée un ticket « guide » pour chaque règle qu’elle décide d’adopter, pour
    renforcer ses points forts et réduire ses points négatifs.
    Cela signifie donc que dans cet artefact est d’abord prescriptif. Il cherche à définir les règles du système avant que de les
    décrire, à l’inverse du tableau des tâches.

    View Slide

  46. 46
    Les premiers guides ainsi créés sont triviaux. Ils répondent aux problématiques simples du début, quand l’équipe se
    définit.
    Mais on a bien vu que pour qu’il y ait résonance, pour que la boucle de rétroaction soit bouclée, un aspect descriptif est
    nécessaire.

    View Slide

  47. 47
    Cet aspect descriptif est apporté plus tard. Les guides ne sont en effet pas absolus, et peuvent devenir obsolètes.
    À une telle occasion, le guide est « fermé ». Exemple : la durée des itérations est changée au sprint 34.

    View Slide

  48. 48
    Il est également possible que l’équipe n’arrive pas à respecter une des règles qu’elle avait édictées lors d’une itération précédente. Cette difficulté est repérée lors
    d’une rétrospective, et l’artefact est mis à jour pour refléter l’état du système.
    Ici, par exemple, l’équipe a régulièrement eu du mal à délimiter le standup à 6 minutes pendant l’itération, alors qu’il s’agissait d’un de ses guides. Pour que
    l’artefact soit un modèle du système, le guide en question est mis en « observation », une ligne spécifique du board.
    Cet aspect descriptif est couplé à un effet prescriptif pour l’itération suivante : le guide est mis en évidence pour l’équipe. Si elle n’arrive à nouveau pas à le
    respecter, elle en discutera lors de la rétrospective et pourra par exemple décider de fermer ce guide, ou d’en créer de nouveaux pour s’aider à le respecter.

    View Slide

  49. 49
    Bien entendu, il ne s’agit pas de modéliser pour le plaisir de modéliser.
    Nous avons pu mesurer la puissance de cet artefact à travers le nombre de débats et de faux pas évités. Vous avez déjà eu une discussion
    où l’un des locuteurs pense que le débat a déjà eu lieu ? Dans notre cas, pointer le guide correspondant a toujours suffi à stopper net la
    discussion, sans aucune frustration puisqu’il s’agit de rappeler un point sur lequel il y a déjà eu accord.
    De la même manière qu’un ticket représentant une story est un « reminder to have a discussion », un ticket représentant un guide est un
    « reminder that a discussion has been had ».

    View Slide

  50. 50
    Dans le temps, les guides deviennent beaucoup plus spécifiques.
    Et on atteint bien entendu un niveau meta.

    View Slide

  51. 51
    Certains guides peuvent en effet influencer le fonctionnement du guide board lui-même. Ce qui nous mène à constater
    qu’un artefact en résonance avec le système en fait nécessairement partie, puisqu’il l’influence… Ça, c’est un vrai
    système adaptatif complexe.

    View Slide

  52. 52
    L’idée de cette approche « centrée artefacts » est donc celle d’une modélisation globale, où l’ensemble des artefacts créés
    par leurs utilisateurs représente le plus complètement possible le système de production.

    View Slide

  53. 53
    Voici donc, finalement, le système de production lui-même. Ce que l’on voit est le modèle mais, celui-ci étant en résonance avec le
    système, les deux sont équivalents.
    Cette approche « centrée artefact » pourrait finalement être qualifiée de généralisation de l’approche kanban. Simplement, au lieu de
    rendre visible seulement la chaîne de production, on modélise l’intégralité du système de production, et notamment les interactions en son
    sein.
    Un modèle étant toujours une version simplifiée du système, il est plus simple de débattre de changements à appliquer sur le modèle que
    de discuter du système lui-même.

    View Slide

  54. 54
    Descriptif
    Nous avons donc vu un premier artefact qui est a priori descriptif. Nous avons remarqué qu’une fois suffisamment de
    temps passé, le modèle devient suffisamment bon pour objectiver le processus de production et permettre sa
    modification.
    À partir du moment où cet artefact devient en partie prescriptif, il entre en résonance avec le système et modifier l’un
    revient à modifier l’autre.

    View Slide

  55. 55
    Prescriptif
    Descriptif
    Nous avons vu un autre artefact, lui a priori prescriptif. Nous avons remarqué qu’une fois suffisamment de temps passé,
    les guides sont internalisés par le système ou effacés par lui. Le modèle décrit donc une partie des règles d’interaction du
    système.
    À partir du moment où cet artefact devient en partie descriptif, il entre en résonance avec le système et modifier l’un
    revient à modifier l’autre.

    View Slide

  56. 56
    Descriptif
    Prescriptif
    Dès lors, les propositions de changements d’un système adaptatif complexe deviennent de simples débats sur des
    modifications à appliquer aux artefacts.
    Qui est responsable de cette évolution des artefacts ?

    View Slide

  57. 57
    Descriptif
    Prescriptif
    Ceux qui sont au sein du système modélisé.
    Dans le cas du développement, c’est l’équipe. Elle est responsable de ses artefacts et choisit de les faire évoluer.
    Ce point est crucial pour l’appropriation et donc le respect de l’aspect prescriptif, sans quoi la mise en résonance est
    impossible et le changement n’émergera pas.

    View Slide

  58. 58
    Descriptif
    Prescriptif
    Approche
    « centrée artefacts »
    Cette approche « centrée artefacts » vise ainsi la résonance entre le système de production et les artefacts le modélisant
    pour que leur modification impacte directement le système.
    Et cela, nous l’avons validé expérimentalement, facilite l’amélioration continue et l’ancre à travers le temps et les
    modifications du projet.

    View Slide

  59. Merci ! Des questions ?
    Merci à
    Nicolas Dupont et
    Thomas De Bona,
    sans qui rien n’aurait pu arriver ;
    Anouchka Labonne, Fabien Brossier,
    Frank Wagner, Régis Rallo,
    Émilie Franchomme et
    Thibaut Kemper
    sans qui cette présentation n’aurait
    pas été ce qu’elle est.
    Crédits images :
    Photos CC-BY-SA Matti Schneider
    Photos oiseau © Thomas De Bona
    Understanding Media©GingkoPress
    Cliparts ©
    approvalsandaccreditation.com,
    referenceforbusiness.com,
    homza.com, aoma.edu
    59
    Références :
    - Manifeste Agile, 2001
    - Grammaire des conduites à projet, Jean-Pierre Boutinet, 2010
    - Crystal Clear, Alistair Cockburn, 2003
    - The Double Diamond Design Process Model, Design Council of UK, 2005
    - Toyota Production System, S. B. Gershwin, MIT OCW, 2010
    - Objects, Bodies and Gods, Arnaud Halloy, 2013
    - Ethnographie d’un daily standup, Matti Schneider, 2013
    - Toyota production system and Kanban system, Y. Sugimori, K. Kusunoki, F. Cho & S. Uchikawa, Toyota Motor Co., 1977
    - Proceedings of « Artifacts, practice and knowledge elaboration » seminary, LAPCOS - MSHS - University of Nice Sophia-Antipolis, 2014

    View Slide