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

Dear 丶 2023-08-17 15:52 72阅读 0赞

这是敏捷生态系统系列的第一篇（ [之一][Link 1]， [之二][Link 2]， [之三][Link 3]， [之四][Link 4]， [之五][Link 5]）。

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

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

--------------------

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

![0_1312865683V455.gif][]

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

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

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

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

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

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

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

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

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

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

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

3. ……

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

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

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

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

3. ……

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

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

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

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

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

--------------------

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

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

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

![0_1311055886783t.gif][]![0_1311055987UN6B.gif][]

转载于:https://www.cnblogs.com/JPAORM/archive/2011/08/09/2510467.html

[Link 1]: http://blog.csdn.net/cheny_com/article/details/6672098
[Link 2]: http://blog.csdn.net/cheny_com/article/details/6672388
[Link 3]: http://blog.csdn.net/cheny_com/article/details/6684054
[Link 4]: http://blog.csdn.net/cheny_com/article/details/6690638
[Link 5]: http://blog.csdn.net/cheny_com/article/details/6694222
[0_1312865683V455.gif]: /images/20230810/4a4b6297490847f78dbec8bcef550984.png
[Link 6]: http://blog.csdn.net/cheny_com/article/details/6616794
[0_1311055886783t.gif]: http://hi.csdn.net/attachment/201107/19/0_1311055886783t.gif
[0_1311055987UN6B.gif]: /images/20230810/fd650fdcc9dc4eab89dcdb06ac5ce550.png