Discussion :

[Arsene Newman]

L’esprit agile est-il en voie de disparaître ?
13 ans après la publication du manifeste agile, un développeur note l’échec des méthodes agiles

Tout professionnel de l’IT s’accorde à dire que le développement logiciel n’est pas une mince affaire. Par le passé, cela reposait essentiellement sur des méthodes et des processus de développement lourds, rigides et coûteux, qui conduisaient à des cycles de développement assez lents. En 2001 le manifeste agile a été publié. Ce dernier décrit une nouvelle approche, une nouvelle famille de méthodes de développement logiciel dites « méthodes agiles ».

Toutefois, ce manifeste décrit les grandes lignes pour des méthodes de développement axées sur le développeur, la collaboration étroite entre l’équipe de développement et le client ainsi que l’importance du feedback des utilisateurs.

13 ans plus tard, force est de constater que les méthodes agiles ont échoué. C’est en tout cas ce que pense Mike Hadlow, un développeur senior, dans un billet de blog. Mais alors pourquoi cet échec ? Une dérive, une incompréhension ou encore un abus serait à l’origine de l’échec, selon celui-ci.

Agile est en premier lieu un état d’esprit mettant au centre de la scène le développeur, chacun doit trouver son propre rythme en suivant un chemin balisé par des méthodes connues. Il ne s’agit donc pas de méthodes de management de l’équipe de développement ni de recourir d’une manière bête et disciplinée à certaines pratiques telles que les stand-up meeting journalier, à de courtes itérations de 2 semaines et à de micro deadlines trop rigides.

Une des conséquences de la mauvaise interprétation/application des concepts agiles est la désignation de chefs de projet non sensibles à l’aspect technique du développement logiciel, ces derniers étant alors initiés aux méthodes agiles en les considérant à tort comme des méthodes de management.

En effet quoi de mieux qu’un développeur pour en comprendre un autre ? Hors si les méthodes agiles se targuent d’être centrées sur le développeur et que le chef de projet n’est pas dans cette dynamique, cela conduira inévitablement à l’échec. Dans le cas contraire, cela relève de la chance ou d'autres facteurs, mais certainement pas de l’application d’une méthode agile.

Au final, il demeure clair que la réussite de la mise en œuvre d’une méthode agile passe en premier lieu par une bonne compréhension des aspects techniques du développement, de la capacité du chef de projet à sympathiser avec le développeur et à le motiver, faute de cela, les méthodes agiles subsisteront, mais l’esprit agile sera en perdition et finira par mourir.

Source : blog de Mike Hadlow

Et vous ?

Qu’en pensez-vous ?

[el_slapper]

Pas grand chose. En football, on se doute bien qu'aligner 11 chèvres avec la meilleure tactique du monde ne suffira pas à battre le PSG. En informatique, par contre, ça parait évident. Et, à la fin, c'est le PSG qui gagne.

Plus sérieusement(en en espérant ne pas voir des hordes d'antiparisiens venir m'étriper, à une époque, c'est l'OM qui était difficille à battre, à une autre l'OL, etc...), l'article pointé en lien est très bien. On est pas forçé d'être d'accord sur tout(il me semble un poil extrême sir les estimations), mais il me plait beaucoup, et il fait un état des lieux (hélas) fort précis. Sa liste à points est très interessante :

•(1)The skills and talents of individual programmers are the main determinant of software quality. No amount of management, methodology, or high-level architecture astronautism can compensate for a poor quality team.
•(2)The motivation and empowerment of programmers has a direct and strong relationship to the quality of the software.
•(3)Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver.
•(4)The consequences of poor design decisions multiply rapidly.
•(5)It will usually take multiple attempts to arrive at a viable design.
•(6)You should make it easy to throw away code and start again.
•(7)Latency kills. Short feedback loops to measurable outcomes create good software.
•(8)Estimates are guess-timates; they are mostly useless. There is a geometric relationship between the length of an estimate and its inaccuracy.
•(9)Software does not scale. Software teams do not scale. Architecture should be as much about enabling small teams to work on small components as the technical requirements of the software.

Tous sont débatables, mais j'adore les points 3, 6 et 7. Que je vais réinterpréter en Français
(3) Les dates de livraisons en dur, spécialement quand elles sont innombrables, flinguent le projet. Perso, je peux comprendre qu'il faille livrer la gestion de l'Euro avant le 31 Décembre 2012. Mais quand une directrice de projet exige des preuves de progrès deux fois par jour, et par conséquent des respects de dates de livraisons systématiques et multiquotidiennes, on passe son temps à planifier, pas à bosser.
(6) Le code n'est pas sacré : il faut pouvoir tout balancer et tout recommencer sans avoir l'impression de se tirer une balle dans le pied. Mon opinion : on fait souvent fausse route, donc un demi-tour facile est essentiel.
(7) La latence tue. Des retours d'information rapides sont indispensables pour réaliser un bon projet. Toujours d'accord, toujours pour la même raison : on faut souvent fausse route, et mieux vaut s'en apercevoir au bout de 2 jours qu'au bout de 2 ans.

J'ajouterais juste qu'un manager non-technique peut être utile, mais à condition d'avoir parfaitement intégré son incompétence technique. Si il passe son temps à animer l'équipe, à chercher quels sont les obstacles et comment les aplanir, a vérifier que tout le monde reste dans le périmètre, et que globalement les gens avancent, alors il peut être très utile. J'en ai vu. Manque de pot, la plupart tentent de tout contrôler(pour asseoir leur pouvoir), et le résultat est celui décrit par le bloggueur.

[Traroth2]

Après avoir vu diverses tentatives plus ou moins honnêtes de mise en oeuvre de Scrum, force est de constater que c'est vrai. Le problème de base, c'est que l'agilité cherche à mettre le développeur au centre du processus de développement. Et ça, malheureusement, personne dans le management de la DSI, à fortiori de l'entreprise, n'en a envie. Le point de vue réel est de considérer les développeurs comme des pions interchangeables, des "ressources". Et là, en réalité, on est aux antipodes de l'agilité. Les méthodes agiles servent aussi de prétexte à tout un tas de mauvaises pratiques, par exemple l'absence de specs.

Typiquement : https://en.wikipedia.org/wiki/Avalanche_model

[transgohan]

J'en pense qu'Agile n'est pas prêt de disparaître du jour au lendemain.
Le seul problème de cette méthode c'est quand on ne joue pas le jeu.
Managers qui font du cycle en V, maitrise d'oeuvre qui fait du cycle en V et développeurs qui font de l'agile.
L'une des combinaison qui va faire échouer un projet...

Cela fait un an que nous avons quitté le cycle en V dans mon équipé pour partir sur de l'Agile (à la demande du PDG).
Nous avons vu de nombreuses améliorations de notre process et de notre qualité suite à l'application de ces méthodes.
Mais le boulet que l'on traîne c'est que les managers ont été formés après nous (voir pas du tout) et font toujours du cycle en V...
Et même s'ils sont formés ils n'adhèrent pas à la méthode car ils comprennent bien qu'ils ont un engagement qu'ils n'avaient pas avant...
Sont pas fous ! Si ça merde c'est leur faute maintenant.

Bref c'est le même principe que de tenter de parler chinois à un français.
S'il ne comprend pas le chinois c'est peine perdu...

Les méthodes agiles servent aussi de prétexte à tout un tas de mauvaises pratiques, par exemple l'absence de specs.

Ce n'est pas un problème des méthodes agiles selon moi mais un problème de mauvaise utilisation de ces méthodes.

[Traroth2]

Ce n'est pas un problème des méthodes agiles selon moi mais un problème de mauvaise utilisation de ces méthodes.

Ah oui, complètement. Il faut quand même en tenir une couche pour ne pas se rendre compte que des specs, c'est indispensable (mais pas suffisant) pour qu'un projet ait la moindre chance de bien se passer.

[antoinev2]

Ah oui, complètement. Il faut quand même en tenir une couche pour ne pas se rendre compte que des specs, c'est indispensable (mais pas suffisant) pour qu'un projet ait la moindre chance de bien se passer.

Oui voilà, finalement c'est sans doute plus un problème de personne que de méthodologie.

Oui c'est un échec du dev, c'est en effet lui qui n'a pas su être agile...
En effet, la charge de la tâche est estimée par le DEV !
Le fait de prendre ou non la tâche dans le sprint est aussi de la responsabilité du DEV !
Bref si à la fin il s'est engagé sur cela et qu'il n'a pas réussi sa mission c'est donc de sa faute.

Tu parles de sprint, donc d'application de la méthode, mais combien de MOA, décideurs, clients (et commerciaux!) connaissent et savent comment appliquer la méthode?
Ils ont entendu parler d'agilité, de post-it, d'effet tunnel et de réactivité, rarement plus.
Les MOA dont je parle se cachent derrière le concept d'agilité pour justifier l'absence de méthode.
Quand bon nombre de points de l'application restent flous, parce qu'on a posé la question au chef de projet qui n'a pas de réponse, on dit qu'il faut être agile. C'est pratique...

Là où ça rejoint ce que dit Traroth2, c'est qu'on n'a pas non plus :
de communication entre tous les acteurs impliqués (plusieurs directions chez le client, plusieurs applications impactées donc plusieurs MOA, plusieurs TMA...)
de recette ("Mais on n'en a pas besoin...")
de bonne volonté de tous les acteurs (entre ceux qui sont incompétents, ceux qui n'ont aucun intérêt à ce que le projet aboutisse et ceux pressés de facturer...)

[Luckyluke34]

Rien de bien nouveau sous le soleil. En 2008 et 2009, on dressait déjà le constat d'un échec massif de l'agilité car les aspects techniques n'étaient pas pris en compte, "Flaccid Scrum"...) Le mouvement Software Craftsmanship s'est construit à la même époque en réponse à cette tendance.

Le problème quand on dit "les méthodes agiles ont échoué" c'est que
1) on suppose que toutes les méthodes sont les mêmes à la base alors qu'il en existe de très différentes, dont certaines qui incluent des pratiques techniques et n'ont pas été si largement appliquées (XP pour ne pas le citer) et
2) on personifie des process alors que ceux qui ont échoué, c'est plutôt les gens qui ont essayé de les mettre en application sans comprendre les concepts sous-jacents ou "parce que c'est à la mode", sans même se demander si l'agilité répondait à leurs problèmes en premier lieu...

J'ai l'impression que l'auteur se tire une balle dans le pied avec ce titre, car il accepte le déplacement de l'étiquette "agile" sur un package qui n'a plus grand chose à voir avec l'esprit du manifeste d'origine. C'est un peu comme s'il appliquait son précepte "You should make it easy to throw away code and start again." à l'agilité. Je ne suis pas fan de jeter ainsi le bébé avec l'eau du bain, car oui il y a des équipes qui réussissent avec Agile, et accepter qu'on vide ainsi une approche de son sens, c'est renoncer un peu trop facilement à mon goût.

[gangsoleil]

Le problème quand on dit "les méthodes agiles ont échoué" c'est que
1) on suppose que toutes les méthodes sont les mêmes à la base alors qu'il en existe de très différentes, dont certaines qui incluent des pratiques techniques et n'ont pas été si largement appliquées (XP pour ne pas le citer) et
2) on personifie des process alors que ceux qui ont échoué, c'est plutôt les gens qui ont essayé de les mettre en application sans comprendre les concepts sous-jacents ou "parce que c'est à la mode", sans même se demander si l'agilité répondait à leurs problèmes en premier lieu...

J'ai l'impression que l'auteur se tire une balle dans le pied avec ce titre, car il accepte le déplacement de l'étiquette "agile" sur un package qui n'a plus grand chose à voir avec l'esprit du manifeste d'origine. [...] Je ne suis pas fan de jeter ainsi le bébé avec l'eau du bain, car oui il y a des équipes qui réussissent avec Agile, et accepter qu'on vide ainsi une approche de son sens, c'est renoncer un peu trop facilement à mon goût.

Il y a des equipes qui reussissent avec Agile ne veut pas dire pour autant que ce terme n'est pas galvaudé aujourd'hui. Oui, aujourd'hui les entreprises "font de l'agile" parce que c'est vendeur aupres des clients, et non plus parce que ce sont des bonnes pratiques qu'il pourrait etre bon de chercher a appliquer au sein de l'entreprise pour obtenir de meilleurs resultats.

En ce sens, je suis d'accord avec l'auteur pour dire qu'on devrait jeter Agile, ce qui ne veut pas dire qu'il faut jeter les vrais principes qui forment sa base ou une partie de ce que c'est sensé être.

[Et pour chipoter, XP est plus vieux qu'Agile, donc jeter Agile ne veut pas dire jeter l'XP]

[Kropernic]

Ah oui, complètement. Il faut quand même en tenir une couche pour ne pas se rendre compte que des specs, c'est indispensable (mais pas suffisant) pour qu'un projet ait la moindre chance de bien se passer.

Je me sens obligé de poster un petit quelque chose en réponse à ceci car c'est qu'il se passe pour presque tous nos projets là où je bosse. Bon ok, il ne s'agit pas d'une boite d'informatique et nous développons donc uniquement pour un usage interne. Mais n'empêche, quand on te dit qu'il faut développer un nouvel outil pour gérer les promotions du magasin pour faciliter l'encodage desdites promotions dans le système caisse et que ça doit être près pour dans 2 mois, y a de quoi tirer la tronche. Heureusement, on a réussi à avoir un délai supplémentaire de 2 semaines .

Et tout ça donc sans aucun cahier des charges. Juste une réunion où on te présente vaguement ce qui existe actuellement (à base de fichier excel). A toi de te démerder pour comprendre toutes les mécaniques sous-jacentes en posant les questions (ça j'ai quand même le droit de faire ^^) qui vont bien aux bonnes personnes (histoire d'avoir les bonnes réponses).

C'est pareil pour les autres dev qui ne sont pas dans une boite de service ?

[Carhiboux]

Merci d'avoir corrigé le titre, cela me piquait horriblement les yeux (oui je sais hôpital, charité, je fais aussi des fautes ).

Les principaux défauts des méthodes agiles à mon sens sont :

1) Que ça ne marche que sur les petites équipes. Au delà de ... allez... 6-7 personnes, c'est difficile à maintenir.

2) Que comme dit dans l'article, les chefs de projets confondent agilité avec méthodologie de management rigide.

3) Le client n'est pas toujours disposé à jouer le jeu. Le concept le séduit de prime abord, mais il se rends ensuite compte de la charge de travail hebdomadaire et il finit par ne plus forcément faire sa part. Alors que dans un projet classique, il travaillera tout autant, mais de manière moins planifiée... Mais il préférera souvent parce qu'il aura certainement l'impression d'être moins "contraint".

[Njörd]

Bonjour,

Je pense également qu'il faut laisser du temps pour que de nouvelles entreprises apparaissent sur notre marché (donc compter quelques 20 à 30 années pour que ce soit dans les mœurs, aussi bien du côté entreprise que côté client). Nouvelle entreprise, donc plus facile de mettre en place les méthodes agiles en partant de zéro.

Le problème, bien souvent, c'est le changement. On rechigne toujours. Dans les entreprises ayant déjà leur culture et leur façon de fonctionner, ça me paraît très difficile (mais pas impossible) de mettre en place les méthodes agiles. Rien que les jeux de pouvoir suffisent à empêcher le changement.

[leminipouce]

Qu’en pensez-vous ?

Précisément l'inverse !
Je pense au contraire que l'esprit agile est en train de prendre. Mais je reste lucide en citant un bon vieil adage français : Rome ne s'est pas faîte en un jour.
Petit historique pour rire :

• 2001 : rédaction du manifest agile.
• 2002 : je commence les cours. On m'y parle de cycle en V, des méthodes Merise et MACAO (une méthode itérative) mais pas d'agilité. Bien que MACAO s'inspire d'XP, la notion même d'agilité n'est pas abordé.
• 2007/2008 : je réalise mon premier projet en mode agile avec Scrum.
• ~2011/2012 (si je ne me trompes pas) : l'agilité rentre dans les gênes de boîtes avec un fort rayonnement. Je pense par exemple à Xebia en France, mais ils ne sont pas les seuls. D'autres structures, plus petites, moins connues prennent également cette direction.
• 2013 : appel d'offres publiques du Ministère de l'agriculture qui prévoit l'agilité comme méthode de travail dans ce marché.
• ...

Il reste énormément de gens qui ne connaissent pas l'agilité ou n'y comprenne rien. D'autres qui y sont tout simplement réfractaires. Après 10, 15, 20 ans ou plus à travailler d'une façon, difficile de se remettre en cause, d'accepter de nouveau préceptes, de nouvelles façon de travailler, ... Difficile aussi de reconnaître que les méthodes existantes et utilisées par le passé ont conduit à de nombreux échecs !

Mais aujourd'hui, les jeunes qui sortent des écoles savent ce qu'est l'agilité. La culture informatique parle d'agilité. Les consultants qui vont et viennent d'une ESN à une autre sont petit à petit passés par une case agile ou semi-agile. Parfois même y ont trouvé un intérêt... et cherche à le reproduire. Les décideurs savent qu'ils peuvent tirer des bénéfices de l'agilité et ne veulent pas rester en marge de ce qui se fait dans le monde, dans les grandes entreprises, dans les structures qui marchent. Les ESN cherchent un modèle qui soit économiquement plus intéressant, plus fiable, ... Bref même s'il faut du temps, je pense que l'agilité est en train de s'inviter, progressivement à la table de nombreux projets et croit, doucement, au fil des échecs et des réussites.

(6) Le code n'est pas sacré : il faut pouvoir tout balancer et tout recommencer sans avoir l'impression de se tirer une balle dans le pied. Mon opinion : on fait souvent fausse route, donc un demi-tour facile est essentiel.
(7) La latence tue. Des retours d'information rapides sont indispensables pour réaliser un bon projet. Toujours d'accord, toujours pour la même raison : on faut souvent fausse route, et mieux vaut s'en apercevoir au bout de 2 jours qu'au bout de 2 ans.

Justement, le manifeste Agile apporte des réponses à ces 2 problématiques :

La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

J'ajouterais juste qu'un manager non-technique peut être utile, mais à condition d'avoir parfaitement intégré son incompétence technique. Si il passe son temps à animer l'équipe, à chercher quels sont les obstacles et comment les aplanir, a vérifier que tout le monde reste dans le périmètre, et que globalement les gens avancent, alors il peut être très utile. J'en ai vu. Manque de pot, la plupart tentent de tout contrôler(pour asseoir leur pouvoir), et le résultat est celui décrit par le bloggueur.

C'est là tout le problème et un des points cruciaux de l'agilité. Reconnaître la valeur du développeur. Ou, en d'autres termes, pour le CP qui ne comprend rien à la technique, être capable de l'avouer/le reconnaître et faire confiance au dév.

[gangsoleil]

Les consultants qui vont et viennent d'une ESN à une autre sont petit à petit passés par une case agile ou semi-agile. Parfois même y ont trouvé un intérêt... et cherche à le reproduire. Les décideurs savent qu'ils peuvent tirer des bénéfices de l'agilité et ne veulent pas rester en marge de ce qui se fait dans le monde, dans les grandes entreprises, dans les structures qui marchent.

On voit aussi de l'agile appliqué de la sorte :
Toute tache dure 2 semaines au maximum --> Si le dev dit qu'il faut 10-12 jours, c'est 2 semaines. S'il dit qu'il faut 20 jours, on coupe le truc en deux, et on fait 2 taches de 10 jours. S'il repond 50, on fait 5 taches. Et avec 9 femmes, on fait un bebe en un mois, c'est bien connu.
Stand-up réunion tous les matins, ou chacun dit ce qu'il a fait la veille et ce qu'il fera dans la journée. --> Hier, j'ai chercher comment contourner le probleme machin. Heureusement, il y a la reunion de ce matin pour que je vous en parle, car je ne suis pas allé voir le specialiste du truc pour avancer, j'ai preferé merder dans mon coin. Et j'oublie aussi celui qui te raconte sa vie pendant la reunion.
Et bien sur des aller-retour avec le client --> Ah oui, mais le developpeur ne parle pas au client, tout doit absolument passer par le chef de projet, qui reformule (quitte a ne plus poser la bonne question) et envoie et transfert la reponse.

C'est là tout le problème et un des points cruciaux de l'agilité. Reconnaître la valeur du développeur. Ou, en d'autres termes, pour le CP qui ne comprend rien à la technique, être capable de l'avouer/le reconnaître et faire confiance au dév.

C'est toi qui parle de SSII et de reconnaitre la valeur du developpeur, avec des chefs de projets competents qui sont capables d'avouer qu'ils ne savent pas quelque chose et de faire confiance a l'analyse du developpeur ? Nous n'avons pas connu les memes SSII !

[LSMetag]

On voit aussi de l'agile appliqué de la sorte :
Toute tache dure 2 semaines au maximum --> Si le dev dit qu'il faut 10-12 jours, c'est 2 semaines. S'il dit qu'il faut 20 jours, on coupe le truc en deux, et on fait 2 taches de 10 jours. S'il repond 50, on fait 5 taches. Et avec 9 femmes, on fait un bebe en un mois, c'est bien connu.
Stand-up réunion tous les matins, ou chacun dit ce qu'il a fait la veille et ce qu'il fera dans la journée. --> Hier, j'ai chercher comment contourner le probleme machin. Heureusement, il y a la reunion de ce matin pour que je vous en parle, car je ne suis pas allé voir le specialiste du truc pour avancer, j'ai preferé merder dans mon coin. Et j'oublie aussi celui qui te raconte sa vie pendant la reunion.
Et bien sur des aller-retour avec le client --> Ah oui, mais le developpeur ne parle pas au client, tout doit absolument passer par le chef de projet, qui reformule (quitte a ne plus poser la bonne question) et envoie et transfert la reponse.

Dans ce que tu décrits, il n'y a pas forcément que des mauvais côtés. Si on sait bien structurer les dites tâches de 2 semaines (en agrégats de petites tâches reposant sur une même thématique) je ne vois pas de gros problème.
Les fameux points matinaux peuvent justement permettre de souligner rapidement des erreurs de la part d'un développeur ou lui donner des conseils pour mieux avancer (par exemple demander de l'aide à un tel).
Par contre, oui le développeur doit avoir un minimum de latitude. Le client doit également être un minimum compréhensif si on veut que ça se passe bien.

[el_slapper]

On voit aussi de l'agile appliqué de la sorte :
Toute tache dure 2 semaines au maximum --> Si le dev dit qu'il faut 10-12 jours, c'est 2 semaines. S'il dit qu'il faut 20 jours, on coupe le truc en deux, et on fait 2 taches de 10 jours. S'il repond 50, on fait 5 taches. Et avec 9 femmes, on fait un bebe en un mois, c'est bien connu.

En cycle en V, c'est souvent pareil, hein(sauf le découpage, encore que parfois, histoire de répartir la tâche.....).

Stand-up réunion tous les matins, ou chacun dit ce qu'il a fait la veille et ce qu'il fera dans la journée. --> Hier, j'ai chercher comment contourner le probleme machin. Heureusement, il y a la reunion de ce matin pour que je vous en parle, car je ne suis pas allé voir le specialiste du truc pour avancer, j'ai preferé merder dans mon coin. Et j'oublie aussi celui qui te raconte sa vie pendant la reunion.

Le peu que j'ai vu, ça marchait bien. Mais il est clair que si on laisse les gens s'installer, ça devient vite catastrophique. C'est à double tranchant, les stand-up. Quand le manager réunnionitique décide de la mener(alors qu'il n'a pas à le faire), c'est, en effet, mal barré.

Et bien sur des aller-retour avec le client --> Ah oui, mais le developpeur ne parle pas au client, tout doit absolument passer par le chef de projet, qui reformule (quitte a ne plus poser la bonne question) et envoie et transfert la reponse.

Ca, c'est le point le plus fondamental, je crois. La communication est, après la taille brute, le premier facteur de plantage d'un projet. Chaque étape de communication fait perdre beaucoup de qualité à la communication...et donc d'informations utiles. La situation idéale, c'est le spécialiste métier sur les genoux du développeur, et les deux en train d'écrire(au tableau ou sur papier, peu importe). Ton cas est désastreux quelle que soit la méthodologie : non seulement tu communiques par écrit(le pire des cas), mais en plus tu rajoutes un intermédiaire.

Le truc, c'est que les ancêtres du mouvement agile justement considèrent ce point comme fondamental(et je suis d'accord avec eux). Par exemple, Alistair Cockburn(chercher Figure 1. Modes of communication).

Donc, ton chef commet 2 entorses fondamentales aux principes agiles : (1) il se met en intermédiaire, et (2) il utilise le moyen de communication inefficace par excellence. Je suppose que le client est complice de ce forfait, c'est fréquent.

C'est toi qui parle de SSII et de reconnaitre la valeur du developpeur, avec des chefs de projets competents qui sont capables d'avouer qu'ils ne savent pas quelque chose et de faire confiance a l'analyse du developpeur ? Nous n'avons pas connu les memes SSII !

Ca n'est pas une question de SSII ou pas, c'est une question de pouvoir. Quand le chef a décidé qu'il était le chef et que nous étions ses grouillots, SSII ou pas, on va dans le décor. Dans les champs de coton ça donnait des résultats mitigés, mais ça restait viable parceque cultiver le coton est une activité linéaire et standardisée. Dans une activité créative, fluide, et multidimensionnelle comme le développement informatique, c'est merguez.

Des CdP comme ça, j'en ai vu. 2 en 14 ans, certes, et j'ai carrément bourlingué. Ca existe. Simplement, ça n'est pas le sens des formations qu'ils recoivent(toujours la "science du contrôle" qu'on martèle dans le crâne des managers). La difficulté, c'est de contrôler au bon niveau(est-ce que le boulot avance là ou il faut, comme il faut?). La tentation, c'est de tout contrôler(qu'est-ce que Gérard fabrique? Il m'avait promis de finir en 2h45, ça fait déjà 2h52 qu'il est sur l'envoi de mails!!!). Et tout pousse nos managers à la tentation : leur hiérarchie(tenez vos équipes!), leur formation, leur peur(ben oui, leur place est rare et convoitée, un bon motif pour perdre les pédales et faire n'importe quoi).

[leminipouce]

On voit aussi de l'agile appliqué de la sorte :
Toute tache dure 2 semaines au maximum --> Si le dev dit qu'il faut 10-12 jours, c'est 2 semaines. S'il dit qu'il faut 20 jours, on coupe le truc en deux, et on fait 2 taches de 10 jours. S'il repond 50, on fait 5 taches.

Euh... En 10 ans d'expériences, j'ai pas souvenir d'avoir déjà vu un chiffrage micro à 50j. Et j'ai du mal à concevoir qu'une tâche aussi longue ne puisse pas être redécoupé en "sous-tâche" plus courtes. Mais où est le problème ? En agilité comme dans les autres méthodologies, il peut y avoir des pré-requis pour réaliser quelque chose. Il peut aussi y avoir des livraisons avec quasiment rien de visible pour l'utilisateur (pour qui la recette ne sera que plus rapide ) car un refactoring/des dév. internes/etc sont en cours. C'est tout à fait possible. Pareil, un projet agile ne fait pas nécessairement une livraison toutes les 2 semaines. Tu peux aussi choisir des itérations plus longues !

Stand-up réunion tous les matins, ou chacun dit ce qu'il a fait la veille et ce qu'il fera dans la journée. --> Hier, j'ai chercher comment contourner le probleme machin. Heureusement, il y a la reunion de ce matin pour que je vous en parle, car je ne suis pas allé voir le specialiste du truc pour avancer, j'ai preferé merder dans mon coin. Et j'oublie aussi celui qui te raconte sa vie pendant la reunion.

Pour ça, l'agilité n'est pas un remède à la connerie. Partager très brièvement tous les matins pour que l'équipe sache ce qui se passe et pour lever les loups, anticiper les problèmes ne veut pas dire "ne pas parler tout le reste de la journée". Si les gens dans l'équipe sont trop bêtes pour perdre une journée entière à chercher plutôt qu'aller voir leur collègue... il est peut-être temps pour eux d'envisager une reconversion professionnelle. Une pratique qui évite aussi ce genre de biais, très peu utilisée en France, est le peer-programming. Mais là, on n'a plus rien à voir avec l'agilité.

C'est toi qui parle de SSII et de reconnaitre la valeur du developpeur, avec des chefs de projets competents qui sont capables d'avouer qu'ils ne savent pas quelque chose et de faire confiance a l'analyse du developpeur ? Nous n'avons pas connu les memes SSII !

Peut-être pas en effet
J'ai eu des CP très cons, et d'autres très intelligent, en SSII ou pas d'ailleurs. Là aussi, SSII ou CP ce n'est pas un remède à la connerie. Si le CP est un idiot fini qui pense tout savoir, on fait avec, on va voir ailleurs, on s'en plaint auprès du DP ou que sais-je encore. Mais l'agilité n'est ni un remède, ni un poison dans ce cas.

[gangsoleil]

Nous sommes donc d'accord : avec un bon chef de projet, on mene a bien un projet, Agile ou pas. Et avec un mauvais, toute methodologie ne va que faire perdre du temps a une equipe qui doit s'auto-organiser pour combler les manques du CdP.

Dans les deux cas, Agile ne change pas grand chose.

Et ce que j'entends aujourd'hui autour d'Agile, c'est de la part de "cheffaillons" qui ne font que des conneries, mais qui arrivent bien a vendre les termes Agile, Scrum, Scrum-Master, ou n'importe quel buzz-word. Et c'est ca qui me derange : le probleme ne vient probablement pas d'Agile, qui est plutot a mon sens une bonne chose, mais c'est devenu tellement n'importe quoi que oui, pour moi, c'est malheureusement devenu a jeter.


Pour les exemples que j'ai pris, c'est malheureusement du vecu.

[niarkyzator]

Le problèmes des méthodes Agiles est simple : c'est avant tout basé sur le bon sens.

Or les managers / chefs de projets ne veulent pas de "bon sens", ils veulent des règles simples qu'on peut appliquer bêtement.

[antoinev2]

C'est comme beaucoup de belles théories : l'objectif est noble mais la nature de l'homme reprend vite le dessus.

D'après ce que j'ai vu, l'agilité est un superbe prétexte pour les MOA et les clients pour justifier le manque ou l'absence de leur méthodologie, de leur suivi.
Le dev agile signifie à leurs yeux "je peux demander à mon développeur tout ce que je veux et changer d'avis aussi souvent que je veux, il se débrouille pour appliquer."
En cas d'échec, qui est responsable? Le dev qui n'a pas su être "agile".

[transgohan]

C'est comme beaucoup de belles théories : l'objectif est noble mais la nature de l'homme reprend vite le dessus.

D'après ce que j'ai vu, l'agilité est un superbe prétexte pour les MOA et les clients pour justifier le manque ou l'absence de leur méthodologie, de leur suivi.
Le dev agile signifie à leurs yeux "je peux demander à mon développeur tout ce que je veux et changer d'avis aussi souvent que je veux, il se débrouille pour appliquer."
En cas d'échec, qui est responsable? Le dev qui n'a pas su être "agile".

Oui c'est un échec du dev, c'est en effet lui qui n'a pas su être agile...
En effet, la charge de la tâche est estimée par le DEV !
Le fait de prendre ou non la tâche dans le sprint est aussi de la responsabilité du DEV !
Bref si à la fin il s'est engagé sur cela et qu'il n'a pas réussi sa mission c'est donc de sa faute.

Et il n'y a pas de "on peut rien refuser à à la MOA", on peut leur prouver par tout un tas d'indicateurs que ce qu'ils demandent n'est pas réalisable dans le temps demandé.
Il n'y a qu'à la MOA des débiles, mais là ce sont eux qui ne jouent pas le jeu et on ne peut pas y faire grand chose...

"MOA> Construit moi un moteur d'avion.
Développeur> Mais... Je ne suis pas mécanicien ???
MOA> Rien à f**tre. Construis moi un moteur d'avion."