52 votes

Scrum est-il diabolique ?

Au dernier CITCON Europe, nous avons eu une excellente session sur le thème " Scrum est-il diabolique ? " Lecture de l'article du blog de James Shore sur " Le déclin et la chute de l'agile "a ramené cette session à l'esprit.

Ce sont des doutes sérieux soulevés par des personnes profondément impliquées dans la méthode agile. Pour les personnes extérieures, les jugements peuvent être encore plus sévères, comme dans ce billet de blog " La maladie agile ".

Quelle est votre opinion actuelle sur Scrum et/ou Agile et son influence actuelle sur le développement de logiciels ?

(Il ne s'agit pas de savoir ce qu'agile signifiait il y a plus de 5 ans, mais plutôt de son influence aujourd'hui. Il ne s'agit donc pas tant de Scrum contre RUP que de savoir si Scrum est le nouveau RUP).

6voto

Cam Wolff Points 1161

Tout d'abord, acceptez SCRUM pour ce qu'il est, un ensemble de pratiques de gestion visant à faciliter la collaboration entre le développement et le partenaire commercial. En tant qu'ensemble de pratiques de gestion, elles sont généralement faciles à mettre en œuvre et à suivre et apportent un bénéfice quasi immédiat à un projet.

SCRUM n'est pas un ensemble de pratiques d'ingénierie. Une équipe sans ensemble de pratiques d'ingénierie est une équipe qui ne sera pas en mesure de maintenir la livraison. SCRUM en soi n'est pas suffisant. Une équipe agile pratiquant uniquement SCRUM commencera à perdre sa vélocité. Sans pratiques d'ingénierie appropriées, par exemple XP, la base de code devient plus difficile à modifier au fur et à mesure que le projet se prolonge.

Ainsi, SCRUM en soi ne fournira qu'un avantage à court terme et peut créer un faux sentiment de valeur. SCRUM, sans les pratiques d'ingénierie telles que XP, deviendra rapidement un projet qui a besoin d'être sauvé. SCRUM est un excellent ensemble de pratiques de gestion qui a besoin d'un excellent ensemble de pratiques d'ingénierie qui doivent être pratiquées en parallèle.

4voto

philant Points 17345

Comme l'a dit F. Brooks, "il n'y a pas de solution miracle", et les processus Agile ne dérogent pas à cette règle et ne peuvent pas être appliqués à tous les types de projets.

De plus, Scrum, et les processus agiles, sont plus qu'un ensemble de pratiques, il y a les principes sous-jacents . Si l'application des pratiques peut être facile, sans ces principes, elle peut conduire à un désastre. Et en inspecter et adapter le processus en permanence le processus se terminera en fonction des besoins de chacun.

Il est évident que Scrum souffre des projets qui l'utilisent [mal] et échouent. C'est inévitable. Mais nous avons vu des projets Waterfall échouer, nous avons vu des projets RAD échouer, nous avons vu des projets RUP échouer, qu'est-ce que cela nous apprend sur ces processus ?

Je pense personnellement que les processus agiles ont atteint leur niveau de maturité, mais je ne suis pas sûr que cela signifie qu'ils ont commencé à décliner.

2voto

MarkJ Points 21438

Tu sépareras le logiciel et la religion. - Code complet .

Choisissez et mélangez les pratiques en fonction de ce qui convient à votre projet actuel. Ne faites pas d'une méthodologie une religion. N'oubliez pas que nous venons tous de mondes différents . C'est ce que Steve McConnell conseille depuis des années. Développement rapide donne un catalogue de pratiques avec des conseils pour savoir si elles conviennent ou non votre projet. Le livre a gagné un Jolt Award en 1997, et Steve McConnell est un très grand respecté alors il est temps qu'il devienne populaire.

Eric Sink dites-le comme ça ce (langue de bois) :

J'admets que l'ensemble de la littérature de sagesse produite par le mouvement Agile contient de très bonnes choses. Mais Agile n'est pas différent de toute autre grande religion comme le christianisme ou le bouddhisme. Vous pouvez y apprendre de grands principes et pratiques, mais devenir officiellement membre est une décision qui ne doit pas être prise à la légère.

Pour être juste, l'article d'Alistair Cockburn Développement logiciel agile conseille également une sélection pragmatique des pratiques, mais à mon avis, certains des autres gourous agiles sont trop évangéliques. D'autres l'ont exprimé de manière plus forte .

1voto

rgargente Points 916

Je pense que cela peut être utile dans certaines circonstances. Mais je pense que SCRUM, ou toute autre méthodologie, doit être un instrument pour nous, et non l'inverse.

Lorsqu'elle commence à créer plus de problèmes qu'elle n'en résout, elle n'en vaut pas la peine.

Si, après l'avoir utilisé, vous améliorez vos estimations de temps, que votre équipe est plus consciente de ses objectifs, que vous détectez plus rapidement les retards et que vous êtes en mesure d'y réagir, alors scrum vous sert.

Mais lorsque vous vous apercevez que vous devez passer beaucoup de temps à essayer de faire le puzzle en assignant des tâches aux développeurs et en les faisant rentrer dans votre temps d'itération, lorsque vous devez faire une estimation de temps sur une tâche qui n'est même pas bien définie, lorsque vous devez faire combien cela coûtera-t-il de mettre en œuvre une technologie que vous ne connaissez même pas encore, etc... juste pour que la direction puisse avoir un joli graphique d'itération, alors c'est une perte totale de temps (et bien sûr d'argent). En fait, c'est une source de frustration, cela rend le développement plus difficile, et la gestion presque impossible parce qu'il ne peut pas générer de bonnes données, peu importe comment vous essayez.

1voto

Klelky Points 278

Il est intéressant de noter que le La mêlée est-elle mauvaise ? Le lien ne donne pas un point de vue particulièrement négatif à mon avis :

Par exemple, "Scrum est mauvais parce que " quand il échoue, toutes les personnes impliquées pensent que toute la méthode agile n'est pas bonne (cela empoisonne le puits pour la méthode agile).

Le point de cet article semble être que le problème est de se concentrer sur le "processus" plutôt que sur l'objectif. Cela s'applique à toute méthodologie.

De même, le Déclin et chute post dit que l'application aveugle d'un processus (en particulier SCRUM, qui est axé sur la gestion) sans l'étayer par de bonnes pratiques d'ingénierie n'a pas de sens.

Je pense que ce qu'il faut retenir, c'est que vous ne pouvez pas prendre n'importe quel processus pour argent comptant et tenter de le copier aveuglément (ou pire, seulement les parties que vous voulez) et espérer que cela fonctionne. Chaque situation est différente et sans une réflexion claire, de bonnes pratiques et des personnes talentueuses et motivées, vous aurez du mal.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X