Scrum In Practice－201003

Andy Yuan （袁斌） Scrum 实践者，MBA 博客 http://blog.vsharing.com/agiledo MSN: [email protected] 邮箱： [email protected] 手机：13501397696 更多信息，请登录 http://www.agiledo.cn （迅思威尔）

我们的 Scrum 实践更加符合我们项目的场景，包括客户、公司、团队的实际情况。仅供参考第 1 页共 81 页

我们这样实践 Scrum

Andy Yuan

袁斌（Scrum 实践者、MBA）

2010 年 3 月（版本 1.0）


文档的内容：（蓝色内容为这个版本新增的内容）

内容状态内容状态内容状态团队建设经验总结典型问题评估会议 Product Backlog 32 人的 Scrum 团队

Sprint 计划会议 1 过程监控 Sprint 计划会议 2 部署

每日例会 SM 的角色 Sprint 评审会议 PO 的角色 Sprint 回顾会议沟通

质量保证教训总结图例：

：初稿完成；：终稿完成；：未开始；：进行中

Scrum 实践的内容包括：我们团队如何实践 Scrum 过程、经验教训（重点）；Scrum 实践的典型问题（重点，包括我们实践中遇到的以及网络中被大家重视的）；

一些 Scrum 推荐的理论（非重点，我只是摘录了一些书籍中的文字，例如《Scrum - Checklists》，不系统也较肤浅，最初目的只是为了让自己有一个比较而已。

关于 Scrum 的理论，我自己做了两个 PPT：Scrum、Beyond Scrum，在团队内部沟通是这两个 PPT 来进行的） Scrum 实践过程中参考了其它敏捷的开发方法：Agile Modeling & XP Scrum 实践过程中参考了很多同行的实践做法以及理论文章，在此深表感谢。如果由于我的疏忽在文中没有标注所有参考文档的原作者出处，请见谅！特别感谢：Mike Cohn：《agile estimating and planning》；Boris Gloger：《Scrum - Checklists》；Esther、Diana《agile retrospectives》；Robert C. Martin《敏捷

软件开发：原则、模式与实践》、InfoQ 网站 Scrum 实践还在不断总结中。已经了解，正在融入实践的部分：KanBan、Lean。在后续的版本中会共享我们这方面的实践。



实践 Scrum 的思路：参考了 Henrik Kniberg 推荐的 Scrum 开发模式




目录我们如何开始－理解敏捷宣言 ........................................................................................................................................................................................................................7

个体和交互胜过过程和工具 ....................................................................................................................................................................................................................7 可以工作的软件胜过面面俱到的文档.....................................................................................................................................................................................................8 客户合作胜过合同谈判 ............................................................................................................................................................................................................................8 响应变化胜过遵循计划 ............................................................................................................................................................................................................................9

团队建设 ..........................................................................................................................................................................................................................................................11 推荐理论 ..................................................................................................................................................................................................................................................11 我们的实践 ..............................................................................................................................................................................................................................................12

SM 的角色 .......................................................................................................................................................................................................................................................14 推荐理论 ..................................................................................................................................................................................................................................................14 我们的实践 ..............................................................................................................................................................................................................................................14

PO 的角色 ........................................................................................................................................................................................................................................................16 推荐理论 ..................................................................................................................................................................................................................................................16 我们的实践 ..............................................................................................................................................................................................................................................16

Product Backlog ...............................................................................................................................................................................................................................................17 推荐理论 ..................................................................................................................................................................................................................................................17 我们的实践 ..............................................................................................................................................................................................................................................18

评估会议 ..........................................................................................................................................................................................................................................................20 推荐理论 ..................................................................................................................................................................................................................................................20 我们的实践 ..............................................................................................................................................................................................................................................20

Sprint 计划会议 1 ............................................................................................................................................................................................................................................22 推荐理论 ..................................................................................................................................................................................................................................................22 我们的实践 ..............................................................................................................................................................................................................................................22

Sprint 计划会议 2 ............................................................................................................................................................................................................................................25 推荐理论 ..................................................................................................................................................................................................................................................25 我们的实践 ..............................................................................................................................................................................................................................................26



每日例会 ..........................................................................................................................................................................................................................................................29 推荐理论 ..................................................................................................................................................................................................................................................29 我们的实践 ..............................................................................................................................................................................................................................................29

过程监控 ..........................................................................................................................................................................................................................................................31 推荐理论 ..................................................................................................................................................................................................................................................31 我们的实践 ..............................................................................................................................................................................................................................................31

Sprint 评审会议 ...............................................................................................................................................................................................................................................34 推荐理论 ..................................................................................................................................................................................................................................................34 我们的实践 ..............................................................................................................................................................................................................................................34

回顾会议 ..........................................................................................................................................................................................................................................................36 推荐理论 ..................................................................................................................................................................................................................................................36 我们的实践 ..............................................................................................................................................................................................................................................36

如何部署 ..........................................................................................................................................................................................................................................................39 如何有效沟通 ..................................................................................................................................................................................................................................................40 保证质量 ..........................................................................................................................................................................................................................................................42 32 人的 Scrum 团队 .........................................................................................................................................................................................................................................44 经验总结 ..........................................................................................................................................................................................................................................................46 教训总结 ..........................................................................................................................................................................................................................................................50 典型问题（一） ..............................................................................................................................................................................................................................................53 典型问题（二） ..............................................................................................................................................................................................................................................57

什么样的领导适合敏捷项目？ ..............................................................................................................................................................................................................57 大型企业 Scrum 进行敏捷改进时障碍是什么？ ..................................................................................................................................................................................58 用户故事和用例的选择 ..........................................................................................................................................................................................................................59 实施敏捷，公司文化要如何改变？ ......................................................................................................................................................................................................61 什么是企业采用敏捷开发最主要的原因...............................................................................................................................................................................................62 采用敏捷开发，企业最担心的是什么...................................................................................................................................................................................................62 采用敏捷开发，企业最大的障碍是什么...............................................................................................................................................................................................62



图例

图表 1 典型的敏捷团队的QA职责需求.................................................................................................................................................................................................63 图表 2 价值－风险：优先级的判断依据...............................................................................................................................................................................................64 图表 3 我们如何管理需求的变化 ..........................................................................................................................................................................................................65 图表 4 我们这样做用户故事 ..................................................................................................................................................................................................................66 图表 5 增加一个新的需求何时可以发布...............................................................................................................................................................................................67 图表 6 我们的白板－改进前 ..................................................................................................................................................................................................................68 图表 7 我们的白板 ..................................................................................................................................................................................................................................69 图表 8 我们这样解决障碍 ......................................................................................................................................................................................................................70 图表 9 项目风险迹象－实际的工作量和评估的工作量不符...............................................................................................................................................................71 图表 10 项目风险迹象－功能不能全部完成.........................................................................................................................................................................................72 图表 11 项目风险迹象－高优先级未完成.............................................................................................................................................................................................73 图表 12 我们这样做Demo.......................................................................................................................................................................................................................74 图表 13 更早的发现编码风险 ................................................................................................................................................................................................................75 图表 14 多团队Scrum－改变前 ..............................................................................................................................................................................................................76 图表 15 多团队Scrum－改变后 ..............................................................................................................................................................................................................77 图表 16 我们这样部署 ............................................................................................................................................................................................................................78 图表 17 变更－燃尽柱 ............................................................................................................................................................................................................................79 图表 18 企业采用敏捷开发最主要的原因.............................................................................................................................................................................................80 图表 19 采用敏捷开发，企业最担心的是什么.....................................................................................................................................................................................81



我们如何开始－理解敏捷宣言此处文字摘自 Robert C. Martin《敏捷软件开发：原则、模式与实践》，在实践过程中个人认为这些文字在敏捷开发的初期团队培训中消除了很多常见的团队对敏捷的误

解，例如敏捷开发可以不要文档、开发过程没有计划等等，。这也是我向团队普及敏捷知识时最先介绍的材料。红色文字部分是我介绍的重点，在这里和大家共享我们

团队是如何开始的。

个体和交互胜过过程和工具

人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效

用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。

一个优秀的团队成员未必就是一个一流的程序员。一个优秀的团队成员可能是一个平均水平的程序员，但是却能够很好地和他人合作。合作、沟通以及交互能力要比单

纯的编程能力更为重要。一个由平均水平程序员组成的团队，如果具有良好的沟通能力，将要比那些虽然拥有一批高水平程序员，但是成员之间却不能进行交流的团队

更有可能获得成功。

合适的工具对于成功来说是非常重要的。像编译器、IDE、源代码控制系统等，对于团队的开发者正确地完成他们的工作是至关重要的。然而，工具的作用可能会被过

分地夸大。使用过多的庞大、笨重的工具就像缺少工具一样，都是不好的。

我们的建议是从使用小工具开始，尝试一个工具，直到发现它无法适用时才去更换它。不是急着去购买那些先进的、价格昂贵的源代码控制系统，相反先使用一个免费

的系统直到能够证明该系统已经不再适用。在决定为团队购买最好的 CASE 工具许可证（license）前，先使用白板和方格纸，直到有足够的理由表明需要更多的功能。

在决定使用庞大的、高性能的数据库系统前，先使用平面文件（flat file）。不要认为更大的、更好的工具可以自动地帮你做得更好。通常，它们造成的障碍要大于带

来的帮助。

记住，团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让

团队基于需要来配置环境。



可以工作的软件胜过面面俱到的文档

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。

然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，

那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。

对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主意，但是那份文档应该是短小的（short）并且主题突出的（salient）。“短小的”意思是说，

最多有一二十页。“主题突出的”意思是说，应该仅论述系统的高层结构和概括的设计原理。

如果全部拥有的仅仅是一份简短的系统原理和结构方面的文档，那么如何来培训新的团队成员，使他们能够从事与系统相关的工作呢？我们会非常密切地和他们在一起

工作。我们紧挨着他们坐下来帮助他们，把我们的知识传授给他们。我们通过近距离的培训和交互使他们成为团队的一部分。

在给新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码

是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方

式。

许多团队因为注重文档而非软件，导致进度拖延。这常常是一个致命的缺陷。有一个叫做“Martin 文档第一定律（Martin’s first law of document）”的简单规则可

以预防该缺陷的发生：

直到迫切需要并且意义重大时，才来编制文档。

客户合作胜过合同谈判

不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件

项目的尝试都以失败而告终。有时，失败是惨重的。

告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导

致低劣的质量和失败。



成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。

一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。在大多数的情况下，合同中指明的条款远在项目完成之前就变得没有意义。那些为开发团队和客户的协

同工作方式提供指导的合同才是最好的合同。

我（Robert）在 1994 年为一个大型的、需要多年完成的、有 50 万行代码的项目达成的合同，可以作为一个成功合同的样例。作为开发团队的我们，每个月的报酬相对

是比较低的。大部分的报酬要在我们交付了某些大的功能块后才支付。那些功能块没有在合同中详细地指明。合同中仅仅声称在一个功能块通过了客户的验收测试时才

支付该功能块的报酬。那些验收测试的细节也没有在合同中指明。

在这个项目开发期间，我们和客户紧密地在一起工作。几乎每个周五，我们都会把软件提交给客户。到下一周的周一或者周二，客户会给我们一份关于软件的变更列表。

我们会把这些变更放在一起排定优先级，然后把它们安排在随后几周的工作中。客户和我们如此紧密地在一起工作，以至于验收测试根本就不是问题。因为他们周复一

周地观察着每个功能块的演进，所以他们知道何时这个功能块能够满足他们的需要。

这个项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住

了这些变更，并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。

响应变化胜过遵循计划

响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。

计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变动。其次，一旦客户看到系统开始运作，他们很可能会改变需求。最后，即使我们熟悉需求，

并且确信它们不会改变，我们仍然不能很好地估算出开发它们需要的时间。

对于一个缺乏经验的管理者来说，创建一张优美的 PERT 或者 Gantt 图并把他们贴到墙上是很有诱惑力的。他们也许觉得这张图赋予了他们控制整个项目的权力。他们

能够跟踪单个人的任务，并在任务完成时将任务从图上去除。他们可以对实际完成的日期和计划完成的日期进行比较，并对出现的任何偏差做出反应。

实际上发生的是这张图的组织结构不再适用。当团队增加了对于系统的认识，当客户增加了对于需求的认识，图中的某些任务会变得可有可无。另外一些任务会被发现

并增加到图中。简而言之，计划将会遭受形态（shape）上的改变，而不仅仅是日期上的改变。



较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略地了解一下

以后三个月要实现的需求。至于系统一年后将要做什么，有一个模糊的想法就行了。

计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划，就很难进行改变，因为团队会根据这个计划

启动工作并有了相应的投入。然而，由于计划仅仅支配了几周的时间，计划的其余部分仍然保持着灵活性。



团队建设

推荐理论

1.Cross-functional 团队

2.Self-Organization

3. 团队尽一切可能去完成任务——发布产品。团队需要全面的能力，这意味小组内拥有实现产品的全部技术和技能。团队还需要充分的理解产品负责人所描述的产品

愿景以及 Sprint 目标，以更好地支持可能需要进一步开发的产品的发布

4. 敏捷团队，QA 的特点：

作为开发团队的一员，和整个团队一起对质量负责：

关注编码，例如评审设计，（对技能要求更高）

自动化测试（对技能要求更高）

在客户很难和 Team 工作在一起时，QA 更多承担 customer proxy

程序员同样关注质量，特别在代码的质量，包括是否符合需求，是否可以自动测试...

图（典型的敏捷团队的 QA 职责需求）展示了一个典型的敏捷团队的 QA 职责需求。

5. 充分的授权是指事先已经给团队提供了完善的支持－训练、信息、资源，然后让团队能够自主地做出正确的决定。否则的话，让团队做决定等于就是弃他于不顾

6. 作为PM/SM，你如果完全放任，可能也就不需要你了。授权的关键在于使人们有权做他们自己的工作，并持续考量他们的工作结果，而不是置身局外

7. 自管理团队演化的过程： Zawacki and Norman 认为成功的自我管理团队由以下 5 个阶段不断演化而成：

阶段 1：传统的等级体系的组织结构，领导对下属进行一对一的管理和指导

阶段 2：领导转变为管理者（group manager），角色逐步向团队的协调者或者教练转变

阶段 3：管理者变成了团队的协调人，并向团队成员提供必要的培训使其承担更多的领导任务

阶段 4：团队承担有管理者承担的责任，管理者变成了团队外部接口

阶段 5：团队的管理者是团队的其中一个资源

8. 自我管理的团队并不意味着由团队来决定实现的目标，这是由 PO、客户决定的。自我管理的团队决定如何适应环境，而管理者会影响环境.在实践中往往会听到团

队说“这件事我们做不了，所以我们决定不做”…

9. 高效的自我管理团队应有以下特征：

清晰的目标。自我管理团队对所要达到的目标有清醒的了解，激励着团队成员紧密地凝聚在一起，形成一个真实的“命运共同体”。



相关的技能组合。这些团队成员拥有很多互补的技术和技能，并通过不断学习新的技术和技能来增加他们技术和技能的多样性、灵活性以及对于团队的价值。

共同的承诺。

良好的沟通。自我管理团队具有一种氛围可以让成员之间相互倾听并畅所欲言，有利于培养创造性与风险承担意识。团队成员直面和公开处理不同建议，并做出

真诚的反馈。他们了解彼此之间工作的进展程度，形成合力。

恰当的领导。自我管理团队的领导者往往担任的是教练和后盾的角色，对团队提供指导和支持，但并不试图去控制它。

环境支持。从内部环境来看，团队应拥有一个合理的支持体系，包括适当的培训，一套易于理解的用以评估员工总体绩效的测评系统，以及一个配套的人力资源

系统。这种支持体系能保证并强化成员行为以取得高绩效水平。从外部环境看，团队可以从多种渠道获得完成工作所必需的各种资源。

我们的实践

1. 角色：高级软件工程师、架构师、美工、QA、第三方技术支持

2. 最关键的特性：必要的技能、沟通意愿、对结果负责

3. 我们尝试了团队完全由高级软件工程师组成，质量由工程师负责，结果非常不好，一个是质量差，另一个是没有很好的技术高手，Coding Review、设计必要的前瞻

性和技术难点经常困扰。后来增加了架构师，增加了编码流程，部分解决了第二个问题和第一个问题中的代码质量，但功能质量还是不能保证，例如边界、各种异常、

非关键的正常流程往往被忽略。于是增加了 QA。此时的流程是：Daily Build，开发人员根据功能最主要的验收测试后发布在测试平台上，由 QA 进行测试。这样 QA 做

Story 增量测试，同时还可以兼任部署的工作。但我们还是有问题无法解决，例如 CMS、Ajax 技术难点、整体网站优化，这样需要更加专业的技术服务，我们和一些专

业公司签署技术服务协议，包括外包、现场支持等。美工是我们最后加的，是部门的资源，在需要的时候申请**天全职在团队中。需要说明的是，这里的“架构师”其

实是某一个专职的架构师和团队内资深的程序员组成的一个小组。

4. 最核心的是人，所以选人是第一步的，如果已经入职的人员不合适，磨合仍然不能符合团队要求，尽早让其离开团队，调整到公司的其它岗位。

5. 如果员工的新点子能够被团队接受，那就实施，这是非常有效的非物质激励的方法

6. 在团队刚开始建立的时候建立“如何一起工作”：有明确的完成标准、互相尊重、鼓励沟通、如何开 Daily Meeting、如果做 Sprint Planning 等等

7. 架构师的职责



在敏捷团队中，架构师的角色和传统开发团队中架构师的角色有很多重复的地方，也有一些不同的地方，我们团队的架构师，工作如下：

在 Sprint 之前，按照 Agile Modeling 的思路建立系统的架构（不是重量级的），这个架构是和团队（主要指 Senior developers）一起完成的，并欢迎团队中每

一个人为解决方案做出贡献。

在 Sprint 中，负责具体的重构（架构和关键业务逻辑）

在 Sprint 中，关注代码的质量和性能，具体是在 Coding Review 时及时提出问题并提出解决方案，同时他的编码会作为小组代码规范而统一；同时通过 Jmeter

进行压力测试，以判断性能情况。

在 Sprint 中，是一个指导者和协调者，可以确保团队不会因为缺少某些经验或是对某些技术感到不适而简单地拒绝一种设计方案。也可以在团队中经常出现不同

意见。还会带来激烈的争吵时来帮助团队打破僵局，重新和谐。

在 Sprint 中，和 PM 一起从业务价值的角度解释 Team 用到的技术方案的选择，所做的技术方案绝不是为了体现技术领先，而是在成熟技术和业务价值之间做平衡。

在 Sprint 中，Story 的实现不是工作重点，但会承担部分 Story 的实现

8. 如何让团队保持热情：

除了绩效考核外，还有一些事情可以使团队保持热情，我们是这样做的：

确定迭代周期，不至于太短使团队压力过大，也不至于太长使团队松懈。工作首先是热情的一个开始，我们的迭代周期是 3周

让大家每个人的工作放在整个团队的面前，例如需求细化、设计、代码、个人进度，这些都放在 Stand-up Meeting 中。有些功能工作量大，可以 3 天有一次 meeting，

遇到紧急或者需要大量讨论的功能，可能半天或者随时就有一次 meeting。

说真话必须受到保护。团队成员提出的建议，只要是对团队有用的，尽可能去实施，这个比任何口头宣传的“尊重、信任”都更有效

让市场的反馈经常传达到团队，无论是好的评论还是坏的评论，都会对团队的工作进行触动。成就感和危机感都会使团队在一种工作状态

给团队成员以技术方面的培训。这里的技术培训，我们一方面是让团队自己去摸索，另一方面将很难的技术问题外包，得到经过论证的可行的技术方案，再应用

到团队中。这样团队学的更快，对产品的风险也更小

要保持 SM/PM 的热情，如果他懈怠了，在团队还没有成为真正自我管理团队之前，一段时期内整个团队的节奏都会慢下来，SM/PM 在使以上措施得以实施的过程中

起到催化剂的作用

让及时推动也无法成为“Pig”的成员早一些离开团队

9. 团队要对承诺负责


我们的实践更加符合我们项目的场景，包括客户、公司、团队的实际情况。仅供参考第页共页Scrum 14 81

SM 的角色

推荐理论

Scrum Master 是整个团队的导师和组织者，他负责提高团队的开发效率。他常提出培训团队的计划，列出障碍 Backlog。Scrum Master 控制着检查和改进 Scrum 的

周期，他维护这一团队的正常运行，并与产品负责人一起让利益相关方获得最大化投资回报。他关心的是这些敏捷开发思想是否能得到利益相关方的理解和支持。

例如：

1. ScrumMaster 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。ScrumMaster 需要根据以上的情况更新反映

每天完成的工作量以及还有多少没有完成的 Burndown Chart。 ScrumMaster 还必须仔细考虑进展中的开放任务数，进展中的工作需要得到最小化，以实现精益生产率

的收益。

2. ScrumMaster 需要找出阻碍 Scrum 的障碍和依赖。他们需要优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团

队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。

我们的实践

1. 和 PO 讨论 PB 中的优先级。SM 讨论时要首先了解 Product Vision、Product Roadmap 和 Business Value，以及更主动的和客户沟通，以了解客户的真实意图以及客

户环境的制约和限制。有时 PO 只是为了增加市场机会，有时 PO 自己也没有想清楚。需要 SM 和 Team 去提出更多的问题去澄清。有一个例子：产品功能中要求不能在凌

晨发送短信，但只有电力行业例外。PO 提出了一个 User Story：系统管理员可以定制每个用户何时可以发短信，认为是高优先级。我们（Scrum Master 和 Team）在评

估 business Value 时提出问题：电力行业客户是否是我们的目标市场？公司是否有资源做电力行业的销售？经过讨论后，PO 的用意是来自 marketing 部门，他们不愿

意放过任何一个可能的市场机会，但 marketing 也承认确实机会比较小。这样，这个 User Story 的优先级非常低。

2. 在团队还不能做到自我管理(committed, proactive, collaborative)时，SM 要权衡领导和管理的比重。我们最开始实施 Scrum 时，两者的比重是 4:6,然后是逐渐

倾向于领导的比重越来越多。

3. 如何使敏捷开发思想是否能得到利益相关方的理解和支持，我们这样和大家宣扬 Scrum 的好处：

a、对公司的影响：公司的各级可能提出需求的部门（老板、市场部、销售、产品部、客户部等）不再是想到一个新的需求，得到客户的一个反馈，就给研发部发布需

求，而是公司有了一个机会，总结这些需求，分析业务的优先级，从 business value 的角度安排公司的资源，提高 ROI。

b、对公司的影响：对市场更快的反应速度，少的，核心的功能，保证了有市场功效的快速发布，增强公司的市场竞争力。特别是对于新成立的公司或者是新产品的研



发。

c、对团队的影响：持续的，可见的成就感。同时，可以很好的和公司的其他部门以及客户建立信任关系。定期的 working system 发布，每日的 stand meeting，随时

的 face to face 沟通，任何项目的 stakeholders 都可以随时了解项目的进展，信任也会很快建立。当然，前提是需要高质量的发布。

d、对个人的影响：快速的学习机会和环境。cross-functional 的团队环境，对于每个人都有更多的学习机会。同时，每个人都有发言权，会更长时间的延续工作的热

情。

4. 如何使敏捷开发思想是否能得到利益相关方的理解和支持，我们这样沟通：

a．首先要站在对方的角度说话。例如和管理层沟通，就要站在公司的角度讨论问题。和 PO 讨论问题，就不要直接说某某功能不能做，因为最终的优先级的决定权在

PO，可以先了解需求，讨论一下可能的工作量，介绍团队的资源，以谈判的方式沟通，而不是先造成潜在的对立环境。

b．维护自己的利益。软件的质量是由 Team 负责的，如果无限制修改需求，则会导致质量的严重下降。曾经遇到这样的 PO：我不管开发团队是否可以完成，反正我已

经提了需求，不能完成是开发团队的事情。这个时候就需要和管理层沟通

c．用数据说话，数据可以有一些 Buffer，但要基本靠谱。“这个功能没有时间做”，这样的沟通只会造成对立情绪。如果换成“这个功能需要 20MD，整个 Team 可以

使用的资源只有 30MD，而这个功能的优先级也很低，增加了这个功能就不能完成更高优先级的**功能，PO 你可以决定是否增加这个功能？”

5. SM 如何做整个团队的导师和组织者

a、和团队一起工作

和团队工作在一起。每一个 ScrumMaster 的背景不一样，有偏技术的，有偏管理的，网络上有各种各样的讨论，有人认为 SM 不应该涉足 Sprint 内的任务（Developer），

而要把重心放在指导、沟通、保护团队上；有人（例如 Mike Cohn）认为 SM 可以一定程度上做一些 Developer，但实现的任务一定不能成为关键路径；还有人认为 SM

需要成为 Core Developer，以保证任务的实现，特别是技术难点或者成为救火队员。我自己很有意思，正好是头 6 年做实际的编码、设计，后 6 年做管理（project

management、people management）。我是这样做的：指导、沟通、保护团队会占据 70％的时间，技术讨论会占据 30％的时间。我不会参与编码，也不会做救火队员，

不是我不想编码，而是我认为所有的对工作量的评估，应该由团队通过自己的实现来形成自己的感觉。我做的具体工作有一些例子：所有的需求我会跟踪到细节；技术

设计讨论我会参加，会发言，但不会主导，由 Team 主导并形成最后决定；代码质量交由团队 coding review 以及静态代码检测工具（findBug）等；测试我会自己将功

能完整过一遍；做燃尽图；…

b、以 Review 为主。由团队提出方案，SM 提出问题，而不是直接提出方案。

c、培训，更多的是以非正式的方式和言传身教的方式

d、对团队已经认可的工作方式，要在团队中固化，并不断改进。这一点非常重要，但很容易被忽视



PO 的角色

推荐理论

产品负责人是利益相关方的代表，他的工作重点是产品的业务方面。他负责向团队介绍产品远景。他负责给出一份明确的，可度量的，合理的产品 Backlog，并从业务

角度出发对 Backlog 中各项问题按优先级排序

我们的实践

1. 我们对 PO 的要求：全职、有深厚业务背景、有很好的沟通技巧可以代表利益相关方排列优先级。我们目前一个人不够，有两个 PO 为这个项目服务，但对于团队而

言，听到的是统一的意见

2. 最初是 SM 帮助 PO 做出最原始的 Product Backlog，以供前几个 Sprint 使用。PO 也是逐渐适应 Scrum



Product Backlog

推荐理论

Mike Cohn 推荐了如下的因素来评估优先级：

1. 经济价值、客户的意愿

2. 开发成本

3. 给公司和团队带来的经验和知识

4. 消除的风险

经济价值主要来源于增加收入以及减少成本。如果经济价值不容易估算，那么用客户的意愿来判断吧：）

增加的收入包含：

新领域（客户）带来的收入

原有客户新增购买量带来的收入

可以独立销售的模块、配件带来的收入

被市场接受更高价格的功能带来的收入

衍生服务带来的收入

减少的成本包含：

保留客户的成本（如果功能不开发，将失去老客户）

可能的效率低下造成的成本，例如培训新员工，部门间的沟通、过长的开发周期

客户的意愿

关于“客户的意愿/满意度”，推荐 Kano 模型：

Threshold：必须包含的功能，是一个客户接受的门槛

Linear：功能的质量、性能、易用性等指标越高，客户越满意。

Excited：可以给客户带来惊喜，但没有这些功能，也不会对满意度有负面的影响



给公司和团队带来的经验和知识，包含产品级的和项目级的。产品级的知识指通过某个新功能的开发来了解产品应该不含哪些功能以及不应该包含哪些功能，例如某个

功能在市场上的“投石问路”；项目级的知识指产品如何被开发出来，例如使用的技术、人员的技能、团队如何工作等等。

风险主要包含“计划风险”、“成本风险”、“资源风险”、“技术风险”、“商业风险”等等

我们的观点是：

1. 以价值（#1 和#3）和风险（#4）作为第一层面的考量，是“应该做”的层面。优先级的顺序如图（价值－风险：优先级的判断依据）所示

2. 以开发成本（#2）作为第二层面的考量，是“能否做”的层面。以这个为参考，适当调整“应该做”。

部分内容摘自 Mike Cohn：《agile estimating and planning》

我们的实践

1. 组成：功能性需求、非功能性需求、Bug

2. 形式：Story（Who、What、Why）

3. 如何考虑优先级：

3.1 PB 分为三类：最重要的，重要的，一般的。

最重要的指必须要在最近的 Sprint 内完成的，例如客户明确提出的、公司管理层提出的，系统有明显漏洞的，就算团队资源不能满足，那就必须拆分功能；

重要的是指尽可能在最近的 Sprint 内完成，例如客户不确定的、管理层不确定的、上个版本的 Known Issues，如果团队资源可以满足最重要的功能之前还有余力，优

先考虑此部分需求。一般的是指在 2～3个以后的 Sprint 考虑的需求

最重要的（> 200)，重要的（100 ～ 200)，一般的（1 ～ 99)。数字越大，优先级越高。

4. 开发团队如何评判 Product Backlog 中的 Item？

我们曾经用到的一些方法/原则：

产品的设计是否对用户的使用增加了规则和约束。如果是，那么就具有很高的风险，因为用户是不会按照我们的思路出牌的，而且我们也不知道用户实际的使用

环境。

产品的功能是 PO 提出的，还是最终用户提出的。如果只是 PO 提出的，是需要和最终用户沟通后再加入到 Backlog。Team 一般会做出原型，以得到客户的确认。

特别关注正常流程和异常流程，以及非功能需求。细节是最好的讨论线索。

要求给出用户使用场景（User Scenario）

涉及用户的体验，原则就是“最小的付出，得到最大的收获”



5. 我们如何管理需求变更

我们用 Product Backlog（PBL）记录产品需要完成的功能，此功能包含功能需求、非功能需求（性能、高可用性、可扩展性等）、上一个 Sprint 发现的 Bug

每一个需求会根据业务优先级加入到 PBL 中

优先级越高的，需求讨论的越细；反之，需求讨论的越粗

PBL 中的需求会经常被重新根据优先级排序，甚至被删除例如有新的需求加入。

每一个 Sprint，只做优先级最高的，Team Velocity 可以接受的需求

具体可以参考图（我们如何管理需求的变化）

说明：

由于我们公司是做电信增值业务，产品有设计、上线、运营等阶段，根据我们的实践，优先级是这样的：

在产品上线前，来自移动的要求、产品的关键卖点、系统的可扩展性的优先级最高

在产品的试运行期间，客户的反馈、性能、高可用性的优先级最高

在产品运营阶段，系统的监控、报警的优先级最高

我们的 PO 会接到各个部门的不断增加或者变化的需求要求，但以上优先级的方式是管理需求变更的原则

6. 我们如何写用户故事

选择一个好的工具，这样和用户沟通时可以很容易做头脑风暴以及方便记录，我们选择的是免费工具：FreeMind

每一个故事有三个要素：角色、事件、原因，我们把角色作为二级目录，事件及原因作为三级目录，分解的子事件作为四、五级目录，最后目录中的最后一级叶

子和二级目录中的角色构成了“故事”。 “故事”不但包含“用户故事”，还包含“开发故事”

为每一个“故事”写验收测试，具体就是分为不同的用户场景，每一个场景的描述为“当…的时候，做了…，会得到…”

好的故事应该是：

独立的，有价值的，可评估完成时间的，清晰并可以很快完成的，可以被测试的

我们有一个实际例子，参考图（我们这样写做用户故事）。其中，蓝色的文字部分是 Sprint Backlog，每一个分支的叶子部分是最后分解的“故事”，或者说相对独

立的小功能。红色的文字是其中一个功能分解为实现的任务。


我们的实践更加符合我们项目的场景，包括客户、公司、团队的实际情况。仅供参考第 20 页共 81 页 Scrum

评估会议

推荐理论

1. 参加者：PO、SM、Team 2. 前提：PB（Story）已经排列好优先级，故事点评估卡片（0，1，2，3，5，8，13，21，34，89）为每一个团队成员准备好。当然，Ideal day 也是另外一种评估

方法

3. 过程：PO 介绍需要评估的 Story 背后详细的用例，各成员首先选择最小用例的 Story X，指派其工作量为 1，然后针对每一个 Story 和 Story X 的工作量比较，同时

亮出评分卡片。如果有分歧，分歧最大的成员进行讨论，然后再次投票，知道所有人意见一致为止。将评估结果添加到 Backlog 中。

4. 交付物：更新后的 PB 通知所有参加会议的人员

5. 持续时间：无推荐

我们的实践

1. 参加者：PO、SM/PM、Team 2. 前提：PB 已经准备好，可以是故事，也可以是 Feature List，但往往 PO 不会提供 Why，SM、Team 也不追究，可以要求 PO 提供需求来自哪里（直接客户、老板、

市场/销售部门、产品部、技术部门），这个在现实中成为优先级的排列依据。PB 的 Item 没有任何书面的细节。PB 包含了业务需求、上一个 Sprint 遗留的 Known Issues、技术部门提出的技术需求（开发环境的搭建、基础架构的实现等）

3. 过程：PO 介绍需要评估的所有 Story 背后的用例，仅是 High-Level，主要的正常流程即可。各成员首先选择最小用例的 Story X，指派其工作量为 1，然后针对每

一个 Story 和 Story X 的工作量比较，我们是用 IMD 为评估方法，直接用任何近似的比例，例如可以认为是 4.3,也可以认为是 2.7（我们也在同时尝试用评估卡片的数

值，正在看不同的效果）。大家同时亮出估算比例，分歧最大的成员进行讨论。对于任何和现有功能依赖关系很弱的功能或者团队成员对整个系统都很熟悉，最多讨论

两轮，根据最后所有人的平均值作为估算比例，这些功能可以由团队中的任何人实施；对于团队中少数人了解的功能或者技能（双机热备等），主要由这些人进行评估，

并给出理由，其他人给出一些辅助意见，同时这些功能也主要由这些人完成。大家评估最小用例 Story 的 IMD，然后按照估算比例计算其他故事的 IMD。最后将估算结

果添加到 Backlog 中。如果 PO 先介绍完 Story，成员已经比较清楚，工作量的评估 PO 可以不参加。参加的好处是透明的过程增加双方的信任感。用 IMD 的最大原因

是 PO、管理层需要明确的估算时间

4. PO 形成期望的 Sprint 目标，这个目标是根据业务优先级以及在评估会议上得到的 Backlog 的评估值由 PO 综合决定。此时 PO 提供期待 Sprint 目标中 Backlog 足够

的信息，并以文档的形式发给团队。例如报表需求，足够的信息包括，通过哪些查询条件，得到什么查询结果，查询条件和查询结果中的字段定义

5. 交付物：更新后的 PB 通知所有参加会议的人员

6. 持续时间：4~8 小时



Sprint 计划会议 1

推荐理论

1. 明确 Sprint 的时间表

选择迭代周期，一般有以下一些方法：根据整个 Release 的周期，一般至少需要 4～5 个迭代以获得客户的反馈根据不确定性的数量，一般不确定性的数量越多，迭代周期越短。最需要关注的不确定性包括：客户到底需要什么？每一次迭代 Team 到底可以完成多少？项目

的技术风险？举例：如果我们想增加一个高优先级的新增需求，那么这个需求一般要在 1.5 个迭代之后才可以提交。见图（增加一个新的需求何时可以发布）根据每一次迭代的成本。成本越高，迭代的周期越长。全用例测试的时间和资源是最典型的迭代的成本。根据团队对压力的感受。好的开发节奏，应该是团队感到压力比较大，但努力一下可以达到。团队没有压力或者压力非常大都不是好的开发节奏，时间长了会严

重影响士气或者产品质量。假如一个团队在 4 周的迭代周期中，第一周开始仍然比较松散，那就要考量一下是计划不合理，还是适当缩短迭代周期。 2. PO 向团队阐述产品的远景

3. 如果 Backlog 中有问题遗漏，PO 可以向 Backlog 中增加问题，并重新排列优先级

4. PO 和团队一起确定 Sprint 目标

5. 持续时间：4~6 小时

我们的实践

1. PO 明确 Sprint 的时间表，这个一般确定在 4 周，但是也会因为客户的要求或者市场的要求而改变。例如我们的客户一般要求每月的第一天开始部署新的程序，此时

我们的 Sprint 周期为 1 个自然月；如果我们的市场宣传需要一个配合（20 天后），那么 sprint 周期会定在 20 天。目标只有一个：提供价值

2. PO 会向团队介绍半年之内的 Roadmap，这个团队非常关心，因为可能涉及到设计等；对于产品的远景，团队会听一听，但不会特别关心，有时候 PO 就不会涉及

产品的远景。

3. 如果有的话，PO 或者开发团队增加认为遗漏的问题，并调整优先级。如果这些问题有在 PO 期望的 Sprint 目标内的，团队需要评估工作量，否则可以留在下一次

的评估会议再评估。

以上持续时间：1小时，休息



4. 团队内部进行讨论，明确至少两个人对某个或几个功能重点关注（对相关业务熟悉的和不熟悉的组成一组）。我们曾经尝试大家一起对所有功能进行分析，但发现

有时候没有人会提问或发言。 5. PO 向团队介绍期望的 Sprint 目标。介绍各个 Backlog 背后的用例，包括正常流程、异常流程。此时团队有任何细节问题都可以向 PO 提问以获得答案。界面原型也

是讨论的一个方面。由项目经理进行整理、记录。以报表为例，此时就增加了如何排序等细节

以上持续时间：4～6 小时，

6. 团队根据项目经理的整理资料，再回顾一次 Backlog 背后的用例，有不确定的地方和 PO 讨论。同时完成各个功能的最主要验收标准

#5 持续时间：4~6 小时

7. 交付物：明确的 Sprint 周期和 Backlog 的用例资料，我们的资料包括文字描述的正常、异常流程和手工界面原型照片、最主要验收标准有一个我们实际的例子来说明交付物的内容：（*****是为了保护商业秘密）需求描述（User Story）：原则： Who, What, Why。在实践中，Why，即 Business Value，很多时候 PO 是会忽略的。例子：各级业务管理员可通过***平台了解全国/省/地市范围内的业务用户数、整体业务量以及***号码使用情况等信息。系统可以固定格式自动按日/周/月/年四个时间维度提供

报表，报表包括：报表 1：***业务发展情况报表 2：***业务号码使用情况统计报表报表 3：***号码业务流量统计报表需求分析原则：保证正常流程、异常流程描述清楚即可。由于这个例子是报表，所以将报表的种类、报表中的字段定义清楚即可。例子：报表种类：包括 4 类报表：关键指标（默认显示）、日报、周报、月报查看方式： 1）系统默认显示“关键指标”，用户可以通过点击相应的按钮，切换到相应的报表页面，并显示当前最新的日/周/月报表；



2）在看到最新的报表的情况下，用户可以通过输入开始时间和结束时间，查询这个阶段内所有的日/周/月报表数据。通过这样查询出来的表，可以看到一个阶段内的

趋势。日报字段定义：累计数：******* 到达数：******* 净增数：***** － ******。净增数量较前日的增长率%：（***** － ****）/ ***** *100% 界面原型原则：由开发人员和 PO 沟通用户体验，在纸面/白板上讨论，最后由美工进行加工并完成以图形方式保存例子：******



Sprint 计划会议 2

推荐理论

过程： 1. 按照 Sprint 目标中的各项功能分出相应的任务，确保考虑到工作中所有的细节：编码、测试、代码评审、会议、学习新技术、编写文档等

2. 如果任务需时超过一天，尝试将此任务分解为几个小任务

3. 通过分解任务判断功能（Story）最初评估的工作量是多是少，如果过多评估，则和 PO 一起增加 Backlog 到 Sprint 中，否则删减或者拆分

4. 团队确认 Sprint 目标（commitment）

5. 持续时间：4～6 小时

做法： 6. 如何拆分故事我们为什么要拆分故事：

故事太大，不能在一个 Sprint 内完成

需要对故事进行精确的评估大小

拆分故事的典型做法：

按照数据的边界

例如一个故事：作为超级管理员，我要看到所有的数据，因为我关心业务各个层面的发展。这个故事可以被拆分为：作为超级管理员，我要看到业务管理员的数据；作

为超级管理员，我要看到客户经理的数据；作为超级管理员，我要看到集团客户的数据；

按照业务操作的边界

例如一个故事：客户经理可以查看客户的基本信息。如果查询条件过于复杂，而且客户信息显示逻辑也比较复杂，这个故事可以拆分为：客户经理可以按照客户创建时

间搜索，显示查询到的客户数量；客户经理可以按照客户创建时间搜索，显示查询到的客户信息；

一般常用的拆分步骤为：首先按照增加、查询、编辑、删除四个环节拆分业务；对每一个环节，按照业务流程不同分支路径进行拆分（例如有 IF 条件）；对每一个路

径，将路径中的节点按业务顺序分步实现；

按照公共模块的边界：这里的公共模块包含登录、出错处理、安全等，做法是将故事拆分为包含公共模块的故事和不包含公共模块的故事。

将性能等非功能性需求和功能性需求分开，先考量可以工作，再考虑做的更快。（Make it work then make it faster）



拆分故事要避免的：不要把故事拆分为任务，例如将故事拆分成编写界面、完成中间层等，这时开发人员常犯的问题，有一个办法可以防范：拆分后的子故事是否有界

面、中间层、数据层中至少两个的任务，如果不是，则有可能被拆分成了任务

部分内容参考 Mike Cohn：《agile estimating and planning》

我们的实践

1. 按照 Sprint 目标中的各项功能分出相应的任务，确保考虑到工作中两个关键的细节：编码、测试。这个过程也就是设计的讨论过程，最关键的是对架构的影响、接

口、数据库的影响。

2. 如果任务需时超过一天，尝试将此任务分解为几个小任务，任务的分解周期是 2～8 小时。如果有多个任务非常小，例如 Bug 修改，可以几个合在一起作为一个较

大的任务。任务完成的时间是在以没有任何外界干扰为前提，例如额外的技术支持等

持续时间：8～12 小时

3. 通过分解任务判断功能（Story）最后的工作量评估。同时团队反馈本 Sprint 周期内可用的资源（MD），乘以资源利用率（需求细化的程度、写文档的时间、会议、

技术支持、适当的 Buffer，例如 20％等因素），就是本 Sprint 内团队可以完成的工作量。用这个工作量去和 Sprint 目标中包含的 Backlog 的工作量比较，多删少补，

以达到 PO 和团队都认可的 Sprint 目标

4. 功能已经初步落实到人（若干人）。即具体的人（若干人）对功能负责，而不是对任务负责。关键的里程碑、check point 也已经确认，目的是让团队所有人对项目

的进展有总体的把握。落实的原则是：逻辑复杂的功能，多人承担；有一个经验丰富的人和业务熟悉的人并不进行满负荷承担，目的是为经验少的人提供结对帮助，同

时也为可能的技术支持等留下资源。

5. 团队确认 Sprint 目标（commitment）

持续时间：2小时 6. Scrum 使用不同阶段，如何判定 Sprint 内可以完成多少功能？承诺驱动——Scrum 使用初期（最初的几个 Sprint）

在我们头几个 Sprint 中，由于开发小组对自己的 Velocity 没有足够的了解，对 Scrum 也没有足够的了解，所以我们用“承诺驱动”的方式来决定 Sprint 内会完成多

少的任务（“故事”），以下是我们的主要步骤：



明确功能的优先级

明确此次 Sprint 要达到的目标

选择优先级最高的功能，分解为实现任务，并评估如何实现

如果 Team 承诺可以在 Sprint 内实现，则此功能加入到 Sprint Backlog 中。如果不能承诺，和 PO 商议，一个办法是拆分功能，另一个办法就是放弃这个功能

不断评审优先级最高的一些功能，直至 Team 不能承诺完成为止

Velocity 驱动――Scrum 使用一段时间后

随着几个 Sprint，开发团队、管理层、PO 对于开发的效率、质量等不断调整心理预期与实际的差距，需要一个量化的指标可以正确标识团队的开发能力，同时也可以

作为团队绩效考核的一个参考，这个时候就需要评定团队的 Velocity。我们是这样做的：

记录每个 Sprint 可以实现功能的 IMD（Ideal Man Day），实现功能的标准是任务可以发布（编码、测试、部署、文档等），而不是仅仅编码完成

记录每个 Sprint 实际的可以利用的资源。例如我们在第三个 Sprint 时，团队 7 个成员（A，B，C，D,E，F，G），3 个星期的开发周期，A，C，E,F,G 将全勤，B

会请假 2天，D 最后一个星期才会加入团队，所以此次 Sprint 团队实际的可利用资源为：5*15＋13+7=95(MD)

计算资源利用率：实际完成功能的 IMD / 实际可利用的资源。以我们的第三个 Sprint 为例，当时完成的实际功能的 IMD 为 52IMD，资源利用率为：52 / 95 ＝ 54.7%。

我总结了团队资源利用率不高的一些原因：

a) 团队刚接触新的业务，对需求的理解花费较长的时间，同时测试也发现了实现和需求不符的地方，这是由于开发人员和 PO 的沟通较少所致

b) 技术架构不成熟，还在不断构建，影响了实际业务层面的实现

c) 有一些技术支持的工作

平均前三期 sprint 的资源利用率。我们没有按照上一期 Sprint 的资源利用率来作为参考，是因为我们对于任务的完成按照 100%完成的标准。按照前三期的平均

值，更加可行

用第四步得到的资源利用率，乘以即将开始的 Sprint 内可以利用的资源，基本可以得到此次 Sprint 的团队开发能力（Velocity）

7. 如何做：估算任务的粒度在 2~8 小时

我们现在是用 IMD 的方式评估工作量，即每一个故事的大小，分解任务时将任务的粒度控制在 2～8 小时之内。

我们的想法：

Sprint Planning 中分解任务部分要达到的目标，不仅仅是看到了一个计划，更重要的是如何完成计划。将任务分解为小时为单位，是为了使团队考虑如何实现功

能时考虑的更加细致，更容易在团队内部讨论，及早发现问题，更加靠谱。

瀑布和 RUP 的开发方式和敏捷开发进行任务拆分，如果我们认为一个版本的功能要拆为 100 份工作会分析的比较透彻，那么打个比方，1000 元分为 100 份，每份

10 元；50 元分为 100 份，每份 0.5 元；瀑布开发的周期较长，整体工作量大，任务拆分的评估单位为天就不错了，而敏捷开发周期短，每个周期的功能工作量小，

如果仍然以天为单位，例如 3 天，团队成员无法了解 3 天的细节，本来敏捷开发就没有特别完善的文档，那么如果在 3 天里出现了意外，团队无法进行有效的帮

助。



我们是这样做的：

每一个故事对任务的拆分，至少包含：编码、测试、文档；如果任务超过 8 个小时，则再拆分。

在 Sprint 中往往有上一个 Sprint 的 Known issues，修改并不会花费很多的时间，很多小的 issue 只会花费 20 分钟，这样我们会汇总相似的，表明工作量为 2～

3 个小时

当某一个 Story 确实无法完成时，团队可以根据任务，和 PO 讨论拆分 Story。我们有过这样一个例子：一个 Story 要求用户可以查询手机号码以获得通话记录，

我们分解的任务是：查询界面、精确查询、带*、？、关联姓名等查询、查询结果界面，其中带*、？、关联姓名等查询耗时较多，最后将 Story 拆分为：用户可

以精确查询手机号码以获得通话记录、用户可以模糊、关联查询手机号码以获得通话记录。其中前者在此次 Sprint 内完成

举例：

我们有一个 story：用户可以发送定时短信，以便在方便的时间编写短信，在不方便的时间发送短信。

分解的任务为：

1. 从数据库中查询满足定时发送的短信（2H）

2. 利用第三方的发送端口发送（15H）

2.1 编写调用第三方发送 API 的接口（5H）

2.2 编写 API 接口的测试用例（3H）

2.3 准备 API 接口的测试数据（2H）

2.4 测试 API 接口（5H）

3. 显示发送状态（2H）

4. 进行界面功能的单元测试（8H）

5. 更新需求文档（1H）

6. 更新设计文档（1H）

7. 更新部署手册（1H）

（）内部分为评估的时间

一点体会：

实践中团队成员开始并不愿意以小时为单位进行拆分任务，一方面是不习惯如此细分，很琐碎，觉得是对自己的不信任，另一方面每个人都会或多或少评估工作量时给

自己留一些 Buffer，以天为单位留 Buffer 容易一些，以小时为单位则任务拆分的更细，buffer 的空间就小了。

参考了《Agile Estimating and Planning》中对敏捷计划的看法：

1. 计划本身比最后的计划重要

2. 计划很容易调整

3. 如果需要，在项目过程中不断调整计划



每日例会

推荐理论

1. 参与人：团队、SM、PO（可选）、相关人员（可选）

2. 在 Sprint Backlog 上的所有任务都是可以增删修改，可重排序的任务的状态可设为“待处理”，“正在处理”，“已完成”的

3. 会议限制在 15 分钟，团队每人回答三个问题：上次会议时的任务哪些已经完成? －－把任务从“正在处理”状态转为“已完成”状态

下一次会议之前，你计划完成什么任务？

－－如果任务状态为“待处理”：转为“正在处理”状态

－－如果任务不在 Sprint Backlog 上：添加这个任务

－－如果任务不能在一天内完成：把这任务细分成多个任务

－－如果任务可以在一天内完成：把任务状态设为“正在处理”

有什么问题阻碍了你的开发

－－如果任务状态已经是“正在处理”：询问是否存在阻碍任务完成得

问题，如果有阻碍你开发进度的问题：把该障碍加入到障碍 Backlog 中

4. 如果展开了一个问题的讨论

提醒团队的成员们注意把精力集中在回答关键问题上

5. 如果相关人员想发表些言论：

礼貌地提醒他，该会议只允许让小组成员讨论

6. 交付物：障碍 Backlog、最新的 Sprint Backlog、最新的工作进展图

我们的实践

1. 参与人：团队、SM 2. 我们每天都会有这个会议（9：00 开始），一般在 20 分钟左右。每 2 天会在 40 分钟左右，这样的会议我们会每次轮换 2 人展示其最核心的一段代码（不超过 100行），大家来 Review，包括 code standard，业务逻辑、异常处理等。

3. 每天的会议，对任务的处理都在口头上（除了可以直接移动任务），由 SM 会后整理、更新白板，否则时间会很紧张。具体的白板信息，见图（我们的白板）。说



明一点：在回顾会议中大家对 3 周的很多细节不能完全回忆，会议的过程不够深入，所以决定在白板中增加一项：GBU，Good、Bad、Ugly，即在 Sprint 内无论是技术、

沟通、管理各个层面，团队的任何人任何时候都可以在这一项中添加自己的意见，这样在回顾会议中，甚至在开发过程中，我们都可以反思、提高我们的流程。

4. 每天的会议，除了说这三件事，我们把它作为整个团队共享信息的机会，例如某个功能细节和 PO 确认，说给大家听；有一个技术突破，说给大家听。只是 High-Level的层面，如果谁有兴趣，可以下来细谈

5. 所有人都会准时参加，因为公司做了考勤制度，3 次迟到了会扣除当日工资的 50％ :( 6. 对于各自遇到的障碍，可以马上得到解决，则明确解决方案，否则明确到承担人，会后再想办法解决，下一次 Daily 会议时通知所有人。具体的解决障碍的方法参

考图（我们这样解决障碍）



过程监控

推荐理论

下一个版本中增加。

我们的实践

1. 我们用 Scrumworks 记录谁在做什么，Sprint 的状态，和 PO 讨论产品的 Backlog。但是我们每天还是用白板做记录，见图（我们的白板）。白板对于团队和 PO有最直接的作用，但对于管理层、其它部门、客户等需要了解 Product Backlog、Product Burndown Chart，很多时候也不会出现在团队的开发环境，Scrumworks提供的 B/S 方式保证了异地了解的可能

2. 我们如何用 ScrumWorks 做项目管理？在实践中，选择的工具是 Scrumworks Basic 版本（V1.8.3），各个 Stakeholders 都可以通过 Scrumworks Server 来加入讨论，了解进展。具体我们是这样做的：

在公共服务器上安装 Scrumworks Basic 版本，加入用户，建立权限

PO 在“Uncommitted Backlog Items”区域中增加新的 Backlog，项目组也可以增加，由 PO 进行优先级设定。项目组对增加的 Backlog 中处于“Top”即高优先级

的部分首先进行工作量评估。Backlog Item 在列表中的位置越高，表示优先级越高

在左侧的“Committed Backlog Items”区域中，PM 建立本次的 Sprint

在 Sprint Planning 之后，PM 将准备在本次 Sprint 完成的 Backlog Items 移到左侧的 Sprint 中，并建立具体的任务，并列出每一个任务评估的时间

每天的 Daily Meeting 后，PM/SM 会更新完成情况

有权限的 Stakeholders，例如管理层、客户代表、PO、项目组成员，都可以在 Sprint 的窗口内看到 Burndown chart，以了解当前的状态；同时也可以在“view

impediments”窗口中了解项目当前需要的问题

回顾会议，“View Impediments”以及“Burndown chart”是两个重要的参考资料

说明：几乎所有的数据和记录，我们都是会议后再加入到系统中，在会议期间，白板是我们最常用的工具。

3. 我们遇到的一些项目预警迹象：实际的工作量和评估的工作量不符

在我们的实践中，特别在初期，经常会经常遇到实际的工作量大大超过工作量的评估，偶尔也会遇到实际的工作量远远小于工作量的评估，这都是 Team、PO 等对自

己认识不足的原因，但有一点，我们可以从 Burn-down chart（燃尽图）中很快发现迹象。参考图（实际的工作量和评估的工作量不符）。图中红色的曲线，给 Team



明显的迹象：实际的工作量已经超过了评估的工作量，项目有极大的风险。图中蓝色的曲线，给 Team 明显的迹象：实际的工作量远远小于评估的工作量，项目没有风

险，但会造成 Team 由于工作量不饱满而表现出的一些问题，特别是有大量的时间浏览与工作无关的网站等，以至于引起 PO 以及管理层对项目组的不满，从而影响双

方的信任等。功能不能全部完成

在 Sprint 中，如果燃尽图一直是正常的，但在某一个时间点经常会有意外的情况导致所有功能不能完全实现，此时我们的策略是： 1）按照优先级实现功能（故事） 2）功能之间是松耦合的，或者说是依赖性不强的，一定是某一个或者某一组（依赖性强）的功能完全实现后再进行下一个或者下一组。在这个场景中，项目风险的典型迹象之一是先完成优先级低的功能，当 Sprint 结束时，高优先级的功能没有完成，提交的软件不能使 PO 和客户非常满意。这种迹象参

考图（功能不能全部完成、高优先级未开发） 4. 我们的白板是怎样的？改进前：虽然我们用 Scrumworks 来管理 Scrum 项目，但我们仍然用白板的方式来最直接的沟通项目的状态，改进前我们是这样做的：

用一块（180*120 厘米）的白板作为沟通的介质。所有人从外面进入办公区，都必须经过一个小的会议室，这个白板就放在里面，我们平时会议也在这里白板分为两个区域：任务进展、关键信息。任务进展区域反映有哪些功能，分解为什么任务，哪些任务正在进行，哪些任务需要确认需求，哪些功能已经达到了

“DoD（definiation of done）”的标准；关键信息区域包含燃尽图（目的是使项目进度一步了然）、“新增加的功能”等 4 个信息项是为了记录 Sprint 内项目更

多的细节以及在回归会议时分析项目经验教训时提供直接的信息我们是每天做 Daily 会议，所以同样周期更新一次白板信息

具体的白板参考图（我们的白板－改进前）改进后：在我们的实践中，虽然 Scrum 的理论要求在 Sprint 内不增加功能，但实际上团队会受到销售、业务、市场，甚至管理层直接的压力，PM 或者 SM 无法拒绝新增加的

功能，所以经常会出现：增加功能、移除优先级低的功能等。此时燃尽图已经无法表达 Scope 的变化，而这些变化也最容易被忽视，因为大家都在关注着最终的结果。

所以在最近我们选择了“变更－燃尽柱”来反映项目的状态，同时删除了“Spike 项目”的信息，用“GBU”信息取代，原因是前者的初衷是为了表达如果此类信息太

多，说明团队的技术能力需要大大提高，或者说技术方向选择的不正确，偏离了团队现有的技术能力，但发现 PO 或者管理层对这些并不关心，他们关心的是结果或者

是遇到的障碍（虽然 Spike 对于团队很重要），所以我们在白板中不再标明；同时在回顾会议中大家对 3 周的很多细节不能完全回忆，会议的过程不够深入，所以决定

在白板中增加一项：GBU，Good、Bad、Ugly，即在 Sprint 内无论是技术、沟通、管理各个层面，团队的任何人任何时候都可以在这一项中添加自己的意见，这样在

回顾会议中，甚至在开发过程中，我们都可以反思、提高我们的流程。我们用的 Card，是两种尺寸的“记事贴”，不记得具体的尺寸，一种的正方形的，一种是长方形的，最长的边应该在 5 厘米以内。我们首选正方形的，因为可写的内

容多一些☺



具体的白板参考图（我们的白板）



Sprint 评审会议

推荐理论

1. 参与者：PO、SM、团队

2. 团队按 Backlog 中的问题，逐个地介绍这次 Sprint 的结果，和演示新功能。

如果产品负责人想要改变功能：添加一个新问题到产品 Backlog 中

如果对功能有一个新的想法：添加一个新问题到产品 Backlog 中

如果小组报告项目遇到阻碍现在还没能解决：把该障碍加入到障碍 Backlog 3. 交付物：对这次 Sprint 的结果和整个产品的开发状态的共识

我们的实践

参与者：PO、SM、团队

过程：

在 Scrum 体系中，每一个 Sprint 之后都会做一个演示（Demo），以获得 Stakeholders 的反馈。在实践中，我们发现如果只在 Sprint 之后再做 Demo，由于 Sprint 过程中沟通不充分，Demo 展示的功能很可能不符合客户真正的需求，导致 Sprint 失败。于是，我们：

1. 将 Sprint 内的 Features（user story）按照耦合的程度分为几个组

2. 每一个组完成后会部署在开发平台上进行测试，此时的测试首先是 QA 的初步测试，保证 Feature 可以正常运行；然后是 PO 的验收测试，保证功能没有偏离需求

3. 当第二个组的 Features 完成后，会进行整合测试

4. 在 Sprint 之后，再进行整体的 Demo。

流程可以参考图（我们这样做 Demo）

好处：

1. 任何偏离需求的风险在 Sprint 期间的非正式 Demo 时被发现，得到及时处理

2. Feature 组是按照优先级排序的，先做的是最高优先级，那么如果发生了任何意外（例如人员变动、技术障碍等）无法完成所有的 Feature，那么高优先级的 Feature可以在 Sprint 结束前被提交。

我们做 Demo，会坚持以下原则：



1. 只是演示本次 Sprint 内的功能

2. 演示过程中，Stakeholders 提出的意见，在演示会议中不做讨论，只是做记录，在会后再进行沟通。

3. 保持 Demo 时间控制在 45 分钟

4. 一个人完成所有的演示

5. 只演示已经完成的功能。除非 Stakeholders 要求，否则不展示未完成的功能。因为只有已经完成的功能才是可以给客户带来价值的。



回顾会议

推荐理论

1. 参与者：PO（可选）、SM、团队

附属工具：为所有参与者准备的荧光笔、贴纸、红色和绿色的白板磁吸、白板和挂纸板

2. 在挂纸板上写上主要指导原则:主要指导原则：不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，

在限定的环境下，都尽其所能做出了最好的成绩

3. 在挂纸板上画上一个至少三页纸连在一起长的时间轴，标记出 Sprint 的开始和结束时间

a、在挂纸板上写上“最重要的事情” b、在挂纸板上写上“我们的成功经验是什么” c、在挂纸板上写上“有什么能够改进”和“谁负责”，然后分成两个区域：“团队”和“公司” 4. 每个人用贴纸写出、张贴、讲解“最重要的事情”、“成功经验”、“需要改进”，限制在 5 分钟完成。然后将后两者确定“谁负责”，再排定优先级

5. 每个与会者对会议做简短的总结 6. 将“需要改进”的部分增加到障碍 Backlog

我们的实践

1. 起步：

介绍会议的持续时间、目标、步骤、会议规则

持续时间：2 小时；目标：下一个 Sprint 我们改进的具体措施

步骤：“共享信息”、“找出成功的经验，发现问题，提出改进意见”、“决定如何改进” 会议规则：每个人都要发言，表决的时候所有人同时进行

2. 共享信息

目的是为了建立所有人讨论的基础，可能有人生病了，可能有人只做自己的功能，不是所有人对整个 Iteration 有全面的了解。这些信息包括：开发过程中故事的完成

情况、BUG、新增技术、故事变更、资源变更、个人的建议、公司的政策变化等等。由于白板只能记录每日的情况，所以我们在实践中在白板中增加了一些区域记录

这些信息，见图（我们的白板） 3. 找出成功的经验，发现问题，提出改进方法

每个人写出最成功的三个经验，贴在白板上



在#2 中确定优先级最高的 5 个问题（优先级由团队确定），大家来发现原因，然后提出改进的方法。最好要列出更多的原因和改进的方法。往往第一个原因和改进的

方法是表层的，深入的讨论才能找到深层的原因和根本的改进方法。

4. 决定如何改进

在改进的方法中找到团队认为在下一个 Iteration 中可以实施的改进方法。如果是公司负责的，则由 SM 记录后和 PO、管理层沟通。

5. 结束回顾会议：将会议的结论记录在案，发给所有的参与者

下面是 2 个小时的回顾会议的时间分配建议：

起步 5％ 6 分钟

共享信息 20～30％ 24 分钟

成功经验，发现问题，改进方法 40～50％ 48 分钟

决定如何改进 30～40％ 36 分钟

结束回顾会议 5％ 6 分钟

经验分享：

1. 如果某一个或多个成员非常被动的发言，可将 Team 分为若干个小组，如 2 人一个组，有一个活跃一些。

2. 尝试回顾会议由团队所有成员轮流主持

3. Release 或者有重大决议的 Iteration 的回顾会议，建议领导（Manager）参加，这样领导会了解团队重大决议的背景，并为领导支持这些决议提供沟通基础。平时

的 Iteration 的回顾会议，领导不需要参加，因为领导往往会不自觉的主导会议，而且团队成员发言会有所顾忌

4. 每个人发言时，不用“我”或者“我们”作为主语，如果要涉及某个成员的功能、代码等问题，

最好是用问题本身作为讨论，而不是将“你”、“你们”加上。例如，如果你说“***，

你实现的登录功能 Bug 太多，以至…”，建议改为“登录功能的 Bug 太多，让我们看一下问题在哪里”。

具体实例：分享我们的一个回顾会议，以第三步（找出成功的经验，发现问题，提出改进方法）为例：

我们对目前的 Bug 做了分析，结论如下： a、有 3 个 Bug 属于异常流程的处理错误，说明开发人员没有在这个方面做更多的测试，同时这 3 个 Bug 应该在测试平台中被发现，说明测试用例不能在异常流程中没

有覆盖

b、有 1 个 Bug 属于正常逻辑（存储过程）的处理错误，比例较小，说明大多数开发人员做了正常流程的单元测试，是一个好信号。

c、有 3个 Bug 属于 QA 对业务的理解问题，说明 QA、开发人员、PO 之间的沟通有问题，今后需求的沟通至少 QA 和开发人员各有一人在场，或者在 Daily Meeting 中互

相说一下

d、对于存储过程的 Bug，特别要说的是，这些存储过程是 DBA 独自编写的，没有进行 coding review，这是一个很大的失误。对于关键的业务逻辑，今后必须进行代码

审查以及两人以上完成。同时对于测试平台有一些用例不能实际测试的情况（如打电话产生的 CDR 处理），我们必须准备完备的测试数据来模拟测试场景，不能以没有

测试条件而放弃这些测试。



如何部署为了保证质量，有四个平台进行部署：开发平台（团队使用）、测试平台（QA 测试）、Staging Server（上线前测试，和现网环境一致）、Production Server（现网

环境）。 1. 我们的 Release 周期为四周，其中三周为测试平台的测试，第四周为 Staging Server 的测试、验收以及部署在生产平台上。 2. 开发团队在开发平台上测试完成后，由 QA 做每日集成到测试平台进行测试，测试的内容包括程序打包、数据库脚本运行、功能等。在第三周末由 QA 提出部署申

请，编写部署手册，总监审批，由工程部部署在 Staging 平台上。由外部 QA、PO、客户（如果客户希望）在 Staging Server 上做验收测试。一切正常，由管理层批

准，由工程部部署在生产平台上。部署流程参考图（我们是这样部署） 3. 如果在一个版本上线后，发现有重大的 bug，例如影响功能使用，报表数据不正确，会采用 HotFix 的方式紧急部署



如何有效沟通总的原则：平和的心态，合理的数据、职业的方式 1. PO 有了新的需求，需要加在这次的 Sprint 中首先站在 PO 的角度分析需求的优先级，然后具体分析需求，评估工作量，告之确实做不完，但可以拆分需求，并去除本 sprint 内未做完的一些旧的需求。双方达成共

识。而不是首先抱怨怎么又加了新的需求，工作已经很饱满了，做不完，或者直接拒绝（虽然理论上 Scrum 要求 Sprint 内不增加新的需求）。 2. PO 和团队都不主动沟通现象：PO 在 sprint planning 会议中讲了 Feature 后，Team 成员没有主动和 PO 进行细节的沟通，很多时候有不明确的地方，会按照自己的理解进行设计、编码；每

日集成后，PO 不会去 review 今天完成了哪些 feature，是否有不符合需求的，而是要等到在 Demo 会议再去验收原则上讲，双方的不主动是“习惯”使然，大家习惯于“各扫门前雪”，同时也会和东方人内敛的性格有关。我们在实践中是这样做的：在制定 sprint plan 时，不会在 sprint 的末端再做 Demo，而是将 sprint 分为更小的阶段，每一个阶段做一个正式的 Demo，这样从制度上保证 PO 对产品的关注，更早

的发现风险 3. 所有发出的信息是本人验证过的 4. 信息在 WiKi 中共享，例如团队组成、工作流程、项目状态、开发经验等 5. 坐在一起以前产品部在其他的办公区域，从项目组到产品部，要 30 秒的脚程，但双方就是不愿意多进行面对面的沟通。几个月前，产品部终于移到了项目组的办公室。现在国

内项目组、国内产品经理组坐在一起已经有两个月了，充分感受到了“坐在一起”的好处：以前有需求的问题不愿意跑一趟，现在“仰起脸”就可以问清楚，沟通的愿望“大大增强”，而且是面对面，不是通过电话、邮件，效果不错。增加“信任”。以前项目组评估的工作量，产品经理会认为高估了；项目组认为 PO 提出一堆需求，交给项目组，然后就等着验收，太轻松了。但现在坐在一起，

每日忙忙碌碌，大家心里都有一杆秤，PO 和项目组的关系很融洽。项目组和 PO 每天都面对同一个白板（以前产品部由于在另一个办公区，也很少到项目组看这个白板），项目信息一目了然，双方沟通的效率是很高的

说明一点：白板区（讨论区）在相对独立的一个区域，这样我们在长时间讨论的时候也会给其他人一个相对安静的环境。我们在实践中有一个体会：在同一个区域环境

中，如果短时间讨论的是和项目有关的话题，对其他人的影响并不大，如果讨论的是与项目无关的话题或者长时间讨论一个话题，周围的人会受到干扰。所以对于后者

的场景，我们会选择在讨论区进行。



一个体会：办公桌之间不要挡板。我们项目组之间就没有挡板，大家坐着就可以聊一下，很方便，也很随意。但是项目组和产品部之间就有一层挡板，感觉不方便，坐

着无法听得很清楚，一般都要站起来。



保证质量我们的做法实践：简单的设计、组对、DoD（Definition of Done）、Coding Review、每日集成、持续测试具体做法： 1. 简单的设计：我们在第一个 Sprint 之前内会做需求的大致分析、系统设计交付物：每一个小项一张（或几张）图即可。我们现在只分析五个小项，结果是五类图。这五张图会在今后的 Sprint 中不断维护。 a、需求的分析（Initial Envision Requirement），目的是获得 High-Level 的 Scope a.1 Usage Model：用户如何使用系统，我们用的就是 System Use Case 的思路 a.2 Domain Model：商业实体和实体之间的关系 a.3 UI Model：目的是确定页面如何流转以及页面的风格，和客户确定。我们现在是做网站应用服务，所以画出了页面的导航图、典型页面的风格，例如登录、查询等。 b、架构的分析（Initial Envision Architecture），目的是获得感觉：大体上讲，如何构建系统 b.1 系统架构 b.2 网络拓扑 2. 组对（目的是为了整个团队可以对产品负责）这里的组对是：如果一个功能需要若干人完成，由业务熟悉的和业务不熟悉的成员组成；新的员工会和老员工一起完成某个功能；关键业务有至少两人完成；熟悉某项

专业技能的和较熟悉这个技能的成员共同完成某个功能（如果是完全不了解专业技能，实践中组对的效果不好）。组对只需要对 DoD 负责，至于形式，是否和 XP 中

提到的结对那样共同操作一台电脑，由组对自己决定 3. DoD（Definition of Done）对每一个功能，都要定义完成的标准，我们是这样定义的： a、功能的细节都是和客户/PO 确认的 b、遵循团队认可的系统设计，对数据库表的修改得到团队的认可 c、代码 Check-in 前进行了代码分析（目前我们用 FindBug）（不是硬性规定） d、开发人员完成功能最主要验收标准的测试 e、 QA 完成验收测试



#d、#e 分别对应于白板中的“开发完成”和“验收完成”，目的是为了发现开发团队对代码的质量和态度 4. Coding Review 我们做 Coding Review 涵盖的方面：Coding Standard、经常出现的技术问题、获得关键业务数据如何做：如果有需要，随时都可以做，两个或者几个人坐在一起就可以。但我们会有一些制度保证团队在一起做，更多的是分享技术，使整个团队少走弯路，同时达成

的标准、方案也容易被团队接受，并在今后的编码中实施。具体我们在 Daily Meeting 中做，每 2 天一次，会在 40 分钟左右，每次轮换 2 人展示其最核心的一段代码

（不超过 100 行），大家来 Review a、 Coding Standard：Java 标准的编码规范有很多，我们根据团队的选择，从最需要的地方开始。例如我们最开始的编码规范就是仅仅要求每一个方法要有说明 b、经常出现的技术问题：异常处理、数据库的操作等是否符合系统设计 c、获得关键业务数据：这里指的是获得数据的 SQL 语句以上三点的风险在 QA 的测试中很难发现，所以选择用 Coding Review 的方式事前发现。 5. 每日集成、持续测试 Check-in，update 的代码在 CVS 上的操作，每天都会进行。但一般在 Sprint 开始的第二周，就会有一些功能开发完成，此时我们开始做每日集成。具体的做法是： a、每日集成的触发是第一个功能开发完成 b、每日集成开始后，每天早上集成部署在测试平台上，PO 做 Feature Review，QA 测试完成的功能，并将 Bug 记录在 Bug 管理工具中（我们用的是 Mantis）。开

发人员进行修改，并在第二天早上重新集成部署在测试平台上。QA 验收测试的触发：功能开发完成。如果仅仅是功能中的若干任务完成，QA 不介入测试。 c、 QA 要维护测试数据库，并在开始每日集成前准备好。例如初始数据库、为统计准备的数据、为性能准备的数据等。好处： a、 QA 的验收测试是增量递进的，而不是最后开发人员完成所有的功能后再介入测试 b、开发、测试会按照优先级最高的功能逐个完成（完成的标准是验收测试通过），这样可以避免所有功能都完成了 90％，但没有可以提交的产品… 所有的实践，我们只是从团队认为现阶段最需要的一个或者几个“点”实施，逐渐改进。关键是坚持和不断改进。



32 人的 Scrum 团队我们在 2009 年初的时候研发部只有 9 人，做一个项目，部门有一个总监。我是在年初的时候加入的，在这个项目组中开始实施 Scrum。目前部门已经有 32 人，同时

进行 3 个项目。目前的人员架构是这样的：产品部 6 人，每两个负责一个项目研发部 32 人，分为 3 个组，每个组的角色包括：PM、架构师、DBA、美工、开发人员、QA，DBA、美工不是每个小组都有。其中一个小组应用了 Scrum，另外两个

小组还是更接近于瀑布的开发模式，PO 和 Team 之间是需求规格说明书在传递需求。目前暴露的问题是： 1. 产品组之间的沟通太少，产品之间无法形成有效的关联、组合，没有清晰的公司级别的 Product Roadmap 2. 项目组最多只有一个架构师，每个项目的设计层次不高，同时项目组之间的技术很难复用 3. 没有清晰的公司级别的产品平台，项目维护成本高。例如有的项目组利用了 CMS（content management system）发布网站内容，有的还是在程序中实现… 4. 瀑布式的开发模式，平均开发周期为 3 个月，其中一个项目失败了，原因就是需求阶段由于整体需求复杂，需求分析不细致，国外 PO 看到了初步的需求分析，认

为没有问题，但太多的细节不正确，但又没有 PO 的及时确认，在项目快结束的时候发现已经晚了。组织架构见图（多团队 Scrum－改变前）和管理层沟通了敏捷开发的整体思路，研发部和产品部的组织架构改变为： 1. 产品部增加一名总监（CPO），负责公司层面的产品思路，整合三个子产品 2. 研发部的三个项目以敏捷开发为开发模式，原有人员不变，PM 兼任 SM 的角色 3. 架构师和 DBA 成立架构师团队，架构师团队根据产品部的整体产品思路，提出并实现公司层面的技术架构（此时每一个项目组需要一个高级开发人员参加）。公

司所有产品在这个架构平台上进行开发。这样的好处是：公司整体的开发成本、维护成本降低，质量提高。同时架构师和参加架构开发的高级开发人员在项目组内

可以快速将架构平台应用在本项目组。在 Release 开始的时候，由“架构师团队”完成 1~2 个 Sprint 以完成系统级的架构，然后架构师团队的成员回到自己的 Scrum团队进行每日的工作。

4. QA 成立 QA 团队，主要的目的是为了整合研发部 QA 的资源，推出更加高效的测试方法、测试工具 5. 三个项目组的 PM（SM）以 Scrum of Scrums 的方式，每周（需要的时候随时）以会议的方式沟通 30 分钟，主要是产品间的整合、项目组见资源的协调、遇到的

Impediments 如何解决等 6. 开发流程：在新产品有了构想之后，架构师团队先花 2 周进行架构平台的设计和调整，然后再分子产品在不同项目组中进行开发。（Agile Modeling 模式） 7. 美工组，负责公司所有产品的界面（页面）设计，最大的好处是页面风格统一，页面层的技术可以共享，同时有利于公司的产品宣传和产品形象。



具体的组织架构见图（多团队 Scrum－改变后）



经验总结 1. 对于非功能性的要求如何处理 a、对于性能、用户体验：我们网站的用户分为管理员和最终客户两种。管理员已经做了沟通，他们明确提出用户体验不是重点，业务的正确性是第一位。对于管理员

涉及的功能，按照功能、性能、用户体验排列测试优先级；对于最终客户，由于业务数据量小，按照功能、用户体验、性能排列测试优先级。 2. 如何开始 a、从最简单开始，小步操作 b、得到团队的同意重要，得到领到的同意同样重要，特别是 PO 的工作方式、激励机制等方面 3. 如果在 Sprint 中遇到重大的需求变更，而且一定要实现，如何做？ a、直接取消此次 Sprint，代码回滚到上个版本 b、临时中断此次 Sprint，发布已经完成的功能。为了让临时中断的 Sprint 对项目的影响最小，现在的做法是将 Sprint 中的 backlog 中的故事（功能）one by one 或者

group by group 的完成，而不是所有的 features 同时并发完成。 4. 如果资源临时性短缺，又要完成同等数量的功能，怎么办？

我们的做法（按照最有效的方式排序）向直接领导反应，争取部门内部的资源协调到外包公司临时性租人，在公司的环境和团队一起办公，而不是将模块外包奖励内部员工推荐猎头招聘广告（报纸、网站…）

5. 在项目初期，所有的成员最有的是激情，这个时候最容易建立流程和规则。过了这个时间，再要建立流程和规则就很难了。 6. 如果 Sprint 失败了（例如质量问题），怎么办？ a、如实沟通失败的原因，特别是流程的漏洞、管理的疏忽等，不是泛泛的，而是落实到诸如异常流程的测试用例不足，coding 没有 review 导致变量类型定义有问题，

应该是 long，但定义为 int，黑盒测试很难发现等等



b、制定切实的改进措施，不但要解决发现的问题，而且要有更长远的计划，如何提高代码质量、测试质量、发布质量，并和管理层进行沟通。其实某次失败对于管理

层不是最担心的，因为管理层都会留出 buffer；管理层最担心的是不知道下一次或者以后产品的质量是否会保证。 c、要保证下一次部署不会出现已经发现的问题。一般新的问题容易被接受，是因为大家都知道改进有一个过程；但如果已有的问题再次出现，信任只会一点点被减弱 d、更多地让管理层了解实现的过程，特别是一些关键节点，例如和产品部的需求确认，研发部提出的问题在 sprint 结束前 5 天才得到确认，间接影响了代码的质量。

不要最后给管理层“surprise”，而是在过程中除了及时沟通风险，还要把关键的过程透明化，这样真出了问题，管理层也会有自己的判断，而不会只从结果来判

断。 7. 对每一个 Sprint 的故事，我们在 Sprint 结束后会保存在 ScrumWorks 中。但同时我们会维护一个产品的需求说明书和设计说明书，每一个 Sprint 结束后会更新这

两个文档，以保证所有人对产品的需求和设计有一个全面的了解。 8. 和 PO、客户保持良好沟通的一个办法：团队和 SM，在项目进程中常常跟 PO、客户讨论怎样把项目做好，对于 PO 的需求提出自己的改进观点，有时候往往增

加了团队实现的难度，但使得 PO、客户认为大家是在一起努力，特别在对团队工作量的评估上会更加尊重团队的意见… 9. 我们的文化提倡：如果产生了影响交付质量的问题，团队就要停下手中其他的工作并解决这些问题。一旦团队觉得 sprint 评估效率太低，没有达到当初预期的目标，

那么我们会中止评估，进行头脑风暴，讨论如何才能做的更好，并按照一个既定的日程来指导我们减少在代码审查上花费的时间。如果在持续集成或者性能测试

环境设置上有问题，那么我们就要停下来修复它们，然后再进行其他用户故事的开发。如果我们完成了很多用户故事，但是功能测试人员没有来得及进行测试，

那么我们就等所有已开发的用户故事得到测试团队认可，然后再来开发新的用户故事。 10. 我们如何在迭代过程中仍然关注 Big Picture

在每一个迭代中，团队经常会专注在本次 Sprint 的功能，在讨论时会常常忽略掉实现对架构的影响，实现对整体业务的影响。而这些特别在多个 Sprint 之后，会越

来越突出，我们是这样做的：

业务层面的分享做法：每个月管理层（具体负责研发、产品的副总）会向所有团队成员分享目前的业务情况，特别是： 1) 强调公司的业务发展的目标以及目前业务的发展状况 2) 到目前为止，业务发展的机会和挑战是什么？ 3) 谁是我们的客户？我们的产品可以给客户带来哪些价值？ 4) 谁是我们的竞争对手？他们的优势在哪里？



产品层面的分享做法：将一年内产品的路线图按季度列出，每个季度产品需要完成的主要功能。在 Wiki 中展示。

技术架构层面的分享做法：将产品的整体系统架构、网络拓扑列在一个白板的上部，并保持；白板的下部是讨论 sprint 期间功能的设计。系统架构的白板部分一般是不擦除的，只有在必要时才

做修改；Sprint 内的设计是可以经常擦除的。好处：团队在分析功能时，至少脑袋里可以有一根弦，这些功能是否真的和业务发展有利？如果我们换一种方式做，是否一样会带给客户价值？Sprint 内功能的优先级是否

符合产品路线图？Sprint 内功能的实现是否对整体系统架构有影响？本来开发团队会更关注于技术，如果没有业务、商务、市场方面的信息及时分享给开发团队，久

而久之，开发团队将彻底对市场失去反应，更谈不上站在用户的角度着想。

11. 我们为什么要用“变更－燃尽柱”？坦白的说，这个工具（burndown bar with changing scope）也是国外的同行首先使用的，我只是照搬而已。对“变更－燃尽柱”有一些基本的介绍：

燃尽图介绍了剩余的工作量，但没有介绍 scope 的变化对项目进度的影响；“变更－燃尽柱”不但介绍了剩余的工作量，而且清晰的反映出剩余的工作量与

Velocity、changing scope 之间的关系。例如燃尽图发现剩余的工作量有明显增大，但不知道是 Velocity 降低了，还是增加了功能所致，但“变更－燃尽柱”可

以反映典型的“变更－燃尽柱”参考图（典型的“变更－燃尽柱”）,项目每日的 Velocity 在 Baseline 之上反映（此时同燃尽图），相邻柱子的 Baseline 之上高度差

就是完成的工作量；Scope 的变化在 baseline 之下反映，在 Baseline 之下的柱子长度就是与 Sprint Planning 定义的 Scope 相比增加的功能 “变更－燃尽柱”可以结合 Velocity 以及 changing scope 推测出可能提交的时间，这为决策提供了很多的帮助。例如图“变更－燃尽柱－1”，如果没有新增

的功能，会按照计划在 A 点提交，但如果新增了需求，则保持资源、Velocity 不便的情况下，会在 B 点提交；如果需求持续增加，例如图“变更－燃尽柱－2”，

则会在 C 点提交。这样会给项目的管理者提供信息，在资源、提交时间、Scope 之间做平衡。单纯的燃尽图不容易做到这一点。 “变更－燃尽柱”的一般操作、查看原则：

任何任务完成后，Baseline 上面的柱子高度会降低当功能重新评估工作量时，Baseline 上面的柱子高度会降低或者升高当新的功能增加时，Baseline 下面的柱子高度会升高当功能被移除时，Baseline 下面的柱子高度会降低

参考文章：http://www.mountaingoatsoftware.com/alt-releaseburndown



12. 截至目前为止，发现的最有效的实践是什么？我们用过很多的 Scrum 的做法，包括一些 XP、Agile Modeling 的做法，发现有两个做法很有效：

Acceptance Test，由产品经理、QA、开发人员、SM/PM 共同讨论商定 DoD（Defination of Done），最核心的是通过 Acceptance Test、build 成功。

我们现在的开发团队无论采用什么形式开发（coding review、Junit、FindBugs、Pair Programming），什么形式沟通（Daily meeting、burn-down chart、retrospective…），

上面的两点是目标。团队可以根据自己目前的能力来选择各种方法实践的程度，方法是手段，要为结果服务。



教训总结 1. 实施敏捷开发最大的障碍就是缺少 Trust

在刚开始实施 Scrum 时，如果你的 Commitment 没有承诺，两次之后，Trust 将丢失。看看我们的教训：公司要求快速提交新产品，但短的周期导致需求经常变化

（开始就没有清晰的思路），开发人员和 PO 的沟通不好，想当然开始编程，同时也没有必要的设计讨论，做出的产品和需求不符，同时质量也有问题。公司的管理层

追究责任，PO、研发部、工程部都在相互推脱，最后演变为设计严谨的流程，各个部分之间必须要有清晰的交付物。从公司的角度可以从责任和流程来控制产品，从

各个部门演变为标准的 waterfall 管理：PO 设计需求，研发部和 PO 明确需求，做设计，提交开发计划。研发部为了不承担开发与需求不符的责任，在 PO 和研发部签

字需求之前，不做任何的设计、编码，而 PO 又不可能将需求设计的非常完美，双方在扯皮，其实两个部门都知道这样做不是最佳方案，但不愿承担责任（一旦承担，

成本太高，或者没有绩效工资，或者失去职位...）。我们是这样做的：降低 Sprint 完成的功能数量，提高质量，增加各个环节的透明度，例如如何评估工作量、项目进展、风险及时沟通等，重新建立信任

2. 项目成为 SM/PM 的项目水平很高的员工未必能做好项目经理，因为从某种意义上，你可能太相信自己了，你不放心，你不相信你的项目成员和你一样能把工作做得很出色，所以所有的事

情你都想自己干，但项目内容实在太多，你忙不过来，你累得半死，你的项目成员在旁边却无事可干，干着急，帮不上忙，偶尔帮上了，还被你臭一顿。只有无限同情

地看着你，看着这个可怜的所谓项目经理。久而久之，项目变成了你一个人的项目，项目成员成了看客，你天天埋怨底下这帮人真笨，没本事，什么都要靠你自己，项

目成员天天想这个项目经理实在没水平，根本不会安排工作，跟着这样的人，完全是在浪费时间，自己也一点没有成就感。还好这不是我们项目组犯的错误，但确实是很多项目组容易犯的错误

3. 客户沟通不到位这个问题导致快上线了，客户认为的关键功能没有实现。产品开发之初，公司没有产品经理（PO），也没有敏捷开发模式，完全是业务部门和客户（移动总部）直

接沟通，然后反馈给研发部门。当时的问题是业务部门没有时间和研发部门沟通，往往是一页纸的需求，细节也没有和客户沟通清楚。后来公司成立了产品部，业务部

门把需求反馈给产品部，由专职的 PO 和研发部沟通需求。确实，需求非常清晰，研发部的质量也不断提高。但是，最大的问题出现了：客户的需求经业务部门转述后

偏离了客户的本意，产品部又没有和客户直接沟通，Sprint 之后的 Demo 业务部门也没有和客户沟通，需求的偏离在不断的积累…在敏捷开发中，最终客户必须要参与

到开发过程中，特别是 Backlog 和 Demo。PO 不代表客户，特别是 PO 不是和客户直接联系时。

4. 没有好的技术架构产品开发之初，为了尽快上线，产品的技术架构、性能、负载均衡、高可靠性等均没有考量，总认为可以不断的重构，但实际上公司根本不会给团队一个时间去做重构，

不断的业务需求占据了团队几乎全部的时间，于是脆弱的架构越来越弱，完成一个新的需求需要越来越长的时间。现在总结一下，架构的高扩展性和稳定性是最高的优



先级，可以满足业务需求不断扩展。网站的性能是次优先级，特别是登录前的静态页面。CMS（content Management System）也是很重要的，最好在项目的前期就

做，可以选择外包的方式，否则大量的页面修改，要根据发布流程，业务部门会不断提出申述…所有这些需要在 Sprint0 阶段就要考量清楚，觉得 Agile Modeling 确实

是实用的。 5. 曾经遇到的一些非常重要的坏气味（Bad Smell），有了这些迹象，我们需要停下来解决这些问题，否则就会越来越糟外部商务的迹象：

提交给客户的质量是不能接收的，客户很不愿意升级版本，因为害怕会遇到无法预计的一些 Bug 给客户提交新功能，需要越来越长的时间。这个问题有可能产生于：功能的实现依赖于特定的团队目前缺少的资源，例如技术专家；测试周期太长；功能必须改

变现有的系统架构，而系统架构耦合性太强。客户不使用我们提供的功能。这个问题可能产生于：客户开始并不清楚自己需要什么；需求来自于市场部门的预测；功能使用的频率低于我们的预期；软件研发的成本太高。这个问题可能产生于：开发周期太长；成员成本太高

内部开发的迹象： “我们”和“他们”的文化。产品部、测试、开发等不同的部门相互指责，没有一个共同团队的感觉客户在签合同后没有机会修改需求。负面影响：特别在国内的垄断客户（例如移动），即使签了合同，也一样会强势要求修改，如果没有过程中给客户以修改的

机会，最后被动吃亏的还是我们。即使我们要求下一版本修改，可能客户就不会给我们下一次的机会没有直接和固定的客户。这个问题经常发生在以下的场景：做产品的公司；客户没有时间参与开发过程；管理层大吃一惊。这个问题产生于：项目的过程不透明资源瓶颈，好的资源被多个项目同时使用非常多的 Bugs 在 Release 之前需要一个没有功能的迭代：加固。加固的目的其实是做系统级测试，但需要发现和修改之前所有迭代的 Bug。这个问题产生于：每一个迭代都没

有达到“Potentially shipped” 没有经常的“集成”。负面影响：不能及早得到反馈，不能及早发现技术风险

6. Sprint Planning，需求没有更大程度的细化在 Sprint Planning 会议中，PO 要和团队讲清楚 Story 之后的逻辑，但很多时候不会涉及界面展示，还有非常多的异常处理。是否要全部细化？理论上讲，团队可以在开发过程中和客户、PO 确认细节。我的经验是：看 PO 是否尊重团队的工作。曾经有一些经历，就是 Planning 会议的时候界面展示大致说了一

下，团队当时能想到的异常处理进行了讨论，没有想到的就过去了。团队承诺了要实现多少多少的功能，但在实现的时候 PO 提出的需求细节过于难实现，或者团队实

现的方案不被 PO 接受，PO 会以 Common-Sense、用户体验来拒绝验收；当你提出减少 Scope 的时候，PO 会说难以接受，因为团队已经承诺了…大家的沟通会很

不愉快。



团队现在是这样做的：不会轻易承诺，一般会将 Planning 会议延长一天，将尽可能多的细节敲定，例如原型、异常处理等。虽然 Planning 的时间长了，但中间沟通的

风险小了，团队的承诺更容易兑现。在整个公司实施 Scrum/敏捷开发的初期，很多环节都会出现问题，适当调整 Scrum 的理论，会让 Scrum 进行下去。



典型问题（一） Q1：技术负债在敏捷团队中会快速的膨胀。 A1：由于敏捷开发过程没有充足的事前（up-front）设计，技术负债是不可避免的，虽然可以通过 TDD、连续集成、重构减轻症状。同时敏捷开发者提倡的原则(比如

S.O.L.I.D 原则，Clean Code,Implementation Patterns )都能帮助敏捷团队避免过多的技术负债。传统的瀑布式开发技术负债是较少的，敏捷开发不是瀑布式开发的对

立面，必须在实践中结合两者的优势。根据国外专业网站的调查，在敏捷实践中超过 60％的团队都会进行一些事前设计以减少技术负债。Agile Modeling 个人觉得是

可以借鉴的办法之一。 Q2：敏捷软件开发团队会想当然地认为每个团队成员都专业，称职并富有责任心。如果事实不是如此，项目开发很快会变得举步维艰。 A2：敏捷开发团队的气氛应该是：勇于承诺；团队成员互信互助，不断追求进步，需要的时候寻求团队成员的帮助。责任心不是每个人都会有，这和性格、素质和既

得利益有关。在实践中团队成员不可能都专业，称职并富有责任心，所以实践中的做法是：首先努力找到专业有责任心的人，其次是创造团队气氛，再次是建立绩效考

核（见 6-25Bolg 文章：如何对 Scrum 团队进行绩效考核），能力较弱的的团队成员会感受到来自其他成员的压力，要不然尽力做好，要不然只有调离团队。 Q3: 由于对敏捷开发实践的错误理解，导致团队不合理地频繁交付，疲于奔命。 A3：我们导入敏捷也是受种种因素（客户环境，团队对敏捷的认识程度，成员的能力）限制的，只能是逐步导入。很多敏捷项目确实存在过于频繁的交付，那是由于

人们迫于各种压力，“好大喜功”的天性而忽略了敏捷其实一直在强调的“根据每个迭代能够实际发布量”（也就是真正能够达到 Done 标准的工作量）来调整下一个

迭代工作量。如果团队不能自主调整工作量，这其实已经偏离了敏捷。公司和团队对敏捷开发的正确理解是解决这个问题的根本。 Q4: 实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。 A4：在不成熟的组织中导入敏捷实践只能是逐步地导入，同时应该是在敏捷宣言的原则下找到适应组织目前状态下的做法。具体的做法，我们的实践体会已经在博客

中有共享，例如（5-8：没有自动化测试，没有 TDD，没有连续集成，如何保证质量？，5-19：没有自动化测试，没有 TDD，没有连续集成，如何保证质量？续）等。 Q5: 绩效差的团队成员很难在高度公开的敏捷团队中掩饰自己能力的不足。好的团队往往能够采取一定的措施来帮助这类成员。但如果没有采取措施，这些成员往往

会想方设法通过消极怠工来掩饰自己能力的不足。 A5：态度决定一切！敏捷团队所不能容忍的是那种故意偷懒的成员。团队成员应该承认个体差异，努力帮助较弱的团队成员，但较弱的成员必须表现出：a)主动 b)努力 c)对结果负责。这三点同样重要，“主动”包括主动需求帮助，如果有 delay 主动沟通等。如果不是这样，只能调离团队。 Q6: 敏捷团队容易过份关注眼前的短期目标，而忽视长期的战略目标。尽管在短期内能够取得成功，长期注定还是会失败。



A6：过分强调了 YAGNI（You Aren't Gonna Need It），因而在早期忽视了一些战略性的目标，尤其是业务需求目标，从而导致后期重构十分困难。这其实在很大程度

上是一个平衡的问题，怎样在 YAGNI 与预先设计之间做平衡。预想开发是个迷人的陷阱，在编码时时刻提醒自己：它究竟是会让代码变得更好，还是平添复杂度？同

时，需求设计时也必须要考虑某个功能虽然在目前是不需要的，但可能在可以预计的时间商业价值很高。最好的方法是在产品开始之初做好 Roadmap，而不是想一步

做一步。设计也要根据 Roadmap 做一些预先设计。 Q7: Product Owner 承担了太多的责任，不堪重负，从而成为团队的瓶颈。 A7：敏捷极大地缩短了从需求到软件的周期。再也不会出现Product Owner等上6个月或者更长的时间，结果发现做出来的并不是自己想要的东西的情况。Product Owner可以在短时间内就能看到软件，及时作出调整，因此敏捷极大地减少了开发成本以及相应的机会成本。公司高层的支持也是十分必要的。没有高层的承诺和授权，不可

能组成全功能的团队。的确，和传统开发相比，PO 需要更大的热情和精力，同时也需要更好的沟通能力。在实践中，往往 PO 是由两个人 Peer 组成的。 Q8: 敏捷的效用被过度夸大，大家的期望值太高，很多人认为导入敏捷能以最小的投入解决实际开发中的所有问题。 A8：实际上，敏捷开发不是以最小的投入解决开发问题，也不是使开发效率大幅提高，而是快速地得到可以工作的产品（功能较少，但核心），快速的得到反馈以改

进产品，始终以市场/客户的要求为每一次推出产品的原始驱动力，这样产品的 ROI（Return of Invest）才是最高。客观的说，和传统开发方法比较，Invest 不见得是

最小的，但 Return 却是较高的。 Q9: 可能出现另一种形式的“相互诟病”。成功的敏捷开发团队一般不会成为产品开发的瓶颈，因此其他部门不能以这个为借口来指责开发团队，但是这有可能进一

步演变成为政治游戏。 A9：尽早与其他部门沟通，大家的最终目标是一致的，各个部门应当一起寻找生产系统的瓶颈，然后努力突破瓶颈。基于这个共同目标，各个部门一起对流程进行修

改，就会减少相互诟病。要想最终的目标是一致的，公司的绩效考核中的 KPI 就应该以此为中心。 Q10: 当 Product Owner 开始决定开发的方向，他就会被过度授权。敏捷开发中缺乏足够的审查和平衡机制。 A10：Product Owner 应该控制产品发展的方向。Product Owner 应当熟悉业务，明确他最终想要什么。尽管开发团队要利用技术手段，提供解决方案，满足业务需求。

但作为开发团队不应该对业务方面干涉太多。需要说明的是，在实践中公司的管理层/老板其实是最大的 Product Owner，所以被任命的 PO 在产品的决定方面必须和

公司的管理层/老板有充分的沟通，这里的沟通技巧主要是和上层的沟通技巧。 Q11: 敏捷理论很吸引人，但失败的案例非常多 A11：敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同。这需要有更多实践经验的培训

师进行培训或者直接加入到团队中。



Q12：为什么 Scrum 团队推荐为小型规模 A12：在 Scrum 实践中，团队的交流和协作是至关重要的，让我们看一下相互交流的成本：C ＝ N*（N-1）/2，其中，C 代表成员交流的渠道（Channel），N 代表

成员的数量。如果成员的数量为 5 个，则团队交流的渠道数量是 10；如果成员的数量为 8 个，则团队交流的渠道数量是 28；如果成员的数量为 10 个，则团队交流的

渠道数量是 45；如果成员的数量为 15 个，则团队交流的渠道数量是 105；如果成员的数量为 20 个，则团队交流的渠道数量是 190；如果成员的数量为 25 个，则团队

交流的渠道数量是 300；如果成员的数量为 30 个，则团队交流的渠道数量是 435。如果团队成员的数量超过了 10 人，例如 20 人，30 人，可以使用 Scrum of Scrums的管理方式。 Q13：小型企业 Scrum 实施的典型障碍是什么？ A13：1）. 会议规则没能被遵循；2）. 产品远景和 Sprint 目标不清晰；3）. 没有产品负责人负责回答提问；4）. 产品 Backlog 未能按商业价值区分优先级；5）. 并不是所有负责交付产品的人员都是团队里的成员；6）. Scrum Master 还要处理其他任务，不能集中精力；7）. 团队人数过多（多于 7 个开发人员）；8）. 团队没有

能坐在一起工作的空间；9）. 团队的 Sprint Backlog 混乱。（摘自 Scrum checklist） Q14：经常沉浸在细节中考量。实践很多具体的措施，但有时候会被环境所左右，慢慢忘记了敏捷最基本的思想。 A14：慢下来，看看敏捷的核心价值观：沟通、简单、反馈、勇气、尊重 Q15：传统思维和敏捷思维的区别是什么？ A15：传统思维敏捷思维是员工的问题是流程的问题针对个人进行考核针对流程进行考核激励并管理员工清除员工面临的障碍，开发员工谁犯的这个错是甚么让错误发生了了解并做好你的工作我的工作如何配合其它部分为了更好的预测，做个全面的分析只有频繁的预测才是可依赖的方法 Q16：客户需要大量的文档，好像和“Just Enough”的原则有冲突？ A16：没有冲突。敏捷的目的是为 Business Value 服务，如果客户需要大量的文档，说明“大量的文档”为客户可以带来价值，“Enough”此时就是“大量”的标准。

一般这样的场景需要在团队中增加“文档编写者”这样的成员。我个人的实践经验：除非文档的工作量非常大，否则 SM 会兼任需求的文档编写，架构师会兼任设计的

文档编写者。



Q17：如何确保自组织团队成功 A17：Dave Nicolette建议可采取下列行动

1) 明确定义边界：要是做不到这一点，团队就会搞不清楚自己对自己的管理能到什么程度，也不知道什么时候应该请求管理层的帮助。没有对边界的定义，团队就会

过于小心谨慎，在没有得到许可之前，他们不会做出任何决策。 2) 容忍错误，并给予时间学习：管理层不应在出现第一个问题时就跳出来。他们应该让团队从自己的错误中吸取经验教训，并自己选择修正行为。 3) 让团队始终感受到挑战，但不能让他们筋疲力尽：管理层应该注意团队的技能水平和限制。他应该为团队提供足够的挑战，从而保持团队处于学习和成长的状态。 Q18：Scrum 开发方式面对定价项目的竞标优势 A18：客户可以在任何一个迭代结束的时候停止项目，仍然可以得到可以上线的产品。同时 Scrum 对于变化的抵御能力较强，任何一个迭代开始之前，客户都可以修

改需求，而且无需付费。 Q19：Scrum 在实施过程中通常会遇到的问题 A19： 1）Scrum 的实施必须以公司的企业文化为背景，必须和企业文化相融合，否则很难成功。 2）没有人能绝对预测以后会发生什么事，尤其是情况不明的时候。所以在每一个迭代做 estimation 的时候，预估不准确是正常现象，尤其是在前几个迭代。 3）很多情况下，在业务功能开始实现之前会做一些基础设施的建设，这些工作在前几个 iteration 会占较大比重，而且优先级比较高，但是同时，每个迭代也要进行业

务功能的发布，因为基础设施需要实际的业务功能来验证其正确性。 Q20：敏捷开发的过程如何提高了软件的质量？ A20：软件的高质量表现在软件的缺陷少；软件实现的功能是客户真正想要的，而且，即使商业需求上发生了变化，高质量的软件也容易进行扩展和修改。软件的缺陷

少，有一个做法是更早的发现风险，见图（更早的发现编码风险）；软件实现的功能是客户真正想要的，是由于短的交付周期、客户参与、团队高频率的沟通等带来的。



典型问题（二）

什么样的领导适合敏捷项目？

1）. 自我反省意识一个好的领导自己最了解自己。特别的是，领导知道自己在公司或者系统的地位，以及自己的优点和缺点。领导人有规律的检查自己的生活和价值观。这种特征最

适合 Agile，因为反省是 Agile 最核心的一个原则。 Agile 领导的价值观鼓励他们不断的去做出提高。自我反省意识所产生的一件事情，就是判断什么时候去领导，什么时候不去领导，什么时候让下属领导你的能力。

2）. 信仰和勇气勇气意味着拥有力量和毅力寻找并沿着正确的路线前进；在你研究不同的选择，分析你所做行为的后果，并坚信你为公司、团队以及投资者所做的是正确的方法之

后，就可以做出满意的决策。知识来自于应用战术，智力，经验以及对情况的判断。优秀的领导人都善于展现自己的勇气。在计划驱动的公司内，追求的目标就是不顾一切代价去遵循一项计划。一个人所能做的最糟糕的事情，就是偏离这项计划。这会导致对项目状态错误的评价。被人

报告落后是一个经理人的耻辱。如果你觉得你落后了，那么你就会迫使你的团队加班加点以赶上进度。每一周，领导人都会宣布团队在沿正常轨道运行。一周以前，我

们计划向领导报告，他的团队落后了，并需要两到三个月以完成剩余的工作。团队如果在连续两个周期内都失败，问题有两个。首先，领导没有勇气说出真相。第二，公司的价值不允许他们传递坏的消息。如果你准备去领导一个 Agile 团队，

你需要拥有勇气说出事实，并鼓励你的团队成员也说出事实。为了让这一切变得简单，公司必须赞成允许 Agile 团队存在的价值。 3）. 创新

创新不是简单的做新的和不同的事情。它不是新颖性。找到解决问题的更加有效率、比以前的方式更加有用的新方法才是创新。创新的一个主要方面是产生新的注

意，选择以及可能性。创新性领导帮助团队产生选择并评价它们的价值。 4）. 好奇心

一个好的开发团队以及他们的领导都很有好奇心。对他们来说仅仅执行一套方案并不够好。他们通过问“如果这样会发生什么”的问题来创建更好的软件系统。他

们想要知道系统是怎样工作的，为什么事情以一种这样的方式发生，怎样做的更好。只要在满足他们的好奇心的情况下，他们才能将工作做的最好。 5）. 倾听的能力如果你“倾听”的话，需要理解以及与另一个人的实际交流。假设有人提出了更改进程的建议。如果你听到了这个建议，而你又是一个好的倾听者，那么你需要提供建

设性的回馈。这个注意也许很好，你想要鼓励他继续下去。或者这个注意需要进一步改进。如果你认为这是一个很糟糕的注意，那么你需要让他知道原因，并提出改进

的方法。



大型企业 Scrum 进行敏捷改进时障碍是什么？

Craig Larman, Bas Vodde 提出了自己的观点排除组织障碍失败

Scrum 方法的联合创始人 Jeff Sutherland 认为，排除组织障碍失败是大型组织面临的一个主要障碍。无法排除组织障碍的最常见原因是“这是我们一直以来的工作方

式”以及“我们不会改变的，因为我们为此已经投入了很多” 。错误的成本节省和整合努力

在施乐公司推广精益原则方面经验丰富的开发经理 Peter Alfvin 与 Reaktor Innovations 公司敏捷教练部主任 Petri Haapio 都指出，因中央集权部门寻求成本节省和

整合而导致的局部优化是一大障碍。他们列举了几个这种错误努力的事例。第一个是，一个中央集权的工具部门强制规定公司的所有部门都必须使用同一个工具，尽

管这种做法的出发点是好的，是为了节省成本，但由于该“强制性工具”并不适合某类工作，因而至少导致一个开发团体的工作效率降低。第二个例子是，所谓的“家具

警察”强制规定所有部门都使用隔断来标准化办公环境，以最小化成本，结果却导致了对于许多团队来说相当低效的工作空间。另一个例子是，公司的 IT 部门限制视

频会议以降低网络流量，结果却妨碍了依赖这种沟通方式的团队开展有效工作。缺少必要的培训

诺基亚西门子网络（NSN）的全球敏捷开发活动协调员 Sami Lilja 发现一些组织倾向于认为学习是一种时间和金钱上的浪费。这类组织通常教育和训练员工，告诉他

们只在“时间允许”的情况下才会安排他们进行学习。这种扭曲的观点常常导致糟糕的“救火”循环 —— 由于开发人员技能不足造成错误，进而导致匆匆忙忙的紧急修补，

而管理团队又不愿花时间分析造成这些错误的原因，结果就导致了更多的错误。单一职能团体

爱立信上海的专家 Larry Cai 提出职能化组织（单一职能团体）是敏捷实施的一大障碍。单一职能团体容易阻碍沟通，造成部门间的互相指责。局部优化与全局优化

咨询顾问、教练、推广专家（expert facilitator）以及两本关于组织学习图书的作者 Esther Derby 认为，那些提倡局部优化而非全局优化的系统是成功的一个主要障碍。

这类系统的例子包括目标管理（MBO）和预算系统等等。认为仅靠读书就够了

西门子医疗系统公司的前敏捷教练 Mike Bria 认为“DIY 式内部改进”是一个常见障碍。他说，许多人往往在读过一两本书之后，就盲目地相信自己“已经知道该怎么做

了”，而事实证明一知半解往往是危险的。这类组织通常不愿意寻求外部专家的帮助，常常喜欢闭门造车。《测试驱动》的作者 Lasse Koskela 也提到一个类似的障碍，

用他的话说 —— “不知道眼睛向外看”。个人绩效评估和奖励

某大型电子商务网站的培训师（因其要求略去了他的名字），提出个人绩效评估和奖励是他所发现的一个主要障碍。这种古老的做法会挫伤敏捷团队中的开发人员和管

理者，阻碍团队整体绩效的提升，并强化命令控制式（command-and-control）的管理。不切实际的许诺

诺基亚西门子网络（NSN）杭州研发中心的敏捷培训师、一个大型研发团队的部门经理吕毅指出，“承诺竞赛”和不切实际的许诺是最大的组织障碍之一。不切实际的期



望往往会导致抄捷径、持续救火、遗留代码等问题。在本书姊妹篇Practices for Scaling Lean & Agile Development 的 “遗留代码”一章中我们将对此做更深入的探讨。认为敏捷只与开发人员有关

敏捷推广专家 Diana Larsen 与《敏捷回顾》（Agile Retrospectives）的作者 Esther Derby 都提到了一个障碍，即“认为敏捷只与开发人员有关”。许多组织经常错误

地认为敏捷和精益只牵涉到开发人员，而不理解成功的敏捷转变其实需要一个组织内的各个层次上，人们思维和行为方式的转变。银弹思维与表面实施

我们采访过的所有人几乎都提到了某种形式的“银弹思维与表面实施” 是一大障碍。OTI 的创始人、大规模精益产品开发顾问、ObjectMentor 公司总经理 Dave Thomas 对这一问题和现象作了精彩的分析。他说，许多公司错误地将敏捷等同于高生产率（productivity），而非适应性（adaptability）。这一误解，加上受过有效培训的高

层管理人员的缺乏，导致了认为“敏捷就是某种形式的银弹”的误解。而这又进一步地促使某些人相信，任何有意义的实质问题只要通过说一句“我们正在做敏捷”，并据

此采取一系列所谓的行动就能获得解决，而不需要一个组织的领导团队作出深刻理解和相应的改变。具有讽刺性的是，由于这种做法既不会导致任何真正的改变，也不

会获得任何真正的效果，最终这些组织将会放弃精益/敏捷原则，因为“它们不起作用”。与此有关的另一个障碍是，一些人想当然地以为大型产品研发团体的敏捷改进不需要几年的时间，就能迅速获得显著的效果。而事实上，大型组织的显著改进往往可能

需要花上 5 到 10 年的时间（在高层管理者的持续支持下）。突出员工个人而非真正的团队及团队合作的组织文化。

有太多这样的团体，他们实际上由许多分离的、缺少凝聚力的个体组成，却伪装成一个团队，表面上实施了 Scrum，心里想的却是" Jill 做 Jill 的工作，Raj 做 Raj 的工作，等等"。这些组织中的开发团体无法以一个整体团队集体行动，开展彼此的结对工作和相互学习。

管理者与一线员工之间的隔阂。常见的情况是，管理层做出的改变对实际的一线工作没有产生任何影响（或至少没有正面的影响）；同样，一线开发人员所做出的决定，也往往不符合组织的方向。形成这种隔阂常常是因为，管理者没有到实际工作的一线环境中去"实地查看"（go and see），有时候是因为他们已经丧失了这么做的技能，而开发人员又不关心属于自

己岗位正常职责之外的事情 —— 他们在自己的岗位上已经“退休”了。这种隔阂会导致浅表的敏捷和精益实施，结果是只在管理层面上发生了变化，而技术实践没有任

何改变，或者只在开发层面上发生了变化，而组织本身没有任何改变。精益做法"实地查看"和"担当教练的管理者"（managers-as-teachers）可以帮助缩小这种隔阂。感谢作者：Craig Larman, Bas Vodde

用户故事和用例的选择

Murali Krishna 告诉我们：未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在于每一个用户故事都是一个“可独立分配”的需求（特徵）单位。

要达到“可独立分配”，就要从“用户”如何使用系统来表达用户故事。这样才让你实现到一个能让用户交流，端到端（用户界面到后端）的功能单位。 Murali 想的跟众多敏捷社区的人仕一样——用户故事是最好的选择，并引用 Mike Cohn 写的一篇文章 Advantages of User Stories for Requirements。文中指出：



1. 每一个用户故事都包括三方面：Who、What、Why 2. 写下故事描述，用作计划和提示 3. 故事的对话为故事细节以测试作为细节的记录，用来判断故事是否完成实现如此看来使用用户故事比较好。但又是否如此呢? Alistair Cockburn，另一位敏捷社区内的名家，仍然使用用例，并从他过往使用用户故事的经验中指出所遇到的问题： 1. 用户故事和 Backlog 上的项目不能提供设计师工作所需要的内容脉络——用户在做什么时候情况下做这事情，这行动的内容前文后理，以及在这一刻的高层目标。 2. 用户故事和 Backlog 上的项目不能提供项目团队所需要的“完整性”——我发现开发队伍对项目估算的故事点随著工作开始以后不断增加，犹如无止境的一样。开发人

员及项目赞助人也为此感到同样的沮丧。到底项目确确实实有多大呢？ 3. 跟完整性有关的是，用户故事和 Backlog 上的项目不能提供一个合适的机制来考虑到未来工作的困难程度（原则上他们可以, 只是实际上他们不行）——我不断收

到这样的投诉，「我们问客户 (产品负责人)一条问题，他/她用上两星期时间才回覆我们。我们找错了人吗？」不是，他们没找错人，他们是过程出问题——有些问题

需要长时间研究，因为不同部门和用户组要找出什么是正确，平衡各方需要的答案。分析员看著用例中一系列的伸延的形势可以找出那一个较容易，那一个较困难，

再进一步进行相关的研究。用户故事和 Backlog 项目未能及时达到适合作出来那考虑的粒度——伸延的形势通常要在 Sprint 中才能观察到，这已经太迟。 Alistair 说了「为何不使用用户故事」后，进一步集中讨论「为什么使用用例」。 1. 目标名称列表将系统对业务和用户的贡献进行了最简短的概括，提供给行政人员。这也提供了一个项目计划框架，可用作建立初始优先次序、估计、团队分配，以

及时间的选择。这也是“完整性”的第一部份。 2. 每个用例的主要成功场景能提供各参与者有关系统基本功能的协议，有时候更为重要的是，它可以告诉人们，哪些事情它不能做。给每一项需求提供脉络，这是其

他工具很难办到的。 3. 每个用例的扩展条件可以给需求分析员提供一个框架，可以找出那些可能会用上 80% 的开发时间成本的烦琐细微之处。它提供一个考虑未来的机制，从而客户、

产品负责人、业务分析员可以察觉到一些可能用上时间研究的问题。这些问题应优先处理，让开发团队开始工作时这些资料也同时准备好。这用例伸延形势分析就是 "完整性" 的第二部份。 4. 用例扩展场景提供一些仔细而然往往也是难处理的细节，像编程员常常问到：「你想我如何处理这情况？」（通常回覆却是：「我不知道, 我未想过会有这情况。」）

换言之，这是一个思考、文档纪录的框架，跟“如果……那么……否则”的情况作配对，帮助编程员思考不同的问题。分别在於这是在研究阶段进行，不是到要开始编

程时才进行。 5. 整套用例系列反映出研究人员有详细思考不同用户需要，不同用户在这系统上使用目的，以及一些业务上的差异。这是“完整性”的最后部份。（的确如是，我曾跟

客户详细讨论长达 240 个用例，到最后，我去问她：「这是全部了吗？」她确认了。我们架建这系统，付运，收到应得的费用，而十年后这系统仍在使用。）一如很多人所料，这回事不是黑白分明。我们该如何做好？我们现时在做的到底有用么？只有一个正确方法呢，还是有两个不同的正确方法呢？或者视乎实际情况而

http://alistair.cockburn.us/index.php/Why_I_still_use_use_cases



定？会不会是有些情况下用用例较好，而有些情况下用用户故事较好呢？还是其实没太大分别呢——像用例中（或许）包含多个用户故事而该用例因为一个用户情节

内外都貌似用户故事呢）明白两者分别极为重要。知道分别才可以作出合适的决定。 Scott Ambler 曾经在 <Artifacts for Agile Modeling> 指出两者的分别：

工具通常应用什么时候保存

用例 1. 主要使用需求综述 2. 分析现有系统使用需求

使用需求综述

用户故事 1. 探索用户需求 2. 与项目参与者对话的提示

功能实现后扔掉

很明显两者的使用情况和目的都很不同。甚至有需要，两者可共同使用及存在。文章摘自：http://www.infoq.com/cn/news/2008/08/use-case-or-user-story 感谢文章的原创者：作者 Amr Elssamadisy 译者麦天志在我们的实践中：用户故事是应用在 PO 和客户沟通和 PO、Team 在 Sprint Planning 中使用。我们维护用例，是为了保持系统需求的整体了解。用例描述做了裁剪，只保留了基本事件

流和异常事件流。

实施敏捷，公司文化要如何改变？

在开发层面：允许开发团队和最终客户协作允许开发团队知道更多的事情，包括商务、市场等

产品路线图

更加透明更加现实



产出

看重价值，而不是功能看重经济性（economy），而不是全面的质量，没有任何质量疏漏

什么是企业采用敏捷开发最主要的原因

VersionOne 做了调查，什么是企业采用敏捷开发最主要的原因。调查结果发现：加快进入市场的时间、更好管理变化的优先级是最主要的原因，两项占到了 43％；增

加生产率、提高软件质量，两项占到了 22％，居次席。参考图（企业采用敏捷开发最主要的原因）

采用敏捷开发，企业最担心的是什么

VersionOne 做了调查，什么是企业采用敏捷开发是最担心的？调查结果发现，缺少事先的计划是最担心的，缺少管理控制、缺少文档居其次。参考图（采用敏捷开发，

企业最担心的是什么）

采用敏捷开发，企业最大的障碍是什么

VersionOne 做了调查，采用敏捷开发，企业最大的障碍是什么？调查结果发现，改变企业文化、没有敏捷开发经验的员工以及管理层的支持占据前三甲。参考图（采

用敏捷开发，企业最大的障碍是什么）


图表 1 典型的敏捷团队的 QA 职责需求



图表 2 价值－风险：优先级的判断依据



图表 3 我们如何管理需求的变化




图表 4 我们这样做用户故事


图表 5 增加一个新的需求何时可以发布




图表 6 我们的白板－改进前


图表 7 我们的白板




图表 8 我们这样解决障碍


图表 9 项目风险迹象－实际的工作量和评估的工作量不符




图表 10 项目风险迹象－功能不能全部完成



图表 11 项目风险迹象－高优先级未完成


图表 12 我们这样做 Demo



图表 13 更早的发现编码风险



图表 14 多团队 Scrum－改变前




图表 15 多团队 Scrum－改变后


图表 16 我们这样部署




图表 17 变更－燃尽柱


图表 18 企业采用敏捷开发最主要的原因




图表 19 采用敏捷开发，企业最担心的是什么

Scrum In Practice－201003

Technology

Transcript of Scrum In Practice－201003