在开始之前，首先来回顾一下我们是如何得到在sprint中需要实现的用户故事（User Story）列表的 ：首先，团队会根据开发团队在以往sprint的经验中得出的团队开发速度评估，以及对产品待开发事项（ Product Backlog）的粗略的成本评估。基于这两个评估，开发团队从产品待开发事项中挑选出一个用户 故事的候选列表，提交给产品利益相关者（Stakeholder）进行讨论。在讨论的过程中，伴随着用户需求 的进一步明确与细化，该列表的优先级可能会有相应的调整。回顾这个过程，不正是敏捷开发过程与传统 瀑布式开发流程最大的不同所在吗？
在上一篇文章中，我介绍了开发流程中团队里的三个核心角色（项目管理，开发，测试）如何协作定 义用户故事。这种协作机制是非常重要的，因为它不但能够使团队中所有的参与人员对产品的设计有一个 统一的认识，同时它还帮助团队在进入编码阶段前就找到产品中一些可能的漏洞。
当然，这种团队内部的沟通协作机制也可以扩展到实现设计以及测试计划阶段。正如我之前提到的那 样，在我看来，敏捷开发并不意味着不需要架构设计和文档。对于任何一个有一定复杂度的项目，尤其是 对于那些开发团队分布在不同地方（就像我们Visual Studio Team Architect团队一样）的项目而言，编 写、评审设计文档对于实现那些复杂的功能是十分关键的。我们团队对此有两种处理方式。一种方式是： 如果功能不是非常复杂，并且各方能很好地理解设计、设计本身不存在重大的不确定因素时，我们就会召 集一个简短的评审会议，负责该功能的开发工程师会准备一些简单的设计文档（比如类图和顺序图），在 会上给团队里的其他人员讲解他/她的整个设计思路。团队成员会一起评审该设计，并且对开发工程师可 能忽视的地方提出意见。测试工程师则可以通过这个过程了解开发工程师的底层实现思路，从而他们能够 在自己的测试计划中添加所需的白盒测试。同时，这个评审的过程也给开发工程师和测试工程师提供了一 个机会，使得他们能够更清楚的划分单元测试、验收测试以及功能测试的范围，从而更好地各司其职。
[注意：这是一个有争议的观点，甚至可作为一个辩论的话题。对此我个人的观点是：多余的测试对于 项目组中珍贵的资源（比如工程团队和机器）来说是一种浪费。我认为既然测试工程师的最终目标是保证 产品的质量，那么为什么他们不能利用开发工程师编写的单元测试作为产品质量验证的一部分呢？]
另一种方式是：当功能非常复杂或者大家对设计内容理解不充分时，我们会尝试针对这个功能做一个 “试探”（Spike）（即构建一个原型系统）并将发现记录下来。我们团队，以及一些经过我的推荐使用 这个实践的团队都发现对于具体的功能实现来说，“试探”无疑是一个非常有用的方法。下面我给大家展 示一下“试探”结果的文档模版：