`
dyllove98
  • 浏览: 1378844 次
  • 性别: Icon_minigender_1
  • 来自: 济南
博客专栏
73a48ce3-d397-3b94-9f5d-49eb2ab017ab
Eclipse Rcp/R...
浏览量:38203
4322ac12-0ba9-3ac3-a3cf-b2f587fdfd3f
项目管理checkList...
浏览量:78419
4fb6ad91-52a6-307a-9e4f-816b4a7ce416
哲理故事与管理之道
浏览量:131583
社区版块
存档分类
最新评论

开发管理 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) -组织项目资源

 

2
0
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics