火星人敏捷开发手册+2012-08-15

火星人敏捷开发手册

作为培训前的预习阅读。 打印并张贴在公司走廊上。 作为企业内部小组培训教材使用。

目录

火星人敏捷开发手册

Scrum概览

Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。 不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。

在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目。

在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)。产品负责人会逐一挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的变化。 在迭代期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日立会 Daily Stand-up Meeting，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一张“燃烧图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成。

在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。

Scrum是什么意思？

Scrum本意是指橄榄球中的“带球过人”

带球过人需要计划！

 在球场上：在比赛每段的开始，双方都要摆开阵势，并计划本段的进攻/防守路线和策略，教练和队长都可以参与计划。

 在软件开发公司：在每个迭代的开始，团队领导者都应该做好本迭代的计划，尤其是需求条目的优先级排序、选择本迭代的工作、设定必须完成的内容等。

带球过人需要灵活应变！

 在球场上：当哨声响起，尽管队员们努力按照既定计划推进，然而场上瞬息万变，队员不可能实时按照教练或队长的指令亦步亦趋地行事，而是靠平时训练中形成的素养见机行事，达成目标。

 在软件开发公司：在每个迭代开始后，团队领导不可能也不需要事必亲恭地者介入每件事情，而是应该由具体执行的人选择如何去做。团队领导要做好的是协调资源、解决困难、提供指导，以达成目标。

Scrum中既有计划会、每日立会、评审会等计划和管理活动，又有迭代期内的灵活应变活动，是一种轻重结合的敏捷过程。

Scrum敏捷方法一分钟扫盲

产品负责人建立条目化的产品待开发项，并进行优先级排序。

在迭代计划会上，产品负责人讲解本迭代要开发的条目，团队进行估算并放入下一个迭代。

团队在迭代内完成所列需求，每天都开每日”立“会以沟通进度和问题。

在迭代终点的迭代评审会上，团队向产品负责人等展示开发成果。

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册 您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

Scrum敏捷方法中的工作产品

产品待开发项 Product Backlog是从客户价值角度理解的产品功能列表。 功能、缺陷、增强等都可以是待开发项。

一般以条目化的方式描述。 客户和用户必须能够理解。 描述怎样使用而非怎样制造。 整体上从客户价值优先级排序。 总工作量一般需要0.5～10人天。 高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。

冲刺待开发项 Sprint Backlog是从开发技术角度理解的迭代开发任务。

在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。 在复杂的开发环境中，可以把一个产品待开发项分解为Web/后台……软件/硬件……程序/美术……等开发任务。

可工作软件 Working Software是可交付的软件产品。

“可交付”在不同场景下差异很大，应视不同情况提前设定和选定交付标准。比如是否需要测试，是否需要性能优化，是否需要操作手册等等。 在正式产品中可能包括使用文档，甚至是纸质的。在新产品开发的初期，则可能只需要交付勉强可看到效果的产品。

产品负责人、用户代表等负责评审可工作软件。

若一个产品功能只是“差不多完成了”，会被视为不可交付。

，下一版本将于2012-10-15发布在：

敏捷方法中的角色

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册 您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

与

的故事

敏捷角色背后的哲学

Scrum过程-创建和维护产品待开发项（Product Backlog）

产品功能列表（Product Backlog）是一组条目化需求。

产品功能列表必须从客户价值角度描典型的描述方法，就是极限编程中提述，并按优先级排序。

到的用户故事（User Story）。

如何编写产品功能列表

产品负责人创建和维护产品功能列表。

需求必须进行条目化管理，才能进行分配、开发、跟踪，才能描述什么做完了什么没做完。 “客户价值角度”就是描述用户如何使用，而不是描述技术层面如何实现。比如“实现手写输入”“实现游戏排行榜”，而不是“编写数据库底层”。用户故事的语法“作为一个……，可以……，以（以便）……”很好地保证了这一点。

背面

正面

Scrum过程-迭代计划会（Sprint Planning Meeting）- I

迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。

产品负责人逐条讲解最重要的产品功能。

开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。

产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。

产品负责人准备什么？讲解什么？

会前准备：条目化的需求（用户故事），优先级排序，最近1～2个迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。

会上讲解：较难以文字表述的内容，如游戏的文化背景，嵌入式设备的手感，OA系统背后的人事关系……讲解过程中团队可以随时发问，产品负责人要予以解

答。若产品负责人感觉答案没想清楚，可推迟故事的开发，或将故事分解为“已想清楚的”和“未想清楚的”，后者推迟到下一迭代或更晚。

两者关系：准备活动类似电影剧本编写，它导致了这是不是一个好故事的基本问题；会上讲解类似导演说戏，它导致了这个故事我们能不能演好的问题。很多团队错误地认为已经有文档可读了，开会讲解太浪费时间，其实两者缺一不可。

一般一个团队只有70%的工作可以进行正式工作，因此每个人月安排15人天左右即为饱和，新团队则可能低至10人天。

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册 您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

Scrum过程-迭代计划会（Sprint Planning Meeting）- II

迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。

产品负责人逐条讲解最重要的产品功能。

开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。

产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。

团队怎样估算？

共同估算：在估算前不应该指定谁将开发这个故事，而是以接收故事的小组为单位集体估算，每个人提出自己的看法，大家综合。这样才能以集体智慧完成任务。

在估算全程，产品负责人不能离开，因为很多估算差异问题来自于“做什么，做到什么地步”，产品负责人需要予以解答，而不是让团队按自己的理解去做。

共同估算的目的不是一个数字上的统一，而是用集体智慧和知识对“做什么，怎么做”达成共识。

共同估算是共同跟进的基础，若不能共同估算，则后面的“每日立会”几乎不可能正常进行，因为大家只会关心自己曾经一起分析、思考、提问、设计乃至争论过的任务进展的怎样了，是不是和自己想象的一样。

共同估算的最佳方法是“扑克牌估算”，这看似很像一个小游戏，但却是Delphi估算的一个快速方法，同时实现了匿名性与高效性。

Scrum过程-办公环境

开放办公环境是敏捷开发的一个符号。 与传统的开发中“背对背”地躲在格子间里边不同的是，敏捷开发提倡沟通与互动，除了每天的站立会议之外，随时随时发生的沟通也不可或缺。

而在旁边放置一个随时可以涂鸦的白板，则是团队的最爱。

Scrum过程-每日立会（Standup Meeting）

队员认领任务（或由组长协商分发），独立或与别人一起完成任务。

团队内部利用每日立会来沟通进度。

开发团队利用燃烧图来展示整体进度。

如无特殊原因，迭代期内无变更。

什么是每日“立”会？

由于每次会议只持续10～15分钟，人们习惯在工位附近的空地上站着开会，所以被叫做“每日立会”。 每日立会上每个人汇报三个问题：我昨天做了什么，我今天要做什么，我遇到了什么困难。由于小组曾经共同估算任务，所以如果出现偏差，可以沟通出现的问题以相互帮助。

燃烧图（Burn Down Chart）的横坐标是时间，纵坐标是本次迭代所有开发项的剩余时间，若时间到达终点而剩余时间也趋于零，则迭代顺利完成。

如无特殊原因，迭代期内产品负责人不会增加、改变、删除工作项，但却会协助开发人员进行产品功能细化。

Scrum过程-评审会（Review Meeting）

小组向产品负责人展示迭代工作结果。

产品负责人给出评价和反馈。

以用户故事是否能成功交付来评价任务完成情况。

怎样开展评审会？

敏捷开发采用时间盒（Time Boxing）的方法，即限定时间而不限定范围。所以迭代不会延期，因为在迭代终点将放弃未完成的故事。

评审的标准是整个故事是否已经达到交付标准，而不是从其中分解出来的任务完成了多少，因此若一个故事“差一点就完成了”也算没有完成。

常常发生很多故事都已经开始开发，但都差一点完成的现象。因此应按迭代内的优先级逐条开发和交付故事。一般总是优先开发MoSCoW方法中必须完成和应该完成的故事，再考虑可以完成的故事。

一般在迭代计划会上设定每个故事的完成标准，如是否需要测试，是否需要考虑性能，是否需要说明文档等等。这些标准一般由项目组提前列好，每个故事只需要选中是否需要即可。

尽管有正式的评审会，但很多团队习惯在单个故事完成时，就让产品负责人进行单个故事评审，以确保交付时不会有“惊喜”。 评审会上发现的问题或改进将被累积到产品待开发项，也不会马上或在下一个迭代中开发，而是由优先级排序决定何时开发。

Scrum过程-反思会（Retrospective Meeting）

在每个迭代后召开简短的反思会。

总结哪些事情做的好，哪些事情做的不好。

制定改进计划。

怎样开展反思会？

反思会是Scrum中最难以实施的活动之一。

反思会上讨论三个问题：我们上个迭代有哪些事情做的好希望继续，那些事情做的不好希望改进，有何改进计划。

经常出现一些问题多次被提到，但却始终没有解决。应该每次仅就1～3个关键问题做出可行的解决方案，在下一个迭代执行改进。“可行”的概念包括两个含义：第一是方法简单，影响面小，见效快；第二个是目标不要激进，而要现实可行，积少成多。

如果必要可以执行领导回避制度，即具有管理职能的人不参加反思会，即使这些人是产品负责人，项目经理，乃至Scrum Master。

I：何为用户故事

按“作为一个……，可以……，以便……”样式和思路写成的用户需求，就是用户故事。

这种样式是技法层面的东西，它保证了无需太多思考，用户故事中即可全面包含角色、功能、价值这三个要素。

要想写好用户故事，要改变那种面向功能而非客户需求的纯技术观念。

价值是完成操作后，客户所得到的好处。 价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如“高效地……”“……可以节省话费”等。

更多分析，请见：敏捷开发用户故事之一：何为用户故事

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册 您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

用户故事 II：面向用户价值编写故事

软

的而不用角户度是从故度。的户用故同事不 事，；同；则若的应

的安装操作。

☻ 调动人员权限调整

☻作为管理员，可以在有人员调动时查询和修改其权限，以保证权限顺利转移。

家，可以通过显示排名，以便让自己在服务器中的地位获得认可（以刺激消费）。

☻ 显示排名

☻作为一个玩家，可以通过显示排名，以查看自己在服务器中的地位。

 作为管理员，可以查询和调整所有用户的权限，以改变某些所需调整的用户的权限。

更多分析，请见：敏捷开发用户故事之二：面向用户价值编写故事

功

能

该若作分不的开同写目写用不的故应户同不从有的

不

价

值

 作为一个排名靠前的付费玩

同

操

观

，

则

 显示排名

 权限查询

件

事

，

编

写

哪些是好故事？为什么？

角

该

 防打扰功能

 作为一个用户，可以选择‘认可所有相似操作’，以便同意或禁止连续的修改硬盘、访问网络的操作。

☻ 防打扰功能

☻作为一个用户，可以在安装软件时选择‘认可本次安装操作’，以便一键完成正常

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册

您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

用户故事 III：用户建模

用户建模的目的，是理解哪些用户可能来使用产品或访问网站，他们为解决哪些问题而来，为达到哪些目的而来。 良好的用户建模，可以保证不同用户都能方便地访问其功能，使用产品后也更容易获得其特定的价值。 将大量功能无序地摆放到大量用户面前，不但不会增加价值，反而令用户无所适从。

用户建模四部曲

更多分析，请见：敏捷开发用户故事之三：用户建模

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册 您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

用户故事 V：用户故事分类的原则

用户故事一般被按尺度分为史诗故事和普通用户故事。若要更精细化地管理，则可能包含颗粒度和可见性等更多维度，并因此而产生出更多的分类。

这些分类本身没有固定的方法，也没有优劣之分，但都必须服务于特定产品在需求管理上的某种目的。

比如为了在不同尺度上观察整个产品的功能，又想让合适的人看到合适的故事，就可能产生下面的分类方法：

某项目的实际分类方法

更多分析，请见：敏捷开发用户故事系列之五：用户故事的分类

用户故事 VI：用户故事分类

一种简单直观的产生用户故事的方法，是在项目开始的时候，从用户的业务出发，列出用户要管理的数据及其操作。



所谓数据，就是左图中“用户、角色、权限”这三种东西，就是要管理的业务

数据，这里权且记下用户有“3个史诗故事”要实现。



所谓操作，就是对“用户”这种数据，应该有增、删、改、查、加入角色……

这些称之为业务操作，这里权且记下对用户，会有“5个用户故事”。 这些对应关系不是绝对的，但却可以在早期帮助迅速勾勒出产品轮廓。

这个史诗故事，是一个业务数据

这个用户故事，是一个业务操作

客户理解这些数据或操作，并会在日常工作中管理这些数据，执行这些操作。

这个用户故事，是两个业务操作

这是个对史诗故事的增强，不是任何业务操作

为研发人员做的增强，客户无法理解，也不会用到。

为客户做的增强，但不是一个业务操作，只是改善了界面。

这是个对用户故事的增强，不是任何业务操作

更多分析，请见：敏捷开发用户故事系列之六：用户故事的产生与组织

用户故事 XII：业务数据与业务操作

火星人为不同种类的用户故事设计了合理的语法，以便更容易加以描述。 业务数据和业务操作是最常见的两种用户故事，与用户进行沟通、展示产品的功能时，主要使用这两种用户故事。

用户故事 VIII：用业务数据+业务操作表达产品功能

示例：利用业务数据故事+业务操作故事形成的用户故事树

用户故事 IX：增强与重构

火星人为不同种类的用户故事设计了合理的语法，以便更容易加以描述。

 增强和重构是常见的两种“变更”，前者主要面向业务功能，而后者则面向业务架构。

 尽管多数重构无需向用户公开，但在描述重构时，仍要说出对业务的益处，才能防止无谓的重构。

 不宜进行过大颗粒度的增强和重构，因为很难确认是否完成。一般将增强和重构拆分到可以指出是对哪个业务数据或业务操作的为

止，并将其挂接到相应的用户故事下。

用户故事 X：用增强+重构表达产品功能的变更

示例：挂接在数据故事和操作故事上的增强与重构

用户故事 XI：缺陷与技术债务

火星人为不同种类的用户故事设计了合理的语法，以便更容易加以描述。

 缺陷和技术债务是常见的两种“质量问题”，前者为已经发生的，后者则是潜在的问题。

 缺陷和技术债务的“重要程度”是与其所发生的了具体的业务功能相关的，在重要的数据和操作中存在的缺陷和债务，其待修改的优

先级也就越高。

用户故事 XII：用缺陷+技术债务表达产品功能的质量

示例：挂接在数据故事和操作故事上的缺陷和技术债务

用户故事 XIII：用户故事，MVC，FPA

敏捷开发用户故事、Asp.net MVC、功能点分析法（FPA）在一定程度上具有相同的目的：作为用户需求与开发人员工作的桥梁，只是侧重点有所不同。

 敏捷开发用户故事关注需求收集与管理；  Asp.net MVC关注架构设计与实现；  功能点分析法关注估算。

☻ 若割裂地管理它们，就可能需要为三种管理目的，分别维护三套管理数据，学习三种知识体系。

若能将它们联合应用，就可能用一种组织方式贯穿性地管理三者。

更多分析，请见：敏捷开发用户故事系列之七：用户故事与MVC

敏捷计划总流程

敏捷计划并非只局限于迭代计划会，而是会贯穿整个产品研发的周期中。

下面是围绕计划会前后发生的具体操作步骤，某些标注为“会前”的活动未必是会前仓促完成，往往是在之前更早的时间点上早有准备。

会前

 项目经理排定每个迭代的工作日历，以便计算整个团队的可用时间。

 产品经理列出每个迭代的周期、大致目标。

 产品经理从当前的产品待开发项（Product Backlog）中选择一些故事组成意向表（Willing List），准备在会上讲解。

会中

//先估算后分配，以便所有人积极参与。 项目经理.核对(日历); 产品经理.概述(迭代计划);

产品经理.概述(上一迭代, 本次迭代, 今后迭代); foreach (var 故事 in 意向表.OrderBy(重要性)) {

产品经理.讲解(故事); 团队.估算(ref 故事);

本次迭代.

Backlog.Add(故事);

if (本次迭代.Backlog.总工作量 > 团队.可用时间)

会后

 团队成员认领或项目经理协助，将用户故事分配到个人或小组。

break; }

return 本次迭代.Backlog;

敏捷计划I：可用时间计算

一个人月到底能完成多少工作量？“当然是22天了！”

那么，计划会、评审会的时间算不算？中途处理突发任务的时间算不算？写文档的时间算不算？做设计的时间算不算？帮助徒弟算不算？中午打瞌睡的时间算不算？……以及一个经常问到的问题：估算的时候要留余量吗？

为了解决这些复杂的问题，前人已经找到了较为成熟的方法，步骤如下（参考页末图中数据）：

 先减去Scrum会议的时间，一般是计划会-1天，评审会-1天

图中2.1计划会和2.29评审会各-1扣除。

 再减去确定无疑的出差、培训、请假……的时间，加上确定无疑的加班时间

图中cheny在6/7两天有一共-1.5天假期，yock在13/20～24有-6天假期；都没有加班  剩下的时间，新团队×50%，老团队×70%，得到预计可用时间

这样两个人最后剩下30.5天可用，如果×70%，结果是21.35天

估算故事时，不再留任何余量，按全时工作计算。所有需要在迭代交付时以PO指定的标准完成用户故事的事情都计算在内。

图片截自火星人敏捷开发工具（详情）

关于“故事点是怎么回事”以及“21.35天到底能完成多少故事”的问题，请参考：敏捷开发绩效管理之五：敏捷开发生产率（上中下三篇）

敏捷计划II：迭代计划

Product Backlog里边有干不完的活…… 每个迭代（Sprint）挑出最重要的部分…… 一个迭代连着一个迭代……

仅仅这样工作，尽管团队现在总是有活干，但是产品未来究竟会如何，却是看不清楚的。因此需要一个迭代计划来支撑对未来的预见。

为每个迭代起一个简短的标题外加设定一个面向客户价值的目标是非常好的实践。

图片截自火星人敏捷开发工具（详情）

如果标题和目标找不到合适的，表明大家其实并不知道自己在做什么，也就是众多的“当前最重要的故事”很难最终被汇聚为有意义的客户业务，进而提供客户价值。

深入讨论请参考：敏捷开发产品管理系列之一：序言及设立迭代目标

敏捷计划III：迭代意向表

在迭代计划会前，产品负责人一般会从众多故事中选择其中一些形成一个迭代意向表（Sprint Willing List），作为计划会讲解的备选故事。  迭代的意向表，是迭代目标在用户故事中的具体体现。

 因此意向表一般并非“当前最重要的用户故事”组成的乌合之众，而往往是

一些相关性强，完成后具备相对完整的业务功能的一组故事，称为“故事群”（一般比传统的史诗故事规模更大）。

 意向表的故事往往有一个预估值，以便产品经理能够大致估算出下个迭代能

完成哪些故事；预估值来自于一般仅由少数业务骨干参与的预估会议。  意向表中的故事、估算都不是最终结果，在计划会上讲解故事-估算故事活动

后，项将有可能被更新。

关于“如何进行优先级排序”以及“故事群”，请参考：敏捷开发用户故事系列之四：优先级排序关于“预估会议”，请参考：敏捷开发产品管理系列之五：预估会议

敏捷计划IV：故事讲解与估算

在迭代计划会上，产品负责人逐个讲解用户故事，团队逐个进行估算。

 讲解顺序应先业务后技术，先总体后细节，先过去后未来，帮助团队系统地把握产品功能。  团队应简要记录需求详情，有些团队在问答环节甚至能当场形成基本的测试用例雏形。  在估算之前，不应该事先指定开发负责人，以便提升整个团队对估算的积极参与。

更多细节，请参考之前页面： 产品负责人讲解什么？ 团队怎样估算？ 扑克牌估算

图片截自火星人敏捷开发工具（详情）

敏捷日常跟进I：故事板（看板）

故事板简单说就是把所有正在工作的内容，张贴到一个板状空间中。

看板（Kanban）一词来自日语，指的是制造业中的一种可视化方法，有相当复杂的思想和流程。由于两者看上去很类似，两个词汇经常混用。

关于故事板的一条简单规则，就是处于“开发中”的故事永远不要太多。也就是说要么做完一个故事，要么干脆不开工，这样在迭代结束前就不会面临很多故事都做了大半，但是都不能交付使用的情况。

图片截自火星人敏捷开发工具（详情）

深入讨论请参考：敏捷开发日常跟进系列之三：故事板，看板

敏捷日常跟进II：燃尽图（Burndown Chart）

根据整个团队的剩余工作总量，每天进行更新，就可以得到燃尽图。

 燃尽图的左上角是迭代第一天开始时，整个团队的所有用户故事的工作量，如图中是19.5工作日。

理想状况下，迭代结束时燃尽图抵达右下角，剩余时间为0的状态。

 每天为某个故事花费一些时间后（底端的粉红色柱状图），这些故事的剩余工作量就会下降。

不排除由于意外，造成“剩余时间≠计划时间-花费时间”的情况，这会造成燃尽图的起伏。  图中在1月13日左右开始，逐渐增加了一些新的用

户故事（图中从中下部开始的粉红色细线），导致总体无法完成，但实际团队完成的工作量，大于原定的计划（绿线终点低于粉线终点）。

 为了防止中间的变更导致原定必须完成的任务无法

完成，常常使用MoSCoW（待续）方法进行迭代内的优先级管理。

图片截自火星人敏捷开发工具（详情）

深入讨论请参考：敏捷开发日常跟进系列之一：燃尽图（上）

敏捷日常跟进III：跟进图与渐进评审

跟进图是高级的燃尽图，可以在迭代中期进行渐进评审，防止最后一天评审时发现的问题来不及改正。

 习惯上，常常在迭代的最后一天安排评审会，而评审会的第二天进行发布，但这将造成一旦评审会发现问题，无法及时解决导致迭代

延期或发布延期；尤其是在大型的团队，以及网络游戏、嵌入式开发等跨职能团队，故事在各平行团队看来处于“似乎能跑”的状态，但在策划和产品团队看来则是“不能满足需求”的状态，就更容易出现这种情况。  一般会为每个用户故事指定一个“跟进人”（网络游戏中是策划人员，而嵌入式开发

中是产品经理和助理），负责随时解释、验收用户故事。

 每当故事完成乃至只是取得一些进展时，都可以邀

请跟进人前来做中期评审，如果评审通过，则再进行下一个故事。

 配合MoSCoW方法，可以按优先级逐个完成用户故

事，确保最后的评审会更像一个“展示会”，而不会有实质性的关键任务评审不通过。

 如果没有足够的人手随时跟进，可以考虑使用“预

评审会”来代替，即在迭代到达70%附近时，先对已经完成的关键任务进行评审，确保它们中发现的问题得到及时解决，能在迭代结束时交付。

图片截自火星人敏捷开发工具（详情）

深入讨论请参考：敏捷开发日常跟进系列之二燃尽图（中）

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册 您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

敏捷日常跟进IV：跟进表

在大型团队中，跟进表与跟进图配合，可以揭示很多工作细节。

如果只使用简单的燃尽图，或者乃至上页中复杂的跟进图，有些信息仍然无法看到，而这些信息对某些大型团队可能是重要的。包括：

哪些故事完成了，哪些故事正在进行中，哪些故事还没有开始，大约何时可以开始…… 谁在开发，谁在跟进（负责解释需求和验收结果）……

对于小型团队，这些问题一般直接面对面沟通即可，但对于大型团队，往往需要一个可视化的工具，这就是下面的跟进表（注意表中没有配置“负责人”，也就是跟进人）。

表中隐含的信息包括：15日全体加班一天，故事“348显示意向表”原本在13日已经完成，但在18日又投入了一天；故事380尚未开始（因此在最右侧呈现粉红色）；故事365、381开始了但是没有完成（因此在甘特图中右侧为红色，而在最右侧呈现红底色），其中365连续三天“花费1天，剩余1天”，至今已经很久没有进展了，很可能遇到相当大的难题；根据故事板中的原则，这时候cheny应尝试彻底完成365、381，而不是开始做380……

图片截自火星人敏捷开发工具（详情）

深入讨论请参考：敏捷开发日常跟进系列之四：跟进表

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册

您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

敏捷生态系统-需求管理

敏捷生态系统表明了敏捷开发中各种实践的依存关系。当一个实践很难实施时，往往是另外一个实践未能很好实施造成的。

火星人敏捷开发手册：基于Scrum敏捷方法的免费敏捷开发手册 您的版本发布于2012-08-15，下一版本将于2012-10-15发布在：

敏捷生态系统-需求管理

客户价值导向-可工作软件-响应变化

客户价值导向是敏捷开发需求管理的主要思想。

敏捷开发相信密切与客户协作比编写详尽的文档更能弄清楚客户的需求；而利用阶段性的可工作软件外加邀请客户参与评审会，比让客户评审需求文档更容易让客户正确地补充需求和验收产品。

由于相信变化后的软件一定比变化前的对客户更有价值，所以敏捷崇尚响应变化。提供可工作产品来引导客户变化，可保证客户更能正确翔实地描述变化；而迭代交付则使得重要的、必要的变化可以提前交付，而不是像瀑布模型一样最后才发生。

通过需求优先级排序和迭代交付，首先可保证重要的需求一定可以交付到客户手中；其次可以保证重要的变更来临时，可以放弃尚未开发的次要需求作为交换；再次可以保证产品负责人（PO）会优先分析重要的需求，不会让它们在模糊状态进入开发。

只有最高优先级的需求才会进入下一迭代，因此很少有变更比它们更重要，而且这些需求也被较深入地分析过，产品负责人就有信心承诺迭代期内无变更，以换取团队承诺，进而保持交付以可持续的步调发生。

拥抱变化是一种由客户协作、优先级排序、可工作软件等各种实践支撑下的、主动的可控过程，而不是被动地“被变化拥抱”，“迭代期内无变更”和“拥抱变化”的对立统一，必须建立在这些实践的基础上。

更多分析，请见：敏捷开发生态系统系列之一：序言及需求管理生态（客户价值导向-可工作软件-响应变化）

敏捷生态系统-计划跟踪 I

敏捷生态系统表明了敏捷开发中各种实践的依存关系。当一个实践很难实施时，往往是另外一个实践未能很好实施造成的。

敏捷生态系统-计划跟踪 II

跨职能团队-共同估算-每日立会-同行压力

跨职能团队的整体思路是“每个人可以做每个工作”。好处是消除了资源分配的瓶颈和造成队员无法互助的分工壁垒。 任务应该先估算后分配给个人，以便整个团队（或至少其中的某个小组）都对其保持兴趣，才可能进行真正的共同估算。 共同估算（一般采用扑克牌估算）中人们利用整个团队的智慧充分讨论和确认任务的实现目标和方法，因此PO会统一管理/讲解需求，以防止个体理解差异。共同估算是共同跟进的基础，在每日立会中人们之所以关注别人的进展，就是因为人们关心自己曾经参与的估算结果是否正确，方案是否可行。

共同估算和每日立会产生了同行压力，即每个人都希望以好于或至少持平于团队估算的结果完成任务，从而产生了受激励的个体。

共同估算和每日立会还防止个体失误，前者通过统一了大家对

同一个需求的理解和其实现方法的理解，后者则防止了工作中出现需求镀金、蛮干等问题，从而产生更好的技能和设计。

作为自组织团队，敏捷团队并非简单地因为“领导让我们自我管理”而受到激励，而是在跨职能团队、共同估算、个体交互、同行压力这些实践的配合下才产生了受激励的个体和更好的技能和设计，从而产生更好的工作效率。

更多分析，请见：敏捷开发生态系统系列之二：敏捷生态系统-计划跟踪 I（跨职能团队-共同估算-每日立会-同行压力）

敏捷生态系统-计划跟踪 III

需求优先级排序-迭代期内无变更-团队承诺

产品负责人（PO）与团队的正确互动是自组织团队正常运转的核心机制之一。

产品负责人的权利是统一管理和讲解需求以及需求优先级排序，而义务则是接受开发团队的估算，并承诺迭代期内不变更。

团队的权利在于开发人员自己估算，而义务则是接受产品负责人所设定的需求内容、实现标准、优先级排序，并对自己的估算做出团队承诺，这种承诺会造成整个团队受到激励。

自组织团队-开发团队自己估算-PO挑战估算-同行压力

产品负责人不能干预团队的估算，却可以挑战估算。挑战估算可以通过对比两个团队处理同类任务、对比以往同类任务与本次任务等方式进行。团队的荣誉感会令团队产生团队间的同行

压力（与其他团队及与自己的过去相比），并进而产生受激励的个体。

作为自组织团队，产品负责人与团队互相没有领导关系，却通过分权与承诺管理，使得两者互相管理，从而产生更高的工作效率。

更多分析，请见：敏捷开发生态系统系列之三：计划跟踪II（需求优先级排序-迭代期内无变更-团队承诺）

以及：敏捷开发生态系统系列之四：计划跟踪II（自组织团队-开发团队自己估算-PO挑战估算-同行压力）

敏捷绩效管理-考核对象的变化

传统绩效考核面向个人

利用个人绩效的压力，来产生主动工作的动力。

☻ 队员会倾向于独自工作，忙的忙死闲的闲死，工作成果受到个人瓶颈制约 ☻ 在需要同时多人合作或前后衔接的场景中，容易引发部门矛盾 ☻ 个体能力有限时，解决问题的能力亦受限 ☻ 团队关系冷漠，新人得不到帮助，无法成长 ☻ ……

敏捷绩效考核面向团队

为整个团队设定目标并整体考核，利用同行压力来产生工作动力。优点： 团队作为整体工作，消除了能力和资源利用的瓶颈

团队会依据自身情况，自行选择以何种方式达到最大生产力

各自为战？高手工作大家帮忙打杂？大家工作高手巡回帮助？……

团队关系融洽，新人不断成长，形成学习型团队 ……

更多分析，请见：敏捷开发绩效管理之一：序言及“敏捷开发是否考核个人”（绩效考核）

以及：敏捷开发绩效管理之三：个体动力之源——同行压力（松结对编程，师徒制度，跨职能团队，绩效考核）

敏捷绩效管理-为团队设定目标，让团队把控细节

传统管理方式：领导指派任务

领导事无巨细地分配任务，追踪任务 ☻ 团队缺少自我思考能力，丧失主观能动性 ☻ 在估算问题上博弈，团队加一倍，领导砍一半 ☻ 推一步走一步，领导累，经理累，队员也累 ☻ ……

敏捷管理方式：自组织团队

为团队指明整体目标（如Sprint Backlog），具体工作细节（如所用技术、人员分配）由团队自己决定。

团队在计划会上会群策群力寻找最佳方案 团队会努力将自己估算变为现实，达成承诺

团队依据日常工作中的实际情况调整工作，无需依赖领导指令 ……

更多分析，请见：敏捷开发绩效管理之四：为团队设立外部绩效目标（目标管理，外向型绩效） 以及：敏捷开发绩效管理之二：用中医理论管理团队及其绩效（绩效考核，团队管理，自组织团队）

智慧敏捷-精益生产的启示

传统工厂的管理方式：中间产品众多

工厂：

☻ 大量资金积压在不可销售的中间产品上 ☻ 在仓库内存储及来回搬运的人工费用很高 软件：

☻ 大量人力花费在不可销售的中间文档上

☻ 编写文档的速度很慢，评审的效率很低，而读取过程中很容易产生歧义

精益生产认为：若能减少浪费，则等同于提高提高生产率

工厂：

 若不再经过零部件环节，则可以节省大量资金  若不需要仓库，则可以节省大量来回搬运的人工费用 软件：

 若尽量减少不可交付的文档，则可以节省大量人力

 若以跨职能团队尽量减少中间交接环节，则可以有效减少文档的数量，进而

提升生产效率

智慧敏捷-写不写文档？

过度设计和返工是造成时间浪费的主因，不同类型项目中两者比重不同

大型项目尤其是系统工程级别的项目，比如军工、航空类项目，设计的工作量很大，原因是这种投入毕竟是可控的；而一旦由于设计工作不充分，导致严重的返工，则往往不是简单的费用问题，还往往造成项目被终止。 成。

因而在这类项目中推广敏捷，应该适当增加文档的数量，以便长期项目能够按计划完

在互联网、消费电子行业则正好相反，返工主要是由于业务变化而不是错误或不足的因此在这类项目中推广敏捷，应当适当降低文档的数量，以便在业务变化时轻装上

设计引起的；相反过度设计往往在未被付诸实现之前就已经过时，反而形成浪费。 阵，而不需要同步修改大量设计文档。

应当理解敏捷开发的出发点不是不写文档之写代码，而是减少浪费，以便能按照自己项目的特点，灵活选择文档的数量及其形式，

在过度设计和返工之间找到平衡。

更多分析，请见：智慧敏捷系列之一：序言，之二：写不写文档，之三：做不做架构设计

智慧敏捷-敏捷实践的表象与内涵

每日立会开多久？

甲：“我们每日立会开不起来。”

乙：“嘿，我们每日立会开起来了，而且越开越长了，一开就是1个小时，净是些技术细节。” 甲：“别人等着他们讨论，那多耽误时间啊……”

乙：“我也觉得是，但是敏捷开发鼓励面对面沟通，到底应该打断还是不打断呢……”

看似沟通顺畅，但是如果队员们把每日立会当作唯一的沟通机会，甚至用来解决技术问题，可能表明他们在会下极少沟通。

定不定规范和模板？

甲：“你们的设计文档打算怎么写？” 乙：“到时候再说。”

甲：“应该有规范的开发流程和模板，才能写好设计文档。”

乙：“预先定义的流程和模板未必适用，敏捷开发崇尚推迟决策，只有在具体工作之前才能决定是否写，怎么写最好（maximizing the amount of work not done）。”

甲：“你们组才3个人，能决策出比组织级定义的流程和模板还好的吗？”

在过多的流程制度制约了开发灵活性的同时，完全没有规范和模板也可能造成团队无所适从，反而浪费时间。因此敏捷开发需要在“个体与交互 和 流程与工具”之间，找到平衡点，而并非完全放弃流程与工具。

智慧敏捷：敏捷开发应该注重各种实践的内涵，而不要被表象欺骗。

更多分析，请见：智慧敏捷系列之三：每日立会开多久，之四：定不定流程和模板。

中英文对照词汇表

火星人博客索引：敏捷开发产品与需求管理