特别鸣谢Paul Nagy！

*

关于我

曾任职诺基亚西门子网络公司全球精益及敏捷转型部门担任精益及敏捷顾问。

专长于大型组织(>500人)的敏

捷迁徙转变。精通各种风格、类型的黑盒测试，包括验收性测试驱动开发、探索性测试、测试自动化等等。在辅助一个400人的大型组织搭

建、规范化测试自动化系统及实践之后，选择传授敏捷/Scrum以及精

益的要义，辅导其他组织进行转变。兴趣广泛，包括但不限于各种类型测试、敏捷/Scrum及精益。

国内敏捷会议的常客，近期的有敏捷中国2010，Scrum Gathering

Shanghai 2010，以及2009、2010

年的敏捷全球之旅中国站活动。

更多信息请看LinkedIn主页：http://cn.linkedin.com/in/kaveri

*

*

产品负责人（PO）问团队:

你们能承诺做完吗？

无人应答。

Scrum Master朝大家看了看，然

后扭头朝向产品负责人

当然，我们能！

*Scrum Master不是团队的经理。

向PO承诺的，是团队，而不是Scrum Master。

产品负责人问团队：

你们能全部搞定吗?

团队：

够呛，这么多恐怕我们做不完，

这样吧，我们可以都接下来，

但是特性6要作为“未承诺 ”

（uncommitted） 的。

*

产品负责人决定做什么（What），

团队确认他们能否完成。

如果团队还剩下一点点儿时间没有用完，不

必强求，随它去不用理会，因为在Sprint过

程中，如果团队

- 已经完成承诺的所有特性

- 还剩下一定量的时间可以干活

他们还可以叫上产品负责人，再选择些特性，

利用Sprint剩下的时间继续把它们完成。

用户故事：

“作为产品负责人，我真的需要

团队按时完成。”

或是

“作为发布经理，我需要团队为

特性A和B执行集成测试。”

诸如此类。。

*INVEST用户

独立

可协商

有价值

可估量

小

可测

作为

<某类型用户>

我需要

<某软件特性>

以满足

<需求或动机>

Independent, Negotiable, Valuable, Estimable, Small, Testable

用户故事：

“为2.0版本产品系统

升级安全性补丁”

问：哪些补丁？

答：团队可以决定。

*

确保产品负责人参加Sprint计划会议的时候，

带来的产品Backlog状态良好：

颗粒度分布均匀，用于当前Sprint备选

的需求相关信息足够详细，例如，小颗

粒用户故事

Backlog Grooming会议

Sprint进行到四分之三的时候举行。

产品负责人和所有团队成员都必须参加。

将软件特性分割到任务级别的过程，有

些团队很有心得研究出一套固定招式：

• 设计

• 编码（包含单元测试）

• 测试

• 测试自动化

• 和团队A确认相关技术细节

*

所有团队成员协同作战，在白板纸上以草稿画、

文字记录等方式，描绘出团队整体对所选软件

特性的理解，从而可以综合开发及测试等多方

面的思维来分析、理解所选特性。

任务的分割

测试自动化相关的任务很难估

计完成任务所需的小时数，

但是敏捷教练告诉我们如果

任务的估时超过16个小时是

不好的，所以我们得要分割

相关任务……

*

有哪些可接受性测试用例？

是不是测试环境很难配置？

是否要使用外部测试设备？

是否要开发测试辅助程序？

是否要开发测试夹具支持？

等等

*

Scrum Master

（环顾四周）张三，就从你开始讲吧。

……

（看着王二）我看这样吧，这个事情你先继续做，回头再和周四联系一下，把实验室地问题解决掉。

……

Scrum Master

* 团队

掌握进度

任务分派

风险管理

Scrum Master

每日站会

关注同时并行的任务数量

应对团队自己无法处理的 障碍、拦路石

留意人际方面问题或冲突，并着手解决

团队成员：

昨天我修复了一个bug。

今天我继续修改别的bug。

或者：

今天早上我开始做测试，但是

被测系统很难连，连接很不稳

定，我叫实验室维护的人来帮

忙了。一直弄到下午我才可以

真正开始测，有点晚了，所以

还没做完呢。明天我继续做这

个测试。

*

关注团队的进展

• 完成尚需要的时间

• 有没有遇到什么惊喜

• 是否有新的收获（相关领域或软件系统）可以分享？

• 有什么值得一提的状况告诉大家？

• 是否需要帮助

基于任务更新状态

团队成员

（任务A：8小时）

第一天：没有阻碍，我正在做，再2个小时应该能做完。

第二天：调试过程遇到些麻烦，不过我在处理，问题不大，应该还有2个小时吧

第三天：……

*

使用燃尽图

应对不如意的进度

明晰状况

•发生了什么

•有什么影响

•有没有偏离

•该做些什么

团队成员们希望能够将每日站会改成

每周开两次。

他们的理由很充分：

• 没人关注我承接任务的状况

• 我对别人的情况也没兴趣，因

为不太能理解他们所说

• ……

*

管任务，别管人！

直线经理（刚刚上任）

“有个团队成员被任务A（估时：

6小时）给困住了，都三天了，

他还没能完成。其他人都忙着改

bug。而任务B又依赖任务A的完

成。”

“我觉得也许我们需要弄一张甘

特图，来控制任务间的依赖。”

问题：先看一下你们的燃尽图吧。

回答：那玩意儿没用，我们没用。

*• 可视化管理

• 团队身边可视化、触手可及的信息

• 让团队知晓你遇到的阻碍，并尽快地寻求帮助以解决问题

• 利用燃尽图来暴露进度上的问题

*

DONE

问题：那么这个特性已经DONE了？Condition of Satisfaction的状况如何?

回答：这个记录在产品Backlog管理系统里的。

（打开工具……）

问题：这就是你们的Condition of Satisfaction？！！

回答：是啊……就是写着的“系统模块验证测试完成；QC内容更新；单元测

试覆盖率高于90%。”

Condition of Satisfaction

Definition of Done

*

Condition of Satisfaction

• = Confirmation

（用户故事3C之一）

• ≈ 可接受性测试

它是

• 特性的行为表现细节

• 特定场景下用户期待的结果

DONE与演示

问题：DONE了几个？

回答：呃，都没DONE

问题：那就是没有演示喏。

回答：但这不都接近DONE吗……

*拒绝

判断某个软件特性是否已经DONE，其判断标准是Definition of Done。

如果没有符合DONE的标准，就不演示，也未收获相应特性的大小（Size，多使用故事点表示）。

*

团队

“我们的任务估算很有问题！总是估少了。”

*

能力不足、缺乏经验

• 和技艺娴熟的同事结对

• Backlog Grooming会有帮助

未及时发现风险

• 在每日站会上发掘潜在风险

任务分派

• Sprint计划会议时共同完成概要设计

团队新成员

• 和技艺娴熟的团队成员结对

*

笔记本会议

• 人们多数时间都在摆弄电脑

• 不注意听别人讲话

• 并非所有成员都理解最终的决定

• 你需要和他们挨个核查情况

• 需要某人发言时必须明确地指明

向他/她提问

*• 每一个人都要表达他们的观点

• 关注会议的目的不偏离

• 推动畅所欲言的文化

• 鼓励有益的（建设性）冲突

*

*谢谢！

mailto:YI.XU@HP.com

mailto:KAVERJODY@GMAIL.com

mailto:KAVERJODY@MSN.com

Skype : KAVERJODY

新浪微博: 徐毅-Kaveri

腾讯QQ : 17376122

http://blog.sina.com.cn/kaverjody

http://cn.linkedin.com/in/kaveri

http://kaverjody.wordpress.com