这是敏捷生态系统系列的第三篇（，，，，）。

产品负责人PO与团队的互动一直是一个难题。典型的问题在于：敏捷开发倡导“迭代期内无变更”以换取“团队承诺”，而实际上产品负责人却会不断地来提变更，打乱开发计划了。我们应该怎么办呢？产品负责人说“敏捷就是拥抱变化，我现在来提变化了，你们却关门了。”团队说“如果你总是变，下次我们怎么给你承诺。”

---

敏捷开发中的计划跟踪生态II大致如此（黑体字即图片中的元素）：

☺ 产品负责人（PO）与团队的正确互动是自组织团队正常运转的核心机制之一。

☺ 产品负责人的权利是统一管理和讲解需求以及需求优先级排序，而义务则是接受开发团队的估算，并承诺迭代期内不变更。

☺ 团队的权利在于开发人员自己估算，而义务则是接受产品负责人所设定的需求内容、实现标准、优先级排序，并对自己的估算做出团队承诺，这种承诺会造成整个团队受到激励。

☺ 产品负责人不能干预团队的估算，却可以挑战估算。挑战估算可以通过对比两个团队处理同类任务、对比以往同类任务与本次任务等方式进行。团队的荣誉感会令团队产生团队间的同行压力（与其他团队及与自己的过去相比），并进而产生受激励的个体。

☺ 作为自组织团队，产品负责人与团队互相没有领导关系，却通过分权与承诺管理，使得两者互相管理，从而产生更高的工作效率。

需求优先级排序-迭代期内无变更-团队承诺是这个生态的主线之一。

让我们重新看一下前面变与不变的例子。

简单粗暴的方法包括“一个强制性的变更或不变更制度”。即在高层领导的支持下（如果他们不支持，大家就放弃敏捷开发，你们说怎么办就怎么办，但别再提敏捷开发了！），团队坚持每个迭代都不变更。这个听起来很简单，但实际操作是有难度的。毕竟变更经常来自客户，团队怕产品负责人，所以搬出高层领导；产品负责人怕高层领导，会搬出客户。

另一种细腻一点的方法是制定一个“何为需求变更何为需求细化”的指南。毕竟有时候提前想的是一件事情，但具体做的时候才发现应该做成另外一个样子。难道大家真的应该二话不说先把错误的东西做出来，到下一个迭代再变更？这不是纯粹和自己较劲么。所以兴许我们不会把任务扔掉，但是却可以把任务的描述改动一下，作为“细化”来接受。这种指南有其现实意义，但万勿当作法律条文来办，因为很快就会发现有处于模糊状态的东西会引发争议。

其实终极解决方案，是顺着图中的线条向下看：团队承诺-迭代期内无变更-需求优先级排序。最后一个才是重点。

有几种原因会导致迭代期内变更，一种是发现了紧急的需求，一种是发现了更重要的需求，另外一种是发现需求和以前想的不一样。

第一种在中提到过，可以通过优先级分级的方法来容纳之；另外事先商定只有比如70%的时间可用，也可提供额外时间来处理，这里不多说了。

另外两种，则都是与优先级排序工作不到位有关的变更。

1. “来了更重要的需求”其实等同于“我们之前在做不重要的需求”。

尽管人们难以准确预测哪些需求真的最重要，但当我们从众多需求中挑选了极其有限的自然也是极其重要的需求放在迭代中，却能在短短的一个月内跳出一个更重要的需求（这个需求多半不在已知的“众多需求”中），就应该意识到之前的需求收集和排序工作肯定出了问题。原因或许是我们挑选了不称职的产品负责人，或产品负责人采用了错误的需求分析方法，或产品负责人工作在极端苛刻的环境中（比如客户拒绝透露需求）等等。这些问题看似可怕，但一旦摆上台面，解决它们比不知道原因地解决“迭代期内到底变更还是不变更”要容易得多。因为事关细节和具体环境，以后会有博文解决（部分已经计划在《》的章节中）。

2. “需求和以前想的不一样”听起来是一种无法避免的问题，但其实我们有很多工作可做。

尽管人们难以准确预测所有需求的实际内容，但却可以就部分内容做深入了解。具体实践包括：

• 在纵观大局的同时，产品负责人应时刻注意最重要的需求是否弄清楚了，应多就这些问题与客户探讨，防止被迫讲不清楚的需求发放给团队的情况。
• 应建立故事群的概念（在中有提到），即当零散的需求极难与客户沟通和获得反馈的时候，应就一组故事与客户反馈。这样不容易遗漏故事，也不容易对故事的排序疑惑，因为故事之间有可比性和依赖性。客户可能很难决定“一周节目单”重要还是“地区访问码”重要，但是却很容易判断“一周节目单”比“当月节目单”重要。

---

在具体工作时，团队不应该彻底放弃对优先级排序工作的思考，而是应该配合产品负责人做好这个工作，尤其是团队中高层次的对业务有所了解的人。

与之相对应的，是产品负责人也不应该彻底放弃对计划工作的思考，这就是下一篇将描述的开发团队自己估算-PO挑战估算-同行压力的生态线。

 

 点击下载免费的敏捷开发教材：《》