方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。
在第一篇文章中，我们来了解标题中的一些词的含义。
方法学是什么？
敏捷是什么？
为什么讨论架构？
方法论
方法论的英文为Methodology，词典中的解释为"A series of related methods or techniques"我们可以把它定义为软件开发（针对软件开发）的一整套方法、过程、规则、实践、技术。关于方法论的出现的问题，我很赞同Alistair Cockburn的一句话，"方法论源于恐惧。"出于对项目的超期、成本失控等等因素的恐惧，项目经理们从以前的经验出发，制定出了一些控制、监测项目的方法、技巧。这就是方法论产生的原因。
在Agile Software Development一书中，作者提到了方法论的十三个要素，基本能够函盖方法论的各个方面：
角色（Roles）
个性（Personality）
技能（Skills）
团队（Teams）
技术（Techniques）
活动（Activities）
过程（Process）
工件（Work products）
里程碑（Milestones）
标准（Standards）
质量（Quality）
工具（Tools）
团队价值（Team Values）
它们之间的关系可以用一幅图来表示：
图 1. 方法论的十三个要素
很多的方法论，都涉及了上面列举的十三要素中的部分要素，因此，我们可以把方法论看作是一个抽象的、无穷的超集，而现实中的方法论都是指超集的一个有限的子集而已。它们之间的关系就好像有理数和1到100之间的整数的关系一样。不论是XP，还是UI设计经验之类，都属于方法论的一个子集，只是这两个子集之间有大小的差别而已。我们还应该看到，讨论一个完备的方法论是没有意义的，因此这种方法论铁定不存在，就好像你视图穷举出所有的有理数一样荒唐。因此，我们关于一个通用的方法论的说法也是无意义的。好的方法论，比如说XP、水晶系列，它们都有一个适合的范围，因为它们了解一点，自己并不是一个无所不能的方法论。
在现实中，我们其实不断的在接触方法论。比如说，为了控制项目的进度，项目经理要求所有的开发人员每周递交一份详细的进度报告，这就是一种方法、一种技巧。如果把开发过程中的这些技巧系统的组织起来，就能够成为一种方法论。你可能会说，那一种方法论的产生也太容易了吧。不，这样产生的方法论并没有太大的实用价值，没有实用价值的方法论根本就没有存在的必要。因此，一个成功的方法论是要能够为多个的项目所接受，并且能够成功实现软件的交付的方法论。
我和我的同事在实践中做了一些试验，希望能够把一些好的方法论应用于开发团队。试验的结果很无奈，方法论实施的效果并不理想，一开始我们认为是方法本身的原因，到后来，我们发现事情并不是这么简单。在试验的过程中，开发人员一致认同方法论的优势所在，但是在实施过程中，鲜有坚持的下来的。在Agile Software Development中，我发现作者遇到了和我们一样的问题。
Alistair Cockburn在和大量的项目团队的访谈之后，写成了Agile Software Development一书。在访谈之前，他笃定自己将会发现高度精确的过程控制是成功的关键所在，结果他发现事实并非如此，他把他的发现归结为7条定律。而我在实际中的发现也包含在这七条定律中，总结起来就只有两点：沟通和反馈。
只要能够保证良好的沟通和即时的反馈，那么开发团队即使并没有采用先进的方法论，一样可以成功。相反，那些"高质量"的团队却往往由于缺乏这两个因素而导致失败（我们这里指的失败是用户拒绝使用最终的软件）。最有效，而成本也最低的沟通方法就是面对面（face to face）的沟通，而随着项目团队的变大，或是另外一些影响因素的加入（比如地理位置的隔绝），面对面的沟通越来越难实现，这导致沟通的的成本逐渐加大，质量也慢慢下降。但这并不是说非面对面的沟通不可，重要的是我们需要知道不同的沟通方式的成本和质量并不相同。XP方法尤为强调面对面的沟通，通过现场客户、站立会议、结对编程等方式来保证沟通的有效。在我的经验中，一个开发团队其实是需要多种沟通方式的结合的。完全的面对面的沟通对某些团队来说是很难实现的，那么问题的关键就在于你如何应用沟通的方式来达到你希望的效果。在前不久结束的欧莱雅创业计划大赛上，有一支团队特别引人注目，他们彼此间素未谋面，仅仅凭借Internet和电话完成了高效的合作。他们虽然没有使用面对面的沟通方式，但是仍然达成了既定的目标。软件开发也是一样的，面对面的沟通是非常有必要的，但其它的沟通方式也是需要的。
再看反馈，不论是控制进度，还是保证客户的满意度，这些活动都需要管理成本。软件开发中的管理成本的一个通性就是伴随有中间产出物（intermediate delivery）。比如说我们的需求规约、分析文档、设计文档、测试计划，这些都属于中间产出物。中间产出物的增加将会带来效率下降的问题，因为开发人员的时间都花在了完成中间产出物的工作上，花在给软件新功能上的时间就减少了。而中间产出物的主要目的是两个，一个是为了保证软件如客户所愿，例如需求规约；另一个是为了作为团队中的其他成员工作的输入，例如开发计划、测试计划等。因此，我们也可以针对这两点来商讨对策，一种是采用迭代的思想，提高软件发布的频率，以保证客户的需求被确实的满足，另一种就是缩小团队的沟通范围，保证成员能够从其他人那里得到新的思路，而不是撰写规范的内部文档（内部文档指那些仅为内部开发人员之间的沟通所需要的文档）。 [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
