IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Agile pourrait-il conduire les organisations vers une dette technique plus importante ?

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    Juin 2016
    Messages
    3 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2016
    Messages : 3 160
    Points : 66 249
    Points
    66 249
    Par défaut Agile pourrait-il conduire les organisations vers une dette technique plus importante ?
    Agile pourrait-il conduire les organisations vers une dette technique plus importante ?
    Don Clos, développeur logiciel, pense que oui et propose une analyse détaillée de la situation

    Agile est une méthodologie largement populaire dans le développement logiciel, et Scrum et Kanban en sont deux des implémentations les plus utilisées. Toutefois, quelle est son incidence sur la dette technique ? Don Clos, responsable du développement logiciel chez Compuware, une société américaine qui édite des logiciels, a déclaré que, contrairement à ce que beaucoup croient, Agile est une approche qui permet l'accumulation de la dette technique. Dans une analyse détaillée sur le sujet, il identifie au moins cinq situations qui entraînent l'accumulation de la dette technique pour les équipes.

    Rapport entre la dette technique et la méthodologie Agile

    La dette technique (aussi connu sous le nom de dette technologique ou dette de code) décrit les résultats obtenus lorsque les équipes de développement prennent des mesures pour accélérer la livraison d'une fonctionnalité ou d'un projet qui doit être revu ultérieurement. En d'autres termes, c'est le résultat de la priorité donnée à la livraison rapide plutôt qu'au code parfait. Ainsi, lorsque les gens parlent de dette technique, ils font en fait référence aux conséquences à long terme des changements "rapides et sales" (quick-and-dirty) apportés aux programmes pour respecter les délais au lieu de coder "la meilleure conception".

    Nom : V.5-Blog-image-tech-Debt-May-14-2019.png
Affichages : 37569
Taille : 317,2 Ko

    Selon Martin Fowler, auteur et conférencier spécialisé dans le développement de logiciels, la façon dont les organisations informatiques accumulent une dette technique est comparable à la façon dont les gens accumulent une dette financière. « La dette technique entraîne des paiements d'intérêts, qui se présentent sous la forme d'un effort supplémentaire que nous devons faire dans le futur en raison du choix d'une conception rapide et sale », a-t-il déclaré. D'après Don Clos, cette affirmation est particulièrement vraie pour les équipes qui font du développement Agile.

    « Lorsque vous utilisez l'approche Agile, le rythme est plus rapide et vous fournissez les fonctionnalités dont les clients ont besoin dès que possible. Les choses doivent simplement fonctionner pour que vous puissiez continuer, et bien qu'elles doivent bien fonctionner, le travail "rapide et sale" se fait toujours et les dettes techniques s'accumulent », a expliqué Clos. Selon lui, c'est ce qui se passe avec les équipes mainframes, alors que de plus en plus d'équipes passent de la méthode Waterfall à la méthode Agile. Voici quelques défauts qu'il cite comme facteurs de l'accumulation de la dette technique.

    • des pratiques de développement et d'exploitation mal définies, y compris des raccourcis techniques pour respecter les délais des projets ;
    • manque de documentation sur la logique du code, ce qui empêche le développeur de comprendre un programme pour trouver le code à modifier ;
    • des outils de développement inadaptés pour la gestion du code source, le débogage, les normes de codage et leur application, la couverture du code et les tests ;
    • tests automatisés inexistants ou inefficaces, laissant la place à des erreurs ou à des tests négligés en raison de processus manuels.

    Par ailleurs, il est important de noter que la dette technique est une expression inventée à l'origine par le développeur de logiciels Ward Cunningham. En plus d'être l'un des 17 auteurs du Manifeste Agile, Cunningham est également reconnu pour avoir inventé le wiki. Il a d'abord utilisé cette métaphore pour expliquer aux acteurs non techniques de WyCash, un système de gestion de portefeuille, pourquoi il fallait prévoir des ressources pour la refonte. Enfin, il est bon de savoir quelles activités (ou leur absence) sont à l'origine de l'endettement technique.

    Dette technique : les origines probables selon Clos

    Selon Clos, la première étape si vous décidez de rembourser votre dette technique, c'est de déterminer l'endroit où elle se situe. Alors, comment s'y prendre ? « En fonction de la culture, des processus et des outils qui entourent votre atelier informatique, l'endroit où vous voyez la dette technique s'accumuler le plus variera, en particulier pour ceux qui passent de Waterfall à Agile. Il existe au moins cinq cas communs dans lesquels la dette technique s'accumule pour les équipes mainframes qui se lancent dans cette aventure », a expliqué Clos. Voici les points que Clos a énumérés.

    Tout d'abord, rappelons que le modèle Waterfall ou le développement en cascade est un modèle classique utilisé dans le cycle de vie du développement d'un système pour créer un système avec une approche linéaire et séquentielle. Il est appelé "cascade" parce que le modèle se développe systématiquement d'une phase à l'autre de manière descendante. Ce modèle est divisé en différentes phases et la sortie d'une phase est utilisée comme entrée de la phase suivante. Chaque phase doit être achevée avant le début de la phase suivante et il n'y a pas de chevauchement des phases.

    Héritage de Waterfall

    Selon lui, le développement en cascade vous donne le temps de planifier, de rechercher, de concevoir, de coder, de tester et de corriger les bogues avant de déployer votre nouvelle fonctionnalité. L'inconvénient est que vous ne livrez pas assez vite pour satisfaire les demandes des clients, des entreprises et du marketing. Par contre, le développement Agile peut être utilisé pour créer plus rapidement de petits éléments de fonctionnalités ciblées afin de répondre plus rapidement aux pressions de l'entreprise grâce à de nouvelles fonctionnalités. D'après Clos, c'est une bonne chose pour les entreprises et leurs clients à l'ère du numérique.

    Cependant, il estime que, si vous faites passer des applications matures de Waterfall à Agile, la dette technique est souvent héritée de vieux systèmes et de vieux codes. Par rapport aux anciens systèmes, il a déclaré que tout système qui existe depuis un certain temps a très probablement sa part de dette technique. Selon lui, plus le système est ancien, plus les développeurs, certains meilleurs codeurs que d'autres, ont probablement travaillé dessus. Le code est continuellement mis à jour et modifié, les anciennes bases de code s'agrandissent avec le temps, et cela rend la maintenance plus difficile.

    En ce qui concerne l'ancien code, Clos a déclaré que, plus l'on ajoute du code à des applications existantes, plus l'on risque d'introduire de nouvelles complexités ou de rompre la logique existante, ce qui se traduit par un plus grand nombre de défauts et une augmentation du temps de développement. Il estime que les bogues plus anciens sont généralement plus difficiles à trouver et à corriger. « Et même si les produits sont vérifiés pour leurs hautes performances avant leur sortie, la dette technique est inévitable lorsque vous évoluez rapidement », a-t-il déclaré.

    « Elle s'accumule rapidement en raison du manque de temps disponible pour remanier le code, construire un environnement d'automatisation des tests ou même écrire une bonne documentation », a-t-il ajouté.

    Documentation insuffisante

    Clos a souligné qu'il est facile d'accumuler technique liée à la documentation, car les développeurs font le plus souvent un mauvais travail à ce stade. Il explique qu'avec Agile, les systèmes changent beaucoup plus fréquemment que Waterfall. Cela signifie que la documentation doit elle aussi évoluer rapidement. Cependant, selon l'analyste, les développeurs ont tendance à documenter les changements sans tenir compte du flux global de la documentation "produit" destinée aux clients.

    Nom : Tech-Debt.png
Affichages : 8945
Taille : 10,6 Ko

    Il estime que, si l'on n'accorde pas l'attention nécessaire à la manière dont la documentation est ajoutée à un guide, l'on se retrouve rapidement avec un ensemble d'instructions gonflées et inutilisables. « Lorsque vous commencez à transformer des applications Waterfall matures en processus Agile, la dette technique dans la documentation existante est généralement évidente, les instructions sont omises, des étapes sont omises, les choses ne sont pas transmises clairement et les nouvelles mises à jour exacerbent le problème », a-t-il déclaré.

    La définition du travail à faire

    Selon Clos, la définition de l'objectif peut aussi devenir un facteur d'accumulation de la dette technique. Toutefois, il a ajouté qu'il est difficile pour une dette technique de découler d'un nouveau développement si la définition du travail à faire est strictement suivie. Ce que cela signifie, c'est que :

    • le travail de développement est achevé tel que défini dans la feuille de route et répond aux critères d'acceptation ;
    • des cas de test manuels et/ou automatisés sont ajoutés et exécutés selon les besoins ;
    • toute la documentation applicable est complétée ;
    • il n'y a aucun défaut dans le nouveau code associé à l'histoire ;
    • le propriétaire du produit a accepté les changements.

    Par ailleurs, il poursuit en disant que, dans l'approche Agile, le propriétaire du produit est responsable de déclarer qu'un cahier des charges est terminé. Cela dit, l'équipe est responsable de faire respecter la définition de "terminé". Selon Clos, lorsque la définition de "terminé" n'est pas respectée, il peut en résulter une dette technique, notamment :

    • un code inefficace ou un code qui ne satisfait pas les objectifs de l'entreprise ;
    • des tests insuffisants, qui se manifestent dans les travaux futurs ;
    • une documentation technique ou une documentation client insatisfaisante ;
    • un code bogué qui nécessitera de futurs travaux de maintenance.

    Prendre trop de travail

    D'après Clos, une dette technique peut également survenir si votre équipe mainframe prend trop de travail. Il estime que cela est particulièrement vrai pour les équipes agiles qui travaillent en sprint. Il existerait plusieurs cas où cela peut se produire, dont :

    • planification des sprints : selon Clos, lors de la planification d'un sprint, l'équipe doit être sûre de pouvoir terminer tous les points prévus pour ce sprint, sinon elle risque de se précipiter et de prendre des raccourcis pour terminer le travail, ce qui entraînera un code inefficace, des défauts et une mauvaise qualité ;
    • Timebox Agile : selon Clos, de nombreuses équipes ont du mal à dire "non" et, au cours d'un sprint, elles en prennent plus qu'elles ne peuvent en accomplir. Il a déclaré que c'est particulièrement vrai dans le cadre de la Timebox Agile, où les équipes "sprintent" vers la livraison d'un produit minimum viable à la date d'achèvement prévue du projet ;
    • travaux en cours : Clos estime que chaque membre de l'équipe doit travailler sur un point à la fois afin de minimiser les travaux en cours. Il a déclaré qu'un travail en cours trop important peut entraîner une dette technique, car les gens passent d'une tâche à l'autre au lieu de se concentrer sur l'achèvement du travail le plus prioritaire avant d'en entreprendre d'autres ;
    • la dérive du champ d'application : Clos a déclaré ici que les équipes ne doivent pas se sentir obligées d'assumer plus de travail que ce qu'elles pensent pouvoir accomplir au cours d'un sprint. Selon lui, la dérive des objectifs consiste à ajouter du travail à un sprint de longueur fixe ou à un projet limité dans le temps sans ajouter de ressources. Il a déclaré que cela entraîne souvent une dette technique.

    S'éloigner du travail d'un sprint

    En dernière position, Clos a déclaré que, dans la méthodologie Agile, les équipes Scrum doivent se consacrer au travail de sprint. Les interruptions, telles que les problèmes des clients et les temps d'arrêt des applications, ont un impact négatif et entraînent souvent un travail de sprint incomplet ou des heures supplémentaires pour les développeurs. De même, il a déclaré que les développeurs doivent se concentrer sur leur travail de sprint et ne pas s'inquiéter d'être obligés de gérer des problèmes de clients et de production. Pour lui, c'est à cela que servent les équipes de solutions clients.

    Selon lui, ces dernières sont là pour s'assurer que les clients reçoivent l'attention qu'ils méritent pendant que les développeurs produisent les fonctionnalités dont les clients ont besoin. Néanmoins, il a déclaré qu'il a un point auquel il faut faire attention. « Bien sûr, le fait de toujours se concentrer sur les nouveaux développements peut entraîner une dette technique. Il faut consacrer du temps et des ressources pour remanier et maintenir correctement le code, améliorer les tests automatisés et mettre à jour la documentation existante. Cela n'ajoute pas de nouvelles fonctionnalités, mais évite à l'équipe de ralentir et la rend plus efficace à long terme », a déclaré Clos.

    « La technologie a progressé et a fourni des fonctionnalités matérielles, logicielles et des fonctionnalités de réseau plus efficaces et plus performantes dont il peut être nécessaire de modifier le code pour en tirer parti. Plus il est facile de lire et de comprendre le code, plus il est facile de le changer et de le modifier », a-t-il ajouté.

    Conclusion

    « La dette technique n'est évidemment pas limitée aux équipes qui s'appuient sur la méthodologie Agile, et il y a de fortes chances que ces points s'appliquent à de nombreuses équipes qui se basent sur l'approche Waterfall, bien que dans une mesure différente. Quoi qu'il en soit, toutes les équipes mainframes sont aujourd'hui tenues d'aller plus vite. Qu'elles s'efforcent de devenir agiles ou qu'elles se battent pour demeurer dans l'approche Waterfall, lorsque vous allez plus vite, la dette technique s'accumule », a déclaré Don Clos en conclusion à son analyse.

    Source : Don Clos

    Et vous ?

    Que pensez-vous des différents points abordés par Don Clos ?
    Pensez-vous qu'Agile contribue à l'accumulation de la dette technique ?
    Selon vous, comment les organisations peuvent-elles payer la dette technique ?

    Voir aussi

    La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas, selon Gene Bond, directeur exécutif chez iiSM.ORG

    « Agile est un cancer », pour Erik Meijer, qui estime qu'il doit être banni une fois pour toutes

    Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile

    Comment l'Agile s'est détourné de son chemin et comment corriger cela, explique l'un des auteurs du Manifeste Agile
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    Par défaut
    Citation Envoyé par Bill Fassinou Voir le message
    Que pensez-vous des différents points abordés par Don Clos ?
    Pensez-vous qu'Agile contribue à l'accumulation de la dette technique ?
    Selon vous, comment les organisations peuvent-elles payer la dette technique ?
    perso, je déteste les méthodologies agiles, peut être déjà parce que j'ai l'impression que dans toutes les boites dans lesquelles je suis passé, elles ne prennent qu'un ou 2 points d'une méthodologie et jettent le reste.

    donc je pense que, peut être, les méthodologies agiles ne provoquent pas une aggravation de la dette technique, mais en tout cas les appliquer mal et négliger le reste, effectivement, ça n'aide en rien.

    la nécessité de livrer pour l'année dernière est sûrement beaucoup plus responsable des problèmes que l'agilité, mais comme j'ai dit, je suis mauvais public.

  3. #3
    Inactif  

    Homme Profil pro
    Ingénieur test de performance
    Inscrit en
    Décembre 2003
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur test de performance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 986
    Points : 2 605
    Points
    2 605
    Par défaut
    Bonjour.

    Le problème, ce n'est pas la méthodologie, ce sont les développeurs. Et aussi parfois les budgets.

  4. #4
    Expert confirmé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 260
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 260
    Points : 4 041
    Points
    4 041
    Par défaut
    C'est l'occasion de faire du Rust

    J'écris très peu de jeux test sauf depuis que je me suis mi au Rust car ce n'est pas très chronophage de tester quelques cas à chaque fois.

    Là où je suis passé il manquait aussi souvent un serveur SonarQube qui aide à détecter des potentiels problèmes.

  5. #5
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 553
    Points : 18 448
    Points
    18 448
    Par défaut
    Citation Envoyé par Bill Fassinou Voir le message
    En d'autres termes, c'est le résultat de la priorité donnée à la livraison rapide plutôt qu'au code parfait. Ainsi, lorsque les gens parlent de dette technique, ils font en fait référence aux conséquences à long terme des changements "rapides et sales" (quick-and-dirty) apportés aux programmes pour respecter les délais au lieu de coder "la meilleure conception".
    C'est vrai que parfois il y a des réunions fréquentes avec le client, donc c'est difficile de dire "pendant plusieurs semaines je n'aurais rien à vous présenter parce que je dois modifier une grosse partie du logiciel, afin de remettre les choses en ordre, parce qu'il a été conçu n'importe comment, allez salut, j'annule les 8 prochaines réunions on se revoit dans 2 mois".

    Parfois il y a des vieux logiciels qui ont été modifiés par plusieurs groupes de personnes, et tu te retrouves dessus à devoir faire du reverse engineering pour comprendre ce qu'il se passe.

    Quel sont les alternatives aux méthodes agiles ? (Est-ce qu'il y autre chose que cette de cycle en V ?)
    Les méthodes agiles permettent de livrer rapidement une nouvelle version au client pour qu'il puisse la tester et faire des retours.
    Est-ce que ça veut dire que sans agilité, tu ne parles pas au client pendant au moins 6 mois ? (c'est risqué, puisque ses besoins sont mal exprimés dans le cahier des charges et en plus ils vont changer pendant le développement du logiciel)
    Keith Flint 1969 - 2019

  6. #6
    Expert éminent
    Avatar de pmithrandir
    Homme Profil pro
    Responsable d'équipe développement
    Inscrit en
    Mai 2004
    Messages
    2 418
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable d'équipe développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 418
    Points : 7 295
    Points
    7 295
    Par défaut
    Je pense que l'analyse est biaisée de plusieurs manière.

    déjà, l'agilité quand on fait partie d'une sorte d'ESN, ca commence mal.(c'est un peu antinomique... parce que le postulat de base de transparence et d’honnêteté ne peut pas être respecté). En plus, ca met toujours les ESN en difficulté pour faire un contrat... car en agile on vend du temps et pas de la réalisation... ce qui est difficile à contractualiser, dans tous les pays.

    En plus, les défauts qu'ils citent, à savoir la suppression des tests unitaires, les outils de dev pas bien configuré... n'ont rien à voir avec l'agilité, mais avec la capacité du PO à comprendre que dans chaque sprint, il faut laisser le temps aux équipes de bien faire les choses(définition du done, part de tickets techniques, etc...)

    Enfin, il est important de noter que contrairement à ce qu'il dit, le but d'un sprint n'est pas d'en mettre le plus possible et de le réaliser... si une équipe réalise 100% de ses objectifs a chaque sprint, elle n'est pas bonne. Soit elle prend de la marge, soit elle bosse sur un rythme pas soutenable ou en dégradant la qualité pou tenir les délais... ce qui va a l'encontre des principes de l'agilité.
    Le découpage en sprint n'est qu'une manière d'estimer grossièrement ce que sera notre travail pendant 2 semaines. Après, la vie étant ce qu'elle est, on fait au mieux avec les impératifs qu'on a, et on livre ce que l'on peut livrer en essayant de s'approcher autant que possible de l'esprit recherché par le PO. Mais un scrum master qui dit : moi je livre cette nouvelle fonction importante dans 10 jours quoi qu'il arrive... ne fait pas son travail.

    toute la logique de l'agilité est de prendre en compte le réel pour accepter ce qui est... et essayer d'anticiper au mieux.

  7. #7
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par stardeath Voir le message
    la nécessité de livrer pour l'année dernière est sûrement beaucoup plus responsable des problèmes que l'agilité, mais comme j'ai dit, je suis mauvais public.
    En ce qui me concerne, tu prêches un convaincu.

    Plus généralement, un sprint de deux semaines, toutes les deux semaines, ça veut dire qu'on est à vitesse maximale tout le temps. Que des humains doivent être à 100% tout le temps. Rien que ça, ça me fait tiquer. Ca veut aussi dire que personne ne prend jamais le temps de penser l'architecture dans sa globalité. Pas étonnant que ça pose des problèmes.

    Une équipe agile chez nous, qui était sur un projet critique, est allée voir la chef, et lui a dit "il nous faut 15 jours ouvrés pour tout refactorer, sinon on va dans le mur". La chef a accepté, ce qui a vraisemblablement sauvé le projet (et peut-être la boite). Mais, pour le coup, c'était pas du vrai agile : un sprint ou il n'y arien d'autre à montrer qu'une liste sans fin de composants refactorés, c'est l'antithèse de l'agile. Mais c'était nécessaires. Quelle proportion de décideurs sont capables de dire oui à une demande pareille?
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  8. #8
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2006
    Messages : 436
    Points : 963
    Points
    963
    Par défaut
    Pour avoir eu la chance de travailler dans plusieurs boites sur des projets de tailles et complexités différentes, j'ai constaté plusieurs problèmes.

    Faire de l'agile à sa sauce : on prend 30% de la méthodo, le reste, bof, c'est chiant donc à la poubelle => forcément ça n'ira pas : si chaque société propose sa propre définition de l'agilité, on ne s'en sort pas.

    Sous estimer les tâches : pas de temps allouer à la réalisation de la documentation, pas de temps pour les tests manuels et automatisé, la relecture de code et les retours.

    Commencer des tâches qui ne sont correctement décrites / absence de maquette. "oh c'est simple y a juste 2 champs à ajouter et 1 bouton" alors oui si on sait exactement où les mettre, ça va vite, mais si on doit aller à la pêche aux infos, sur une tâche estimée à une demie journée, n a déjà perdu 1h à attendre que le "product owner" sorte de sa réunion, encore 1h pour qu'il se renseigne, 1h pour retrouver la documentation, 1h pour avoir le complément d'info car la doc était pas à jour. Bref, j'en rajoute peut être un peu, mais ça arrive plus souvent qu'on ne le pense.

    Ensuite, le plus gros problème, c'est de négliger les sprints d'architecture en début de projet : c'est surtout à ce niveau que ça fait TOUTE la différence selon mon expérience : une société qui prend le temps de faire des tâches pour l'archi et ne pas "itérer" avant de pouvoir commencer, c'est une source de problème à moyen terme totalement désastreuse.
    J'ai adoré travailler sur des projets avec des Sprint 0 - 1, Sprint 0 - 2, Sprint 0 - 3 etc jusqu'à ce que l'archi et les composants nécessaires pour dérouler le projet soient en place.
    Par exemple :
    - ORM : PoC pour démontrer les différentes couches à mettre en œuvre pour communiquer avec la base et remonter les infos jusqu'à l'UI (service, injection de dépendance etc)
    - Logs : pouvoir remonter et piloter les logs depuis un dashboard : ça fait économiser énormément de temps d'avoir un maximum d'info
    - Metrics : il peut être intéressant de connaitre la fréquence d'utilisation d'un module, d'une fonctionnalité. Ici encore, avoir un dashboard qui met le tout en évidence de façon synthétique fera gagner du temps. Ce genre de pratique permet de savoir si une refactorisation/optimisation/refonte/etc, vaut le coup : pourquoi passer 2 sprints à revoir un module utilisé par 2% des clients et que l'utilisation faite par ces 2% représente 5% du temps d'utilisation du logiciel ?
    - Framework : méthodes d'extension, helpers, utilities, etc
    - composants UI : point crucial et souvent négligé : on créé les composants au fur et à mesure des besoins... Alors là, c'est une méthode infaillible pour avoir du code crade, implémenté de 10 façons différentes et super emmerdant à refactoriser/tester.
    Il ne faut pas être un cador pour anticiper des besoins récurrents en terme d'UI. Exemple :
    Est-ce que l'appli aura besoin d'un DataGrid filtrable ?
    Est-ce que l'appli proposera des liste déroulantes à choix multiples ? Si oui, est-ce qu'on aura besoin d'un bouton aucun/tous dedans ? etc.
    Des présentations sous forme d'onglet ?
    Des fenêtre de dialogue avec plus de choix que "oui" "non" ?
    Des notifications ?
    Alors oui, il est possible qu'on développe des contrôles qui ne seront pas utilisés (YAGNI) mais qu'est-ce que ça change la vie quand 10 développeurs différents sont capables à peu de chose près de pondre une UI avec les mêmes composants rapidement sans perdre 1 semaine à créer un nouveau composant. Ca permet d'estimer les réalisations avec beaucoup plus de précision puisque les composants existent en grande majorité.
    - thème : on rajoute des thèmes après coup, on oublie de l'appliquer à de vieux composants, on a des visuels différents, pas les mêmes marges, des couleurs différentes etc. Que de temps perdu à aligner le tout après coup alors que ça peut s'anticiper.

    Les projets qui anticipaient un max de chose en amont se sont avérés bien plus agile par la suite que celles qui négligeaient ces aspects. Après, c'est mon retour d'expérience perso.
    "S'adapter, c'est vaincre" - Cellendhyll de Cortavar

  9. #9
    Expert éminent
    Avatar de pmithrandir
    Homme Profil pro
    Responsable d'équipe développement
    Inscrit en
    Mai 2004
    Messages
    2 418
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable d'équipe développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 418
    Points : 7 295
    Points
    7 295
    Par défaut
    El slapper, je ne suis pas d'accord quand tu dis qu'une équipe qui fais du travaille non montrable ne travaille pas dans l'esprit agile.

    Rien n'a jamais dit que tous les livrables devaient être montrable, ni qu'ils devaient changer quelque chose de visible.
    Conserver l'existant est parfois déjà un objectif en soit.

    Après, le problème vient souvent de 2 difficultés :
    - le PO ne travaille pas au sein de l'équipe, ni vraiment dans le projet. donc il ne fait pas son rôle de PO.
    - Le PO n'accepte pas les taches techniques, ce qui entraine 2 biais, soit le projet va dans le mur, soit les techniciens vendent 10 pour une réalité de 6 pour utiliser ces 4 unités de temps pour faire ce qui leur parait important. Avec le risque de passer du temps a travailler à rebours des besoin du PO. (gros refactoring sur un module qui est fermé dans 2 mois...)

  10. #10
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    +1000 avec Kikuts : le YAGNI, c'est un principe qui m'a toujours semblé casse-gueule. Avoir des bases solides, c'est quand même bien plus performant quand on multiplie les éléments.

    Mon beau-frère a un jour utilisé une structure qu'il avait anticipé 11 ans plus tôt. Si il avait respecté le YAGNI, il aurait gagné 30 minutes au départ, et perdu plusieurs jours de refactoring à la fin. Souvent, le délai est plus court.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  11. #11
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    Je suis pas convaincu qu'une méthode soit plus propice à la dette technique que les autres. Ce qui créer de la dette c'est

    • les mauvaise estimation de temps. : Il faut aller vite , on fait donc au plus rapide et c'est rarement le mieux. Ca inclus aussi les spéc foireuse puisqu'on arrive pas à les chiffrer correctement
    • des contraintes particulières : Typiquement sur certains projets ou je bosse on nous impose une "forward compatibility" qui empêche de casser certaines chose pour faire mieux.
    • le manque de compétence de l'équipe


    A la limite je dirais même que l'agile peut permettre d'intercaler quelques sprint de refactoring si vraiment c'est le bordel , là ou sur des méthode plus traditionnel ca n'arrivera , éventuellement, qu'à la fin.

    perso, je déteste les méthodologies agiles, peut être déjà parce que j'ai l'impression que dans toutes les boites dans lesquelles je suis passé, elles ne prennent qu'un ou 2 points d'une méthodologie et jettent le reste.
    C'est un autre débat , mais je pense qu'au contraire c'est une très bonne chose de ne prendre dans les méthodes agile ce qui colle à l'équipe. Vouloir appliquer à la lettre une méthode ca ne fonctionne que très rarement. Après y'en a qui se dise agile alors qu'il ne font que de la gestion de crise en permanence.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  12. #12
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    Par défaut
    Citation Envoyé par grunk Voir le message
    C'est un autre débat , mais je pense qu'au contraire c'est une très bonne chose de ne prendre dans les méthodes agile ce qui colle à l'équipe. Vouloir appliquer à la lettre une méthode ca ne fonctionne que très rarement. Après y'en a qui se dise agile alors qu'il ne font que de la gestion de crise en permanence.
    c'est possiblement un autre débat, mais quand même, si au final tu te dis agile parce que tu fais un morning meeting (véridique, j'ai déjà subit ce type "d'agilité"), tout ce qui sera tenté d'être construit par la suite sera naze.
    parce qu'en plus, d'après mon expérience, on ne prend pas d'agile ce qui colle à l'équipe, mais ce qui plaît à une hiérarchie et en général ça ne colle pas à l'équipe, mais on doit subir de la même manière.
    et quand, sous couvert ce cette agilité, tu délaisses les specs (genre les specs fonctionnelles faites par des dévs), les tests (on m'a demandé plusieurs fois de ne pas tester, car ça prend du temps), la qualité de dév, etc., faut pas s'étonner d'avoir une dette qui devient encore plus ingérable.

    après on est toujours au même point, j'ai toujours eut l'impression que malgré qu'on me vende de l'agile, je n'en ai jamais fait.
    ça donnait surtout l'excuse de ne pas traiter les problèmes parce que pas dans un sprint, une road map, etc.

  13. #13
    Membre chevronné Avatar de denisys
    Profil pro
    Développeur informatique
    Inscrit en
    Mai 2002
    Messages
    1 122
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Mai 2002
    Messages : 1 122
    Points : 1 924
    Points
    1 924
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    25/02/2021 13h18
    Parfois il y a des vieux logiciels qui ont été modifiés par plusieurs groupes de personnes, et tu te retrouves dessus à devoir faire du reverse engineering pour comprendre ce qu'il se passe.
    Manque de documentation technique.
    Et généralement tu retrouve cette situation.
    Avant l’avènement des méthodes agiles.
    Parce que, ce temps n’est pas inclue dans les charges de travailles.
    Aujourd’hui, avec les méthodes agiles, combien de temps est inclue dans les charges de travailles, concernant documentation technique ?.
    La triste constatation, que l’on peut faire.
    La seul et unique méthode acceptable, pour certains chef de projet, manager etc ..
    C’est celle qui permet de livrer le produit avant de l’avoir commencé, affin de rentrer sur son retour d’investissement.
    Quel que soit la méthodologie utilisé : cycle en V , PERT etc ..
    Hé oui de vi …..
    Ne pas savoir n’est pas une faute si l’on cherche à combler ses lacunes.

    "Il n'y a pas d'obstacles infranchissables , il y a des volontés plus ou moins énergiques voilà tous" Jules Vernes

  14. #14
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par grunk Voir le message
    Je suis pas convaincu qu'une méthode soit plus propice à la dette technique que les autres.
    L'une des sources de la dette technique est le fait de s'engager à la fois sur le périmètre et le délai de livraison. En effet, en cas d'estimation optimiste, les développeurs, pour essayer de tenir les délais à court terme, produisent un résultat dont la qualité est en dessous de ce qu'ils savent faire. Si la méthode rend la qualité prioritaire sur le périmètre, alors cela fait une source de dette technique en moins.

    Par exemple, en vrai SCRUM, la qualité ne diminue pas en cours de sprint. En cas de problème d'estimation, la variable d'ajustement, c'est le périmètre. La DOD (Definition Of Done) doit être respectée, ce qui limite la croissance de la dette technique.

    Je cite le guide SCRUM :
    During the Sprint:
    • No changes are made that would endanger the Sprint Goal;
    • Quality does not decrease;
    • The Product Backlog is refined as needed; and,
    • Scope may be clarified and renegotiated with the Product Owner as more is learned.
    Cela dit, parmi les entreprises qui disent faire du SCRUM, peu en font vraiment.

  15. #15
    Inactif  

    Profil pro
    Inscrit en
    Janvier 2011
    Messages
    3 064
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 064
    Points : 4 604
    Points
    4 604
    Par défaut
    Bonsoir ,

    Agile pourrait-il conduire les organisations vers une dette technique plus importante ?

    Don Clos, développeur logiciel, pense que oui et propose une analyse détaillée de la situation

    Que pensez-vous des différents points abordés par Don Clos ?
    Tout à fait , le fond du problème est aussi à voir dans la composition des équipes.

    Pensez-vous qu'Agile contribue à l'accumulation de la dette technique ?
    Tout à fait . Quand on commence a avoir plus de "consultant" ou de "pseudo développeur" ... C'est mignon d'avoir des "sachants" qui vont donner leur opinion ... Ceux ci ne codent pas et sont totalement déconnectés de la problématique initiale ... De ce qui conduit à des aberrations .

    Cas concret , un dev "team leader" en java, angula, php, versionning, qui se prêtant "expert" en BI ... qui au final ne fait pas la différence entre "tableau" et "matrice" et n'a aucune notion de qualitaticien , ni de la "qualité" ... Résultat un projet BI la partie ODS / pré datamart a été revu ... 12 fois !

    Selon vous, comment les organisations peuvent-elles payer la dette technique ?
    1) en mettant en place une cartographie des process
    2) en ayant moins de "sachant" et plus de techniques , combien de sachants, pseudo techniques et faux experts ? Par moment on frise le ridicule en terme de consultant machin chose ... qui n'y connaissent quedal , voir n'ont aucune notion de ce qui se fait dans l'entreprise
    3) venir mettre les process et les explications sur une "carte" , en donnant des explications et non pas des pages et des pages de règles de gestions imbuvables ...
    4) Wiki et partage de doc c'est bien aussi

  16. #16
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 423
    Points : 8 699
    Points
    8 699
    Billets dans le blog
    43
    Par défaut
    Sujet intéressant que celui de la dette technique où il n'est jamais facile de faire le tri et de hiérarchiser les facteurs, tant ils sont nombreux.

    Tout d'abord, j'aurais tendance à dire que la méthode sur ce sujet précis n'est pas l'ennemi. Si on n'a pas envie, ou pas les moyens de faire du "bon boulot", que la méthode soit Agile ou Waterfall, ou un mix des deux, on aboutira fatalement à un SI fait de bric et de broc, de rustines faites dans l'urgence ou par incompétence, ou les deux à la fois, croulant sous un héritage rigide et obsolète.

    Il est de bon ton et à la mode de taper sur l'Agile. Parfois par méconnaissance, parfois par paresse intellectuelle. Cette méthode a des défauts et n'est pas adapté à tous les projets, mais dire qu'elle est la principale responsable de la dette technique d'une entreprise, c'est un peu fort de café. Les organisations n'ont pas attendu de se mettre aux méthodes Agile pour voir apparaître des boulets techniques dont elles ont du mal à s'en défaire, malgré des moyens financiers parfois colossaux.

    Les deux principaux facteurs qui me semblent directement contribuer à la dette technique sont :

    * Les personnes : sauf à vouloir être dans le déni, nous sommes tous contributeurs à des degrés divers d'une dette technique. Chaque décision prise, chaque ligne de code écrite, peut potentiellement se révéler à long terme être de la dette technique. Tout simplement car les besoins évoluent et l'état de l'art dans notre milieu évolue sans cesse. Je dis souvent qu'il ne sert à rien de voir 10 ans à l'avance, c'est ridicule, cependant, il est toujours bon d'avoir quelques coups d'avance.
    Le niveau de compétence des personnes est important pour limiter la dette technique, mais bizarrement, et je suis pourtant un grand avocat de remettre en avant la technique, avoir un développeur très compétent par rapport au reste de l'équipe peut aussi poser des problèmes. Ce dernier pouvant être difficile à manager, à canaliser et à faire rentrer dans un certain schéma global.

    * L'organisation : il y a des formes d'organisation, des cultures d'entreprise qui favorisent davantage la dette technique que d'autres. Pour avoir bossé dans différent secteur, j'ai pu constater que les petites organisations avaient tendance à favoriser la culture de la bidouille et du "chacun fait comme il veut". Ce qui est très bien pour l'innovation, mais a ses limites lors du passage à l'échelle et en terme de pérennité et d'évolutivité. A contrario, les organisations plus grosses, avec davantage de process limitent ce problème avec l'existence de normes, même partielles, mais en contrepartie génèrent de la dette technique par la lenteur de la mise en œuvre.

    Pour limiter la dette technique, il convient donc d'être à la fois rapide dans la mise en œuvre et structuré. Ce n'est pas antinomique avec les méthodes Agile.
    La dette technique, c'est comme la poussière, il faut passer le balai tous les jours.
    C'est donc plus une question de volonté au quotidien, de faire régulièrement de l'administratif (documentation) ou des tâches rébarbatives (refactoring, mise à jour des suites de tests, etc) que d'une méthode sur un projet donné.
    Tutoriels et FAQ TypeScript

  17. #17
    Membre éclairé
    Homme Profil pro
    Chef de projet
    Inscrit en
    Mars 2017
    Messages
    323
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chef de projet
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2017
    Messages : 323
    Points : 781
    Points
    781
    Par défaut
    Tout part de la volonté des décideurs de projet: si ils ne sont là que pour faire de la merde et ne cherchent pas l'amélioration, laissez tomber, peu importe la méthode ce sera un fiasco.

    J'ai fait des sprints de 15 jours en agile pendant des années sur un progiciel, les livrables étaient testés, fonctionnels, il n'y a jamais eu de crash en production, mais toute l'équipe bossait dans le même sens. Si il y avait des portions à refactoriser, et bien c'est une fiche à intégrer dans un sprint, c'est tout. Et j'ai pu refondre 75% du code du projet au fil des sprints tout en patchant les bugs et en ajoutant du fonctionnel, une énorme partie de la dette a été soldée ainsi et ce fut un succès. Couplé à une approche DevOps ont a pu améliorer les retours clients et les retours en interne des salariés du support technique.

    L'agilité, l'approche DevOps, sont des états d'esprit à avoir, ils traduisent une autre façon d'appréhender l'informatique et son utilisation par tous les acteurs. Malheureusement j'en ai croisé beaucoup qui n'ont pas cette approche, ils considèrent que c'est une perte de temps d'améliorer les systèmes dans ce sens. Ils ne voient pas le gouffre financier que les coûts cachés induits par la dette technique amène, puisque c'est de l'argent indirectement dépensé quand j'annonce qu'il me faut 10 jours pour le faire au lieu de 5.

    Par contre, quand on leur dit que la modif est facile à implémenter et que j'en ai pour 2 jours, j'entends "ah bah c'est cool!"
    Oui, mais réveilles toi, j'ai passé 2 semaines à la conception initiale. Merci l'anticipation. On a rien sans rien, si tu veux aller vite au début, t'iras lentement plus tard!

  18. #18
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 851
    Points : 2 424
    Points
    2 424
    Par défaut
    Citation Envoyé par tanaka59 Voir le message
    Bonsoir ,

    Cas concret , un dev "team leader" en java, angula, php, versionning, qui se prêtant "expert" en BI ... qui au final ne fait pas la différence entre "tableau" et "matrice"
    https://www.developpez.net/forums/d1...bleau-matrice/

    mathématique vs informatique

  19. #19
    Inactif  

    Profil pro
    Inscrit en
    Janvier 2011
    Messages
    3 064
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 064
    Points : 4 604
    Points
    4 604
    Par défaut
    Bonsoir,

    Citation Envoyé par marc.collin Voir le message
    Hélas impossible à faire comprendre à l’intéressé ... Dans une approche BI ,Microsoft par exempl,e utilise le terme "matrice" pour ce qui contiendra exclusivement du numérique. "Tableau" quand on peut avoir du alphanumérique / booléen et j'en passe ... Ne pas prêter attention a ce type de différence peut conduire à des aberrations ...

  20. #20
    Inactif  

    Homme Profil pro
    Ingénieur test de performance
    Inscrit en
    Décembre 2003
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur test de performance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 986
    Points : 2 605
    Points
    2 605
    Par défaut
    Bonjour.

    Citation Envoyé par el_slapper Voir le message
    +1000 avec Kikuts : le YAGNI, c'est un principe qui m'a toujours semblé casse-gueule. Avoir des bases solides, c'est quand même bien plus performant quand on multiplie les éléments.

    Mon beau-frère a un jour utilisé une structure qu'il avait anticipé 11 ans plus tôt. Si il avait respecté le YAGNI, il aurait gagné 30 minutes au départ, et perdu plusieurs jours de refactoring à la fin. Souvent, le délai est plus court.
    Nous sommes content pour ton beau-frère.

    Nous aimerions connaître cette structure, nous avons l'eau à la bouche.

Discussions similaires

  1. Réponses: 2
    Dernier message: 08/03/2011, 18h43
  2. Réponses: 0
    Dernier message: 20/04/2010, 15h14
  3. Réponses: 8
    Dernier message: 27/09/2008, 00h46
  4. Rediriger les répertoires vers une page
    Par Alexandre T dans le forum Struts 1
    Réponses: 3
    Dernier message: 20/09/2007, 19h27
  5. Orienter les flux vers une carte réseau
    Par fregolo52 dans le forum Réseau
    Réponses: 4
    Dernier message: 03/07/2007, 17h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo