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.
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 ?
à 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…
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 ».
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.
». 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.
très peu de ressources. Une équipe technique de trois personnes à temps plein, et deux personnes à temps partiel pour les aspects financiers, administratif…
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.
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.
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 ?
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.
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.
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.
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.
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.
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.
retenir est que nous pouvons façonner nos outils à travers nos interactions. Et il se trouve que cette conception émergente est particulièrement pertinente.
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.
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.
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.
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.
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.
é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.
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 !
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.
ê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.
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.
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 ».
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.
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.
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.
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.
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 ».
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.
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.
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.
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.
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.
système adaptatif complexe deviennent de simples débats sur des modifications à appliquer aux artefacts. Qui est responsable de cette évolution des artefacts ?
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.
« 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.
mattisg
n1n9
hakubishin3
bo0om
usaito
ymas0315
motokimura
avandeursen
zacky1972
tam17aki
kamicup
hiroki13
s3_seminar
kneath
mongodb
rasmusluckow
chriscoyier
searls
andyhume
roundedbygravity
3n
sstephenson
marktimemedia
brad_frost
jonyablonski
