Discussion :

[Ryu2000]

De part mon expérience personnelle, les risques d'échec avec les méthodes Agile (SCRUM ou autres) sont plus importants qu'avec les méthodes classiques du genre cycle en V.

Je ne suis pas d'accord.
Si on applique le cycle en V strict (je fais la conception à 100% avant d'écrire la moindre ligne de code), qu'on a les informations au début et après plus rien, il y a trop moyen de se planter.
Je l'ai déjà dis, mais le client a mal exprimé ses besoins (il n'a pas demandé se dont il avait besoin, il a demandé des choses qu'il n'a pas besoin) et de toutes façons ses besoins ont changé pendant le développement.

Le côté cool de Scrum c'est que régulièrement le client voit l'avancement du projet et peut donner des indications vers où se diriger.
On commence par les fonctions principal, c'est la première chose qu'on doit montrer au client.
Vous pouvez proposer des choses au client qui lui seront utile, mais auquel il n'avait pas pensé.

Quelque part les méthodes agiles c'est un peu un tas de cycle en V itératif.
Si on veut on peut faire un cycle en V par fonction, en quelque sorte...

[el_slapper]

Merci à Saverok et Ryu d'appuyer mon point, chacun défendant sa paroisse à coup d'anecdotes. J'aurais tendance à penser comme Ryu, mais la réalité, c'est que tant qu'on a pas fait de mesures sérieuses et massives, on pisse tous dans des violons autant qu'on est.

[Ryu2000]

Non mais le cycle en V strict c'est de définir un truc au début et de s'y tenir jusqu'à la fin.
Tu livres exactement ce que t'as dis que t'allais livrer... Donc c'est n'importe quoi !

Vous imaginez comme c'est compliqué d’exprimer son besoin ?
Il faut que le client soit fort pour savoir ce dont il aura besoin dans le futur.
Et les avancées technologique ne seront pas prisent en compte.

Je pense que le mieux c'est de la faire de la gestion de projet battarde, il faut des objectifs à court terme et des objectifs à moyen terme.
Cycle en V strict et SCRUM strict c'est de la merde pour un projet informatique.
Il faut faire de l'agile mais ne pas respecter le moindre détail de la méthode, il faut avoir un peu de liberté.
Après je m'en fous je ne suis pas chef de projet.

Le cycle en V c'est tip top pour construire un bâtiment en 1980

[pascal-od]

Il n'y a pas de bonne ou de mauvaises méthodes pour mener un projet à sa fin. Il y a des méthodes qui sont adaptées ou non pour chaque projet et pour chaque équipe. La méthode agile (ou n'importe quelle autre) peut fonctionner très bien sur le projet A avec l'équipe alpha et mener au désastre sur le même projet A avec l'équipe gamma.
Le CP doit connaitre son équipe, ses qualités et surtout ses défauts, et trouver la bonne méthode à utiliser selon le projet.

[Ryu2000]

La méthode agile (ou n'importe quelle autre) peut fonctionner très bien sur le projet A avec l'équipe alpha et mener au désastre sur le même projet A avec l'équipe gamma.

Ouais mais au moins avec les méthodes un peu agile tu peux rectifier le tir si t'as loupé la première étape de conception...
Si t'as un mauvais cahier des charges et que tu bases tout la dessus, ton logiciel ne va pas être terrible.
Il faut au moins présenter régulièrement les avancées du projet au client pour qu'il puisse dire "En fait j'ai pas besoin de la fonction A, mais j'ai besoin d'une fonction B".

[pascal-od]

Ouais mais au moins avec les méthodes un peu agile tu peux rectifier le tir si t'as loupé la première étape de conception...
Si t'as un mauvais cahier des charges et que tu bases tout la dessus, ton logiciel ne va pas être terrible.
Il faut au moins présenter régulièrement les avancées du projet au client pour qu'il puisse dire "En fait j'ai pas besoin de la fonction A, mais j'ai besoin d'une fonction B".

Si la conception du projet est mal faite il faut revoir la conception. Si le cahier des charges est mauvais c'est le cahier des charges qu'il faut revoir. Rassures-moi, on parle bien de réaliser un projet dans un cadre professionnel ?

[Ryu2000]

Rassures-moi, on parle bien de réaliser un projet dans un cadre professionnel ?

Les besoins sont parfois mal exprimés par le client, les besoins sont parfois mal compris par les développeurs.
Il peut donc arriver qu'il y ait des erreurs dans le cahier des charges.

En montrant le projet au client, il peut se rendre compte qu'il a demandé des choses dont ils n'a pas besoin et qu'il a oublié des choses dont il a besoin.
De toute façon le besoin du client évolue pendant le développement.
Des nouvelles idées apparaissent pendant le développement.

Avec les méthodes agile le premier truc que tu montres au client c'est la fonction principale, donc c'est facile de bien orienter le projet.

[pascal-od]

Les besoins sont parfois mal exprimés par le client, les besoins sont parfois mal compris par les développeurs.
Il peut donc arriver qu'il y ait des erreurs dans le cahier des charges.

En montrant le projet au client, il peut se rendre compte qu'il a demandé des choses dont ils n'a pas besoin et qu'il a oublié des choses dont il a besoin.
De toute façon le besoin du client évolue pendant le développement.
Des nouvelles idées apparaissent pendant le développement.

Avec les méthodes agile le premier truc que tu montres au client c'est la fonction principale, donc c'est facile de bien orienter le projet.

Oui, oui je comprends très bien ce que tu veux dire.
Mais choisir une méthode en particulier parce que ça permet de corriger les erreurs ou omissions faites en amont signifie pour moi que le problème se situe ailleurs.
Le client n'a pas à savoir exprimer ses besoins, ce n'est pas son métier. C'est le prestataire à qui il fait appel qui doit être capable de l'amener à exprimer correctement ses besoins. Ensuite ce prestataire doit être capable d'expliquer le cahier des charges au client et s'assurer qu'il est bien en adéquation avec sa demande et ses besoins. C'est un travail préalable essentiel, pour lequel il faut prendre son temps.
Ensuite une méthode, agile ou non, n'est qu'un cadre formel dont il faut savoir s'échapper pour mener à bien un projet.

[Ryu2000]

Ensuite une méthode, agile ou non, n'est qu'un cadre formel dont il faut savoir s'échapper pour mener à bien un projet.

Ouais, mais ce que je dis c'est que sur un point précis les méthodes agiles sont supérieurs au cycle en V, car le client suit le projet, test le projet, fait des retours et par conséquent il n'y a pas de surprise à la fin.
Après le cycle en V a peut être des avantages sur certains points.

Mais dans l'ensemble c'est moins motivant, comme les objectifs sont énorme, il peut arriver que les développeurs perdent de la motivation et finissent par rusher pour que la livraison soit prête à temps.
Alors qu'avec SCRUM tu peux faire des petits sprints de 2 semaines, ça fait des objectifs plus court et des "récompenses" plus fréquentes (t'es content t'as atteint ton objectif).

Mais sinon c'est ce que je dis, il ne faut pas suivre les méthodes de gestion de projet à la lettre.

[Saverok]

Mais choisir une méthode en particulier parce que ça permet de corriger les erreurs ou omissions faites en amont signifie pour moi que le problème se situe ailleurs.

Pourquoi partir du principe qu'il y a un problème ?
Il arrive assez souvent que volontairement, le besoin détaillé reste flou lors de la définition générale du besoin et cela n'a rien de spécifique à l'info.

Lorsque tu fais construire une maison par exemple, tout n'est pas détaillée à l'avance.
Tu as le gros oeuvre évidement.
Tu sais où va se situer les pièces d'eau et la cuisine, par exemple, mais tu ne détailles pas leur aménagement dès le début du chantier.
Les plans détaillées de la cuisine se font même le plus souvent une fois le gros oeuvre terminée car c'est du sur mesure et lors de la réalisation du gros oeuvre, une cloison peut parfaitement bouger de quelques centimètres.
Je ne parle même des finitions telles que la couleur des murs et les revêtements de sol qui peuvent parfaitement être décidés au dernier moment.
etc.

Un projet info, c'est exactement la même chose.

Le client n'a pas à savoir exprimer ses besoins, ce n'est pas son métier.

Bien sûr que si.
C'est pas à ton boulanger de décider à ta place du type de pain et de la quantité que tu vas manger.

En tant que client, tu sais que tu as besoin de pain et pour quel usage.
Le boulanger est là pour t'aider à affiner le choix par le conseil et en te posant des questions pertinentes pour orienter et spécifier ton besoin.
Mais au final, le besoin est bien le tien et c'est bien toi qui y met un point final ou pas.

Pourquoi cela serait il différent en info ?

C'est le prestataire à qui il fait appel qui doit être capable de l'amener à exprimer correctement ses besoins. Ensuite ce prestataire doit être capable d'expliquer le cahier des charges au client et s'assurer qu'il est bien en adéquation avec sa demande et ses besoins. C'est un travail préalable essentiel, pour lequel il faut prendre son temps.

Juste pour info : il existe énormément de situation où la MOA est interne à l'entreprise cliente.
Tout le monde ne fait pas de la prestation tout azimut, y compris dans l'info.

La plupart des mini projets que je réalise sont 100% interne à ma société.
Le service métier qui exprime son besoin à la DSI est interne.
La MOA qui spécifie le besoin est interne.
Je suis un CP et RA interne et une partie de mon équipe, y compris quelques dev / concepteurs et architectes, est interne.

Ensuite une méthode, agile ou non, n'est qu'un cadre formel dont il faut savoir s'échapper pour mener à bien un projet.

Inutile de s’échapper. Personne n'est prisonnier de quoique ce soit.
Ce qu'il faut c'est s'adapté et la nuance est grande.

La méthode à adopter n'est pas uniquement à sélectionner en fonction de l'équipe MOE mais à l'ensemble des acteurs du projet et cela va des utilisateurs, à la MOA, MOE et jusqu'à l'équipe d'exploitation et de déploiement.
C'est bien beau de vouloir faire de l'itératif mais si la MOA et les utilisateurs ne sont pas disponibles pour tester et valider la solution à chaque fin de sprint, on va dans le mur.
etc.

[cihinel]

Dans ma boite, la méthode SCRUM a plutôt été utilisée comme couverture à notre désorganisation

Des cycles courts pour cacher que l'on changeait tout le temps d'objectif et qu'il fallait donc sans cesse recommencer, des équipes réduites pour cacher le manque de moyen,des sprints pour cacher que l'on était incapable de planifier et de prévoir des objectifs et une stratégie, et qu'il fallait donc tout traiter dans l'urgence.

Beaucoup d'entreprises ne font que réparer toutes les catastrophes de la journée et leur sensation de courir en rond est juste une méthode moderne très tendance.

A chaque plantage, on sortait la phrase : « il faut être agile ! », ce qui voulait juste dire «on est mauvais mais on est dans l'air du temps...»

Le vrai succès vient de l'écoute des équipes, de la confiance, d'une bonne équipe, d'un bon capitaine. Au bout de 5 échecs et plusieurs démissions, n'hésitez pas à remettre en question le capitaine.

Ha oui, j'oubliai de dire, ma boite n'a rien à voir avec la programmation, si ce n'est ceux des échecs.

[el_slapper]

[B]Dans ma boite, la méthode SCRUM a plutôt été utilisée comme couverture à notre désorganisation(.../...)

Enfin, ça, c'est vrai de toutes les modes organisationnelles. La meilleure méthode du monde, appliquée par des gnous, ne donnera aucun résultat. Tiens, parallèle avec le football. La meilleur équipe d'Europe, en ce moment, semble être le Real Madrid, qui joue généralement en 4-4-2 diamant. Tu prends 10 tocquards et tu me rajoutes dans les buts, et on va prendre pilée sur pilée. Même si on joue en 4-4-2 diamant.

L'organisation n'est qu'un choix de squelette, si les muscles(i.e. les gens qui bossent) ne suivent pas, il n'y aura jamais de résultat.

[Luckyluke34]

A part générer du flamewars pour le plaisir, je vois vraiment pas l'intérêt de déterrer un billet de blog ouvertement provocateur et trollesque d'il y a plus de 2 ans.

D'autant que celui-ci est un tissu d'absurdités fallacieux de bout en bout (il se le fait d'ailleurs copieusement rappeler dans les commentaires).

Scrum, in accounting for all the engineer’s time in a tightly managed fashion

Ben non, Scrum ne dit absolument rien sur la mesure du temps passé et encore moins le temps passé individuellement par chaque membre de l'équipe

Scrum encourages “least amount of work possible” solutions 

Cette phrase ne veut strictement rien dire si on ne met pas en face ce qu'on s'attend à obtenir une fois le travail, fut-il le moindre possible, fini. Or Scrum permet de spécifier tous les critères imaginables de qualité, de performance, etc. "The least amount of work" pour un produit en or massif peut donc très bien être une masse de travail considérable si c'est ça que le client exige.

By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and/or ownership of their work. 

Comprends pas. Les items ont beau être faisables par tout le monde, au bout du compte, c'est bien un dev en particulier (ou un binôme) qui l'a réalisé non ? Ou est la perte de fierté du travail effectué ?

Scrum is highly intolerant to modification

Une méthode qu'on peut modifier en tous points est-elle encore une méthode ? Le document décrivant l'intégralité du cadre fait une quinzaine de pages en tout et pour tout, et dedans il y a des parties prescriptives mais aussi des recommandations ou des choix laissés à l'implémenteur. On ne peut pas dire que beaucoup de process soient aussi légers.

Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads

Mauvaise pioche. Le Team Lead n'est pas dans Scrum. Le Product Owner, c'est le client. Cela laisse... un rôle, le Scrum Master, qui n'est pas un rôle de management.

Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on?

Ben non mais en même temps Scrum ne demande à personne de faire ça. Les estimations recommandées c'est sur les product backlog items (pas les tâches) et c'est à grosses mailles. Pas de tracking.

Are they required to do bi-weekly sell-off meeting to justify their activities?

Idem, ce n'est pas dans la méthode.

It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand-holding.

Cette obsession du task tracking qui encore une fois n'est pas dans la méthode

etc. etc.

[Saverok]

Enfin, ça, c'est vrai de toutes les modes organisationnelles. La meilleure méthode du monde, appliquée par des gnous, ne donnera aucun résultat. Tiens, parallèle avec le football. La meilleur équipe d'Europe, en ce moment, semble être le Real Madrid, qui joue généralement en 4-4-2 diamant. Tu prends 10 tocquards et tu me rajoutes dans les buts, et on va prendre pilée sur pilée. Même si on joue en 4-4-2 diamant.

L'organisation n'est qu'un choix de squelette, si les muscles(i.e. les gens qui bossent) ne suivent pas, il n'y aura jamais de résultat.

Ce qui me gêne avec ta métaphore c'est qu'elle suggère que tout est entre les mains de l'équipe opérationnelle et donc responsable de la réussite ou de l'échec du projet sans tenir compte de tout l'environnement autour.

Pour reprendre ta comparaison, un club de foot, ce n'est pas juste les joueurs.
Il y a tout le staff du club, les dirigeants, le club de formation, les infrastructures, les clubs de supporter, etc.
Les joueurs sur le terrain ne sont que la partie visible de l'iceberg.

Un projet info, c'est la même chose.
On ne peut pas tout résumer aux dev et concepteurs et c'est particulièrement vrai dans le cas des projets en méthode Agile.
Tu auras beau avoir une équipe d'experts en dev, si la MOA ne suit pas, que le CP est une quiche et que tu les installes dans un sous sol mal éclairé avec des chaises de merde et un PC qui compile le projet en 45min dès le premier sprint, ton projet ira dans le mur (et tu peux être sûr que tes dev vont donner leur lettre de dem les uns après les autres).

[el_slapper]

Ce qui me gêne avec ta métaphore c'est qu'elle suggère que tout est entre les mains de l'équipe opérationnelle et donc responsable de la réussite ou de l'échec du projet sans tenir compte de tout l'environnement autour.(.../...).

Tu as 100% raison, mais ça ne fait que renforcer ma conclusion : une bonne méthode, ça ne sauve pas une situation où d'autres éléments sont défectueux. SCRUM est souvent vendu comme la solution miracle qui va sauver tous les projets informatiques de l'univers, alors que si il y a des manques par ailleurs(au niveau de l'équipe elle-même comme je l'ai souligné, ou au niveau de toute ce qu'il y a autour comme tu le soulignes fort justement), eh bien ça ne va rien sauver du tout.

[Marco46]

Tiens, parallèle avec le football. La meilleur équipe d'Europe, en ce moment, semble être le Real Madrid, qui joue généralement en 4-4-2 diamant. Tu prends 10 tocquards et tu me rajoutes dans les buts, et on va prendre pilée sur pilée. Même si on joue en 4-4-2 diamant.

Tu oublies l'arbitre. Pour avoir le même rendement que le Real Madrid il te faut le 4-4-2 diamant ET l'arbitre avec toi sinon ça marche beaucoup moins bien !

[orfraie]

Bonjour,
Une méthode reste une méthode , c'est son contexte d'utilisation et son périmètre d'application qui font sa pertinence.
Dire que Scrum est une mauvaise méthode , c'est comme dire que le WaterFall est une mauvaise méthode.
Ca n'a pas de sens sans examen du contexte.
Appliquez Scrum à tout ce qui à faire est stupide.
Appliquer Scrum indistinctement avec tous les collaborateurs est stupide.
Appliquer Scrum indistinctement à tout type de périmètre volumétrique l'est également.
L'auteur de l'article ne met pas en perspective ces 3 aspects qui font de Scrum une méthode pertinente dans un contexte défini et une méthode certes intéressante, mais qui ne doit pas être appliquée dans d'autres contextes.
La digression sur la motivation du personnel est discutable car aucun membre d'une équipe de réalisation bien formatée sur un projet bien mené ne souhaite revenir à une méthode plus classique V, WaterFall.
La base de la base c'est que si c'est un clou à planter, il faut un marteau, s'il y a un écrou à visser , prenons une clé.

[Saverok]

Une méthode reste une méthode , c'est son contexte d'utilisation et son périmètre d'application qui font sa pertinence.
Dire que Scrum est une mauvaise méthode , c'est comme dire que le WaterFall est une mauvaise méthode.
Ca n'a pas de sens sans examen du contexte.

Oui et non.
Il y a des méthodes qui sont nulles quelque soit le contexte.

La digression sur la motivation du personnel est discutable car aucun membre d'une équipe de réalisation bien formatée sur un projet bien mené ne souhaite revenir à une méthode plus classique V, WaterFall.

Je connais des développeurs qui restent adeptes du cycle en V même après avoir été formés à des méthodes Agile et avoir participé à des projets réalisés en Agile qui se sont bien déroulés.
Le cycle en V a le mérite de rassurer les gens qui savent ainsi exactement où ils vont et comment ils y vont.

Par exemple, je connais quelqu'un qui prend tjrs le même trajet pour aller travailler et ce, quoiqu'il arrive.
Il utilise son GPS pour connaître son heure d'arrivée mais jamais il ne va changer d'itinéraire en cas de bouchon alors que son GPS lui propose des chemins alternatifs plus rapides.
Il est dans son habitude et ça le rassure car il sait où sont les virages dangereux, les radars, etc.
Changer d'itiniraire, c'est de l'inconnu et ça l'angoisse.

Avec les méthodes Agiles, c'est un peu comme ça.
On se donne la possibilité d'adapter l’itinéraire à chaque croisement et ça peu en effrayer certains.

[Ryu2000]

Le cycle en V a le mérite de rassurer les gens qui savent ainsi exactement où ils vont et comment ils y vont.

C'est quasi impossible d'avoir le cahier des charges parfait pour un projet qui sera peut être fini dans plusieurs années.
Comment une entreprise pourrait correctement exprimer son besoin ?
« Dans 2 ans j'aurais précisément besoin de ça : * »
Le client ne sait déjà pas ce dont il a besoin aujourd'hui, alors comment pourrait-il savoir ce dont il aura besoin dans la futur ?

On se donne la possibilité d'adapter l’itinéraire à chaque croisement et ça peu en effrayer certains.

Je comprend que prendre une autre route c'est stressant, mais je ne comprend pas en quoi SCRUM c'est stressant.
Moi perso c'est pareil, je préfère prendre un itinéraire plus long que je maîtrise qu'une route plus courte inconnue.

Un des nombreux problèmes du cycle en V c'est qu'on se planter sur la destination.
Donc ok t'es ton itinéraire tout tracé, mais il va dans le mauvais coin.
C'est un peu prévoir son itinéraire sur une carte déprécié.
Ou juste se planter d'adresse de destination.

Il y a des avantages et des inconvénients dans chaque méthode.
Perso je vois plus d’inconvénients dans le cycle en V que dans SCRUM (mais bon il n'existe pas que 2 méthodes de gestion de projet).
Et de toute façon si on regarde sous un certains angle, SCRUM c'est un peu plein de petits cycle en V.

[ZenZiTone]

Je comprend que prendre une autre route c'est stressant, mais je ne comprend pas en quoi SCRUM c'est stressant.
Moi perso c'est pareil, je préfère prendre un itinéraire plus long que je maîtrise qu'une route plus courte inconnue.

Tout dépend de comment elle est appliquée et des profils des différents participants. Le scrum peut être vu comme une continuité de dead line dont seul le fil rouge est visible. On ne sais pas en janvier sur quoi on va travailler en mars. Pour certains c'est stressant. Pour d'autre ça peut être l'inverse. On a pas tous les mêmes façons de travailler, penser, etc.. C'est d'ailleurs pour ça que les méthodes "agiles" sont sensé évoluer pour s'adapter aux équipes et aux projets. Et c'est aussi pour ça que ces méthodes sont beaucoup critiquées : elles n'apportent pas -dans un premier temps- les gains de productivité qu'elle vante.