Discussion:Scrum (Boite à outils)

Une page de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Autres discussions [liste]
  • Suppression -
  • Neutralité -
  • Droit d'auteur -
  • Article de qualité -
  • Bon article -
  • Lumière sur -
  • À faire -
  • Archives

Discutions plus anciennes[modifier le code]

Scrum (1995) reprend (pour partie seulement en ce qui concerne cette méthode très incomplète)l'ensemble des théories itératives , incrémentales, adaptative issues des travaux de Barry Boehm (1986) et fonctionnellement instrumentées, pour la première fois en 1991 par James Martin dans sa méthode RAD. Pourtant les auteurs de Scrum se dispensent de toute réference d'antériorité. Le révisionnisme qui consiste a supprimer les références antérieures ne résiste pas à l'histoire et au temps. Il n'y a bien que dans le domaine informatique que des tentatives pareilles peuvent exister. Comme si les chefs de projets américains n'avaient pas lu James Martin ou observé DSDM à partir de 1991. Pour le Garner Group qui suit depuis le début l'évolution des techniques et méthodes informatiques et managériales, les méthodes Agiles actuelles sont simplement RAD ou néoRAD. Refuser l'antériorité des publications sur un sujet (ce qui est base même de la communication scientifique), n'empêchent pas ces communications d'exister.


Exemple parfait de jargon technocratique pondu par des illuminés ou la transposition de l'idéologie des sectes dans le monde du travail, performe en massacrant le français allègrement, plie-toi à des structures ésotériques véhiculée par un vocabulaire d'initié et gouvernées par un Master !! - Siren 25 avr 2005 à 20:35 (CEST)

Oui, c'est de la grosse polémique, mais il y a quand même une parcelle de vérité et c'est ça qui est préocupant.


> Hmmm...Tout ceci me parraît bien poétique plutôt...Quel Style ! On dirait du Dali :-}
Christophe MOUSTIER 26 avr 2005 à 01:04 (CEST)


Remarque personnelle:Je ne partage pas tout à fait cette critique - l'isolement mentionné est de courte durée (entre 2 et 4 semaines), et rien n'empêche le client de formuler de nouvelles exigences et de les rajouter au Project Backlog pendant la durée du Sprint. Cependant, il est correct que la réponse des développeurs (analyse, estimation, etc.) sera seulement donnée au début du prochain Sprint, donc 2 à 4 semaines plus tard au maximum - ceci pour leur permettre d'atteindre leur objectif premier du Sprint, à savoir de fournir une version livrable, testée, qui a une valeur pour le client et qui marche. Pour remédier à cette limitation, libre à chaque ScrumMaster de définir des Sprints plus courts si ceci est vraiment un problème, mais dans la pratique, 2 à 4 semaines semblent un bon laps de temps pour fournir un incrément de valeur pour le client. --213.200.248.18 8 jun 2005 à 11:58 (CEST)François Bachmann


Ce texte est reporté ici, les articles ne sont pas un lieu de discussion, les éléments y figurant peuvent trouver place dans l'article mais formmulés d'une façon moins personnelle (et non signés).

(aparté) Plus je relis cet article, plus je trouve que ce Scrum est le sommet du ridicule technocratique. Cette façon de travailler est naturelle pour un groupe qui cherche l'efficacité, pourquoi en faire une sorte de de recette mystérieuse qui ne tire son intérêt et son originalité que par l'utilisation de termes anglais ridicules pour expliquer des chose si banales, une forme moderne du bourgeois gentilhomme qui fait de la prose : technocratisme puant ! Siren 8 jun 2005 à 12:32 (CEST)


On ne cherche pas toujours le génie en toute chose. Ca a le mérite de formaliser. Quant aux termes l'anglais, le jour où le français sera considéré langue commerciale universelle et qu'un pays francophone jouera les maitres du monde dans les faits, on verra peut-être apparaitre des méthodes ridicules en français ... Bref, j'aimerais savoir si il existe d'autres méthodologies du même genre, utilisant le suivi des protagonistes à intervalle court. Le cas échéant, peut-on ajouter des liens vers celles-ci ? Paulobou


Bon j'ai réécrit l'article. La raison principale est qu'il y manquait beaucoup de choses, et d'autre part il contenait quelques concepts qui étaient à l'opposé des méthodes Agiles et de Scrum. C'est vrai que vu sous cet angle on pouvait mal interpréter la méthode et la considérer comme un simple jargon qui n'apporte rien de concret. J'espère avoir fait passé les vrais valeurs et concepts, et que les auteurs précédents ne se vexeront pas de cette refonte totale. Avangel 14 juin 2006 à 11:28 (CEST)

Lien externe mort[modifier le code]

Bonjour,

Pendant plusieurs vérifications automatiques, et dans le cadre du projet correction des liens externes un lien était indisponible.

Merci de vérifier si il est bien indisponible et de le remplacer par une version archivée par Internet Archive si c'est le cas. Vous pouvez avoir plus d'informations sur la manière de faire  ?ici. Si le lien est disponible, merci de l'indiquer sur cette page, pour permettre l'amélioration du robot. Les erreurs rapportées sont :

Eskimbot 1 février 2006 à 01:24 (CET)


Image du processus Scrum[modifier le code]

L'image du processus scrum http://fr.wikipedia.org/wiki/Image:Scrum.png est joli et j'ai l'intention de la traduire en Allemand. Une question: quelle est la source originale de cette image? Est-ce qu'elle est vient de Schwaber / Beedle http://de.wikipedia.org/wiki/Scrum#Literatur

-- HJH


L'image a été réalisée par Mike Cohn et traduite par Claude Aubry. Elle est publiée sous licence Creative Commons, ce qui signifie que vous pouvez la publier et la modifier mais en laissant apparaître le nom de son auteur original (à vérifier).

--Avangel 23 août 2006 à 10:30 (CEST)

Traduction française "backlog"[modifier le code]

Outre la traduction (difficile et assez discutable) de Scrum, la traduction de "backlog de produit" me semblerai assez naturellement "Journal de bord du produit". Cela correspond bien au concept d'historique, de "recherche arrière", ainsi qu'au fait que l'on peut y écrire "un peu tout", etc... Qu'en pensez-vous?

PS: Le mot "item" est un bel anglicisme également, en français c'est "élément". On trouve également les "user stories" traduites par "demandes utilisateur" ou "cas utilisateur".

Thomas BAECKEROOT 15 août 2006 à 16:30 (CEST)


Il n'existe pas de traduction officielle, aussi c'est difficile de mettre tout le monde d'accord ;) Personnellement je préfère le terme "backlog" à toutes les traductions françaises que j'ai vues. "Journal de bord" reflète bien les idées derrière le mot anglais "backlog", mais dans la pratique, il me semble que ça serait beaucoup trop long à prononcer. C'est déjà pénible de préciser "backlog de produit" ou "backlog de sprint" quand on en parle 10 fois dans une conversation !

Pour le mot item, il fait bien partie de la langue française (trouvé dans le petit larousse de 1965 enfoui dans une armoire au boulot ;). Le terme "User Stories" est effectivement traduit en français, mais "cas utilisateur" rapelle trop le "cas d'utilisation" d'UML, alors que le concept n'est pas le même. "Demande utilisateur" me paraît un peu informel, rappelle l'idée du "cahier des charges" avec ses "demandes utilisateur", et ne représente pas bien l'idée de fiche autonome. Un terme exotique (certes en anglais), permet de se donner une représentation bien spécifique du concept sans faire de rapprochement avec d'autres. --Avangel 23 août 2006 à 10:30 (CEST)


En français technique, l'expression correcte est "exigences" (besoin formellement exprimé et pouvant faire l'objet d'un test de validité). La déclinaison est alors : exigences fonctionnelles et exigences techniques.


Le sens de backlog est celui de "Reste à Faire". Cette notion simple implique que ce qui est dans cette liste devra être fait, ce qui empêche d'utiliser le Backlog comme une liste de souhaits. Cela force aussi à donner des détails : ce qui doit "être fait" doit être suffisamment clair pour être actionnable par les développeurs. Le backlog produit peut donc se traduire par le "Reste-à-faire produit".

Pour le mot "User Story", je ne trouve pas mieux que "Récit utilisateur". Cela me parait simple est élégant.

--Sébastien Sacard 04 novembre 2012 à 19:30 (CEST)


Personnellement, je ne comprend pas trop cette volonté de traduire absolument tout. Je suis d'accord que les anglicisme ne sont pas très joli. Mais dans notre cas, il s'agit de vocabulaire très lié à la méthode SCRUM en elle même. Et je ne suis pas sur que traduire ces termes aide réellement à la compréhension de l'article. De plus, toutes les autres sources utilisent ces termes anglais, ce qui pourrais rendre la compréhension d'un novice d'autant plus difficile.

--VCocaud (discuter) 9 septembre 2015 à 09:16 (CEST)

utilité de EPF ?[modifier le code]

J'ai du mal à voir à quoi peu servir ce truc...

Quelqu'un pour m'éclairer ?

L'outil décrit la méthode, mais je cherche son utilité. C'est plutôt descriptif que fonctionnel, non ? Je trouve cet article plus utile que EPF dans le cas.

Brisssou (d) 4 novembre 2008 à 16:11 (CET)

post blog a propos de cet article[modifier le code]

http://www.aubryconseil.com/dotclear/index.php/2008/10/27/486-radotage

Monsieurs, la partie de la critique de scrum est oublié par hasard ou pas ? --82.121.147.211 (d) 1 mars 2009 à 23:49 (CET)

La magie des articles de Wikipedia[modifier le code]

Formidable cet article (heu publicité ?) pour SCRUM qui à la lecture de la page est la solution, où rien n'est négatif dans le fonctionnement, si ce n'est bien sûr la mauvaise volonté de ceux qui n'adhèreraient pas à la solution.

Il me semble qu'il manque une vraie partie "critique de la solution" (pas un truc qui dirait "si ça ne marche pas, c'est que vous le faite mal")...

J'ajouterai que le but principal de ce genre de méthode est à mon avis de faire une jolie aparté dans la plaquette commerciale pour dire que la boite applique la méthode SCRUM. Ca fait toujours class d'ajouter des logos et des acronymes "à la mode".

--Jmda (d) 9 septembre 2011 à 11:22 (CEST)

Ah ben voilà : http://www.scrumalliance.org/scrum_certification

Ils existent les logos... Allez, combien faut payer pour pouvoir le mettre sur sa plaquette à côté de la certification SAS, la certification Windowz j'sais plus quoi..?

C'est beau le marketing driven. C'est sûr que c'est ça qui va permettre d'avoir de bien meilleurs produits... :)

--Jmda (d) 9 septembre 2011 à 11:33 (CEST)

Je suis d'accord avec Jmda. Je suis certifié et pratiquant depuis de nombreuses années, et SCRUM n'est pas une solution miracle à tous les maux. Ce serait d'ailleurs suspect que ca soit le cas. Comme tout, SCRUM a ses mauvais cotés et il y a lieu de bien informer le lecteur.

Qualité de l'environnement de travail[modifier le code]

Je me questionne sur le contenu de cette section. La grande partie du contenu n'a aucun rapport avec Scrum ... et n'a aucune source vérifiable. Soit on fait un grand ménage, soit on supprime ?
— Le message qui précède, non signé, a été déposé par Ogourment~frwiki (discuter), le 23 mars 2012 à 03:05 (CET).

Le chapitre me parait hors sujet en effet. --Laurent N. [D] 23 mars 2012 à 14:30 (CET)

Supprimer les rappels sur les méthodes agiles ?[modifier le code]

Est-ce réellement nécéssaire ? Un lien vers les méthodes me semble suffisant. Par contre, on ne parle pas des trois piliers cités dans le guide officiel : Transparence, Inspection et Adaptation. Quelqu'un a t'il une objection pour que je supprime cette partie, et que je la remplace ? --Jonathan.Scher (d) 26 mars 2012 à 19:10 (CEST)

Partie remplacée --41.250.90.71 (d) 28 mars 2012 à 20:46 (CEST)

Equipe auto gérée est elle la plus efficace des organisations ?[modifier le code]

On trouve cette phrase dans l'article, je l'ai déplacée. Savez vous sourcer cette information ? Section "équipe de développement... Contrairement à ce que l'on pourrait croire, les équipes auto-gérées sont celles qui sont les plus efficaces et qui produisent le meilleur niveau de qualité de façon spontanée.[réf. nécessaire] --41.250.90.71 (d) 28 mars 2012 à 20:46 (CEST)

Daily Scrum[modifier le code]

On trouvait ce passage dans Daily Scrum. Si des informations sont intéressantes, elles n'ont pas leur place dans ce paragraphe. A réintégrer à l'article.

L'équipe se met ensuite au travail. Elle travaille dans une même pièce, dont le ScrumMaster a la responsabilité de maintenir la qualité d'environnement. Les activités se déroulent éventuellement en parallèle : analyse, conception, codage, intégration, tests, etc. Scrum ne définit volontairement pas de démarche technique pour le développement du logiciel : l'équipe s'auto-gère et décide en toute autonomie de la façon dont elle va travailler.
Remarque : Il est assez fréquent que les équipes utilisent la démarche de développement guidé par les tests (Test Driven Development en anglais). Cela consiste à coder en premier lieu les modules de test vérifiant les contraintes métier, puis à coder ensuite le logiciel à proprement parler, en exécutant les tests régulièrement. Cela permet de s'assurer entre autres de la non-régression du logiciel au fil des sprints.

--Jonathan.Scher (d) 11 avril 2012 à 09:56 (CEST)

Refus et enfouissement des références historiques[modifier le code]

Après avoir refusé les références historiques concernant les sources des concepts et pratiques de cette méthodes, les tentatives de faire remonter l'historique de Scrum aux années 1980 se poursuivent en publiant des références sans lien concret avec les principes de cette méthode. Plus inquiétant pour l'éthique de cette encycplodédie, on constate maintenant des actes systématiques d'enfouissement des références publiées. --Vickoff (d) 15 mai 2012 à 21:08 (CEST) Les plus anciennes références bibliographiques (sauf erreur de ma part) impliquant les auteurs de la méthode sont les suivantes :

  • Agile Software Development With Scrum , Ken Schwaber, Mike Beedle, Prentice Hall, (October 21, 2001) (ISBN 978-0130676344)
  • The Power of Scrum , Jeff Sutherland, Rini van Solingen, Eelco Rustenberg, Kindle Edition, (Nov 10, 2011) (ASIN B007474YMC)

Je viens d'acheter le document OOPSLA 1995 afin de vérifier le programme complet. Ken Schwaber était seul à présenter Scrum (Jeff Sutherland était bien a cette manifestation comme co-chairman mais n'intervenait pas sur la présentation de Ken Swaber. Voici d'ailleurs l'Abstract concernant Scrum :

« 4.10 SCRUM Development Process - Ken Schwaber, Advanced Development Methods

The stated, accepted philosophy for systems development is that systems development process is a well understood approach that can be planned, estimated, and successfully completed. This is an incorrect basis. SCRUM states that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. SCRUM defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used. »

Une autre question : si comme il est précisé dans l'historique « En 1995, Sutherland et Schwaber ont présenté conjointement un document décrivant Scrum à l'OOPSLA, à Austin, aux États-Unis. Schwaber et Sutherland ont collaboré au cours des années suivantes pour fusionner les publications, leurs expériences et les meilleures pratiques du secteur en ce qui est maintenant connu comme Scrum » pourquoi ne trouve t'on pas au moins un livre ou une publication officielle ou même un simple article dans une revue professionnelle avec les deux noms, ou même un seul d'ailleurs ?

La version de Jeff Sutherland lui même est simple : "In 1995, I introduced Ken Schwaber to John's (Scumniotales) team after which Ken wrote the first Scrum paper for OOPSLA'95." Jeff Sutherland

Dernier point, bien que ni Sutherland, ni surtout Schwaber ne revendiquent une telle antériorité, les documents 2011 de la Scrum.org (the official Home of Scrum) portent en bas de page " © 1991-2011 Ken Schwaber and Jeff Sutherland, All Rights Reserved " et comme par hasard, 1991 c'est la date officielle de présentation de la méthode RAD. Heureusement, en matière de communication scientifique, la réalité historique n'est pas si facile à altérer. — Le message qui précède, non signé, a été déposé par Vickoff (discuter).

Scrum et itération[modifier le code]

Je ne comprends pas bien ce que l'auteur a voulu dire par là :

"Les pratiques de Scrum sont essentiellement orientées sur la maîtrise d’une livraison d’incréments (sprint) mais réfutent la possibilité de modifier les fonctionnalités en cours de réalisation (dans le backlog de sprint). Cette limite interdit la mise en œuvre d’une conception émergente comme celle d'XP ainsi que celle d'itération"

Au contraire, le Scrum propose bien un mode de pilotage itératif en maximisant les possibilités de rétroaction.

Sources: http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20FR.pdf

— Le message qui précède, non signé, a été déposé par l'IP 90.80.214.217 (discuter).

Estimation et Engagement (demande d'explications)[modifier le code]

"(les membre de l'équipe) prévoient alors ce qui sera fait pendant le sprint, construisant ainsi une estimation. Cela constitue l'engagement de l'équipe."

La notion d' engagement dans les projets agiles recouvre, selon certains, uniquement la notion d' engagement de moyens, ici par exemple : http://laurentmeurisse.wordpress.com/2012/03/29/principes-engagement-agile/

Si, comme cela est décrit ici, l' estimation devient rigoureusement engageante, alors l'équipe risque de se focaliser sur la défense de son engagement formel (et ses conséquences) et non plus le produit lui-même et les moyens de le faire aboutir.

Cette phrase de l'article est-elle fidèle aux principes des méthodes agile ? Elle me semble ne servir que la cause du Product Owner, et non de l'ensemble de l'équipe. Quelles explications ou précisions peut-on apporter à cela ? Merci de vos lumières ! — Le message qui précède, non signé, a été déposé par l'IP 82.67.143.181 (discuter).

La question de l'engagement dans les méthode agiles est à voir méthode par méthode. Pour ce qui est de Scrum, la notion d'engagement a disparu du Scrum Guide en 2011, et n'est toujours pas reparue. Le sujet est évoqué dans cet article de scrum.org. Dans les faits, la notion d'engagement est encore très présente dans les organisations qui appliquent des modes de travail inspirés de Scrum, mais qui restent incapables d'abandonner complètement le fonctionnement hiérarchisé en commande & contrôle. Ils trahissent de ce fait le fondement de la méthode, mais c'est malheureusement assez fréquent.
--A22 (discuter) 28 avril 2014 à 14:24 (CEST)

Utilisation du terme propriétaire du produit et directeur de produit[modifier le code]

Dans l'article il est utilisé indifféremment les termes "propriétaire du produit" et "directeur de produit" il faudrait à mon avis utiliser dans tout l'article le terme "propriétaire du produit" qui est le rôle défini dans la partie Rôles. Un avis ? — Le message qui précède, non signé, a été déposé par Echo.dubois (discuter).

oui, c'est modifié. J'ai écrit "propriétaire du produit" au lieu de directeur de produit. --A22 (discuter) 30 avril 2014 à 07:36 (CEST)

Travail non vérifié[modifier le code]

Toute la partie "Compléments" n'a rien à voir avec la méthode, mais plutôt avec un retour d'expérience. Soit on cherche des sources valables pour justifier ce contenu, soit on l'enlève. Des avis ? --A22 (discuter) 30 avril 2014 à 07:47 (CEST)

 Enlever tout le travail qui ressemble à une thèse ou à un publireportage et qui ne peut pas être sourcé et/ou neutralisé. Cependant, certaines parties de cette section ont leur place sur cet article (mais pas dans une section complément). --Scoopfinder(d) 30 avril 2014 à 09:09 (CEST)

J'ai déplacé le paragraphe « définition de prêt » dans la partie « Compléments » parce que ni le guide scrum, ni aucun texte de référence que je connaît, ne mentionne de « définition de prêt ». Ils ne parlent que de la notion de « prêt » pour les items de product backlog qui sont prêts à être intégrés dans un sprint. De plus, les sources qui étayent le paragraphe ne sont pas directement liées au sujet de l'article, mais plutôt à l'agilité en général Donc merci d'en discuter ici avant d'annuler la modification.

À un moment il faudra décider quoi faire de la partie « Compléments » et de la partie « Risques » dont, à mon avis, la majorité du contenu tient de la progéniture dégénérée du travail inédit et de la non neutralité. Moi je suis pour le scalpel. Des objections ? --A22 (discuter) 9 mai 2014 à 17:41 (CEST)

Je suis d'accord avec le manque de source total. Je pense que cette section à été rajouter pour essayer de présenter des défauts à SCRUM. Sauf que c'est très mal mener et je ne trouve pas que ce qui est dit soit très pertinent. Toute fois, la suppression pure et simple de la section ne me parait pas non plus une solution. Après tout, il en existe bel et bien des inconvénients à cette méthode autre que "Vous pouvez pas comprendre".--VCocaud (discuter) 9 septembre 2015 à 09:07 (CEST)

SCRUM n'est pas une Méthode[modifier le code]

SCRUM est un cadre de travail.
Il est différent d'une méthode dans le sens où il ne prescrit pas de processus clairement définis à suivre et qu'ils repose sur des valeurs à intégrer / incarner.
Référence : Guide SCRUM français : http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-FR.pdf
« Scrum (n) : un cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible.
Scrum est :

  • Léger
  • Simple à comprendre
  • Difficile à maîtriser

Scrum est utilisé depuis le début des années 1990 pour gérer le développement de produits complexes. Scrum n’est pas en soi un processus ni une méthode de développement de produits; c’est un canevas pour l’application de divers procédés et techniques de développement »
— Le message qui précède, non signé, a été déposé par StefBrodu (discuter), le 29 août 2016 à 17:10 (CEST).

Encore une vérité effacée[modifier le code]

« Scrum est considéré comme un cadre méthodologique et non à proprement parler comme une méthode agile. Compte tenu de la prédictibilité imposée par un carnet de produit en préalable du développement, et d’une adaptabilité limitée par le but immuable d'un sprint, donc en contradiction avec la troisième et la quatrième des valeurs Agiles. »

Pourtant cela correspondait exactement à la réalité. Mais dans ce domaine où les français ont perdu la partie depuis longtemps, il est de bon ton de cacher les choses gênantes pour les "money maker ". Jean-Pierre Vickoff
— Le message qui précède a été déposé par l'IP 85.69.167.107 (d · c), le 11 juillet 2017 à 22:01 (CEST). Il est recommandé de signer en cliquant sur l'icône de signature ce qui ajoutera les quatre tildes de signature (~~​~~).