一、Scrum开发流程介绍
SCRUM 方法是由Ken Schwaber 和Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM 方法最初实践于Easel 公司(1993 年) ，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。SCRUM 提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master 、SCRUM Team 、Demo 等模式已被PLOP 作为组织和过程模式（Organizational and Process Pattern）的标准。
SCRUM 的基本假设是：开发软件就像开发新产品，无法一开始就能定义Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。Scrum 有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进，因此，SCRUM 非常适用于产品开发项目。
SCRUM 开发流程通常以1-6 周为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于每个周期后交付成果，团队每天用15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做scrum meeting。
SCRUM 较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。SCRUM方法的开发过程包括三个过程：(1) 计划和体系结构设计（确定性过程）Backlog；(2) Sprint（经验性过程）(3) 交付和巩固（确定性过程）SCRUM 过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint 期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。SCRUM 对过程的管理有很多独特的方法。SCRUM 在实践中大大提高了生产率（据软件生产率组织的Capers Jones 称可提高 6 倍）。
名词解释:
1、SCRUM Meeting:团队每天用15 分钟开会检视每个成员的进度与计划，了
解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做
scrum meeting。
2、Sprint:SCRUM 开发流程通常以1-6 周为一个迭代周期，每个迭代周期叫
做一个Sprint，由客户提供新产品的需求规格开始，发团队必须尽力于每个周期后交付成果。
3、Product backlog：这份文件主要记录被区分先后次序的客户要求列表。
Product owner 要经常更新它。与软件项目有关的任何人都可以就里面的需求提出建议，但是只能由Product owner 来更改和分出优先级。此文档还应该包含对所有功能的总体概括。
二、Scrum中的角色分配
Scrum 中只有三个角色：Scrum master，Scrum team 和Product Owner
1. Scrum master
Scrum master 有别于项目经理一职，他的职责是帮助Scrum team 来处理除开发任务之外的其他事务，例如安排和主持与客户、管理层人员和股东开会。Scrummaster 帮助开发团队进行一些重要的团队本身无法做出的决策，并且充当开发团队和外部世界之间的防火墙。Scrum master 只是引导团队，而非控制他们。最终，Scrum master 必须处理和项目有关的所有问题，包括团队内部问题，与管理层的接触，或者团队能力不足等。
2. Scrum team
Scrum team 是可以进行自我组织的，即此团队内部自己决定哪个开发任务由谁来完成，每个成员具有相同的责任和权威。同时，每个成员都有一定的应付开发任务的知识和经验。团队内部具体是什么结构并没有被定义，而是有实际的项目来决定团队的规模和结构的复杂程度。Scrum team 的规模介于5～9 人。对于查过此规模的团队，可以将它划分为较小规模的拥有5～9 人的小组。这样，小组内部构成一个Scrum team，而小组的Scrum master 们又构成上一层次的Scrum team。
3. Product owner
Product owner 对所有的需求、投资回报率（Return Of Investment）、项目
目标及整个项目负责。他负责更新product backlog 并将其中的需求区分先后次序。
三、沟通和信息交流
3.1 每天召开Scrum meeting
在scrum meeting 中，每个人需要回到以下问题：
从上次Scrum meeting 到今天做了什么？
接下去的计划是什么？
有什么障碍和困难？
如果一个成员的问题涉及到其他成员，由他们会后自己安排临时小会讨论。Scrum meeting 是为了帮助成员同步他们的工作，能够知道彼此地进度；同时让与会者了解遇到的障碍，这样大家可以互相帮助解决问题。
3.2 Sprint 计划会议
Sprint 计划会议由2 个4 小时的分会组成，召开的时间是每个Sprint 的开始阶段。在第一个 4 小时会议中，Scrum master, Scrum team, 管理层，Product owner 和stakeholder（如果有可能的话）讨论在接下去的Sprint 中将完成什么任务：product backlog 中优先级最高的需要实现的功能或完成的测试任务应该被选中；本Sprint 的目标也被确定下来。（确定Sprint 目标）。
第二个 4 小时会议由Scrum master 和Scrum team 参加。与会者把选定的任务再细化成若干小的步骤，写入Sprint Backlog。每个小步骤应该能够在大约4~16个小时内完成。如果一开始无法细化，可以在接下来的日子里逐步细化。另一个很重要的会议任务是必须完成对所要完成的工作有一个总体的设计。
3. 3 Sprint-30 天迭代
一个Sprint 以30 天为周期，在期间进行产品的开发和测试工作。一个Sprint 结束之后，另一个Sprint 接下去进行，直到所有的任务完成或者资金用完为止。这个过程称为迭代。在每一个Sprint 结束之际，应该可以展示可工作的产品。Sprint 的结束如期不能改变。如果在Sprint 结束时，有些工作没有完成，那么它们应该被写回Product Backlog 中，以便在下一次Sprint 计划会议中讨论执行它们。如果在Sprint 结束之前所有预设任务完成，可以在product owner 的帮助下，从product backlog 里选出一些任务加入Sprint backlog。除开发团队外的任何人都不可以修改Sprint backlog。管理层人员，product owner，Scrum team 和Scrum master 如果觉得当前的Sprint 已经没有用出或者不可能完成，可以终止一个Sprint。当一个Sprint 结束时，测试和文档应该已经完成，并且可以提交产品了。
3. 4 回顾会议（Review meeting）
在每一个Sprit 结束时，需要为product owner 和stakeholder 召开一个 4 小时的回顾会议。会上，Scrum team 简单地展示在这个Sprint 里完成的工作（他们对会议的准备不能超过 1 小时）。同时，关于解决方案的优劣也应在会上进行
阐述和分析。演示的结果会和计划会议中确定的Sprint 目标相比较，以决定开发团队是否完成了他们自己设定的任务。在会上，客户可以有机会改变未来产品开发的方向，从而使开发团队能够应对不断变化的客户需求或外部环境。
3.5. Sprint 总结会议（retrospective meeting）
在回顾会议后，需要召开 3 小时的总结会议，目的是总结经验教训，改进下一个Sprint 的工作。总结会议由Scrum master, Scrum team 和，作为可选，Product owner。
每个与会者应该回答以下两个问题：
在过去的一个Sprint 什么方面进行的很好？
在下一个Sprint 里，那些方面可以改进？
在会议上，Scrum master 的工作不是给出这两个问题的答案，而是记录下会议的结论。经过讨论好，问题的答案和解决方案可以作为非功能性需求写入Sprint backlog 里。这样，就可以改进下一个Sprint 的工作方法，提高工作效率，并且去除可能的障碍。
四、项目中的相关文档
1. Product backlog
这份文件主要记录被区分先后次序的客户要求列表。Product owner 要经常更新它。与软件项目有关的任何人都可以就里面的需求提出建议，但是只能由Product owner 来更改和分出优先级。此文档还应该包含对所有功能的总体概括。
2. Sprint backlog
主要记录包含优先级的在当前Sprint 里需要完成的活动或步骤。只有Scrum team 才可以更改。在Sprint 期间，此文档应该不断更新。文档里应该描述每项活动，责任人和完成时间。开发人员在每天工作完毕时更新时间信息。此文档由Scrum master 负责管理和协调。
3. Burndown chart（剩余任务图）
有两种剩余任务图。产品任务图显示还有几天的剩余工作和已经完成了多少。Sprint 剩余任务图则显示要完成所有在Sprint 中定义的工作，还有多少小时的工作量。
4. Sprint 目标
在计划会议中，当前Sprint 所要完成的目标应该写在Sprint 目标文档中。这样，有了参考目标，就可以组建团队并且指导团队向正确的方向开展工作。
SCRUM的基础知识 Scrum 是迭代的，增量型的流程。Scrum 构造的产品迭代周期为Sprints, 工作的迭代时间一般为一到四周。Sprints 是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。在每一Sprint 的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint 的末期完成这些项目。每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint 的末期，团队将对这一阶段工作结果作——展示并取得相关的反馈，为下一Sprint 做好准备。Scrum 强调生产可以使用的产品，意指在Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。 Scrum 中的角色 在Scrum 中有三个基本的角色：产品所有者，开发团队成员和ScrumMaster。 产品所有者（Product Owner）负责收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为产品的形式。在一些情况下，产品所有者正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者这一角色在许多企业中是由产品经理或产品市场经理担任。 开发团队成员构建客户将会购买的产品：软件，网站，或者是任何一种产品。Scrum 团队通常包括五到十个成员，尽管团队大到15 个成员和小到3 个成员也有很好的收效。团队应该包括所有交付工作所需的专门人员——例如，一个软件项目的开发团队包括程序员，界面设计师，检测员，市场人员和研究人员。开发团队不仅构建产品，他们也向产品所有者提供让产品尽善尽美的建议和想法。开发项目包括15 个或以上的人员时，通常会被划分为若干的Scrum 团队，每一团队注重于产品开发的不同方面，并相互紧密的协作。团队成员同时可以参与其他项目开发，这样比只限制开发团队致力于Scrum 更能提高生产效率。团队内部成员也可以在不同Sprint 中变化，但是这样会减少整个团队的生产效率。 ScrumMaster 的任务是以任何方式帮助整个团队取得成功。ScrumMaster 不是团队中的经理；他或她是服务于整个团队，帮助团队铲除壁垒而取得成功。协助团队会议，并支持Scrum 的实践。在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些团队可以是其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的ScrumMaster 可以有不同的背景和学科：项目管理，工程技术，设计，检测。ScrumMaster 和产品所有者不应是同一人；有时， ScrumMaster 可能会号召拒绝产品所有者（例如，他们有时会在某一Sprint 中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster 不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。 除以上三个角色之外，还有其他对于项目成功作出重要贡献的人员：可能其中最重要的是经理。他们的角色在Scrum 中的发展, 他们仍保持了相当重要的位置——他们支持开发团队使用Scrum，他们为整个项目的开发提供知识，技术和各种必要的协助。在Scrum 中，这些人转化了以前“保姆”式的角色（布置任务，收取进程报告，和其他一些谨小慎微的管理方式），取而代之的是承担起更多的“指导“作用（指导职业发展，在职辅导培训，扮演魔鬼的代言人，协助铲除障碍，帮助解决问题，提供创新的建议和指导团队成员的技能发展）。为了能更好地实现这一变化，经理们需要改进他们的管理方式方法。
产品负责人（Product Owner） 主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。 流程管理员（Scrum Master） 主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。 开发团队（Scrum Team） 主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。 Scrum流程图
//------------------------ 下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。 什么是Sprint？ Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。 如何进行Scrum开发？ 1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负 责的； 2、Scrum Team根据Product Backlog列表，做工作量的预估和安排； 3、有了Product Backlog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议）来从中挑选出 一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog； 4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任 务的工作量在2天内能完成）； 5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行Daily Scrum Meeting（每日站立会 议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）； 6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集 成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员； 7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）； 8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言， 总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
一、Scrum开发流程介绍 SCRUM 方法是由Ken Schwaber 和Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM 方法最初实践于Easel 公司(1993 年) ，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。SCRUM 提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master 、SCRUM Team 、Demo 等模式已被PLOP 作为组织和过程模式（Organizational and Process Pattern）的标准。 SCRUM 的基本假设是：开发软件就像开发新产品，无法一开始就能定义Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。Scrum 有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进，因此，SCRUM 非常适用于产品开发项目。 SCRUM 开发流程通常以1-6 周为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于每个周期后交付成果，团队每天用15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做scrum meeting。 SCRUM 较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。SCRUM方法的开发过程包括三个过程：(1) 计划和体系结构设计（确定性过程）Backlog；(2) Sprint（经验性过程）(3) 交付和巩固（确定性过程）SCRUM 过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint 期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。SCRUM 对过程的管理有很多独特的方法。SCRUM 在实践中大大提高了生产率（据软件生产率组织的Capers Jones 称可提高 6 倍）。 名词解释: 1、SCRUM Meeting:团队每天用15 分钟开会检视每个成员的进度与计划，了 解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做
1.角色分工、职责与义务 本流程内按不同的职责将人员划分为四个角色：PO（Product Owner），PD（Product Designer）和开发人员和架构组（Architect）。 1.1.PO的职责与义务 1)PO的职责为收集提出的需求并对其进行分析，输出产品为可以直接应用于产品设计与 开发的需求文档。 2)需求文档是产品设计与开发过程中针对产品功能的唯一参考文档。 3)需求文档应当包含产品设计和开发中需要使用到的全部功能性信息，包括且不限于主要 功能模块划分、详细用例描述、系统输入与输出数据的定义等等。 4)需求文档必须为针对客户需求进行分析总结的结果，其中对功能的描述应具有通用性， 而不应仅针对用户提出某些特定场景。 5)需求文档中所有的内容都应是确定的和无疑义的，应保证任何人通过阅读需求文档所得 出的理解是基本一致的。 6)任何在系统使用过程中可以录入的数据都不是需求的一部分。 7)对需求文档进行的任何修改都应留有历史记录，记录中应包含新增或修改的章节、修改 的内容、进行修改的时间和修改人的姓名。 8)PO对需求文档中的内容拥有最终解释权。 9)PO需要提供的文档如下： 必须提供的文档：需求文档 非必须的文档：辅助其他人员理解需求的参考资料（比如行业规范，网站上的介绍，宣传资料，自己做的图表等等） 1.2.PD的职责与义务 1)PD的职责为按照需求文档进行界面和用户体验设计，输出产品为界面设计及相关说明 文档。 2)界面设计中应当完整体现需求文档中描述的全部功能。 3)界面设计不但应包含正常流程的界面和用户体验设计，也应当覆盖异常流程。 4)在不同页面中相同类型的元素（如：按钮、表格等），其样式应保持一致。 5)界面设计应直接体现最终产品的静态显示效果。 6)界面设计如以原型或屏幕截图的方式提供，那么其中应提供一份对基本的使用流程及一 些功能上的重难点进行描述的说明文档。 7)PD对界面设计中用户体验及显示样式部分拥有最终解释权。
Scrum开发流程 一、什么是Scrum? 开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。 Scrum 开发流程通常以30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与需求方于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于30 天后交付成果，团队每天用15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。 二、Scrum角色定义及名次解释 （一）有关Scrum的角色定义
（二）有关Scrum的名次解释 三、Scrum的过程简单介绍 1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的； 2、Scrum Team根据Product Backlog列表，做工作量的预估和安排； 3、有了Product Backlog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议）来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog； 4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）； 5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行Daily Scrum Meeting（每日站立会议），
?Sprint 计划会议1：原始需求者、产品负责人及团队一起，确定任务优先级，定出Sprint 目标和既定产品Backlog。?Sprint 计划会议2：团队将既定产品Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。?Scrum 每日例会：项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在15 分钟内。?Sprint 验收会议：由原始需求者或产品负责人断定实际所发布的功能是否与既定的Sprint 目标一致。 ?Sprint 回顾会议：项目团队分析Sprint中的成功经验和所遇到的障碍。 整个Sprint的周期（时间盒）确定为10天（两周），具体的时间安排为： ?Sprint会议（0.5天） ?开发（8天） ?验收&总结（0.5天） ?技术提升日（1天），自主学习技术 1、需求收集 1.1 需求的分类 需求可与分为业务团队的，也可以包括团度内部的，比如性能优化。 1.2 需求提交模板 ?–任务 ?–可用性问题（Bug） ?–性能问题 ?–概念想法 注意：即使是概念性的想法，目前技术上无法实现的想法都可以收集。
②优先级可从以下五种情况中选择 ?–特别的严重 ?–非常重要 ?–很重要 ?–普通 ?–低 注意：切忌将所有的任务的优先级都设置的非常的高，这里不提供非常紧急这样的表述。我们只会根据重要程度去执行任务，所以紧急的任务需要业务部门及需求方尽早的提出。 ③需求类型可以是两种类型 ?–详细需求 ?–毛坯需求 注意：我们的需求并不是要求一定要完整的，及时是一些非常毛坯的需求，也可以提交过来，毛坯的需求由产品负责人进行分析和梳理，暂不清楚的可选择搁置。 ④需求标题有自己进行书写，但是需要遵守的规范是采用动宾短语格式。 比如：―导出+CN酒店每天的PV、UV等流量数据‖ 注意：这里的需求内容一定是站长使用者角度是提出的，切勿出现专业的程序方面的表述：如添加一个导出的按钮。还有需要注意的是动词切忌使用大而宽泛的词，比如―管理‖，类似―管理关键词‖这样的需求是严格避免的，这样会使得要开发的内容变得没有清晰的边界。 ⑤详细描述需要按照用户故事的格式进行书写。具体用户故事格式的要求如下： 用户故事是从用户的角度来描述用户渴望得到的功能。需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。一个好的用户故事包括三个要素： ?角色：谁要使用这个功能。 ?活动：需要完成什么样的功能。 ?商业价值：为什么需要这个功能，这个功能带来什么样的价值。