1 任务拆解概览图

参考文章 JIRA配置之问题类型，我们知道了史诗，故事，任务分别是什么定义？

那么我们在实际敏捷开发工作中，如何将大的需求一步步拆解出来，再分配到研发团队成员名下，大家通过团队合作，最终交付可工作的软件的呢？

如下图所示：

2 工作事项的拆分

我们把工作事项分为四个层级，level1～4。

level1:史诗级需求，比如做一个网站的支付系统，这样的需求不是一个人能完成的，也不是一个冲刺周期就能完成的，史诗级需求需要进一步拆解。

史诗级需求应该是产品经理在做产品/项目初期规划的时候就定义好的。

level2: 需求->故事，把史诗级拆解成可以更小的需求，需求再拆解成更小的故事

那么故事就是需求的最小单元，而且故事一定是在一个冲刺周期范围内可以做完的，一般来讲一个5～8人的scrum team，一个冲刺可以完成6～15个故事。故事数量太少，就失去了敏捷的灵活性，故事数量太多，又使得团队分工过于复杂。建议10个左右是比较合适的。

需求/故事一般是产品经理前置研发冲刺一个月的时间，就开始创建的。基于大的史诗级需求和用户调研，竞品分析等结果，渐进明细地定义具体要做的故事。

故事是由产品经理创建，冲刺启动后责任人转移到研发人员，进入测试后又转移到测试人员名下，最后交付验收的时候，又转移给产品经理做最后的确认验收。

故事拆解需要满足 invest 原则

1、独立的(Independent)

独立性和传统软件工程的松耦合的概念有异曲同工之妙。强调用户故事与用户故事之间不要有太多的依赖，因为有依赖的不同故事，可能优先级是不同，这就会给故事的工作量估计，以及故事在开发迭代的排期造成困扰。

2、可协商的（Negotiable）：故事是可以协商，故事卡是用户功能的简单描述，细节需要在客户与开发团队的讨论中产生。

3、有价值的（Valuable）

故事是以客户或用户的视角来书写，通常是业务语言而非技术语言。在故事中自然体现这个功能具体给用户带来的价值是什么。

4、可估算的（Estimate）：每个故事都对应估计的故事点数，即工作量应该是可以度量的。开发人员可以根据所业务领域的知识和相关技术经验来估计每个用户故事可能对应的故事点数。基于每个用户故事的故事点数的估算，确保纳入每次迭代的故事的总故事点数不会超过开发团队的速率，即处理能力。

5、小的（Small）：每个故事可以小到在一次开发迭代中就可以完成。合适的故事大小最终取决于团队的速率，以及所使用的技术。我们可以考虑把一些大的史诗故事通过某些规则分解为更小的可在一个迭代中就可以完成的小的故事。

6、可测量的（Testable）：故事必须是可测量的，这个和每个故事必须对应验收条件是息息相关的。可度量的验收指标是不可少的，比如系统的可用性为99.99%，99%的情况下，打开一个页面的时间不能超过2秒等。

level3: 研发任务，这里的任务可以是从故事拆解而来，也可以一些非需求类的任务，比如，接口升级，文档，资源部署之类的事情。这里的任务拆分颗粒度是责任到人的，也就是说一个任务 是由一个经办人完全负责其全过程的（便于做研发效能统计）。而且为了保证评估的精确性，建议单个任务的工作量大小不超过2days（保证项目估时的准确性）。在冲刺启动的第一天，就要根据产品经理安排的冲刺故事去拆解和创建研发任务。

测试计划，也是测试人员基于产品经理安排的冲刺故事去做一些测试工作量的评估而创建的。

level4: 测试用例：测试用例一般是冲刺启动2～3天后，测试负责人根据具体要做的故事，定义出来的若干个测试用例，测试用例归属于测试计划，同时又和故事有关联关系。

缺陷：是当故事进入提测状态后，相关的测试用例执行失败了，从而由测试负责人创建出来的，分配给研发人员处理的事项，一个版本缺陷的数量和千行代码缺陷数用于衡量研发过程中的产品质量。

故障：是指产品上线后，用户发现的问题，故障通常和迭代的需求没有关系，但是故障的优先级又很高，需要立即处理。如果没有明确的故障管理机制，就会打乱整个研发冲刺计划，导致整个项目的延期。特别是对于第一次上线的产品，往往会产生大量的线上故障。这里的故障管理机制，可以参考文章 JIRA之变更处理

3 冲刺的拆分？

介绍完工作事项的四个层级，那么这么多的工作事项从时间的维度又是从何拆分的？

从图中可以看到，从时间维度，划分了三个 sprint，

sprint1（week1～2）:史诗1的部分需求，需求1的故事1～n，需求2的故事1，以及这些故事对应的任务，这个sprint的测试计划，测试用例，缺陷，故障等。

sprint2（week3～4）:史诗1的需求2，史诗2的需求3，需求2的剩余故事，需求3的故事1～n，以及这些故事对应的任务，这个sprint的测试计划，测试用例，缺陷，故障等。

sprint3（week5～6）:史诗2的需求4，需求4的故事1～n，以及这些故事对应的任务，这个sprint的测试计划，测试用例，缺陷，故障等。

参考如下图片

4 版本的拆分？

如上图所示，V0.1.0的范围包括：故事1～6，V0.2.0的范围包括：故事7～11.

关于版本的定义和管理，参考文章JIRA之版本管理

版本和冲刺的关系？

版本是向客户发布软件的实际版本，当一个冲刺结束的时候，可以有一个版本发布上线，也可以两个冲刺合并一个版本发布，也可以一个冲刺发布两个版本。版本的范围通常也是由产品经理来定义的。在实际敏捷管理中，为了简化流程，通常会定义一个冲刺上线一个版本，把冲刺范围和版本范围划等号，但是记住这不是必须的。