[用户故事与敏捷方法]编写故事

为了构造好的故事,我们应该关注六个特征:

  • 独立的(Independent),如果故事不是独立的,我们在对故事做相关计划时,故事间的相互依赖就会导致一些问题。还是之前例子:
    1. “用户需要通过浏览器上传文件”
    2. “用户需要选择多文件上传”
    3. “ 用户需要上传文件夹”
    我们会发现故事2、3是需要在故事1的实现前提下才能实现,这样无法给出这些故事的时间评估。出现这种情况时,我们通常需要通过一些思路绕开这种依赖:
    1. 将互相依赖的故事合并成一个大的故事
    2. 用一个不同的方式去分割故事
    这样上面的故事例子可以重新整理成:
    1. “用户需要通过浏览器上传多个文件”
    2. “用户需要通过浏览器上传文件夹”
    通过这样的重新整理,故事互相独立,可以给出每个故事的计划评估。
  • 可讨论的(Negotiable),首先故事不是签署好的合同或者软件必须实现的需求,其次故事是功能的简短描述,细节在客户团队和开发团队的讨论过程中产生。故事卡片不必包含相关细节。但可以包含一些重要的细节注释,用来表明讨论需要解决的问题;在讨论过程中确定的一些细节需求就可以成为测试用例。故事是需要实现的功能概述,具体讨论确认需要实现的细节作为详细需求内容以及测试用例。
  • 对用户或者客户有价值的(Valuable to Purchasers or Users),需要注意的是客户和用户可能不是同一个角色,同时需要避免只对开发人员有价值的故事。保证每个故事对客户或者用户有价值的方法是让客户来编写故事。
  • 可估计的(Estimatable),对于开发人员来说,能估算故事的大小(猜下工作量和难度)十分重要。一般造成故事不可估计的原因包括:
    1. 开发人员缺少业务知识
    2. 开发人员缺少技术知识
    3. 故事太大了
    对于第一点,开发人员需要参与同客户讨论,或者充分的沟通,让开发人员理解故事的必要重要情节,对故事有个大概的了解。如果开发人员缺少技术知识,需要进行技术性的探索,则可以建议开发人员进行一个技术预研,然后根据预研的结果,评估工作量,这个技术预研需要当作一个单独的开发任务给技术开发人员,可以作为一个迭代的开发内容。对于第三点,故事太大了,这种情况只需要对故事进行拆分,到足够评估工作量即可。
  • 可测试的(Testable),故事的描述需要可测试,这样多方才能确认量化需要的最终效果。一些故事描述例如:用户必须觉得软件很好用,这种故事描述就无法进行测试。

未经允许不得转载:Mr.开发者 » [用户故事与敏捷方法]编写故事

赞 (0)
分享到:更多 ()