在2.3节里我们曾经提到，任何一个团队都像一辆行驶中的车。要想高效前进，3件事情最重要：方向不能错；跑得要快；车不能散架或翻倒。
在这一过程中，流程则像是一种保证车不散架、翻倒的辅助手段。如果车是木头的，并且很容易颠坏，那么修理上的开销会降低平均速度。这时候无疑需要些手段来使车身更为牢固，比如，对结合处进行铆接等。
这时的另一个关键点是，也不能走到另一个极端。无疑的可以通过把骨架换成铁的来加固，但是你不能让换过的车身太沉，否则车的动力可能不足以拉动它，一样会降低平均速度。
所以，我们说完美的流程必然是与现实契合度最高的流程。
这似乎略有一点滑稽，我们从一个起点出发，历经种种分析，却最终回到一个老生常谈的话题。所幸的是，我们通过逻辑链对契合度这一概念进行了一定程度的分解，也还勉强算得上是否定之否定。最后强调一下，这里的契合度是指：
●流程的步骤之间彼此正交，没有重叠区域。
●对工作的控制粒度停留在恰当的程度上。
●流程并不面面俱到，不介入可控制也可以不控制的区域。(www.xing528.com)
●流程自身是组织的一种基本共识。
契合度高的流程就是好的流程，我们甚至看不到好流程的成本。
契合度低的流程就是坏的流程，坏的流程就像锁链，可以绞杀一切改善和热情。
流程，需求变化与人
软件的世界中似乎有这样一种趋势：需要应对的需求其变化频度越高，对人的依赖性越强，而对流程的依赖性就越弱。
想象一下，某个类似QQ这样的产品，每天从终端用户反馈来的各种小的需求铺天盖地。这个时候，可以按既定流程汇总小需求，完成分析，建立设计文档，实现，测试等，但这会导致开发的节奏变慢。而直接把各种小需求记录为ticket，直接进行实现和对应，会快很多，但这样一来对人的依赖则会增强。
虽然没有考证过，但这很可能是敏捷开发的一个起因。当需求碎片化到一定程度后，很多传统软件工程中所倡议的模板（可以试想一下，在每个月处理几百个小需求的时候，怎么去使用RUP的需求模板）都变得很难使用，同时也变得只能更加依赖于个人。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
