Discussion :

[tawaha2010]

Bonjour tout monde,

Je viens de commencer un projet Web, je cherche à suivre un cycle de développement (en V, en Y, en cascade,...), le problème qui se pose maintenant est: Est-ce que Scrum est un cycle de développement? ça veut dire est ce que je peux choisir Scrum comme cycle de développement ou c'est juste une méthodologie de travail ?!

Je voudrais avoir plus d'informations sur les méthodes agiles? ça veut dire quoi? c'est quoi la différence entre les méthodes agiles et les autres méthodes? et est-ce que Scrum peut être utilisé comme cycle de développement?

Merci d'avance.

[XxArchangexX]

Bonsoir,

C'est un peu une mode, tu trouveras tout et rien mais dans l'idée les méthodes agile ont pour but d'optimiser et d’accélérer le cycle de développement. Basé sur une bonne communication et un travail d'équipe optimal plutôt que des outils informatique pour la gestion de projet.

Scrum est une dérive de cette méthode de travail, qui dit qu'une fois le projet prêt l'équipe rentre dans un cycle infernale, 24h/24 de travail pour finir le plus vite. L'inconvénient c'est que pendant cette période de travail l'équipe est dans une bulle qu'il ne vaut mieux pas déranger. Deplus pour de gros projet si la préparation n'a pas pris en compte tous les aspects sa peut poser des problèmes.

[el_slapper]

D'un point de vue théorique, Scrum, c'est une succession de sprints. Chaque sprint est un cycle de développement en lui-même : on se fixe des objectifs limités, on fait, et on fait un feed-back à 360°(i.e., du dev vers le spécificateur, du spécificateur vers le dev, pareil pour les homologateurs, voire d'autres acteurs encore). XP fait des cycles plus court, Crystal plus long(enfin, c'est juste une tendance), mais toutes font plusieurs cycles là ou "V" ou "cascade" n'en font qu'un.

D'un point de vue philosophique, il n'y a pas de "méthode" agile : il n'y a que des manières agiles d'appliquer des méthodes. Qui passent mieux avec les méthodes XP, scrum, ou Crystal, mais ces méthodes dites "agiles" peuvent parfaitement être appliquées de manière monolithique.

D'un point de vue pratique, l'important, c'est de savoir ou on veut aller, et, ensemble, d'y aller. Formaliser une méthode peut être utile, mais le plus important est de la remettre en cause si on se rend compte que ça ne marche pas. L'Agile ne peut pas fonctionner avec un client rigide(le département de la défense américain, par exemple), c'est tout le monde qui doit l'être pour que ça marche.



En bref : connait ton client, et sa manière de travailler. Si il est du genre "tire-toi avec les specs que je t'oublie jusqu'à la fin du projet", c'est mal barré pour de l'agile.