高效研发流程

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

准备好小本本听课吧!
一、从产品目标到产品路线图 满足用户诉求是产品的基础功能,在此之上还有一个更高的期望,即产品的目标。通常情况下产品目标与产品的收益、市场份额、流水有关。在制定具体产品目标时,需要考虑产品的商业模式以及产品所处的阶段。好的产品目标是具体的、可衡量的、相对稳定的。
在进行产品目标阶段性地拆解时,需要考虑拆解的维度与方法。除了根据阶段性的时间维度进行拆分外,还可以根据产品的里程碑进行拆分。
二、从产品路线图到发布计划 在了解如何制定产品发布计划之前,我们需要先了解一个工具:用户故事地图。用户故事地图实际上是一个完整的用户故事。它可以帮助我们增强团队协作、洞察真实需求、打磨优良产品。
想要创建用户故事地图,首先要有用户故事地图的框架。它的核心是一条从左到右的时间线,然后从上到下按照归纳结构分为三个层级。这一条时间线上方的一级粒度的功能需求,在工作中,我们称之为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等。通过这种方式,能够对执行情况有清晰的认知,对执行过程产生积极的影响。
点击进入了解更多技术资讯~~

    推荐阅读