在敏捷开发中,产品经理 (PO) 既是产品需求的定义者,又是开发项目的管理者。PO 使用用户故事 (User Story) 来定义产品的需求。那么一个用户故事是否完成了所有的开发工作,光 PO 说了算就可以了吗?
用户故事的完成应该由团队来定义
敏捷团队是一个自治的组织。PO 虽然是产品的所有者,但是他也是敏捷团队的成员。敏捷团队通过持续地沟通和协作来应对不对变化的需求。要让团队成员之间顺畅地沟通和协作,团队成员对团队工作的认可是必不可少的。而只有有高度使命感和责任感的团队才会自发地沟通和协作,而不是通过一层层的权利机制去驱动任务的完成。
通常来说,当一个人做出了承诺,他就会对承诺肩负起责任感。如果团队成员能够指定标准,他们也会成为标准的捍卫者。有鉴于此,团队应该在成立之初就要达成一个重要的协议:什么叫做做完了一个用户故事?
定义什么叫做完成?(Definition of Done)
理想的用户故事应该在完成以后,客户可以立即看到它的价值,所以它应该是一个完整的软件需求。一个有责任感的团队,会对用户故事的定义、代码的质量、测试的方案、测试的执行等提出自己的要求。在定义什么叫做完成时,Scrum Master 可以引导团队在下面几个方面达成一致:
- 用户故事定义的标准
AC是否明确,团队是否估算了故事点数等 - 代码质量
Code review, 单元测试代码覆盖率 - 测试相关
测试用例、API测试、功能测试 - 产品经理验收
完成定义和工作量估算的关系
我在与同事讨论“完成”的定义的时候,曾有同事提出,在产品上线以后没有问题了才叫做完成。如果是这样,用户故事就会在上线之前一直是未完成状态,这会带来一个明显的问题:我们没法估算团队在一个冲刺 (sprint) 里开发的速度。从这里可以看出,完成的定义应该和开发和测试工作的结束相关并且可以用来衡量团队的开发速度。
结论
本文提出用户故事的完成应该由团队来定义,只有这样团队才会对开发工作有使命感和责任感。本文还简单讨论了如何定义完成以及定义完成和开发工作量的关系。
|