敏捷思维-架构设计中的方法学资源-CSDN文库

敏捷思维

4星 · 超过85%的资源需积分: 10 166 浏览量 2013-04-18 17:53:42 上传评论 2 收藏 829KB PDF 举报

资源推荐

资源详情

资源评论

方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能

够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。

在第一篇文章中，我们来了解标题中的一些词的含义。

• 方法学是什么？

• 敏捷是什么？

• 为什么讨论架构？

方法论

方法论的英文为 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）。比如说我们的需求规约、分析文

档、设计文档、测试计划，这些都属于中间产出物。中间产出物的增加将会带来效率下降的问题，因

为开发人员的时间都花在了完成中间产出物的工作上，花在给软件新功能上的时间就减少了。而中间

产出物的主要目的是两个，一个是为了保证软件如客户所愿，例如需求规约；另一个是为了作为团队

中的其他成员工作的输入，例如开发计划、测试计划等。因此，我们也可以针对这两点来商讨对策，

一种是采用迭代的思想，提高软件发布的频率，以保证客户的需求被确实的满足，另一种就是缩小团

队的沟通范围，保证成员能够从其他人那里得到新的思路，而不是撰写规范的内部文档（内部文档指

那些仅为内部开发人员之间的沟通所需要的文档）。

因此，一个软件项目的成功和你采用的开发方法论并没有直接的关系。

重量

我们根据把拥有大量 artifact（RUP 官方翻译为工件，意思是软件开发过程中的中间产物，如需求规

约、设计模型等）和复杂控制的软件开发方法称为重型（Heavy Weight）方法，相对的，我们称 artifact

较少的方法为轻型（Light Weight）方法。在传统的观念中，我们认为重型方法要比轻型安全许多。

因为我们之所以想出重型方法，就是由于在中大型的项目中，项目经理往往远离代码，他无法有效的

了解目前的工程的进度、质量、成本等因素。为了克服未知的恐惧感，项目经理制定了大量的中间管

理方法，希望能够控制整个项目，最典型的莫过于要求开发人员频繁的递交各种表示项目目前状态的

报告。

在 Planning XP 一书中有一段讨论轻重型方法论的精辟论述，它把重型方法论归结为一种防御性的姿

态（defensive posture），而把轻型方法论归结为一种渴望成功（Plan to win）的心态。如果你是采

用了防御性姿态，那么你的工作就集中在防止和跟踪错误上，大量的工作流程的制定，是为了保证项

目不犯错误，而不是项目成功。而这种方法也不可谓不好，但前提是如果整个团队能够满足前面所提

到的两个条件的话，项目也肯定会成功，但是重型方法论的一个弊端就在于，大家都在防止错误，都

在惧怕错误，因此人和人之间的关系是很微妙的，要达到充分的沟通也是很难的。最终，连对人的评

价也变成是以避免错误的多寡作为考评的依据，而不是成就。我们在做试验的时候，一位项目经理开

玩笑说，"方法论源自项目经理的恐惧，这没错。但最糟糕的是整个团队只有项目经理一个人恐惧，

如果能够做到人人的恐惧，那大家也就没有什么好恐惧的了。"这句话提醒了我们，如果一个团队的

精神就是力求成功，那么这支团队的心态就和其它的团队不同了，尤其是对待错误的心态上。根本就

没有必要花费大量的精力来预防错误，错误犯了就犯了，即时改正就可以了。这其实就是渴望成功的

心态。

方法论的艺术

管理，被称为科学和艺术的融合体，而管理的艺术性部分很大程度的体现为人的管理上。我说，方法

学，一样是科学和艺术的融合体。这是有依据的，其实方法论和管理学是近亲关系，管理学中有一门

分支是项目管理，而在软件组织中，项目管理是非常重要的，方法学就是一种针对软件开发的一种特

定的项目管理（或是项目管理的一个子集）。

重型方法最大的一个问题就在于他不清楚或忽略了艺术这个层次，忽视了人的因素，把人做为一个计

量单位，一种资源，一种线性元素。而人的要素在软件开发中是非常重要的，软件开发实际上是一种

知识、智力的转移过程，最终形成的产品是一种知识产品，它的成本取决于开发者的知识价值，因此，

人是最重要的因素。而人这个要素是很难衡量的，每个人都有不同的个性、想法、经验、经历，这么

多复杂的因素加在一起，就导致了人的不可预见性。因此，我们强调管人的艺术。

最简单的例子是，在重型方法中，我们的基本假设是对人的不信任。项目经理要控制项目。但不信任

就会产生很多的问题，比如士气不高，计划赶不上变化，创新能力低下，跳槽率升高等等。人都是希

望被尊重的，技术人员更看重这一点，而很多公司也口口声声说自己多么多么以人为本，可是采用的

却是以不信任人为前提的开发方法，言行不一。我们说敏捷方法的出发点是相互信任，做到这一点是

很难的，但是一旦做到了，那这个团队就是非常具有竞争力的。因此，这就产生了一个问题，在没有

做到完全的相互信任之前，我们到底相不相信他人呢，这就是我提到的艺术性的问题，什么时候你要

相信人？什么时候你不相信人，这些都是需要权衡的问题，也都是表现你艺术性的问题。

敏捷

敏捷代表着有效和灵活。我们称那些轻型的、有效的方法为敏捷方法。在重型方法中，我们在一些不

必要、重复的中间环节上浪费了太多的精力，而敏捷则避免了这种浪费。我们的文章将会重点的讨论

敏捷（Agile）方法论的思想，敏捷这个名字的前身就是轻型。目前已经有了一个敏捷联盟，他们制

定了敏捷宣言：

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.

• Customer collaboration over contract negotiation.

• Responding to change over following a plan.

而我对敏捷的理解包括了几个方面：

• 较低的管理成本和高质量的产出。软件开发存在两个极端：一个是没有任何的管理成本，所

有的工作都是为了软件的产出，但是这种方式却往往导致软件开发过程的混沌，产品的低质

量，团队士气的低落。另一个是大量管理活动的加入，评审、变更管理，缺陷跟踪，虽然管

理活动的加入能够在一定程度上提高开发过程的有序性，但是成本却因此提高，更糟糕的是，

很容易导致团队的低效率，降低创新能力。因此，敏捷方法视图寻找一个平衡点，用低成本

的管理活动带来最大的产出，即软件的高质量。

• 尊重人性。敏捷方法尊重人性，强调效率。软件开发可以说是一种脑力的投入，如果不能保

证开发人员的自愿投入，产品就肯定要打折扣。事实多次的证明，一个愿意投入的开发人员

和一个不愿意投入的开发人员效率相差在三倍以上，对组织的贡献更是在十倍以上。

• 沟通和反馈是一切的基础。我们已经讨论过沟通的重要程度，而即时的反馈是拥抱变化的前

提条件。

• 客户是上帝。没有客户就没有一切，客户的重要性可以用一句话来形容，就是以合理的成本

建造合适的软件（build the right system at the right cost）。

剩余38页未读，继续阅读

评论收藏

内容反馈

frankchenhf

2014-01-27

很清晰，谢谢楼主分享！

ninjaboy

粉丝: 4
资源: 4

敏捷思维-架构设计中的方法学

敏捷思维－架构设计中的方法学

敏捷思维-架构设计中的方法学.rar

敏捷思维－ 架构设计中的方法学.doc

敏捷思维-架构设计中的方法学.pdf

敏捷思维-架构设计中的方法学.doc

敏捷思维架构设计中的方法学

敏捷思维－架构设计中的方法学（1）

敏捷思维-架构设计中的方法学(1-15).doc

敏捷思维－架构设计中的方法学(1)从方法论看架构设计

敏捷思维－架构设计中的方法学(2)架构设计的敏捷视图

插件《E灵19.6》约260个功能，支持WPS和Excel，官方下载

camunda7.15版本汉化

华为研发部门绩效考核制度及方案（经典）-35页.pdf

Word精灵V9.2，包含110个排版工具，官方下载

Power BI 官方中文教程（PDF版）

55个MES项目解决方案及案例

SAP SCR LEGACY TEXT EDITOR GUI8.00

MES系统功能架构图.pptx

低代码框架 JNPF JAVA SPRINGBOOT 单体版本

数据分类分级管理制度.docx

最新资源

敏捷思维－架构设计中的方法学.doc