如何将用户故事细化为开发任务

原文出处：http://www.softwareandi.com/2011/11/how-to-break-user-story-into-tasks.html

 

将用户故事细化分解成开发任务是Scrum中最隐晦的，这种细化分解通常发生在Sprint Planning会议的后半段。在我培训辅导敏捷的过程中，被问到最多的问题是:"如何把用户故事分解成开发任务"？

 

问题定义

我最满意的对于用户故事的定义是用户故事是一个简单、纵向划分的功能，用来描述对于用户（或客户）而言的一个价值增量。

而开发任务则是指开发团队为了完全满足用户故事的需求，需要采取的一个步骤。一般情况下，我会将开发任务限定在1到2天来完成。

所以问题便成了，团队需要哪些具体的步骤来完成一个用户故事？

 

审视你的软件架构

不管怎样，你的项目都会有一个软件架构。它可能是由架构师团队精心从中抽取出来的，反映宏观概念的架构图表。你可以从图表中看看，哪些组件将会在实现用户故事中需要被需该。

举个例子，假如我们有这样一个支持多种网络社交的网站产品。有一个这样的用户故事：为了拓展社交圈子，作为用户，我希望可以从gmail中导入联系人信息。对于这类产品的典型架构，我定义的开发任务可能是：

• 增加新的“联系人导入”页面
• 增加一个从Gmail获取联系人信息的后台服务
• 修改Contact类以适配Gmail的数据格式（假定需要）
• 修改联系人的数据模式

如果以上这些任务大小适中（均在4-16小时），那么开发任务就完成了。如果其中某个任务还是太大，我们需要再对它进行分解。如果某个任务太小，我们可以将它和相关的任务进行合并（当然，如果没有合适的合并任务，也不要担忧，我的4-16规则只是作为参考）。这样，我们已经定义好了用来编码完成用户故事的所有任务了。

 

审视DONE的定义

当然，仅仅从编码上完成故事是不充分的，在Scrum里面，"DONE"意味着交付，或者我想可以这么定义：该用户故事可以被客户/用户接受。敏捷团队都有一系列用户故事的完成标准。所以，你同时需要看看你的完成定义，是否还有其他任务。

假定，我们的DoD包括以下几条：

• 代码完成
• 自动化用户接受测试
• 文档已经更新
• 新功能被加入到发布包（e.g. InstallShield）

这样的话，你需要增加一些任务帮你达到用户故事的完成标准（DoD）.对于以上的列子，你可能需要做：