在和大量的项目团队的访谈之后，写成了
一书。在访谈之前，他笃定自己将会发现高度精确的过程控制
是成功的关键所在，结果他发现事实并非如此，他把他的发现归结为 * 条定律。
而我在实际中的发现也包含在这七条定律中，总结起来就只有两点：沟通和反
馈。
只要能够保证良好的沟通和即时的反馈，那么开发团队即使并没有采用先进的
方法论，一样可以成功。相反，那些高质量的团队却往往由于缺乏这两个因
素而导致失败（我们这里指的失败是用户拒绝使用最终的软件）。最有效，而
成本也最低的沟通方法就是面对面（）的沟通，而随着项目团队
的变大，或是另外一些影响因素的加入（比如地理位置的隔绝），面对面的沟
通越来越难实现，这导致沟通的的成本逐渐加大，质量也慢慢下降。但这并不
是说非面对面的沟通不可，重要的是我们需要知道不同的沟通方式的成本和质
量并不相同。' 方法尤为强调面对面的沟通，通过现场客户、站立会议、结对
编程等方式来保证沟通的有效。在我的经验中，一个开发团队其实是需要多种
沟通方式的结合的。完全的面对面的沟通对某些团队来说是很难实现的，那么
问题的关键就在于你如何应用沟通的方式来达到你希望的效果。在前不久结束
的欧莱雅创业计划大赛上，有一支团队特别引人注目，他们彼此间素未谋面，
仅仅凭借 ) 和电话完成了高效的合作。他们虽然没有使用面对面的沟通
方式，但是仍然达成了既定的目标。软件开发也是一样的，面对面的沟通是非
常有必要的，但其它的沟通方式也是需要的。
再看反馈，不论是控制进度，还是保证客户的满意度，这些活动都需要管理成
本。软件开发中的管理成本的一个通性就是伴随有中间产出物（
）。比如说我们的需求规约、分析文档、设计文档、测试计划，这些
都属于中间产出物。中间产出物的增加将会带来效率下降的问题，因为开发人
员的时间都花在了完成中间产出物的工作上，花在给软件新功能上的时间就减
少了。而中间产出物的主要目的是两个，一个是为了保证软件如客户所愿，例
如需求规约；另一个是为了作为团队中的其他成员工作的输入，例如开发计划、
测试计划等。因此，我们也可以针对这两点来商讨对策，一种是采用迭代的思
想，提高软件发布的频率，以保证客户的需求被确实的满足，另一种就是缩小
团队的沟通范围，保证成员能够从其他人那里得到新的思路，而不是撰写规范
的内部文档（内部文档指那些仅为内部开发人员之间的沟通所需要的文档）。
因此，一个软件项目的成功和你采用的开发方法论并没有直接的关系。
重量
我们根据把拥有大量 （( 官方翻译为工件，意思是软件开发过程中
的中间产物，如需求规约、设计模型等）和复杂控制的软件开发方法称为重型
（+"）方法，相对的，我们称 较少的方法为轻型（,
"）方法。在传统的观念中，我们认为重型方法要比轻型安全许多。因为
我们之所以想出重型方法，就是由于在中大型的项目中，项目经理往往远离代
码，他无法有效的了解目前的工程的进度、质量、成本等因素。为了克服未知
