Blog entries

  • Exemple de "contrat agile" mis en place entre Logilab et ses clients

    2015/06/18 by Sylvain Thenault

    Dans la mesure du possible, nous essayons de travailler avec nos clients en mode agile. Bon, c'est pas toujours évident, ça ne s'applique pas à tout le monde, mais ce n'est pas le sujet de ce billet. Supposons donc que vous ayez un client déjà initié au sujet et souhaitant fonctionner de cette manière avec vous (si si ça peut arriver !).

    Même dans ce cas, il reste à préciser un certain nombre de points qui vont définir plus précisément les processus et interactions, comme par exemple la durée des itérations, le ou les environnements de test / production et autres manières d'utiliser les outils de suivis. C'est précisément l'objet de ce qu'on appelle le contrat agile, dont voici un exemple qu'il me semble utile de partager avec vous (miroir sur slideshare).

    https://www.logilab.org/file/294043/raw/handshake.jpg

    (photo by Julia Taylor licence CC BY-NC-ND )

    Cet exemple a été légèrement anonymisé. Il rappelle quelques éléments d'agilité et définit :

    • le cycle de développement (itération, recette, etc)
    • les livrables et environnements
    • le mode de fonctionnement avec notre extranet de suivi (une variante de cette forge)

    Il vous faudra donc de fait l'adapter à votre projet, en collaboration avec votre client. Et évidemment, dans un esprit agile, le faire évoluer au fur et à mesure du temps (dans l'exemple avec notre client, nous en sommes à la 3eme version).

    Les sources sont du HTML qui utilise showr et je n'ai aucun problème à les partager pour ceux qui ça intéresse.

    Enfin merci de me faire part de vos remarques et retours sur ce contrat !


  • Méthodes Agiles et logiciels sûrs

    2015/09/23 by Sylvain Thenault

    J'ai assisté ce mercredi à une journée d'étude sur le thème "agilité et logiciels sûrs". Organisé par Aerospace Valley, il y avait une quarantaine de personnes, à la fois des agilistes expérimentés et des curieux, voir dubitatifs, pour l'essentiel venant des industriels du secteur.

    https://www.logilab.org/file/1625539?vid=download

    C'est Claude Aubry qui s'est chargé de chauffer la salle en posant les fondements de l'agilité en général et de Scrum en particulier. Je ne vais pas m'étendre sur cette présentation rapide, efficace et appréciée, si ce n'est sur les rappels suivants qui me paraissent particulièrement intéressants dans le contexte :

    • l'agilité est une culture avant d'être des processus,
    • cela permet de gérer le décalage entre les plans et la réalité grâce à une boucle de rétroaction courte,
    • c'est fait pour gérer des systèmes complexes et adaptatifs,
    • dans le cadre du développement de logiciel sûr, on prendra notamment soin à :
      • la présence d'experts lors des réunions d'affinage,
      • la définition de fini,
      • montrer l'incertitude.

    Je citerai pour conclure cette introduction la définition de l'Agilité selon Claude :

    "l'agilité est la capacité d'une organisation à fournir tôt et souvent de la valeur, tout en s'adaptant à temps aux changements dans son environnement"
    https://upload.wikimedia.org/wikipedia/commons/1/1a/ST_vs_Gloucester_-_Match_-_23.JPG

    (photo par Pierre Selim, licence CC-By-SA 3.0)

    Gérard Ladier et Jean-Paul Blanquart sont ensuite entrés dans le vif du sujet avec une double-présentation-avec-passe-de-ballon (oui oui, y avait 2 projections simultanées avec 2 projecteurs) sur le sujet des contraintes liées au besoin de certification dans le cadre de l'aéronautique pour Gérard et du spatial pour Jean-Paul.

    En commençant par rappeler que normes et règlements ne sont pas là (que) pour nous embêter mais avant tout pour protéger des parties prenantes qui n'ont pas forcément leur mot à dire dans le cadre de la définition d'un produit. Comme vous et moi dans le cadre d'un nouvel avion par exemple : on nous demande pas notre avis mais on pourrait bien finir par le prendre. Ainsi, ces normes et règlements sont censés fournir un cadre permettant de répondre à un objectif de très haut niveau, aussi simple que "on ne doit pas risquer sa vie en montant dans un avion de ligne".

    Je vais passer sur la plupart des points techniques, si ce n'est pour citer la fameuse DO-178C aéronautique qui est la norme définissant les différents niveaux de conformité qu'un logiciel devra agréer dans le cadre de la certification d'un programme. Apparemment, s'il y en a bien une à connaître c'est celle-ci (et ECSS côté spatial).

    Le point important, c'est que ces normes découpent le projet en phase avec des échéances obligatoires mais sans pour autant y associer de méthode. Notamment le cycle de développement en soi n'est pas normé. Il n'y a donc pas de contre-indications à utiliser des méthodes agiles pour répondre aux exigences de ces normes. Ce qui ne veut pas dire qu'il n'y a pas de résistance au changement des habitudes, et notamment celles des experts...

    Gérard a complété ce numéro de duettistes par une présentation des attentes d'Airbus en manière d'agilité :

    1. changer la manière de développer pour accompagner le passage à un mode de développement incrémental des avions et obtenir une diminution du time-to-market,
    2. diminuer les coûts liés aux défauts pour permettre l'augmentation des taux de productions,
    3. améliorer la gestion du risque et de la complexité afin de faire face à l'augmentation des coût de développement

    Donc si on en croit cette présentation, Airbus constate qu'il faut apprendre à travailler différemment, ils sont prêts à tester l'agilité sur des sous-systèmes (trop disruptif sur un système complet, faut pas pousser !) et sont même en attente de challenges de la part de leur partenaires. À suivre !

    https://www.logilab.org/file/1616201?vid=download

    (photo par pixabay, licence CC0)

    L'après-midi, on est reparti sur les chapeaux de roue avec une présentation d'Emmanuel Chenu de Thales Avionics, porteur d'un message massue : "on l'a fait (et on en est content)". Tout part du constat des problèmes liés à l'intégration "big-bang" entre logiciels ou entre logiciel et matériel, mais aussi du fait que mener les activités liées à la certification tardivement et en gros lots :

    • ne réduit pas la complexité,
    • ne permet pas de corriger tôt les pratiques,
    • génère des activités peu efficaces et pas fiables,
    • empire avec l'avancée dans le projet.

    Ces choix ne sont évidemment pas un hasard, ils s'expliquent en particulier par le besoin de versions anticipées non certifiées, ou encore par les échéances des audits qui collent au cycle en V. Malgré tout cela, ils ont donc tenté d'appliquer l'agilité aux développements d'une centrale inertielle pour l'A350 (ADIRU de son petit nom). Ce projet, qui doit répondre au plus haut niveau de la norme DO-178C, est spécifié par plusieurs milliers d'exigences et est constitué au final de plus de 500 000 lignes de code spécifiques. Et il semblerait qu'à l'issue du projet, tout le monde était content :

    • l'avionneur, car il a eu plusieurs livraisons intermédiaires sans régressions et avec globalement moins de défauts (environ 0.15 / kLOC, soit un facteur 100 par rapport aux taux habituels d'après Emmanuel),
    • le service qualité, car il a des retours rapides, globalement moins de soucis et qu'il apprécie la motivation de l'équipe, à la fois à développer et à améliorer son process,
    • l'autorité de certification, qui a été impressionné par le respect des exigences du produit.

    Et vu le deuxième point, on peut raisonnablement penser que l'équipe Thales était contente aussi !

    Les enseignements tirés par Thales et identifiés comme des savoir-faire critiques sont :

    • "produit potentiellement livrable" = le logiciel accompagné de tous les artefacts qui vont avec (notamment ceux nécessaires pour la certification des features développées),
    • l'importance en premier lieu des pratiques techniques:
      • architecture objet
      • test de couverture automatisés
      • intégration continue
      • safe delivery
      • stop the line
      • design by contract
      • qualimétrie
    • il est indispensable d'avoir une gestion de configuration très rigoureuse, notamment en utilisant du versionnement pour les exigences comme pour le code,
    • il faut réorganiser les revues pour ne pas coller au cycle en V, et décrire les itérations et incréments dans les plans.

    Évidemment, comme toujours en développement agile mais encore plus ici : la qualité n'est pas une variable d'ajustement. Et le processus dans son ensemble est suivi par un certain nombre d'indicateurs dont :

    • une mesure "qualité" sur le long terme (somme de critères évolutifs),
    • la couverture des tests,
    • le nombre d'exigences satisfaites.

    Au final, l'avionneur peut s'appuyer sur les versions intermédiaires pour développer d'autres parties de manière incrémentale, il a une mesure plus objective de l'avancement et il obtient une baisse significative des défauts résiduels et de l'impact des changements de priorité. Surtout, Thales démontre ici que l'agilité et la certification DO-178C ne sont pas incompatibles, bien au contraire.

    https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Airbus_A350-900_XWB_Airbus_Industries_%28AIB%29_MSN_001_-_F-WXWB_%2810223175703%29.jpg/640px-Airbus_A350-900_XWB_Airbus_Industries_%28AIB%29_MSN_001_-_F-WXWB_%2810223175703%29.jpg

    (photo par Laurent Errera, licence CC-By-SA 2.0)

    La dernière présentation de l'après-midi était celle de Vincent Meunier (SII), mais je dois avouer que mon attention était déjà sévèrement entamée et que le fait qu'il y ait pas mal de recouvrement avec les présentations précédentes l'a achevée. Je me contenterai donc des points suivants que j'ai relevés :

    • il faut coopérer avec tout le monde, y compris les autorités,
    • ne surtout pas retarder les éléments risqués,
    • tester dans un sprint les processus ou les outils dont on doute,
    • adapter le processus global,
    • laisser l'équipe suggérer les améliorations.

    L'après-midi s'est terminée par une séance de brainstorming autour des points à améliorer ou des actions à mener afin d'étendre l'usage de l'agilité dans le contexte de logiciels sûrs. De nombreuses idées ont été soulevés par l'ensemble de l'audience, visiblement intéressée par le sujet. Au point que le pôle Aerospace Valley semble prêt à creuser encore le sujet via un groupe de discussion.

    J'ai de mon côté été agréablement surpris de ce que j'ai vu et entendu. Arrivant avec un a priori négatif sur la relation du milieu l'aéronautique (et en particulier d'Airbus) vis-à-vis de l'agilité, cette journée me fait penser que c'est possible, au moins localement ! Quant au temps qu'il faudra pour faire bouger les lignes, l'avenir nous le dira - mais ça va être long.

    En tout cas merci à Aerospace Valley et en particulier à Gérard Ladier pour cette journée, ainsi qu'à l'ensemble des intervenants qui étaient tous de grande qualité.


  • Agile Tour Toulouse 2015

    2015/11/30 by Denis Laxalde

    La semaine dernière, plusieurs Logilabiens ont assisté à l'Agile Tour à Toulouse. Le thème de cette huitième édition était le bonheur au travail.

    Le format de la première journée, qui a vu passer environ 300 personnes, alternait entre conférences "classiques" et ateliers participatifs tandis que la deuxième journée, plus intimiste, s'est (auto-)organisée en un forum ouvert où les participants choisissaient et animaient les ateliers qui leur plaisaient. Voir le programme ainsi que les feedbacks.

    affiche attls 2015

    J1: ateliers et conférences

    En ouverture, la comédie humaine du travail de Danièle Linhart nous a plongé dans l'histoire de l'organisation du travail dans les entreprises et son évolution depuis les travaux de Taylor. Peu de rapport direct avec l'agilité, si ce n'est une question (qui est par ailleurs revenue lors des questions / réponses) : dans quelle mesure la mise en pratique de l'agilité dans les entreprises est-elle vraiment différente des différents avatars du taylorisme dont l'objectif reste de déposséder les travailleurs de leur savoir, c'est-à-dire de leur pouvoir ? La question reste ouverte...

    Dans un registre plus technique, Baptiste Mathus nous a présenté sa forge logicielle aux petits oignons : un bon retour d'expérience qui nous rappelle que l'agilité du point de vue technique passe par la maîtrise des outils au quotidien. Quelques éléments intéressants aussi quant aux problématiques de conduite du changement vis-à-vis des principes du lean sofware development (de l'intérêt des radiateurs d'information par exemple) ou encore de l'utilité du shadow IT.

    La conférence d'Olivier Azeau nous a rappelé (trop rapidement) les principes du #NoEstimates. Thème repris par l'atelier sur l'art d'avoir tort animé Christophe Heral dans l'après-midi.

    La plénière d'ouverture de l'après-midi était assurée par Luc Pouliquen d'Airbus : longue dissertation sur l'impact supposé de l'application des principes de l'Agile Manifesto sur un projet fictif dans une entreprise comme Airbus. Les présentations qui ont suivies étaient sympathiques, de part le témoignage qu'elles apportaient ou par la performance de l'orateur, mais il faut bien avouer qu'on n'a pas appris grand chose.

    Enfin l'atelier "mettons en mouvement la solution" de Frédéric Duffau était particulièrement intéressant. Celui-ci propose un format de rétrospective basée sur la définition d'un idéal plutôt que sur un mode "cahier de doléances", l'idée étant in fine d'investir chacun dans les actions à prendre.

    J2: open-space

    image

    Le forum ouvert en deuxième journée était bien agréable, peut être plus instructif que la première journée finalement. Quelques ateliers auxquels nous avons participé :

    • la business value : inutilisée en pratique, mais qui peut servir à rappeler l'importance de la valeur du risque (ou d'apprentissage) lors de choix stratégiques ;
    • l'agilité dans les réponses à appels d'offres (surtout lorsqu'ils ne sont pas étiquetés agile) : de l'importance de choisir une méthode éprouvée telle que SCRUM, de former les parties-prenantes à l'agilité et de véhiculer un climat de transparence dans les processus.
    • le recrutement agile : discussions fructueuses autour des idées de questionnaire (graphique) centres d'intérêt / compétences, de suivi de recrutement via des rapports d'étonnement.
    • autour du développeur Heisenberg, celui que l'on ne peut pas observer sans altérer son comportement, nous avons discuté des relations hiérarchiques ou encore des métriques de qualité qui, lorsqu'elles sont imposées par les équipes qualité sont souvent absconses voire contre-productives ; la voie est sans doute dans le bon usage des working agreements.
    • la rétrospective dans la durée, ou quoi faire varier pour ne pas s'essoufler en dehors des formats (en étoile, speed-boat, las vegas, mise en avant de la solution évoqué plus haut, à base de dixit...). Quelques pistes : le lieu, l'animateur, le sujet...
    • pitch elevator agile : l'agilité c'est quoi ? pour qui ? pour quoi ? comment ça se compare ? quels sont ses avantages et sa valeur ? Nous avons chacun tenté l'exercice du pitch avec plus ou moins de succès, mais force est de constater que cela s'améliorait au fur et à mesure. On retient de l'exercice qu'il faut faire attention à se décentrer pour s'axer sur son interlocuteur plus que sur sa propre vision.
    • comment interpréter les résultats de niko niko : ben on sait pas trop ! Intéressant pour avoir une tendance globale dans la durée, et éventuellement détecter un problème. Cela fournit notamment des données à reprendre en rétrospective. Quoiqu'il en soit, attention à bien expliquer le but avant de mettre ça en place.
    • l'agilité sur des équipes distribuées, ou comment les projets Open-Source d'envergure restent la source d'inspiration de référence, avec une ou deux semaines de "team building" par an pour consolider les liens et créer une vision d'ensemble.

    Conclusion

    À la vue de tout ça, on se rend compte que nos pratiques, tant en terme d'agilité que d'entreprise libérée, sont plutôt assez développées. Et ça c'est toujours agréable. Comme disait l'autre, « Quand je m’observe, je m’inquiète. Quand je me compare, je me rassure » !

    Évidemment cela reste loin de la perfection, et voici quelques points qu'on aimerait (peut-être) faire à la sortie de cet ATTLS:

    Bref, nous avons passé un moment sans révolution mais enrichissant et qui donne des idées pour les prochains incréments. Agile quoi !

    Donc merci à toute l'équipe d'Agile Toulouse pour l'organisation !


  • Châtaignes, Saucisson et Méthodes agiles... on était au Raid Agile #4 !

    2016/02/15 by Marla Da Silva

    Adrien, David, Katia et moi avons participé au 4ème raid agile organisé par Pablo Pernot et Claude Aubry dans les Cévennes.

    https://www.logilab.org/file/4386083?vid=download

    Je partage l'avis de Sylvain Thénault, lorsqu'il a dit ici il y a quelques mois "j'ai eu la chance de participer au raid agile organisé par Pablo et Claudio", car à mon avis, c'est vraiment une chance de pouvoir se retrouver dans un gîte des Cévennes pour une formation agile originale pendant trois jours et trois nuits. Pendant cette formation, on arrête tout et on partage ses expériences, on joue, on randonne ensemble, et surtout on apprend les nouvelles pratiques du management, de l’agilité organisationnelle et de la gestion de produit. On parle, bien sûr, de participer à des ateliers d'impact mapping, de story mapping, de faire des échanges sur Scrum, Kanban et d'approfondir ses connaissances sur la culture agile.

    Malgré un côté un peu "monomaniaque" (on est isolé au milieu de nulle part, on fait des randonnées, on arrive en haut de la montagne et on ne parle que des méthodes agiles), à aucun moment on ne parle de vie personnelle, ce qui permet de vite se couper du monde extérieur et s'impliquer dans les jeux. Les profils distincts des participants (grands groupes, PME et indépendants) a permis d'échanger et de se rendre compte que les problèmes ne sont pas si différents et qu'on peut trouver un moyen d'adapter l'agilité pour les résoudre.

    Je n'ai pas pu m'empêcher de réfléchir à ce qu'on pourrait mettre en œuvre pour améliorer les pratiques agiles déjà instaurées au sein de Logilab. Ce qui est intéressant, c'est que je me suis toujours dit que les méthodes agiles ne s'appliquaient qu'aux développeurs, et désormais j'ai vu qu'on peut appliquer cette nouvelle façon de travailler dans tous les domaines d'activité dont celui de la communication.

    Je pense surtout au chef de projet qui doit mener son projet à terme tout en respectant les délais et surtout le budget dédié. Et pour atteindre son objectif, le chef de projet doit penser au contenu, au calendrier, au budget mais aussi à la satisfaction du client (et j'ajouterais même "à sa fidélisation"). À travers les méthodes classiques, on se voit confier le projet, on le démarre et on avance... selon une ligne droite : on valide l'étape précédente avant de passer à la suivante. Sauf qu'il arrive (et très souvent) qu'on ne valide pas l'étape précédente et que, par manque de temps ou de budget, on fonce vers l'étape suivante. Il en résulte un très grand stress et s'il faut revenir en arrière pour corriger un problème, c'est toujours plus coûteux.

    https://www.logilab.org/file/4386092?vid=download

    Dans les méthodes agiles, on nous propose de découper le travail en plusieurs itérations, qu'on gère en tant que "mini-projets" définis avec le client. Ensuite on identifiera — toujours avec le client — les différentes fonctionnalités et leur priorité. Résultat : le client pourra clarifier ses attentes et ses exigences pendant que le projet avance et il se sentira rassuré d'avoir une meilleure visibilité sur le projet (objectifs à court terme livrés régulièrement). L'amélioration se fait en continu, la qualité reste tout le temps contrôlée et les risques sont identifiés au plus tôt. Tout au long du projet, l'équipe reste motivée car ses objectifs sont toujours proches et sont régulièrement atteints (à chaque fin d'itération). Et s'il arrive qu'il n'y ait plus de budget, le projet peut s'arrêter sereinement et le client n'est pas surpris car il a suivi l'évolution du projet.

    Dans les méthodes agiles on se focalise sur l'objectif, on découpe le temps, on fixe des échéances, on propose des livraisons fréquentes, on suggère des aménagements en permanence, on communique avec ses collègues, son équipe et le client (on parle d'un échange étroit entre toutes les parties prenantes, une réflexion constante,) et surtout... on accepte le changement.

    https://www.logilab.org/file/4386097?vid=download

    Par exemple, nous avons appris la méthode Scrum grâce à un exercice consistant à faire ensemble un puzzle de 500 pièces. 3 équipes de 3 personnes ont été formées. À cette occasion nous avons dû :

    • déterminer les exigences du client (son objectif : le puzzle monté),
    • identifier les priorités (quelles étaient les parties que le client souhaitait voir réalisées en premier et pourquoi),

    Des mêlées ont été organisées à la fin des sprints de réalisation afin de contrôler l'avancement du projet. Ceci nous a permis de faire un rapport qualitatif et quantitatif du projet. Le client nous a fait part de son mécontentement, et nous avons pu expliquer que le produit ne pourrait pas être livré dans le délai souhaité. Le client a donc pu comprendre nos contraintes et nous avons pu trouver ensemble une solution satisfaisante.

    Ce jeu m'a permis de comprendre scrum et m'a montré son efficacité. Je comprends mieux pourquoi chez Logilab nous appliquons les méthodes agiles à nos développements et tous nos projets.

    https://www.logilab.org/file/4386104?vid=download

    L'ensemble des outils évoqués tout au long du raid s'appuie sur du matériel issu du mouvement agile. Le contenu est dense, on enchaîne les jeux à grande vitesse, et malgré (ou grâce à) des visions souvent opposées, Pablo et Claude ont su nous immerger dans l’agilité.

    Je ne saurais trop vous recommander de sauter sur l'occasion et de participer à une prochaine édition du raid !


  • Mon premier Agile Games

    2016/03/15 by Sylvain Thenault

    Vendredi et samedi dernier j'ai participé à la 6ème édition de la non-conférence Agile Games France. J'étais assez privilégié sur ce coup-là puisqu'en plus de faire partie des heureux possesseurs d'une entrée, l'événement se déroulait dans mon village, Nailloux ! Voici un petit compte-rendu de ces deux jours.

    Pour commencer il faut savoir que Agile Games est une "non-conférence" : tout est auto-organisé, depuis le choix du lieu jusqu'à la sélection du programme en live. Comme dit Alex, "c'est un peu comme un forum ouvert, mais en moins organisé" ! Chacun affiche sur un mur les jeux qu'il se propose d'animer, voire ceux auxquels il voudrait jouer dans l'espoir que quelqu'un se propose. Ensuite c'est parti ! Et ça marche, moyennant qu'il ne faut pas rater le coche lorsqu'un jeu qui vous intéresse démarre.

    https://www.logilab.org/4980434?vid=download

    Le journée du vendredi a commencé pour moi par le cube bleu. L'objectif est de montrer notre rapport à l'engagement : comme chacun fonctionne différemment face à un engagement, ou encore la différence entre prendre un engagement individuel par rapport à un engagement collectif. Excellent rapport ludicité / apprentissage de mon point de vue.

    J'ai ensuite pas mal papilloné sans vraiment m'installer nulle part : crayon d'Ariane, Néo le robot agile, Playing lean ou encore le Bikascrum... Il y a de l'activité partout et même ainsi on ne s'ennuie pas. J'ai fini par m'installer en début d'après-midi dans un atelier aidant à comprendre et appliquer les principes de la communication non-violente. L'exercice est difficile mais intéressant (j'avoue être impressionné par la maitrise d'Isabel). Enfin, la journée s'est achevée par une petite dégustation de vin : "In vino veritas", animé par l'équipe nantaise d'Agile Garden. On y a approché la différence entre les résultats obtenus de manière individuelle ou en groupe, sans modération particulière. Comme souvent, la vérité est dans un compromis, ou du moins dans une approche permettant à chacun de s'exprimer.

    Le samedi j'ai attaqué par un icebreaker créatif : commencer par dessiner son voisin, histoire de mettre chacun à l'aise, avant de faire par équipe une mind-map libre, que l'autre équipe devra deviner en partant des feuilles. Et pour encore plus d'énergie, un bon temps dehors pour un chifoumi collectif déjanté, avant de faire un parallèle entre le théatre d'improvisation et les valeurs de l'agilité.

    https://www.logilab.org/file/4980425?vid=download

    L'après-midi, ce fut un energizer collectif "Zoom" autour de l'auto-organisation, planète derdian sur le thème de l'interculturalité, ball point game pour illustrer les interactions équipe / client dans un cadre agile, ou encore un début de jeu expérimental d'Alex où l'on met en place une chorégraphie pour illustrer la conduite du changement.

    Voilà. Et je ne vous parle pas des rencontres, des moments de discussion ou encore du tas d'autres jeux auxquels je n'ai pas participé (improvement kata, beer game, pompafric et autres jeux de cartes et de plateaux)... Bref, un moment plein d'énergie dont on repart ressourcé et inspiré. C'était mon premier Agile Games, et j'espère bien en faire plein d'autres !

    Si vous voulez en savoir plus ou trouver des liens sur les jeux cités, vous pouvez aller voir les billets de Chris ou encore celui de Fabrice.

    https://www.logilab.org/file/4980413?vid=download

    (photo by B.Cabanne)

    Merci à tous les non-organisateurs et participants, et en particulier à Claude pour m'avoir aiguillé jusque là.


  • Agile France 2016

    2016/06/30 by Marla Da Silva

    Nous avons assisté à la conférence Agile France qui a eu lieu les 16 et 17 juin au Chalet de la Porte Jaune, à Paris.

    La grande conférence agile francophone, de la communauté pour la communauté, réalisée dans un lieu exceptionnel proposait d'aborder différents sujets, tels que les méthodes agiles, l'intelligence collective et la facilitation, le développement de logiciels, l'expérience utilisateur d'innovation, les organisations et leur management, etc.

    Dans un cadre très agréable permettant de s'échapper de l'ambiance urbaine, notre équipe a pu assister à quelques conférences qui ont attirées notre attention :

    Facilitation graphique

    Jean-Pierre Bonnafous, qui a participé aux 15 ans de Logilab, a invité les participants à réagir tout au long de ces deux jours et a mis en image leurs retours.

    https://www.logilab.org/file/6729471/raw

    Toutes les sessions d'Agile France étaient présentées sur une fresque. Nous, nous sommes fans !

    https://www.logilab.org/file/6831358/raw

    Utilisateur, fais moi mal : la ditacture du test

    Emilie-Anne Gerch et Nicolas Moreau ont parlé de l'importance du test utilisateur d'une façon dynamique et ont partagé leur expérience concernant le site d'AXA Assurances avec une approche assez drôle : les designers viennent de Vénus et les développeurs de Mars, les utilisateurs sont, quant à eux, de bons Terriens. Comment ramener sur Terre un designer un peu trop perché ou sortir de sa grotte un développeur pour qui un texte blanc sur fond noir est la norme ?

    Grande leçon pour les designers, les développeurs et les chefs de projet, car ceux qui apportent la bonne réponse ce sont les utilisateurs. Selon eux, c'est le jury le plus juste, car ce sont eux qui utilisent le produit final. Les utilisateurs finaux constituent le jury le plus sévère mais le plus juste qui soit. Ils ont des mots parfois crus et des doigts qui cliquent partout sauf là où on avait pensé. :-)

    Les tests utilisateur permettent de tester un produit en conditions réelles. Grâce à ceux-ci, il est possible de recueillir des informations utiles pour améliorer le produit. Ils permettent de donner une priorité à différentes fonctionnalités ou idées. Ils permettent de reconnaître les fonctionnalités à conserver (les plus utilisées, les plus demandées...) et celles à supprimer (celles que personne ne voit ou n'utilise). Ils constituent aussi un moyen d'intégrer efficacement l'utilisateur dans la conception.

    Quelques points permettant de mieux comprendre la psychologie de l'utilisateur :

    L'être humain utilise rarement un outil pour sa fonction primaire. Il est partisan du moindre effort, il bricole et modifie les outils de manière à les adapter à son besoin.

    L'utilisateur souhaite avant tout aller à l'essentiel.

    Il ne veut pas avoir la sensation de devoir apprendre. Il ne lit pas les manuels, il pioche les informations dont il a besoin lorsque la nécessité se fait sentir.

    Il est influencé par l'extérieur (le bruit, un interlocuteur), par son état émotionnel (le stress, la somnolence...) et par son vécu (il calque ses actions sur ce qu'il a déjà pratiqué ailleurs). Son expérience s'étend au delà du numérique.

    Il est "techno-aveugle" : il veut avant tout que ça marche, la technique utilisée ne l'intéresse pas.

    Il est bienveillant : il aura tendance à se blâmer au lieu de remettre en cause le produit et donne des retours d'expérience très facilement.

    Présentation

    Un iceberg pour explorer ce qui ne va pas

    Certains d'entre-nous ont assisté à la conférence Un iceberg pour explorer ce qui ne va pas, animée par Emmanuel Gaillot et Raphaël Pierquin. La session portait sur la découverte de nos réactions face à un évènement donné.

    Cette conférence a démarré par une démonstration pratique basée sur la métaphore de l'iceberg créée par Virginia Satir. Il arrive qu'on agisse et qu'on réagisse d'une manière qui nous surprend ou nous dépasse. Pendant cette session, nous avons exploré ces situations à l'aide d'un exercice inventé par Virginia Satir, basé sur la métaphore de l'iceberg (ce qui est émergé est observable, ce qui est immergé se passe au-dedans). Les participant·e·s ont pu ainsi s'approprier un format de réflexion simple à suivre pour apprendre à mieux se connaître — et possiblement apprendre à mieux s'apprécier.

    Raphaël Pierquin a choisi un évènement qu'il a contextualisé en décrivant les comportements de chaque personne impliquée dans son récit, puis a présenté sa stratégie par rapport à cet évènement. Guidé par Emmanuel Gaillot, qui avait au préalable disposé des feuilles de papier au sol sur lesquelles étaient écrits les intitulés de chaque "case" de l'iceberg, il a ensuite déroulé devant l'assemblée toutes les étapes présentes sous le niveau de l'eau de l'iceberg. À chaque changement de "case" dans son récit, Raphaël se déplaçait vers la feuille idoine, établissant ainsi son propre cheminement physique et mental. Nous avons ensuite eu l'occasion de pratiquer par trinôme puis de discuter de cette méthode avec Emmanuel et Raphaël.

    https://www.logilab.org/file/6832314/raw

    DDD : et si on reprenait l'histoire par le bon bout ? Tout simplement.

    La conférence sur le DDD (Domain Driven Design), par Thomas Pierrainet Jérémie Grodziski a été une synthèse intéressante sur une approche de conception et de développement permettant de se concentrer sur la valeur métier. Cette approche permet notamment de communiquer efficacement et de collaborer avec les experts métier (qui doivent être capables de lire et comprendre notre code !). Les conférenciers ont su extraire certains principes et patrons de conception du fameux "blue book" à l'origine de cette expression, et les rendre accessibles : les "values objects", la couche anti-corruption, l'architecture hexagonale, etc.

    Forum Ouvert

    À cette occasion plus d'une trentaine d'orateurs ont proposé un sujet qui leur tenait à coeur. Les personnes intéressées pouvaient débattre sur chaque sujet en groupes spontanés répartis dans tout l'espace de la conférence pendant 45 minutes.

    Dans ce type d'activité, les groupes sont petits et donc la répartition du temps de parole est assez homogène.

    Juliette de notre équipe a animé le forum "le bonheur au travail" avec une vingtaine de personnes, elle a pu recueillir beaucoup d'idées intéressantes.

    Voici quelques idées qui se sont dégagées de la reflexion :

    https://www.logilab.org/file/6831796/raw

    Mindfulness & Agile

    Dov Tsal Sela nous a présenté "Comprendre tes équipes, pour comprendre à toi-même". La pleine conscience est l'art de regarder le moment présent avec clarté. En nous conseillant de faire un voyage à travers le Taoïsme, les neurosciences et le royaume animal pour comprendre comment sont prises les décisions personnelles et en groupes (et qui les prend…)

    Au cours de cet atelier, nous avons pu visionner des vidéos, et même méditer un peu.

    Comment j'ai recruté mon pair ?

    Juliette a assisté à une conférence animée par Houssam Fakih et Jonathan Salmona centrée sur le recrutement. Partant du principe que les profils trop semblables feront les mêmes erreurs et souhaitant recruter les bonnes personnes pour leur société, ils ont développé leur propre méthode d'évaluation. L'entretien est, pour eux, une des nombreuses vitrines de l'entreprise, aussi souhaitent-ils que cette expérience se déroule de la manière la plus professionnelle possible. Ils ont établi un modèle d'entretien, ce qui assure l'équitabilité des chances pour tous les candidats. Ils ont présenté leur grille d'évaluation, les différentes difficultés rencontrées, les pièges à éviter, les retours de leurs candidats, le suivi des nouvelles recrues ...

    Mais aussi...

    Laura a participé à une discussion intéressante sur le travail agile réparti sur plusieurs sites. De nombreux participants ont fait des retours sur leur expérience, qui parfois impliquait une équipe de développement répartie dans plusieurs pays. À la distance peuvent donc s'ajouter des difficultés liées aux différences culturelles. En laissant de côté ce dernier aspect qui nous concerne moins à Logilab, plusieurs éléments sont applicables sur nos développements répartis entre Paris et Toulouse :

    Des obstacles à garder en tête :

    Il est difficile de capter le ressenti à distance.

    À distance, on ne bénéficie pas de l'"info café" : ces conversations informelles dans le couloir ou la salle café, qui souvent contiennent des informations utiles pour le projet en cours.

    Certaines pratiques sont plus compliquées à distance : rétrospective, planning poker... Mais il existe des applications en ligne pour ça.

    Il est important de :

    Se rencontrer régulièrement, pour partager la même vision et souder les équipes.

    En début de projet, se mettre d'accord sur un "contrat de développement", avec entre autres les bonnes pratiques et le processus de revue et d'intégration.

    Que tout le monde ait accès à la même information : idéalement, le product owner devrait être sur un troisième site distant, pour ne "favoriser" personne. Si il n'y a pas de PO, faire en sorte que des développeurs de chaque site puissent assister régulièrement aux réunions client.

    Et enfin, pourquoi pas...

    Mettre des webcams en salle de pause.

    Faire du pair-programming réparti.


  • Rencontre autour de l'entreprise libérée à Toulouse

    2016/11/23 by Sylvain Thenault

    J'ai eu l'occasion de participer à une rencontre autour de l'entreprise libérée organisée par l'APAP et NOÏO sur Toulouse. Voici quelques notes pour la postérité.

    https://www.logilab.org/file/9306297/raw/20161121_214833.jpg

    La première partie de cette rencontre était la diffusion du documentaire E 3.0, Une entreprise humaniste qui présente les 6 premiers mois de la "libération" d'Averia, une entreprise de miroiterie d'ile de france. Le réalisateur était présent et nous a annoncé en amont de la projection son parti pris volontaire pour l'entreprise libérée (ce qui n'est pas pour me déplaire). J'ai trouvé ce documentaire intéressant de par l'aspect "témoignage sur le vif" et par le suivi sur quelques mois de cette phase critique de transformation. Ça donne envie de savoir où il en sont maintenant (la période filmée est le second semestre 2015).

    La seconde partie s'est déroulée sous la forme d'un forum ouvert. Au delà des sujets de départ que j'avais choisi, cela m'a surtout permis d'échanger avec d'autres personnes dont l'entreprise est plus ou moins avancée sur le chemin de la libération (j'ai du mal avec ce terme que je trouve un peu galvaudé mais bon). J'y ai notamment rencontré une dirigeante d'une société de pose de parquets (Erah), en voie de "libération" depuis 5 ans. Celle-ci a pour le moins étonné tout le monde lorsqu'elle nous a appris que ses salariés avaient décidés ensemble d'être tous payés pareils, indépendamment de leur expérience (mais légèrement au dessus des prix du marché même pour les expérimentés), ou encore que la société finançait à ses salariés des stages sur leur temps de travail, indépendamment de l'intérêt du sujet pour elle. J'ai également discuté avec la dirigeante de Fun and fly qui gère son entreprise d'une dizaine de personnes dans la veine de l'entreprise libérée sans le savoir jusqu'ici. Non sans similitude avec Logilab, où nous avons grandi depuis 2000 avec bon nombre de principes aujourd'hui regroupés sous la bannière de l'entreprise libérée.

    https://www.logilab.org/file/9306355/raw/20161121_222142.jpg

    La soirée s'est conclut pour moi avec le directeur de Web-Atrio qui devrait prochainement inviter le petit groupe que nous avons formé à un déjeuner ou diner afin d'aller plus loin dans les échanges autour de nos avancées et expérimentations respectives, élément qui est apparu essentiel à chacun, même si nous n'espérons pas y trouver de recettes miracles s'appliquant à tout le monde.

    Pour aller plus loin, le lecteur intéressé pourra :

    • regarder cette conférence d'Isaac Getz qui m'a été recommandée pendant la soirée (à Logilab Toulouse nous en avons regardé une de Frédéric Laloux que je recommende également si vous n'avez pas lu son livre),
    • lire une bande dessinée à ce sujet,
    • suivre ce qu'il se passe du côté de l'association MOM21, qui devrait notamment créer une antenne Sud-Ouest et organiser une journée à ce sujet le 18 janvier prochain (mais je n'ai pas trouvé plus d'info à ce sujet sur leur site).

    Merci à tous les organisateurs pour ce moment rondement mené et qui a permis de se rendre compte qu'on n'est pas seul sur le chemin !


  • Le forum ouvert

    2016/11/23 by Sylvain Thenault

    J'ai eu l'occasion de participer une nouvelle fois à un forum ouvert lors de la rencontre autour de l'entreprise libérée organisée par l'APAP et NOÏO (la dernière, c'était à l'Agile Tour Toulouse) . J'en ai fait un petit compte-rendu mais ce n'est pas l'objet de ce billet.

    Comme je trouve que le forum ouvert est vraiment un format super pour tirer le meilleur parti d'un groupe de gens indépendamment de la taille du groupe, je vais ici faire un petit rappel des bases (telles qu'elles nous ont été rappellées lors de cette rencontre), qu'on peut ensuite adapter en fonction de ses propres contraintes.

    Les principes du forum ouvert (ou Open Space) sont inspirés du fait que dans les conférences, la plupart des choses intéressantes sont dites en off : en discutant entre les conférences, pendant le café, devant la porte, etc. L'idée est donc de transformer la conférence en une grande pause avec des discussions libres, en petit groupe, autour d'un thème donné et avec les quatre principes suivants pour mettre tout le monde à l'aise :

    • toutes les personnes présentes sont les bonnes personnes,
    • ce qui arrive est ce qui pouvait arriver,
    • quelque soit le moment où ça commence, c'est le bon moment,
    • et quand c'est fini, c'est fini.
    https://www.logilab.org/file/9306538/raw/20161121_194647.jpg

    Partant de ces bases, un forum ouvert se déroule en quatre phases :

    1. introduction du sujet et des principes du forum ouvert énoncés ici,
    2. proposition et éventuellement sélection des sujets,
    3. plusieurs rounds de discussions sur les sujets choisis,
    4. choix d'actions et clôture.

    Une fois le sujet introduit, voici le détail du déroulement des étapes suivantes...

    L'émergence des sujets

    Dans cette première phase, chacun est invité à proposer un sujet qu'il va écrire en gros sur une feuille en y indiquant également son nom. Cette feuille sera affichée sur un tableau qu'on nomme la place du marché, accompagnée d'une indication de l'heure et du lieu où aura lieu cette discussion.

    Pour cette indication, l'organisateur aura au préalable préparé une grille d'emploi du temps déduite :

    • du nombre de discussions en parallèle (en fonction de l'espace ou des tables disponibles ainsi que du nombre de personnes présentes - compter entre 5 et 10 personnes max par groupe),
    • de la durée et le nombre de créneaux successifs (au moins 40 minutes pour un créneau, le temps passe vite !).

    À partir de ces informations on obtient une grille horaire dans laquelle les propositions pourront être placées, ainsi accompagnée d'un lieu (en général un numéro de table) et d'un créneau horaire.

    https://www.logilab.org/file/9306522/raw/20161121_194729.jpg

    On peut apparemment tabler sur une proposition de sujet pour deux personnes en moyenne. Si plusieurs propositions sont similaires, il est possible de les recouper si les porteurs du sujet le souhaitent. Enfin s'il est nécessaire de faire une sélection, on peut demander aux participants de "s'inscrire" sur les sujets afin de voir lesquels sont les moins suivis.

    Le temps des discussions

    Et c'est parti pour le premier round de discussion ! Chaque porteur de sujet s'installe à sa table, y indique clairement le sujet discuté (on laisse l'affichage général en place pour les retardataires et promeneurs) et attend d'être rejoint par d'autres personnes également intéressées par ce sujet. Il a deux responsabilités :

    • introduire le sujet,
    • s'assurer qu'un compte-rendu sera écrit (mais pas forcément par lui).

    Animer la discussion n'en fait pas parti.

    Pendant les discussions, on peut ajouter :

    • la loi des deux pieds : chacun est libre s'il en ressent l'envie pour une raison ou pour une autre de quitter sa table pour aller s'installer sur une autre,
    • les abeilles qui butinent de tables en tables, sans jamais vraiment s'installer mais en permettant d'essaimer l'information d'une table à l'autre,
    • les papillons qui papillonnent un peu en marge du processus, mais il n'est pas rare d'en voir émerger des choses.
    https://www.logilab.org/file/9306530/raw/20161121_194658.jpg

    Une dizaine de minutes avant la fin du créneau, l'organisateur indique qu'il est temps de s'assurer que le compte-rendu de la discussion sera fait. Enfin à la fin du temps imparti, chaque table va afficher son compte-rendu sur le grand journal.

    https://www.logilab.org/file/9306515/raw/20161121_212456.jpg

    Je trouve qu'il est intéressant de réserver un créneau à ce moment là pour qu'une personne par table présente ce compte-rendu en quelques minutes, car il est parfois difficile de se contenter de ce qui est écrit ou dessiné.

    Après on enchaîne rapidement sur le round suivant, et ainsi de suite.

    La clôture

    À ce moment là, tout le monde commence à être bien détendu, en confiance, et à connaître au moins une partie des participants. Afin de faire avancer la cause discutée, on va effectuer une dernier round de propositions / discussions dont l'objectif est de dégager des actions réalistes à court terme. Sur le modèle des étapes précédente, les participants sont invités à proposer une action qu'ils ont envie de tirer (ou de voir tirer) avec d'autres. Ils l'énoncent et l'affichent sur le marché aux actions.

    Une fois toutes les actions proposées, les personnes intéressées par une action donnée se regroupent et structurent une action qui sera énoncée devant l'assistance une fois le temps imparti écoulé. Si possible, l'organisateur effectuera un suivi de ces actions après l'évènement.

    https://www.logilab.org/file/9306297/raw/20161121_214833.jpg

    Il est ensuite temps de se féliciter, de se remercier, d'annoncer la suite ou toute autre chose utile avant de se quitter.

    Les photos sont tirées de l'évènement sus-cité, merci aux organisateurs et en particulier ici aux facilitateurs graphiques !