开发管理 CheckLists(7) -敏捷开发-编写故事

在本章我们将关注故事编写，为了更好的构造故事，我们关注六个特性，一个好的故事应该具有如下6个方面的特点

故事的6个特征

1、独立的

       避免故事之间的相互依赖，在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致一些问题

2、可讨论的

        故事是可讨论的，他们不是签署好的合同或者软件中必须实现的需求，敏捷故事是功能的简短描述，细节将在客户团队和开发团队中讨论中产生，故事是提醒客户团队和开发团队以后要进行关于需求的对话，它并不是具体的需求本身，因而它不需要包含具体的细节。这些细节可以在后期例如：Scrum计划会议上面进行讨论

3、对用户或者客户是有价值的

      “每个故事必须对用户有价值”，这句话不是正确的，许多项目包含着对用户没有意义的故事，要记住用户（软件实际的使用人）和客户（软件的购买者）之间的区别。

       例如现在的很多公司做的 电信项目来说：客户就是电信提供商，但用户确实广大人们群众，像“5台服务器集群”这样的故事，对用户来说没有任何意义，群众只关心服务，但是对于客户来说，这个故事就非常有意义了。

       之所以介绍上面的故事是想说，故事一定是对用户或者客户有价值才行，不要出现只对开发人员有价值的故事

       例如：

        1、所有的数据库连接要从连接池中获取

2、 配置程序的log4j日志输出，并且配置好日志级别。

 像这些故事关注的是技术和实现细节，这些故事的背后想法是好的，但是故事的编写没有能够体现对客户或用户的价值。

上面的故事可以换成如下的形式：

1、这个软件，最多50位用户能使用5用户的数据库许可

2、所有的错误应该以统一的方式展现给用户并做记录

4、可估计的

       故事是可以估算大小、即把故事转变成代码的工作量是可以估算的。

       如下3个方面可能导致故事无法正常估算

       1、开发人员缺少领域知识

       2、开发人员缺少技术知识

       3、故事太大了

5、小的

      故事的大小很关键，故事太大或者太小都无助于定制计划。如果故事太大 比如“一个用户可以计划一次度假”，计划一次度假包含着一系列的任务，women把这种大故事成为“史诗故事”，对与这种故事我们要拆分成更小的故事，

      合适故事的大小最终取决于团队、它的容量和使用的技术

         故事太大就要分割故事

故事太小就要合并故事

6、可测试的

      故事必须是可测试的,成功通过测试证明开发人员正确的实现可故事。

      不可测试的故事发生在非功能性需求上面，这些需求和软件有关但是没有直接关系

      1、用户必须觉得软件很好用

      2、用户觉不需要花很长时间等待窗口出现

      这个2个故事都是不可测试的，无论什么时候，只要有可能，就要把测试自动化，要正确99%的故事都是可测试的。当产品增量开发时，很多东西变化的很快，昨天能工作的代码，今天就会出现问题，这时候就需要通过自动化测试来尽早的发现这些问题。

故事特征的总结

     立项情况下，故事之间独立的，有时候很难做到这一点，但是我们要尽力去实现。故事之间的交付顺序应该是无关的，可以任意拿一个故事来实现

     故事细节由用户和开发人员讨论得出

     故事应该很清晰的体现出来对用户活客户的价值，最好的做好事让客户编写故事

     故事可以注释一些细节，但是过多的细节会使故事难以理解，也可能给人一种这个故事很详细可不需要再和客户沟通了

     给故事假山注释最好的方式是编写测试用例

     如果格式太大，符合故事和复杂故事可以分成几个小故事

     如果故事太小，几个小故事可以合并成一个大故事

     故事应该是可测试的

开发人员职责

    负责帮助客户编写故事，这些故事要能提醒你们同客户交谈，而不是记录详细的需求定义，故事应该是对用户或客户有价值的，他们是独立的，可测试的、大小合适的

    如果被问及实现故事所用的技术或者基础架构信息，应该使用对用户或客户有价值的术语来描述。

客户团队职责

     负责编写故事，这些故事要能提醒你们同开发人员交谈，而不是记录详细的需求定义，他们对用户或者你们自己是有价值的，他们是独立的、可测试的、大小合适的

                    开发管理 CheckLists(22) -组织项目资源