Pen^2 (./477) :
Nil > oui, voilà !
manoloben > oui et non, impliquer le client au plus vite permet d'éviter les surprises et avec des retours réguliers il y a moins de chances que ça diverge trop de ce qu'il attend.Disons que la gile n'est pas larache.
Mouais ça c'est toujours comme ça, c'est bien initialement, ça devient de la merde quand les gens agissent en prenant ça comme règle générale sans réfléchir plus loin. Ce fut la même chose dans le temps avec la bureaucratie par exemple.
Les gens de partout sont obsédés par le fait de toujours paraître de plus grande valeur, et ils boivent tous ces petits conseils qui sont objectivement bien, les premiers temps en tous cas. Puis ils ne s'adaptent pas. Parce qu'ils ne sont pas vraiment des gens de valeur, ils veulent juste paraître de valeur pour leur propre ego et pour pouvoir tromper leurs proches (et pouvoir baiser).
Je pense la même chose des langages dynamiques et du dév rapide. J'ai fini par faire ça pour mon jeu aussi par exemple, et ça m'a permis d'avancer beaucoup plus vite et de faire tester des choses aux gens, sachant que moi en tant que codeur je ne suis pas la seule personne sur terre qui doive pouvoir déterminer si mon jeu est bien ou pas (rien que par le fait qu'on soit 2 sur le projet, dont un non-codeur). Pas de jugement de valeur là-dessus, c'était une méthode qui a permis d'avancer et a donné un jeu qui était plus "community-feedback-based", alors que j'aurais aussi pu continuer comme avant et ça aurait donné un jeu "Brunni-opinion-based". Mais de là à se dire que parce que c'est "bien" (et ça a été bien de faire ce que j'ai fait vu le résultat) c'est ce qu'il faut faire tout le temps, parce que si tu fais autrement c'est vieux, démodé et kitsch et donc "pas bien", il y a un pas nauséabond à ne pas faire selon moi. Prototyper un truc en codant de façon agile c'est très bien, continuer à le faire pour que les managers puissent bullshitter et obtenir de la thune permettant au projet de persister mouais bof, mais accepter que quand cette phase est terminée et que tu veux mettre un max de codeurs sur le projet on doit rattraper le temps perdu et se remettre à coder comme il faut (ce qui signifie suivant le projet de le recoder entièrement avec un langage statique, hé ouais c'est la vie mon gars). Et non se dire "non mais de toute façon mieux vaut pas avoir plus de 4 ingénieurs sur le projet, après l'efficacité s'effondre" (véridique). Bien sûr qu'elle s'effondre sur un putain de projet en Python. Mais on ne pond pas le prochain Super Smash Bros avec 4 codeurs Javascript les mecs, non ! Un peu d'ambition, un peu de cerveau, un peu de valeur de vraie que diable. On vous paie assez pour ça !