Traiter la dette technique en partageant les impacts - Scrum Life 25

🎁 Le guide du Scrum Master compétent 👉 sl.run/8ThoYc
Comment gérer et résorber la dette technique ? Je vous propose de la partager avec le Product Owner afin qu'il la priorise ! Mais comment faire pour qu'il y comprenne quelque chose ?
💜️ La communauté Scrum Life 👉 sl.run/GFo5bV
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
- Scrum Life 4 à propos du Definition of Done : • Le Definition of Done ...
- Scrum Life 19 à propos de la vélocité : • Comment bien utiliser ...
- Scrum Life 23 qui pose la question "Que faire lorsque les développeurs ne sont pas motivés ?" : • Que faire lorsque les ...
Et pour aller plus loin sur la visualisation de la dette technique :
- Un de mes articles qui donne plusieurs exemples de management visuel pour recenser et visualiser la dette technique : jp-lambert.me/...
- Un article de Constantin Guay qui donne d'autres pistes pour visualiser la dette technique : const.fr/blog/...
----------
CREDITS
Crédit photo de couverture : Olga DeLawrence sur Unsplash unsplash.com/p...

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/PV4b2T

[@portoyosh]

Arff ! J'étais passé à côté de cet excellent scrum life ! Bon pour faire simple, il y a un concept inventé par les SRE de Google qui est celui de budget d'erreur. Pour faire simple, on fait un rapport entre la vélocité et le nombre de nouveaux bugs introduits et on obtient un taux de fiabilité des nouveaux développements (je schématise grandement, mais dans l'idée c'est ça). Ce taux devient alors un indicateur qui peut être utilisé pour définir un contrat entre le business et la dev team: tant que le taux est au dessus d'un certain seuil, on continue les innovations, s'il est en dessous, on résorbe la dette technique. C'est un outils qui peut être très puissant sur des produits d'âges variés (bon pour les produits où la dette technique est vraiment trop importante ce n'est pas forcément la méthode la plus adaptée, mais elle permet au moins de se rendre compte de la situation)

[@Videovorace]

Ça tiens compte de la criticité du bug ? Bloquant, Majeur, Mineur...

[@portoyosh]

@@Videovorace ça peut, il suffit simplement de pondérer le résultat en fonction de la criticité du bug.

[@oniyonkuru]

Ce Scrum Life est super cool. Perso j'ai vécu cette situation où j'avais une dette technique colossale et des end users qui me foutaient une pression de ouf pour livrer leurs features au plus vite. Dans l'équipe il y avait 3 écoles: 1/ La première qui voulait d'abord qu'on réduise la dette en faisant des refacto et en nettoyant le code (réduire ou supprimer des grosses dépendances inutiles entre composants, des bouts de code inutilisables, etc.) 2/ La deuxième qui voulait qu'on consacre à chaque Sprint 20 à 30% du temps pour réduire notre dette 3/ La troisième qui voulait une refonte complète vu que le produit était et est toujours une bonne vieille merde avec des plantages réguliers qui des fois provoquent des arrêts de service de plus de 45 min (il y a plus de 1000 personnes qui utilisent quand même le produit chaque jour) J'étais plutôt partisan de la 2ème école car il m'était difficile d'aller expliquer aux stakeholders qu'il faudra qu'ils attendent 1 mois et demi sans rien leur livrer afin de m'occuper de la dette (j'ai expliqué aux stakeholders l'impact de la dette sur le business comme par ex des traitements qui prennent actuellement 2 jours dont une partie est manuelle, et qu'on pourrait automatiser pour que le tout prenne 30mn mais ils ne voulaient rien entendre) Si c'était vous, comment vous auriez procédé? D'autres commentaires sont bien entendu les bienvenus!

[@paubree1]

Très bien! merci JP! Sinon, il faut bien séparer les bugs (crash, blocage...) de la dette ( on avance moins vite) et des "anomalies fonctionnelles" qui sont en fait des découvertes fonctionnelles : "tiens ca marche pas comme j'aimerais (maintenant) que ca marche..." (montrer au client le produit, il saura ce qu'il veut...). Ca évite aussi de dire que seuls les devs travaillent mal... A l'inverse, le boulot du dev est de traiter sa dette au fil de l'eau (boyscout campfire rule). Ca évite de trop se prendre la tête avec le PO (ma technique classique). Dans ce cas, BIEN inclure la qualité dans les estimations... "Trop cher avec la qualité.. Essaye sans!" Et sinon, (dé)montrer l'impact business (100% avec JP). Continue JP!

[@AlexandreGucia]

Je découvre cette chaîne, c'est une pépite ! Je rejoins le propos de la vidéo, où très souvent les problèmes sur un projet sont d'ordre humain plutôt que technique. Sur un projet, le rôle de l'architecte (ou un lead tech/dev) est d'expliquer aux non-techniques les impacts de la dette. Pas qu'au manager, mais également au client. On se doit d'appuyer sur la valeur qu'apportera la refacto : gain de productivité, amélioration de la sécurité, amélioration des perfs, ... Traiter la dette c'est bien, la prévenir c'est mieux ! Je trouve crucial de sensibiliser les développeurs à la qualité de code via le pair programming et la revue par exemple. Faire preuve de pédagogie paie toujours :)

[@kevinrenson1710]

La DEV team est très transparente et en parle volontiers avec le P.O. En tant que Scrum Master, j'essaie que cette dette apparaisse dans le product backlog et même de la traduire en user story afin de que le message/l'idée passe mieux en review auprès des sponsors. Le tout est répercuté, tout comme les bugs, dans le burnup de release.

[@damienlebris7119]

Merci pour la vidéo. Toujours aussi sympa. Pour la gestion de la dette technique, j'ai tendance à la mettre en visibilité de l'ensemble de l'équipe (PO compris) sur un MOSCOW dissocié ou récemment dans le backlog produit par la dev team. Si un sprint se déroule bien, on pioche dans la dette technique en fonction des priorités du MOSCOW. Sinon, on lie des features (US) avec la dette et on pousse la qualité en traitant les US avec leur dette technique à venir. Ainsi, on ne touche pas ce qui fonctionne mais qui n'est pas top , et on refactor au moment où le risque se présente. L'US comprend dans son estimation le refactor de la dette idéalement. La qualité est non négociable sur les projets qui sont des succès pour mes retours d'expérience. +1000 pour la communication PO / Devteam dans les 2 sens pour des livrables qui ont de la valeur business. Attention, trop de bug peu nuire au business. Le PO a sa part de responsabilité dans la qualité de son produit.

[@MrAsteba]

Mon vécu dans plusieurs entreprises, c'est que 0% du temps de l'itération est dédié à la dette technique. Particulièrement quand le PO n'est pas un ancien développeur.

[@GuillaumeBertrand1984]

De mon côté, l'équipe gérait la dette jusqu'à il n'y a pas si longtemps en sous-marin, quand ils avaient le temps, c'est-à-dire jamais. Pour résoudre ça, on a commencé par re-créer une liste d'US "techniques" qu'on a inséré dans le backlog produit. Elles étaient priorisées par la Dev Team, puis expliquées au produit. Les POs ont eu du mal à accepter de voir autant d'US techniques apparaître dans le backlog, puis dans le backlog de sprint, surtout qu'elles sont clairement tagguées "Tâches techniques" dans Jira.. Du coup, la prochaine étape, c'est que je vais proposer de supprimer ce tag pour travailler sur l'aspect psychologique négatif, et je vais proposer aux POs de bosser sur la Business Value de ces US au même titre que les US fonctionnelles. A voir donc !

[@simonnowak9782]

Mode troll on: on refile la TMA a un concurrent qui se chargera de la dette

[@TheGragol]

Très intéressante cette vidéo, merci.

[@sbertho82]

Vidéo très intéressante et amusant le "déjà z'abonnés" à la fin.

[@ScrumLife]

Ah ah ! Ce n'est pas bien de se moquer ! 😁

Avec ma nouvelle mission dans les coulisses de la structure pour d'autre aspect de l'IT, j'attire l'attention que la dette ne se trouve pas que dans le code mais aussi dans les outils, les pratiques les procédures (délaissés parce ceux ont mal lu le manifeste)

[@ScrumLife]

Bien vu ! Il y a aussi la dette organisationnelle. Quelle est la pire dette que tu aies vu ou connu ? -- JP

@@ScrumLife les phrases "on a toujours fait comme ça" ou "oui mais tu sais bien ici". ( Ce ne sont pas des dettes mais des indices )

​@@ScrumLife Je me souviens d'avoir rejoint une équipe de développement web de 30 devs d'un grand compte. Qui codait en prod.... Et de temps en temps un se levait et disait "j'ai modifié des scripts en prod, resynchronisez vous"... Le pire c'est qu'ils utilisaient svn (git n'existait pas encore) pour "faire un backup de leur code. Quand tu arrives comme petit nouveau que tu utilises du versionning depuis 5 ans et que tu dois dire à une bande de senior de la boîte "euh age de pierre ?"

[@adritinerance]

À largement diffuser, la conclusion est top ! Merci pour l'impact ;)

[@spip931]

Bonjour, Je perçois 2 types de dettes techniques : - la première c'est celle qui est inévitable et inhérente à n'importe quel logiciel, n'importe quelle application. Autrement dit, quel que soit le logiciel, l'application, il y a des bugs et donc de la dette technique. - La seconde c'est celle que "peut" générer une équipe scrum (ce n'est évidemment ni une obligation, ni une fatalité) à un moment ou à un autre pour livrer les fonctionnalités prévues lors du sprint en rognant sur la qualité, sur les tests en se disant qu'elle la règlera plus tard, quand on aura plus de temps pour la traiter Partant de ce constat-là comment fait-on pour que : - la dette technique inhérente a chaque logiciel et chaque application plus - celle parfois générée lorsqu'on rogne sur la qualité sur les tests pour pouvoir livrer dans les temps comment fait-on pour que ces 2 types de dettes techniques soit les plus petites possibles de façon à ce que leur accumulation puisse être (facilement) gérée plus tard ?

[@ScrumLife]

Merci pour ce feedback "quel que soit le logiciel, l'application, il y a des bugs" => la notion de dette inévitable est réelle, néanmoins je ne la mettrais pas sur "les bugs". Les bugs dans un logiciel ne sont pas une fatalité ! :) Il existe des approches et méthodes pour que les bugs n'existent pas ou alors qu'on les détecte très très tôt (dans les quelques minutes maximum). Une équipe agile se doit de se former et de se contraindre à trouver les pratiques qui lui permettent de ne pas générer de bugs. Est-ce que tu en connais ? Aussi sur ta seconde proposition, sur la notion de rogner sur la qualité pour livrer, c'est assez dangereux et à mon avis ne peut être acceptable que si l'équipe est REELLEMENT autonome sur ses sujets et qu'elle arrive à avoir un process pour que cette dette ne s'empile pas. C'est à dire, qu'elle est remboursée dans les quelques jours qui suivent AU MAXIMUM. Le process de l'équipe doit alors lui permettre de s'assurer qu'elle ne peut plus rien faire tant que la dette n'est pas remboursée. -- Constantin

[@fun3000able]

Plusieurs axes de résolution sur le plan technique 1) petites modifications : gestion au fil de l'eau de l'itération et bonne pratiques. 2) bug : hiérarchisation des bugs 1 à 4 : traitement des bugs de gravité 3 et 4 sur des actions dédiées, traitement des 1 et 2 dans le cadre de 1) si les features traitées y font référence. L'intégration continue et le sérieux des développeurs doit avoir réduit ce risque. 3) code historique pourri : introduction de patterns de conception qui réduisent les dépendances entre les modules i.e "interface" et réalisation de code vraiment objet. Cela nécessite souvent une formation des développeurs légers qui utilisent un framework objet sans comprendre le paradigme objet. les rôles et interfaces doivent être clairement visualisés par l'équipe. sur un plan sponsor: explications en terme de Menace/Opportunité et donc de bénéfice à mener des actions de fond surtout dans le cas 3) précédent.

[@fun3000able]

on est d'accord !

[@agilidee2600]

Je le fais sans en parler. Si tu demandes la permission de bien faire, la réponse sera toujours la même... Non.

[@cog_g]

Agilidée c’est un peu dommage. Ça va , à mon avis, à l’encontre de la transparence, cela crée une défiance vis à vis de l’équipe si le PO s’en rends compte. Et de plus, je pense que ça crée une fracture au niveau de l’équipe Scrum. Il y a « les devs », qui sont plus malins et plus sages, qui savent que la dette doit être résorbée. Et il y a le PO, qui ne comprends rien (vu qu’on lui cache la vérité je serais tenté de dire). En tout cas, c’est ainsi que cela peut se ressentir.

[@hananazer8175]

ز

[@GuillaumeBertrand1984]

De mon côté, l'équipe gérait la dette jusqu'à il n'y a pas si longtemps en sous-marin, quand ils avaient le temps, c'est-à-dire jamais. Pour résoudre ça, on a commencé par re-créer une liste d'US "techniques" qu'on a inséré dans le backlog produit. Elles étaient priorisées par la Dev Team, puis expliquées au produit. Les POs ont eu du mal à accepter de voir autant d'US techniques apparaître dans le backlog, puis dans le backlog de sprint, surtout qu'elles sont clairement tagguées "Tâches techniques" dans Jira.. Du coup, la prochaine étape, c'est que je vais proposer de supprimer ce tag pour travailler sur l'aspect psychologique négatif, et je vais proposer aux POs de bosser sur la Business Value de ces US au même titre que les US fonctionnelles. A voir donc !