本文是敏捷开发产品管理系列的第五篇。(序言及设立迭代目标,产品版本规划,产品用户群规划,新产品研发,预估会议,Product Servant,Product Owner团队,产品线管理)
粗估会议是一个较少使用的敏捷实践,但其作用还是很明显的。
Why
Scrum里边,有两个关于需求的比较头疼的问题。
一个是PO不太懂技术,不知道故事大约需要多久才能完成。为什么PO要知道?因为如果划分的颗粒度不好,会导致有的故事太大或太小;而且如果不知道故事的大小,就比较难大致预测未来的几个迭代能做完哪些故事,版本计划不好做。
二个是如果只依赖短暂的Sprint Planning Meeing,往往团队对故事的理解不够深刻。人的思维方式往往是分为两种的:一种是集中思维,就是现场的讲解问答;另一种则是分散的思维,就是“回去以后越想越不对劲”的那种,后者如何利用呢?
开一个预估会议把。
When
有一家游戏公司,会在每次Sprint Planning Meeting前一天,先把整个迭代要开发的大致内容讲解一下。这次讲解,未必是按照故事条目来的,更多的是整体的介绍。因为游戏的需求相对复杂,而且关联关系很重,所以有必要整体把握以下。这很像拍摄电影,导演会把下一个场景整体介绍一下,才会分解镜头拍摄,否则整体感和连贯感会很差。
有一个日本企业,则是在30天迭代的第10天左右,开下一个迭代的预估会(或称为预测会也行),整体就是提前20天介绍一下下个月有什么事情要做。这个目的,则是让队员在剩下的20天里边,都会潜移默化地思考下个月的事情;另外就是在开发本月内容的时候,如果成本很低,会提前做一些准备工作(比如预留点接口。“过度设计”很容易造成浪费应该避免,但是为20天后的工作内容做准备,则极少会浪费,所以值得)。
How
在预估会上,PO给大家讲解整体需求,和他对下个迭代的期望,以及他提前拆分出来的几大块或几小块内容(看工作习惯了)。
团队会分析这些内容的关联性、实际工作内容、工作量规模等内容,必要时拆分故事,描述故事的依赖性,并进一步帮助PO形成条目化的用户故事。
PO在形成有工作量预估的用户故事后,会重新计算和规划下一个迭代的工作内容,让其能更完整地组成一个发布。
当然这次估算不一定准确,力求做到条目化和拆分即可,准确性由参会者在直觉上保证都可以,毕竟在计划会上还会细化。
Who
有时候整个团队参加,尤其那些对完整性要求比较高的产品,比如游戏。
有时候只让小组长或骨干参加,他们会把参会的内容传达给自己的队员;更少的参会人员,可以降低对其他无关人员的工作量占用影响。
这取决于产品和团队的情况,试着开几次会议,自然会发现怎样才是合适的。
TODO
PO开完会议后,可能有这样一些工作要做:
1. 记录下来最终被条目化的故事。
2. 在计划会之前,把会议上似是而非的一些内容敲定。
3. 根据故事的大致规模,规划下一个迭代的内容。应本着相对完整内聚的原则,组织成一个用户能真正拿到并完整工作的产品。
4. 按照MoSCoW排序出下个迭代的内容。(MoSCoW请参考http://cheny.blog.51cto.com/3988930/1100076 )
转载于:https://blog.51cto.com/cheny/1101222