很多团队认为,敏捷的价值观是“拥抱变化胜于执行计划”。那么,既然咱们做敏捷了,那就不用做什么计划了。
6 ]: H! ?. G" H: l4 e' M: U
这是对敏捷价值观的误解。如果完全没有计划,团队一定会得过且过,没有危机感,致使项目一片混乱。这样的话,前几节介绍的商业模式、产品愿景都将无法落地实现。我在前面介绍的Sprint计划和看板填充节奏都是敏捷里的计划活动,但敏捷计划不只是这些。
# q& ~/ T+ o/ B' E$ f! p4 A _
很多敏捷团队非常专注于眼前的工作,只关注当前迭代的交付,或者是那些已经进入看板就绪队列的需求的交付,但是对产品下一步要做什么、未来要做什么都不清楚。
8 y6 d& ?, J. Z
实际上,产品规划是在多个层面上持续进行的活动,我称之为“洋葱圈规划”,如图8-12所示。 7 a. L' n: n2 V$ [4 Q& U
8 k' Z7 t9 Q4 l$ d3 J% U
图8-12洋葱圈规划示意图
! U) ^ _) I; |. Q5 U6 f
表8-3介绍了各层级计划活动的时间节奏、活动参与人和计划的重点内容。 % C* b3 G& L, j
表8-3各层级计划内容一览表 + v+ d ]2 @6 W5 M' b) C
第1层:投资组合计划
& y9 G- s3 `+ A" d; R4 W+ j1 b. A
一个企业或业务部门一般会并行管理多个产品,这时需要在整个组织层面规划好要投资做哪些产品、要对哪些产品撤出投资,以及正在做的产品准备何时上市。
. j8 o+ v! R4 s9 J( F$ C+ |
投资组合计划除了规划整个组织的产品研发上线时间,还需要规划产品的预算、人力等成本。 : O+ S# U/ P/ u, W! T5 c2 \
第2层:产品路线图计划
5 n2 t8 {/ O$ L# a! ~. S, z( E- [9 a
对于一个创新产品而言,在团队创建了商业模式和产品愿景,并用第一版MMR探索了市场反馈之后,团队对需要做哪些优化心里更加有谱。这时,团队可以规划相对长期的产品路线图。 3 i# q8 S0 U, d2 F g0 Q/ V) H* Z
团队通常产品路线图以季度或月度为单位,来规划即将发布的产品的重大特性。产品路线图包括以下内容: * F& w* }% w) z- r
- 重要版本的发布时间;
- 重要版本的名称;
- 重要版本要实现的目标;
- 重要版本的特性(这些特性不需要做详细拆分)。
* c# U* d R/ _" u0 Y5 }- D
1 E4 c% U+ q- r* m
产品路线图计划是渐进明晰的,即发布时间越近,产品特性越明确,交付时间越准确;发布时间越远,产品特性越不明晰,启动时间越不明确。当时间节点到的时候,一般团队会召集人员对产品路线图的实施情况进行评审,并对产品路线图进行更新。 3 x) U7 G0 F& ^6 G H6 I: P. P7 [
第3层:版本计划
9 ~& f2 W% R2 X- f! X8 [7 I& K( P
在产品路线图的每个时间段内都会有一个或多个版本发布。产品路线图规划了某个时间节点上要交付的产品特性;而版本计划则更加详细,团队不仅需要将特性拆分成最小价值单元的用户故事,还要依据团队的速率数据,计划一个版本的完成需要多少个迭代。版本计划也是渐进明晰的,即相对于当前版本计划,越往后的版本计划越粗略,特性拆分的粒度也越粗。
5 t% T/ g3 ^1 s; `7 v3 V
团队支付一个版本后,一般会召开版本评审会议和回顾会议,其流程与Sprint评审会议、Sprint回顾会议相似。所以,团队在版本最后一个迭代的时候,可以将Sprint评审会议和回顾会议的范围拓展到对整个版本的评审和回顾。 , P: H# r' A# q1 Z0 i7 I* w
第4层:迭代计划
; e8 ?1 ]. T4 }7 o1 e0 \
一个版本可能会经过多个迭代才能完成。每个迭代都要有明确的计划,当迭代结束时,团队要召开评审和回顾会议。
# q4 @9 \3 I6 W- C, b
需要说明的是,很多互联网团队的交付能力比较成熟,每个迭代甚至在每天都会发布多个版本。这说明,版本周期小于迭代周期。在这种情况下,团队一般不需要召开评审和回顾会议。 5 h) T; d8 l% w6 D h
第5层:每日站会
7 {9 h+ b/ Z& F& B b4 a* m
每日站会是团队成员每天对项目情况进行审视,并计划当天的工作的活动。因此,每日站会是最小单元的计划活动。 8 A5 O; u. ~* p6 T" b. |% g
6 B6 j" E }+ N
/ q% _/ [6 Y0 g- A+ l
|