敏捷项目管理实战之在敏捷开发中引入 Story 演示

转自：http://www.ibm.com/developerworks/cn/rational/r-cn-agilestorydemo/index.html?ca=drs-

Story 演示活动可以帮助敏捷开发团队提高开发质量、降低返工带来的质量低下与进度滞后的可能性。本文以作者黄文海的实际敏捷开发与管理的经验为基础，分享了具体实施 Story 演示的注意要点以及如何控制 Story 演示的成本。本文分享的不仅是一个具体的敏捷开发实践，更是一种敏捷开发的思想和思维方法。

敏捷项目管理实战系列

0

评论：

黄
文海, 项目经理, 软通动力信息技术（集团）有限公司

2012 年 12 月 28 日



内容

什么是 Story 演示

敏捷开发中往往使用 Story 驱动的方式实现需求。Story 驱动开发的优势在于它体现了“聚焦用户价值”这一理念。聚焦用户价值意味着软件开发过程中的一切活动和取舍都以最终交付件能否为软件的用户产生价值为考量。

在笔者所带领的敏捷开发团队中，一个 Story 在转测试之前其开发人员要召集相关的测试人员将该 Story 的各个验收测试用例执行一遍给测试人员看。这个过程中，测试人员会判断所执行的各个验收测试用例是否真正通过，并根据用例通过的情况决定相应的 Story 是否允许转测试。这样一个由开发人员执行验收测试用例，测试人员复核用例通过情况并据此决定相应的 Story 是否允许转测试的活动，笔者称之为 Story 演示。

Story 演示过程中所用的验收测试用例是在开发人员进行编码前由测试人员和开发人员一起根据 Story 所体现的用户价值设计出来的。因此，Story 演示这一活动是在聚焦用户价值这一理念的指导下产生的一种适合于敏捷开发下的转测试控制措施。

回页首

引入 Story 演示有什么好处

在讨论如何实施 Story 演示之前。有必要讨论下实施 Story 演示有什么好处。或者说为什么要实施 Story 演示。因为这个问题的答案会告诉我们如何实施 Story 演示。“为什么”的问题是“意”的问题，即我们做一件事情的时候，我们的意图是什么或者说我们期望这件事情的完成给我们带来什么收益的问题。用心理学的术语来讲，就是一个动机是什么的问题。“怎么做”的问题是一个“形”的问题，即行为方式或者事物的外在表现方式的问题。“意”会决定“形”，而“形”要遵从“意”。这样，我们所进行的活动才能较好得达到预期目的。比如爬山，如果我们的“意”是体验居高临下的一览众山小的感觉，那么我们可能会比较快得爬到山顶，而忽略沿途的风景。如果我们的“意”是散散心、呼吸新鲜空气、欣赏风景，那么我们可能是慢慢爬，流连在半山腰的风景之中。

Story 验收测试用例从用户价值的角度定义了 Story 的最低质量标准。Story 演示通过评估这些用例的执行通过情况决定相应 Story 是否允许转测从而保证了转测 Story 的最低质量要求，有效降低了由于转测 Story 质量低下而导致的多次修正代码多次再转测的返工可能性。返工作为软件开发过程中一种最为常见的浪费现象，它不仅阻碍了进度，也降低了质量。因此，从短期角度看，Story 演示的好处在于它能够有效减低返工的可能性，提高 Story 代码的质量。

Story 演示是由开发人员和测试人员共同参与的。Story 演示所呈现的软件功能作为开发人员的作品，对于往往有着弊帚自珍心理的开发人员来说，他总是不愿看到其作品在他人面前出现缺陷的。因此，Story 演示前，开发人员必须做好充分的单元测试才能避免在演示时当众“出丑”。于是，通过一次次的 Story 演示可以强化开发人员的质量意识。而开发人员的质量意识很大程度上决定了缺陷的数量。毕竟缺陷不是由测试人员“发现”出来的，而是开发人员“创造”了大部分缺陷。

另一方面，Story 演示过程中，开发人员往往能够自己发现一些在此之前不曾发现的问题，这些由其自身发现的问题往往能给其留下深刻的印象因而有利于其避免下次再犯同样或者类似的错误。这有利于开发人员自身的持续改进，提高其个人能力。因此，从长期角度看，Story 演示的好处在于它强化了开发人员的质量意识，并促进开发人员个人能力的持续改进。

能够从短期和长期的角度去理解实施 Story 演示的好处非常重要，因为这会影响到我们如何具体实施 Story 演示。

回页首

如何设计验收测试用例

验收测试用例的设计与选取要从用户或者更切确地说利益干系人的角度出发。验收测试用例定义了 Story 应满足的最低质量要求。比如，对于一个 ATM 机取款功能，我们可以定义如下几个验收测试用例：

用例 1：

预置条件：发卡行为本行，账户余额 1000 元，ATM 机剩余现钞 1000 元。取款金额 1000 元，吐钞设备正常，网络正常。

期望：吐钞设备吐款 1000 元，账户余额 0 元，ATM 机剩余现钞 0 元。

用例 2：

预置条件：发卡行为本行，账户余额 1000 元，ATM 机剩余现钞 1000 元。取款金额 1100 元，吐钞设备正常，网络正常。

期望：吐钞设备无吐款，账户余额 1000 元，ATM 机剩余现钞 1000 元。

用例 3：

预置条件：发卡行为本行，账户余额 1000 元，ATM 机剩余现钞 900 元。取款金额 1000 元，吐钞设备正常，网络正常。

期望：吐钞设备无吐款，账户余额 1000 元，ATM 机剩余现钞 900 元。

用例 4：

预置条件：发卡行为本行，账户余额 1000 元，ATM 机剩余现钞 1000 元。取款金额 1000 元，吐钞设备故障，网络正常。

期望：吐钞设备无吐款，账户余额 1000 元，ATM 机剩余现钞 1000 元。

从上面的例子可以看出，在验收用例的设计过程中我们仍然使用边界值法、场景法等常用的测试用例设计方法。但是，验收测试用例的选取和设计是从 Story 给利益干系人（上述例子涉及的银行储户和银行）提供的价值为准绳。它通常覆盖一些正常业务场景，但也覆盖一些重要的异常业务场景（如上述例子的用例 4）。而有些无效等价类测试用例，虽然它们可以用于测试软件的健壮性，但在真实环境下这些用例所描述的情形往往不可能出现。因此，这些无效等价类测试用例一般都不作为验收测试用例，而只是作为后面的 Story 测试用例。比如上例中，在真实的
ATM 环境下由于输入设备的限制，取款人无法输入“abc”这样的取款金额值，因此取款金额为“abc”这样的无效等价类测试用例则不列入验收测试用例。

回页首

Story 演示的主动权和表决权

Story 演示中的测试用例是由开发人员执行的。在演示过程中，对于每条验收测试用例，开发人员会向测试人员展示和讲解其预置条件以及实际结果与期望结果的吻合。而测试人员在此过程中则评估预置条件的正确性和充分性，并复核实际结果与期望结果是否真正吻合，进而判断相应用例是否真正通过。并记录每条用例的通过情况。开发测试人员在此时也可以一起重新评估下事先设计的验收测试用例覆盖是否充分，是否有所遗漏。因为此时开发人员已经经历了该 Story 的编码，测试人员已经在编写自动化测试用例脚本了，大家对 Story 的理解较之前有了更丰富的背景因而能够发现事先所不能考虑到的测试用例。

在没有意识到 Story 演示给我们带来的长期利益（强化开发人员的质量意识和促进开发人员的持续改进）的情况下，测试人员往往倾向于从开发人员手上“抢过”主动权，自行执行演示测试用例。此时，本来应该是演示的活动就“退化”成了检查——测试人员去检查开发人员的工作产出是否满足最低质量要求。这样实施，事实上只是发挥了演示的短期利益，而没有把其长期利益发挥出来。要发挥演示的长期利益，就必须由开发人员执行测试用例，这样才能增加其自行发现问题的机会，有利于其避免问题重复出现从而促进其持续改进。

Story 演示作为一种转测试入口控制措施，其通过与否要由测试人员来决定。测试人员在演示过程中会记录每个用例的执行通过情况。演示结束后根据执行未通过的用例数量和这些用例所暴露的问题的严重程度综合考虑演示是否通过。只有通过演示的 Story 才允许进行转 Story 测试。

回页首

控制 Story 演示成本

在 Story 演示给我们带来收益的同时，它也会产生成本。因此演示过程中要注意控制成本。

首先，Story 演示中执行的测试用例并不是该 Story 的全部测试用例，而是其中的验收测试用例。这意味着从所执行的用例的数量上控制演示的成本。因此，我们可以在 Story 测试用例设计时把其中符合验收测试用例选取原则的用例标记为验收测试用例，在后面演示时可以直接使用。

另外，测试人员在演示过程中要根据当前所发现的用例执行不通过的情况及其暴露出来的问题的数量和严重程度及时决定演示是否继续还是停止，等问题修复用户再重新演示。如果演示过程中所发现的低级问题或者严重问题比较多，说明 Story 演示准备得不充分，此时应及时停止演示，避免浪费时间。并由开发测试人员约定好再次演示的时间。

同时，也要注意控制每个 Story 演示的次数。一个 Story 演示的次数通常要控制在三次以内，避免过多的演示浪费时间。

回页首

Story 演示结果的登记与公布

Story 演示的结果要由测试人员及时登记并提交到配置库上，供后面迭代回顾时对 Story 演示活动进行分析与总结，以便对下一个迭代的 Story 演示活动提出改进措施。同时，通过比较两次迭代的 Story 演示结果可以明确开发质量是否有所提升，开发人员是否在进步。

每个 Story 的演示结果参与演示的测试人员要及时知会到全体成员。演示的结果包括通过、不通过和待确认。对于一次性演示通过的 Story，在知会演示结果时测试人员要及时对相应开发人员的高质量工作表示肯定和感谢以提高开发人员的成就感，正是他们的高质量工作降低了测试人员的工作量（降低了对一个 Story 多次进行测试的可能性）。对于未过演示的 Story 及时进行知会可以提醒开发人员及时保质量地修复问题，避免同一个 Story 演示次数过多而增加演示成本。

Story 演示结果可以在状态墙上知会，也可以使用即时通讯工具进行知会。

表 1 是一个 Story 演示记录的样例。

表 1. Story 演示记录样例
[thead]
[/thead]

Story 名称	演示次数	参与者	演示日期	问题及疑问	问题处理结果	演示结果
ATM 本行取款 Story	第 1 次	张三、李四、王五	2012 年 12 月 10 日	无	无	通过

回页首

总结

本文从引入 Story 演示所期望的收益入手，分享了具体实施 Story 演示活动的注意要点，以及如何控制 Story 演示的成本。Story 演示能够给敏捷团队带来的好处或者预期收益是其“意”，而采用什么样形式去实施 Story 演示以便获得预期收益是其“形”。“意”是引入一个具体实践的目的和意图，而“形”是如何落实一个具体实践的形式。“意”决定了“形”，而“形”要符合“意”的要求。同时，Story 演示活动中开发人员、测试人员紧密协作，这体现了敏捷开发中“个人与交互胜过过程于工具”的价值观。因此，本文同时也是在分享一种敏捷开发的思想。

参考资料

学习

查看“敏捷项目管理实战系列”其他文章。

访问 IBM developerWorks 中国网站敏捷专题，获得与 敏捷开发相关的技术资源和最佳实践。

访问 IBM developerWorks 中国网站 Rational 专区，获得关于
IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。

订阅 IBM developerWorks 时事通讯，一份关于 developerWorks
指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。

获得产品和技术

学习“敏捷开发学习路线图”，掌握更多敏捷开发技能。

获取更多 IBM 试用版软件，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及
WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。

讨论

加入 developerWorks 中文社区，developerWorks
社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

访问 developerWorks 社区上的 敏捷开发小组，在那里您将有机会与更多的开发人员一起交流敏捷开发最佳实践。

加入 IBM
软件下载与技术交流群组，参与在线交流。