Reprise du message précédent :

 
Ben je ne pense pas que ce soit contradictoire. Effectivement, sur ce sujet, je pense que les biais sont très nombreux. Ça ne m’empêche pas d’avoir une opinion moi-même et qui n’est pas autant arrêtée que tu sembles le penser. J’ai longtemps défendu SCRUM,  le manifesto (d'ailleurs je continue à en défendre la plus grande partie), et même le principe des sprints.
Le seul reproche qu’on pourrait me faire, c’est de ne pas détacher (pour le moment, je pense éditer mes messages plus tard) mes opinions de mon genre d’exposé qui n’en d'ailleurs même pas vraiment un. Je pose quelques bases pour ouvrir la discussion et comme tout topic sur un forum comme HFR, c’est aussi fait pour faire réagir. J’ai ni la prétention, ni probablement les compétences pour faire un exposé sur un sujet aussi complexe d'une manière parfaitement neutre.
Si tu penses que qu'un SCRUm classique correctement implémenté avec des sprints peut marcher, c'est super, tu peux très bien le défendre ici, et même ça m’intéresse. C’est pas parce qu'on a pas réussi que c'est impossible, et même le fait que je connaisse bcp de monde qui sont contre (pour des raisons souvent différentes d’ailleurs), ça ne prouve rien dans l'absolu. J’ai mon opinion, mais ça s’arrête là.

Témoignage un peu extrême, mais voilà où ça peut mener quand c'est pris en main par des managers farfelus ou zélés :

https://agile.developpez.com/actu/3 [...] ificielle/

J'ai comme vous l'avez vu un appriori négatif sur tout ça mais perso, j'apprécie l'opinion de Hermes car elle est justement tempérée et il semble conscient des dérives possibles. Ça me permet de voir un peu plus le côté positif de la chose sur ce topic.  
 
Le soucis est que (tres) trop souvent, les gens amènent l'agile comme la bible ou le coran.  

Hermes est surement mesuré grâce à son parcours de dev où il a vu ce que c'était d'être de l'autre côté.
Comme toute méthode il faut piocher ce qui peut fonctionner pour l'équipe en place

J'ai connu que la méthode agile dans mes différents jobs car j'ai principalement bossé dans des startups.
J'ai jamais connu l'enfer que décrivent certains.
 
Par contre mes reproches à cette méthode sont les suivants:
- difficile de faire des trucs un peu long terme ou un peu R&D: on est encouragés à avoir un vision court-termiste car on travaille à l'échelle de quelques semaines (mais aussi c'est très lié à la typologie de boite dans lesquelles j'ai bossé)
- management qui veut les avantages de l'agile sans les inconvénients (veulent à la fois de l'agilité et des plannings à 6 mois dans lesquels tu t'engages sur la date de livraison d'une feature X)

Ici on fait beaucoup de R&D, et très peu de développement adhoc
On travaille sur des projets dont la faisabilité/intérêt est parfois remise en cause après quelques semaines de recherche/prototypage
Donc y attribuer des sprints courts avec points calculés et connus à l'avance ça se résume un peu à faire du Mme Irma

J'suis d'accord sur les deux points.
 
Et ton parallèle est d'autant plus adéquat que dans les deux cas, les gens qui martèlent n'ont souvent soit pas lu ou soit pas compris
 
Après j'en ai probablement fait brièvement partie aussi parce que du point de vue d'un grouillot, l'agile fait miroiter pas mal d'avantages; dans mon cas j'ai particulièrement été sensible au dialogue plus direct avec le métier et au fait (lié) de donner plus de sens à ce que je faisais. Du coup j'avais l'impression d'avoir un intérêt assez direct à ce que ça fonctionne bien, mais comme évidemment ça fonctionnait pas bien... Ça braque.
Mais les promesses n'engagent que ceux qui les croient et à moins d'être particulièrement aveugle il est souvent clair assez rapidement que tu peux pas grand-chose au fait que ça fonctionne pas bien, et c'est le moment de lâcher prise. En vrai ça fait un petit moment que je suis reparti en mode ballec sur le sujet. J'ai les certifs et je connais suffisamment la théorie et le vocabulaire pour que ça ne me coupe pas d'opportunités, après je m'adapte en fonction.
 
Après c'est comme beaucoup de choses (genre le communisme ), on te vend un truc qui se base sur des prérequis inatteignables et qui ne marchera jamais vraiment (là je reparle de Scrum en particulier), mais ça veut pas dire que c'est complètement de la merde non plus. Bien au contraire même, en l’occurrence il y a beaucoup de bonnes idées dedans - reste à identifier lesquelles peuvent être adaptées à son contexte du moment pour en tirer quelque chose. Tu feras pas du VRAI SCRUM mais tu en tireras quand même des avantages.
 
... Et c'est ce qu'Hermès est en train de décrire je pense (j'avoue ne pas avoir tout lu mais je le ferai promis). Avec l'intérêt supplémentaire de son job, pour moi en tout cas, parce que qu'un CTO ça voit pas la même chose qu'un grouillot.

Bon le second oui, mais bon c'est pas la faute à agile
 
Le premier je suis aussi d'accord, si tu parles de Scrum/sprints. Rien que le passage d'une grosse user story en sous-stories pour que ça tienne dans des sprints peut déjà faire perdre suffisamment de contexte pour qu'une fois dessus, associé avec la mentalité agile "on implémente le strict minimum pour que la tâche soit complète", le résultat soit du code qui fonctionne pour la story en question mais en réalité dès le sprint suivant compliquera la mise en place de la suite, avec au global une perte d'efficacité sur le long terme vs avoir fait toute la spec d'un coup au début. Ya pas de miracle, en pratique il faut jamais vraiment laisser un dev faire ce qu'il veut même si c'est un des points de base de l'agile... Il te faut un membre de l'équipe "moins égal" que les autres pour surveiller l'architecture logicielle et penser long terme - et ça aussi, de base ça va un peu à l'encontre de l'agile.

Et comme jamais deux sans trois, je donne mon avis sur un truc qui a TOUJOURS posé de gros problèmes dans tous mes projets Scrum: le PO.
 
- indépendamment de tout le reste, la qualité du PO aura un impact absolument énorme sur les résultats de l'équipe. Ton équipe peut surperformer, si c'était vers des trucs pas importants parce que le PO fait mal son boulot, c'est DTC pour tout le monde. Pareil si besoins mal compris, mal définis, etc.
- en même temps, être un bon PO est extrêmement difficile. La théorie veut qu'il connaisse le métier et les besoins sur le bout des doigts, soit toujours dispo, soit bon communiquant envers le client ET l'équipe... Un mix de Jésus et de Superman.
- un mauvais PO va amener à des séances de grooming longues et laborieuses et/ou des stories pas claires et donc réduite d'autant le temps de boulot effectif de l'équipe
- pour couronner le tout en théorie il est seul. Un autre membre de l'équipe en vacances ça réduit un peu la vélocité. Un PO en vacances, avec un peu de malchance ça peut ruiner un sprint complet.

 
Je plussoie énormément ce message.  

Bon, je viens d'éditer enfin mon troisième post pour y décrire notre application de la méthode NNL. Je précise bien NOTRE application avec NOS solutions.
 
J'éditerai probablement les 3 premiers posts avec des warnings etc... Et prendre en compte vos remarques.  
 
Please be patient (j'ai pas bcp de temps )
 
N'hésitez pas à dire ce que vous en pensez. Si vous pensez que c'est WTF, dites le, mais surtout dites pourquoi et pourquoi il n'y aurait aucune chance que cela puisse marcher chez vous
 
https://forum.hardware.fr/forum2.ph [...] #t70351421