柯南君： 教你看敏捷开发のScrum是如何工作的？

柯南君
教你看敏捷开发のScrum是如何工作的？
现在敏捷开发是越来越火，人人都在谈敏捷，人人都在学习Scrum和XP,柯南君的朋友“远哥”是一位项目leader，柯南君与远哥促膝长谈，远哥也毫不避讳，知无不言言无不尽，把自己对Scrum的理解和自己工作中的经验积累与柯南君分享，在这里柯南君代替远哥与大家分享一些经验。

一、 [b]什么是敏捷开发？[/b]
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人，它采用的是迭代式开发；

二、[b]为什么说是以人为核心？[/b]
我们大部分人都学过瀑布开发模型（见备注），它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

备注：

① 在这里儿，给大家普及一下基础知识的，什么是软件开发模型？对于开发模型知识点，要掌握软件生命周期的概念、各种开发模型的特点和应用场合。主要是的开发模型有瀑布模型、增量模型、螺旋模型、喷泉模型、V模型、快速应用开发模型、构件组装模型、敏捷方法和统一过程等。

[b] 三、什么是迭代？[/b]

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

四、 关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。

1、什么是Scrum？





Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作

2、 IT方法的采用率对比

软件开发中有很多过程方法可以使用，下图为Forrest Research 2009年调查的方法采用率对比，其中可以看到Scrum方法明显占有优势。本篇我将从IT方法论的角度来谈Scrum。





3、Scrum与CMMI

暂无

4、Scrum的特点

① 是一个敏捷开发流程

② 以团队为基础

③ 要求迅速变化情况下迭代和增量开发

④ 改善交流并最优化合作

⑤ 检测开发过程障碍并将其去除

⑥ 最大化生产率

⑦ 适用于单一的项目到整个组织

⑧ 能让参与者对工作贡献赶到满意

5、Scrum中的角色









1）Scrum Master——项目负责人、项目经理

① 保护团队不受外界干扰，是团队的领导和推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。

② 与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

2) Team——开发人员、测试人员、美工设计、DBA等全职能性团队

① 团队负责交付产品并对其质量负责，团队与所有提出产品需求的人一起工作，包括客户和最终用户，并共同创建 Product Backlog 。

② 团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

③ 自组织地完成项目开发，使用一切可行手段保证进度和质量

3) Product Owner——产品负责人、产品经理、运营人员

① 从业务角度驱动项目，传播产品的明确愿景，并定义其主要特性。

② Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目，在 Sprint 中帮助团队完成自己的工作，不干扰团队成员，并迅速提供团队需要的所有信息。

4） User——最终用户、运营人员、系统使用人员

① 很多人都可能成为最终用户，比如市场部人员、真正的最终用户、最好的领域专家，也可能是因其专业知识而被雇佣的资讯顾问。

② 终用户会根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。

5） Manager——管理层、投资人

① 管理层要为 Scrum 团队搭建良好的环境，以确保团队能够出色工作，必要的时候，他们也会与 Scrum Master 一起重新组织结构和指导原则。

6） Customer—— 户、系统使用人员、运营人员

① 客户是为 Scrum 团队提出产品需求的人，她会与组织签订合同，以开发产品。

② 一般来说，这些人是组织中的高级管理人员，负责从外部软件开发公司购买软件开发能力。

③ 在为内部产品的公司中，负责批准项目预算的人就是客户。

6、Scrum流程





备注：

① Scrum的核心在于迭代，整个过程只有三个角色。产品负责人的职责是利用产品backlog，督促团队优先开发具有价值的功能，并在其基础上继续 开发。产品负责人必须频繁检视产品代开发需求的优先级，以便将最具价值的功能安排在下一个迭代中完成。团队的责任是开发软件功能，他们是自组织团队，团队所有成员对每一次迭代和整个项目共同负责，不单做考核。Scrum Master则需要对Scrum过程负责，向所有项目参与者讲授Scrum方法，负责实施Scrum，确保它既符合企业文化，又能交付预期利益，还需督促 全体成员遵从Scrum规则和实践。

　　② 启动Scrum项目所需的最简约计划包括：一份愿景及产品Backlog。愿景描述项目开发原因和预期目标。愿景可能描述商业运作方式将发生哪些改变，主 要特性和功能如何为客户创造收益，以及对市场的预期影响。产品backlog将定义交付愿景时，系统应满足的功能性和非功能性需求，它需事先划分优先级并经过初始预估（预估的目的是了解每个需求自身及相对与其他需求的规模）。

　　③ 在Sprint第一天召开sprint计划会议，这个会议分为两部分，计划会议1由PO、SM和Team参加，主要是从产品backlog中挑选出需要放 到当前sprint下的既定产品backlog，然后由SM、Team参加计划会议2，把既定产品backlog的故事拆分成任务进行估算，PO也可以一 起参加这个部分来了解具体的开发细节。sprint周期在spirnt计划会议2正式开始。开发过程中，团队每天召开每日站会（Daily Scrum），沟通团队成员间工作进度和进行任务协调。Sprint周期结束时，需要召开Sprint评审会议，由团队向产品负责人和其他利益相关者展示当前sprint周期内的产品开发情况。产品负责人根据团队这次
Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。评审会议结束后会进行回顾会议，通过总结以往的实践经验来提高团队生产力。





7、Scrum 中的产出物

1） Product Backlog——Backlog 待开发项，积压的任务。



① 产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。

② Product Backlog不是制定一次就完了的，它是动态的，需要持续的被修订，可能会出现故事的增加、删除和修改、合并或者拆分任何一个Backlog的目标都是：它应该足够短、级别足够高，无特殊情况不需要修改。如果Backlog改变了，那么我认为你应该假设你的 Backlog错了，而不是需求变更了。变更需求通常意味着Backlog太长或者太详细，比如把复杂算法和逻辑也写入了backlog中了，要不就是写 的太含糊不清了，需要花费太多的时间猜测它究竟讲的是什么。

③ prodcut Backlog有什么用？

产品backlog根据用户价值罗列所有即将在产品中开发的功能，通过简洁的展示需要实现的功能，我们可以对项目进行规模上的估算，确定发布计划和迭代计划。产品backlog可以帮助我们对将要做的事情有个整体的认识，以及可以知道我们现在的状态。如果没有backlog，我们将不知道现在和将来产品做成什么样子，由于对产品目标的不明确，当然也不知道什么时候可以发布产品，或者发布的产品能给客户带来什么价值。

④ 谁提供product backlog的需求？

产品负责人与客户最近，他最清楚产品应该做什么样子，所以product backlog应该由Product Owner来制定。里面的需求由产品负责人或者客户制定，有时候Team里的需求分析人员可以和产品负责人或客户一起定义需求。制定后，由Scrum master和Team协助产品负责人修订并进行初始评估，里面的需求在sprint计划会议将进行更进一步的讨论。

⑤ 什么时候会修改product backlog？

如果一个列表太长或者内容陈旧，product backlog的浪费远大于价值本身，所以我们必须不断的维护产品backlog。产品backlog由产品负责人提供，与Team进行规模估算时，可能会拆分合并或者添加删除故事，初始估计也由Team进行评估提供估计值。产品所有者通常会向开发小组提出自己确定的优先级顺序，而小组也可能会请产品所有者根据他们对主题的评估对这个顺序作出少量调整。

怎么写故事?

一般按照轻量级的故事来进行描述需求。用户故事是最基本的设计单元，它是从系统用户或者客户的角度出发对功能的一段简要描述。用户故事的形式很自由，没有什么强制性的语法。但是，按照大致符合这样一个形式来考虑 用户故事是比较有益的：“作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到...的结果】以便【业务价值】。”以这样的模作为例子，可以得到一个用户故事说：“作为购书者，我希望可以根据ISBN来找到一本书，以便能更快的找到正确的书。”在做用户故事时，需要注意每个用户故事用的是用户的语言，它只描述一个功能（feature），而且每个用户故事的开发周期不要太长（1－5天）我们不需要一开始对所有的故事都进行详细的描述，但计划放在下一个sprint中的故事应该比较清楚。

⑥ 一般按照轻量级的故事来进行描述需求。

用户故事是最基本的设计单元，它是从系统用户或者客户的角度出发对功能的一段简要描述。用户故事的形式很自由，没有什么强制性的语法。但是，按照大致符合这样一个形式来考虑 用户故事是比较有益的：“作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到...的结果】以便【业务价值】。”以这样的模作为例子，可以得到一个用户故事说：“作为购书者，我希望可以根据ISBN来找到一本书，以便能更快的找到正确的书。”在做用户故事时，需要注意每个用户故事用的是用户的语言，它只描述一个功能（feature），而且每个用户故事的开发周期不要太长（1－5天）

====================================================================================================================================







备注：

拆分故事：注意在这里不要把故事拆分到任务，故事是可以交
付的东西，是产品负责人所关心的，而任务是不可交付的东西。

优先级：经济价值、开发成本、依赖关系、新知识、风险。

⑦ ID为一个唯一标识，确定后最好固定不变，在其他工作或者文档中想引用故事就使用这个ID来引用 Name2到10个字，通过简单的描述来说明故事，如果要很多字才能表达这个故事，那很有可能这个故事太大，或者不清楚 重要性 这个优先级决定了sprint选择的故事，优先级越高的越早实现 初始估算 这个由Team来根据故事描述内容来估算，产品负责人讲解完故事后，Team对不清楚的进行询问，大概了解后进行粗略估算。从估算的角度出发，故事不应该太短，但也不能太过于详细，不需要把具体的规则和算法写进去。
How do demo 从用户视角，从操作层面进行讲解这个故事如何通过软件来演示，也可以作为一个简单的测试用例了。重要性高的backlog条目都要填写”如何演示“。 Notes相关信息、解释说明和对其他资料的引用等，一般都非常简短。

⑧ 怎么拆分故事？

故事非常大时，我们将很难对它进行估计。如果故事预计在N次迭代后才进行，那么大的故事很正常。但如果估计预计在接下来的迭代中进行，那么我们就 可能会对大的故事进行拆分。很大的故事基本上都能进行拆分，只要确定每个小故事莹然可以交付业务价值就行。注意在这里不要把故事拆分到任务，故事是可以交 付的东西，是产品负责人所关心的，而任务是不可交付的东西，产品负责人对它并不关心，任务是在sprint计划会议上拆分的。

分割用户故事：1 按照用户故事所支持数据的边界来分割大型用户故事（例如导入GBQ文件、Excel等）
2 有些时候，可以从主用户故事中除去对例外或错误条件的处理（相当于用户的基本路径和扩展路径），从而把一个大型用户故事变小许多
3 按照操作边界分割，把大型用户故事分割成独立的建立、读取、更新和删除操作（例如预算二次导入，或者新增时需要向导、规则而比较复杂时也可以单独成一个故事来描述）
4 考虑去除横切考虑（例如安全处理、日志记录、错误处理等），为用户故事建立两个版本：一个具备对横切考虑的支持，另一个不具备这种支持
5 考虑功能性需求和非功能性需求隔离到不同的用户故事，从而分割大型用户故事（性能）在拆分故事时，我们有时也需要考虑组合故事的场景，如   把bug列入产品backlog时，可以把多个类似的bug组合成一个故事。
⑨怎么评定优先级

最简单的方法就是问问客户最希望在下一个迭代中最想看到的是哪一些功能。从考虑的因素来看，我们可以从以下4个因素来考虑：
A  获取这些功能带来的经济价值，价值越高的优先级越高。
B  开发成本带来的影响。例如可能2个月后由于使用新技术只需要2周，而现在做需要2个月，这时可以考虑把优先级放低一些获取新知识的重要性。
C  在开发中会不断的产生一些项目和产品的新知识，及早了解和开发这些新知识可以减少不确定性，所以这类功能优先级会高些故事之间会存在依赖关系，这时候被依赖的优先级会更高，需要先完成开发这些功能所减少的风险。
D 在开发过程中，会出现进度风险、成本风险、技术风险等，对于风险越高价值越大的我们需要首先处理，对风险高价值低的要尽量避免，可以通过以下图查看确定功能优先级时综合考虑风险和价值的关系

2）Sprint Backlog——Sprint 本意为“冲刺”，指迭代周期，长度通常是一至六周。

在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产生本次 Sprint 要完成的 “已定 Product Backlog”。

已定 Product Backlog Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。





目标：定出 Sprint 目标，确定所有任务。

备注：

① sprint计划会议1
产品负责人和团队一起，在先前评估的成果基础上，定出 Sprint 目标和既定产品Backlog。
【目标】
　　           定出 Sprint 目标和既定产品 Backlog
【会议准备】
邀请与会者：产品负责人、Scrum Master、团队所有成员
已按优先级排列产品 Backlog 中各项问题
已评估 Backlog 中的各项问题
把产品 Backlog 公开给会议中的每个人，保证其可被获取
预期团队中有哪些人已明确会缺席（如度假）
保证房间环境适合小组讨论
每个人都可以获取上次 Sprint 评审会议和 Sprint 回顾会议的结果
Sprint 时间表已经安排
Sprint 计划会议 1 的时间安排
Sprint 计划会议 2 的时间安排
Sprint 的第一天已确定
Sprint 的最后一天已确定
Scrum 每日例会的时间安排
Sprint 评审会议的时间安排
Sprint 回顾会议的时间安排
（可选）为既定 Backlog 准备图钉板:一个至少 2x2 米的图钉板、卡片和贴纸、荧光笔
（可选）用作计划纸牌的卡片
会议进程（4 小时）
把 Sprint 时间表公开给所有人
把 Sprint 评审会议的结果公开给所有人
把 Sprint 回顾会议的结果公开给所有人
产品负责人向团队产品阐述产品远景
产品负责人和团队一起确定 Sprint 目标
如果 Backlog 里有问题遗漏：产品负责人有权限往 Backlog 里添加问题
如果产品 Backlog 完全未被评估：选择 Backlog 中您认为是最小用例的问题，并指派其工作量为 2 个Story Point。以这个最小用例的工作量标准，分配 Backlog 中其他问题的 Story Point
如果 Backlog 中的一些问题尚未被评估：根据其他问题工作量，评估这些问题的 Story Point 量
如果产品 Backlog 中的各项还没能合理地按优先级排序:产品负责人对产品 Backlog 中的各项按优先级排序
产品负责人和小组成员相互认可这 Sprint 目标和既定产品 Backlog
　        【会议结果】
　　       为 Sprint 计划会议2的进行准备好既定产品 Backlog
　　       sprint计划会议2
在 Sprint 计划会议 2 中，团队将既定产品 Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。
【目标】
　　       确定所有任务，生成 Sprint Backlog，确认 Sprint 目标

3） User Story、Task——用户故事、任务

用 User Story 来描述 Sprint Backlog 里的项目，User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大，可能会导致对它的开发横跨几个 Sprint，此时就应该将这个 User Story 分解。

为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task 的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。

障碍 Backlog——问题列表，积压的待处理事务。

列举了所有团队内部和团队相关的和阻碍项目的进度的问题，Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

注意： 通用会议规则

基本要求

每次会议都要准时开始、准时结束。
每次会议都采取开放形式，所有人都可以参加。

会前准备

提前邀请所有必须参会的人，让他们有时间准备。
发送带有会议目标和意图的会议纲要。
预订会议所需的全部资源：房间、投影仪、挂图、主持设备，以及此会议需要的其他东西。
会前24小时发送提醒。
准备带有会议规则的挂图。

会议推进

展开讨论时，会议的推进人必须在场。他不能参与到具体讨论中，但是他需要注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正规。
推进人展示会议的目标和意图。
有必要时，推进人可以商定由某个撰写会议记录。
推进人可以记录团队的意见，或是教授团队如何自己记录文档；而且推进人可能会在挂图上进行记录，将对话可视化。
推进人会对会议进行收尾，并进行非常简短的回顾。

会议输出

使用手写或挂图说明来记录文档，给白板和挂图上的内容拍照。
必须传达会议记录和大家对会议结果的明确共同认知。

让团队坐在一起！

大家都懒的动，尽量让“产品负责人”和“全功能团队”都坐在一起！
互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。
隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到，反之亦然。

团队建设

Scrum 团队最佳人数控制在“5～9”人。
全职能性团队：开发组（后台开发、前端开发、测试人员——3~8人）、Scrum Master（项目经理）、产品负责人
兼职团队成员：美工、DBA、运维

每日立会（Daily Standup Meeting）——建议下班前开始

会议目的

团队在会议中作计划，协调其每日活动，还可以报告和讨论遇到的障碍。
任务板能够帮助团队聚焦于每日活动之上，要在这个时候更新任务板和燃尽图。

构成部分

任务板、即时贴、马克笔
提示：ScrumMaster 不要站在团队前面或是任务板旁边，不要营造类似于师生教学的气氛。

基本要求

成员：团队、Scrum Master
无法出席的团队成员要由同伴代表。
持续时间/举办地点：每天15分钟，同样时间，同样地点。
提示：团队成员在聆听他人发言时，都应该想这个问题：“我该怎么帮他做得更快？”

会议输出

团队彼此明确知道各自的工作，最新的工作进度图。
得到最新的“障碍 Backlog”
得到最新的“Sprint Backlog”

会议过程

团队聚在故事板旁边，可以围成环形。
从左边第一个开始，向团队伙伴说明他到现在完成的工作。
然后该成员将任务板上的任务放到正确的列中。
如果可以的话，该成员可以选取新的任务，交将其放入“进行中工作”列。
如果该成员遇到问题或障碍，就要将其报告给 Scrum Master。
每个团队成员重复步骤2到步骤5。

每个人三个问题：

上次会议时的任务哪些已经完成？：把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么？
下次会议之前，你计划完成什么任务？：如果任务状态为“待处理”，转为“正在处理”状态。如果任务不在 Sprint Backlog 上，则添加这个任务。如果任务不能在一天成，把这任务细分成多个任务。如果任务可以在一天内完成，把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”，询问是否存在阻碍任务完成得问题。——明天做什么？
有什么问题阻碍了你的开发？：如果有阻碍你的开发进度的问题，把该障碍加入到障碍 Backlog中。——今天遇到了什么问题？

注意事项

不要迟到
不要超出限制时间
不要讨论技术问题
不要转变会议话题
不要在没有准备的情况下参加
Scrum Master 不要替团队成员移动任务卡片，不要替团队更新燃尽图。
Scrum Master 不要提出问题，团队成员不要向 Scrum Master 或管理层人员报告。
如果不能出席会议，需要通知团队，并找一名代表参加。

任务板

任务板集合了选择好的 Product Backlog 和 Sprint Backlog，并以可视化方式展示。
任务板只能由团队维护，使用不同颜色的“即时贴”来区分开发人员，或者在“即时贴”写上接受任务的姓名。
尽量使用大白板，也可以使用软件。

任务板有4列：

选择好的 Product Backlog：按照优先级，将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。
待完成的任务：要完成一个故事，你得完成一些任务。在 Sprint 规划会议中，或是在进行当前 Sprint 中，收集所有特定 Backlog 条目需要完成的新任务，并将它们放入该列。
进行中的工作：当团队成员开始某个任务后，他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始，没有完成的任务都会放在该列中，并在上面做标记（通常是个红点）。如果某个任务在“待完成任务”列中所处时间超过一天，就尽量将该任务分为更小 的部分，然后把新任务放到那一列，移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成，就会得到一个红点标记，Scrum Master 就会记下一个障碍。
完成：当一个任务卡完成后，完成此任务的成员将其放入“完成”列，并开始选取下一张任务卡。


=


燃尽图（Burn Down Chart）

跟踪进度要由团队来完成，燃尽图的横轴表示整个Sprint 的总时间，纵轴表示 Sprint 中所有的任务，其单位可以是小时，人天等。一般来说，燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
团队每天更新燃尽图。
如果燃尽图一直是上升状态，或当 Sprint 进行一段时间之后，Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几，就说明这个 Sprint 中的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快，例如 Sprint 刚过半时Y值已经接近0了，则说明这个 Sprint 分配的任务太少，还要多加一些任务进来。在
Sprint 计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。（锻炼团队人员的自我估算时间）
燃尽图要便于团队更新，没必要让它看起来很炫，也不要过于复杂，难以维护。

Release 燃尽图：记录整个Scurm项目的进度，它的横轴表示这个项目的所有Sprint， 纵轴表示各个Sprint开始前，尚未完成的工作，它的单位可以是个（Story 的数量），人天等。



Sprint 规划会议——第一部分（上午）

会议目的

该会议的工作以分析为主，目的是要详细理解最终用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束，团队将会决定他们能够交付哪些东西。
产品负责人在会前准备：条目化的需求（用户故事），优先级排序，最近1~2个迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。

基本要求

迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

构成部分：

经过估算和排序的 Product Backlog。
挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
假期计划表、重要人员的详细联系信息。
参会成员：团队成员、Scrum Master、产品负责人

持续时间：在 Sprint 中，每周该会议占用时间为 60 分钟，在早上召开该会议，这样还有可能在同一天召开 Sprint 规划会议的第二部分。

会议输出

选择好的 Product Backlog 条目。
各个 Backlog 条目的需求。
各个 Backlog 条目的用户验收测试。

会议过程

从第一个 Product Backlog 条目（故事）开始。
讨论该 Product Backlog 条目，以深入理解。
分析、明确用户验收测试。
找到非功能性需求（性能、稳定性...）
找到验收条件。
弄清楚需要“完成”到何种水平。
获得 Backlog 条目各个方面的清晰了解。
绘制出所需交付物的相关图表，包括流程图、UML图、手绘草图、屏幕 UI 设计等。
回到步骤1，选取下一个 Backlog 条目。

流程检查：询问团队能否快速回答下列问题，只需要简要回答即可：“我们能 在这个 Sprint 中完成第一个 Backlog 条目吗？”如果能得到肯定的回答，那么继续询问下一个 Backlog 条目，一直到已经分析完的最后一个 Backlog 条目。——接下来，休息一下。在休息后，对下一个 Backlog 条目展开上述流程。

结束流程：

在 Sprint 规划会议第一部分结束前留出 20 分钟。
再次提问——这次要更加严肃、正式：“你们能否完成第一个 Backlog 条目，...第二个，...？”
如果团队认为他们不能再接受更多的 Backlog 条目，那就停下来。
现在是非常重要的一步：送走 Product Owner，除了团队和 Scrum Master 之外的所有人，都得离开。
当其他人都离开后，再询问团队：“说真的——你们相信自己可以完成这个列表？”
希望团队现在能短暂讨论一下，看看他们到底认为自己能完成多少工作。
将结果与 Product Owner 和最终用户沟通。

注意事项：不要改变 Backlog 条目大小，不要估算任务。

Sprint 规划会议——第二部分（下午）

会议目的

该会议的工作以设计为主，产品开发团队可以为他们要实现的解决方案完成设计工作，在会议结束后，团队知道如何构建他们在当前 Sprint 中要开发的功能。

基本要求

只有产品开发团队才能制定解决方案，架构师或其他团队之外的人只是受邀帮助团队。

构成部分：

能够帮助团队在该 Sprint 中构建解决方案的人，比如厂商或是来自其他团队的人员。
选择好的 Product Backlog 条目。
挂图......

注意事项：不要估算任务，不要分配任务。

会议输出

应用设计、架构设计图、相关图表
确保团队知道应该如何完成任务！

会议过程

从第一个 Backlog 条目开始。
查看挂图，确定对于客户的需求理解正确。
围绕该 Backlog 条目进行设计，并基于下列类似问题：

我们需要编写什么样的接口？
我们需要创建什么样的架构？
我们需要更新哪些表？
我们需要更新或是编写哪些组件？
......

当团队明确知道自己应该如何开发该功能后，就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟，团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展，将这些任务放在任务板上。

持续时间：在 Sprint 规划会议第一部分完成后，召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分，在 Sprint 中，每周该会议占用时间为 60 分钟。

估算会议——根据项目情况合并到 Sprint 第二部分会议

会议目的

要做好战略规划，你需要知道 Backlog 中各项的大小，这是版本规划的必要输入；如果想知道团队在一个 Sprint 中能够完成多少工作，这个数据也是必须的。
团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

基本要求

只有团队才能作估算，Product Owner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事。

构成部分：

Product Owner 根据业务价值排定 Product Backlog 各项顺序。
需要参加的人员：Team、Product Owner、User、Scrum Master

注意事项：

不要估算工作量大小——只有团队能这么做。
Product Owner 不参与估算。

会议过程

Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
团队使用规划扑克来估算 Backlog 条目。
如果某个 Backlog 条目过大，需要放到下一个或是后续的 Sprint 中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目，并对新的 Backlog 条目使用规划扑克进行估算。
重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

持续时间：该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周，那么每个 Sprint 举行两次估算会议比较合适。

会议输出

经过估算的 Product Backlog。
更小的 Backlog 条目。

扑克牌估算（Planning Poker）

具体步骤：

每个人各自估算后独立出暗牌，听口令一起开牌。
数值最大者与最小者PK，其他人旁听也可参考。
讨论结束后重新出牌和开牌。
重复上述过程，直到结果比较接近。

常见问题

1、为什么任务要分给组而不是个人？

答：因为怕出错了牌又说不出所以然，这样即使日后他不做这个功能，也对这个功能很了解。

2、为什么不让最后领任务的人自己估算？

答：因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

3、为什么不让师傅估算大家采纳，他不是最厉害吗？

答：师傅的想法常常是徒弟们理解不了的，比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

Sprint 评审会议（Review Meeting）——根据项目需要举行

会议目的

Scrum 团队在会议中向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。

基本要求

Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。

构成部分

有可能发布的产品增量，由团队展示。

会议输出

来自最终用户的反馈。
障碍 Backlog 的输入。
团队 Backlog 的输入。
来自团队的反馈为 Product Backlog 产生输入。

持续时间：90分钟，在 Sprint 结束时进行。

会议过程

Product Owner 欢迎大家来参加 Sprint 复审会议。
Product Owner 提醒大家关于本次 Sprint 的目的：Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
产品开发团队展示新功能，并让最终用户尝试新功能。
Scrum Master 推进会议进程。
最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

注意事项：

不要展示不可能发布的产品增量。
Scrum Master 不要负责展示结果。
团队不要针对 Product Owner 展示。
Sprint 反思会议（Retrospective Meetin）——根据项目需要举行

会议目的

该会议的对应隐喻：医疗诊断！其目的不是为了找到治愈方案，而是要发现哪些方面需要改进。

构成部分

参与人员：团队成员、Scrum Master

基本要求

从过去中学习，指导将来。
改进团队的生产力。

注意事项

不要让管理层人员参与会议。
不要在团队之外讨论找到的东西。

会议输出

障碍 Backlog 的输入。
团队 Backlog 的输入。

持续时间：90分钟，在 Sprint 评审会议结束后几分钟开始。

会议过程

准备一个写着“过去哪些做的不错？”的挂图。
准备一个写着“哪些应该改进？”的挂图。
绘制一条带有开始和结束日期的时间线。
给每个团队成员发放一叠即时贴。
开始回顾。
做一个安全练习。
收集事实：发放即时贴，用之构成一条时间线。每个团队成员（包括 Scrum Master）在每张即时贴上写上一个重要的事件。
“过去哪些做的不错？”：采取收集事实同样的过程，不过这次要把即时贴放在准备好的挂图上。
做一个分隔，以区分“过去哪些做的不错”和接下来要产出的东西。
“哪些应该改进？”：像“过去哪些做的不错”那样进行。
现在将即时贴分组：
我们能做什么》团队 Backlog 的输入。
哪些不在我们掌控之内？》障碍 Backlog 的输入。
根据团队成员的意见对两个列表排序。
将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入，并决定到时候要如何处理这些发现的信息。





8、最后说一下 Scrum的核心价值观

在 Agile
Software Development with Scrum 一书中指出，Scrum 的核心价值观是：承诺、专注、公开、敬重和勇气，它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则，这些价值观对个人管理依然非常有效。
1) 承诺（Commitment）：我们是否经常暗下决心，要做好某件些，比如要戒掉游戏、学习英语，一定要完成这个任务，但是最后结果却大打折扣。如果你有这种现象，那么你需要做的就是自己对自己承诺，自己相信自己，如果自己都不能相信自己，那么谁又能相信你呢？
2) 专注（Focus） ：要事第一，对一件事情投入100％去做好。
3) 公开（Openness）： 有人说，能力就像怀孕一样，时间久了才能看出来，你个人的学习、个人的Open都需要公开的表达才能让别人知道。比如刚组建的团队，个人要公开地表达自己的能力和特长，在团队交流或讨论问题时才能找正确的人解决问题。

4) 敬重（Respect）：三人行必有我师，空杯心态，尊重每一个人，向不同的学习。
5) 勇气（Courage）：为了接受并负责任的交付产品，团队成员必须有足够的勇气来对大家说“不”，比如不能承诺时，对纳入sprint的故事说“不”等，做这些决定其实是需要很大的勇气的，因为前面并不一定是平坦之路，但对自己要绝对自信。