fbpx

Au coeur de l’agile : l’amélioration continue – 3 – Comment s’améliorer – Le Design et la dette technique

Dans ce post, nous continuons (et finissons cette fois) d’aborder quelques notions sur l’amélioration continue en Agile. Ce que vous allez voir va certainement vous intéresser! (sinon, allez vous amuser ailleurs au lieu de lire sur l’agilité, cela peut être payant! 🙂 ). Nous parlons, dramatiquement et sarcastiquement de deux sujets en 1 : Le design et la dette technique.

le design et la dette technique

Partant du fait que le travail est fini lorsque le prochain intervenant le confirme, ce que nous voulons avoir, c’est une série de “passage de taches” entre les différents intervenants sans délai. Nous ne voulons pas que le travail soit empilé entre les intervenants, la raison est que le travail empilé peut cacher des défauts.

le fruit logiciel pourri

Rewind maintenant.. comment ceci est il arrivé? En fait, c’est pas tout a fait pareil avec la pourriture du fruit que le logiciel pourrit. D’ailleurs, la complexité de la création du fruit est tout simplement incomparable avec le développement logiciel, mais anyways.. En logiciel, l’affaire s’est plutôt passée a l’inverse .. :

le logiciel en etapes

il y’a une décision a prendre a ce moment précis. régler le problème, ou continuer a bâtir par dessus. c’est la décision de qui? généralement, nous, spécialistes du développement logiciel, nous allons poser la question aux gestionnaires (parce que ce sont eux les experts en logiciel etonnement ..) : “voulez vous qu’on laisse les défauts dans ce que nous venons de builder?” !

le resultat du fruit logiciel

Dans un système ou les défauts sont empilés et non corrigés tout de suite, nous allons construire dessus, et nous allons livrer avec ces défauts. Plus encore, nous allons re-construire sur ce logiciel et re-livrer et re-livrer. Nous livrons ainsi un logiciel défaillant, et à ce stade, il devient presque impossible de fixer ces défauts.

Les défauts dont je parle ne sont pas le genre de défaut simple que nous pouvons détecter avec un test automatisé, mais plutôt des défauts de conception logicielle, des défauts de violation de principes de design fondamentaux qui dictent vraiment si la productivité est descendante ou ascendante.

Si nous construisons sur des défauts comme si ils étaient les fondations de notre travail dans le futur, nous pouvons alors nous attendre que les fondations de notre travail sont défaillantes!

la dette technique

le deuxième phénomène (oui je l’appelle ainsi..) qui arrive dans ce genre de situation, c’est celui ci :

discussion dette technique

la dette a un nom

solution marge securite

Alors voici ce qu’est la marge de sécurité

marge de securite

le gestionnaire est conscient de la marge

lequipe travaille dans la marge

En conclusion

conclusion amelioration

Anis Berejeb

Anis est avant tout un passioné de l'agilité et du développement. Avec plus de 15 ans dans le domaine du développement web, son expertise combine des connaissances accrues dans l'ensemble des notions partant du développement logiciel jusqu'à l'organisation des équipes dans les environnements agiles à grande échelle.

You may also like...