Discussion:Scrum (développement)/Archives

message: 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)
thread_title:  Discussions plus anciennes 

message: 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 : 
* http://www.agilealliance.org/articles/searchResults?topic=Scrum
** Dans Scrum, le Fri Jan 27 21:12:19 2006, 404 Not Found
** Dans Scrum, le Tue Jan 31 22:53:02 2006, 404 Not Found
▪ Eskimbot ☼ 1 février 2006 à 01:24 (CET)
thread_title: Lien externe mort

message: 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)
thread_title:  Image du processus Scrum 

message: 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)
thread_title:  utilité de EPF ? 

message: 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)
thread_title:  post blog a propos de cet article 

message: 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)
thread_title:  La magie des articles de Wikipedia 

message: 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 chapitre me parait hors sujet en effet. --Laurent N. [D] 23 mars 2012 à 14:30 (CET)
thread_title:  Qualité de l'environnement de travail 

message: 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)
replies: text: Partie remplacée --41.250.90.71 (d) 28 mars 2012 à 20:46 (CEST)
thread_title:  Supprimer les rappels sur les méthodes agiles ? 

message: On trouve cette phrase dans l'article, je l'ai déplacée. Savez vous sourcer cette information ? Section "équipe de développement...
--41.250.90.71 (d) 28 mars 2012 à 20:46 (CEST)
thread_title:  Equipe auto gérée est elle la plus efficace des organisations ? 

message: 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)
thread_title:  Daily Scrum 

message: 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)
thread_title:  Refus et enfouissement des références historiques 

message: "(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 ! 
: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)
thread_title:  Estimation et Engagement (demande d'explications) 

message: 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 ? 
: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)
replies: text: Je partage, cela rend la page incompréhensible. Et si on pousse le raisonnement, il faudrait aussi renommer la page en "Mêlée" .--Nibbler869 (discuter) 29 mai 2020 à 21:58 (CEST)
thread_title:  Utilisation du terme propriétaire du produit et directeur de produit 

message: 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)
replies: text: 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). --NoFWDaddress(d) 30 avril 2014 à 09:09 (CEST)

text: 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)
thread_title:  Travail non vérifié 

message: 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
:C'est ignorer l'existence de la revue de sprint dont le feedback est justement là pour adapter le backlog produit à chaque sprint. Donc le backlog produit n'est pas figé en préalable des développements. Quant au sprint, il peut être annulé sur décision du PO ou son périmètre modifié à la demande de la devteam. C'est quand même pas mal comme capacité d'adaptabilité. Tout ceci figure dans le guide scrum. Donc ça ne me choque pas que cette phrase ait été retirée.--Nibbler869 (discuter) 19 juillet 2019 à 23:06 (CEST)
thread_title:  Encore une vérité effacée 

message: J'ai ajouté quelques bandeaux pour mémoire, afin d'y revenir d'ici quelques jours (c'est les vacances, profitons-en !) et sourcer ces passages qui me semblent les plus critiques car pas décrits dans le guide Scrum. Pour ce qui est décrit dans ce dernier, ça risque d'alourdir le texte si chaque section est sourcée.--Nibbler869 (discuter) 19 juillet 2019 à 23:18 (CEST)
thread_title:  Manque de sources