Scrum(Story)

【搜集故事】
  搜集方法
    用户访谈
    问卷调查
    观察用户
    故事编写工作坊
  
【编写故事】
  六个特征

  •     独立的
  •     可讨论的
  •     对用户或者客户是有价值的
  •     可估计的
  •     小的
  •     可测试的

  特征总结  

  1.      立项情况下,故事之间独立的,有时候很难做到这一点,但是我们要尽力去实现。故事之间的交付顺序应该是无关的,可以任意拿一个故事来实现
  2.      故事细节由用户和开发人员讨论得出
  3.      故事应该很清晰的体现出来对用户活客户的价值,最好的做好事让客户编写故事
  4.      故事可以注释一些细节,但是过多的细节会使故事难以理解,也可能给人一种这个故事很详细可不需要再和客户沟通了
  5.      给故事假山注释最好的方式是编写测试用例
  6.      如果格式太大,符合故事和复杂故事可以分成几个小故事
  7.      如果故事太小,几个小故事可以合并成一个大故事
  8.      故事应该是可测试的

【估算故事】
  估算方法特点
    1、运行改变估算结果
    2、适用于所有的故事
    3、很容易很简单的进行估算,不需要花费太多时间
    4、提供进度和剩余工作的主要信息
    5、计算不准确也不会有大问题
    6、估算的结果可以用来指定发布计划
  估算方法
    以故事点(完美工作日或者小时)的形式进行估算
    以团队估算
  估算步骤
    1、所有参与的客户和开发人员聚在一起
    2、从第一个故事开始,详细讲解故事直到所有的人都清楚了解这个故事
    3、每个开发人员都先写下自己估算的值,一故事点为单位 ,例如 2完美工作日(2天)
    4、大家都展现自己的估算,然后每个人都说一下为什么估算出这个值
    5、最后经过论证团队估算出一个所有人都认可的值
    6、继续下一个故事的估算
  估算总结
     用故事点估算故事,故事点是故事复杂度,工作量或工期的相对估算
     应由团队进行估算故事,估算属于团队而不是个人
     听过其他估算进行比较做三角测量
     团队是否使用结对编程对故事点估算没有影响,结对编程影响的是团队的速率,不是他们的估算

【验收故事】
  测试步骤
    1、将测试要点记录到敏捷的故事卡的背面,任何时候发现新的测试,都可以记录到故事卡背面
    2、将测试要点变成全面测试,这些测试用来演示故事已正确、完整的实现
  测试类型用例类型
    1.单元测试用例
    2.验收测试用例:用户交互测试/可用性测试/性能测试/压力测试
  搜集测试用例方法
    1、关于这个故事、程序员还想知道什么?
    2、对怎么实现这个故事,我的想法是什么?
    3、有没有特殊情况会使这个故事有不一样的行为?
    4、这个故事什么情况下回出错?
  测试用例编写时间
    1、开发人员和客户讨论故事且需要记录明确的细节时
    2、在迭代开始时候、在写代码前作为一项专门的任务
    3、在开发中或者任何时候发现新的测试时
  测试总结
    1、验收测试可以用来记录客户和开发人员讨论的工作细节
    2、验收测试即可了有关故事的一些假设,这些假设可能还没有和开发人员讨论过
    3、验收测试提供可检查故事是否被完整实现的基本标准
    4、验收测试应有客户来写而不是开发人员
    5、验收测试应该在程序写代码之前就写好
    6、如果新的验收测试对阐明故事的细节活意图没有任何帮助,就不用再写
    7、验收测试应有客户来执行而不是开发人员
  

转载于:https://my.oschina.net/igooglezm/blog/846424

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值