这是敏捷开发日常跟进系列的第六篇。

 

产品负责人常常被描述成在计划会前准备好用户故事，在计划会上讲解并帮助开发团队估算后就万事大吉，只等月底接收“可工作软件”的样子，其实如果真的这样，很容易出问题。

需求精化

这是发生在迭代周期中间的常规活动，产品负责人会与团队密切接触（确切说如果能经常坐在一起更好），在每个故事开发的前夜或中间，将之前讲解过的用户故事更详细地描述一番（有时候是在看到开发一半的半成品后做一些细化或更正）。

一般认为产品负责人在开发的中间来打扰开发组工作是不令人欢迎的行为，那这两者之间到底区别何在呢？

在以后将会编写的一个《敏捷开发产品管理》系列中将会提到，产品负责人要做到“迭代期内无变更”，必须要做好长周期的研发管理，就是为每个版本每个迭代提前设定好目标。因此落实到具体迭代的时候，这个目标不是那么容易发生变化的，但“如何更好地达到这个目标”，则可能经常在变化。

需求精化的过程，就是产品负责人帮助团队更好地达到目标的过程。

“需求精化到底包含哪些活动？”确切说，只要把产品负责人和团队放在一起，什么事情都可能发生。

可能会对模糊的需求进行细化；可能会根据半成品做一些调整；可能给开发人员讲解一下用户背景……总之试一试，就知道了。

NEC的迭×××发中甚至有一个固定的时间（忘了是一个月中的第10天还是第20天），产品负责人会帮助全组对下一个迭代的故事进行一次提前通告，以帮助团队预测到以后发生的故事，从而略微地为未来做一些准备。这种准备既有提前了解业务的方面，也有潜在的在架构上为扩展做一些有限的准备。

跟进人，渐进评审

若开发组的人数众多，而产品负责人只有一个，他的工作会相当繁忙，顾此失彼。

跟进人制度是在产品负责人团队基础上建立起来的。所谓产品负责人团队，就是多个对产品了解的人组成一个团队，集体行使产品负责人的职责，典型的如软件或嵌入式产品研发中的产品总监-产品经理-产品专员团队，游戏团队中的主策划-策划组长-策划团队。

而跟进人，就是针对某个用户故事，指定相应的产品负责人团队的某个组员，来跟踪故事的开发进展。

跟进人最大的好处，是可以在用户故事一完成的时间点就进行评审、改进，防止了到最后却发现故事实现的不好，一则返工浪费时间，二则影响了上线日期（只能下个迭代修改）。

跟进人制度和渐进式评审在网络游戏的敏捷开发中非常普遍，原因是网游的策划人员比较多能完成跟进，而且对于“影响上线”比较敏感。

个人感觉跟进人制度和渐进式评审在普通研发中也应该推广，无论如何如果用户故事因为“只差一点，需要改进”而不能交付，要延期到下一迭代中，的确令人沮丧。

故事板安排技巧

故事板的一般概念就不多说了，无外乎几个栏目：待开发-开发中-待测试-测试中-待发布-发布之类的，大同小异。

一个技巧则是“开发中”这一列一定要窄，含义是不要同时开发多个故事，最好结束几个再开几个。目的是不要所有故事开始了却都没有结束，导致最后无法交付。

这也使得跟进人不会太忙乱于多个故事，可以一个一个介绍，一个一个评审。