C’est le contenu de base que l’on retrouve dans la plupart des livres sur les méthodes agiles, comme l’Extreme Programming de Kent Beck ou le Scrum de Jeff Sutherland. Vous pouvez aussi regarder les user stories. La plupart des gens ne savent pas vraiment que le fondement de l’agile, ce sont des sprints courts et des démos afin de s’adapter rapidement aux exigences des clients.
Je comprends tout à fait votre point de vue.
Il y a clairement des aspects qui ne peuvent pas être remplacés par le code.
Dans ce sens, si je devais l’expliquer un peu différemment, ce que je voulais dire, c’est qu’un code très lisible permet d’éviter d’avoir à produire de la documentation.
La documentation qui s’accumule au fil du temps à mesure que le logiciel évolue impose elle aussi une charge cognitive aux développeurs. L’idée centrale est de réduire les allers-retours entre le code et la documentation.
Je ne pense pas qu’on puisse ne laisser que le code.
J’imagine que cela peut varier selon le contexte et la situation.
Merci pour votre commentaire.
Pour formuler une objection avec prudence, je pense que le code ne peut pas remplacer la documentation. Les langages de programmation n’ont pas encore la richesse d’expression ni la capacité de transmission du langage naturel, et, en pratique, qui peut vraiment lire tout ce code ?
Avoir un code capable de remplacer la documentation est un espoir, un vœu pieux, mais c’est une tour de Babel impossible à atteindre.
Autant faire sérieusement de l’OOAD, cela me paraît bien mieux.
Qu’est-ce que ça veut dire, au juste, « rédiger les specs de façon agile » ?
Rédiger les specs à la va-vite.
Rédiger les specs comme le client les dicte.
Si les exigences du client changent, maintenir les specs avec l’aide d’outils pour pouvoir les modifier rapidement.
Rédiger les specs de façon agile.
Au fond, le point essentiel de cet article, c’est qu’on ne sait même pas vraiment ce qu’est l’agile. On n’a cessé de dire que l’agile a telles ou telles caractéristiques et qu’il faut faire ceci ou cela, mais jusqu’à présent je n’ai jamais vu d’article qui montre concrètement : « voici un produit construit selon la méthodologie agile ». Même en lisant le Manifeste, ça reste assez flou. Peut-être pourriez-vous en montrer un exemple ?
Je ne sais pas pourquoi on considère à ce point les méthodologies comme des textes sacrés. À mon avis, l’auteur original n’était pas si différent non plus : seule l’orientation changeait, mais il relevait tout autant du dogmatisme.
À partir du moment où on choisit SQLite pour un serveur de production, il faut sans cesse se demander quand il faudra migrer.
Autrefois, cela valait la peine d’y réfléchir parce que le coût même de la base de données (achat des serveurs, IDC, licences, etc.) était élevé,
mais aujourd’hui, alors qu’on peut déployer tout ça en un soi-disant simple clic, est-ce vraiment nécessaire de se poser la question ?
Rien qu’avec la remise en cause de la prise de décision verticale et l’amélioration itérative par cycles courts, le message qu’elle nous laisse est fort pour nous (et il en va évidemment de même pour les méthodes et outils de gestion de projet).
La conclusion selon laquelle « l’agile lui-même n’a pas apporté de nouvelles perspectives et caricature tous ceux qui le défendent en fans aveugles de l’agile » me semble excessive.
Oui, voilà. Je me suis dit qu’il y aurait peut-être un nouvel angle intéressant, alors j’ai même regardé l’article original, mais je me suis demandé ce que c’était que ça...
Au lieu d’ouvrir avec des points basiques comme le fait qu’on utilise le disque parce que la mémoire coûte cher, la stabilité d’exploitation en production ou encore l’atomicité, ils se mettent d’emblée à faire des comparaisons de vitesse, et ça me fait doucement rire.
« On vend des DB, mais il n’y a pas toujours besoin d’une DB ! » — ils publient un article pour dire ça sans la moindre gêne ; on se demande s’ils veulent juste faire du marketing -_-... Même en essayant de voir ça positivement, ça me rend parfois un peu cynique.
Bon, disons au moins qu’on en aura tiré un benchmark.
Je vous ai bien lu. Ainsi que ce que vous avez écrit sur votre blog. Je ne sais pas si l’analogie est vraiment appropriée, mais cela me fait penser à la raison pour laquelle le tout premier tutoriel de nombreux langages est Hello World!, et au fait que, par le passé, lorsqu’on apprenait le développement web en construisant des forums ou des boutiques en ligne, le processus relevait au fond de la même logique que celle que vous évoquez. À l’époque, je pensais ceci : si l’on maîtrise suffisamment les techniques pour créer un forum et une boutique en ligne, alors on peut implémenter la plupart des sites web. Et au fond, la programmation, en fin de compte, ce n’est jamais qu’une affaire d’input et d’output.
Je trouve que la conclusion est un peu excessive. La commercialisation ou la formalisation peuvent poser problème, mais cela ne veut pas dire que des outils comme les sprints ou le backlog sont devenus inutiles. Ils ont aussi contribué à ancrer une culture de réunion plus horizontale et centrée sur les objectifs. Il est vrai que le SDD a gagné en importance, mais comme on peut désormais rédiger rapidement cette spécification de manière collaborative avec l’IA, cela reste malgré tout agile. Les sprints de deux semaines se sont simplement raccourcis à quelques heures ; l’essence même, celle d’itérer en affinant progressivement, me semble inchangée.
C’est un article assez idiot. Le point essentiel, c’est qu’il faut rédiger la spec. elle-même de manière agile... L’agilité, c’est s’adapter rapidement à l’évolution des exigences du client.
C’est à cause de ce genre de malentendus sur l’agilité et des idées vagues que les choses partent dans la mauvaise direction, que ce soit pour l’agilité ou pour la culture de développement.
rip
C’est le contenu de base que l’on retrouve dans la plupart des livres sur les méthodes agiles, comme l’Extreme Programming de Kent Beck ou le Scrum de Jeff Sutherland. Vous pouvez aussi regarder les user stories. La plupart des gens ne savent pas vraiment que le fondement de l’agile, ce sont des sprints courts et des démos afin de s’adapter rapidement aux exigences des clients.
Je comprends tout à fait votre point de vue.
Il y a clairement des aspects qui ne peuvent pas être remplacés par le code.
Dans ce sens, si je devais l’expliquer un peu différemment, ce que je voulais dire, c’est qu’un code très lisible permet d’éviter d’avoir à produire de la documentation.
La documentation qui s’accumule au fil du temps à mesure que le logiciel évolue impose elle aussi une charge cognitive aux développeurs. L’idée centrale est de réduire les allers-retours entre le code et la documentation.
Je ne pense pas qu’on puisse ne laisser que le code.
J’imagine que cela peut varier selon le contexte et la situation.
Merci pour votre commentaire.
On dirait juste une invitation à changer de perspective, mais vous êtes tous bien susceptibles.
Je vais moi aussi essayer une fois.
Merci pour ces bonnes informations.
Pour formuler une objection avec prudence, je pense que le code ne peut pas remplacer la documentation. Les langages de programmation n’ont pas encore la richesse d’expression ni la capacité de transmission du langage naturel, et, en pratique, qui peut vraiment lire tout ce code ?
Avoir un code capable de remplacer la documentation est un espoir, un vœu pieux, mais c’est une tour de Babel impossible à atteindre.
Autant faire sérieusement de l’OOAD, cela me paraît bien mieux.
Qu’est-ce que ça veut dire, au juste, « rédiger les specs de façon agile » ?
Au fond, le point essentiel de cet article, c’est qu’on ne sait même pas vraiment ce qu’est l’agile. On n’a cessé de dire que l’agile a telles ou telles caractéristiques et qu’il faut faire ceci ou cela, mais jusqu’à présent je n’ai jamais vu d’article qui montre concrètement : « voici un produit construit selon la méthodologie agile ». Même en lisant le Manifeste, ça reste assez flou. Peut-être pourriez-vous en montrer un exemple ?
BckHWP. Automatisation VBA pour Excel
https://m.blog.naver.com/husky81/222045248589
Ce serait bien que gemini cli fonctionne correctement, mais il plante tout le temps.
Ces derniers temps, je vois ce genre de cas plus souvent.
Je ne le comprends pas exactement, mais j’ai l’impression de voir à peu près ce que ça veut dire.
Merci.
Je ne sais pas pourquoi on considère à ce point les méthodologies comme des textes sacrés. À mon avis, l’auteur original n’était pas si différent non plus : seule l’orientation changeait, mais il relevait tout autant du dogmatisme.
À partir du moment où on choisit SQLite pour un serveur de production, il faut sans cesse se demander quand il faudra migrer.
Autrefois, cela valait la peine d’y réfléchir parce que le coût même de la base de données (achat des serveurs, IDC, licences, etc.) était élevé,
mais aujourd’hui, alors qu’on peut déployer tout ça en un soi-disant simple clic, est-ce vraiment nécessaire de se poser la question ?
Cet article lui-même n'est pas agile !
Je suis d’accord.
Rien qu’avec la remise en cause de la prise de décision verticale et l’amélioration itérative par cycles courts, le message qu’elle nous laisse est fort pour nous (et il en va évidemment de même pour les méthodes et outils de gestion de projet).
La conclusion selon laquelle « l’agile lui-même n’a pas apporté de nouvelles perspectives et caricature tous ceux qui le défendent en fans aveugles de l’agile » me semble excessive.
Ce serait bien que codex prenne aussi en charge les jetons OAuth comme Claude.
Oui, voilà. Je me suis dit qu’il y aurait peut-être un nouvel angle intéressant, alors j’ai même regardé l’article original, mais je me suis demandé ce que c’était que ça...
Au lieu d’ouvrir avec des points basiques comme le fait qu’on utilise le disque parce que la mémoire coûte cher, la stabilité d’exploitation en production ou encore l’atomicité, ils se mettent d’emblée à faire des comparaisons de vitesse, et ça me fait doucement rire.
« On vend des DB, mais il n’y a pas toujours besoin d’une DB ! » — ils publient un article pour dire ça sans la moindre gêne ; on se demande s’ils veulent juste faire du marketing -_-... Même en essayant de voir ça positivement, ça me rend parfois un peu cynique.
Bon, disons au moins qu’on en aura tiré un benchmark.
Je vous ai bien lu. Ainsi que ce que vous avez écrit sur votre blog. Je ne sais pas si l’analogie est vraiment appropriée, mais cela me fait penser à la raison pour laquelle le tout premier tutoriel de nombreux langages est
Hello World!, et au fait que, par le passé, lorsqu’on apprenait le développement web en construisant des forums ou des boutiques en ligne, le processus relevait au fond de la même logique que celle que vous évoquez. À l’époque, je pensais ceci : si l’on maîtrise suffisamment les techniques pour créer un forum et une boutique en ligne, alors on peut implémenter la plupart des sites web. Et au fond, la programmation, en fin de compte, ce n’est jamais qu’une affaire d’input et d’output.Je trouve que la conclusion est un peu excessive. La commercialisation ou la formalisation peuvent poser problème, mais cela ne veut pas dire que des outils comme les sprints ou le backlog sont devenus inutiles. Ils ont aussi contribué à ancrer une culture de réunion plus horizontale et centrée sur les objectifs. Il est vrai que le SDD a gagné en importance, mais comme on peut désormais rédiger rapidement cette spécification de manière collaborative avec l’IA, cela reste malgré tout agile. Les sprints de deux semaines se sont simplement raccourcis à quelques heures ; l’essence même, celle d’itérer en affinant progressivement, me semble inchangée.
C’est un article assez idiot. Le point essentiel, c’est qu’il faut rédiger la spec. elle-même de manière agile... L’agilité, c’est s’adapter rapidement à l’évolution des exigences du client.
C’est à cause de ce genre de malentendus sur l’agilité et des idées vagues que les choses partent dans la mauvaise direction, que ce soit pour l’agilité ou pour la culture de développement.