把很早之前写的scrum相关论文中的某段发出来供大家参考

置顶感谢，受教大神:

参考文献

[1]百度百科，Scrum.https://baike.baidu.com/item/Scrum/1698901?fr=aladdin [H],2018-4-16

[2] Mike Cohn.译者: 廖靖斌/吕梁岳/陈争云/阳陆育《Scrum敏捷软件开发》[M],清华大学出版社，2010

[3] 周勇.Scrum方法在c公司软件项目管理中的应用研究 [D].华东理科大学，2016（03）

[4] 夏辰未.Scrum在M公司项目管理中的应用[D].西南交通大学，2015

[5] 刘谦.《敏捷方法在软件项目管理中的应用》[D] 上海交通大学,2011

[6]禅道.http://www.zentao.net/book/zentaopmshelp/103.html[H],2018-4-16

前言

Scrum这个名字起源于英式橄榄球的对阵争球，争球双方各有8名队员参与，各方出3名前锋，在水平排中并肩站立，横跨顶部和肩部彼此相对，其他前部在臀部肩膀阵容后站在彼此后面

橄榄球对阵争球的场景和接力赛场景对比，我们看看两者什不同？ 橄榄球运动，团队作为一个整体前进，而接力赛大部分时间，是一个运动员跑，其他三个站着看。1986年，有人首次把Scrum应用于产品开发，他们表明：传统“接力式”开发方法不能应对市场变化，而整体或”橄榄球式”的方法----团队整体前行，在团队内部传球前进，也许可以更好的满足当前激烈的市场竞争。 1993年 scrum之父 Jeff Sutherland首次将 Scrum用于软件开发，2001年敏捷宣言及12条原则发布、敏捷联盟成立， 从此 Scrum作为一种主流的敏捷方法，被越来越多的人接受。 2002年Scrum联盟成立。 我们所说的CSM认证就是Scrum联盟颁发的认证。[1]

第2章 Scrum特点与敏捷原则概述[2]

敏捷宣言

我们的最高目标，是通过尽早和持续地交付有价值的软件来满足客户；

拥抱需求变更，即使项目后期也要善于利用需求变更帮助客户获取竞争优势；

不断交付可用的软件，周期几周到几个月不等，越短越好；

项目过程中，业务人员和开发必须要一起工作；

要善于激励项目人员，给他们以需要和环境支持，并信任他们；

面对面沟通是最高效的方法；

可用的软件衡量进度的主要指标；

敏捷过程提倡克持续的开发，项目方，开发人员和用户应该保持恒久稳定的进展速度

做到简洁，即尽最大可能减少不必要的工作，这是一门艺术；

最佳的架构，需求和设计出自于自组织的团队；

团队要定期反省如何能做到更有效，并相应地调整团队行为；

2.1 Scrum框架

Scrum Guide是这样定义Scrum的：Scrum是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并创造性地交付尽可能高价值的产品。

第一、框架

什么是框架呢？ 可以举个例子，房屋的柱子，地基是框架，而不是房子中的墙壁和家具。所谓框架就是基础，就是原则，计框架必然是稳定的。同时框架又是可以灵活填充的。 Scrum框架，就是这样的，用原则基础的东西（scrum团队，团队角色，团队工具，scrum规则）。相scrum框架的填充如 内部定制的使用工具，ERP等等，只要达成目的就行。scrum不明确你需要填充的“内容”，这些细节应该是Scrum master根据实际环境考虑的。

第二、最佳适用场景-复杂问题

根据软件开发维护工作的复杂程度，可以把软件相关工作分为3类：简单问题、繁杂问题、复杂问题。简单问题指需求很明确、很稳定、不会变化，需要掌握的技术很简单，最佳解决方案显而易见。比如安装一个软件，一路点“下一步”，就安装好了。繁杂问题指诸如软件日常维护、修bug之类的工作。复杂问题指创新型的新产品开发，或者现有产品的创新型的新功能的开发。Scrum最适合用来处理复杂问题，指导创新型软件开发工作。

第三、高价值

正如敏捷的12条原则中的第一条所述，“我们最重要的目标是通过持续提供有价值的软件来满足我们的客户。这里的价值是指对顾客的价值，是指商业价值。Scrum并不追求软件开发范围最大化，不认为开发的功能越多越好，而追求商业价值最大化。

最后，我们用三句话总结一下Scrum能干什么。第一句，Scrum是一个框架，它告诉我们Scrum团队的角色、进行的活动和产出的工件不能变，又允许我们自定义实施Scrum的具体细节。第二句，Scrum最适合用来指导创新型产品的开发。第三句，Scrum帮忙我们交付高价值产品。

2.2 Scrum角色、过程、工件

第一、角色

在scrum项目开发中可以包含多个scrum团队，每个团队中Scrum中的角色分为三类，即product owner、Scrum Master、team。

Product owner 是授权的产品领导核心，是唯一能对产品方向、产品要求、产品优先级功能、（限定期限中）进行最大化产出和规划下一阶段计划的角色

主要沟通工作分为对外和对内2方面。1.了解外部干系人，以分析和理解该干系人的期望及需求，从而精细化对外部干系角色进行定义，制定精确的用户故事 产品架构、流程，维护product backlog。 2.将产品规划及产品设计场景触发等输出给team帮助开发人员在开发过程中正确理解产品，规避理解偏差带来的风险问题

Scrum Master是团队中协调式领导（本质无任何职权），是帮助PO、Team角色正确理解scrum精要，确保内部团队更好的协调，提升整个团队生产力，提高整个产出效率，一般来说这类角色以scrum经验丰富的人担任

Team是有该case中所需迭代产品专业人员组成的（架构师、设计师、开发、测试等等）跨职能人员，负责在每个sprint周期内完成工作任务及实现方式，并在冲刺完成后交付可运行的产品交付物（注：一般5～9人为宜）

第二、过程

产品计划： Scrum方法中，首先由 product owner将利益干系人进行分解（客户、用户、市场、高层等等），了解期需求及期望，通过此建立产品愿景及 story，再根据需求权重将每项的商业价值、需求类型、风险判断、开发难易、紧急程度等等判断其优先级建立 product backlog。再通过计划会确定此次产品迭代增量目标（2-6周）

冲刺会议：在冲刺大会上，我们也称为冲刺计划会议。目的是将 PO细化的产品功能 list供开发团队选择（在此会议之前 PO须重新审视优先级，并反复确认）开发团队在选择过程中根据优先级从高到低选择出细化开发任务，细小到自己可2天之内开发完成，形成 sprint backlog，同时明确产品评审会、回顾会时间（4-8小时会议）；

每日站立会议：每次会议控制在15分钟左右，由 PO、 M、 T组成会议成员，每个人都（必须）发言（其他人只能作为旁观者不能发言），你必须亲自向所有成员报告你昨天完成的任务，并向所有成员承诺今天要完成的任务，并且还可以提出你无法解决的问题。每个人的答案完成后，他们必须去黑板更新他们自己的Sprint烧录地图。并排除障碍；

冲刺评审：目的是对本次冲刺任务进行审核，冲刺会议忆由利益干系人、用户、 PO、 M、 T参加，在此过程中由 T向他人进行演示冲刺计划中的增量迭代功能，在演示完后，验收者对此进行一定反馈，以便以后进行迭代；

回顾会议：由PO、M、T对此过程进行回顾，讨论其过程中的缺失和可行性方法，并提出和应用改进意见；

第三、工件

1.product backlog：产品负责人结合产品利益关系人、M、T的意见建议及商业价值，风险等考量，形成优先级的产品列表降序排列。优秀的产品list具有以下特征：1）没有废话；2）动态（实时调整） ；3）容易理解，4）有初步的投入产出计算

2.sprint backlog：由Team成员对sprint中需要交付的功能可视化的表达，其包括预期计划时间，实际耗时，用户故事，目前状态，验收标准等等，sprint backlog在执行过程中是不能改变的，除开 tame在过程中确认无法在当前时间下完成，这时PO和team会再次就sprint backlog重新调整

3. 燃尽图：burndown图表用于显示sprint中剩余工作任务的总量，以了解sprint的开发工作量和完成趋势。结合 sprint backlog来对过程中问题解决以改进的可视化工具

2.3 Scrum转型

第一、ADAPT模型

ADAPT需要满足5个要求，即意识、渴望、能力、推广、传递

要知道所有的革命都是来自现实与理想的不平衡，即使如此，意识到目前的方法效率不佳还是一件难事，一般来说行动时间与意识时间都有一个时间差。

有意识后我们需要强烈的动机去渴望改变，就好像你想找个女朋友但你未必行动，必须得有个强烈的动机去找女朋友。渴望改变是对动机的支撑，要说服一个人渴望改变，必须满足天时地利任何，时机不对多说无益，但是在对的时间、对的地点、对的人去给他说或许就能从意识改变到渴望改变

意识到改变，渴望改变还需要与之相匹配的能力才行，在转型过程中，scrum团队不得不对过去告别，不断接受拥抱变化，比如使用新的工具，新的技能，新的团队工作思维模式，学会适用在短时迭代的高效率、高投入产出比的项目

成功验证scrum转型后，就可以将此方法推广到其他项目组，同时公司制度也应为这种转型进行改变，保持scrum的成果，比如绩效奖金等等[3]

第二、逆抵触

scrum转型会对规章制度权利分配（底部）重新洗牌，导致有人获利有人利益受损，因此基于风控原则来说，在执行scrum前我们要了解自己的组织架构并对有可能产生的影响作出准确的预测抵触，并将风险前置。

对于改变每个人都有不同反应，马尔塞怀特和英格拉姆将此分为3类即创新主义者、实用主义者、保守主义者。创新主义喜欢改变，实用主义可能是抵触者也可能是支持者，保守主义最可能是抵触者

据07研究抵触研究发现，管理者抵触的首要原因是控制和权利，其次是缺少时间，再次是对现状满意，而对员工而言抵触的原因是缺乏意识，其次是对未知事物恐惧，再次是缺乏职业上的安全感

第三、角色转变与技术转型

在一般的开发管理流程上，部门leader负责资源分配和进度监管，项目经理是项目的负责人，（产品）分析员承担需求调研分析挖掘等任务，架构师负责整个程序的的架构设计和技术指导，开发人员负责代码的撰写，功能实现、缺陷修复，测试人员则负责测试产品找出缺陷，尽量避免将有缺陷的产品在线或交付给客户。以上角色在scrum的改变下职责上会发生或多或少的变化。

1） 部门leader

在一般开发模式下说，部门leader拥有行政权利，可以分配项目人员还可以直接参与项目任务的分配。Scrum转型后，工作任务是team中个人自己选择，部门leader不能干预，部门leader和scrum团队之间相对于之前项目关系会减弱。

2） 架构师

scrum角色中是没有架构师职位的，架构师角色的职责会有开发team循序渐进完成整个架构设计工作。在技术咨询上开发人员也应该对架构师意见进行交流学习，同时在产品功能架构出来后，PO（产品负责人）应与架构师沟通交流意见。

3） 分析员（产品经理）

传统的分析员（产品经理）对于产品知识及业务相当熟悉，同时善于沟通协调，一般来说产品经理会在担任产品负责人的角色，传统的的分析员是尽量完成需求分析，而scrum则要求动态分析需求，尽量比冲刺规划早一些完成需求分析任务，在传统开发流程中，一般采用文档进行信息分享，在scrum中提倡非正式的情况下对于team进行分享。

4） 开发人员

传统的开发人员主要负责需求中的功能实现、并将产品中的缺陷进行修复，在scrum团队中，开发人员不再告知需要完成哪些功能，而是主动获取理解和掌握需求。

5） 测试人员

scrum转型后，开发团队的重心从理解需求到讨论需求，故而测试人员不能在确保实现需求文档中功能作为职责，而是主动与PO（产品负责人）、用户、客户和其他干系人交谈，了解某个特性的期望响应时间是多久，业务流程是怎样的等等，在测试环节，不能像以前一样各司其职，完成分配所属的测试模块，而应该和开发人员及其他测试沟通协作，且从手动过度到自动化测试。

第3章 基于D公司实战中Scrum的经验方法论

3.1 D公司Scrum项目过程改进

第一、D公司困境之问题列表

本来是想基于整个项目贯穿说一次D公司困境，篇幅有限故此直接罗列问题。

1. 需求中途老是变更导致开发团队无法按时完成（需求收集问题）

2. 需求传达不准确导致过程中需求方与开发团队沟通成本增加（沟通问题）

3. 没有规范的需求流程，各自为政，沿用上家公司的流程，没有达到有效的团队契合

4. 代码编写具有个人特色，导致接收代码者，阅读代码困难

5. 开发方式不能应对市场，导致经常延期（本地构建）

6. 开发代码质量不高，再后期上线需更改代码时，消耗大量时间成本（测试驱动开发）

7. 代码无法系统化规划，缺失架构观及集体共享，使得开发人员对其他模块不了解，导致开发出现代码缺陷（代码集体权）

第二、需求收集和分析的改进

不管是什么样的需求管理，需求收集与分析都是最重要的环节，挖掘用户、客户、市场的需求，并要在过程中保证传递的信息准确。

1. 在scrum敏捷开发模式下，产品负责人在内部是唯一需求方，产品负责人参与整个项目可以最大程度上规避传递信息的误差率，产品负责应该定期与不定期拜访需求源（用户、客户、市场）从需求源上了解公司产品问题，把反馈整理到product backlog中去。

2. 真正挖掘客户需求和市场趋势，使用外部数据如：行业数据，艾瑞咨询、某某研究院对产品目标用户的行为偏好，使用习惯，未来趋势来定位产品走向，同时也能让自身产品落地，贴合用户。

3. 需求的描述：应用简洁易懂的句子即描述用户或角色处于什么样环境下，需要达成什么样的目标。讲故事的使用可以清楚地表达用户的真实需求并避免理解上的偏差。

用户故事invest原则[6]

Idependent(独立的):用户故事应该独立于（尽可能）另一个用户故事。故事之间的依赖导致计划的增加，建立了有限的水平，故事估计这些任务非常困难。通常，通过组合用户故事或分割用户故事可以减少依赖关系。

Negotiable(便于沟通的):一个用户故事是便于沟通的。故事卡片是对故事细节的简要描述。这些详情是通过讨论阶段来完成的。有很多细节的卡实际上减少了与客户的谈话。

Valuable(有价值的):每个故事都必须对客户有价值（无论是用户还是买家）。让用户故事有价值的好方法是让客户写下来。一旦客户意识到用户故事不是合同并且可以谈判，他们会很乐意编写故事。

Estimable(可估计的):开发人员需要估算用户故事，以确定有限的级别并计划故事。但是让开发者难以估计故事的问题来自：缺乏领域知识（在这种情况下需要更多沟通），或者故事太大（需要将故事分成更小的故事）。

Small(短小):一个好的故事应该在工作量方面较短，描述具有代表性，且不超过2-3人周的工作。超出此范围的用户故事在范围和估算中会有很多错误。

Testable(可测试的) :用户故事可以测试以确认完成。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子：软件应该是易于使用的。

。

第二、共识需求规则流程

基于Scrum框架来说，需求过程本质上分为，收集确定和 细化迭代product backlog 2个阶段。

收集确定：由PO首先与用户（客户、市场）沟通，并确定整个项目的整体架构，对于业务范围较大的管理系统，可以由PO将干系人拉到一起，召开产品密集需求会议，由PO确最后确认需求优先级，发现其不合理或缺陷的地方。生成“最终版”产品列表后，由干系人签字，作为验收基石；

细化迭代：冲刺活动前，由PO 重新审视剩余产品，并将优先级高的需求细化，补充完整，进而为开发铺垫（有甲方时需与甲方确定）。

共识需求规则流程是为了让大家统一工作节奏，保证每个时间段知道自己所参与的项目活动及角色职责；

第三、明确需求变更规则流程

在功能开发过程，PO会受到老板及甲方（市场）的需求制约，导致需求变更，这时PO首先确定接受到的需求源是谁？需求是否真实，需求范围影响，开发成本及商业价值，在确认需求确实需要变更的时候， PO署《需求变更报告》同时让需求提出者签字（甲方或老板，PO提出自己签字）同时对团队强调不管变更对进度的影响和成本影响都需要纳入开发计划。这样做是为了对整个产品开发历史做回顾，同时作为对上级和甲方报告进度延期的凭证[4]。

3.2 技术改进

第一、测试驱动开发

通过先一步编写测试代码写入开发代码中来保证开发代码符合需求，覆盖率高的代码测试代码可以结合“持续集成工具”来提提高产品代码质量。

第二、不定期重构

常规：基于代码互查获得代码质量反馈，开发需要代码进行重构，迭代自身代码质量，优化规范。

 不定期：任务空隙提倡开发不定期定通过重构代码过程改善自身代码质量。

第三、持续集成

通过使用集成工具，让团队在本地服务器上执行本地构建，然后提交版本控制库。确保代码变更不会导致集成失败，开发人员每天至少更新一次代码，同时保证每次构建都要100%通过（能生成可用性产品），如若构建失败将最高优先级处理。持续集成有助于检查缺陷，了解软件健康状况，减少假设并提高产品质量。

第四、代码集体共有权

之前开发人员只对自己的代码负责，但是代码集体权提倡团队对每人对代码负责，显著表现为每人都可以编写他人写的代码或修改他人的功能，若需要修改他人代码可以无需让原著开发帮忙修改，代码集体权的好处是让团队对代码结构了解，而不存在“祖传代码”的问题，降低协作成本，但是修改他人代码也会带来一定风险，可以通过“测试驱动开发”和持续集成快速发现问题，并很快定位代码缺陷。

第五、代码规范标准

在推行代码集体权中，需要看的懂他人代码，这时代码规范的重要性就显而易见，一行行拥有代码规范的代码会对团队协作非常有帮助，所以开发团队讲代码的风格，函数及变量定义、注释规范、代码属性一一统一起来，并形成《代码规范手册》，作为对代码规范的标准文档，同时也可以给新人进行培训。

第4章 Scrum局限性

随着我们不断加深对 SCRUM的理解发现 SCRUM在指导研究和开发，特别是复杂的软件开发方面有很大的局限性：SCRUM涵盖了软件开发生命周期的构建阶段，但它缺少了团队初始创建阶段，项目启动，即将发布的软件版本以及软件阶段维护的指导价值。