产品经理对于如何做版本迭代规划,有时总会产生无力感,要么是计划难以确定下来,要么是制定好的计划无法执行下去,这个问题的原因很复杂。在项目初期,我们缺少对产品的全局概念和整体把握,内部意见很难统一;再者,没有一个完整的用户体验或者价值流导向,对于每个迭代无法合理定制出可交付产品增量。
之前我们讲过如何构建产品路线图,路线图可以给PO和团队整体方向的指导,但更具体的内容,需要用户故事地图的方式,通过横向的框架和纵向的任务,将一个产品完整的展示出来。然后,再通过故事点估算和优先级的排序,来确定版本迭代计划。
版本迭代其实是一个路线图,展示了将要实施哪些功能以及何时完成这些功能的期望。通常遵照团队自己的节奏,有的是一个Sprint 一个Release,有的将多个Sprint归为一个Release中,如下图所示。还有的在每个功能完成后立即发布,这也通常被称为持续部署或持续交付。
根据产品开发的策略,它可以由功能驱动,目标是一旦开发出预期的功能模块就发布; 或者由日期驱动,过了预定的检查点就发布。
具体如何做呢?我们可以分这个步骤来完成。
1. 创建用户故事地图
和客户一起,厘清产品的用户角色,并尽可能多地写出用户的行为,以及每个用户行为下需要做的事情,然后按照用户行为从左到右讲故事。当大家把自己所能想到的故事地图都放上去之后,再合并增减故事,最后会形成一个二维故事地图。
2. 构建产品发布路线图
整个故事地图会包含很多故事点,但在一定时间完成所有功能是不太可能的,团队要综合考虑商业价值、市场现状、实现难度等方面因素,确定接下来几个发布的内容,以及每个发布预期能达成的目标。
3. 快速估算
用户故事创建好后,我们可以对地图中的所有任务进行快速估算,以便于能够知道我们整个Release要发布产品的所需大概工作量。不同于Sprint中对故事的估算,这里更粗略更快速,可以用故事点或者T恤size(S, M, L , XL)来制订我们的估算标准。
4. 制定Release计划
前面工作完成后,我们对于整体产品和开发时间会有一个大概的估计,那么就可以设计Release计划了。我们可以按照我们的估算,设计一个Release需要发布哪些特性,然后包括几个Sprints,下图为Release计划示例。
再将故事按照优先级和价值进行排序放回到每个Sprint里,可以利用一些迭代规划的在线工具,如下图把右侧产品Backlog的内容,自由拖动到左侧的Sprint中。
5. 产品发布日历
在计划会议之后,最终确定详细信息,进行任何最后调整,然后与所有利益相关者共享产品发布日历。
本文作者:Kaya
首发于Worktile官方博客,如转载请注明出处。
原文链接:https://worktile.com/blog/design/how-to-release-planning