Pour une discussion plus complète sur les origines de Scrum, voir la page Papiers Scrum.
Scrum découle directement de l'article de Takeuchi et Nonaka publié dans la Harvard Business Review, "The New New Product Development Game". Le meilleur exemple de ce document est Honda et son style de développement de produits. J'ai remis ce document à Kent Beck, à sa demande, en 1995, alors qu'il mettait au point la programmation eXtreme.
La réunion quotidienne Scrum découle directement de l'article de Jim Coplien sur Borland Quattro Pro.
La théorie des systèmes adaptatifs complexes, en particulier celle mise en œuvre par iRobot à l'aide de l'architecture de subsomption du professeur Rodney Brooks, a été utilisée pour mettre en œuvre des règles simples permettant à une équipe moyenne de démarrer dans un état hyperproductif.
Tout cela s'est déroulé en 1993. Les excellents résultats obtenus par Scrum avec de nouveaux produits en 1994 et 1995 ont suscité l'intérêt de Mike Beedle et de Ken Schwaber pour le processus. Ken a clarifié le processus pour la consommation mondiale à partir de 1995 et Mike Beedle a dirigé l'effort de rédaction du document sur les modèles PLoP sur Scrum en soulignant qu'il s'agit d'un modèle organisationnel permettant aux équipes d'atteindre un état d'hyperproductivité.
La première équipe Scrum, qui a démarré en 1993, a rapidement atteint un état d'hyperproductivité en mettant en œuvre toutes les pratiques d'ingénierie connues aujourd'hui sous le nom de XP, ainsi que certaines pratiques qui n'en font pas partie. En particulier, elle a utilisé des stratégies pour choisir les éléments du Sprint Backlog qui généraient l'apparition la plus rapide de nouvelles fonctionnalités. Cela a non seulement imposé le développement de tests d'abord (et de documents d'abord également), mais a également créé une stratégie similaire à l'ingénierie simultanée de Toyota.
Peu de mises en œuvre de Scrum atteignent l'état hyperproductif pour lequel Scrum a été conçu (5 à 10 fois les performances normales). Celles qui y parviennent mettent toutes en œuvre des variantes des pratiques d'ingénierie XP et nombre d'entre elles, comme la mise en œuvre CMMI de niveau 5 de Scrum, pilotent l'ensemble de la mise en œuvre dans une perspective d'allègement.
Takeuchi et Nonaka sont les parrains du Scrum et lui ont donné son nom. Leur dernier livre Hitosubashi clarifie et étend leur travail dans l'article original de la Harvard Business Review et il est utile pour ceux qui essaient d'atteindre un état hyperproductif. Il y est beaucoup question de lean (bien que Takeuchi et Nonaka ne mentionnent jamais le lean car ils le considèrent comme un concept occidental qui ne fait qu'imiter le Toyota Way).
Le premier Scrum a été influencé par les concepts de la théorie des contraintes de Goldratt et s'est concentré sur muri, mura et muda. L'élimination des perturbations du flux a été initiée après les premiers sprints afin d'éliminer les temps de réinitialisation entre les sprints, ce qui est désormais accepté comme une meilleure pratique dans le cadre de Scrum. Mura, ou l'évitement du stress sur une personne, un système ou un processus, a produit des états hyperproductifs combinés à un taux d'attrition nul dans plusieurs des entreprises Scrum où j'ai dirigé l'ingénierie. C'est ce que l'on appelle aujourd'hui le rythme durable dans le développement Agile. Enfin, Muda, ou la réduction radicale du gaspillage, a toujours été un moteur principal dans toutes les entreprises où j'ai mis en œuvre Scrum. Il est impossible d'atteindre un état hyperproductif sans cela.
Jim Coplien a souligné à plusieurs reprises au fil des ans que la théorie des contraintes présente des inconvénients et que certaines pratiques XP devraient être évitées. J'ai fait de mon mieux pour éviter les écueils qu'il a signalés.
Scrum a été spécifiquement conçu pour traiter :
Loi de Ziv - les spécifications ne seront jamais entièrement comprises.
Loi de Humphrey - l'utilisateur ne saura jamais ce qu'il veut avant que le système ne soit en production (peut-être même pas à ce moment-là).
Le lemme de Wegner - un système interactif ne peut jamais être entièrement spécifié ni entièrement testé. C'est l'analogie logicielle du théorème de Godel.
Le lemme de Langdon - les logiciels évoluent plus rapidement lorsqu'ils s'approchent de régions chaotiques (en veillant à ne pas déborder sur le chaos).
Ainsi, toute association de processus prédictifs ou définis avec Scrum est un exercice futile.
Cela dit, je suis tout à fait d'accord avec Ken Schwaber pour dire que tout cela devrait être guidé par le principe "inspecter et adapter" et par l'établissement d'une liste d'obstacles classés par ordre de priorité. L'établissement de la liste des obstacles par ordre de priorité permettra de rationaliser le flux, de réduire le stress et d'éliminer le gaspillage dans l'ordre approprié, faute de quoi, ironiquement, les principes de l'allègement seront violés. Scrum découle directement d'une compréhension simultanée de Les travaux de Langton sur la vie artificielle et les travaux de Rodney Brooks sur l'architecture de subsomption.
"Il existe un spectre de travail dans lequel Langton se situe à une extrémité et Brooks à l'autre. À l'extrémité de Langton, l'objectif est de créer des simulations virtuelles (rien de physique) qui présentent des caractéristiques telles que le changement évolutif et la complexité émergente. Une grande partie de ces travaux a été réalisée en collaboration avec l'Institut de Santa Fe, il y a une dizaine d'années. L'enthousiasme qu'ils suscitaient est aujourd'hui bien retombé. À l'extrémité de Brooks, les roboticiens utilisent des modèles d'organismes réels pour organiser leur structure. Les premiers travaux dans cette veine comprenaient un cafard artificiel, et c'est une caractéristique de la recherche de Brooks au MIT depuis une quinzaine d'années. Bien qu'ils soient tous deux inspirés par la biologie, les objectifs et les méthodes sont très différents".
http://web.stanford.edu/class/cs378/
French 
English 
Spanish