Discussion :

[kilroyFR]

Je suis moi meme developpeur et pourtant je n'accroche pas a la methodologie Agile. Les serious game etc. ca ne sert qu'a infantiliser les gens (voir jeu du SUPER POULET ridicule) + vocabulaire a connotation sectaire/religieuse on parle de "rituel", "Obeya", "scrum master == gourou" "evangeliste agile" etc.

Depuis 30 ans que je developpe je n'ai jamais accumulé de dette technique pourtant je peux dire que j'ai switché de technos bon nombre de fois et fait evoluer mes applis sans tout jeter a chaque fois.
La difference que je vois avec les devs Agile de maintenant c'est qu'ils se plaignent en permanence de ne pas disposer d'heures pour faire des POC, pas assez de temps pour faire la conception etc. parce qu'ils partent du principe de tout jeter et tout refaire d'un coup ce qui ne fonctionne pas. Pire la notion de retrocompatilibité leur est absolument inconnue. D'une version a l'autre le nettoyage est fait et ca ne leur pose aucun pb de remettre en cause des interfaces; les consommateurs s'adapteront.
J'avoue qu'avec un certain nb de mes collegues on est sidéré de ce genre de comportement. Generalement les sprints de 3 semaines les sujets ne sont meme pas menes au bout (qu'importe la methode permet de reporter sur sprint suivant), le suivi des FTs clients ca ne les interesse pas, ils veulent juste betement coder pour coder. La dette technique comme je disais j'arrive a la faire au fil des projets (sur chaque projet je refais une partie (souvent une couche applicative) en maintenant la compatibilité fonctionnelle. Ainsi en quelques versions on bascule les projets de technos assez efficacement et sans risques. Le client est content, l'application est renovée, nous on a assainit les fondations on peut passer a la suivante.
En 30 ans que je fonctionne comme ceci je n'ai jamais eu aucun soucis - faire passer des applis windows forms>web>angularsans soucis, couche par couche, applis par appli, tranquillement sans risques.

Generalement les POC, veille techno je les fais chez moi, le travail au bureau etant purement lié au codage applicatif. jouer avec les technos je considere que c'est du domaine du hobby, etc. donc je prends sur temps perso sans aucun soucis, ca me donne plus de latitude et je n'ai pas a aller pleurer ou me plaindre de ne pas avoir assez d'heures.
Je le constate sur les nouveaux projets menés par la nouvelle generation de dev, beaucoup d'heures en POC, une dette technique par manque de maitrise des sujets techniques qui sont juste survolés et au final comme ca ne marche pas, les complaintes sont 'on n'a pas eu assez de temps'. Attitude pitoyable.
Comme je leur dit souvent, vous vous prenez pour des architectes mais vous n'etes meme pas de bons macons. Ils commencent la maison par choisir la marque des outils et la couleur des moellons. Bon effectivement en montant le mur ils voient que ca ne va pas, on s'en fout, un coup de refactoring, on casse tout et on recommence. Effectivement la dette technique est colossale au final. Quand des ouvriers en cols bleu se prennent pour des cols blancs ca donne ca.
La seule chose qui importe c'est d'ajouter un inventaire de technos survolées sur le CV pour mieux aller se vendre dans la boite d'a coté ou le meme rituel se repetera.

[ebformat]

On a souvent un pbm technique lors de dev, car le scrum master veut être un winner, sans poser de questions sur l'analyse technique , mais toujours avoir l'objectif combien de point complexite livré sur un sprint (2/3 semaines). Le dev doit coder vite sans penser à l'archi, et quand la fin de sprint approche , on détecte de problème technique et dans ce cas je ne parle pas du TU,les mecs des devs sont toujours full car le prochain sprint est déjà en vue avec leur rétrospective (mdr...) qui sert à rien. Du coup les test sont tous taggué « @Ignore » . Je précise qu’ on travaille sur un vieux pgm aves des evol permanentes . Est qu'un BA dans le mode agile doit être technique? car si on balance directe dans dev ça va faire de nouille.

[pdcdec]

Salut à tous,

Comme facteur important de dette technique, j'ai souvent constaté que les cahiers des charges et les spécifications détaillées sont très défaillants.

Ca n'est pas seulement parce qu'on y passe trop peu de temps. C'est plus grave : on ne sait pas écouter le client et on ne sait pas l'aider à exprimer ses besoins. Si j'osais quitter le domaine technique pur un instant, je dirais qu'on manque parfois d'empathie.

Pour pallier ce problème, en tant que spécialiste UX/UI, je participe avec le PO aux interviews client et, en parallèle des specifications "classiques", je réalise un prototype très réaliste (avec des interactions avancées puisque j'utilise la programmation simple d'Axure).

Quand je réalise le proto, je tombe sur des dizaines de questions qui obligent à préciser le métier. Je suis obligé donc de comprendre le fonctionnel dans le détail (là où il y a le diable, vous savez), sinon, je suis bloqué. Et il vaut mieux traiter ces points en amont que plus tard en dev...

Ainsi, le client valide les specs en "jouant" avec le proto et en se l'appropriant. Ca devient son "bébé".

Ce qui est difficile parfois, c'est de faire comprendre qu'il faut investir plusieurs jours d'étude supplémentaires pour prototyper. Pour les cas compliqués, ça peut représenter jusqu'à 5 à 10% de la charge de développement.

Je conçois que ça puisse sembler énorme, mais, après des dizaines et des dizaines de projets, je peux témoigner que, du point de vue dette technique, nous avons toujours été largement gagnants.

Quand je dis "nous", c'est nos équipes, mais aussi les clients qui apprécient cette façon de faire.

Voilà, ça n'est que mon expérience concrète, mais si ça peut aider certains à réduire la dette...

Phil

[el_slapper]

@pcdec : ton point est plus annexe que central à la question posée... mais il me semble fondamental si on sort du cadre strict du sujet. Ma boite a viré un fonctionnel qui était sensé demander aux clients ce qu'ils veulent, et qui a trouvé plus commode d'inventer un besoin depuis chez lui en télétravail. Besoin qui ne collait pas du tout au vécu de son client. Exemple que la concordance entre la demande et l'offre est un sujet sensible et complexe.

Plus généralement, le client ne sait pas très bien ce qu'il veut, et le laisser jouer avec un prototype, c'est quand même idéal pour que LUI il pige ce dont il a réellement besoin. Après, le risque, c'est le prototype qui part en prod parce qu'il fait l'affaire... Deux manières de gérer ça, soit prend le temps de faire un prototype propre, soit on alloue un budget pour tout refaire au propre. Dans ces deux cas, c'est couteux...mais très vite rentable en termes de dette technique (hop, on retombe sur le sujet).

[pdcdec]

@el_slapper : c'est très pertinent quand tu dis : "c'est quand même idéal pour que LUI il pige ce dont il a réellement besoin".

Ca m'a rappelé ce que disait Steve Jobs : "Impliquez les utilisateurs pour définir le problème et non pour trouver des solutions".

Merci.

[vertex.3F]

Je suis moi meme developpeur et pourtant je n'accroche pas a la methodologie Agile.
...
Depuis 30 ans que je developpe je n'ai jamais accumulé de dette technique pourtant je peux dire que j'ai switché de technos bon nombre de fois et fait evoluer mes applis sans tout jeter a chaque fois.
...
Generalement les POC, veille techno je les fais chez moi, le travail au bureau etant purement lié au codage applicatif. jouer avec les technos je considere que c'est du domaine du hobby, etc. donc je prends sur temps perso sans aucun soucis, ca me donne plus de latitude et je n'ai pas a aller pleurer ou me plaindre de ne pas avoir assez d'heures.
Je le constate sur les nouveaux projets menés par la nouvelle generation de dev, beaucoup d'heures en POC, une dette technique par manque de maitrise des sujets techniques qui sont juste survolés et au final comme ca ne marche pas, les complaintes sont 'on n'a pas eu assez de temps'. Attitude pitoyable.
Comme je leur dit souvent, vous vous prenez pour des architectes mais vous n'etes meme pas de bons macons. Ils commencent la maison par choisir la marque des outils et la couleur des moellons. Bon effectivement en montant le mur ils voient que ca ne va pas, on s'en fout, un coup de refactoring, on casse tout et on recommence. Effectivement la dette technique est colossale au final. Quand des ouvriers en cols bleu se prennent pour des cols blancs ca donne ca.
La seule chose qui importe c'est d'ajouter un inventaire de technos survolées sur le CV pour mieux aller se vendre dans la boite d'a coté ou le meme rituel se repetera.

salut kilroyFR,
ces arguments intéressants sur les nouveaux projets et nouveaux développeurs me paraissent assez "clivants", certes on peut puiser dans notre expérience des exemples concrets qui vont les illustrer, mais aussi des contre-exemples.
Par contre j'ai un vrai souci avec l'idée de réaliser ses POC sur son temps perso, comme un hobby (pourtant ça m'arrive bien des fois malheureusement... disons par exemple lorsque les échéances du projet sont mal gérées) à moins que je comprenne mal ton propos. Si le POC est nécessaire à l'avancée du projet alors pour moi il constitue du temps de travail à part entière.
En général j'aime bien moi aussi faire le parallèle entre l'IT et le BTP, mais je vois mal un maçon rentrer chez lui le soir pour faire un POC et essayer une nouvelle méthode de construction de mur, tester les nouveaux parpaings dernier cri, etc.

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...)

Salut pmithrandir,
bien d'accord avec ce que tu écris, j'ajouterais - de façon simpliste - que, quelle que soit la méthode, on aura toujours un "souci" pour que les préoccupations des différents protagonistes du projet se rejoignent harmonieusement :

• le PO défend les fonctionnalités du produit; ça me parait naturel qu'il puisse "passer à coté" des considérations techniques (pourtant fondamentales car le produits final est, au fond, technique)
• le développeur défend la qualité logicielle; en connaissant les coulisses du métier, on sait la difficulté d'estimer l'effort de refactoring nécessaire pour accueillir une nouvelle fonctionnalité; pire, au gré des fonctionnalité, toute partie de code peut etre considérée dans le futur comme de la dette; et puis on a la dette non intentionnelle, et la dette dite "intentionnelle", acceptée afin de pouvoir livrer plus vite par exemple, et qu'on a convenu avec son scrum master de rembourser "plus tard", bien sûr, lorsqu'on aura du temps...
• le financeur ou le client final qui apprécient les moyens, les efforts, ou les résultats à leur façon

(liste non exhaustive, forcément)
Etant amené à se focaliser/spécialiser sur son sujet, chacun apporte un regard différent et sa "perception sélective". On peut imaginer, au moment des grands arbitrages du sommet de la pyramide, que les considérations du bas de la pyramide auront moins de chances d'être considérées.
Au final l'organisation (au sens large) obtient le produit qu'elle mérite, avec la dette qu'elle mérite. Difficile de désigner un responsable, et pas question pour moi de tirer sur les développeurs (qui doivent produire un logiciel "stable" en marchant sur les sables mouvants des technonogies informatiques) ni, à l'autre bout, sur les financeurs (lesquels doivent accepter de recevoir à proportion de ce qu'ils donnent).

...
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.
...

Salut Kikuts,
merci, oui, l'optimisme dans lequel l'informatique "baigne" peut - assez vite - nuire à la qualité logicielle !
Mais comment ne pas négliger ce qu'on ignore ? (dit autrement : comment bien estimer ce qu'on ne conçoit pas)

Face à cette question cruelle (pour l'entreprise qui aime la prévisibilité) les pratiques Agiles tombent à pic pour qui veut en reconnaitre les qualités !

Pour abonder dans ton sens concernant le choix des priorités, maintenant je ne suis plus étonné de rien, je vois qu'on "place" aux postes de Scrum Master et directeur de projets informatiques des profils issus d'écoles de commerce qui n'ont pas (et ne veulent surtout pas "avoir") la fibre technique, et dans un tel contexte je ne suis pas étonné des Flaccid Scrums et autres dérives. On mettra tous les échecs sur le dos de l'Agilité ou des développeurs, ce sera toujours plus facile que de se questionner sur l'organisation et le management.

[tanaka59]

Bonjour,

Pour abonder dans ton sens concernant le choix des priorités, maintenant je ne suis plus étonné de rien, je vois qu'on "place" aux postes de Scrum Master et directeur de projets informatiques des profils issus d'écoles de commerce qui n'ont pas (et ne veulent surtout pas "avoir") la fibre technique, et dans un tel contexte je ne suis pas étonné des Flaccid Scrums et autres dérives. On mettra tous les échecs sur le dos de l'Agilité ou des développeurs, ce sera toujours plus facile que de se questionner sur l'organisation et le management.

Si je puis me permettre , je mettrai aussi un facteur sur la scolarité . Depuis maintenant bien 30 ans l'aspect "téléguider" de ce qu'on fait .

En somme la pédagogie depuis 30 ans en milieu scolaire et universitaire , c'est l'écolier/collégien/lycéen/étudiant fait son taff ... puis on lui donne une correction . Amplifié on tombe dans un schéma : "faire" "correction" "faire" "correction" "faire" "correction" ... Hors en entreprise la correction c'est NOUS/VOUS qui le faisons/faisez ...

Un manager ou collègue n'est pas un prof qui va "apporter la correction" ... Beaucoup de jeune sont dans ce schéma la . Du moins c'est ce que j'ai constaté ces dernières années , avec les plus jeunes qui arrivent sur le marché.

Entre un manque de connaissance technique, un manque de connaissance métier, une vision "comptabilistique" ... La dette technique / metier est juste énorme ... Sans parler quand la main d’œuvre change tous les 6 mois ...

[kilroyFR]

salut kilroyFR,
Par contre j'ai un vrai souci avec l'idée de réaliser ses POC sur son temps perso, comme un hobby (pourtant ça m'arrive bien des fois malheureusement... disons par exemple lorsque les échéances du projet sont mal gérées) à moins que je comprenne mal ton propos. Si le POC est nécessaire à l'avancée du projet alors pour moi il constitue du temps de travail à part entière.

Personnellement je suis rentré dans l'informatique il y a 30 ans et c'etait un hobby avant de vouloir en faire un metier. Meme maintenant je considere toujours que c'est un hobby pour lequel je suis payé donc aucun etat d'ame a faire des POC, elearning a gogo chez moi parce que pendant les heures de boulot je n'aurai pas le temps ni l'envie d'aller pleurer des heures pour faire des choses interessantes. Justement le boulot c'est l'opportunité de proposer des choses evaluées par ailleurs et les mettre en pratique sur des cas concrets. 9 fois sur 10 le sujet etant creusé techniquement et validé ca passe comme une lettre a la poste.
Mais je constate egalement que ce n'est pas la mentalité en 2020, ca n'est pour beaucoup qu'un boulot (interessant) mais pas une passion qui doit si possible etre le mieux payé. Pour ca que j'ai un peu de mal avec les nouveaux devs, souvent assez refractaires a sortir de leur zone de confort, peu curieux de ce qui se fait dans d'autres langages, technos, domaines de l'informatique.
L'agilité la dedans n'a rien resolu. Le bon sens et la logique surclasse tous les rituels et autres gadgets. Je me rends compte que dans mon equipe on est plus "agile" que ceux pratiquant l'agilité; plus reactif c'est certain (on n'attend pas la fin du sprint pour sortir des versions ou des patches pour une prod). Ca fonctionne car justement on n'a pas cette rigidité et cette lourdeur du process agile ou tout est codifié. D'ailleurs je le vois les projets menes avec agilité explosent tous les budgets et delais (enfin dans ma boite, mais generalement quand l'agilité ne marche pas on dit toujours que c'est la faute aux gens, pas assez impliqués, etc pour moi ce sont de faux pretextes. Enfin c'est la mode alors tout le monde le fait.

[el_slapper]

@el_slapper : c'est très pertinent quand tu dis : "c'est quand même idéal pour que LUI il pige ce dont il a réellement besoin".

Ca m'a rappelé ce que disait Steve Jobs : "Impliquez les utilisateurs pour définir le problème et non pour trouver des solutions".

Merci.

Dit encore autrement, par Henry Ford : "on me demandait des chevaux qui allaient plus vite, j'ai conçu la Ford T".

Un manager ou collègue n'est pas un prof qui va "apporter la correction" ... Beaucoup de jeune sont dans ce schéma la . Du moins c'est ce que j'ai constaté ces dernières années , avec les plus jeunes qui arrivent sur le marché.

Un tout autre morceau du problème, mais très pertinent. Ca va même plus loin, on enseigne aux gens que chaque problème a une solution unique, qu'il faut connaitre, et basta. Rien à voir avec la vie réelle, notamment dans nos métiers (je suis sur que ça pose problème aussi dans d'autres métiers, même si je manque de billes). En plus, la vie réelle, ce sont des problèmes "sales", d'un point de vue intellectuel, avec toujours une petite verrue à droite à gauche.

C'est pour ça que beaucoup d'employeurs font un premier filtrage sur le fizzbuzz. Pas un problème difficile, mais nombre de diplômés vont chercher à juste appliquer la solution qu'ils connaissent, de manière élégante, sauf que ça n'a pas de solution élégante. L'algo est toujours un peu tordu, un peu moche. Dans le même style, tu peux demander de trouver le deuxième entier le plus élevé dans une liste d'entiers (en plus, il y a une ambiguïté dans la question, qu'est-ce qu'on fait si la valeur la plus élevée est un doublon?), et là, tu perds pas mal de gens.

Ca fonctionne car justement on n'a pas cette rigidité et cette lourdeur du process agile ou tout est codifié.

Ce qui est l'antithèse du mot, même. J4ai eu cette discussion il y a trois ans avec un collègue. Il m'a explicitement dit ça, que l'agile était extrêmement codifié, et qu'il fallait scrupuleusement suivre toutes les règles. L'agile. Putain, prenez un dictionnaire, les mecs (je ne dis pas les filles, les nôtres ne sont pas tombées dans le panneau, ne me demandez pas pourquoi, et à 2, elles ne sont pas un échantillon représentatif)

[tanaka59]

Bonjour,

Ca va même plus loin, on enseigne aux gens que chaque problème a une solution unique, qu'il faut connaitre, et basta. Rien à voir avec la vie réelle, notamment dans nos métiers (je suis sur que ça pose problème aussi dans d'autres métiers, même si je manque de billes). En plus, la vie réelle, ce sont des problèmes "sales", d'un point de vue intellectuel, avec toujours une petite verrue à droite à gauche.

Exactement , c'est l'un des problèmes de fond . Le schéma de la "pensée unique" .

[kilroyFR]

Ce qui est l'antithèse du mot, même. J4ai eu cette discussion il y a trois ans avec un collègue. Il m'a explicitement dit ça, que l'agile était extrêmement codifié, et qu'il fallait scrupuleusement suivre toutes les règles. L'agile. Putain, prenez un dictionnaire, les mecs (je ne dis pas les filles, les nôtres ne sont pas tombées dans le panneau, ne me demandez pas pourquoi, et à 2, elles ne sont pas un échantillon représentatif)

Ce n'est pas parce qu'une methode est nommée agile qu'elle l'est dans les faits. Tu t'arretes au vocabulaire moi je constate juste que je suis plus efficace (le bon sens et la confiance et la bonne communication avec les collaborateurs) sans suivre la methode dite AGILE (qui n'a d'agile que le nom), avec mon equipe on reste reactifs, plus auto adaptatifs a n'importe quelle demande impromptue, des chiffrages au plus juste basés sur l'experience plutot que le poker plannig; pas de jeux de cartes ni de "serious games"; que ce qui est pratiqué par nos equipes agile, ou rien ne sort en dehors du sacro saint sprint; aucune reactivité, suivre des dogmes et des rituels quotidiens pour essayer de motiver les gens a rentrer dans le moule.
Pas ma definition de l'agilité; cette methode porte mal son nom (et les chiffres le prouvent en tout cas dans ma boite, budgets et delais explosent). Ce sont 2 de mes projets (non agiles) de plusieurs millions d'euros qui ont fait le CA de l'an dernier; pas besoin de demonstration autre pour ma part pour voir qu'on peut faire mieux sans tout ce tralala (bon ca fait vivre des boites et autres evangelistes qui croient avoir la parole divine).