Discussion :

[Jitou]

Parce que souvent il y a d'énormes différences entre l'idée du projet de base et le projet final.
Alors qu'en cycle en V pure, on livre exactement ce qu'on a dit des années avant...
C'est cool d'avoir des réunions régulière avec le client pour qu'il puisse dire "en fait je n'ai pas besoin de ça, mais maintenant j'ai besoin de ça".

En Cycle en V il faut être extra fort, il faudrait comprendre le besoin du client mieux que le client lui même et anticiper les besoins du futur.

100% d'accord avec ce que tu dis mais ça on le faisait déjà avant qu'on lui donne le nom de "méthode de travail agile", des vrais cycle en V et des développement en mode sous marin pendant x mois je n'ai jamais vu, à un moment ou à un autre le client toujours inquiet voudra voir son bébé en cours de réalisation et forcement il va changer des trucs et remettre en cause les specs. Heureusement que les développeurs eux ont toujours été flexibles, allez demander à un artisan carreleur de changer les dalles de votre futur salon parce que après réflexion cela ne vous plait pas.

[Ryu2000]

des vrais cycle en V et des développement en mode sous marin pendant x mois je n'ai jamais vu

Oui, mais si on appliquait le cycle en V à la lettre il faudrait faire comme ça.
C'est pour ça que je pense qu'au lieu de respecter scrupuleusement un protocole il vaut mieux comprendre l'essence du truc et faire sa propre gestion de projet.
Parce que le Cycle en V pur et SCRUM pur, c'est pas top.

Si vous parlez de "méthode de travail agile" et que vous êtes flexible, c'est qu'il y a un peu de gestion de projet agile.
Selon comment on regarde : SCRUM c'est un peu plein de mini cycle en V itératifs.

De toute façon ça change selon le projet, selon l'équipe, selon le besoin, etc.
Il n'y a pas de méthode qui fonctionne dans tous les scénarios.

[Luckyluke34]

Malheureusement l'agilité est devenue un "buzzword" et des managers sont prêt à tout pour prétendre faire de l'agilité pour bien se faire voir et pour ça il n'y a rien de plus simple que de mettre en place la partie la plus visible de certaines méthodes. Le plus souvent les post-it sur un mur dans une zone de passage car ça en jette, les autres collègues qui passent devant sont impressionnés, on donne l'impression que l'on a mise place une organisation quasi militaire et que l'on croule sous le travail et puis les stands up du matin c'est pas mal non plus car c'est aussi très visible, d'ailleurs cela suscite toujours la curiosité ces groupes de paroles improvisés au milieux des autres collègue debout autour d'un gourou

Les méthodes agiles c'est surement bien si cela permet de répondre à certains problèmes d'organisation sur les projet mais je n'ai pas encore vu beaucoup de bénéfice sur les projets sur lesquels j'ai bossé jusqu'à présent. Si il y a quand même le Kanban implémenté sous forme logiciel, cela m'aide à mieux organiser mes objectifs pour la journée et je crois que mon chef de projet y gagne beaucoup en visibilité sur son équipe mais ça on le vois pas si l'on ne fait pas parti de l'équipe projet

Scoop(s) :

- Il n'y a pas de chef de projet en agile. La notion de "visibilité sur son équipe" n'a pas de sens.

- Les post-it sur les murs ou numériques ne font pas partie des méthodes agiles, c'est une pratique répandue mais connexe.

- Kanban != agile

[Pyramidev]

- Il n'y a pas de chef de projet en agile. La notion de "visibilité sur son équipe" n'a pas de sens.

C'est une interprétation extrême du principe « Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. » parmi les 12 principes sous-jacents au manifeste agile.
À mon avis, un chef de projet qui donne les priorités dans les grandes lignes est compatible avec l'agilité.

[Luckyluke34]

C'est une interprétation extrême du principe « Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. » parmi les 12 principes sous-jacents au manifeste agile.

Tu auras remarqué que je quotais Jitou sur un point précis :

"cela m'aide à mieux organiser mes objectifs pour la journée et je crois que mon chef de projet y gagne beaucoup en visibilité sur son équipe"

Sous-entendu : le chef de projet est quelqu'un qui flique quotidiennement les tâches individuelles de chaque membre de son équipe. Et les méthodes agiles l'y aident.

Non ! C'est même l'inverse. Un chef de projet ainsi décrit n'a pas sa place dans une organisation agile, c'est contre-productif. En agile, tout le monde a une visibilité sur l'avancement du produit, ce n'est pas une personne qui a une visibilité sur une équipe qu'elle micromanage.

À mon avis, un chef de projet qui donne les priorités dans les grandes lignes est compatible avec l'agilité.

Un chef de projet qui se contente de donner les priorités (sur quoi d'ailleurs ?) dans les grandes lignes n'est pas un chef de projet au sens où on l'entend le plus souvent dans les entreprises. Et c'est rarement l'attitude qu'un chef de projet "classique" va spontanément adopter si on le met à la tête d'une équipe dans un contexte agile. Les dizaines de récits sur l'agilité mal appliquée par le management qui peuplent ce forum sont là pour en témoigner.

[Saverok]

Tu auras remarqué que je quotais Jitou sur un point précis :

"cela m'aide à mieux organiser mes objectifs pour la journée et je crois que mon chef de projet y gagne beaucoup en visibilité sur son équipe"

Sous-entendu : le chef de projet est quelqu'un qui flique quotidiennement les tâches individuelles de chaque membre de son équipe. Et les méthodes agiles l'y aident.

Non ! C'est même l'inverse. Un chef de projet ainsi décrit n'a pas sa place dans une organisation agile, c'est contre-productif. En agile, tout le monde a une visibilité sur l'avancement du produit, ce n'est pas une personne qui a une visibilité sur une équipe qu'elle micromanage.

En Agile, et même surtout en Agile, il est indispensable de mesurer régulièrement la vélocité de l'équipe (et son évolution) et donner des points d'avancement au client et à la direction.
Le purs théoriciens de l'Agile vivent dans un monde éthéré où l'argent n'existe pas et où le temps est une notion aléatoire et infinie (je caricature un peu mais pas tant que ça ).
Bref, quelqu'un doit rendre des comptes, ce qui est, à mon sens, normal.
L'idéal de la méthode Agile serait que chacun assure ces tâches à tour de rôle car tout le monde a une vision de l'avancement mais dans les faits, on a une personne dédiée qui est là pour se prendre les skuds et autres joyeusetés car le projet n'avance pas assez vite ou ne prend pas la direction souhaitée, ...
Ce gus, c'est le CP.
Appelle le comme tu le souhaites mais saches qu'il est tjrs là.

Personnellement, je n'ai encore jamais vu une équipe 100% autogérée et auto-animée.
A un moment donné, l'équipe a besoin d'un leader qui entraîne les autres et lors des débats, on a besoin de quelqu'un qui sache faire la synthèse et puisse trancher si le consensus n'est pas là où s'il met trop de temps à se définir.

[Luckyluke34]

Le purs théoriciens de l'Agile vivent dans un monde éthéré où l'argent n'existe pas et où le temps est une notion aléatoire et infinie (je caricature un peu mais pas tant que ça ).

Schwaber et Sutherland (pour ne prendre que l'exemple des créateurs de Scrum) sont les mecs les plus intégrés dans l'orthodoxie capitaliste que je connaisse. Ils parlent de ROI à longueur de page et expliquent que leur méthode fait gagner des millions de dollars aux compagnies qui l'utilisent. Tout Scrum est tourné vers la création de valeur qui va permettre à un produit de prendre des parts de marché.

Par ailleurs, tu sembles accorder à la seule méthode de management command-and-control le monopole de la conscience du temps et de l'argent. Je ne vois pas le rapport.

Bref, quelqu'un doit rendre des comptes, ce qui est, à mon sens, normal.
L'idéal de la méthode Agile serait que chacun assure ces tâches à tour de rôle car tout le monde a une vision de l'avancement mais dans les faits, on a une personne dédiée qui est là pour se prendre les skuds et autres joyeusetés car le projet n'avance pas assez vite ou ne prend pas la direction souhaitée, ...
Ce gus, c'est le CP.
Appelle le comme tu le souhaites mais saches qu'il est tjrs là.

Le fait que tu ne précises même pas s'il s'agit de rendre des comptes et prendre des décisions au niveau technique, fonctionnel, organisationnel, financier, RH, administratif... montre bien que le schéma du chef de projet omnipotent a la vie dure.

Et si on distribuait différemment les responsabilités ?

Et si une personne responsable du produit se prenait les Scud relatifs au fonctionnel (retours utilisateurs, ROI...) et l'équipe de réalisation entière se prenait les Scuds relatifs ... à la réalisation ?

Je ne vois pas ce qu'il y a de si ahurissant à cela

[randriano]

Si je lis bien, il ne s'agit pas d'abandonner Agile mais abandonner les frameworks comme Scrum, XP, Kaban ou ... non??

Si je cite les 12 principes issus du Manifeste:

1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage
3. compétitif au client.
4. Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
5. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
6. Réaliser les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
7. La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
8. Les processus agiles encouragent un rythme de développement soutenable.
9. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
10. Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité.
11. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
12. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
13. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Et je prends le 7. Les processus agiles encouragent un rythme de développement soutenable

L'Agilité devrait limiter au maximum le stress côté développeurs non???

[el_slapper]

100% d'accord avec ce que tu dis mais ça on le faisait déjà avant qu'on lui donne le nom de "méthode de travail agile", des vrais cycle en V et des développement en mode sous marin pendant x mois je n'ai jamais vu, à un moment ou à un autre le client toujours inquiet voudra voir son bébé en cours de réalisation et forcement il va changer des trucs et remettre en cause les specs. (.../...)

Moi j'ai vu. Des specs de deux ans d'âge, donc obsolètes(pour une fois qu'Accenture avait fait du bon boulot, le client a attendu que ça ne soit plus applicable tel quel...), et le grand chef coté client refuse toute modification dessus au prétexte que "c'est ce qui a été signé, c'est donc ce qui sera fait, et ça va marcher". Et ça n'a pas marché, évidemment, ça ne collait plus à l'existant. soit c'était conforme, mais ça ne marchait pas. Soit ça marchait, mais ce n'était pas conforme. un projet de 60 personnes, prévu sur 18 mois. 6 ans plus tard, ils ont tout mis à la poubelle et recommençé sur d'autres bases(saines? Aucune idée, je sais juste qu'ils sont repartis d'une feuille blanche, 8 ans après qu'Accenture aie fait ses specs).

Effectivement, la plupart des clients sont plus sérieux que ça. Sorti un peu par hasard de cet enfer, je suis tombé chez un client pas folichon, mais quand je trouvait une erreur dans la specs, la réponse était "on va corriger la spec". Le Nirvana, en comparaison.

Le truc, c'est que les projets qui finissent en tunnel sous-marin complètement à coté de la plaque, ce sont souvent les plus gros, les plus visibles. Parce que l’ego du décideur est en jeu. Le projet Louvois, le système d'armement du F35 sont des sujets de ce genre, et qui foirent justement parce que le décideur s'implique pour que ça marche...et exige un plan de marche suivi scrupuleusement à la lettre. Ce qui amène a des aberrations comme celle que j'ai vécu sur ce projet spécifié par Accenture. Alors que quand on laisse les gens bosser et corriger les erreurs au fur et à mesure qu'elles sont détectées, ça se passe bien mieux.

- Il n'y a pas de chef de projet en agile. La notion de "visibilité sur son équipe" n'a pas de sens.(.../...)

vrai, mais les chefs de projet n'en ont rien à foutre. Ils veulent des gens à fouetter, et le fouet à la mode s'appelle "agile", dans leur esprit autoritaire.

[randriano]

Je suis fan de l'esprit Agile mais je n'aime pas du tout la représentation de la méthode incrémentale de l'Agile suivante:


Cette image prête à confusion des gens leur faisant dire que je ne veux pas d'un skateboard en attendant une voiture. Cette illustration donne parfois raison au cycle V d'attendre jusqu'à la fin au lieu d'incrémentalement à chaque sprint

Ou insistez-vous que c'est la bonne représentation??

[Ryu2000]

je ne veux pas d'un skateboard en attendant une voiture

Le truc c'est de dire au client "Regardez on a développé une fonction que vous avez demandez. Est-ce que ça répond toujours à vos besoins ?". C'est loin d'être fini, mais il y a un truc utile qui est déjà là.
Avec l'agile on peut réorienté le projet avec l'évolution des besoins.
Mettre un peu d'agile dans la gestion du projet ça permet de développer une solution qui répond vraiment aux besoins.

Sans aucune agilité c'est hyper rigide. Tu livres ce qu'il y a dans le cahier des charges, donc il y a de grandes chances pour que ça tombe à côté des besoins du client...

[an1844]

bonjour à toutes et à tous,

Le truc c'est de dire au client "Regardez on a développé une fonction que vous avez demandez. Est-ce que ça répond toujours à vos besoins ?". C'est loin d'être fini, mais il y a un truc utile qui est déjà là.
Avec l'agile on peut réorienté le projet avec l'évolution des besoins.
Mettre un peu d'agile dans la gestion du projet ça permet de développer une solution qui répond vraiment aux besoins.

Sans aucune agilité c'est hyper rigide. Tu livres ce qu'il y a dans le cahier des charges, donc il y a de grandes chances pour que ça tombe à côté des besoins du client...

Cette dernière contribution m'encourage à intervenir dans votre discussion.

Mais force est de constater ... que je suis l'intrus ... je suis un client.

En fait je représente plutôt un client, je ne suis pas le chef de projet client (il y en a 1 de désigné), je ne suis qu'un "chargé de projet", je vous laisse faire le distinguo.
Le chef de projet du coté développeur, c'est chargé poliment de me remettre à ma place, mes demandes semblaient l'agacer.
j'imagine qu'un chef de projet se doit de recevoir des "commentaires" (tickets) que d'un autre chef de projet.

Je me suis permis d'ouvrir une discussion sur ce même forum.
https://www.developpez.net/forums/d2...-informatique/
Si vous avez du temps je veux bien un coup de clavier.

merci de votre attention
an1844

[Ronny1212]

On ne change pas une methode qui marche