Discussion :

[crica]

Et je suis d'accord avec ceux qui partagent qu'il n'y a pas UNE méthode mais des RÉSULTATS ! Si une société a une équipe qui fonctionne et délivre, pourquoi devrait-elle changer de méthodologie... on ne change pas une équipe qui gagne !

Ce qui est intéressant dans l'agilité c'est que les équipes échangent chaque jour, qu'elles devraient oser remonter leurs problèmes et questions et que personne ne devrait être isolé.... moi, j'ai compris ça dans le sens de la confiance.

Lorsque l'on a connu le travail au sein d'une équipe de confiance... on ne peut qu'aimer cela, traditionnel vs moderne que soit la méthode.

Par contre, aujourd'hui, je vois pas mal de gens dysfonctionner parce que la confiance n'est pas là et dans ces conditions, bonjour les résultats pas terribles et la déception des équipes !

Enfin, ce n'est que mon humble avis
Bravo d'avoir soulevé le point.
Cheers,
CR

[Jamatronic]

Vous êtes un génie, beau, grand, fort et intelligent.

Vous avez fait partie de ceux qui ont "inventé" l'agile.

Vous avez expliqué au monde votre trouvaille.

Des milliers de gnous s'en sont emparé et ont fait de la merde.
Et c'est normal, ce sont des gnous.

Vous publiez donc que :
"l'agile c'est bien, mais les gnous en font de la merde.
S'il vous plait, les gnous, arrêtez de faire de la merde."

Ca va changer quoi ?

Les gnous font tourner le monde ! Les gnous sont nombreux ! Les gnous, c'est nous !

[Pyramidev]

Hors sujet : d'où vient le mème qui consiste à qualifier de gnous les personnes incompétentes ? el_slapper l'utilise souvent sur ce forum pour parler de candidats dans le contexte du recrutement de développeurs. Mais, en dehors de ce forum, je n'ai vu nulle part cet usage du mot gnou.
D'ailleurs, quand el_slapper utilise le mot gnou pour un développeur, ce n'est pas pour ceux qui ont un niveau autour de la moyenne, mais ceux qui ont un niveau très en dessous.

[foetus]

Hors sujet : d'où vient le mème qui consiste à qualifier de gnous les personnes incompétentes ?

Effectivement il n'y a presque rien, mais c'est, en gros, le "mouton" africain

D'ailleurs j'ai trouvé la définition de Marc Jolivet

Gnou
Gnou (d'après Larousse) : nom masculin. Antilope d'Afrique à tête épaisse et cornes recourbées.
Ma définition : Gnou, animal votant de la famille majorité silencieuse. N'est pas le pluriel de goy. À un regard asexué imprégné de mollassonnerie consensuelle. Politiquement, se situe entre le veau et le mouton. L'espèce n'est nullement en voie de disparition, l'animal se reproduisant avec la rapidité des lapins.

Et en plus tu peux trouver des vidéos de son spectacle gnou - 1997 (lien youtube: youtube.com/watch?v=WhXRe-NXO0w)

[Excellion]

Pour ma part, en tant que développeur, je suis passé complètement à côté de ces méthodes de gestion de projets (méthodes agiles).

Tout ce dont j'en ai entendu parler, ce sont nos prestataires, qui gavés de mots d'anglais, nous baladaient.
Les projets prenaient un retard incroyable, ils bossaient directement en production (sites web), pas de documentation, pas de possibilité de transmettre à une autre équipe ce qui avait été fait, pas de concrétisation des demandes, bref, un vrai festival.


Je me suis donc, légèrement, penché sur SCRUM.
Et là stupeur!

Vous passez votre vie en réunion.

Imaginez dans une PME, avec une équipe de 2 ou 3 développeurs, qui doivent faire des réunions debout devant la machine à café, l'image.
Et demandez à un employeur déjà surchargé de faire une réunion par mois pour voir l'avancée des travaux...

Tout est fait pour développer au plus vite, avec les tares que cela peut donner en terme de conception.
Effectivement l'absence de documentation technique ou fonctionnelle est prévisible, puisque tout est fait dans le but de livrer le produit au plus vite.


J'ajouterai, qu'il n'existe pas vraiment, dans ce modèle, de responsable désigné. Tous un peu responsable, donc personne ne l'est vraiment.
Qui décide? Le Product Owner? Qui n'y connait rien? Le Scrum Master? Les développeurs? Une tierce personne?


En tout cas, je m'explique mieux pourquoi quand je vais dans une banque, la personne qui est en charge de mon dossier est obligée de s'y reprendre à 5 ou 6 fois pour faire une évaluation.

Le logiciel est truffé de bugs, est sensible à la casse quand il ne le devrait pas, accepte le html, au risque de planter tout le système…

Manifestement, le but est vraiment de faire passer la qualité au second plan.

En tout cas, c'est comme cela que je l'ai vu et vécu, en tant que client.

[Luckyluke34]

(zip)

Je ne sais pas ce que tout ça est censé décrire, en tout cas certainement pas Scrum.

Ah, si, sur l'aspect "faire une réunion par mois". Breaking news : si ton client (ou toi) est trop surchargé pour assurer ce minimum de présence, c'est que le projet n'est pas vraiment important à ses yeux. On est dans le génie logiciel, pas sur le chantier d'un chalet en rondins.

[levolutionniste]

Bonjour,
Version courte :
Developpez.net pourrait mieux choisir ses titres, tout au moins être plus clair.

Version longue :

Quelqu'un peut-il m'expliquer pourquoi dans un forum de développeurs les titres de news sont comme des titres de journaux ... comme des titres trompeurs?

Lire ce titre ci :

Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries

pour ensuite lire ceci (la pensée réelle de Ron Jeffries):

Les développeurs devraient adopter les principes de base du Manifeste Agile indépendamment d’un framework ou d’une méthode dans le développement d’application comme cela était pensé initialement par les signataires du Manifeste. Cela permet aux développeurs de s’épanouir dans leur travail. Le logiciel étant fonctionnel à tout moment, d’importants travaux d’extension peuvent être effectués dans un délai assez raisonnable. Au mieux, Ron Jeffries propose d'utiliser l'Extreme Programming qui tient compte de la gestion de projet dans la réalisation de l'application.

Je vous le concède il y a beaucoup de différences, notamment des zones floues à éclaircir (méthodes, frameworks, pratiques, manifestes, tirer le meilleur) mais on pourrait facilement ce dire que la motivation de l'auteur de developpez.net est de nous faire lire même ce qui ne vaut pas la pein.

[Pyramidev]

SCRUM est défini par le guide SCRUM qui a le mérite d'être gratuit et court (19 pages en PDF). Pour défendre ou critiquer SCRUM, dans les deux cas, il faut le lire.

Dans le message de Excellion :

« Vous passez votre vie en réunion. » correspond au Sprint Planning, au Daily Scrum, à la Sprint Review et à la Sprint Retrospective. Attention, un sprint ne dure pas forcément un mois. Il dure au maximum un mois, mais peut être plus court.

« il n'existe pas vraiment, dans ce modèle, de responsable désigné » est effectivement une des caractéristiques de SCRUM : « Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. »

Par contre, « le but est vraiment de faire passer la qualité au second plan », ça reste à prouver. Dans SCRUM, l'équipe de développement est auto-organisée et c'est elle qui estime les durées des développements :

• « They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality »
• « Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. [...] The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate. »

Donc, si l'équipe décide qu'il faut travailler correctement (revue de code par les pairs, tests unitaires, etc.) et que les estimations sont faites en fonction de cela, alors cela facilite le long-terme.

Cela dit, en développement logiciel, parmi les entreprises qui affirment appliquer SCRUM, ça me surprendrait qu'il y en ait beaucoup qui confient les estimations des durées des développements aux développeurs.

[Ryu2000]

on pourrait facilement ce dire que la motivation de l'auteur de developpez.net est de nous faire lire même ce qui ne vaut pas la pein.

Chaque news avec dans le titre "selon" ou "d'après", c'est quasiment du People.
C'est l'avis d'un type random (parfois c'est juste un article de blogue).

Bon là c'est pas totalement un mec random puisque c'est un des 17 signataires du Manifeste pour le développement Agile de logiciels. En 1996 il faisait parti des 3 qui ont créé l'Extreme programming.

===
Mais peu importe, parce que ça lance un vrai débat sur la gestion de projet. (la citation du mec au début c'est qu'un prétexte pour parler de gestion de projet)
Les gens peuvent défendre leur point de vue, ll y a des grandes familles :

• Cycle en V
• Cycle en spirale
• Cycle semi-itératif
• Cycle itératif

Parfois la méthodologie est mal appliqué (que ce soit en cycle en V, en Kanban, en Extreme Programming ou ce que vous voulez).

Bon apparemment il n'y a pas de méthode miracle, ça change selon le projet, le client, l'équipe, etc.
Personnellement je trouve qu'il est plus facile de trouver des arguments contre le Cycle en V que pour le Cycle en V, par exemple.
Mais beaucoup de gens défendent le cycle en V et ont des bons arguments.

Moi j'aime bien quand c'est un peu itératif.

[Luckyluke34]

« il n'existe pas vraiment, dans ce modèle, de responsable désigné » est effectivement une des caractéristiques de SCRUM : « Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. »

La formulation d'Excellion est beaucoup trop vague. Responsable... de quoi ? De la coordination et du process Scrum en lui-même ? => le Scrum Master. Des choix métier et du ROI du produit ? => le PO. De la réalisation ? => l'équipe de dev.

Scrum définit bien des responsabilités pour ces rôles mais ne va pas au-delà car ce n'est pas son taf. Si on cherche un fusible qui va payer pour les autres parce qu'on a livré de la m...e, ce n'est pas dans Scrum qu'on va le trouver. Etonnant, non ? (et incroyable mais vrai: on ne va pas non plus le trouver en cycle en V, Waterfall, Lean, etc. etc.)

[GreatDeveloperOnizuka]

Perso je trouve que les méthodo agiles sont pas mal mais pas plus que d'autres méthodo. L'importance c'est toujours les mecs qui bossent dessus. S'ils sont bons, qu'ils fassent du waterfall ou cycle en V, je pense qu'on sentira pas vraiment la différence

[Pill_S]

J'ai toujours été dubitatif sur la mise en place de l'agilité, pour l'avoir vécue et subie comme un échec dans 3 entreprises successives.

Les bases sont bonnes (faire communiquer les gens, ne pas les empêtrer dans des docs inutiles, faire fonctionner le soft plutôt que de trop le spécifier, accepter le changement ...)

Le résultat, bien souvent c'est que 1) on force les gens à communiquer alors qu'ils travaillent sur des tâches sans rapports les unes aux autres (qu'est-ce que je m'en fous de savoir que Serge a déployé son web service que je n'utilise pas, ou que Sophie a fini de tester une appli qui n'est pas chez moi!!) 2) on n'a plus du tout de doc parce qu'on n'a jamais plus pris le temps d'en faire (ou alors on est submergé par des tonnes de Sprint Review que personne ne lit jamais) et 3) un soft qui fonctionne là tout de suite mais comme tout le monde change d'avis tout le temps (c'est carrément encouragé par la méthode!) et qu'on encourage la pensée à court terme, ça tiendra pas longtemps

Le seul grand gagnant de l'histoire, c'est le chef de projet (ha non pardon on dit Scrum Master :/) qui ne doit plus faire le forcing pour avoir les infos d'avancement: tous les matins, il a son petit point de situation perso (au passage, qui bloque 10 personnes pendant 30 minutes)

Bref, moi perso, quand on me dit que l'agilité va règler tous les problèmes du monde, j'me fend la gueule et je vais poser ma pêche (pendant que les autres discutent de plein de choses passionnates mais inutiles)

[Luckyluke34]

Tu viens de confirmer en quelques lignes le “Agile” ideas are applied poorly à la base du billet de Jeffries.

1) on force les gens à communiquer alors qu'ils travaillent sur des tâches sans rapports les unes aux autres (qu'est-ce que je m'en fous de savoir que Serge a déployé son web service que je n'utilise pas, ou que Sophie a fini de tester une appli qui n'est pas chez moi!!)

Ce n'est pas le but des daily meetings, normalement c'est une équipe de dev centrée autour d'un unique produit qui échange sur l'avancement du sprint avec un but partagé par tout le monde. Si la communication est inefficace, on l'évoque en rétrospective et on arrête de faire ces choses qui ne servent à rien.

ou alors on est submergé par des tonnes de Sprint Review que personne ne lit jamais)

La sprint review n'est pas un document mais une réunion. De plus, si un document n'est lu par personne, on l'évoque en rétrospective et en général on décide de l'abandonner (élimination du gaspillage).

un soft qui fonctionne là tout de suite mais comme tout le monde change d'avis tout le temps (c'est carrément encouragé par la méthode!)

Tout le monde, non : une seule personne décide des besoins métier, le Product Owner. Tout le temps, non : il doit se responsabiliser et réaliser que ça coûte cher de changer des fonctionnalités. Encouragé par la méthode, non : autorisé tout au plus.

Le seul grand gagnant de l'histoire, c'est le chef de projet (ha non pardon on dit Scrum Master :/)

Perdu, le Scrum Master n'est pas un chef de projet. Il n'est pas un chef (pas hiérarchiquement au-dessus de l'équipe), il n'a pas la maîtrise du budget ni des ressources humaines, ne flique pas les membres de l'équipe, etc.

tous les matins, il a son petit point de situation perso (au passage, qui bloque 10 personnes pendant 30 minutes)

Alors la taille recommandée d'une équipe Scrum c'est 7 personnes +/-2 et la durée conseillée du daily meeting c'est 15 minutes. Si la réunion traine en longueur et qu'on bloque des gens qui n'ont pas à être là, on l'aborde en rétrospective et on trouve une solution pour laisser les gens faire leur boulot.

Bref, moi perso, quand on me dit que l'agilité va règler tous les problèmes du monde, j'me fend la gueule et je vais poser ma pêche

Ca ne règle pas tous les problèmes du monde, ça les fait remonter à la surface (en augmentant la communication et la capacité à réfléchir sur son propre fonctionnement).

[Pill_S]

Je connais les principes de la méthode. Je mettais juste en évidence, sur un ton quelque peu ironique je te l'accorde, les dérives que je vois au quotidien dans l'application de la méthode.

Nous sommes une équipe de +/- 15 personnes, réparties sur 2 sites distants, et tout le monde travaille sur soit de la maintenance et de petites évolutions, sur du dév de nouvelles applications. Le Scrum Master n'a pas envie de gérer autant de daily meeting qu'il y a de sujet, donc tout le monde se retrouve en même temps le matin en vidéo conférence. Sur les 15 minutes du daily, je parle environ 4 secondes et tout le reste du temps je poireaute en écoutant des gens parler de sujets que je ne comprends pas... C'est frustrant et pas gratifiant. Et ça c'est au quotidien depuis des mois voir des années. Aucun intérêt mais comme il faut respecter la méthode, je continue à y aller, et à m'y ennuyer.

Combinée avec une interprétation exotique du principe de changement par certains PO, le résultat c'est que tout change tout le temps et on réfléchit à court terme (à coup de POC et de MVP). Donc les avantages de Agile versus cycle en V, vu du point de vue du développeur, ne sont pas flagrants. C'est même exaspérant parfois, les bonnes choses du V ont disparues et aucune des bonnes choses de Agile ne sont apparues.

Pour moi il manque de la rigueur et de l'éducation pour que cela ait un intérêt. J'attends impattiemment de voir appliquer l'agilité correctement, mais là je commence à saturer (bientôt 10 ans de pseudo-agilité et pas de ROI, ça me conduit à devenir moqueur envers les évangélistes Agile)

Après chacun est libre de croire en ce qu'il veut

[Ryu2000]

Je mettais juste en évidence, sur un ton quelque peu ironique je te l'accorde, les dérives que je vois au quotidien dans l'application de la méthode.
(...)
J'attends impattiemment de voir appliquer l'agilité correctement

Donc le problème c'est la mauvaise application du concept et pas le concept en lui même.
Il faut que tu fasses remonter à tes supérieurs que SCRUM est mal appliqué.
Ou au moins dire à ton Scrum Master qu'il fait de la merde.

[Pill_S]

Disons que ces dérives ne sont pas le seul fait de mon Scrum Master. Difficile de le blâmer lui personnellement, quand les 5 derniers que j'ai côtoyé tombaient dans les mêmes travers. Que dire d'une méthode si difficile à appliquer que personne n'y est arrivé en 10 ans? Faut-il blâmer la méthode ou les personnes qui échouent à l'appliquer?

Plein de bons sentiments dans l'agilité, mais pratiquement une utopie selon moi.

[Luckyluke34]

Que dire d'une méthode si difficile à appliquer que personne n'y est arrivé en 10 ans?

Qu'elle n'est pas adaptée à votre contexte ?

Honnêtement, utiliser Scrum pour "une équipe de +/- 15 personnes, réparties sur 2 sites distants, où tout le monde travaille sur soit de la maintenance et de petites évolutions, sur du dév de nouvelles applications", c'est un peu comme faire du basket sur un terrain de foot. Et dans ce cas-là, on n'accuse pas les règles du basket.


Il faut faire le point sur ce que vous voulez garder de l'agilité mais vous tourner vers d'autres méthodos qui répondent mieux à vos problèmes. Mais il faut le faire maintenant, pas attendre passivement qu'agile soit passé de mode, décrié par des gens qui l'appliquent mal, et que quelqu'un ait trouvé *ze* next méthode qui bien sûr subira le même sort...

[Matthieu76]

Ron Jeffries estime qu’il est temps de passer à autre chose.

Et faire quoi ? De la couture ? Dire que c'est nul sans rien proposer de mieux c'est inutile, je n'appellerais même pas cela une critique !
Il y a un truc qui est plus nul que la méthode Agile, c'est ne pas avoir de méthode du tout !!!!

PS : Dans mon travail la méthode agile fonctionne parfaitement, permet de m'épanouir, fait gagné du temps et donne de la visibilité sur différent les projet à venir. Personnellement je n'ai rien à redire sur cette méthode

[Jitou]

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

[Ryu2000]

je n'ai pas encore vu beaucoup de bénéfice sur les projets sur lesquels j'ai bossé jusqu'à présent.

Si votre gestion de projet n'est pas agile, est-ce que ça veut dire que le cahier des charges n'évolue jamais ?
Est-ce que vos projets durent longtemps ?

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.