Commentaires sur : Le KANBAN pour réduire la dette technique

Par : Yann Picard de Muller

Yann Picard de Muller — Tue, 29 Dec 2009 01:30:05 +0000

La chance qu’a ton client pour ce qui est de la dette technique est que la contrainte se situe hors du développement.
(En même temps rattraper du code qui n’est pas testé… soit on a une bonne suite de tests unitaires, soit ça peut faire très mal au 2e tour.)

Une solution apparament viable à long terme qui semble s’associer bien à Kanban, c’est de mettre en place une forme de taxe sur la capacité à la contrainte.

Un exemple : le code de cette story est catastrophique, la contrainte ne travaillera qu’à 66 % de sa capacité de façon à le remettre d’équerre. Un code propre n’aurait amené une réduction que de 5 ou 10 %.

Hors contrainte, la mise en ordre que tu décris est toujours appliquable

Par : Rémy Sanlaville

Rémy Sanlaville — Wed, 16 Dec 2009 10:05:32 +0000

C’est sans doute une bonne chose pour l’équipe de développement qui a trouvé un moyen pour travailler sur sa dette technique.

En même temps je suis un peu mal à l’aise avec cette idée car cela ne résout pas le problème de fond (au contraire). En effet, un des problèmes est que la dette technique reste trop au niveau de l’équipe de développement et n’est pas assez pris en compte par la MOA et les décideurs. Le fait de « cacher » ces travaux vont faire croire qu’il n’y pas besoin d’aborder ces problèmes puisqu’ils ne seront plus visibles (ce qui n’est pas très agile d’ailleurs). Que se passe-t-il si le goulot d’étranglement revient vers l’équipe de développement ?

A mon avis le vrai enjeux est d’arriver à montrer aux MOAs le coût financier que fait porter la dette technique sur le projet. Sujet difficile à mener…

Alex : La MOA est informée de la situation et une action d’amélioration vise à intégrer les actions de réductions de la dette technique au même niveau que les exigences … mais cela n’empêche pas de « profiter de la situation » pour diminuer la dette technique

Par : Cédric

Cédric — Mon, 14 Dec 2009 09:54:30 +0000

Excellent!
Appliquer une réflexion lean sur une organisation en place est payant, mais cela demande une certaine prise de recul, et il n’est pas évident de trouver les vraies sources d’amélioration sans se défaire de nos réflexes et schémas de pensée quotidiens.

Pour ma part, en fonctionnant en mode scrum, j’ai livré du code sans les tests unitaires implémentés (ce qui ne signifie pas qu’aucun test unitaire n’avait été effectué), pour les besoins d’une démo. Il a été accepté par le PO de faire cette première livraison, puis d’ajouter au backlog un NFR correspondant à la montée en compétence de l’équipe sur JUnit + codage des tests unitaires sur le code déjà implémenté.

L’approche lean nous a permis d’identifier que notre flux d’information était mal organisé : l’équipe en charge du développement, échange avec deux autres équipes, et rassemble les informations. Cela génère énormément d’échange, les deux équipes interlocutrices ne parlant pas entre elles. nous allons donc changer l’organisation de manière à créer un flux d’information à l’image d’une chaîne de montage, en forçant ces deux équipes à s’entendre avant de nous remonter les informations. Mais la politique reste un frein à ce genre de changements, comme d’habitude.