Catégorie : Agilité

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.

Après des années de pratique des nombreuses méthodes de relaxation, Loïc Rabault les décrit comme les multiples traductions d’un même livre. C’est de cette manière que son choix s’est arrêté sur la sophrologie, la plus complète selon lui.

La sophrologie développe la conscience de façon à harmoniser le corps et l’esprit, en chassant peurs, stress et tensions.
Source : Doctissimo

La sophrologie est une science de développement de la conscience positive. Le médecin psychiatre Alphonso Caycedo a élaboré la sophrologie en 1960, à partir des connaissances occidentales en relaxation, en hypnose et des techniques traditionnelles asiatiques (yoga, bouddhisme, méditation zen).
Source : Zen Conseil (Loïc Rabault)

L’intervenant évoque le stress comme une notion n’étant ni positive, ni négative : c’est un état de fait qui est spécifique à l’individu, relatif aux évènements vécus, qui évolue sans être toujours reproductible dans des situations semblables. Le stress est finalement nocif sur la durée et dans son intensité, et peut être généré par le changement.

La sophrologie fait parti des thérapies psychocorporelles qui agissent sur 3 dimensions : les sens, les sensations corporelles et les émotions.

L’intervenant de cette conférence, Christophe Addinquy,  a abordé 12 leçons apprises lors de la transition agile du grand projet Linky, en y associant des conseils.

1. L’immersion agile
   • pas facile, pas naturel
   • une journée d’immersion : ateliers, jeux, discussions pour appréhender les mécanismes de l’agilité
2. Commencer lentement et délibérément
   • qualité = les bons gestes, du code testé
   • les premières itérations : focaliser l’attention sur la qualité et pas le nombre de stories réalisées
   • /!\ équipes cherchent à aller vite quand même
3. Le droit à l’erreur
   • rassurer, logique d’expérimentation
   • erreur = opportunité d’apprendre quelque chose
   • laisser l’erreur arriver car on apprend par nous-même
4. Les tests d’acceptation
   • avant de coder
   • spécifications avec de vraies valeurs
   • permet de trouver des bugs en les écrivant
   • créer des compréhensions partagées avec les équipes fonctionnelles, développeurs…
5. La posture du management
   • pas le droit de dire aux personnes comment elles doivent faire
   • manager : porteur de l’objectif, de la vision et du sens. Il est responsable du cadre (moyens, motivation)
6. Veiller à l’auto-organisation
   • écouter et surveiller les phrases comme « on m’a demandé que »
7. Craftmanship
   • la qualité du code = pré-requis de l’agilité
   • 3 axes : facteurs externes (coding dojo), injecter du savoir-faire dans les équipes (binômage, refactoring) et créer de la masse critique pour la qualité du code (augmenter le nombre de personnes agiles pour faire basculer la balance de l’autre côté)
8. Le fond et non la forme
   • « Comment » (=folklore) : post-it, rôles, cérémonies
   • « Pourquoi » : collaboration, feedback, implication, transparence
9. Apprendre à s’améliorer
   • amélioration continue
   • rétrospective : actions faisables, review des actions précédentes
   • pendant l’intégration : action n’importe quand
10. L’architecture compte !
    • importance du feedback
    • ne pas regarder seulement les fonctionnalités, mais comment travailler avec au jour le jour, qu’on peut le tester
11. Off/on : comment faire la transition agile ?
    • par petits pas : apporte une confusion j’y suis / j’y suis pas
    • bien si brutale
    • autonomie de l’équipe
    • terminer un sprint avec un livrable, des tests dans l’itération
    • pas de challenges trop élevés
12. Parfois il faut plonger pour mieux réussir
    • quand on a compris, on ne fait plus appel à l’aide
    • on ne peut pas forcer les gens à écouter
    • phase de dégradation après la mise en place mais on remonte toujours, elle est plus ou moins longue, c’est plus facile à expliquer après cette phase

// Une interface doit être facile à bien utiliser et difficile à mal utiliser.

// Faites attention à ce que vous demandez, vous risquez de l’obtenir

• pas de mesure de vélocité car sinon rapidité au lieu de la qualité
• nombre d’indicateurs le plus limité possible (=1), ils doivent permettre de prendre une décision (=indicateur actionnable)

Conférence présentée par Simon Jaillais et Aurélien Morvant ayant pour but de nous montrer des ateliers pour accompagner les gens dans le changement.

Fonctionnement

Pour commencer, ils nous ont présenté le fonctionnement des ateliers. Voici quelques idées à retenir pour une bonne organisation :

Innovation game

• commencer et terminer à l’heure
• respecter celui qui parle
• une conversation à la fois
• l’opinion de chacun compte

Pratique des 7P

Peu d’espoir quand on est dans l’improvisation, un bon atelier demande 70% de préparation.

• Product : qu’est-ce que j’attend à la fin de l’atelier ?
• Purpose : quels sont les objectifs ?
• People : qui va participer (rôles, préparation, déléguer – time keeper, scribe) ?
• Practices : quelles sont les pratiques ?
• Preparation : préparations (post-it, vidéoprojecteur…)
• Process : que doit-on mettre en œuvre ?
• Pitfalls : quels sont les risques associés (distances géographiques des participants) ?

Ensuite, Simon et Aurélien ont proposé aux participants de choisir un atelier parmi ceux proposés. Pour l’atelier sélectionné, ils nous ont proposé un déroulé composé d’un certain nombre de pratiques collaboratives. Voici deux ateliers choisis.

Résolutions des problèmes par la créativité

Ice breaker : alphabet des concepts

• une question à poser au groupe et chacun répond avec un mot correspondant à une lettre en donnant la définition de ce mot
• phase de réflexion individuelle avant celle de réflexion en groupe
• prendre la température du groupe

Techniques de créativité

• Purge : sortir toutes les idées sur un post-it ou sur des grandes feuilles avec des dessins
• Analogies : donner des contextes pour lesquels on peut rencontrer le même problème (=phase de projection). Pour chaque environnement, ramener à notre contexte (=phase de convergence)

QQOQCP : plan d’actions

• Quoi ? Qui ? Où ? Quand ? Comment ? Pourquoi ?
• caractériser les actions avec les questions / réponses
• une action (=ce que je peux faire) non portée = une discussion
• chaque personne qui ressort à une action

Cohésion d’équipe

L’arbre à personnages (=15 min)

• plusieurs personnages dans un arbre situés à des hauteurs différentes, dans des diverses positions (de dos, seul, par groupe, en train de sourire, de tomber…)
• chaque personne cherche sa position dans l’arbre
• chacun vient se positionner sur l’arbre (gommettes) et explique pourquoi devant le groupe
• caractériser l’état d’esprit pour l’animation
• /!\ poser une question avant d’utiliser l’arbre

La crevasse (=30 min)

• jeu en binôme, les personnes s’appuient sur les mains de l’autre en face à face (pour faire un pont) et on doit avancer le long de deux lignes droites
• l’un sans l’autre c’est difficile de travailler
• confiance aille dans les deux sens

Conclusion

La co-construction + cohésion est une motivation pour les équipes. Les pratiques collaboratives apportent beaucoup de valeurs, sont des bons moyens de polliniser et restent des moments privilégiés.

Antoine Vernois a commencé la journée par une présentation nommée « Software Craftsmanship », une session sur le développement mais le développement bien fait et sur le mouvement de l’artisanat logiciel. Cette même conférence a été filmée lors de l’agile tour de Montpellier en 2013.

Antoine se définit comme un artisan développeur, une notion très intéressante au sein de laquelle la qualité n’est pas une option.

Antoine aborde ensuite la métaphore de la dette technique, qui par analogie explique que si on ne fait pas bien les choses dès le début on prend plus de temps par la suite (comparable aux intérêts en finance) et que si ce point n’est pas corrigé rapidement on se retrouve très vite à ne payer que des intérêts ou à un figement de l’application pour éviter de payer ces intérêts. Cette analogie est un concept bien connu dans notre service. D’ailleurs, nous essayons de nous améliorer en permanence afin de ne pas être prisonnier de cette dette technique.

Antoine a ensuite évoqué le principe de Peter et le fait que cela n’est pas immuable. Il n’appartient qu’à nous d’éviter ce principe mauvais pour les entreprises.

Il a également parlé du fait que les artisans choisissent eux même leurs outils selon le contexte, et du fait qu’il faut investir un peu de temps chaque jour pour accélérer le quotidien en automatisant les tâches automatisables. Le retour sur investissement est alors rapide.

Antoine a aussi évoqué un auteur et développeur américain Robert C. Martin, co-auteur du fameux Manifeste Agile. Voyant que certains interprété le Manifeste Agile de manière inexacte (« geule de bois agile »), il l’a étendu en créant le manifeste pour l’artisanat logiciel, ou « Manifesto for Software Craftsmanship ». Il a aussi publié des livres comme Clean code, au sein desquels il dit que « le seul moyen d’aller vite, c’est de faire bien », encore une fois la qualité n’est pas une option et ne peut pas en être une.

Antoine considère qu’il faut faire un code propre notamment pour les personnes qui passeront après nous sur les projets, cette notion me semble plus qu’indiqué lorsque l’on travaille de façon agile en équipe.

Il nous indique aussi que pour lui un développeur n’est pas juste une personne qui écrit du code, cela n’est pas le premier objectif de notre métier. L’objectif de notre métier et de créer des applications et pour cela nous écrivons du code mais si demain nous pouvons réaliser une application sans écrire du code il y a de forte chance que les développeurs n’écrivent plus de code.

Il a également repris différents points du manifeste agile pour les expliquer comme notamment les relations entre les individus et le partage de connaissance avec des rencontres entre professionnels et/ou passionnés autour d’évènement comme le Printemps agile 2015. Ceci dans le but de progresser ensemble en partageant les bonnes pratiques et les expériences de chacun.

Enfin, Il invite les développeurs à choisir leurs outils de travail et leur plan de carrière. Ils doivent être les plus à même de pouvoir le faire. Si ce n’est pas le cas, Antoine invitent clairement à regarder ailleurs, « changer de boîte ». En effet, dans notre domaine il y a des postes à pourvoir.

Antoine s’appuie sur des citations bien trouvées comme « la différence entre la théorie et la pratique, c’est qu’en théorie il n’y en a pas ». Il relativise la théorie et explique ainsi que les personnes ayant de l’expérience, terrain j’entends, sont plus à même de prendre des décisions dans la conception d’un logiciel qu’une personne qui écrit la théorie (« architecte logiciel »).

Il promeut le simple au lieu du complexe qui n’apporte rien, pour Antoine un professionnel fait simple.

Par la suite, il explique aussi que dans notre métier on ne s’entraîne plus, au sens où lorsque l’on code il y a toujours un but de production derrière, il pense que cela est négatif pour notre « art » dans le sens où on ne se donne jamais le droit à l’échec sans conséquence (financière, …).

Il termine sa présentation par expliquer que si l’on veut changer de boite par ce qu’il y a du code pourri dans celle où on se trouve et bien ce n’est pas une bonne raison car il y a du code « pourri » partout et c’est comme ça. Mais il ne faut pas avoir peur du code pourri car il fonctionne déjà mal donc on peut se permettre de rentrer dedans on ne fera sûrement pas pire. Ce code pourri a un potentiel énorme d’amélioration et est le lieu propice à l’expérimentation.

Ainsi se termine la présentation d’Antoine Vernois, très instructive et ça fait du bien de voir des personnes passionnées par ce métier et le goût du travail bien fait.