高效研发流程

今天我们将从从产品目标到产品路线图、从产品路线图到发布计划、从发布计划到迭代计划、从迭代计划到迭代的落地执行四个方面来全面解读高效研发流程，这也是一套完整流程中的四个步骤。

准备好小本本听课吧！

一、从产品目标到产品路线图

满足用户诉求是产品的基础功能，在此之上还有一个更高的期望，即产品的目标。通常情况下产品目标与产品的收益、市场份额、流水有关。在制定具体产品目标时，需要考虑产品的商业模式以及产品所处的阶段。好的产品目标是具体的、可衡量的、相对稳定的。

在进行产品目标阶段性地拆解时，需要考虑拆解的维度与方法。除了根据阶段性的时间维度进行拆分外，还可以根据产品的里程碑进行拆分。

二、从产品路线图到发布计划

在了解如何制定产品发布计划之前，我们需要先了解一个工具：用户故事地图。用户故事地图实际上是一个完整的用户故事。它可以帮助我们增强团队协作、洞察真实需求、打磨优良产品。

想要创建用户故事地图，首先要有用户故事地图的框架。它的核心是一条从左到右的时间线，然后从上到下按照归纳结构分为三个层级。这一条时间线上方的一级粒度的功能需求，在工作中，我们称之为Epic，也就是橙色卡片。这条时间线下方的第一行为二级粒度的功能需求，在工作中，称之为Feature，是黄色卡片。在二级粒度功能下，蓝色的卡片为三级粒度的需求，工作中，称之为Story，是蓝色卡片。

此处我们提炼出了用户故事地图创建中五个重要的步骤：
① 一步一步写出你的故事
② 组织情节
③ 探索替代故事
④ 提取故事地图的主干
⑤ 切分出能帮你达成特定目标的任务

我们通过一个“训练智能机器人小A从起床到出门”的简单例子来更清楚的了解这五步骤。

首先我们使用蓝色卡片按照步骤写出每个任务，每张卡片只写一个任务，任务以动词开头，如“睁眼”、“关闹钟”、“穿拖鞋”、“叠被子”等等。然后按照任务的发生顺序从左到右的组织卡片摆放。

接下来第二步，对所有的任务进行提取，得到概括性的行为，把这些行为放到黄色卡片上，也就是feature。如：“睁眼”、“关闹钟”这些行为可以归为“醒来”后要做的事情；“穿拖鞋”、“叠被子”这两个行为可以归为“起来”后要做的事情。

接下来进入第三步：探索替代故事。细节、替代、变化和异常构成故事地图的主题。比如：时间充裕可以睡个回笼觉，楼上装修被提前吵醒等等可能发生的变化和异常。我们需要将这些任务补充进地图。

然后进入第四步：将一系列类似的任务提取出来，形成更大的目标。在类似任务的上方，放一张橙色的卡片,也就是之前提到的Epic,卡片贴上一个动词短语，使其足以覆盖其下方所有任务卡片所要表达的意思。例如：“起床”可以概括“醒来”和“起来”；“如厕”可以概括“如厕”和“刷牙”。

目前已经完成了较为完整的故事地图。然后进入第五步，切分出能达成特定目标的任务。先确定本次迭代需要完成的特性/目标，使用切分来识别和特定相关的所有任务和细节。

在“训练智能机器人小A从起床到出门”这个例子中，分为了三个版本。在第一个版本15分钟起床，回笼觉这张卡片明显是不需要放到其中的。在这些的story中选出满足15分钟起床的事务并将其放入都第一个版本中。至此我们也就完成了一个简单的用户故事地图的创建。

上面这张图片是实际工作中对用户故事地图的应用，可以看到在实际工作中完整的用户故事地图所包含的内容非常庞杂。

完成用户故事地图之后，就需要制订发布计划。在创建用户故事地图的第五步中，我们切分出了达成特定功能的任务目标，每一个发布计划都对应着一个版本。具体的步骤如下：

①Big Story进行细化讨论

②按照价值和重要程度进行版本规划

③确定每个版本的期望达成目标

④确定每个版本的内容

⑤团队达成共识

通过以上步骤，就基本确定了用户故事地图的发布计划。

三、从发布计划到迭代计划

第三部分主要讲解集中发布式模式这一常用的模式，在集中发布式模式中，一次发布包含多次迭代；在迭代发布模式中，一次发布等于一次迭代。

很多大型项目都在使用这一模式，通常是每月发布一次，一次发布包含四个迭代，四个迭代之后，发布一次版本。

从发布计划到迭代计划共包括四个内容。

1、用户故事拆分

用户故事的拆分对迭代速率有一定影响。对用户故事的拆分要做到拆分出的故事尽量小，但是要适当，并不是越小越好。避免出现一个迭代内无法完成的故事。

2、用户故事优先级

在完成用户故事拆分后，需要对用户故事的优先级进行排序。用户故事的排序其实是对需求的一个排序，优先级排序有许多方法，如高中低、数字排序、衣服尺码L、XL等方式。优先级决定排入迭代的顺序。

以一个两周的迭代时间为例，假设我们有这样一个需求，前面的数字是需求卡片的序号，后面的数字从100到45，这是项目优先级排序的一个方式。每一次迭代能做4个卡片时，我们就会把优先级最高的卡片放入迭代池。

而当第二次迭代时，需求发生了变化，出现了x和y两个新的需求，x和y有着较高的优先级，那么我们仍然将优先级最高的四个卡片放入迭代池中。

第三次迭代中又插入了新需求z，需求z也有较高的优先级，那么当我们进行迭代的时候，需求z就会顶替另一个需求被放入迭代池中。

通过以上的例子可以看到，在原本的迭代计划中，12张卡片会被按顺序放入迭代池中，而真实情况是插入了更高优先级的需求，替换了低优先级的需求，把低优先级的需求放入了下一次迭代中。这就是优先级排序对迭代计划的影响。

3、用户故事估算

在迭代之前，需要对用户故事进行估算，用户故事估算实际上是对工作量的估算。这个工作量体现的是团队均值能力。

通常在公司内有不同级别的员工，高级别的员工和低级别的员工完成同一任务所需的时间是不同的。所以在进行用户故事估算时就需要规避掉技能的差异，根据团队的均值能力来进行估算。

用户故事估算通常参考是团队的历史数据，我们可以从历史数据中进行合理的估算。而没有这种历史数据的团队，可以参考一下类似团队的数据。当这两者都不具备时，就只能采用本能估算的方式了。

4、迭代计划制定

当前面三步全部完成后，才能开始指定迭代计划。

将已拆分好的用户故事按照优先级依次放入迭代池中，对每个要进行迭代的用户故事进行估算，确定好迭代的时间期限。所以我们就制定出了迭代计划。

当需求变更，团队人员进行调整以及预估不准确时，我们需要对迭代计划进行调整。调整方式有：范围调整、需求置换；延期；加人、加班赶工三种方式。

我们推荐采用范围调整、需求置换这一方式，也就是前面提到过的，插入高优先级用户故事，顺延低优先级故事到下一次迭代的方式。

四、从迭代计划到迭代的落地执行

对于一个团队来说需要通过迭代计划会、站会、需求评审会、迭代回顾会等会议对计划进行分析和迭代，然后进行开发和测试。在整个过程中无论是开发还是测试都是以story的力度进行的。分析、开发与测试这三个步骤是并行的。

团队可以使用卡片墙标注完成的任务和未完成的任务以及遇到的bug等。通过这种方式，能够对执行情况有清晰的认知，对执行过程产生积极的影响。

点击进入了解更多技术资讯~~