敏捷开发方法的不同声音

敏捷软件开发的不同声音

 

再次读《敏捷软件开发》

，有了更深的理解，敏捷软件开发有好处，也有弊端，但对于

成规模的公司，成型的项目来说，弊端是大于好处的。书中列举了一个

Rufus

公司的例子，

该项目的情况和油田应用开发部的项目非常相同。

首先，

项目需求基本不疗机的情况下，

让

项目经理排出一个需求完成的时间，

又硬要一个设计的时间，

最后整体项目控制在一定时间

内完成。

当项目经理带领项目组人员进行需求调研后，

也没有发现项目需求的大概量是多少，

更没有细化每一个需求，所以做到什么地步只有跟着感觉走。最后项目不得不延期的时候，

才发现系统完成的功能只有

50

％不到。然而到了此时，项目需求依然仍有很多没有搞清楚，

完成的结束时间依然不能预计出来，

试想一下，

这样的项目即使继续下去，

也一定不会有一

个完美的结果，

要么是进度不知所终，要么是成本大大超出预算。

但是再试想一下，如果需

求搞的清楚了，

并划定了优先级，

对不能确定的需求进行一步步的细化一步步的深入，

设计

也针对优先级排定的顺序进行设计，

编码过程中采用多次增量或者迭代开发，

让用户尽早的

试用和熟悉功能，

我想最后虽然不一定按期完成项目，

但至少知道需求做了多少，

还有多少

的工作量，目前离着预估的时间还能做完哪些。所以，敏捷软件开发并不一定是适用的。

 

 

下面将从几个方面进行分析敏捷软件开发和过程的优缺点

 

1.

敏捷软件开发号称个体和交互胜过软件过程和工具

 

这一点听起来好像是有道理的，

但到底是否真的对于一些公司适用呢，

到底对哪些项目

适用呢？首先公司的重点资源是人没有错，

沟通和交互是项目中最重要的手段也没有错，

但

是没有过程控制的个体无异于会做的五花八门，

没有过程的个体没有统一的原则，

最后将不

得不为这些个性而付出代价。所以，个体是重要的，但只有过程控制的个体才是有效的。

 

如果没有过程控制，

就不知道哪些是该记录的哪些是不该记录的，

记录了不该记录的内

容没有错，

但没有记录该记录的内容，

则等有一天发生意想不到的争吵的时候，

没有一个记

录，

则会因为没有证据而无奈。

所以个体有着更多的随意性，

去除这些随意性则是过程的优

点。

 

2.

可以工作的软件胜过面面俱到的文档

 

这一点是正确的，

但关键的理解是，

面面俱到的文档，

什么又是面面俱到呢？或许每个

人有每个人的解释，

感觉作者的面面俱到指的是一点都不遗漏的记录下来，

有用的没用的都

记录，所以成了面面俱到的文档。但这点和过程文档的规定是不同的，比如拿

CMMI

为例

子，

CMMI

虽然文档众多，

但非常灵活，

大量的针对不同项目的裁剪形成了独有的灵活体系。

所以对于敏捷软件和

CMMI

的过程来说，都不希望有大量文档，只要有有效有用文档就足

够了。

 

3.

客户合作胜过合同谈判

 

客户合作是重要的，

敏捷软件开发中强调这一点，

无非是想说明与客户建立良好的沟通

关系。

但是一般的过程中对这点也是没有详细规定的，因为对待客户一定要灵活、

有效、适

用。所以在这一点上，过程和敏捷开发的要求是相同的。

但有一点不同，就是敏捷软件提到

的客户合作更加注重让用户参与，

而实际过程中用户参与的程度哪里是项目开发方所能控制

的呢，所以，制定有效的计划，加强和客户沟通及时调整计划才是更有效的做法。

 

4.

响应变化胜过遵循计划

 

或许作者认为做了

CMMI

的人，

或者做了

IPD

的人，

他们的计划就按部就班的执行了，

或

QIT

的人就可以照章办事了，但其实不然，做了计划也可以更改，因为计划是人做的，

只要是人，

肯定会有计划变更，

因为人的思维意识是不断推进，理解不断加强的。

所以响应

变化是及时的，

但计划更新却是有章可循的，

如果随便就调整了计划，

计划调整的频次过多

时，惹人烦躁不说，这样的项目，结束时间将永远看不到。

 

 

极限编程

XP

法

 

1.

用户素材

 

这些用户素材的深度和广度是不适合项目的，

XP

更强调快速表面理解，而表面的理解

则代表理解的可能错误，

所以对用户素材更加强调了人为作用，

经验丰富的可能好一点，

经

验不丰富的结果可能南辕北辙，

而对于做项目的公司来说，

哪里有那么多经验丰富的人呢？

所以应该从实际出发。

 

2.

短交付周期

 

交付周期可以短，

但不能短的让人烦躁。

就像说交付你去做一件事情，

一个小时变一次，

你的感觉会可想而知。所以交付是要有代价的，那就是客户的信任度和忍耐度，从

100

％一

直下降，当降低到一定程度，与客户的交流也可想而知会出现什么样子的结果。

 

3.

验收测试

 

客户根本不会做验收测试，或者很少客户会测试，

所以，

测试还是在内部做好，而且内

部一定要做好。即使出了问题，也不是浅显的、表面性的，更不是数据流、重大功能模块崩

溃类的错误。

如果尝试用户去测试，

那用户岂不是也要消耗你的成本了。

当然大部分项目是

这样，有些项目客户肯定是需要测试的，但我经历的项目，除了移动之外，其他少而又少。

 

4.

结队编程

 

这样的是资源充足的情况下才能进行的，

而结队会浪费大量的时间，

作者说表面虽然看

起来浪费了时间，实际节省了时间，

但一个功能两个人做，到底是节省了还是浪费了，

想一

下就知道了。

如果出现问题，

则计算一下问题的解决时间，

我想也会大于两个人在哪里对一

些优化类编程的好。但如果遇到问题或者重大功能的时候，结队编程不失为一个好的方法，

企业如果不采用结队，也可以采用互审代码，

但一定要有的放矢，

而不是漫无目的的审，所

以，计划是一定要制定的，审的原则也一定要明确的，如果写一个

helloworld

都要审一下，

岂不是浪费了资源和时间！

 

 

5.

测试驱动开发

 

测试驱动开发不可取，

因为项目根本没有那么多的时间来应付前期测试开发，

做过四年

测试的我，

对于测试驱动开发一直持保留状态，

因为不要轻易采用测试驱动，

一来需要大量

培训，

二来需要大量的测试代码编写工作量和检查工作量，

三来发现的问题是否足以获得投

入的有效率，也值得人深思。所以，本人一般不提倡采用测试驱动开发。

 

6.

持续集成

 

这一点是赞成的，持续集成，不断集成，集成的方式和方法与项目规模有直接关系。

 

7.

开放的工作空间

 

在这里我只注意到作者一句话，

充满积极讨论的屋子，

也就是说，

讨论一定是针对问题，

积极而有效的。

这样的做法我们也早就开始了，

如果非有效的扩散了问题，

则结果一定是浪

费了时间，没有得到结论。

 

 

XP

提倡简单的设计

 

1.

考虑最简单的事情

 

将事情简化，

复杂转化为简单的时候，

人们也更容易接受。

有道理的设计，

将设计分层、

类库集中等方式。

 

2.

你将不需要它

 

这一点是错误的，至少从实际出发，

要考虑各种情况，进行分析后才得出结论。敏捷设

计说不需要提前准备一些东西，而将来这些东西可能没有用，所以怕准备也白花费了时间。

当等到临时用的时候，

你再准备，

那也就迟了，

中国有句老话，

叫做

“未雨绸缪”

，

不用

“临

时抱佛脚”

。

 

3.

一次，并且只有一次

 

XP

不能容忍重复代码，所以它将花费大量人力物力在设计和代码的审核，如果不是，

代码的重复程度一定非常高，所以

XP

的一次是终结的一次，是几乎不可能完成的一次。大

部分公司的项目并没有达到高手临立，

英才倍出的组合，

而是一种平均能力，

或许有实习的，

或许有试用期的，

也或许有正式一年的，

高手通常需要若干年积累精研才有了那种宏大而深

邃的经验。

 

4.

重构

 

重构也是需要花费时间的，

虽然精简了代码，

优化了程序，

但或许因为重构的时间造成

了项目的延期，

因为项目的时间通常是紧张的，

而重构花费的人力绝对不少于项目中一个高

手在项目时期的工作量，

与其如此，

还不如让高手做一些其他的工作，

当程序稳定下来，再

考虑性能优化和重构

（注：对性能要求不高的程序，要求高的，要实时的考虑性能部分的重

构）

。

 

5.

阴喻

 

XP

设计的原则是让所有人都了解全貌，了解所做的事情属于哪一块，和其他业务的联

系多少，而实际过程中，

代码开发人员不会了解到全貌，

只会了解到自己的一部分实现，所

以通常站的高度不是全局的，

因为要站到全局的高度，

需要人的能力也应该是把握力非常强

的，

因为稍微有一点变化，

你就要知道并且分析到自己的影响，

而通常项目中只有项目经理

和全局的设计人员能做到这一点。所以阴喻是好的，但的确是要求非常高的。

 

 

极限编程是好东西，

但适用于项目却是特殊的，

如工期短见效快，

工期短低要求的项目，

对于一些大型项目和产品，极限编程绝对是错误的，但敏捷软件开发中一些原则是正确的。

 

敏捷开发方法与传统重型开发方法相比

 

1

、敏捷开发方法与传统重型开发方法相比较，是一种更加主动的模式。那么在项目管理过

程中，调动每一位项目参与者主动的创造、适应变化，主动的发起、参与

 

交流和协作就显

得犹为重要。对于项目管理来说，就需要积极创造这些环境、

协调资源，调动项目成员的主

动性，鼓励团队的创新与协作。

 

2

、敏捷开发具有很强的灵活性，强调了拥抱变化。那么项目管理方式和项目开发策略也可

以适当灵活调整。比如：

在项目管理方面，可以吸取一些敏捷方法如

DSDM

方法中的实践，

直接授权于团队成员，

为了使项目快速进行，

团队成员必须能够对他们的工作任务迅速做出

评估决定，以保证项目能够如期交付；在项目开发策略方面，可以根据

MoSCow

原则，灵

活调整项目计划、各项任务的优先级。

 

3

、敏捷开发与传统开发模式还有一点差异，

注重交流

、特别是面对面的交流，那么如何提

高交流沟通的效率以及各种交流会议的价值也是值得思考的。

在没有任何流程、

文档强约束

的情况下，

将各种隐性的知识和概念如何在用户、

项目参与人员之间达成一致的、

正确的理

解也是需要重视的