敏捷方法与Scrum

一、什么是敏捷？

敏捷开发以实现最高的业务价值为核心， 通过不断梳理需求的优先级来消除在低价值需求上的资源浪费， 通过提高沟通效率来消除团队沟通上的资源浪飞， 鼓励团队在一起工作，使得团队信息更加紧密、更透明。敏捷开发通过细分项目的交付目标灵活轻便的管理方式，让团队能够及时市场急业务需求的变化，提高研发效率和生产力。

一种以人为核心，迭代，循序渐进的开发方法。

聚焦价值、应对不断变化的需求 敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

1.1-敏捷开发的优点

敏捷（AGILE）：

需求逐步完善；信息沟通透明；交付品客户满意可以满足不断变化的需求聚焦价值提升团队竞争力

1.2-传统开发和敏捷开发的区别

传统开发方式是计划驱动，用可变的时间和资源实现功能 敏捷开发方式是客户价值驱动的，用确定的资源和稳定的交付时间不断满足动态变化的业务需求，对整个项目有一个粗略的估计，每一次迭代都有详细的计划。业务人员，需求规划人员，开发人员紧密合作。问题发现早，修复成本低。

我们分别从计划、变更、管理透明度、交付、风险和团队合作方面 瀑布+迭代开发：

项目专注于遵循计划；团队对变更态度较保守、有严格流程控制；项目过程对业务部门不透明；专注于遵循计划、交付即结束；项目风险较高、软件越晚交付风险影响越大、缓释风险或问题修复成本高；仅对自己的工作负责、依赖文档沟通。

敏捷开发：

对整个项目做一次粗略的估计、每一次迭代都有详细的计划；允许并鼓励需求变更、用业务价值驱动；业务人员、需求规划和开发人员之间的合作关系紧密；专注于对交付软件的不断修正和打磨；风险发现早、问题修复成本低；注重团队融合、面对面沟通、团队共同为最终交付的软件负责。

1.3-敏捷的定义

敏捷开发Agile Development：一种以人为核心、迭代、循序渐进的开发方法。

1.4-敏捷宣言:

个体和互动胜流程和工具工作的软件胜过详尽的文档客户合作胜过合同谈判响应变化胜过遵循计划尽管右项有其价值，我们更重视左项的价值

1.5-敏捷包括了具体的方法：

极限编程（Extreme Programming XP）SCRUM动态系统开发（Dynamic Systems Development Method DSDM）看版管理（kanban）测试驱动开发（Test-Driven Development TDD）精益软件开发（Lean Software Development）Scrumban大规模（Scrum Large Scale Scrum LeSS）规模化敏捷框架（Scaled Agile Framework SAFe）自适应软件开发（Adaptive Software Develop ASD）水晶方法特征驱动开发（Feature Driven Development FDD）

1.6-敏捷宣言遵循的原则

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意；欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化；经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期；业务人员和开发人员必须相互合作，项目中的每一天都不例外；激发个体的斗志，以他们为核心搭建项目；提供所需的环境和支援，辅以信任，从而达成目标；不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈；可工作的软件是进度的首要度量标准；敏捷过程倡导可持续开发；责任人、开发人员和用户要能够共同维持其步调稳定延续；坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强；以简洁为本，它是极力减少不必要工作量的艺术；最好的架构、需求和设计出自自组织团队；团队定期地反思如何能提高成效，并依此调整自身的举止表现。

二、什么是SCRUM——一个打造产品的方法

来自橄榄球运动中的争球的动作：公开（OPENNESS）、勇敢（COURAGE）、尊重（RESPRECT）、专注（FOUCUS）、承诺（COMMITMENT），他是一个团队流程。

2.1-迭代

迭代是把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程，同时每一次迭代都可以开发出一个可以交付的软件产品。 Sprint迭代

2.3-用户故事

用户故事是以一种形式简洁的、面向验收展开的功能或特性的描述。敏捷开发将用户需求被拆分为故事，以此作为团队交流、开发、测试和获得反馈的工作单元。 通过用户故事团队的客户角色、实现功能和业务价值这三个去修要素达成共识。 其完成的定义（Definition of Done）：让所有干系人对交付的最终目标建立共识。

2.4-用户故事地图

用户故事地图是一门在需求拆分过程中保持全景图的技术，可以将你的待办事项清单（backlog）变成一张二维地图 使得大家对项目从共享文档变成对产品取得共识 好的用户故事应该遵循INVEST规则：

独立的（Independent）便于沟通的（Negotiable）有价值的（Valuable）可估计的（Estimable）短小（Small）可测试的（Testable）

2.5-Scrum软件开发流程

产品负责人（Product Owner）————>产品代办事项列表Product Backlog（特性、功能、需求、改进、修复；会随着产品需求和项目的改变而不断的丰富） 迭代计划会议Sprint Planning————>迭代代办事务列表Sprint Backlog

三、Scrum的三个角色

开发团队（Team）、产品负责人（Product Owner）、敏捷教练（Scrum Master）

3.1-产品负责人（Product Owner）：

对产品负责，确定产品愿景及产品规划和所有产品需求相关的事项；建立产品愿景，产品待办事项的唯一负责人；负责定义产品功能，管理产品待办事项列表并保证其对于业务部门和团队保持透明度；对产品待办事项进行优先级排序；接受/拒绝工作成果；对项目的成功负责并保证投资回报率；不可以由多人负责，不可由敏捷教练代替

3.2-敏捷教练（Scrum Master）：

对团队资源及团队管理负责，于产品负责人一同把控产品质量；保证团队可以遵守Scrum的价值、实践和规范；指导高效，高质量工作；保证团队不受外界因素的干扰；保证各个不同的角色之间的良好协作，消除障碍；帮助PO更好的利用团队的能力；保证团队实现价值的增量；不能代表团队做决定；不能同时担任产品负责人；可以由团队成员担任；与团队成员无上下级差异；

3.3-开发团队（Team）:

通过讨论用户故事，团队对细分需求的客户角色、实现功能和业务价值这三个需求要素达成共识。一般5-9人;决定一个迭代周期中完成的工作量；共同对迭代目标负责；管理跟进迭代任务；不断自我改进；不可等待分派任务；不可等待项目经理解决问题；不可依赖队友的决定；对团队资源及团队管理负责，与产品负责人一同把控产品质量。

四、Scrum的五个活动

所有事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是固定的，不能缩短或者延长。而其他事件则可以在该事件的目标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。 Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。

4.1-产品待办事项列表:

发生在下个迭代开始前，一般是对下个迭代需求的讨论、澄清、细化，以保团队成员对需求的理解一致，帮助团队在下个迭代更快地进入到开发工作中。

对需求进行梳理，排序、拆分、细化和澄清；进行需求的拆分，生成用户故事，使得优先级高的需求被团队成员理解；能够支撑后续敏捷开发活动的开展

4.2-迭代计划会议：

发生在迭代的开始，PO、ScrumMaster和开发人员一起规划这个迭代的内容，即这个迭代完成哪些故事，预测在一个合理的条件范围内承诺能完成的工作量。

迭代目标以及迭代待办事项；拆分每个迭代的需求，生成Sprint迭代待办事项列表；帮助团队对细化后的需求的理解达成一致。成熟的敏捷团队可以将产品待办列表梳理会和计划会议合在一起。

4.3-每日站立会议：

保证成员对现状、问题和风险有一致的了解；确保迭代目标得以实现；固定时间，固定地点，15分钟。全员参与（5-9人）；了解当前迭代周期内各项任务的进展，以确保任务都能按时完成，同时站会也能有效地提高团队成员工作的主观能动性。

团队成员主要回答以下三个问题： 1、昨天完成了什么帮助团队完成冲刺？ 2、今天打算做什么帮助团队完成冲刺？ 3、什么因素阻碍了团队的前进之路？

若有遇到障碍，在找到对应的解决/协助人后，应在会后讨论具体的解决方案，这是一个很好的控制站会时间的方法。

4.4-迭代评审会议：

迭代评审会议是在当前迭代结束前开发团队给用户（业务、产品负责人、利益相关者、管理人员等）展示成果的过程，团队展示的成果是符合事先约定好的“完成定义”的，展示的成果不一定是完整的产品，但需是一项可以使用的功能。

确认系统功能和用户期望是否一致；收集用户反馈，明确后续目标;检查和调整正在构建的产品是否为客户真正想要的（确保开发沿着正确的方向走）;经常受到反馈消息可以让Scrum团队更好的理解产品与业务需求。

这个会议和迭代回顾会都是“检查与调整”的活动。

4.5-迭代回顾会议：

这个会议出现在迭代演示会后，下一个迭代开始前。在进行迭代回顾会时，开发团队、PO、ScrumMaster一起来对当前迭代哪些实践是做得好的（Scrum、技术、工作环境/氛围等）、哪些实践是可以做得“更好的”，对于哪些可以做到更好的要制定好相应的解决方案，并指定相应的任务跟踪人。

使整个团队回顾整个迭代的过程和结果；总结经验，寻找最佳的工作方式，自我改进。

迭代演示会一样也是“检查与调整”的活动，两者的区别是，迭代演示会是检查调整产品，而迭代回顾会使检查调整过程。到这里大家应该明白了，Scrum是一个持续改进的过程。

五、Scrum的三个工件

Scrum 的工件以不同的方式展现工作和价值,可以用来提供透明性以及检验和适应的机会。Scrum 中所定义的工件能最大化关键信息的透明性,来保证 Scrum 团队成功地交付完成的增量。

5.1-产品待办事项列表（Product Backlog）

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源;产品负责人负责产品待办事项列表的内容、可用性和优先级;产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的和众所周知的需求;

5.2-迭代待办事项列表(Sprint Backlog)

Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行的工作。

Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会因为如下原因发生变化:

随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到Sprint Backlog中。

程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作。

5.3-产品增量(Product Increment)

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。

六、SCRUM的五个价值观

承诺 – 愿意对目标做出承诺；专注– 把你的心思和能力都用到你承诺的工作上去；开放– Scrum 把项目中的一切开放给每个人看；尊重– 每个人都有他独特的背景和经验；勇气– 有勇气做出承诺，履行承诺，接受别人的尊重。

七、怎样才能变得敏捷

用开放的心态看待变化 掌握相关的知识，技能，工具 在实践中学习 业务部门和科技更紧密的合作

业务人员和开发人员一起工作，从依赖书面沟通转变为面对面的交谈，沟通效率更高，信息更透明减少不必要的工作，尽量简洁。让团队更加专注于业务价值的交付以交付产品来衡量团队和项目进队，让团队更加专注于交付产品本身尽早、持续的交付软件，让业务需求尽早实现，尽快让业务部门看到功能欢迎对未开发的需求进行调整，紧跟快速变化的市场需求对技术的精益求精，不断学习新的技术和工具，对设计的不断完善将不断提升敏捷性建议团队定期回顾总结，如何做的更好，并相应地调整团队的工作方式，鼓励团队自我完善、激励团队成员，给予资源及充分的技术培训，相信他们能够完成任务，激发团队成员的工作热情和斗志，从局部的工作任务提交，向“端到端”交付结果负责。

参考文章：Scrum中文网