产品待办事项列表臭味之愚蠢( un-SMART, No Acceptance Criteria)

每次到新的客户那里,总会发现在“做Scrum”的团队,它们不能在本Sprint完成所有的用户故事,因此在不少公司的Scrum团队中甚至衍生出了开发Sprint,测试Sprint。甚至在去年有一家自以为Scrum做的不错的公司,做了这方面的分享,自认为这是一个聪明的改进,把它称之为“具有其公司特色的Scrum”。

Handgunning-Front-Sight-Wrong2-300x229

症状

  • 开发Sprint、测试Sprint、T-6、Hardening Sprint、发布Sprint
  • Sprint结束的时候,大部分用户故事完不成
  • 测试人员要等到Sprint结尾的时候才开始测试Sprint计划会议承诺的故事
  • 很难给故事定义明确的验收条件
  • Sprint开始几天内,没有用户故事完成

诊断
在Backlog中,高优先级的那部分故事,应该是SMART的(Specific, Measurable, Attainable, Resource, Timely)。这跟设定目标一个道理,远期的目标可以是大的、方向性的;但是近期的目标一定要具体,可完成的。不SMART的高优先级故事,会导致如下问题:

  • 很难完成Sprint承诺,测试人员在测试上一个Sprint的故事时,发现的bug会冲击到本Sprint的计划,从而导致本Sprint的故事延期
  • 排优先级十分困难,需要pk已“完成”的故事中的bug与当前Sprint中故事的优先级
  • 很难获得准确的开发速率(Velocity),因此很难预测发布计划。由于每个Sprint中“完成”的故事,实际上并没有完成,造成了较高开发速率的假象,但是项目后期,还是需要很大投入去维护
  • 缺失团队统一的Sprint目标,开发和测试人员的目标不一致,而这些团队成员的目标又与组织的目标(把功能完成、上线、获得客户)不一致。很难形成团队合力。

症因

  • 开发测试人员之间角色过于分明,过于强调工作移交而不是协同
  • 开发团队不愿意帮助PO切分用户故事、定义验收条件
  • 团队不掌握需求切分的技能
  • 测试人员不情愿重复测试同一个功能
  • 缺乏自动化测试支持

处方

  • 引入周期性的产品待办事项梳理活动
  • 团队一起切高优先级的用户故事,确保故事粒度在单个Sprint可以完成4-10个范围内
  • 引入实例化需求(Specification By Example)实践、用例子描述验收条件,并将之变成自动化测试
  • 对于一个用户故事如果需要过多场景或者测试用例来验证,需要把它从用户角度切分
Share

0 comments

请输入正确的验证码