{"partition": "head_middle", "source_domain": "www.agilex.fr", "digest": "sha1:FYYIYQQBDLSWLJS7GOHGRHCI645IJ66H", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00018.parquet"}
Agilex : Agilité et Expertise
Agile, Lean, Scrum et informations diverses
Jeu : Casino Game
Jeu : Au Tableau
Jeu : The Big Payoff
FORMATIONS NOUVELLES
Plus d informations sur la page Agenda des Formations Le KANBAN pour réduire la dette technique	Posté le décembre 14th, 2009
Alexandre Boutin
Le sujet de la dette technique est vaste et a même suscité l’écriture de quelques très bons livres comme celui de Michael Feathers « Working effectively with legacy Code » qui explique comment travailler par petites étapes et surtout la nécessité d’arrêter d’augmenter systématiquement cette dette (« Stop Digging! »).
Bien souvent les équipes de réalisation sont conscientes de cette dette mais ont un réel problème pour trouver du temps pour s’en occuper. Les Technical Story spécifiques sont bien souvent repoussées dans le bas du Product Backlog par le Product Owner et l’ajout de quelques items de qualité de code dans le TERMINE (DONE) est une bonne pratique mais bien souvent insuffisante pour s’attaquer réellement à cette dette.
Alors comment faire ?
Un de mes clients a trouvé une solution sans la chercher et tout cela grâce au Kanban.
L’objectif initial de ma mission était d’améliorer le fonctionnement de l’équipe de réalisation et ses interactions avec les équipes produit. Plutôt que de mettre en place Scrum et ses cérémonies que je ne trouvais pas vraiment adapté au contexte de ce client et à son fonctionnement, j’ai préféré conseiller l’approche lean et la mise en place d’un kanban comme outil de management visuel du cycle de vie des fonctionnalités.
Depuis quelques semaines ce Kanban est en place avec une colonne par étape et les limitations de WIP (Work In Progress) bien visibles. Cet outil a fait clairement apparaître un goulot d’étranglement (« Bottleneck ») au niveau de la validation fonctionnelles des exigences (~UAT) qui est en cours de traitement, et donc les tâches en amonts ont une tendance à s’entasser devant ce goulot. L’effet induit pour l’équipe technique est qu’il n’y a plus de place vide sur le Kanban (WIP) pour démarrer les réalisations et donc, d’une certaine façon, qu’elle n’a rien à faire !
Cette opportunité a immédiatemment été utilisé par l’équipe pour s’attaquer à la dette technique (une forme de 5S), ce qui leur permet de passer du temps sur cette activité tout en sachant que cela ne pénalise pas la productivité totale puisque, par définition, la vitesse du flux de sortie est subordonnée par le goulot, donc tant que le goulot est alimenté en permanence le système est à son maximum de vitesse.
Et vous, comment trouvez vous du temps pour réduire votre dette technique ?
Dette technique, Kanban, Lean	3 réponses à “Le KANBAN pour réduire la dette technique”
14 décembre 2009 à 11:54
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.
Rémy Sanlaville
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 Yann Picard de Muller
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 Laisser une réponse
Adresse de messagerie (ne sera pas publiée) (obligatoire)
01 informatique
Agile France
Agile Grenoble
Au tableau
Définition Produit Agile
Ensimag
goulot
Innovation Games
Jeu Agile
Jeux agiles
management visuel
Produit Agile
Velocité
YahooWP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.
Les blogs que je lis
Stéphane Bigeard
Fermer l’aperçu
Yann POLES
Emilie Chabbouh
Jean-Pierre Bonnafous
Christophe ADDINQUY
Alfred Almendra
Arpinum
Oana Juncu
JC Grosjean
Fabrice Aimetti
Antoine Vernois
Ca Scrum !
Institut Agile
Luc Jeanniard
Cyrille Deruel
Laurent Morisseau
Touilleur Express
Mathieu CANS
lean machine square
ScrumBan
Belgium Blog
Yann PicardDeMuller
Thierry CROS
Denis DOLLFUS
Bruno ORSIER
Emmanuel ETASSE
Laurent Tardif
Pascal Van Cauwenberghe
Emmanuel GAILLOT
Emmanuel HUGONNET
Emmanuel CHENU
Lean Software Engineering
Claude AUBRY
Pascal BORGHINO
Commentaires récents	David Koss: Bonjour Alexandre, Merci pour cet article dans lequel je me reconnais tout à fait en tant que PO chez un...
stephane bigeard: Merci pour ce bel article et la mises évidence dans ton univers métier de l’utilisation des...
Alexandre Boutin: Bonjour Votre interrogation est tout à fait naturelle, et d’un autre coté, si la situation...
Guillaume PRECHEUR: Bonjour, merci pour l’article. Le fait de recentrer la rétro sur les individus ne...
Rémy: Merci ! Excellente idée de faire ce focus. Je ne l’utilise pas assez en rétro. Je vais me repencher sur...
CARA (21)
Conférence (95)
Enseignement (7)
Etude (36)
Formation Agile (1)
Jeu Agile (34)
Lean (24)
Commentaires (RSS)
Conçu avec WordPress
Créé par My Mobiles