通过用户故事来表达需求正在敏捷团队中变得越来越受欢迎。这些使用用户故事的团队把重点从描述需求转移到讨论需求。客户很高兴他们终于不用从项目开始之前就要确认所有需求。用户很满意以这种方式生产的产品，因为现在产品更能满足他们的需求。
然而，尽管用户故事能够使得团队和客户进行更多的交流，但是通常还是有许多东西需要进行记录。合约项目和外包开发是一种需要团队针对文档进行讨论的例子。这篇文章会介绍我以前使用过的，针对合约型敏捷开发的协议书写方式。
几年前，我曾经在一个用于奥运会广播的系统上工作。解说员，作者和其他会使用这个系统的人都需要能够从各种与运动员有关的事件中摘录信息。其中一个场景就是，一个将要解说400米栏的解说员会用这个系统来查找以往的成绩和一些运动员的有趣的信息，以备加入到稍后的解说中。系统被设计成一个庞大的信息网站，一个用户可以从一个体育项目开始逐步深入查找相关的国家以致运动员。用户或者也可以从一个运动员开始，查找其将参加的所有比赛项目，然后再通过这些项目找到参加这些项目的其他运动员。这个项目被外包到了我们的团队，而当时我们正在使用的就是最流行的敏捷开发流程之一—Scrum.
需求按照下面的格式，通过用户故事的形式记录下来：
作为一个…， 我希望可以…，以便…
这种格式使得用户故事可以明确地表明一个用户想要得到的东西，以及其原因（可选）。在这个系统中的用户类型有很多，不过在这个例子中我们只需要知道其中的两个就可以了：观看者和内容提供者。观看者就是指可以在系统中浏览数据的用户，包括前面提到过的解说员和研究员。内容提供者是那些将有用的资料输入系统中的作者。下面是一些这个系统中的用户故事：
1. 作为一个观看者，我可以看到指定运动员的详细信息。
2. 作为一个观看者，我可以轻易地找到一个运动参与的项目，以及得到在其团队中的其他运动员的列表。
3. 作为一个观看者，我可以给运动员加上标签。
4. 作为一个观看者，我可以容易地找到加过标签的运动员。
5. 作为一个观看者，我可以高亮显示运动员档案的部分项目，以便我下次在看档案的时候可以找到我最感兴趣的部份。
6. 作为一个内容提供者，我可以控制信息显示的基本格式。
如果要我们单独对上面的用户故事，每个给出估计的时间，然后提供报价，那将会是很大的挑战，也是相当危险的。我们需要与客户交流来获得更多的信息。但是同时我们也要记录下在交流中得出的一些关键推测和决定。我们所做的是，为每个用户故事提炼出少数概要的验收准则。现在我把这些准则叫做用户故事的满足条件。然后我们就得到一份包含每个用户故事及其满足条件的文档。下面是第一个用户故事的满足条件的描述：
1. 作为一个观看者，我可以看到指定运动员的详细信息。
名字（多个，可能很长，包含读音）
昵称（包含读音）
奥运会中之前的成绩
所保持的世界纪录和奥运会纪录
趣闻
国籍，训练地，教练（链接）
6作为一个内容提供者，我可以控制信息显示的基本格式。
斜体
粗体
项目符号和编号
不需要所见即所得，但是可以通过点击一个按钮进行预览
在签订合同和开始编码之前我们就和客户进行了交流，并且总结出了上面的列表。关于第六个用户故事的讨论尤为重要，因为团队通过放弃所见即所得编辑器而改为用预览按钮，帮客户省下了一笔钱。他们也同时决定非常简单的显示格式已经足够。我们并不需要改变字体风格，大小以及颜色。更准确地确定范围，这样就避免了在投标中，低价投标导致亏本，高价投标的导致无法中标的潜在风险。
有时候一个看起来非常直接的用户故事可能会隐藏了一些非常危险的推测。通过讨论满足条件，可以帮助找到这些推测从而使得开发人员和客户更加相信他们已经针对合同达成协议，并且非常清楚哪些工作是需要的。让我们看看这样一个例子来：
5. 作为一个观看者，我可以高亮显示运动员档案的部分，以便我下次在看档案的时候可以找到我最感兴趣的部份。
第一眼看到这个故事的时候似乎是非常清楚的。开发人员准备提供一个可以让观看者使用黄色高亮任意区域的界面。然而，通过与客户的交谈，我们发现客户实际需要的更多。在与客户讨论的过程中，我们会问下面的一些问题来发掘用户故事的细节：
我们怎么才算完成？
当我们演示这个用户故事的时候，你想要看到什么来确定我们做的就是你想要的？
这些问题能够引起一些客户从来没有想过的需求的讨论。例如像刚才提到的高亮问题，一部份工作正如我们所计划的那样，但是客户同时也提出了“全局高亮”的概念，就是说一个高亮设定可以对所有其他用户可见。这又引起了安全权限的讨论—我们是不是该让高亮对所有用户都可见呢？另外还引起其他话题的讨论。到最后，我们确定用黄色来做私有高亮，蓝色来做全局高亮。然后在我们的合同中这个用户故事及其满足条件就是：
5. 作为一个观看者，我可以高亮显示运动员档案的部分，以便我下次在看档案的时候可以找到我最感兴趣的部份。
两种高亮模式—黄色和蓝色
在一个会话中设定的高亮对下个会话可见
当然，收集这些满足条件是相当费时的。这就是为什么我们不会找出需求中所有的不确定因素，同时那是也不可能的。相反，我们尝试找出足够多的不确定因素，来保证签订合同的各方都有足够的信心，尽管我们都知道当中可能会有一定的风险。在我的经验中，在第一次签订合同的时候，把用户故事的满足条件全都列出来是很有用的。但是在接下来的项目里，如果双方已经知道如何合作，并且已经建立起一定的信任，合同里面只需要有用户故事就足够了。
当然，除了用户故事的满足条件以外，还有很多东西可以帮助你订制好的敏捷项目的合同。一份好的合同同时也需要能够对双方都有鼓励促进作用。另外，团队必须拥有良好的估算方法，才能提高项目盈利的可能性，从对用户故事定义满足条件开始，会是个不错的开端。
作者:Mike Cohn
原文地址：http://www.mountaingoatsoftware.com/articles/5-writing-contracts-for-agile-development
