Discussion :

[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.

[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 ?

[NoClassDefFound]

Malheureusement les méthodologies "Agile" ont souvent été mises en avant, imposées, pour de mauvaises raisons.
Exemple: Scrum impose d'avoir des réunions face à face avec le client, c'est donc un moyen d'éviter la délocalisation des projets.
Le Directeur de Projet en question nous imposait de l'Agile à cause de ce postulat plus ou moins foireux, tout le reste comme la montée en compétence des équipes sur la méthodologie et les surcoûts en gestion de projet notamment lui passaient au-dessus de la tête.

[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).

[est13java]

Je crois que le développeur pose bien le problème.
Mais la conclusion est ouverte à discussion.
Fonctionner avec des méthodes Agile ne signifie pas qu'il ne faut plus de manager (mauvaise compréhension de l'auto-organisation), qu'il ne faut plus d'architecture (au contraire). Par contre, l'agilité nécessite de l'excellence à tous les niveaux notamment techniques (ce que dans la réalité, peu de développeurs comprennent malheureusement car en France après 35 ans, le développement est considéré à tort comme une tare), des changements de paradigme de pensée (notamment chez les anciens chefs de projets).

Je partage l'idée qu'il est plus efficace d'avoir un manager et un leader technique (pas forcément la même personne) qui comprennent, partagent et insufflent la même vision.

Je doute que l'IT soit manichéenne au point de tout ou rien. L'agilité est un état d'esprit qui, bien appliqué, procure des résultats très intéressants. Mais là encore, il faut passer du temps à se former, régulièrement, à s'améliorer en permanence, à investir sur d'autres axes que la productivité pure.

A mon sens, la démarche Agile dans les cycles de développement s'inscrit complètement en phase avec le Management 3.0 (cf site de J. Appelo), le Software Crafsmanchip, l'émergence de leaders, les nouveaux axes de motivation ...

L'important reste à mes yeux d'avoir une équipe qui progresse, qui se sent bien, qui fournit des résultats efficaces. Et je crois qu'il ne faut pas être dogmatique. Selon les projets ou les membres de l'équipe, il faut utiliser le cycle de développement le plus adéquat. Mais qui accepte de changer facilement de paradigme de pensée, de langage de programmation, de amnière de concevoir ou tester les programmes .... pas simple ;-)

Ollivier

[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.

[ericherve]

Je suis d'accord avec l'article : l'esprit se perd. Pourquoi? Buzz word et non-application des concepts sous-jacents.
Pourtant ceux-ci sont beaux. Après, ça demande un réel travail d'équipe entre les différentes équipes, de réelles compétences, de réelles responsabilités. On ne peut pas reporter la responsabilité.
À mon sens, ça vient aussi un peu du manque d'envie de comprendre le métier de l'autre, et de la suprématie de certains domaines sur d'autres. Ex : Un dev qui s'en fout du côté business. Un responsable des ventes qui prend des décisions d'orientation techniques.
La communication ne se fait au final pas plus que dans d'autres méthodologies.
Et tous les projets ne sont pas adéquats à de l'agile (mais ça, je veux bien qu'on me prouve le contraire).
Et par pitié, que chacun prenne les décisions dans son domaine de compétence : les ventes aux ventes, les délais aux cp, l'archi à l'archi, le marketing au marketing. Il faut savoir être humble. D'ailleurs, j'ai raison

[ericherve]

Par contre, l'agilité nécessite de l'excellence à tous les niveaux notamment techniques (ce que dans la réalité, peu de développeurs comprennent malheureusement car en France après 35 ans, le développement est considéré à tort comme une tare), des changements de paradigme de pensée (notamment chez les anciens chefs de projets).

Je suis d'accord avec toi :

• Le succès des premières équipes Agile est dûe à leur qualité
• L'impact du maillon faible en Agilité est vraiment visible (ce qui devrait être un atout par rapport au waterfall au final pour fixer le problème)
• Payons les développeurs seniors à des salaires de seniors, et non pas de ratés
• Continuons de nous former en tant que travailleurs (ou humains. Je connais trop de gens dans le dev, et dans tous les autres domaines, qui arrêtent de se former)

[Luckyluke34]

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

C'est vrai, et c'est à peu près le cas de toutes les méthodes agiles, beaucoup de fondateurs du manifeste étant venus avec leur propre process déjà existant (y compris les auteurs de Scrum) car c'était le but de la rencontre. Du coup, on jette ce qui est décrit dans le manifeste agile et on garde toutes les méthodes ? Est-ce que le même phénomène de Cargo Cult autour d'un process particulier à la mode ne risque pas de se reproduire ?

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.

Pas d'accord. Il n'y a pas de chef de projet au sens traditionnel du terme dans une équipe agile. Il peut y avoir un facilitateur (Scrum Master, coach, etc.) qui :

- N'assigne pas les tâches aux membre de l'équipe
- N'a pas les cordons de la bourse
- N'est pas un supérieur hiérarchique
- N'est que co-responsable de l'échec ou du succès du projet (et n'a pas sa tête sur le billot si l'équipe échoue)

Par ailleurs l'auto-organisation est recommandée :

The best architectures, requirements, and designs
emerge from self-organizing teams.

En revanche, je suis d'accord qu'un bon chef de produit (Product Owner, client) est crucial au succès d'un projet. C'est lui qui fait les choix métier et décide d'investir sur telle feature plutôt que telle autre et peut mener le projet dans le mur ou à la réussite.

[chiv]

Excellent article. Je suis totalement en accord avec l'auteur.

Ce ne sont pas les méthodes agiles qui ont échoué, ce sont les gens, ceux qui pensent qu'on peut faire de l'informatique quand on est pas informaticien, quand on a pas de compétences.

Ce qui est rassurant, c'est que d'un certain point de vue, il est assez simple de faire du bon travail finalement. Il suffit de travailler avec des informaticiens, ce qui ne manque pas, et de se passer de managers, ce qui ne manque pas non plus mais dont on se passe très bien.

[Laurent 1973]

Ayant pratiqué plusieurs méthodes agiles (Scrum, XP, Kaban), il y a une chose qui me gène dans la discussion.
Beaucoup parle de "chef de projet".
C'est justement ce qui change dans cette approche méthodologique: il n'y a pas de "chef de projet"

On va avoir un chef de produit (ou "product owner" en Scrum), quelqu'un qui va avoir la vision des besoins utilisateurs ainsi que d'intégrer les contraintes de priorités et commerciales dans la réalisation de ce produit.
Mais il n'a pas besoin de connaitre le comment on va faire tel ou tel chose: il fait confiance aux développeurs pour trouver la meilleur solution technique à ces besoins?

Il y aura aussi un falicitateur de la méthode (appelé suivant le cas "Scrum master", ou "catch agile") pour aider à lever les points bloquants et respecté la méthode.
Bien qu'il connait souvent la technique, il reste neutre quand à la décision architecturale ou technologique trouvé par les développeurs. ll est là justement pour aider l'équipe à trouver la meilleur.

Mais il n'y a pas de "chef de projet" au sens superviseur, manageur directif qui va "prendre" tel ou tel ressource "developpeur" pour pisser un bout de code comme il l'a imaginé.
Ce genre de manageur n'as pas de sens dans l'agilité.

N'oublions pas que nos clients/utilisateurs se foutent éperdument de nos "projets", ce qu'ils veulent c'est nos "produits"
Donc, a bas les "chef de projets" et vive les "chef de produit".

Comme sité plusieurs fois dans les commentaires, le problème de l'agilité c'est que cela nécéssite de repenser entièrement la chaine managerial de l'entreprise. Beaucoup de "chef de projets" ne sont pas près à ce changement.

[JCB001]

L'agilité est une méthode parmi tant d'autres, comme l'approche TDD, c'est une approche très intéressante qu'il est au moins utile de connaitre et de l'appliquer si besoin.
En effet il ne sert à rien d'appliquer une méthode de façon intégriste en pensant que parce qu'elle a fonctionné sur le projet X elle fonctionnera forcément sur le projet Y, ça c'est de l'incompétence ;-)
Sur mon précédent projet on a privilégié l'approche TDD car on avait des grosses contraintes de qualité et qu'en même temps les déploiements dépendent d'un hébergeur très peu réactif (plusieurs semaines pour appliquer un correctif sans escalade ), sur mon projet actuel les contraintes ne sont plus les mêmes et compte tenu de l'historique de ce projet l'approche TDD que pourtant j'apprécie n'a pas été utilisée.
Et inutile aussi de s'appuyer sur des effets de mode...
Tout est question d'adaptation au projet : technologie, taille, budget, délais, criticité, personnes de l'équipe, MOA, etc... et c'est là qu'intervient l'intelligence, la compétence des membres de l'équipe pour choisir la bonne méthodologie... ou pas.
Comme rappelé c'est la compétence des individus qui prime d'abord.
En clair si vous voulez réussir vos projets embauchez ou rejoignez des gens compétents, honnêtes qu'ils soient technique ou fonctionnels, qui connaissent les différentes méthodologies, après cette intelligence d'équipe sera à même de choisir la méthodologie "optimale".

[lelutin]

Les méthodes AGILES sont selon moi pour des collaborateurs issu de la technique.
Le chef de projet ("responsable projet") doit donc avoir un passif de développeur et pas issu de formation de management ou commercial ou école d'ingé généraliste.
De plus, il doit vraiment jouer son rôle de filtre en ce qui concerne les specs (dire non au client peu être bénéfique pour ce dernier quand il dépasse le cahier des charges).
AGILE permet et demande une très grande réactivité car il y a intégration à flux constant et demande beaucoup d'échanges, mais n'est pas élaboré pour de très grosses équipes.
Il ne faut donc pas critiqué cette méthodologie, mais les managers ("Développeur en chef").

ps: JCB001 a tout dit, en fait...

[transgohan]

AGILE [...] mais n'est pas élaboré pour de très grosses équipes.

On lit souvent cela mais c'est parfaitement faux.
On peut par exemple faire du SCRUM de SCRUM.
Les projets où il y a 50 devs sur le même logiciel indécomposable en modules sont proches du néant.

[Aurelien Plazzotta]

Bonjour,

L'auteur du blog a bien résumé (ou a tapé large, selon sa sensibilité ) : il s'agit bien de dérive, d'incompréhension ou d'abus.
Néanmoins, il reste très vague sur les causes menant à cette conclusion.

D'autres utilisateurs ont très bien analysé le problème dans son ensemble mais je tiens à participer au fil de la discussion sur cinq points :

1. La transformation des chefs de projets en facilitateurs / coachs est très mal perçue car elle implique une baisse d'autorité. Beaucoup d'individus feraient l'amalgame entre baisse d'autorité et baisse de légitimité (à tort ou à raison, mais ce n'est pas le sujet).

2. Mike Hadlow semble (notez mon incertitude ) avoir une vision incomplète des parties en présence. Il cite le client, les développeurs et le chef de projet. Mais où est donc passé le meta-management ? La gouvernance d'entreprise n'est jamais abordée dans son billet de blog. Or, les chefs de projet ont eux aussi des supérieurs hiérarchiques, et la philosophie de travail dite Agile ne peut réussir si elle n'est pas approuvée par une autorité suffisante. Les opérationnels et les encadrants de proximité ne DOIVENT PAS être les seuls à appliquer les approches Agiles.

3. La taille des équipes est nécessairement petite. Certains auteurs (comme BOISVERT et TRUDEL), recommande 7+-2 opérationnels, soit 5 à 9 personnes ! Nous sommes loin des 508 intervenants qui ont bossé sur le logiciel unifié de gestion des payes des fonctionnaires (fin du troll).

4. Je subodore que la formation soit perçue comme une honte et un facteur d'échec en France métropolitaine. Cependant, l'application des préceptes de l'Agilité implique OBLIGATOIREMENT la formation et la sensibilisation de TOUTES les parties en présence, et pas seulement des développeurs ni même du client.

5. Pour des raisons de coûts financiers ou de méconnaissance de l'industrie du génie logiciel, l'expert fonctionnel (dans les cycles en V) et son équivalent chef de produit (dans les méthodes Agiles) sont malheureusement inconnus au bataillon. Leur absence parasite dangereusement la communication entre les différentes parties au contrat (voir les autres commentaires pour plus de détails sur la mauvaise communication).

[Luckyluke34]

Les méthodes AGILES sont selon moi pour des collaborateurs issu de la technique.

Agile ne s'écrit pas en majuscules (ce n'est pas un sigle). Par ailleurs, dire que c'est fait "pour des collaborateurs issu de la technique" n'a aucun sens. On construit un produit logiciel pour un client. L'implication du client est primordiale. Dans beaucoup de méthodes, le client est embarqué dans l'équipe agile ("Business people and developers must work together daily throughout the project").

Le chef de projet ("responsable projet") doit donc avoir un passif de développeur et pas issu de formation de management ou commercial ou école d'ingé généraliste.

Il n'y a pas de chef de projet agile en tant que tel, comme ça a été dit auparavant. Le facilitateur ou coach ou scrum master doit avoir une culture informatique mais rien ne l'oblige à être développeur à la base...

De plus, il doit vraiment jouer son rôle de filtre en ce qui concerne les specs (dire non au client peu être bénéfique pour ce dernier quand il dépasse le cahier des charges).

Mauvaise pioche, il n'y a pas de cahier des charges en tant que tel dans un projet agile. De plus, on peut dire non au client lorsqu'il veut ajouter du travail à l'équipe pendant une itération, mais entre les itérations ce dernier a tout loisir de remanier les exigences. C'est un des premiers intérêts de ces méthodos...

[gangsoleil]

Mauvaise pioche, il n'y a pas de cahier des charges en tant que tel dans un projet agile. De plus, on peut dire non au client lorsqu'il veut ajouter du travail à l'équipe pendant une itération, mais entre les itérations ce dernier a tout loisir de remanier les exigences. C'est un des premiers intérêts de ces méthodos...

A condition de rappeler au client que cela a un cout, aussi bien en termes financiers qu'en terme de delais sur la fin du projet. C'est un point que beaucoup oublient.

Et en ce sens, non le client n'a pas loisir de tout modifier a chaque iteration -- du moins pas sans repasser par les commerciaux.

[Luckyluke34]

A condition de rappeler au client que cela a un cout, aussi bien en termes financiers qu'en terme de delais sur la fin du projet. C'est un point que beaucoup oublient.

Et en ce sens, non le client n'a pas loisir de tout modifier a chaque iteration -- du moins pas sans repasser par les commerciaux.

Ce raisonnement illustre toute la difficulté qu'on a aujourd'hui à penser "hors du cadre". L'agilité ne marche pas si on reste dans le cadre contractuel et de gestion de projet traditionnel que tu sous-entends puisqu'elle consiste précisément à dépasser ces contraintes classiques.

1/ Tu supposes qu'on est au forfait avec un périmètre et un délai fixés à l'avance pour l'intégralité du projet. Le propos des méthodes agiles, c'est l'inverse : on ne connait pas le périmètre, on part sur un plan à grosses mailles qu'on va adapter au fil du temps et du feedback sur les livraisons. Parfois même, on cherche juste à fabriquer un prototype rapide pour estimer la viabilité d'un produit et ça va durer un mois en tout et pour tout. Le meilleur mode pour cela selon moi, c'est des contrats de type "stop ou encore" avec des volets courts, des lots au bout duquel le client peut décider que le produit lui suffit et d'arrêter là ou de continuer. Le périmètre de chaque lot est fixé avant le démarrage de celui-ci ce qui laisse tout loisir au client d'ajuster sa trajectoire. Une autre approche est d'avoir une clause du type "change for free" où le client peut substituer une fonctionnalité à une autre d'estimation équivalente comme bon lui semble entre les itérations.

2/ Tu supposes qu'on est en SSII avec un commercial qui va tenir des comptes d'apothicaire (sur une réalisation technique qu'il ne comprend pas la plupart du temps). Or ce n'est pas le cas de tout le monde, et les relations souvent exécrables entre les SSII et leurs clients aujourd'hui montrent que leur mode de fonctionnement n'est pas vraiment idéal. Ces dernières n'ont strictement aucun intérêt à faire changer le système actuel puisque c'est celui qui leur rapporte le plus - un petit truc à ajouter qui n'était pas explicitement écrit dans le cahier des charges, et bam! on facture. C'est un cercle vicieux car le client va en conséquence essayer de "blinder" les spécifications, de tout prévoir à l'avance, ce qui 1. va engendrer un coût initial du projet plus important et 2. rigidifier le périmètre, laissant moins de place à l'adaptation et rendant l'erreur de spec encore plus coûteuse.

3/ Tu parles en termes de projet qui a une fin alors que les méthodes agiles travaillent plutôt sur des produits et envisagent leur pérennité dans le temps. J'ai tendance à croire qu'une application aujourd'hui ne connait pas de fin. Les SSII aiment parler de leur projets comme s'il s'agissait de splendides réalisations de BTP qui une fois finies nécessitent juste un petit service après vente "nettoyage et entretien". Fadaises. D'expérience, ça se passe mal car les équipes de maintenance sont souvent sous-dimensionnées et différentes de celles de réalisation. Le building était déjà plus ou moins branlant à cause de la pression du délai fixe de livraison, puis on rajoute des fix, des patches sur les fix, des verrues sur les patches... Avec le temps le code finit par ne plus être maintenable du tout (qui n'a jamais connu l'"application legacy mutante du client X" dont le seul nom fait trembler tous les presta en intercontrat ?) Donc on la jette et on reconstruit un nouveau "bâtiment" tout neuf. Le monde d'aujourd'hui joue de plus en plus contre cette métaphore et en faveur d'applications plus évolutives, même dans des domaines où le software était traditionnellement figé après la release finale. Le firmware de mon appareil photo a bénéficié de 4 upgrades importantes depuis que je l'ai acheté il y a 2 ans. Pareil pour ma voiture, ma télé. Je ne parle pas du monde du web où les gros acteurs déploient des dizaines de fois par jour en production sur des sites parfois vieux de plus de 10 ans.

Alors oui, prédictibilité, budget, rationalisation, pression du financier, etc. mais du point de vue du client il vaut mieux quoi : partir sur un petit contrat au coût connu auquel on va rajouter des lots optionnels au fur et à mesure et dont il est facile de sortir, ou faire une bonne grosse prédiction qui risque de se révéler totalement aux fraises et au final obtenir un logiciel hors budget, hors délais et aux fonctionnalités inadaptées ? Se tromper vite, le savoir et corriger le tir, ou ne s'en rendre compte que quand les plâtres sont secs et tout l'argent alloué dépensé ?