Discussion :

[Logan Mauzaize]

Pour continuer sur le thème "ne blâmez pas la méthode, blâmez les gens qui l'utilisent mal", je conseille l'excellente réponse d'Uncle Bob Martin à cet article.

Tiens c'est marrant le point (5) me rappelle quelque chose

[souviron34]

Je n'ai pas lu l'article d'origine, mais ne vaudrait-il pas mieux dire "dont le concept Agile a été détourné du droit chemin" ?

Absolument, et, sans re-rentrer pour la N'ième fois dans le détail, je suis atterré et l'ai dit X fois dans cette partie du forum, depuis plus de 8 ans, par la confusion (marketing, et en pratique et enseignée) qui s'est faite entre "le Manifeste" et des méthodologies..

Le Manifeste est ANTINOMIQUE d'une méthodologie quelconque..

Mais le monde de l'informatique veut des règles écrites.. un processus défini..

Je me suis déjà fait blasté au motif d'élitiste, mais je maintiens : l'agilité est faite pour des gens COMPETENTS et EXPERIMENTES..

XP, Scrum, etc, ne devraient pas exister ou être suivis... Il ne devrait pas y avoir de personnes "Scrum Master". Juste des rôles... mais la même personne peut être Master sur un projet et autre chose sur un autre projet..


Les gens qui me connaissent ici connaissent ma position, et je ne peux que me désespérer qu'une excellente pratique soit la cible de critiques infondées, simplement parce qu'on a voulu l'appliquer à tout et n'importe quoi avec n'importe qui..


Pour ceux qui le souhaite, je suis disposé à aller faire des présentations

[zulu1]

-- contenu supprimé. Raison : post sans contenu -- zulu1

[el_slapper]

(.../...)
Je me suis déjà fait blasté au motif d'élitiste, mais je maintiens : l'agilité est faite pour des gens COMPETENTS et EXPERIMENTES..
(.../...)

compétents, de toutes façons, les pas compétents planteront un waterfall aussi surement, et n'oseront même pas faire du cowboy.

Expérimentés, ça aide, c'est sur. Mais je connais des gens qui, à peine diplômes, étaient parfaitement opérationnels dans un environnement hostile ou il leur fallait être, par défaut, agile. Sans jamais que le mot soit prononcé.

Non, le souci que moi je vois, c'est que dans un projet agile, le pouvoir est en bas de la pyramide hiérarchique : les utilisateurs finaux et les développeurs sont ceux qui créent de leur mains, et la hiérarchie est juste là pour leur trouver des machines et un réseau qui marche. Et ça, dans bien des structures, c'est inacceptable. Si le chef n'a pas le pouvoir de jouer au petit chef, alors il va tout faire pour reconquérir se pouvoir. Et donc empêcher la démarche agile de se déployer correctement.

[Luckyluke34]

Le Manifeste est ANTINOMIQUE d'une méthodologie quelconque..

Pas tellement d'accord. Ca reviendrait à dire que la pensée est antinomique de l'action, que le principe est antinomique de son application concrète et formalisée.

Parmi les auteurs du manifeste agile, au moins 4 ont par la suite ou avaient déjà créé leur propre méthodologie et tenté de la diffuser, preuve qu'ils étaient loin d'estimer qu'il ne pouvait pas y avoir de cadre concret et prescriptif à ces idées. Maintenant c'est vrai qu'ils souhaitaient ces processus les plus légers possibles. Le manifeste était d'ailleurs un groupe de réflexion sur les lightweight methods avant que le nom Agile soit choisi.

Je me suis déjà fait blasté au motif d'élitiste, mais je maintiens : l'agilité est faite pour des gens COMPETENTS et EXPERIMENTES..

Compétents et expérimentés en quoi ? En technique ? En recueil de besoins ? En organisationnel ? Tout cela peut s'acquérir à condition qu'on se pose les bonnes questions.

Je dirais plutôt que l'agilité est faite pour des gens qui sont conscients d'avoir des problèmes auxquels l'agilité répond, et veulent s'améliorer.

XP, Scrum, etc, ne devraient pas exister ou être suivis... Il ne devrait pas y avoir de personnes "Scrum Master". Juste des rôles... mais la même personne peut être Master sur un projet et autre chose sur un autre projet..

Le mot Master est sans doute maladroit, mais il correspond bel et bien à un rôle avec des tâches définies. Scrum ne dit nulle part que le Scrum Master doit être le même de projet en projet.

Les gens qui me connaissent ici connaissent ma position, et je ne peux que me désespérer qu'une excellente pratique soit la cible de critiques infondées, simplement parce qu'on a voulu l'appliquer à tout et n'importe quoi avec n'importe qui..

Absolument, mais c'est aussi vrai pour les méthodologies agiles que les valeurs et principes du manifeste lui-même.

[souviron34]

Expérimentés, ça aide, c'est sur. Mais je connais des gens qui, à peine diplômes, étaient parfaitement opérationnels dans un environnement hostile ou il leur fallait être, par défaut, agile. Sans jamais que le mot soit prononcé.

Ce que je voulais dire, ça n'est pas pour les éléments, mais les pivots de la démarche (le "master" ou je sais pas comment on appelle ça, etc etc ).. Le "backbone" de l'équipe..

Non, le souci que moi je vois, c'est que dans un projet agile, le pouvoir est en bas de la pyramide hiérarchique : les utilisateurs finaux et les développeurs sont ceux qui créent de leur mains, et la hiérarchie est juste là pour leur trouver des machines et un réseau qui marche. Et ça, dans bien des structures, c'est inacceptable. Si le chef n'a pas le pouvoir de jouer au petit chef, alors il va tout faire pour reconquérir se pouvoir. Et donc empêcher la démarche agile de se déployer correctement.

Encore une fois, je pense que c'est parce qu'on parle de "méthodologie de projet" et non d'approche..

Dans l'approche, la hiérarchie est intégrée.. (j'ai par exemple moi-même donné des présentations au Conseil d'Administration des entreprises):


Mais si on parle de méthodologie de projet informatique, on se limite à l'équipe informatique, et DONC on a des problèmes de hiérarchie..

Pas tellement d'accord. Ca reviendrait à dire que la pensée est antinomique de l'action, que le principe est antinomique de son application concrète et formalisée.

Relis les Principes..

Si tu y vois quoi que ce soit d'écrit dans le marbre, dis-le moi

Parmi les auteurs du manifeste agile, au moins 4 ont par la suite ou avaient déjà créé leur propre méthodologie et tenté de la diffuser, preuve qu'ils étaient loin d'estimer qu'il ne pouvait pas y avoir de cadre concret et prescriptif à ces idées. Maintenant c'est vrai qu'ils souhaitaient ces processus les plus légers possibles.

La plupart étaient Américains, et chez les Américains c'est souvent la manière de faire (du business et/ou de la technique)

Mais ça ne veut pas dire qu'ils ont eu raison de le faire (et d'ailleurs 4 personnes ont donné 4 méthodologies différentes...)
(plus voir la suite)

Compétents et expérimentés en quoi ? En technique ? En recueil de besoins ? En organisationnel ? Tout cela peut s'acquérir à condition qu'on se pose les bonnes questions.

Je dirais plutôt que l'agilité est faite pour des gens qui sont conscients d'avoir des problèmes auxquels l'agilité répond, et veulent s'améliorer.

Tu vois, il y a un mois j'ai re-rencontré un groupe d'ergonomes et d'ingénieurs avec qui j'avais travaillé à l'époque, et tous m'ont dit que cela avait été leur meilleure expérience et projets..

La clef du succès est dans l'informalité et l'adaptivité...

C'est pour ça que ça marche BEAUCOUP mieux avec des gens compétents et expérimentés.. Que l'on entraîne un groupe d'individus moins expérimentés dans la démarche, oui, bien sur.. Avec enthousiasme.. Mais les moteurs doivent justement pouvoir se passer d'un formalisme...

Et c'est là que la méthodologie "bloque" le processus... Comme on le voit dans la réalité, et dans bon nombre de posts et de retours d'expérience.. On va de l'anarchie à des buzzwords non appliqués..


Maintenant, je suis d'accord avec toi, mais pour être conscient des problèmes auxquels l'agilité répond, il faut avoir une certaine expérience des échecs des autres approches, du ressenti du pourquoi et comment ça a foiré..

Le mot Master est sans doute maladroit, mais il correspond bel et bien à un rôle avec des tâches définies. Scrum ne dit nulle part que le Scrum Master doit être le même de projet en projet.

Alors pourquoi les gens mettent-ils sur leur CV "Scrum Master" et pourquoi y a t-il des offres d'emploi "Scrum Master" ?????

Absolument, mais c'est aussi vrai pour les méthodologies agiles que les valeurs et principes du manifeste lui-même.

Tout à fait...

Et c'est désespérant...

[Logan Mauzaize]

Alors pourquoi les gens mettent-ils sur leur CV "Scrum Master" et pourquoi y a t-il des offres d'emploi "Scrum Master" ?????

Pour les mêmes raisons qu'on demande un développeur d'une techno, un architecte, CP technique, etc. Au final ce n'est pas 100% du temps, ni même les fonctions assurées quelques semaines plus tard.

[corydon]

Il suggère que les équipes de développement suivent leur propre voie avec des méthodes qui font participer tout le monde, mais qui n’accordent pas la priorité au délai dans les discussions. Il insiste sur le fait que tout le monde doit participer, et si des personnes doivent être exclues, il faut exclure les gestionnaires. Il suggère également de livrer le logiciel seulement quand il est prêt, ni avant, ni après. Le coût de livraison du mauvais produit est beaucoup plus élevé que le coût de prolongement des délais pour livrer le bon produit, rappelle-t-il.

Il me semble que ces suggestions sont passablement agiles.

[Jitou]

Il pense qu’Agile n’est seulement profitable qu’aux sociétés de conseil, qui doivent faire un prototype rapide pour un client qui ne sait pas vraiment ce qu’il veut, et qui facturent sur une base temporelle. Ces dernières sont ainsi prêtes à accepter n’importe quelle idée avec laquelle vient le client, étant donné que cela signifie un délai plus long, donc plus de revenus.

Exactement ce que je vis de mission en mission depuis que Agile c'est immiscé dans les projets à l'initiative des décideurs qui ont parfaitement compris comment l'exploiter. On va d'abord dire au développeur que c'est une super méthode cool et tendance que tous le monde doit maintenant appliquer afin d'organiser ses projets selon cette méthode, il dit ensuite exactement la même chose au client et de fait n'a plus jamais à justifier tous les dépassements de budget puisque avec agile on est quoique arrive dans les clous puisqu'on n'arrive jamais là où le client l'avait définit au départ ... résultat le devoir de conseil passe définitivement à la trappe et le client pilote techniquement son projet et s'improvise architecte des applicatifs de son SI.

[Laurent 1973]

Exactement ce que je vis de mission en mission depuis que Agile c'est immiscé dans les projets à l'initiative des décideurs qui ont parfaitement compris comment l'exploiter. On va d'abord dire au développeur que c'est une super méthode cool et tendance que tous le monde doit maintenant appliquer afin d'organiser ses projets selon cette méthode, il dit ensuite exactement la même chose au client et de fait n'a plus jamais à justifier tous les dépassements de budget puisque avec agile on est quoique arrive dans les clous puisqu'on n'arrive jamais là où le client l'avait définit au départ ... résultat le devoir de conseil passe définitivement à la trappe et le client pilote techniquement son projet et s'improvise architecte des applicatifs de son SI.

Ben oui, tu as tout compris, c'est le but de l'Agilité: mettre le client au centre de développement logiciel.
C'est bien lui qui décide de quoi il veux et dans quel ordre.

C'est lui qui pilote SON projet ...enfin.
Plus un "petit" chef qui n'a aucune idée de ses contraintes métiers.
Et finalement, le client paye réellement que ce qu'IL a choisi, pas ce que le "petit" chef a décidé.
Le conseil? et bien c'est l'équipe qui lui donne en fonction de ses choix, ses besoins, ses contraintes.
Et si le client n'est pas content du travail effectué, et bien il arrête l'équipe, il récupère les sources et trouve une nouvelle équipe plus compétente.

Du coté fournisseur on s'y retrouve aussi mieux vu que l'on est pas obligé de respecter un contrat figé parfois stupide qui impose des heures non prévu (et donc non facturées).
Les factures reflètent le travail effectué et le client est plus satisfait: tout le monde y gagne.

Bon, là, j'évoque que le coté "commercial" de l'agilité.
Pour que cela fonctionne vraiment, il faut aussi que l'équipe de développement ait réellement les moyens de travaillé en Agile.
C'est à dire: auto-organisation, lien direct avec les utilisateurs (d'où le conseil), amélioration continu, choix technique émergeant des équipes, ...

Pour cela, il faut que le management de l'entreprise accepte de lâcher un peu de pouvoir décisionnel à cette même équipe.
Et là, c'est pas toujours gagner, le conservatisme de certain "petit" chef à encore de long jour devant lui.

[Luckyluke34]

Relis les Principes..

Si tu y vois quoi que ce soit d'écrit dans le marbre, dis-le moi

"Les principes du manifeste agile ne sont pas écrits dans le marbre.
Les méthodologies Scrum, XP, etc. sont écrites dans le marbre.

Les méthodologies Scrum, XP ne sont pas agiles"

C'est un syllogisme pour moi. Ce n'est pas parce que des principes sont formulés de manière générique et conceptuelle qu'ils ne peuvent pas être traduits et parfaitement respectés dans une méthodologie formalisée.

Alors pourquoi les gens mettent-ils sur leur CV "Scrum Master" et pourquoi y a t-il des offres d'emploi "Scrum Master" ?????

Deuxième non sequitur

"Scrum ne dit pas que la même personne devrait être Scrum Master de projet en projet.

Personne ne devrait être Scrum Master de projet en projet"

...

[vinmar]

Je rejoint certain posts : vouloir mettre l'Agilité a toutes les sauces dans tous les contextes est une bêtise. Vouloir appliquer une méthode parce qu'elle est déclarée par certain comme universelle est une bêtise. Déclarer une méthode comme universelle est une bêtise.

Faire de l'agilité au sein d'une entreprise qui développe son propre logiciel (application métier interne, etc.) en dehors de considérations de deadline (ou autres critères propres au pendant commercial) me parait complétement faisable.
Faire de l'agilité au sein d'une SSII qui de toute manière fait passer la rentabilité avant la qualité, autant changer de méthode.

Chaque environnement délimite un périmètre qui lui est propre : priorité à l'argent, priorité à la qualité, priorité à la sécurité, etc... Il n'y a pas de schémas vertueux, il y a une multitude de mondes différents et l'Agilité ne peut être la solution idéale pour tous ces environnements.

[souviron34]

Pour que cela fonctionne vraiment, il faut aussi que l'équipe de développement ait réellement les moyens de travaillé en Agile.
C'est à dire: auto-organisation, lien direct avec les utilisateurs (d'où le conseil), amélioration continu, choix technique émergeant des équipes, ...

Pour cela, il faut que le management de l'entreprise accepte de lâcher un peu de pouvoir décisionnel à cette même équipe.
Et là, c'est pas toujours gagner, le conservatisme de certain "petit" chef à encore de long jour devant lui.

C'est bien pour ça que je prône depuis des lustres une tête bicéphale : un utilisateur-expert reconnu par ses pairs ET un CP technicien généraliste..

...

Ce que je veux dire, c'est que ce sont des PRINCIPES...

Au même titre que "Liberté, Egalité, Fraternité"..

Les méthodologies sont au Manifeste ce que la loi française est à ces principes fondateurs..


Or, à l'inverse de la loi qui balise les écarts aux Principes, mais ne dit pas comment les suivre, les méthodologies essayent de dire comment les suivre...

C'est fondamentalement biaisé et faux...

[bmayesky]

C'est impressionnant comment un article complété de ses commentaires peut résumer la situation du développement informatique.

Remettre autant en cause Agile n'est pas utile. Pas pour se rendre compte qu'un projet est attendu à une date fixée afin que l'entreprise fonctionne normalement hors de l'informatique. Pas plus pour découvrir qu'aucune méthode n'est parfaite.

Alors que disent tout ces commentaires qui n'épargnent ni la direction, les gestionnaires et les incompétents (voir les débutants) du développement, bref tout le monde ? Simplement que l'élément essentiel est l'ensemble des personnes engagées sur le projet, leurs motivations, leurs compétences et non une méthode.
Méthode qui, pour fonctionner et rendre le résultat attendu à tous les coups, suppose toujours des humains parfaits. Ce n'est jamais le cas ! (*)

Renversons donc le paradigme consistant à appliquer une méthode de projet à priori et à ajuster les personnes dedans pour chercher à ajuster vos méthodes de projet aux personnes et à l'environnement de votre projet.
Alors vous chercherez la meilleure solution à chaque étape de votre projet au lieu de résoudre les problèmes d'inadéquation entre votre méthode et votre environnement humain.

(*): un parallèle intéressant est à faire avec les théories économiques qui échouent à prévoir l'avenir (tout autant que les méthodes de projets) parce qu'elles se basent sur un consommateur parfait (Cf le concept d'écône et le "nudge").

[dacid]

A mettre dans vos favoris:
http://reflexiongestion.com/2013/12/...a-methodologie
:-)

[Laurent 1973]

C'est impressionnant comment un article complété de ses commentaires peut résumer la situation du développement informatique.

Remettre autant en cause Agile n'est pas utile. Pas pour se rendre compte qu'un projet est attendu à une date fixée afin que l'entreprise fonctionne normalement hors de l'informatique. Pas plus pour découvrir qu'aucune méthode n'est parfaite.

Alors que disent tout ces commentaires qui n'épargnent ni la direction, les gestionnaires et les incompétents (voir les débutants) du développement, bref tout le monde ? Simplement que l'élément essentiel est l'ensemble des personnes engagées sur le projet, leurs motivations, leurs compétences et non une méthode.
Méthode qui, pour fonctionner et rendre le résultat attendu à tous les coups, suppose toujours des humains parfaits. Ce n'est jamais le cas ! (*)

Renversons donc le paradigme consistant à appliquer une méthode de projet à priori et à ajuster les personnes dedans pour chercher à ajuster vos méthodes de projet aux personnes et à l'environnement de votre projet.
Alors vous chercherez la meilleure solution à chaque étape de votre projet au lieu de résoudre les problèmes d'inadéquation entre votre méthode et votre environnement humain.

(*): un parallèle intéressant est à faire avec les théories économiques qui échouent à prévoir l'avenir (tout autant que les méthodes de projets) parce qu'elles se basent sur un consommateur parfait (Cf le concept d'écône et le "nudge").

Et oui, l'important dans un projet (informatique ou autre) c'est l'humain

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Tiens, c'est surprenant: on en parle dans la première valeur de l'Agile Manifesto

[weberan]

Bonjour,

Ce qui m'amuse c'est que ici comme ailleurs, on assiste au cycle par lequel passe toute nouveauté: d'abord on est réticent, puis on trouve ça génial, on l'applique, on obtient des résultats qui ne sont pas à la hauteur des espérances, et finalement on trouve que c'est de la merde et on la jette. (Je schématise un peu). Il est quand même remarquable que c'est maintenant que la méthode Agile commence à être largement adoptée (sans doute souvent sans en respecter l'esprit) que l'on commence à voir passer des critiques négatives. Ceci dit en passant, je trouve très bien que les opinions critiques puissent enfin s'exprimer.

Je pense qu'au delà de l'observation de ce type de cycle, il faudrait s'interroger sur la démarche qui nous pousse à toujours adopter des nouveautés. Derrière cela il y a aussi un cycle qui part d'une vision pessimiste pour se réfugier dans des espoirs démesurés. L'effet de cette démarche est que on travaille toujours avec des méthodes et des outils non-éprouvés. Il serait quand même plus sein d'adopter une démarche de progression basée sur l'existant plutôt que de sans cesse jeter ce que l'on a pour adopter des nouveautés dont on sera déçus dans quelques années.

Salut,

André

[souviron34]

Bonjour,

Ce qui m'amuse c'est que ici comme ailleurs, on assiste au cycle par lequel passe toute nouveauté: d'abord on est réticent, puis on trouve ça génial, on l'applique, on obtient des résultats qui ne sont pas à la hauteur des espérances, et finalement on trouve que c'est de la merde et on la jette. (Je schématise un peu). Il est quand même remarquable que c'est maintenant que la méthode Agile commence à être largement adoptée (sans doute souvent sans en respecter l'esprit) que l'on commence à voir passer des critiques négatives. Ceci dit en passant, je trouve très bien que les opinions critiques puissent enfin s'exprimer.

Je pense qu'au delà de l'observation de ce type de cycle, il faudrait s'interroger sur la démarche qui nous pousse à toujours adopter des nouveautés. Derrière cela il y a aussi un cycle qui part d'une vision pessimiste pour se réfugier dans des espoirs démesurés. L'effet de cette démarche est que on travaille toujours avec des méthodes et des outils non-éprouvés. Il serait quand même plus sein d'adopter une démarche de progression basée sur l'existant plutôt que de sans cesse jeter ce que l'on a pour adopter des nouveautés dont on sera déçus dans quelques années.

Salut,

André

Cachez-le

Sain serait mieux, sans doute, dans ce contexte

Maintenant, je suis tout à fait d'accord avec toi, et c'est un peu ce que je me tue à dire depuis au moins 8 ans sur ce forum..


Et j'ai déjà vilipendé et la déification faite à l'OO (en jetant au rebut le procédural), et la déification faite a l'agilité (sans avoir intégré ce que c'était que la cascade ou le V), ou aux langages formels, etc etc...

C'est exactement à ça que je faisais référence en citant des "expérimentés". Des personnes qui savent POURQUOI et COMMENT le V foire, dans quel contexte, et sont donc aptes à saisir en quoi les PRINCIPES de l'agilité s'appliquent (ou non).


Je dénonce dans ces pages régulièrement exactement ce que tu dis, une "comsumérisation jeuniste" de tout, forçant ce qui a plus de X années à être obsolète et barbare, dinosauresque; et érigeant en prochain Dieu le nouveau mot-clé, la nouvelle tendance marketing..

C'est comme les "nouvelles" discussions sur l'IA.. Ca fait 40 ans que j'entends ça, mais avec Internet, les forums, les formations, etc, d'un seup coup, ben oui, c'est demain.. Comme le Cloud, les TDD, les patterns, l'open-source, les bibliothèques tierces, les grands nombres, les Frameworks, ....


Aucun recul, et aucune pondération... On s'engouffre, on dit "avec ça tout va marcher comme sur des roulettes".. "nous on a la Vérité, ceux d'avant ou qui doutent sont des idiots", Et on s'étonne de se planter.. ou de ne pas arriver à la panacée.. Comme les infos : de la consommation, sans plus..

On passe de déification en déification...

Et donc on brûle les icônes d'hier...


Sans avoir pris le temps de les comprendre et intégrer... Avec l'Agile, c'est encore plus évident...

[el_slapper]

(.../...)
Sans avoir pris le temps de les comprendre et intégrer... Avec l'Agile, c'est encore plus évident...

Oui, parce qu'être agile, dans sa définition initiale, c'est tout sauf suivre aveuglément le petit manuel. Et qu'à chaque fois que j'ai fait de l'agile, ce mot n'était pas prononcé. Cette manière de penser s'était imposée naturellement dans le process. A chaque fois que le mot a été prononcé, c'était pour imposer des méthodes à suivre scrupuleusement(les petits post-its sur le tableau, c'est bien gentil, mais ça n'arrive pas à la cheville d'un bon Trello. Et quand le périmètre est prédeterminé et n'a aucune raison de changer, franchement, c'est s'emmerder pour rien).

[RedGuff]

Agile place les commerciaux au dessus des développeurs, et c'est pour cela qu'il y a des problèmes