敏捷方法之极限编程(XP)和 Scrum区别

敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum, 似乎很少有文章介绍这两者的区别,

发现一篇外文, 见解非常深刻, 特将其翻译一把.

原文(DIFFERENCES BETWEEN SCRUM AND EXTREME PROGRAMMING )在此:

http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming

作者总结的大致区别如下:

区别之一:  迭代长度的不同

XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队收到干扰

区别之三: 在迭代中,User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是: 如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.

别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量

Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证,但XP对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”

不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束

作者建议, 在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)

时间: 2024-08-28 04:11:14

敏捷方法之极限编程(XP)和 Scrum区别的相关文章

瀑布式开发、迭代开发、敏捷开发、XP与SCRUM的区别

瀑布式开发.迭代开发,区别[都属于,生命周期模型]         两者都是一种开发模式,就像设计模式一样,考虑的角度不一样,个人感觉谈不到取代一说. 传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好.特别是前期阶段,设计的越完美,提交后的成本损失就越少.我现在从事的外包项目就是这样的流程. 迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目

敏捷方法Scrum概述

• 敏捷方法是一类软件开发流程的泛称: • 敏捷方法是相对于传统的瀑布式软件过程提出的: • 敏捷方法可以用敏捷宣言(4条).敏捷原则(12条)来概括: • 敏捷原则通过一系列的敏捷实践来体现出来: • 敏捷方法有很多种. 敏捷的方法: • Extreme Programming (XP)极限编程 • Scrum • Adaptive Software Development (ASD)自适应软件开发 • Crystal Clear and Other Crystal Methodologies

DevOps - 与敏捷方法区别

章节 DevOps – 为什么 DevOps – 与传统方式区别 DevOps – 优势 DevOps – 不适用 DevOps – 生命周期 DevOps – 与敏捷方法区别 DevOps – 实施原则 DevOps – 工程师职责 DevOps – 自动化工具 DevOps – 总结 DevOps方法与敏捷方法的侧重点是不同的. 一个典型的软件开发各方合作过程,如下图所示: 敏捷方法解决客户和开发人员之间的鸿沟,如下图所示. DevOps方法解决开发人员和运维人员之间的鸿沟,如下图所示. 下

21天敏捷打卡--敏捷方法实现

常用的敏捷实践包含:精益.看板.Scrum.XP极限编程.水晶.DSDM动态系统开发.FDD功能驱动开发.AUP敏捷统一过程.OpenUP. <敏捷实践指南>将敏捷方法和看板方法是为精益方法的子集.因为他们都符合精益思想的具体实例,都反映了“关注价值”.“小批量”.“消除浪费”. 精益软件开发LSD TPS 面对场景 解说 原则 解说 过度 对员工和生产/研发过程施加不必要的额外压力 消除浪费 无法带来价值的事务就是浪费 违规 不切实际的需求导致过生产/研发程中的不均匀 尽快交付 短期迭代或小

《用户故事与敏捷方法》阅读笔记01

用户故事与敏捷方法第一章是对用户故事的概览.      首先第一个问题用户故事是什么?用户故事描述了对用户.系统或软件购买者有价值的功能.用户故事由三个方面组成,包括1 .一份书面的故事描述,用来做计划和作为提示.2.有关故事的对话,用于具体化故事细节.3.测试,用于表达和编档故事细节且可用于确定故事何时完成.      然后第二个问题细节,故事的细节可以用另外的用户故事来描述,多个小故事远远胜于一个庞大的故事.书上将大的故事成为史诗故事,那些史诗故事可以分为多个小故事.例如将"用户可以搜索工作

敏捷方法适合什么样的团队?

敏捷开发适用于研发团队吗? 距敏捷开发宣言的发布已经过去了将近二十年,现在很多团队都在思考“敏捷”的工作方式.营销团队想要尝试Sprint的方式来加速盈利,运营团队正在采用Scrum敏捷项目管理,而人力资源团队则正在寻求如何为公司战略注入更多的灵活可变性. 那么对于研发团队而言,敏捷实际上只是一套帮助解决大型且复杂项目的方法论.在工作中,如何正确的运用敏捷方法哪种方式,一直存在很多争论. 是否采用敏捷开发? 通常而言,复杂.大型的研发项目需要跨部门的协调,项目经理总是希望可以快速实施并交付产品.

如何用敏捷方法做测试?

敏捷的核心就是个"快"字:快速开发,快速推出,快速验证产品方向.说白了就是管理每个小目标,保证他们能够按时完成. 想要运用敏捷方法,要注意几点: 1.开发做完一个小功能马上开始测试,减少等待时间. 2.测试的工作量更加分散,不会出现一段时间无事可做,一段时间忙的要死的情况. 3.每次的bug都是针对刚刚开发完的功能,开发处理起来会更得心应手,减少沟通成本. 在与同事沟通中,我还了解到,将bug加入开发计划会大大影响他们的目标完成进度,往往问题刚整理出一些思路,就因为某些bug需要处理而

读《用户故事与敏捷方法》有感(五)

今天,读到了次本书的第三部分--经常讨论的话题,用户故事不是什么,用户故事的优势与不良征兆. 第一,用户故事不是软件需求规格的指南,这种需求规格指南强调的是"系统应该--",而且对于需求规格指南而言,在写下需求之前,每个需求的成本是不可见的.典型的情况是,一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档.随后把文档交付给程序员.这时程序员告诉分析师(消息会被转告给用户),完成项目要24个月,而不是分析师所希望的6个月.在这种情况下,分析师在编写团队没有时间开发的四分之

适用于kali linux的远程桌面开启方法(从windows xp 远程登录到kali linux )

为了解决Windows远程桌面访问Ubuntu 12.04 之一 中提到的VNC远程桌面的缺点(见http://www.linuxidc.com/Linux/2012-07/64801.htm),我们采用第二种方法XRDP,该方法支持多用户登录并远程桌面. 1.首先参考Windows远程桌面访问Ubuntu 12.04 之安装VNC中提到的安装GNOME桌面方法(点击这里): 2.进入GNOME界面,在左上角进入系统->首选项->桌面共享进行如下设置. 我们共享所使用的协议是rdp,所以我们要