Agile Tour Lille 2015 (Partie 2/2)

Retour sur la 1ère partie…

Suite de l’article : Agile Tour Lille 2015, partie 2

Pour rappel, voici les conférences que j’ai suivies cette année :

  1. Des lean startups dans l’administration !? – par Pierre Pezziardi
  2. Si le TDD est mort, alors pratiquons une autopsie – Par Bruno Boucard et Thomas Pierrain
  3. Construire plus vite en apprenant plus vite – Retour d’expérience du Monde.fr – Par Ismaël Héry
  4. Ratez vos revues de code en 5 leçons ! – Par Michel Domenjoud
  5. L’estimation, un formidable outil de discussion, même pour les projets #NoEstimates – Par Sébastien Delest
  6. Le Kanban expliqué par Bison futé – Par Cyrille Deruel
  7. Alliés contre les défauts – pourquoi et comment nous relisons ensemble le code que nous produisons – Par Julien Jakubowski et Antoine Blancke
  8. Intégration continue, DevOps et après ? – Par Laurent Tardif

5. L’estimation, un formidable outil de discussion, même pour les projets #NoEstimates – Par Sébastien Delest

Sebastien Delest est venu nous présenter le mouvement #NoEstimates. Aujourd’hui, nous avons besoin d’estimer pour décider et gérer un projet, une équipe. La difficulté est qu’estimer l’imprévu peut s’avérer.. complexe. On utilise généralement le coté reproductible des choses pour avoir une idée du temps nécessaire. Seulement on ne fait pas tout le temps la même chose, qui plus est dans le même contexte. Par ailleurs on a souvent tendance à être trop optimiste.

Sébastien nous propose donc d’éviter l’estimation, ou au moins de minimiser son importance. Pour cela il nous propose quelques alternatives :

  • On ne peut se fier à une estimation pour des décisions importantes. Il vaut mieux prendre des décisions mineures et pouvoir changer d’orientation, s’adapter.
  • Il faut garder le point de vue sur la vision, l’objectif est d’utiliser le maximum de feedbacks sur des cycles courts pour prioriser les besoins.
  • Engager moins d’argent et donc moins de temps, en faisant un point d’avancement chaque semaine, par exemple, pour savoir si on continue ou si on prend la bonne direction.

Toutefois, l’estimation a également des vertus : elle permet par exemple via le planning poker de discuter du besoin et de partager la vision de celui-ci. Et donc de mieux le comprendre et soulever les premières inconnues. Il en est de même pour la rédaction des User Stories et des Scénarios BDD qui permettent de décomposer le besoin et encore une fois d’avoir une meilleure vision des détails. Sur ces points, l’orateur insiste sur l’intérêt d’avoir des interlocuteurs variés afin d’augmenter les points de vue et d’enrichir les échanges.

On peut également se poser la question de la valeur ajoutée d’une demande. Générerait-elle plus de chiffre ? Est-ce nécessaire pour améliorer la maintenabilité et donc mieux supporter les évolutions à venir ou simplement la qualité du support ? Pour cela, on peut utiliser une Story-map qui permet de prioriser les fonctionnalités par valeur ajoutée et/ou effort nécessaire.

Comme toujours il n’y a pas de solution miracle, mais des bonnes pratiques peuvent limiter les impacts. Ainsi si un client change d’avis et souhaite revenir en arrière, faire des cycles courts et avoir un retour au plus vite permet de réduire les pertes. De même, dans le cas d’engagement au forfait, il vaut mieux privilégier la confiance et s’engager sur l’effort plutôt que sur le contenu.

Dans tous les cas, le travail d’estimation doit être pris comme une opportunité d’échanges sur le besoin et les priorités plutôt que comme une simple opération comptable.

6. Le Kanban expliqué par Bison futé – Par Cyrille Deruel

Voilà une présentation très dynamique et diablement pertinente ! Cyrille est Delivery Manager chez Octo, il ne travaille aucunement pour bison futé, en revanche il a eu une soudaine conviction un jour de bouchons sur la route des vacances. Il a remarqué de nombreuse similitudes entre la gestion du trafic routier et celle ses projets informatiques. Voilà l’origine de sa présentation.

Cyrille nous propose donc d’améliorer les 5 pratiques de notre kanban en appliquant les solutions correspondantes à ce que fait Bison Futé pour mieux gérer le trafic routier.

1. Visualiser le flux de travail

Pour éviter la frustration des clients engendrée par le manque de vision des délais, on peut indiquer sur le kanban une estimation du temps restant avant la mise en production d’une fonctionnalité, comme le fait Bison Futé avec ses panneaux à affichage variable estimant le temps restant pour atteindre une destination. Ce n’est pas un engagement, on ne peut prévoir l’imprévu. Par contre on peut supposer au vu du rythme actuel que si la fonctionnalité est en phase de test par exemple, il lui reste X jours pour arriver en production.

De même on peut préciser le nombre de personnes travaillant actuellement sur tel ou tel pan applicatif. Ainsi on a conscience qu’un sujet dans un domaine avancera plus ou moins vite en fonction de l’énergie actuellement allouée sur ce domaine.

2. Limiter le WIP (Work In Progress)

C’est un classique, le multi-tâches c’est le mal, et accumuler un ensemble de tâches en cours est le meilleur moyen de se noyer. C’est là qu’intervient le WIP. Pour respecter ce nombre de tâches pouvant être traitées en parallèle, on bloque ce nombre. Comme un feu rouge devant une autoroute, vous êtes ainsi certain que la route sera fluide et optimale. De manière plus radicale, on peut imaginer une circulation alternée. Si les Product Owners ne sont pas en mesure de prioriser les tâches, on peut les choisir aléatoirement. C’est à éviter autant que possible, mais ça débloque le problème. Un concept intéressant est également celui de la fourrière. Si chaque jour une tâche n’avance par car un élément externe est bloquant, on peut mettre cette tâche en fourrière, ne plus s’en préoccuper et ainsi libérer l’équipe d’un point sur lequel elle ne peut rien faire.

3. (Mesurer et) gérer le flux

Concernant le trafic routier, il y a plusieurs options : on peut réserver une voie au taxi pour qu’il puisse aller plus vite en cas de bouchon, ponctuellement utiliser une voie d’arrêt d’urgence pour augmenter le flux ou encore limiter la vitesse globale pour augmenter la vitesse de croisière. (Réduire la vitesse de 10km/h sur le périphérique parisien à augmenté de 18% la vitesse moyenne !)

Pour notre kanban, comme pour le reste d’ailleurs, le meilleur moyen de décider est d’abord de mesurer. Il faut régulièrement s’adapter et expérimenter. Tester une nouvelle manière de gérer, et si au bout d’un mois le résultat n’est pas concluant, on refait comme avant. Par ailleurs, en période de congés, quand une partie de l’équipe est absente, on absorbe forcément moins d’activité que si tout le monde était présent.

4. Rendre explicites les règles des processus

Il est essentiel de définir les règles à suivre, de réaliser des checklists pour vérifier que l’on s’y tienne et de les adapter au fil du temps et notamment de l’expérience. Ainsi en cas de problème, on peut en identifier les causes et faire évoluer le process pour ne plus reproduire l’erreur. La checklist permet d’éviter les habitudes qui trop vite nous font oublier certains points et donc reproduire des erreurs.

Ici aussi en mesurant la « quantité de problèmes »qu’on a sur les différents sujets, on est plus à même d’identifier et corriger le problème en amont.

5. S’améliorer collaborativement

Il faut dés le début avoir conscience et prendre en compte les contraintes externes. Un éco-pont a permis d’éviter des accidents avec des sangliers sur la route. Vérifier que le ciblage de nos utilisateurs est compatible avec le règlement de la CNIL évite de s’en rendre compte une fois en production. Il faut aussi, comme le télépéage, automatiser tout ce qui peut l’être, comme le déploiement sur un environnement de tests, par exemple.

Cyrille ajoute à cela l’importance d’avoir une bonne salle de pause et des événements en dehors du travail. Cela améliore la qualité des échanges et simplifie la communication.

Il faut aussi prendre conscience que le changement peut prendre du temps : 40 ans après le lancement de la ceinture de sécurité, 21% des tués dans les accidents de la route ne la portaient pas…

Je vous invite à parcourir les slides qui sont assez évocateurs :

 

 

7. Alliés contre les défauts – pourquoi et comment nous relisons ensemble le code que nous produisons ? – Par Julien Jakubowski et Antoine Blancke

Voila une nouvelle présentation sur la revue de code, plutôt orientée sur le retour d’expérience des équipes au Web Center d’Axa.

Julien et Antoine commencent par nous expliquer qu’au début, la revue de code était plutôt faite par un expert dans l’équipe et parfois en pair-programming. Cependant le résultat était peu concluant car le retour d’expérience était peu diffusé et l’expert avait trop de code à relire. Ils ont donc opté pour une revue de code faite par l’ensemble de l’équipe. De premier abord, cela semble particulièrement coûteux, à raison de 3 réunion d’une heure par semaine pour tout le monde d’un coup. Dans les faits, le coût est de 5% du budget de développement du projet.

Il y a deux choses qui permettent d’accepter ce coût :

  • La première est d’optimiser au maximum l’efficacité de la revue de code. Pour cela, il ont établi des rôles qu’il est impératif de respecter : un time-keeper, un modérateur, un scribe, 3 lecteurs et bien sur l’auteur initial du code qui explique ce qu’il a produit. Chaque rôle permet d’équilibrer la réunion et de s’assurer de son efficacité.
  • La deuxième chose est de relativiser ce coût par rapport au autre coût d’un projet. Des statistiques donnent un R.O.I de 4 pour 1 (4h de debug pour 1h de revue) avec un budget dédié à la correction de bugs au départ de 43% du budget du projet. Pour finalement descendre à 5% du budget lorsque la revue de code est utilisée.

D’autres avantages de la revue de code sont aussi la communication autour du code, la mise en place d’une propriété collective du code qui devient donc plus facile à maintenir, et enfin la facilité d’apprentissage pour les nouveaux arrivants qui intègrent plus facilement les standards et la compréhension du projet.

S’il est difficile au début de faire des revues de code, par peur de montrer son code ou de faire des remarques peu pertinentes, ou simplement par la pression du projet. Avec du travail, notamment sur la communication : ne pas critiquer le code mais faire référence au standard, reformuler ses phrases pour ne pas accuser (tu …) mais plutôt partir d’une hypothèse (je pense que …). Et le respect des rôles (time-keeper, modérateur), la pratique de la revue de code s’avère très efficace et améliore notablement la communication, même avant les revues !

En conclusion, s’ils ne devaient garder qu’une chose sur leurs gestions de projet, ils garderaient la revue de code !

Les slides de la présentation sont disponibles ici :

 

8. Intégration continue, DevOps et après ? – Par Laurent Tardif

« Prédire » l’avenir est difficile : En 1994 par exemple, le rapport Thery ne croyait pas en l’avenir d’internet… Toutefois Laurent commence par présenter un chiffre intéressant : d’après une étude Gartner, en 2016 Devops va passer d’un marché de niche à une réelle stratégie pour 25% des entreprises. Le ton est donné.

Ensuite, il réalise un rapide état des lieux de ce qui existe : l’émergence des principes sur l’agilité, les outils d’intégration continue qui permettent déjà de rapprocher le développement des tests. Tout cela permet d’améliorer la qualité du code, sa robustesse et son processus de livraison.

Ensuite nous voyons une définition de ce qu’est DevOps – la fusion du dev, des tests, et des ops :

  • D’un point de vue technique, c’est principalement de l’automatisation, des processus de tests, de la livraison, etc.
  • D’un point de vue du business, c’est une approche qui croit en l’expérimentation, à l’échec rapide, au produit viable minimal et une décision prise sur des chiffres.

Puis on passe en revue rapidement pléthore de domaines couverts par devops ainsi que les principaux outils associés :

On constate à nouveau qu’il est très important de mesurer, via du monitoring, la gestion du feedback utilisateur. C’est là clé pour prendre les bonnes décisions.

Puis Laurent fait un rapide bilan de ce que l’on a aujourd’hui : un forte tendance vers les produits Open Source, les clouds privés et/ou publics, les technologies autour des containers (Docker) et micro-services, et enfin le machine learning, aujourd’hui avec Mahout et Spark et demain certainement avec Flint.

On apprend que les solutions de cloud privé sont en recul, notamment du fait de leur coût et leur complexité, au contraire de l’IoT et la sécurité qui sont en forte croissance. Un nouveau courant cherche à décentraliser les puissances de calcul pour les apporter jusque dans les téléphones mobiles (via des containers). Cela permettrait d’amoindrir les coûts et d’améliorer le service, par exemple en cas de coupure réseau.

Enfin comme piste de réflexion pour le buffet de clôture, Laurent imagine qu’après l’association des Devs et des Ops, la prochaine génération associera les Devs et le Marketing.

Les slides de la présentation sont disponibles ici :

Tout cela n’aurait pas eu lieu sans l’association Nord Agile et de leurs sponsors, un grand merci à eux !

Et bien sûr merci à Salto Consulting de m’avoir permis de participer à cette journée !

Par Matthieu Fernandes