#Barcamp : Journée 4, la dernière !

Pour la dernière journée, nous avons prévu une séance de veille de 2H + présentation puis de rendre le gîte à midi pour faire la rétrospective l’après-midi dans un lieu encore tenu secret 😉

Vincent et Julien sont partis sur la limite entre traitement client et traitement serveur (une bonne pratique à mettre en commun ;))

Thomas et Lise sur les pseudo élément CSS, pour expliquer ces concepts assez peu répandus dans le service.

Pierre-Olivier regarde les nouveautés du côté de Rails 5 et oui il faut évoluer avec notre framework.

Matthieu regarde l’utilisation des assets Ruby On Rails.

Jérémie pour sa part nous a présenté les canvas et leur utilisation.

Midi, nous rendons le gîte et c’est parti pour un resto suivi d’une rétrospective.

Fin de la journée, et voilà le volet du Barcamp 2016 refermé.

A l’année prochaine, on espère 😉

Le service Web

#Barcamp : Journée 3, seconde journée de veille complète

En ce jeudi du printemps agile, que nous avons donc raté :(, dommage, nous nous sommes remis au travail.

Le départ est lancé à 8H40, sur des sujets très divers pendant une séance de 3H suivie des présentations toujours riches en discussion. Le barcamp permet vraiment de confronter des visions et de trouver un consensus commun partagé et appliqué par tous (même si on ne peut pas contenter tout le monde chacun fait des concessions, merci l’agilité d’avoir mis fin à la raison du plus fort ;)).

Pierre-Olivier et Vincent sont en pleine réflexion sur la factorisation du code notamment sur le développement Ruby on Rails.

Julien et Lise sont partis sur les slideshow touchable et swipeable, une étape nécessaire pour les écrans tactiles notamment qui représentent plus de 50% de nos visiteurs, on doit faire attention à l’ergonomie pour ceux-ci.

Matthieu et Jérémie partis ensemble sur les systèmes d’animation que ce soit CSS3 ou SVG, ils se sont vite aperçus que ces 2 éléments de veille étaient trop distincts pour être traités ensemble, ils sont donc partis chacun sur un sujet.

Thomas quant à lui est parti sur la veille pour les sites one page, une sorte de site que l’on commence à faire pour les marques qui ne nécessitent pas trop d’investissement sur le numérique.

C’est la pause, le midi, un repas bien mérité et on s’y remet.

C’est reparti pour 3H et les présentations.

Jérémie et Matthieu repartent ensemble sur les unités relatives

Pierre-Oliver et Julien sur l’organisation de réalisation de sites et de communication notamment avec un service avec qui nous traitons souvent.

Thomas et Lise se lancent dans la communication avec un autre service avec qui nous traitons souvent.

Vincent part seul sur le temps réél, la veille c’est aussi revenir sur des sujets déjà étudiés pour voir s’ils ont évolué et dans notre métier c’est souvent le cas quand un an s’est écoulé.

Fin de la journée 18H45-19H, ce soir restaurant conseillé par Thomas le fin gourmet de l’équipe.

A demain.

#Barcamp : Journée 2, première journée de veille complète

La journée du Mercredi commença à 8H30 par une première séance de veille de 3H suivie d’une heure de présentation des sujets étudiés.

Thomas et Vincent nous ont présentés leur veille sur Flexbox, une technique qui simplifie grandement la gestion de position des blocs HTML, sûrement dans nos prochains sites, à suivre…

Lise et Pierre-Olivier nous ont présentés leurs idées sur l’amélioration de la communication d’une équipe avec une personne en télé-travail. Ce sujet ne remplissant pas les 3 heures, ils ont aussi commencé à plancher sur le sujet de la typo web, ses limites, les bonnes pratiques pour ne pas avoir de comportement bizarre quand le chargement est lent…. Pas de présentation pour le moment, le sujet sera revu ultérieurement.

Matthieu et Jérémie ont quant à eux présenté une utilisation avancée de Sass, les fonctions, les mixins, les héritages, ceci entre directement en résonance avec les sujets CSS et notamment l’organisation de celui-ci pour un repérage plus facile.

Enfin Julien a étudié les astuces présentes dans les vidéos du site hackademy.io, site destiné à apprendre sur les technologies web et notamment Ruby qui est notre langage principal depuis maintenant 6-7 ans. Ce service est proposé par Synbioz, une agence de communication très reconnue dans les métiers du Web et qui utilise comme technologie de base Ruby, il est donc toujours intéressant d’écouter les conseils de ces acteurs qui ont une expérience plus qu’avérée.

La pause du midi, se déroula dans un petit resto sur Courseulles sur Mer et retour au gîte pour la seconde séance de veille 3H suivie de la présentation des sujets étudiés.

Jérémie et Vincent ont présenté les Webcomponents, technologie peu répandue mais qui pourrait être intéressante à l’usage.

Pierre-Olivier et Thomas sont partis sur l’intégration des emailing, cela tombe bien nous en faisons de plus en plus, pour les pharmaciens d’une part et nous allons nous (re)lancer dans les emailing pour les consommateurs. L’aspect responsif de ces emailing est l’une des pistes qui a été étudiée.

Matthieu et Julien ont quant à eux défriché le sujet ReactJS, le besoin d’utiliser cet outil ou un concurrent n’est pas flagrant mais la technologie ne doit pas nous faire refuser un projet à nous même de proposer des outils performants via ces nouvelles technologies. Mais la conclusion est sans appel, cet outil est un peu complexe, pas super mûr et ne répond pas à nos besoins pour l’instant (un peu comme angular à l’époque). Ces outils ne sont utilisés que dans des cas bien particuliers, or nos cas sont tout à fait réalisables avec un code jQuery mieux organisé. Nous resterons donc sur nos technologies actuelles, c’est aussi ça la veille, prendre du temps pour étudier un sujet et pouvoir prendre la bonne décision de l’utiliser ou non et parfois c’est non car ce qui prime est le contexte.

Lise est partie vers la veille des webdesigns et tendances actuels afin de pourvoir partager avec nos interlocuteurs ces données récoltées. Et les tendances ne sont pas toujours celles qu’on croit.

La journée de travail se termine à 17H45, un petit quart d’heure et toute l’équipe se lance dans une session de course à pied jusqu’à 19H15 pour certains et d’autres jusqu’à 18H20 😉 et oui chacun son niveau mais tout le monde court ensemble… Un bon moment commun de détente, chacun son ordinateur, ok on est un peu geek mais certains luttent contre cette conclusion en sortant des livres 😉 et bonne nuit.

La suite demain…

#Barcamp : Journée 1, arrivée et lancement du Barcamp 2016 !

En ce jour du mardi 22 Mars 2016 à 9H15, nous arrivons sans heurt au gîte hormis pour Matthieu, Jérémie et Julien qui avec une voiture plus que chargée (à cause des courses) se sont perdus, enfin ont pris un raccourci qui n’en était pas un 😉

Le gîte est superbe, 7 chambres distinctes, 4 salles de bain et une grande table, juste ce qu’il faut pour 7 voire 8 personnes. Petit lancé de dé pour attribuer les chambres et chacun pose ses affaires dans son espace nuit.

10H30 : Tout le monde est prêt, on lance le premier sujet et pas des moindres « la définition et la mise en commun de bonnes pratiques », sujet basé sur notre expérience individuelle et mise en commun.

Il nous aura fallu pas moins de 7 heures acharnées de discussion sur des sujets aussi variés que le nom de nos variables jusqu’à l’indentation du code en passant par les endroits et la façon de factoriser du code.

Ce sera évidemment le seul sujet abordé et on en a sûrement oublié des choses, mais forcé de constater que cela était nécessaire.

Et oui, on ne fonctionne pas en équipe à 7 comme on fonctionnait à 4, les choses changent, évoluent et de nouvelles contraintes apparaissent, de nouvelles idées aussi, il faut savoir prendre le temps qu’il faut pour mettre à plat tout ça et garder une cohérence dans l’activité du service.

La journée se termine donc à 19H, s’en suit une préparation du repas en commun ainsi qu’un tout petit moment de détente individuelle car ce soir c’est poker… Il est lancé à 21H et se soldera par une victoire de Jérémie, partie tout aussi acharnée avec chacun son moment de grâce.

Le barcamp continue demain….

Développement de projet guidé par le comportement – Printemps agile 2015

David et Pierre, de KNP Labs à Nantes, nous ont présenté le technique du développement de projet guidé par le comportement, Behavior Driven Development (BDD), lors du Printemps agile 2015.

Les 3 grandes questions qu’ils se posent sont les suivantes :

  • Comment décrire les besoins d’un projet en évitant un énorme cahier des charges exhaustif ?
  • Comment utiliser le même langage entre l’équipe du marketing et l’équipe de développement afin d’éviter les incompréhensions ?
  • Comment accélérer le début du projet afin de développer et tester une fonctionnalité le plus tôt possible ?

C’est notamment suite à cette conférence que je me suis intéressé à RSpec, celui-ci se définissant comme un framework de test guidé par le comportement pour Ruby.

La vidéo de leur présentation est disponible sur le site de KNP : KNP au Printemps Agile : La BDD expliquée à Michel, le maçon

Les TDD en toute agilité, par Julien et Pierre-Olivier – Printemps agile 2015

Notre équipe a été invitée à faire une présentation durant ce Printemps agile 2015. Julien et Pierre-Olivier se sont lancés et ont proposé d’aborder la technique du TDD, ou Test Driven Development (développement piloté par les tests en français), technique que l’équipe pratique quotidiennement.

Juste après avoir (peu) mangé, Pierre-Olivier et Julien ont donc présenté la technique du développement piloté par les tests. Ils ont montré l’intérêt de cette technique et ont, à travers un live-coding, expliqué la façon dont nous la pratiquons au sein de l’équipe.

Les TDD en toute agilité
Pierre-Olivier et Julien nous présentent le contenu de leur présentation.

La qualité des questions posées à la fin de la présentation a montré l’intérêt porté par l’assistance à cette présentation. Les questions ont permis d’approfondir quelques points abordés succinctement et d’élargir le dialogue aux tests d’intégration, sujet qui n’avait pas été développé durant la présentation, et au développement de tests automatiques pour des applications existantes non testées. Ne pratiquant pas les tests d’intégration, Pierre-Olivier et Julien ont laissé la parole à Frédéric, présent dans l’assemblée, qui a évoqué les deux solutions Selenium et Nagios. La personne s’étant questionnée sur la refonte d’applications non testées a été invitée à suivre la présentation de Mathieu Sadouni et Pierre-Emmanuel Fringant intitulée « Sécuriser une refonte avec le Golden Master Testing » se déroulant juste à la suite de celle-ci.

Les slides de la présentation « Les TDD en toute agilité » sont disponibles à l’adresse : http://slide.julien-anne.fr/les-tdd-en-toute-agilite

Definition of done, comment ?

Le but de cette veille était de voir l’intérêt de cette definition of done (définition de terminé ou fait en français) et comment la mettre en place au sein du service si cela peut être intéressant.

Déjà d’où vient cette définition ? Sur ce point je me suis souvent trompé en pensant qu’elle venait du système Kanban. Et bien non elle provient de Scrum. Mais Kanban n’est pas en reste car il possède une notion similaire qui est la ou les règles de passage d’une colonne à l’autre. Scrum nous indique que la definition of done est la liste des critères que doit remplir un incrément pour être considéré comme terminé. Scrum indique aussi que si un des critères n’est pas rempli l’incrément n’est pas terminé donc pas compté dans la vélocité (nous on ne la calcule pas vraiment donc pas de souci). Cette définition doit être composée de différents types de critères : pérennité du logiciel, support de mise en production (doc si besoin, commit de git, merge si nécessaire, …), requis du monde des affaires (prévenir le PO, les utilisateurs, tracer les changements, …). Ces différents aspects permettent de couvrir les différents points de vues des acteurs de l’incrément.

Quelques erreurs à éviter selon Scrum :

  • Liste de critères trop importante -> contre productif
  • Liste implicite peu d’intérêt plutôt mettre par écrit les choses même triviales car il arrive à tout le monde d’oublier.
  • Éviter les incréments en suspend en se disant je reviendrais dessus plus tard.
  • Il faut que dans tous les cas on puisse checker la totalité des critères.

Pour notre part on ne va pas choisir entre l’un et l’autre nous allons prendre les deux. D’un côté comment déterminer qu’une tâche est terminée et de l’autre comment faire avancer ces tâches dans chacune des colonnes de notre Kanban. Voyons maintenant comment déterminer ces règles qu’il faut écrire, afficher et partager entre tous les membres de l’équipe, l’objectif est d’avoir une façon de travailler proche et de limiter les erreurs sur des choses que l’on ne fait pas régulièrement.

De mon point de vue, il faut partir du contexte dans lequel vous êtes, prendre toutes les bonnes pratiques de chacun en discuter avec tous les membres et se mettre d’accord sur les points qui peuvent poser problème.

Par exemple, je fais une branche, j’écris au moins un test qui échoue, j’écris le code de l’application, je lance tous les tests, ils passent tous puis je merge ma branche, je push mon code, je fais un test en prod et je préviens le PO.

Voilà, il est important de prendre conscience que ces règles ne peuvent être universelles, elles peuvent être proches mais pas universelles, chacun fonctionne à sa manière et le but n’est pas de standardiser cela mais bien d’améliorer cette manière de fonctionner.

Systémique, par Rémy Génin – Printemps agile 2015

Rémy Génin nous a présenté la « Systémique », une séance riche voir très riche. La systémique est une approche au même titre que l’agilité. Il a donc tout au long de la présentation fait un parallèle entre ces 2 approches similaires mais pas identiques, et cependant compatibles. La systémique a été élaboré en 1958.

Premier point commun, ce sont toutes deux des approches empiriques, elles se pratiquent en faisant, on teste, on essaie, on change, on revient en arrière, …

Qui dit systémique dit système. Un système est un ensemble d’éléments en interaction pour un objectif commun.

Les fondations sont la relation entre les différents éléments, la qualité individuelle des personnes passe après la relation.

Il y a toujours une finalité positive à toute action réalisée, mais on ne la voit pas toujours de notre point de vue. Il faut alors recadrer sa vision pour trouver cette finalité positive et ainsi pouvoir discuter avec la personne a l’origine de l’action, si celle-ci est négative pour le système.

La systémique lutte contre les procédures, pas contre les processus. Les procédures sont les chemins qui permettent d’atteindre un objectif, ils n’ont pas besoin d’être définis. Les individus savent quel chemin prendre et ils peuvent même le modifier pour le rendre plus efficace. Le processus quant à lui indique un but, un objectif. Ce dernier est suffisant pour les éléments du système.

Le principe de totalité nous indique que le tout est supérieur à la somme des partis, lors du binômage, certains disent que 1+1=3. L’interaction des 2 premiers individus génère les idées qui auraient pu être apporté par une 3e personne, ce qui est un gain énorme de productivité. Lorsque vous êtes 6 répartis en 3 binômes, vous pouvez quasiment atteindre la productivité de 9 personnes travaillant seules.

Les systèmes sont toujours englobés par un système plus grand, l’objectif du système le plus englobant prime sur l’objectif du système englobé. Si une action apporte un bénéfice à un service mais devient négatif pour une entreprise cette action doit être annulée.

La systémique se base aussi sur le concept de rétroaction. Le postulat comme quoi une cause entraîne un effet puis une fin est faux. Pour la systémique, une cause entraîne un effet qui entraîne un effet qui entraîne un effet … de façon infinie.

Le « Pour quoi ? » (dans quel but ?) est important, le « Pourquoi ? » (la cause) l’est moins.

Pour résoudre un problème, il faut un mouvement dans le système, cela entraînera un changement qui peut permettre de résoudre un souci.

Mais attention, un système répond au principe de l’homéostasie : Il cherche toujours un équilibre et se stabilise. Si le changement est trop superficiel, il sera absorbé par le système et celui-ci reviendra à son état d’origine.

Un autre principe est que la réalité est construite environ 30% provient des sens (réalité de première ordre commune à tous) et 70% environ provient de nos souvenirs et expériences passées (réalité de second ordre propre à chaque individu). Le but est d’agir sur cette réalité de second ordre en élargissant notre vision en changeant de pont de vue et en agissant sur ce que perçoivent les individus et non ce qu’ils sont.

La systémique donne aussi des retours rapides. Si le message n’est pas compris il faut le reformuler pour s’adapter à son interlocuteur. Cela présume que l’interlocuteur ce sente assez en confiance pour indiquer qu’il n’a pas compris certaines choses.

Afin de mieux comprendre ce que perçoit notre interlocuteur, nous devons changer notre façon de penser grâce à un recadrage en ouvrant. Il faut éviter les prophétie auto-réalisatrice négative, si on dit à une personne « tu es mauvais », elle le sera.

Rémy nous a ensuite invités à regarder une conférence TED sur l’éducation positive.

Il indique que la systémique n’est pas un système binaire bien ou mal mais un système ou cela peut être bien et mal.

Afin de modifier un système, il existe deux types de changements :

  • Le type 1 : Adapter les règles existantes. Il est simple et indolore.
  • Le type 2 : Plus contraignant : remplacer les fondamentaux. Cela nécessite de l’apprentissage.

Cela doit toujours se passer dans le respect et l’écoute de l’avis de chacun des éléments du système.

Les outils pour mettre en mouvement le système et ses acteurs sont divers et variés :

  • Le questionnement
  • La réflexion
  • Le silence permet de prolonger sa réflexion

Ces outils permettent aux acteurs de trouver LEURS solutions et non pas les miennes. Elles seront donc plus facilement acceptées, manipulation positive.

Il faut susciter le désir. Être convaincant ne suffit pas, il faut montrer en quoi le progrès est positif. Il faut montrer le chemin et non pas l’emprunter à la place des personnes. Il faut se donner rendez-vous à un point (objectif – vision). L’important n’est pas le moyen de s’y rendre mais bien de s’y rendre.

Il faut, à intervalles réguliers, faire un état des lieux des points qui fonctionnent bien et un ce qu’il faut améliorer.

Explorer les solutions dans les expériences de chaque éléments du système pour voir si elles peuvent répondre au besoin du moment.

Ne pas hésiter à faire rêver, cela aide les personnes à passer le pas du changement. Recadrer en utilisant le « et » pas le « ou ». Imagine le pire est aussi un moyen de sauter le pas du changement, si le pire n’est pas trop atroce ;). Dire que l’on a une solution sans la dire, cela invite les gens à réfléchir en se disant qu’une solution existe, et qu’ils leur faut la trouver. Cela retourne de la manipulation bienveillante car réalisée pour les autres et non uniquement soi. Il faut cependant toujours s’adapter au contexte et non partir d’une base inexistante.

La finalité est le maître mot de la systémique : sans vision les personnes ne pourront comprendre l’intérêt du changement.

Les bonnes intensions ne suffisent pas, il faut réaliser les actions qui vont avec. Il n’y a pas forcément 1 ou 2 solutions mais peut être une 3e. Essayer d’aller dans le sens de l’interlocuteur pour comprendre son point de vue et voir comment ce point de vue peut s’intégrer dans le système.

C’est par le système auquel il appartiennent que les individus se définissent, il est donc important que celui-ci soit bâti avec eux (ex: un service).

Voici pour la présentation sur la systémique, forte intéressante et effectivement, elle partage pas mal de notions avec l’agilité.

Retour et débrief du barcamp 2015

L’heure du barcamp 2015 étant sonné, il est temps de débriefer et de faire une rétrospective (et oui contexte agile oblige 😉).

Le débrief a duré environ 2 heures, quand on donne la parole aux personnes ils la prennent et cela fait plaisir.

Plusieurs axes de retours :

L’espace de travail, des locaux : Le retour est sans appel, il nous faut à la fois un open space pour la synergie des idées à l’instant T et des espaces d’isolement pour les tâches qui demandent une concentration maximale.

Le lieux géographique : A l’identique, le retour ne donne pas place aux doutes, le barcamp doit avoir lieu à l’extérieur de la société, la proximité du quotidien à notamment pesé sur la gestion des petits tracas non urgent mais que l’on n’aime pas laisser trainer.

Renforcement de la cohésion d’équipe : Cet aspect a été complétement laissé de côté dû au fait que les personnes rentrent chez elles tous les soirs (lieux géographiques) et ne mangent pas ensemble ni n’ont d’autres activités que celle du travail. Un exemple concret la partie de poker avec des pizzas (achetés en minibus ?) le soir après 22H a manqué à chacun des participants. Ce point marque définitivement le lieux géographique de cette année comme à ne pas reproduire.

La durée : Ce point a soulevé plus d’échanges, 4 jours oui mais, la majorité indique quand même que cela est plutôt une bonne durée. La séparation est elle aussi au coeur des débats mais un système de 2*2 jours avec un week-end entre deux serait la solution préconisée. A voir les possibilités qui s’offriront à nous les prochaines fois.

Le format : deux points sortent du lot, horaires peu flexibles dommage et pas de time box sur les présentations qui du coup s’envolent un peu parfois.

Déconnexion du quotidien : Sur ce point des choses sont à améliorer ou au moins revenir à ce que l’on a pu faire en 2013, à savoir être moins à la disposition des collègues pour éviter les appels pas utiles qui génèrent toujours une pensée en plus et une déconcentration. Il est clair que ce genre d’évènement ne raisonne que si l’on ne fait que ça. Mais nous ne pouvons pas omettre que les projets ne permettent pas de faire ce que l’on veut, peut-être faut-il mieux prévoir le moment du barcamp. Un petit manque de communication aussi sur cette activité et son aspect trop peu officiel auprès de nos collègues. Encore une fois sur cet aspect l’environnement géographique prend toute son importance.

Matériel : Point positif pour les ordinateurs portables, un petit bémol sur les serveurs qui mériteraient peut être d’être préparés en amont du barcamp afin de faire des tests de manière plus rapide lors du barcamp.

Contenu : Le contenu convient car les participants les ont déterminé eux-mêmes. Petit bémol sur le manque de temps pour pousser les sujets les plus « gros » ou « intéressants ».

Ecrire les articles : Oui mais quand ? Cela pose souci à tous les participants, pendant le barcamp cela perd du temps réel de veille hors du barcamp nous n’avons plus le temps.

Préparation du barcamp : Un serveur de test, la définition du contexte et des problématiques actuelles et le partage plus tôt des sujets aurait permis une meilleure organisation du barcamp.

D’autres retours en vrac : le barcamp est apprécié par l’équipe, il permet d’approfondir les nouveautés. Mais il est sporadique donc trop chargé (trop de choses à voir), un étalement serait peut-être intéressant avec une veille de 2H par semaine avec présentation si nécessaire le vendredi après midi. Nous allons essayer cette formule et voir si cela est jouable. Il a manqué un peu de JS dans ce barcamp, pas assez de binomage sur les sujets. Un manque de mise en pratique direct même si certains sujets ont été mis en pratique, cela est loin d’être le cas standard.

Voilà pour les retours, nous essaierons d’améliorer les choses la prochaine fois.

Cessons les estimations ! par Frédéric Leguédois – Printemps Agile 2015

Frédéric Leguédois est un agiliste évangéliste, libriste et geek humaniste. Au quotidien, il anime des équipes de développement logiciel.

Premier rappel : les coûts d’un projet sont les charges, le délai de réalisation et la qualité de finition. Un coût peut être modulé à condition d’affecter les deux autres. En Agilité, la qualité est le coût non négociable d’un projet, ce qui se traduit le plus souvent par un étalement dans le temps afin de conserver des charges raisonnables.

Cet étalement est d’ailleurs préconisé par l’intervenant, au travers d’un modèle économique basé sur l’abonnement, rendu possible par des livraisons fonctionnelles fréquentes.

Ce modèle raisonne sur la nature du métier et s’oppose à la rédaction préalable de cahier des charges pour les raisons suivantes :

  • Un cahier des charges est rédigé en amont du projet, par des personnes qui ne sont bien souvent pas développeurs, qui ne peuvent ni estimer le travail à réaliser, ni anticiper la complexité d’une création nouvelle
  • Un cahier des charges comporte en conséquence des estimations de coûts et de temps imaginaires, qui sont néanmoins acquis comme Vérité
  • Par la contractualisation des pénalités de retard, l’équipe de développement reçoit une pression anti-qualitative qui génère la dette technique
  • Annoncer un délai annihile la capacité des développeurs à prendre des initiatives, pour automatiser, refactoriser, optimiser, et à être moteurs
  • L’équipe réalise le projet, mais si elle est considérée en retard sur la prévision arbitraire qui lui est appliquée, elle se démotive (cercle vicieux)
  • Ce type de projet entraine automatiquement un perdant : le prestataire ou le client arnaque l’autre, car la prévision de délai est fausse

Pour Frédéric Leguédois, le Planning Poker permet bien d’estimer à 15j la complexité des tâches à réaliser mais demande plusieurs itérations. Cette méthode ne permet toujours pas d’annoncer une prévision de coût ni de temps en amont du projet, qui sont la raison même de consommer du temps et de l’argent à réaliser des estimations.

En revanche, les estimations mesurent si les gens travaillent, ce qui est biaisé et faux à la fois. Tenir un délai n’est pas synonyme de travailler proprement, mais ne pas tenir un délai permet de désigner un ou plusieurs coupables.

L’intervenant constate que s’il est impossible d’estimer quelque chose qu’on fait pour la première fois, on peut mesurer ce qui est reproductible et en déduire une estimation, bien que cette méthode ne soit pas réceptive au changement.

Si Frédéric n’aime pas les estimations, c’est qu’il estime qu’elles créent du retard là où il y a des gens qui travaillent, alors que prendre du temps est un investissement dans l’amélioration continue pour gagner en efficacité au fil du temps. Estimer est donc contre-productif.

Une constatation simple est ce qu’attend le client : être livré. Dès lors, des estimations non fiables suffisent, réalisables non pas en amont mais tout au long du projet, en prenant des mesures sur le travail réalisé.

L’intervenant présente ainsi différentes approches pour amener le client à dévoiler ses motivations de délai : est-ce une contrainte financière ? Légale ? Arbitraire ? Quelle serait la gravité de ne pas tenir le délai face au gain de fonctionnalités dans le MVP ?

Coopérer avec ses partenaires évite de créer des conflits qui servent notamment la concurrence, en lui laissant le temps de prendre de l’avance.

La solution avancée repose donc sur un modèle itératif, par exemple mensuel, où l’équipe rencontre le client pour lui présenter l’évolution du produit en production et recueillir ses nouvelles demandes.

La vision du client évolue avec son produit, ce qui lui offre de la flexibilité mais aussi la possibilité de contrôler le travail livré : le client et le prestataire ont un intérêt convergent à collaborer.

Dans ce modèle par abonnement, le prestataire doit tout faire pour conserver un client satisfait. En lui offrant la possibilité de rompre le contrat à tout moment, il créé la confiance nécessaire pour que le client se sente d’égal à égal, et que ce dernier puisse faire pression (suspension du contrat) si le travail ne correspond pas à ses attentes.

La création de logiciel est souvent illimitée dans le temps, il peut être judicieux d’offrir ou d’avancer la première semaine de travail au client afin de le mettre en confiance. Le prestataire conserve la possibilité de rompre à tout moment avec un client qui serait malhonnête.