你想象中做计划的方式是不是这样:先确定要做哪些需求,其次针对这些需求评估工作量,从而确认整体的计划。执行过程与计划发生偏差的时候,延迟发布。
如果我告诉你还有另一种方式是这样的:计划的周期是固定的,然后评估需求的工作量,排不下的先砍掉放到下一个周期。执行过程与计划发生偏差的时候,砍掉功能以确保至少有一部分功能能够按时发布。通常叫做固定时间盒方式。
你会不会说:我们的需求就是固定的,这些一定要做完才能上线,我们已经承诺了客户了,做不完会被用户骂?
揭开固定时间盒的面纱
固定时间盒,只是定义了一个固定的周期,然后定义这段时间里需要做的事情,有可能几个时间盒之后才会有发布,也有可能一个时间盒结束后有一次发布,甚至有可能时间盒中间就会有发布。可以简单用下面三个图来标志:
目前笔者在团队实践的实际情况是,时间盒结束之后一般会伴随一次发布。
接下去,笔者介绍一下在自己的项目是如何通过固定时间盒来做计划的。完整流程的基本示意图如下:
解释一下上图:
所谓的固定时间盒指的是研发(开发+测试)的周期固定,上图中的周期是2周;
为了确保,前一个周期和后一个周期之间,开发不会存在等待的情况,那么相应的需求和设计必须在开发结束当前周期之前完成下一个周期的内容;
开发制定计划的时候,如果有排不下的功能,就自动延后到下一个周期。其实不只是开发阶段,就算是交互和视觉,甚至是策划阶段,当发现有做不完的工作,就自动调整到下一个周期。
固定时间盒的好处
首先,每一次计划不用再重复确认,策划稿什么时候确认,交互什么时候交付,视觉什么时候完成,开发什么时候提测都已经固定,不需要再额外沟通。这让所有角色对于未来的工作都很有规划性,比如作为交互这个角色,当他参加完需求评审之后,他就知道一周以后他得将交互稿设计出来。这对一些公共成员来说可能会很有价值,公共成员需要服务于多个产品,如果每个项目都有这样比较确定的节奏,他对于自己的工作规划就会很清晰,公用这个成员的项目组之间可以提前协调一个节奏,来避免对这个公共成员使用时间的冲突
由于需求会在各个阶段都有可能被砍掉,这使得团队对于需求优先级的评估更重视和谨慎。因为只要过程中出现一些偏差,当内部无法消化时,最低优先级的需求就会被砍掉,所以团队会仔细斟酌每个需求的优先级排序。我们会要求所有需求都是有唯一优先级的。这更能确保我们的团队在有限的时间内聚焦在最高优先级的事情上
固定的时间盒,让估算和计划变得更容易。由于每一次的计划都是相同的周期,各个角色对于这段时间能做多少事情越来越有概念,我上一个迭代做了多少事情,最终是紧张了还是宽松了,这个迭代就可以做相应的调整。对于需求团队,也是如此,需求同学也会对自己每个周期该准备多少需求,越来越有把握。对于不固定周期的版本,这方面的控制和把握会更难一些,因为要额外多一个时间的变量。
对于外部的期望做更好的管理。有的团队说,我无法做固定的迭代的原因是,我们没法管理我们的用户,用户说某个功能什么时候要,我不能告诉他我们是固定周期的,要等到下一个迭代。其实用户期望的管理可以更早就开始了,客户有的时候对需求的上线时间并没有那么高的要求,他们只是没有安全感,他们不相信我们,不确定你们会什么时候上线,所以他天然就把需求都说的很紧急,希望能尽快上线。如果我们能够提前将我们的节奏同步给对方,也许对方会更有安全感,他知道他应该在什么时候提需求,大概什么时候会有发布。如果有一些需求真的非常紧急,非得在某个时间上线,而这个时间并不是时间盒的最后一天,那也没关系,我们可以在时间盒的中期做一次发布,但是这并不影响我们以固定时间盒做计划。
三个问题,理解更深一步
问:如果需求,交互,视觉阶段,一层层砍下来,会发现,最终发现开发的排期并不饱和的时候怎么办?
答:这个时候我们就要去考虑分析前面的阶段,哪个环节砍掉的需求比较多,是什么原因?效率问题?还是人力配比的问题,然后定向解决。
问:时间盒的周期是不是越短越好?
答:缩短周期引入的成本:
1. 更短的周期会给团队引入更多的成本:如会议的时间,沟通的时间,计划的时间,测试回归,部署等工作的时间。
2. 更短的周期有时候也会给用户带来一些成本,如客户端的版本更新。
所以时间盒的周期建议是取一个平衡,目前2-4周的时间盒长度是比较常见的,如果需要更短的周期,则对自动化的要求也会更高,大家可以视团队和业务的情况决定。
问:迭代结束了,但是发现bug还没改完,肿么办?
答:
1. 首先我们要有这样一个共识,就是做10个半成品还不如做一个能够发布的功能。所以执行过程中一旦发现某个功能的bug无法收敛,就要及时干预,在后期如发现整体bug很多,而且收敛速度不好的时候,应该及时决策,舍弃一些功能,确保其他功能能够按时上线。当然这会对我们的分支管理提出了很高的要求。
2. 如果前期未能控制住,真的是在最后一天无法按时发布了,则意味着我们的整个计划都失败了,这个信息要传达给团队所有成员,让成员一起对这个情况负责,同时组织回顾分析原因,避免后续发生。剩余的bug,只能在下个迭代安排工作量解决并做发布。
结束语
以上是笔者自己在有限的项目经历下总结出来的关于固定时间盒的理解,如有不同意见,欢迎探讨交流!
本文来自微信公众号“网易杭研项目管理”(ID:NeteasePM),作者 何燕华。
管理圈经授权发布,如需转载请联系原作者。