L'agile: tout le monde en fait, et pourtant . . .

Je crée un topic dédié aux méthodes de développement pour avoir un endroit où poster cet article que je trouve assez intéressant.
Il décrit, en seulement quelques paragraphes mais de manière très juste (à mon avis*), les limites et problèmes des méthodes agiles telles qu’on les applique en ce moment.

L’article date de novembre 2018 mais vient de se faire reprendre sur HN et Reddit, où ça commente activement.

* à part le name-dropping au milieu que j’ai trouvé agaçant

3 Likes

Le top ca serait une méthode agile pour le relationnel client-dev qui enrobe une maniere de coder en cycle en V :slight_smile:
Parce que bon ca dépends des secteurs d’activité, mais j’ai trop souvent vu “methode agile = excuse pour dev cheap et rapide sans véritable methode/procedure”
On s’en rends compte au moment des audits/incident de sécu

4 Likes

Depuis un an, je bosse comme expert scientifique pour une boite d’avocat pour leur client faisant du CIR.

Les “méthodes agiles” utilisés par beaucoup de boite dans leur R&D sont aussi une justification pour ne pas faire de doc “bah on a nos stories, on a pas de de doc type cycle en V” … résultat c’est un calvaire de prouver aux impots que les mecs font de la vrai R&D sans doc XD

La méthode Agile n’est peut-être pas parfaite mais quelques fois ça n’en a que le nom: un mélange de méthode à l’arrache, de cycle en V avec une dénomination Agile qui n’a rien à voir avec la choucroute sauf à se la jouer aux comités de direction.

Parce que ça a donné de si bons résultats que ça par le passé, le cycle en V pour le dev ? :stuck_out_tongue:
Les mauvaises équipes n’ont pas attendu les méthodes agiles pour skipper la doc ou la sécu.

2 Likes

Yep, mais maintenant Agile leur donne une excuse pour skipper la doc.

2 Likes

Ce qui est moche c’est quand des équipes font des outils de détection d’anomalie (comme l’intrusion) en méthode agile pour alimenter leur SoC, et qu’au final ils n’ont quasi aucune doc derrière …