授课视频在线视频

大家好。今天我们开始讨论敏捷开发方法

什么是敏捷开发方法？

进一步地说什么是方法论？

首先来看一看

方法论指的是什么

指的是方法和规则，这毫无疑问

方法，我们强调，第一，它是一系列的方法

是一个集合

规则也是一系列的规则，规则的集合

方法是希望你能够按照这个方法来做

给你提供经验

规则是约束我们的开发人员

约束他们的行为

从而保证产品质量

这句话之前说过

软件工程它是一个非常实践

非常工程、非常灵活的方法

是这样一个集合

后面会能够更深刻地体验到这一点

一般地来说，在一个项目当中

这个方法特别有效

这个方法在另一个项目当中就未必有效了

所以说切忌不要照搬方法论

总体上来说，方法论

它的规则它的方法很多

要做到的就是，之前我们也提到过

要学习方法，实践方法

忘掉方法

方法论，Cockburn认为

它来自于人的恐惧

什么样的恐惧

前面提到过，软件工程追求的是一个三角形

质量，进度和成本

由于项目经理或者说

项目管理者、老板们认为

无法对项目的这三个因素进行有效地监控

他就会觉得比较恐惧

项目会不会超期呀？

进度会不会难以控制啊？

质量能不能得到保证啊？

基于这个原因

他们从以前的经验出发

制定了一系列的控制方法

来监控整个项目、整个团队

这里面比较有意思的是

大家看一看贝多芬的这句名言

我要掐住命运的咽喉

大家想象一下

在一个开发团队当中

如果一个程序员或者一个骨干程序员

他在写程序的时候

所有东西都在他的控制之下

有一天他突然对老板说

老板我要加钱，你不加钱我就不干了

老板就感觉自己的脖子被这个程序员给掐住了

要不给他加工资呢

他可能就不干了

那我的项目就完蛋了

给他加工资呢，就受到了胁迫

这是很不爽的一件事情

所以说，从这个角度来看

管理者和老板们恐惧被

团队当中的成员掐住自己的脖子

所以他们也有必要

从这个角度来说

来进行一个有效的所谓的这种管理

提出一套方法论

一般地来讲，理想的方法论

它是无限大的，很理想的

方方面面都能够考虑得到

在实际当中，你想让程序员

一天24小时地工作，为你挣钱

那是不可能的

人要生病，人要吃饭，人要休息

从这个比较直白的方面进行讨论

不存在一个完备的通用的方法论

所有的方法论必须是与实际的

团队成员、企业文化、项目特色等等有密切关系

一个成功的方法论

它必须要经过多个项目的实践检验

实践出真知

如何对方法论进行分类？

我们一般按照这种规则的多少和约束的强弱

或者是中间产物的多少

来大致地把软件工程分成

重型方法和轻型方法两大类

这是大致的分类

到底有多重有多轻

后面我们来看一看

如何来评价这个方法是重型的还是轻型的

以及它们之间的界限

首先来看重型方法

重型方法的特征，往往正规、比较严谨

其中一个重要的特点就是，刚才提到了

老板可不想被程序员

被我们的开发人员掐住脖子

所以它的特点之一就是

开发人员具有很强的可替代性

比如我是个技术牛人

我告诉老板说，我要加钱

不加钱我不干了

老板马上通知HR

晚上就能从人才库里找到接替人员

你就可以拜拜了

不会因为一个人的生老病死而影响整个项目的进展

这是重型方法的一个非常重要的特点

重型方法它侧重的是计划

就是计划很周详

提前很长时间

做了各种各样的计划

它对过程非常看重，每部分和整个控制

我们刚才提到了

要消除恐惧的方法就是要对整个过程能看得清

能够控制在我的手掌之内

然后强调中间产物

典型的就是文档、开会、报告

说这周的计划是什么

上周完成了什么

有什么问题

这是典型的一种状态报告

通过这种报告

管理者就可以对所有的开发人员

他们的这种进步、状态和计划有一个非常清晰的了解

就能够估计我们这个项目能不能

在指定的进度要求内、成本要求内

和质量要求内得到控制

很明显对于管理者来说

一般都比较偏爱这种重型方法

一切都在掌握之中，一切都按计划进行

对于开发人员

他比较不是太喜欢

什么事情我都要做额外的一些工作

比如说写代码，程序员想

写代码就是我的主要工作

我还得写文档，我还得开会

文山会海的，做各种计划

轻型方法它的特征就是迭代

就是强调说

快速地完成一部分的工作

然后增量性的迭代和开发、重构

对前面的工作，有一些改进

达到响应需求的快速变化

在一些轻型方法当中

它的主要的交付物就是代码

核心内容是代码、是源程序

然后我的源程序能跑起来

黑猫白猫抓住耗子就是好猫

文档多不多暂且不表，程序没问题

能满足用户需求，如何确定能满足用户需求

如何确定没有错误

在轻型方法当中

还是比较重视测试用例的

通过测试用例来完成对产品质量的控制

这种控制可能来自于需求

轻型方法它所强调的是

低成本的管理

管理人员少，管理活动少

但是成效高

这样的话，总体上来说

开发人员是比较喜欢这种轻型方法的

必要的文档，很简洁

主要工作是写代码

保证代码的正常工作

就是没有了很多额外的会议

如何来确定一个方法论的轻和重

或者是说在开发实践当中

如何引入不同的方法论

首先要明确一点

没有两个项目会采用完全相同的方法论

就像我们说世界上没有完全相同的两片树叶

不同的项目，不同的人员，不同的客户

都会造成方法论的不同

第二要强调的就是，软件工程非常的灵活

它是一套非常灵活的方法

所以不要企图照搬书能够解决问题

如何考虑重型和轻型呢？

一般从规模和紧要性来考虑

比如规模比较大，项目比较大

一般比较偏重于采用重型方法

不会因为一个人的一些变故

对整个项目造成致命的影响

而小型的项目可以比较灵活一点的

人员也比较少，有利于组织

紧要性就是说这个项目是不是很着急

优先级比较高，deadline就在前面

在方法论的选择方面

提倡刚刚够、刚刚好

什么意思呢？多大的团队

多大的规模，多大的软件

采用什么样的，几斤几两的方法论

是根据实际来裁剪的

这里面没有一个固定的法则

但是不论采用哪种方法论

我们的工作重点都是沟通

并且沟通的成本要降低，尽可能的低

反馈，希望能得到来自开发团队内部

甚至客户的反馈

然后达到一个什么样的结果

就是软件频繁地交付，增量式的交付

逐步满足用户的需求

这里来看一个例子

这个团队是一个20人的团队

这个团队是一个6人的团队

这两个团队相比来说

他们采用什么样的方法进行软件开发

核心就在于沟通、反馈和频繁交付

就拿沟通来说

20人的团队的沟通方式

与6个人团队的沟通方式是不一样的

比如6个人的团队中午吃饭的时候

在餐厅里就可以一边吃饭一边讨论

就把个问题解决了

反过来，20人的团队

要讨论一个问题的时候

需要先开会，安排会议

提前把会议资料发给大家

约定开会时间，确定开会地点

这样的话，这种管理成本和沟通成本

就比6个人的团队要大

如何降低沟通成本和管理成本

是我们在进行团队管理的时候

要重点考虑的

总之，我们采用的方法论

要明确的达到管理目标，就是要有效和灵活

实际上在开发过程当中

我们希望通过自动化的技术和工具

让轻重方法论之间达到进一步的融合

它们的界限进一步模糊

比如现在的很多自动化工具

它们有很强的同步特性

如设计模型与代码之间的双向同步

这种双向实时同步

对轻型方法中的迭代和重构有很好的支持

有了这些工具

如果采用轻型方法

核心的特征就是迭代重构

就能快速的准确无误的进行

同时自动化工具的模型翻译和转换

比如从高级到低级的转换

从设计到代码的转换

依赖于这种文档

比如用UML写出了一个非常详尽的类图

从目前的技术来讲

很多自动化工具

就能够把这种设计的UML类图

包括它们之间的关系实时地转换为代码

反过来，从代码它可以实时地转换为模型

也就是说，重型方法强调文档

这个文档不仅仅是非形式化的文档

也包括形式化的文档

有了这种自动化工具

可以既支持重型方法也支持轻型方法

所以我们希望能够引入这样的一些自动化工具

同时，大型项目

往往不会单独采用其中的一种

往往会整体上采用重型方法

局部采用轻型方法

经常有人说，现在瀑布模型过时了，不用了

被敏捷方法取代了

其实我个人是不认同这种观点的

所有的方法，不论是重型还是轻型

它都是由基本的开发活动构成的

你不能说轻型方法就没有测试、没有编码

没有设计，重型方法轻型方法都有

只不过它们组织的方式不一样

不同的方法论它是相互结合，相互融合

而不是相互取代

在实际的工作当中

根据自己的团队规模、人员素质

企业文化和客户的信息

来选择不同的工具和方法

从不同的方法当中来选择适合自己的

你觉得TDD不错就用TDD

如果你觉得结对编程太浪费，公司没那么多钱

你可以不用

你觉得计划纸牌就是开玩笑

那你可以不用

你觉得每天的站立会议不错，你可以选择

甚至你可以发明出自己的新方法

只要它有助于管理，有助于提升

好，这部分内容就到这儿，谢谢大家