《敏捷软件开发：用户故事实战》—对用户或客户有价值的

对用户或客户有价值的

“每个故事对用户必须有价值”听上去很有吸引力，但是可能并不适当。一些项目包括了对用户并不重要的故事。要注意用户（使用软件的人）和客户（购买软件的人）之间的区别，假设开发团队正在构建一个软件，该软件将部署在一个具有5000台计算机基数用户群的公司中。这个产品的客户可能会非常担心5000台计算机中的每一台是否都使用了相同的软件配置。这可能会产生这样的故事：“所有配置信息都是从中心位置读取的。”用户不会关心配置信息存储在哪里，但客户可能会关注。

类似下面的故事可能对考虑购买的客户有价值，但是对实际用户却并不重要。

l   在整个开发过程中，开发团队将编制符合ISO 9001审核标准的文件。

l   开发团队将依照CMM 3级的标准来构建软件。

要避免只对开发人员有价值的故事。例如，应该避免下面这样的故事。

l   所有与数据库的连接都是通过连接池进行的。

l   所有的错误处理和日志记录都是通过一组公共类完成的。

上面所写的故事都关注在技术和实现上。这些故事背后的想法很有可能是好的，但它们应该能够清晰地描述出能够给客户或用户带来什么利益，从而使客户能够方便地将这些故事排列优先级，并划分到开发计划中。这些故事更好的版本可能如下。

l   最多50个用户应该能够使用5用户的数据库许可来使用该应用程序。

l   所有错误都会以一致的方式呈现给用户并记录。

同样，将用户界面假设和技术假设从故事中抽离出来是值得的。例如，前面修改后的故事去掉了连接池的使用和一组错误处理类。

确保每个故事对客户或用户有价值的最好方法是让客户来编写故事。开始时客户通常不愿意这样做，可能因为开发人员以前总是令客户认为，他们所写的东西以后可能会对他们产生不利（“嗯，需求文档并没有说……”）。一旦客户习惯于故事卡不是正式的承诺或者是对功能的特定描述，而只是对稍后进行讨论的提示，大多数人都会开始自己编写故事。

软件开发 敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。