Discussion :

[pbezault]

Bonjour,

je suis Manager d'une équipe pluridisciplinaire assez vaste. Entre autre, une partie de dévelopement informatique avec des Business Analyst, des Développeurs Java, des DBA d'études...

Voilà 8 ans que nous sommes agiles !

Je dis bien "nous sommes agiles" et non "nous utilisons une méthode agile" car sans donner dans le philosophique, ce qui compte dans un projet c'est l'équipe. Faire de l'agile ne peut pas être imposé, cela ne correspond pas à tous et parfois il vaut mieux faire du cycle en V que faire de l'agile avec des gens qui ne sont pas fait pour.

Après l'idée de ne fournir aucune doc et aucune planification est une ineptie. Et puis on peut tout à fait faire un cycle en V sans doc (experience vécue).
Comment croyez-vous que j'arrive à vendre des projets à mon DSI et nos clients si je balance "Je ne sais pas combien ca coute ni quand on fini !" ?

Enfin je reviens sur une idée reçue : une équipe agile est faite pour la maintenance (évolutive) et non seulement pour du projet !

Déjà parce que l'agilité c'est savoir refactorer facilement/rapidement son code et aussi parce que vous avez à l'avance une enveloppe vous permettant de staffer et aucun objectif défini.
Le contenu des iterations est défini tout au long de l'année par les clients leurs donnant la possibilité d'arbitrer les correctifs au fur et à mesure... le seul challenge est de leur faire entendre que l'on étale les correctifs sur l'année et que non on ne sera pas 50 ce mois-ci et 0 le reste de l'année (ce serait anti-agile ;-) )

Donc ma critique de cet article serait plutot pourquoi ne pas interroger des clients qui ont fait face à des équipes classiques et des équipes agiles ?

Au final mon conseil, soyez pragmatiques !

Or parfois, par exemple, mon équipe récupère des applis qui sont très belles et fonctionnelles, que le client porte aux nues et il déchante quand il apprends que la moindre évolution va lui couter un bras car il n'ya pas de doc, que les gars qui ont monté l'appli ne sont plus là et que le code est affreux !!

Attention, je modère mes propos.
Je ne dis pas que Méthode Agile => Solution non maintenable
Je dis Méthode Agile => Plus de flexibilité => Plus de latitude AUSSI pour faire de la m****

ATTENTION là ce n'est plus une question d'Agilité mais de qualité de code et de Knowledge Management

[Patriarch24]

Je dis Méthode Agile => Plus de flexibilité => Plus de latitude AUSSI pour faire de la m****

Je ne vois pas en quoi un code dégueux trouve son origine dans plus de flexibilité...

[zyongh]

+1

[vasaldo]

perso la methode agile c pas mal, meme si en tant que cp classique j'aime bien la methode en V

perso je verrais plutot sur de gros projets logiciels :
- utilisation de la methode en V pour la creation du logiciel jusqu'a sa MEP
- methode agile pour la suite, cad la maintenance evolutive
dans le cas de maintenance evolutive la methode agile sera plus souple, le metier normalement saura comment fonctionne l'appli deja en PROD donc ils pourront intervenir directement et utilement.

apres de ce que j'ai vu dans pas mal de boite, la methode agile est interprété comme : "pas de doc à faire ...yahooooo" !!
bref du n'importe quoi

en meme temps en methode classique combien je vois d'incompétents (oui faut appeler un chat un chat) qui vont pondre des docs merdiques juste bonnes a etre validées par la MOA/le métier mais qui ne seront pas utilisables par les developpeurs et/ou les équipes de recette/integration..bref des specs qui servent a rien, ou pire qui sont ambigues :-)
une specs ambigues merdiques, ca veut dire une tres forte proba d'anomalies d'integ/recette donc des correctifs donc re-tests donc retards donc planning qui dérive comme le radeau de la meduse..au final client mécontent, equipe sous pressio n permanente...bref tout le monde dans la merde parcequ'au départ on n'a pas voulu faire l'effort de faire les choses "bien", cad soigner les specs....une sorte d'effet domino (ou papillon mais la c'est un peu vantard lol)

et puis la methode en V ne garantit pas que les gens feront leur boulot, cad mettre a jour les specs en tant réelle cad a chaque evol/correctif necessitant la maj des specs : normalement ca impose une revalidation des specs..ok c chiant, ca bouffe du temps mais au moins on sait ou on va !!
car des specs pas a jour, on sait comment ca finit...elles seront jamais mise a jour.

[vasaldo]

Je ne vois pas en quoi un code dégueux trouve son origine dans plus de flexibilité...

+1000

c l'habituelle excuse des nuls ca ;-)

[zeyr2mejetrem]

+1000

c l'habituelle excuse des nuls ca ;-)

Premièrement, quand on arrive sur un forum et que l'on désire être apprécié, on évite d'être insultant

Deuxièmement, il faudrait peut-être arrêter de voir tous les développeurs comme des gens consciencieux et/ou compétents ...

Je développe mon propos:
Dans les méthodes agiles on met en avant des valeurs telles que la communication et l'initiative et on laisse plus de liberté au développeur en comptant sur une implication active de sa part.
C'est bien, mais pas avec tout le monde.

J'ai déjà travaillé avec des développeurs qui dans ce contexte produisait du code fonctionnel mais non commenté, non documenté et obscur et donc non maintenable parce qu'ils n'avaient pas la bonne mentalité (en gros, le genre à dire "Je m'en fous, c'est pas moi qui vais maintenir").

Dans les méthodes à l'ancienne il y a généralement plus de flicage et donc ce genre de chose arrive moins.

En résumé. Les méthodes agiles, je suis pour mais sur des projets de taille humaines et avec une équipe qui joue le jeu.
Sinon j'applique l'ancienne méthode (celle avec les chaînes et le fouet <-- PS: Ceci est une boutade, et donc à prendre au second degré, Merci de ne pas poster des réactions indignées )

[Anything]

J'ai vraiment tendance à me méfier de ce genre de rapport. J'ai l'impression que la plupart du temps, si quelqu'un critique quelque chose c'est pour vendre son produit de manière plus efficace. Je ne connais Voke mais sait-on pour une fois si les intentions de ce rapport sont honnêtes ?

Au moins, il a le mérite de faire contre poids aux divers rapports qui disent que les métodes agiles livrent les logiciels à temps, rendent heureux les développeurs, font le café et accéssoirement permettent de guérir du cancer

Pour ma part dans mon entreprise actuelle, avant on avancait sans visibilité à plus de deux semaines du projet, le patron pouvait demander à changer tout d'une semaine sur l'autre, on n'avait pas le démarrage d'une spec quand on devait dev nos appli.
Maintenant avec l'application de scrum, on avance sans visibilité à plus de deux semaines du projet, le patron peut demander à changer tout d'une semaine sur l'autre, on n'a pas le démarrage d'une spec quand on doit dev nos appli mais on colle des post it sur un tableau et on fait une réunion entre 15-30 min chaque matin.
Ca change tout, vraiment

Personnellement, j'ai plutot vécu la mise en place de scrum comme un flicage supplémentaire(ok c'est beaucoup du à mon CdP hyper méfiant qui ne fait confiance qu'à lui même et à qqun de ses potes) et une perte d'autonomie.

Bref les méthodes agiles ont certainement des mérites et des avantages, mais quand c'est uniquement pour camoufler une méthode à la Rache, c'est tout ce qui il y a de plus pourri.

PS: dans ma précédente entreprise on était, je pense, pas loin de l'esprit des méthodes agiles et ça fonctionnait plutot bien(projet par itération, brainstorming autour d'un café et quand même quelques docs et specs).

[vijvij]

Les développeurs... je ne suis pas sûr, c'est plutôt la hiérarchie chez mous qui en profite: plus de traçabilité des taches, plus de compte rendu de réunion, plus d'anticipation...

[parou]

Chez nous c'est le top du top

Nos têtes pensente réorganise les méthodes de développement et de gestion de projet :

pour la gestion du projet : Prince 2 avec tout les documents + cahier de charge détailler analyse technique et fonctionnelle + pid + ... + ...
toute cette belle documentation n'est bien sur jamais jamais jamais mise à jour par la suite

pour la partie développement : Agile par ce que c est à la mode

et pour la partie test : V-model

Tout ce ci est il réellement compatible ... ??????
Pour ma part je pense toujours avoir travaillé de manière "Agile" sans avoir besoin d'une méthodologie ou d'une norme pour y arrivé

[zeyr2mejetrem]

Chez nous c'est le top du top

Nos têtes pensente réorganise les méthodes de développement et de gestion de projet :

pour la gestion du projet : Prince 2 avec tout les documents + cahier de charge détailler analyse technique et fonctionnelle + pid + ... + ...
toute cette belle documentation n'est bien sur jamais jamais jamais mise à jour par la suite

pour la partie développement : Agile par ce que c est à la mode

et pour la partie test : V-model

Tout ce ci est il réellement compatible ... ??????

Oui, mais tu connais le dicton: "Rien n'est impossible ... à celui qui n'a pas à le faire !!"

[montesq]

pour la partie développement : Agile par ce que c est à la mode

Effectivement chacun met ce qui l'arrange derrière le mot "agile". Compte tenu de ce que tu présentes, il semble que ton organisation implémente certaines pratiques de l'agilité, mais cela n'en fait pas pour autant une organisation "agile".
Concrètement, quand je demande à des développeurs s'ils ont déjà travaillé en Scrum, la réponse est souvent: "oui, on faisait une réunion tous les matins"

Ceci dit, il est illusoire de croire qu'une organisation peut passer du jour au lendemain à un modèle "agile". Cela demande de profonds changements en terme d'organisation et de compétence. Il faut donc savoir si le développement agile est une première étape pour généraliser l'approche agile dans le futur à la partie recueil du besoin et test ou bien s'il s'agit uniquement d'implémenter le buzzword du moment. Dans ce cas, il est faut être conscient qu'en limitant le périmètre de l'agilité, on réduit de ce fait les gains potentiels...

[phpXpress]

L'agilité est loin d'etre une arnaque. c'est plutot les méthodes classiques qui en sont une !
Ca fait 40 ans qu'on fait des projets en étant incapable de tenir les délais sauf à sacrifier les phases finales (généralement les tests). Le client est quasi tjrs déçu (je pensais pas ça comme ça ...) Le soft est mal testé est truffé de bugs.
Le ressenti final est souvent peu reluisant.
Agile n'est pas une méthode mais un mode de fonctionnement. Scrum est une méthode Agile. On peut appliquer quelques principes de Scrum dans des méthodes classiques sans faire de l'Agile pour autant.
L'agilité se met en place en accord avec une décision de la direction pas unilatérallement par les développeurs.
Scrum ne dit pas "pas de doc" ou "pas de planning" mais de la doc dans le code, dans le les cahier de test et le product backlog. Le planning est bien plus contraignant en Scrum car suivi au jour le jour.
Par contre le mode de fonctionnement est tout simplement IDEAL ! on passe en mode win/win ou se parle et on s'écoute, le périmetre du codeur s'élargit à celui de codeur+analyste+testeur... Il fait tout et c'est bien plus gratifiant et enrichissant.
Par contre, le coté "certification" après 2 jrs de formation est effectivement une arnaque mais c de bonne guerre.
Je pourrais en parler encore des heures mais ...

[lolpapa]

Les pratiques Agiles ne sont pas une arnaque, mais elles demandent du courage, elle obligent à oser se remettre en question.

Elles ne sont pas non plus un remède miracle à tout. Mal employées elles feront autant de mal qu'une autre méthode mal employée.

Et pour ce qui est des méthodes toujours dominantes aujourd'hui et basées sur le système "Waterfall" il est amusant de savoir que l'un de leurs pères fondateur, Winston Royce, écrivait ce qui suit en 1970 et page 7 de ce que l'on pourrait considérer comme le Waterfall Manifesto de l'époque :

Selon ma propre expérience, ce model n'a jamais fonctionné pour les développements de grands logiciels

[Mano78]

Le problème n'est pas la méthode.
Pour moi le succés d'un développement informatique est d'abord la motivation de tous, l'implication de tous.
Avec de la volonté on peut tout faire.
Avec de bons développeurs, motivés, on peut faire des miracles.
L'implication de tous les corps de métier est primordiale.
J'ai travaillé comme indépendant, puis une startup, puis de grosses
entreprises. Agile pour moi, c'est plus de souplesse, plus de créativité,
et ça me rappelle un esprit startup. Ca ne veut pas dire qu'il faut oublier
la doc.
Un développeur à besoin de reconnaissance. D'abord de ses collègues, puis de ses managers, puis des utilisateurs de son produit, et puis il ne faut pas l'oublier : la carotte -.
Pour avoir tout cela dans les grosses boîtes, il y'a du chemin. Il faut
qu'elles soient vraiment sous pression.

[arnonyme75]

Les critiques que j'ai lu sur les méthodes agiles émanent de personnes ne semblant rien y connaître.
Il ne suffit pas de prétendre faire de l'agile pour l'être. Lire l'agile manifesto.
L'agilité nécessite de la rigueur et de la discipline. Mais, à la différence du management habituel, cette rigueur et cette discipline émanent de la conscience interne de l'équipe de leurs nécessité.
Rien n'est imposé de l'extérieur. On fait confiance aux équipes et les laissent s'organiser comme bon leur semble.
Pour ma part, je suis convaincu par la méthode SCRUM. J'ai croisé à des réunions sur le sujet beaucoup de personnes qui prétendent être agiles mais qui n'appliquent pas vraiment SCRUM. Ils vous servent toujours les mêmes arguments : dans la vraie vie ceci, dans la vraie vie cela...
En fait, ils prennent ce qui les arrange et jettent le reste. Parce qu'ils ne veulent pas se remettre en cause.
Hors, la remise en cause est la base de toute amélioration continue, et l'amélioration continue est au coeur de l'agilité.

[el_slapper]

Et donc tu ne remets pas en cause SCRUM?

[souviron34]

Bon, je vais intervenir un peu ici

Ceux qui fréquentent le forum depuis un certain temps connaissent ma position : je suis absolument convaincu de l'approche agile. Je suis assez contre les méthodes agiles.

Là où le bât blesse, et où on peut être tenté d'appuyer les conclusions de l'article, c'est dans le fait que c'est devenu il y a quelques années un buzzword, et que donc ça a été vendu/appliqué par des gens n'y connaissant rien, comme d'habitude dans ce genre de cas de figure marketing.

Quand je lis :

• Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile.
  ...
• Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance.

ça ne m'étonne absolument pas...

et je suis sûr qu'on peut ajouter un dernier point (mais là c'était les managers qu'on interrogeait, donc l'auto-critique n'est pas leur fort)

[*]Survey participants report that managers use the guise of Agile to sell a new service to their clients

Justement parce que c'est une mode, perçue non comme un moyen d'arriver à un bon résultat, mais techniquement comme "un truc à la mode" et de manière gestionnaire comme "un moyen de vendre un service" ou "un moyen de se postionner dans la modernité.


Pour reprendre quelques points qui me paraissent essentiels :

L’agilité n’est pas une méthode. Selon moi, c’est plutôt une philosophie qui conduit à observer nos métiers selon un angle précis, guidé par des principes fondateurs simples :

• Les individus et leurs interactions plus que les processus et les outils

Le problème n'est pas le concept, mais l'implémentation du concept.

Non non, ni "par les développeurs" ni "pour les développeurs". Ne pas confondre l'outil et l'objectif.

Le but c'est de livrer le meilleur produit dans le meilleur budget/temps.

...
Donc non, l'agilité n'est pas "developer-centric" (gros contresens de l'étude). Ce sont juste des solutions hyper pragmatiques, et dans pragmatique il y a "on ne regarde pas d'où ça vient du moment que c'est efficace".

Je dis bien "nous sommes agiles" et non "nous utilisons une méthode agile" car sans donner dans le philosophique, ce qui compte dans un projet c'est l'équipe. Faire de l'agile ne peut pas être imposé, cela ne correspond pas à tous et parfois il vaut mieux faire du cycle en V que faire de l'agile avec des gens qui ne sont pas fait pour.
...
Au final mon conseil, soyez pragmatiques !

Les critiques que j'ai lu sur les méthodes agiles émanent de personnes ne semblant rien y connaître.
Il ne suffit pas de prétendre faire de l'agile pour l'être. Lire l'agile manifesto.
L'agilité nécessite de la rigueur et de la discipline. Mais, à la différence du management habituel, cette rigueur et cette discipline émanent de la conscience interne de l'équipe de leurs nécessité.

C'est l'esprit du Manifeste, et l'esprit de l'Agilité.

Alors, en tant que développeur, les méthodes agiles ont très largement ma préférence, mais en tant qu'auditeur, je préfère une bonne vieille méthode présentant un dossier complet de programmation, avec analyse organique et fonctionnelle !

En quoi est-ce que ceci ne fait pas partie d'une démarche agile ??

Je développe mon propos:
Dans les méthodes agiles on met en avant des valeurs telles que la communication et l'initiative et on laisse plus de liberté au développeur en comptant sur une implication active de sa part.
C'est bien, mais pas avec tout le monde.
...
En résumé. Les méthodes agiles, je suis pour mais sur des projets de taille humaines et avec une équipe qui joue le jeu.
Sinon j'applique l'ancienne méthode (celle avec les chaînes et le fouet

C'est exactement ce point qui est à la base des mauvaises expériences et de l'absurdité des "méthodologies" et de leur application bête.

Le Manifeste a été écrit PAR des personnes expérimentées, pluridisciplinaires, et versatiles (plusieurs environnements) POUR des personnes expérimentées, pluridisciplinaires, et versatiles (plusieurs environnements).


Il n'est pas destiné à un dev de base ayant fait 6 mois de formation, il est destiné à des devs ou CP expérimentés.

Quand on parle de l'humain dans les équipes, c'est l'humain d'exception. Le Manifeste ne se veut pas une manière de faire industrielle, mais au contraire une manière de faire artisanale qui produit de la qualité industrielle.

Là, l'application des méthodolgies "brutalement" avec n'importe quelle équipe, ça revient à prendre 6 de vos voisins qui gratouillent une guitare ou un piano et vouloir faire le concert du 14 Jullet retransmis à la télé.. Il est bien évident que ça ne donnera pas un bon résultat. Si par contre on prend Catherine Lara pour la composition et le violon, Benjamin Biolay ou Bénabar pour les paroles, Jean-Michel Jarre pour le synthé, Lavilliers à la guitare, et Zaz au chant, on rsique d'avoir un bon concert..


Là on utlise un buzzword et on fait n'importe quoi..

(et en plus, souvent dans les formations universitaires par exemple (ce qui implique les remarques sur le manque de doc etc) on n'enseigne plus la manière de concevoir une analyse "traditionnelle", qui est cependant la base de la culture et des gens du Manifeste et d'une application générale : il faut savoir analyser et savoir QUOI mettre dans une doc... Même si cette doc est réduite, il y a toujours une analyse et un document de conception. )


L'approche Agile est simplement la manière de travailler en informatique d'une équipe d'artisans pluridisciplinaires pour faire un produit industriel.


Je me suis déjà fait traiter ici "d'élitiste" pour avoir osé dire ça, Mais c'est la réalité. C'est pas à un maçon lambda qu'on va confier de réparer Notre-Dame..

[souviron34]

Je compléterais par un point :

En résumé. Les méthodes agiles, je suis pour mais sur des projets de taille humaines et avec une équipe qui joue le jeu.
Sinon j'applique l'ancienne méthode (celle avec les chaînes et le fouet

Je pense au contraire que les méthodes agiles s'appliquent superbement sur de gros voire très gros projets...

Dans une méthode classique, on va faire une analyse (6 mois à un an au moins), faire les docs, monter une équipe d'une 50aine-100 aine de personnes, qui va travailler pendant 5 ou 7 ans, qui vont être divisés en équipes, avec des chefs d'équipe, qui vont nécessiter des réunions, des documents correspondants, des retombées pour chacune des équipes, traduites dans son langage, etc., qui vont finir par éventuellement faire quelque chose de testable au bout de 10 ans, temps au bout duquel on s'apercevra que a) soit la technique a évolué et/ou b) on n'a pas pris en compte / mal modélisé / mal implémenté quelque chose. On aura passé tous les tests unitaires, systèmes etc, et pourtant on n'aura pas le bon résultat (si on juge le succès par le contentement des utilisateurs et non pas le fait de pouvoir dire à son patron "j'ai fini").

Mon expérience personnelle sur 3 projets comme ceci - 60 à 100 personnes, 10 à 15 ans de dev - (c'est d'ailleurs la même expérience que les auteurs du Manifeste).est que au contraire dans ce cadre une approche agile est gagnante à une échelle incommensurable.

Plus le projet est gros, plus l'approche agile est essentielle...

[23JFK]

Le nom "méthode agile" m’insupporte, j'ai à chaque fois l'impression que l'on se réfère à un numéro de cirque avec des macaques bien dressés. Puis je ne pense pas qu'il puisse exister une méthode de production universelle qui soit à elle seule la source de garantie du succès d'un projet, et encore moins que l'on puisse me l'imposer comme une prétendue amélioration.


Ouaissss, c'est Noël, et j'exhume les vieux sujets.

[ego]

Un avis de plus...

Selon moi, le seul truc bien de l'Agile est la notion d'itération. Cette notion tire le reste et ça c'est franchement intéressant même s'il faut rester vigilant sur certains effets négatifs comme le manque de conception qui peut en découler.

Mais le réel problème que je vois (j'ai vu), c'est l'accent trop important mis sur les aspects management. Au début, quand l'approche a démarré on avait surtout des pratiques XP avec une emphase sur des aspects proche du développeur. Même si la dimension management était présente, comme le mouvement venait du monde du développement, il y avait une assimilation des pratiques à des pratiques de développeurs, donc pas forcément prises aux sérieux par le management des entreprises.
Puis, est venu des approches comme Scrum, plus respectables car plus orientée sur le management....là on a pu rentrer dans les entreprises plus facilement, on parlait de problématiques que des managers pouvaient comprendre. Et donc comme l'on déjà dit certains, non seulement on a eu cette adhésion par le management mais aussi cette utilisation d'une approche "sans documentation". Cette fausse vision de l'Agile mais qui s'est construite par excroissance de l'approche management et parce que dans les entreprises (je parle d'entreprise "cliente" pas des SSII) on y voyait une occasion de faire des specs rapides, "à la main" sans forcément se prendre trop la tête à être précis. Comme il y a beaucoup de sous-traitance dans les grosse boites, tout ça n'est pas grave, le sous-traitant n'a qu'a comprendre ce que j'ai écris, ce fénéant.
Et là, certains discours sur l'Agile et certains "outils" ne facilite pas les choses. Je veux parler par exemple des UserStory/Epics. Une vraie arnaque ce truc. On y met ce que l'on veut, on se retrouve vite avec un sac de 500 stories dont on ne sait pas lesquelles sont en relation avec lesquelles et vas y pour maintenir tout cela pendant 10 ans ou plus. Allez expliquer à un nouvel arrivant IT ou au métier ce que votre application est censée faire avec un sac de stories. Et je passe les tests fonctionnels à organiser avec ces machins.

Mais comme vous savez, dans les grosses boites, comme on sous-traite le développement et parfois la conception, la connaissance du métier de l'informatique se perd. On s'oriente de plus en plus vers des internes, gestionnaires de relations contractuelles et c'est pour cela que leur donner une méthode qui apparamment (mais comme je l'ai dit qui selon moi n'aide pas trop) n'impose pas de technique de travail "contraignante" sur les phases amonts d'un projet permet une adoption grandisante mais dangeureuse.

C'est entre autre à cause de ces types de dérives que l'on voit des mouvements comme le craftsmanship.....vous connaissez ?