Discussion :

[orfraie]

[QUOTE=Saverok;10226080]Oui et non.
Il y a des méthodes qui sont nulles quelque soit le contexte.

Vrai !
Et côté équipe, j'ai dit ...d'une équipe de réalisation bien formatée...
Et ce que vous dites est encore vrai sauf qu'il faut limiter / éliminer les collaborateurs qui préfère " se rassurer plutôt que s'adapter "
dès le début des Sprints.

[Ryu2000]

pas en janvier sur quoi on va travailler en mars.

C'est pas forcément le cas, parfois il y a une collection de tâches et tu sais qu'un jour tu devras les réaliser, donc t'as des mois et des mois de travail en attente.
Au moins SCRUM est beaucoup plus motivant que le Cycle en V, parce que t'atteints souvent tes objectifs.
Alors que le Cycle en V c'est trop gros, du coup les développeurs se font chier, et il y a des gros rushs avant les livraisons.

En gros c'est un peu comme celui qui fait une petite vaisselle à chaque fois qu'il cuisine ou mange (SCRUM) et celui qui attend une semaine pour faire toute la vaisselle d'un coup (Cycle en V).
Je trouve que c'est cool d'avoir des objectifs proches.

C'est d'ailleurs pour ça que les méthodes "agiles" sont sensé évoluer pour s'adapter aux équipes et aux projets.

Toutes les méthodes de gestion de projet doivent s'adapter, ça n'a pas de sens d'appliquer la marche à suivre à la lettre.
Il faut bricoler un peu.
Essayer d'utiliser ça ^^ :
Extreme programming

Le cycle en V c'est très bien si tu veux construire un immeuble en 1980, mais peut être pas aussi bien pour développer un logiciel en 2018.
Au final les chefs de projet font du Cycle en V un peu agile.
Parce que le Cycle en V strict c'est l'enfer.
Tu dois avoir fais tellement de choses avant de pouvoir écrire la moindre ligne de code...

Je préfère la logique "On se dépêche de développer une fonction principale pour la montrer au client, ensuite on pourra étoffer autour, à chaque réunion le client pourra nous préciser l'évolution de son besoin".

[Saverok]

il faut limiter / éliminer les collaborateurs qui préfère " se rassurer plutôt que s'adapter "
dès le début des Sprints.

Le hic est que tu ne choisis pas forcément ton équipe dans son ensemble.
Tu composes avec les personnes que tu as de dispo.
Et c'est dans ces moments là que le rôle de manager du CP prend tout son sens en accordant une attention particulière à ces collaborateurs qui ont besoin d'éléments de réassurance.

[Pyramidev]

@Ryu2000 : Là où je travaille aussi, le cycle en V serait une mauvaise idée, mais il ne faut pas généraliser si vite. Pense aux systèmes embarqués critiques comme dans l'automobile et l'aérospatial. On ne va pas déployer sur le terrain des avions agiles au fur et à mesure que la conception avance. « Oups, désolé pour le crash de l'avion : il y a eu une petite régression lors de la dernière release. »

[ZenZiTone]

Pense aux systèmes embarqués critiques comme dans l'automobile et l'aérospatial. On ne va pas déployer sur le terrain des avions agiles au fur et à mesure que la conception avance.

Ceci est, pour moi, une mauvaise interprétation de l'implémentation de la méthode SCRUM. Quand on parle de "livraison", on ne parle pas forcément de mise en production. Il peut seulement s'agir d'une mise à disposition d'un élément fonctionnel de la future solution.

[Ryu2000]

@Ryu2000 : Là où je travaille aussi, le cycle en V serait une mauvaise idée, mais il ne faut pas généraliser si vite. Pense aux systèmes embarqués critiques comme dans l'automobile et l'aérospatial. On ne va pas déployer sur le terrain des avions agiles au fur et à mesure que la conception avance. « Oups, désolé pour le crash de l'avion : il y a eu une petite régression lors de la dernière release. »

Ouais enfin bon normalement il y a des tests de non régression...
Si c'est un système sensible il faut que ce soit extremement testé.
Sinon ça peut finir comme ça :
Pourquoi Ariane 5 avait-elle explosé en plein vol ?

Mais voilà, Ariane 5 était plus véloce : son accélération pouvait atteindre la valeur 300 (qui vaut 100101100 en binaire et nécessite 9 bits). Ainsi, la variable codée sur 8 bits a connu un dépassement de capacité puisque son emplacement mémoire n'était pas assez grand pour accepter une valeur aussi grande, il aurait fallu la coder sur un bit de plus, à savoir 9, ce qui nous aurait fait 2^9=512 comme valeur limite, alors suffisant pour coder la valeur 300.

Bon à la limite pour une fusée je veux bien que le cycle en V peut être adapté, vu qu'on peut tout bloquer des années avant.
Mais la majorité des projets sont beaucoup moins sensible et peuvent évoluer.
Le Cycle en V dans une entreprise ça ferait que t'arrives à la livraison après 3 ans de développement et on te dit "ça fait 2 ans qu'on a plus du tout besoin de ça".
Les besoins évoluent généralement.

De toute façon quasiment personne ne fait du Cycle en V strict, la gestion de projet c'est un peu plus du bricolage, il y a des libertés quand même.
Parce que le cycle en V c'est lourd, si tu découvres un problème il faut repartir de loin.
Si les tests unitaires sont mauvais il faut refaire la conception détaillée et le codage.
Si les tests d'intégration sont mauvais il faut refaire la conception architecturale, la conception détaillée et le codage.
Si les tests de validation sont mauvais il faut refaire les spécifications, la conception architecturale, la conception détaillée et le codage.
Si la recette est mauvaise il faut refaire l'analyse des besoins, les spécifications, la conception architecturale, la conception détaillée et le codage.

Le Cycle en V c'est bien quand les besoins sont bien exprimés, bien compris et ne changent jamais.
Ça ne représente pas la majorité des projets

Après SCRUM c'est pas la solution miracle non plus...
Mais je trouve que mettre un peu d'agilité dans la gestion de projet ça fait généralement pas de mal...
Personnellement je vois plus d'avantage dans l'agile que dans l'ultra rigide comme le Cycle en V.

[el_slapper]

(.../...)
Le Cycle en V c'est bien quand les besoins sont bien exprimés, bien compris et ne changent jamais.
Ça ne représente pas la majorité des projets (.../...)

De mon expérience, en info de gestion, on doit frôler les 10% : évolutions réglementaires et migrations techniques clairement identifiées. J'en ai fait. Rien de tel qu'un bon GANTT qui détaille tout ce qu'il y a à faire, dans ce cas-là, avant de mettre les mains dans le cambouis.

Mais dans les +90% de projets restants.....

[type901]

D'une façon globale, mon ressenti est que Agile / Scrum est une bonne méthode sur des projets de petit ou périmètre moyen et surtout partant d'une feuille blanche :
Ce sera parfait pour monter un site web e-commerce ou un nouvel IHM, par exemple.

Ce sera nettement plus compliqué pour monter un SI d'entreprise où les décisions d'architecture technique et fonctionnelle prises dès le départ vont fortement impacter les possibilités à terme.
Même chose sur une refonte (totale ou partielle) de SI, pour laquelle il faudra préalablement faire une revue de règles fonctionnelles, éventuellement faire évoluer celles-ci et s'intégrer dans un environnement technique et fonctionnel contraignant impliquant une phase d'étude en amont non négligeable, peu compatible avec une méthode par itération.

Agile / Scrum, c'est souvent vu sous l'angle "on a le droit de se tromper" voire parfois "Je sais pas trop ce que je veux, on va voir ce que les techos vont me proposer" => c'est trop souvent le paravant des fonctionnels qui ne font pas leur boulot

[jyves69]

L'Agilité à tout prix => NON !
On doit faire de l'Agile (Scrum, Kanban, etc.) quand il y a des zones de flou.
Si on sait exactement ce qu'il faut faire, que la techno est sèche, qu'il n'y a aucune interprétation, => Pas besoin de faire en Agile.
Faire en Agile coûte plus cher ! (Et oui, les rétro, Daily, ...ça coûte...)
Et l'Agilité n'est "rentable" que si ce que l'on est en train de construire a des zones de flou. L’agilité permettra de s'adapter.

Pour répondre à la problématique de grands projets, grandes équipes... il faut aller chercher des framework à l'échelle : SAFe, LeSS, ... car Scrum n'est pas fait pour une équipe de plus de 9 personnes.

C'est bien parce qu’on veut faire de l'Agile à tout prix, que l'on va payer au prix fort le "l'agilité, ça marche pas".

[Pfeffer]

Je travaille en mode agile Scrum. Le projet a démarré sept 2021, fin prévisionnelle, 1er trimestre 2022. On vient d'annoncer un retard de 8 mois 😁 !! C'est une catastrophe.

De notre côté, les spécifications fonctionnelles sont écrites en même temps que les développements. L'équipe back a été déployée en même temps que le front, or toutes la logique métier côté back a pris du temps pour se développer donc l'équipe front est restée quasi inactive pendant plusieurs semaines.

Là rebelotte le front avance mais les specifications fonctionnelles et le détail des tickets ne sont pas écrits.

Pire, les besoins sont mal compris, les specifications erronées et donc, en itération, effectivement je passe mon temps à faire / défaire / refaire.

A cela vs ajoutez une équipe de dev junior et un product owner qui n'a aucune notion en UI/UX et on est bien 😂😂.

Scrum c'est génial si vous avez trop d'argent, des développeurs à payer à rien faire et des deadlines non définies. 😁