敏捷开发生态系统系列之一：序言及需求管理生态（客户价值导向-可工作软件-响应变化）

 这是敏捷生态系统系列的第一篇（ 之一， 之二， 之三， 之四， 之五）。

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

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

---

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

 

☺ 客户价值导向是敏捷开发需求管理的主要思想。

☺ 敏捷开发相信密切与客户协作比编写详尽的文档更能弄清楚客户的需求；而利用阶段性的可工作软件外加邀请客户参与评审会，比让客户评审需求文档更容易让客户正确地补充需求和验收产品。

☺ 由于相信变化后的软件一定比变化前的对客户更有价值，所以敏捷崇尚响应变化。提供可工作产品来引导客户变化，可保证客户更能正确翔实地描述变化；而迭代交付则使得重要的、必要的变化可以提前交付，而不是像瀑布模型一样最后才发生。

☺ 通过需求优先级排序和迭代交付，首先可保证重要的需求一定可以交付到客户手中；其次可以保证重要的变更来临时，可以放弃尚未开发的次要需求作为交换；再次可以保证产品负责人（PO）会优先分析重要的需求，不会让它们在模糊状态进入开发。

☺ 只有最高优先级的需求才会进入下一迭代，因此很少有变更比它们更重要，而且这些需求也被较深入地分析过，产品负责人就有信心承诺迭代期内无变更，以换取团队承诺，进而保持交付以可持续的步调发生。

☺ 拥抱变化是一种由客户协作、优先级排序、可工作软件等各种实践支撑下的、主动的可控过程，而不是被动地“被变化拥抱”，“迭代期内无变更”和“拥抱变化”的对立统一，必须建立在这些实践的基础上。

客户价值导向-可工作软件-响应变化这三条是需求管理生态的核心内容。下面从一个问题的分析来看需求管理生态的工作原理。

 

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

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

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

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

3. ……

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

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

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

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

3. ……

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

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

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

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

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

---

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

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

 

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》