明天咱们将从从产品指标到产品路线图、从产品路线图到公布打算、从公布打算到迭代打算、从迭代打算到迭代的落地执行四个方面来全面解读高效研发流程，这也是一套残缺流程中的四个步骤。
筹备好小本本听课吧！
一、从产品指标到产品路线图
满足用户诉求是产品的根底性能，在此之上还有一个更高的冀望，即产品的指标。通常状况下产品指标与产品的收益、市场份额、流水无关。在制订具体产品指标时，须要思考产品的商业模式以及产品所处的阶段。好的产品指标是具体的、可掂量的、绝对稳固的。
在进行产品指标阶段性地拆解时，须要思考拆解的维度与办法。除了依据阶段性的工夫维度进行拆分外，还能够依据产品的里程碑进行拆分。
二、从产品路线图到公布打算
在理解如何制订产品公布打算之前，咱们须要先理解一个工具：用户故事地图。用户故事地图实际上是一个残缺的用户故事。它能够帮忙咱们加强团队合作、洞察实在需要、打磨低劣产品。
想要创立用户故事地图，首先要有用户故事地图的框架。它的外围是一条从左到右的工夫线，而后从上到下依照演绎构造分为三个层级。这一条工夫线上方的一级粒度的性能需要，在工作中，咱们称之为 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 等。通过这种形式，可能对执行状况有清晰的认知，对执行过程产生踊跃的影响。
点击进入理解更多技术资讯~~