方法论的英文为Methodology，编程的方法论应该是指软件开发的一整套方法、过程、规则、实践、技术。不过我们一般提到的方法论都偏重于项目、过程和人员。《敏捷软件开发》的作者Alistair Cockburn提出方法论具有以下要素：角色、个性、技能、团队、技术、活动、过程、产品、里程碑、标准、质量、工具、团队价值，它们的关系可以用一幅图来表示：

对于方法和方法论的区别，我们要注意的是方法更多的是针对具体的事情的处理方式和步骤。而方法论探讨的是一个团队在处理一个较大的过程的时候，在面临一种特定的场景时候应该采用的方法组合和协同。

方法论既可以是启发和参与式的，又可以是标准化的。对于一个不断成长的知识体系，方法论的一部分由启发转化为标准化，成为典型问题的标准解决方案。这类似于在我们的知识管理中，当我们的隐形的知识转换为显性的时候，就可以标准化到具体的过程中，方法论和过程是经验的一种良好载体。

方法论的设计是和项目本身的特点密切相关的，这里面包括了人员，项目的规模，研发产品的特点和对质量的要求，研发团队的工作模式等。方法论是一个全集，当面临一个特定的项目的时候我们需要定义和项目特征匹配的软件开发生命周期模型和软件过程。因此在这个过程中涉及到了需要考虑方法论的重量，大小，规模，精度，可见性，稳定性等一系列问题。

在方法论的设计过程中一定要考虑到人的变化，跨项目的变化，项目周期的变化和技术的变化对方法论的影响。在初次设计方法论的时候我们经常犯的错误就是所有项目都采用同样大小的方法论，不考虑方法论的重量和灵活性，完全主观按照自己的意愿去设计，或者自己去采用没有经过实践的业绩最佳实践等。因此在这里我们的重点是去分析和学习可用于设计和评价方法论的七条原则：

1.交互面对面的交流是费用最低，最高效和快速的信息交换方式

在这里要注意的是团队随着规模的扩大，沟通渠道呈现指数倍增加。因此规模扩大后要强调划分开发小组，或者是通过提升个人技能避免不必要的规模扩大。交流的过程最好是结合白板的沟通，图形往往更容易让他人理解。交流的结果必须要有记录，可以是录像的方式或者是文档化。

2.方法论超重的后果是高昂的代价

对于方法论超重可以看做是对管理者虚荣心的一种满足，或者是可以让团队让外界看起来更美，或者体现了管理者对团队和人员信任的下降，他们希望看到更多的中间输出。一个项目的运作的重点不是满足过程，而是要实现目标，没有达到项目的目标在华丽的过程都没有用。

团队成员的重点需要时刻放在产品开发和对产品质量的关注上。方法论的重量要体现到对特定项目目标的贡献度上面。方法论越重我们往往越难去解决复杂的问题，一个小团队往往能够用较轻的方法解决更大的问题。

3.更大的团队需要一些更重一些的方法

对于一个4-6个人的小团队，让他们坐在有白板的办公室里面工作是可行的，这样在他们进行创造和交流的协作游戏时，交谈中会产生信息对流。但是随着团队大小的增加，沟通，协调，干扰，交叠和重复都是需要考虑的问题，我们必须要针对这些问题制定其它形式的协调和交流。

4.项目危险程度越高，对方法论的正规度要求也越高

对于航天飞机等大型软件系统的开发，我们必须有严格和高度正规的方法论定义。这种项目容不得一丝一毫的错误。而对于中小型信息系统的开发，项目的目标不仅仅是质量，还有进度和成本，我们必须要在这些要素之间进行权衡。

因此如果我们简单的照搬大型软件工程的开发方法论到小规模敏捷团队中，很显然是得不偿失的。我们有通过沟通协作等更轻量的方法来保证质量和避免犯错误。

5.增加反馈和交流，减少对中间工件的需求

最终产品的质量和用户对产品的满意度是衡量项目是否成功的一个关键要素，而中间的任何工件更多的是为了符合项目团队内部管理和监督的需要。我们相互间越不信任，往往就越需要更多的中间输出。

我们用中间工件的完成进度来衡量项目的进展是毫无意义的，因此在快速开发团队中大型瀑布的开发模式必须用迭代增量的模式进行代替。 通过这种快速迭代的交付既可以降低风险，又可以使进度真正有意义。

6.纪律，技能和理解 VS 过程，形式和文档

首先过程不是纪律，过程只是让人们遵守规范和指令，而纪律要求人们选择一致的方法去工作。在这个过程中，纪律的效力更强。其次，不要混淆文档和理解，在软件开发过程中仍然有很多隐性知识，文档只能表达这些知识的一小部分，更多的是需要通过沟通后的理解。最后，形式始终都是表面性的东西，制定了UML规范和学习了UML并不代表你能够有足够的技能进行面向对象的设计。

轻量级的方法论更加看重理解，纪律和技能，而不是文档，过程和形式。因此他们适用于探索性的情况。而重量级的方法论看重的是文档，过程和形式，它们设计的目的是让人们在不需要适应变化的环境下工作，只需要成本最优化。

7.从非瓶颈活动中需要效率

约束理论常用于关键链项目管理中，而关键链项目管理的重点就是说明了项目的进度是取决于项目中核心和瓶颈资源的约束的。为了让项目进度有保证，我们需要考虑的就是让瓶颈资源更加高效率的运作，而要做到这一点就是让非瓶颈资源尽可能提前的做好各种工作，以保证输入到瓶颈资源的工件有更高的质量，减少瓶颈资源的返工。

从非瓶颈活动中需要效率需要我们考虑，当项目进展受到瓶颈资源约束的时候，我们闲职的非瓶颈资源应该如何利用。一个项目进展我们最怕的就是由于瓶颈的约束让团队中更多的人显得无所事事。