所谓生态系统，就是指互相依赖方能生存的一系列生物。生态系统常常不是单向依赖的，而是互相依赖互相促进。

敏捷开发中的实践也是如此。典型地，当一个实践很难实施时，一定不要认为简单的制度可以保证其实施，而是要思考是什么导致了它的失败。比如每日立会，如果发现大家都不按时开会甚至不开会，马上要做的不是要求大家按时开会+开会迟到给大家买水果+统计每月按时比例+……而是要想一想为什么这些人不按时来，他们一定觉得这个会议不是很重要，会上讲的东西听的东西不能帮助自己的工作，反而耽误时间。进而就能发现会议开不好的根本问题。

敏捷开发中需求管理生态大致如下（请配合插图，黑体字即插图中的元素）：

• 客户价值导向是敏捷开发需求管理的主要思想。
• 敏捷开发相信密切与客户协作比编写详尽的文档更能弄清楚客户的需求；而利用阶段性的可工作软件外加邀请客户参与评审会，比让客户评审需求文档更容易让客户正确地补充需求和验收产品。
• 由于相信变化后的软件一定比变化前的对客户更有价值，所以敏捷崇尚响应变化。提供可工作产品来引导客户变化，可保证客户更能正确翔实地描述变化；而迭代交付则使得重要的、必要的变化可以提前交付，而不是像瀑布模型一样最后才发生。
• 通过需求优先级排序和迭代交付，首先可保证重要的需求一定可以交付到客户手中；其次可以保证重要的变更来临时，可以放弃尚未开发的次要需求作为交换；再次可以保证产品负责人（PO）会优先分析重要的需求，不会让它们在模糊状态进入开发。
• 只有最高优先级的需求才会进入下一迭代，因此很少有变更比它们更重要，而且这些需求也被较深入地分析过，产品负责人就有信心承诺迭代期内无变更，以换取团队承诺，进而保持交付以可持续的步调发生。
• 拥抱变化是一种由客户协作、优先级排序、可工作软件等各种实践支撑下的、主动的可控过程，而不是被动地“被变化拥抱”，“迭代期内无变更”和“拥抱变化”的对立统一，必须建立在这些实践的基础上。

客户价值导向-可工作软件-响应变化这三条是需求管理生态的核心内容。

下面从一个问题的分析来看需求管理生态的工作原理。

“为何客户在评审会上不置可否，只说让我们继续开发一些功能后再说？”

这是一种很常见的场景，简单粗暴的处理方法包括：

1. 若评审会上没有意见，就表明认可了功能。

2. 评审会结束后必须书面验收已经完成的功能。

3. ……

不过这些仅仅是粗暴地执行Scrum的实践，而没有获得Scrum的精神。

仔细分析一下，客户这样做的原因很多，其中一些我们不容易控制，另外一些则相反：

1. 客户送来的代表是个“小角色”，无法替客户决策。

2. 我们的软件在客户眼中不是一个“可工作的”软件，因此他不能或不想太早下结论。

3. ……

针对1这类“不可控”问题，在实际环境中其实都有各种解决方法，只是作用大小而已。比如将每次的评审功能抄送给对方的负责人以引起重视；让功能的最终使用者参与评审等等，具体情况具体分析，这里就不多说了。

针对2这类“可控”问题，可做的就很多了。

什么是可工作软件？在研发人员眼中，可工作软件很容易等同于可运行的软件，“它能跑在我们的测试服务器上，我们还有自动化脚本能自动运行和测试其功能……”但在客户和用户眼中，可工作软件是那种他们现在就可以拿回去用的软件。比如一个Word软件，如果能编辑但是不能分段；能插入标题但是字体一样大；能插入图片但暂时只是一个链接需要双击才能打开……这三样功能都是至关重要的功能，但把它们临时凑在一起的软件，并不能让用户真正使用起来。还不如做一个“暂时只能编辑，不过可以分段、缩进，适合写简单的无复杂格式的文本，比如私人邮件（现在Outlook中还有个选项是用Word编辑邮件）”，看到这样一个软件，尽管客户不会接受这就是他们最终得到的产品，但是却可以理解在这样的场景中，这个软件到底好不好用，如果要改进改进哪里等等。

或许为了制造这个软件，我们一定程度上打破了优先级排序（“插入标题”比“缩进”要来得重要），但却使得“可交付”和“客户评审”成为现实。其实从这个角度看，我们反而在以客户价值驱动的方式生产着软件，也就是说“可运行软件”要从“客户价值驱动”的角度来定义。

好了，要解决这个问题答案就出来了：我们多半会把Product Backlog划分为若干故事群，每个故事群大致可以完整交付；我们提前让客户参与制定故事群开发的排序工作，这样客户就知道什么时候将发布什么功能，以及自己来评审什么功能；在完整地看到一组功能后，客户更容易得出“这一切是否可行”的结论；如果他们愿意，还可以提前部署上试用一下……

个人感觉在应用敏捷实践时，虽然不能迷信其普适性，但也千万别在遇到挫折的时候马上否定，或将问题归结为文化和公司环境；作为开发和管理人员，我们极有可能少或多做了什么事情。

有读者在图中的右侧可能看到了“迭代期内不变更-团队承诺”这条很重要的生态线，将在以后的“计划跟踪”中提到。

如果说需求管理中尚有一些团队无法控制的因素导致实施困难，计划与跟踪过程总归就没有问题了吧？其实不然，笔者见过领导很放权的全团（很多是因为领导根本管不过来了），但在团队内部仍然存在很大的问题，一般最为突出的，就是每日立会开得毫无生机。这不完全是因为文化差异问题，而是生态系统出了问题。

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

• 跨职能团队的整体思路是“每个人可以做每个工作”。好处是消除了资源分配的瓶颈和造成队员无法互助的分工壁垒。
• 任务应该先估算后分配给个人，以便整个团队（或至少其中的某个小组）都对其保持兴趣，才可能进行真正的共同估算。
• 共同估算（一般采用扑克牌估算）中人们利用整个团队的智慧充分讨论和确认任务的实现目标和方法，因此PO会统一管理/讲解需求，以防止个体理解差异。共同估算是共同跟进的基础，在每日立会中人们之所以关注别人的进展，就是因为人们关心自己曾经参与的估算结果是否正确，方案是否可行
• 共同估算和每日立会产生了同行压力，即每个人都希望以好于或至少持平于团队估算的结果完成任务，从而产生了受激励的个体。
• 共同估算和每日立会还防止个体失误，前者通过统一了大家对同一个需求的理解和其实现方法的理解，后者则防止了工作中出现需求镀金、蛮干等问题，从而产生更好的技能和设计。
• 作为自组织团队，敏捷团队并非简单地因为“领导让我们自我管理”而受到激励，而是在跨职能团队、共同估算、个体交互、同行压力这些实践的配合下才产生了受激励的个体和更好的技能和设计，从而产生更好的工作效率。

跨职能团队-共同估算-每日立会-同行压力是这个生态系统的主线之一。

如果从每日立会的例子看，要解决每日立会问题并不难，可以简单地：

1. 由Scrum Master监督必须召开每日立会

2. 统计每日立会的执行情况

3. 设立按时完成奖和迟到罚款箱

4. ……

这些方法有很多公司都用过，笔者早期知道这些方法时，还真的以为这样就可以了呢，直到后来听说沉闷的每日立会越来越多，才知道存在深层问题。

从生态系统的角度怎样看待呢？

第一个要怀疑的是是否进行了共同估算。如果大家都对别人的任务不了解，也从来没有参与其中（，那么自然就像听天书一样听别人讲；而如果别人对自己的任务不了解，那么即使遇到困难，告诉他们又有何用？（除了表明自己笨……）最终就形成了沉闷的每日立会。

但如果继续分析下去，共同估算的根源又在跨职能团队。这里之所以只把“先估算后分配”当作一个小跳板，是因为不能简单地认为“因为大家不知道会分给谁，所以不得不一起估算”，大家迟早会形成习惯性分工的，所有人都会知道哪个任务其实肯定分给别人。只有“每个人都能做每个任务”的跨职能团队才能解决这个问题。

建立跨职能团队是个难题，个人感觉不可能强制三四个人无缘无故地就跨职能了，他们私下里都会自动形成强分工体系的。一个好的方法是利用师徒制度和松结对编程建立稳固的团队关系，责权利统一远远易于改变团队文化。

尽管计划跟踪整体上是团队内部的事情，但是却可能在计划的时候被强制多做事情，而在跟踪途中又被加入变更而时间点不变。怎样处理这些问题呢？这就是计划跟踪生态系统的另一条生态线，将在下一篇文章中描述。

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

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

• 产品负责人（PO）与团队的正确互动是自组织团队正常运转的核心机制之一。
• 产品负责人的权利是统一管理和讲解需求以及需求优先级排序，而义务则是接受开发团队的估算，并承诺迭代期内不变更。
• 团队的权利在于开发人员自己估算，而义务则是接受产品负责人所设定的需求内容、实现标准、优先级排序，并对自己的估算做出团队承诺，这种承诺会造成整个团队受到激励。
• 产品负责人不能干预团队的估算，却可以挑战估算。挑战估算可以通过对比两个团队处理同类任务、对比以往同类任务与本次任务等方式进行。团队的荣誉感会令团队产生团队间的同行压力（与其他团队及与自己的过去相比），并进而产生受激励的个体
• 作为自组织团队，产品负责人与团队互相没有领导关系，却通过分权与承诺管理，使得两者互相管理，从而产生更高的工作效率。

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

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

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

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

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

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

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

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

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

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

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

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

在纵观大局的同时，产品负责人应时刻注意最重要的需求是否弄清楚了，应多就这些问题与客户探讨，防止被迫讲不清楚的需求发放给团队的情况。

应建立故事群的概念（在之一中有提到），即当零散的需求极难与客户沟通和获得反馈的时候，应就一组故事与客户反馈。这样不容易遗漏故事，也不容易对故事的排序疑惑，因为故事之间有可比性和依赖性。客户可能很难决定“一周节目单”重要还是“地区访问码”重要，但是却很容易判断“一周节目单”比“当月节目单”重要。
在具体工作时，团队不应该彻底放弃对优先级排序工作的思考，而是应该配合产品负责人做好这个工作，尤其是团队中高层次的对业务有所了解的人。

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

一半内容属于需求管理生态，一半内容属于计划跟踪生态。

在实际开发环境中，产品负责人常常和开发组存在潜在的利益对立。前者往往希望在更短的时间开发出更多的功能，而后者的绩效则多数来自于计划按时率/缺陷率这些会因“更短-更多”而下降的数据，于是两者的隔阂从此开始。

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

• 产品负责人（PO）与团队的正确互动是自组织团队正常运转的核心机制之一。
• 产品负责人的权利是统一管理和讲解需求以及需求优先级排序，而义务则是接受开发团队的估算，并承诺迭代期内不变更。
• 团队的权利在于开发人员自己估算，而义务则是接受产品负责人所设定的需求内容、实现标准、优先级排序，并对自己的估算做出团队承诺，这种承诺会造成整个团队受到激励。
• 产品负责人不能干预团队的估算，却可以挑战估算。挑战估算可以通过对比两个团队处理同类任务、对比以往同类任务与本次任务等方式进行。团队的荣誉感会令团队产生团队间的同行压力（与其他团队及与自己的过去相比），并进而产生受激励的个体。
• 作为自组织团队，产品负责人与团队互相没有领导关系，却通过分权与承诺管理，使得两者互相管理，从而产生更高的工作效率。

自组织团队-开发团队自己估算-PO挑战估算-同行压力是这个生态的主线之一。

让我们重新看一下前面产品负责人与团队矛盾的例子。

简单粗暴的解决办法无外乎此：

1. 规定产品负责人完全不得干预估算

2. 规定无论接受了任何挑战（质询），团队最终对估算结果拥有决定权

这些看起来都是很好很符合Scrum思想的制度，但是执行起来却早晚出问题。 我们假设在项目开发环境中，产品负责人是一个销售/售前*（或者拥有与其相似的绩效机制的人），他的绩效来自于合同额+客户满意度，从合同额中提取X%作为奖金；而开发团队的绩效来自于与计划相比的按时完成率+缺陷率。这个结构已经确定了两者的心法将背道而驰，无论任何研发方法论都不可能统一两者的思维。很快前者就会祭出客户来打破公司制度，而高层捍卫Scrum的决心远远低于捍卫销售额的决心，制度很快名存实亡。

怎么办？从“自组织团队”的根基下手。

笔者正在筹备一个“自组织团队系列”，其中第一篇已经处于草稿状态（截至2011-08-16）。这一篇的名字叫“用中医理论管理团队”。由于限于医学技术，中医始终不知道“细菌”“病毒”这些外部因素的存在，而只知道生病是人体自身存在了问题，比如“肝火上升致邪气入侵”，因此类似针灸这种完全没有任何药物的治疗方法也非常有效。对于一个敏捷团队，要理顺产品负责人和团队的关系，首要的就是调理好团队的利益。

在敏捷外包工程之二：人员结构中提到过三个公司，一个将项目额的10%给予团队作为奖金，一个将研发成本计入产品部门的成本，一个将实施成本计入销售人员的销售成本，从而很大程度上统一了产品负责人和团队的认识。这三个团队及其他类似团队的做法可归纳为两条：

1. 将研发成本计入销售成本。

此举将保证产品负责人（有时是一个团队）将非常在意客户是否真的需要某个功能，而不是本着越多越好、盲目讨好客户的原则办事。

2. 将项目收入下放到研发团队

此举将保证研发团队正视“盈利”这一开发人员很少在意但却是公司立足之本的元素。

做好这两条后，一个自组织团队的雏形就出现了。现在公司高层不用天天做仲裁了，双方会很平心静气地坐下来思考问题，查找关键解决方案。

这两点做得最好的是网络游戏团队，笔者去过很多家游戏开发公司，其中多数都拥有几个乃至几十个游戏研发团队，每个团队内部拥有产品负责人（策划团队）和开发团队。他们都高度自治，除了影响投资和收益的重大里程碑评审，领导几乎不过问细节，比如他们是用什么开发方法，最近在做什么等等。因为他们的核心内部机制就一个：赚钱大家分。不赚钱的功能不会有人提出来，赚钱的功能也不会有人偷懒不做。

在项目开发中这一点可能有点困难，不过在敏捷外包系列中可以看出其实还是有很多实际工作可做的。

完成自组织团队的初步建设后，开发人员自己估算和PO挑战估算就完全变成另外一个样子，而产生的同行压力也与之前截然不同。人们会：

1. 团队尽可能缩短估算，尝试最快的实现方法--------因为没有人考核“按时完成率”，完成早了多了来自客户的奖金也多。

2. “偷懒的人”将不复存在，因为他不但挡在自己的财路上，还挡在团队的财路上----------所以领导不用安装摄像头和屏幕监视软件了。

3. 赶工期的PO也不复存在，我见过一个PO很担心地问团队是否真的能完成，因为一旦延期客户会很失望，大家都遭殃。

4. ……

本篇的内容大量涉及了非研发部门的制度问题，比如为销售设置奖金机制，在实施起来会很有难度，需要公司层面的配合；从另外一个角度看，收益也是明显的。

笔者除了做过研发管理之外，还曾经任外企中国公司的部门经理和副总经理，同时管理过市场/销售/支持等非研发部门。本文的案例虽然是引自别的公司，但在理顺自己管理的部门的时候都有尝试使用，取得了显著效果。在这个过程中逐渐悟到如果不能在整个公司层面理顺关系，妄谈敏捷开发几乎是不可能的。

读者可能注意到本文所使用的图形中框的底色不同，其实自下而上它们被分为团队/客户（棕色）-计划实践（蓝色）-跟踪实践（紫色）-收益（绿色）-目标（金色）几个层次，但缺少“配套制度”这类研发外的生物，“持续集成”“MoSCoW”这些生物也没有位置。

未来本系列（也或许是其他系列）中将将包含一篇或几篇“敏捷成熟度模型”的文章，会将它们纳入其中。这个成熟度模型不是为了评估使用，而是为了弄清楚自己的团队还有哪些活动没有做，它们的目的和价值是什么，是否由于缺失它们而造成了一些困难，从而判断自己的敏捷开发还可以做哪些改进。