敏捷开发其实意义不是很大,在复杂项目中

13-10-11 wangcity
                   

敏捷开发其实意义不是很大,在复杂项目中

复杂系统的开发,不会采用敏捷的方式,而是要在开始阶段,多考虑完善,多在架构层面,留有余量,而这个余量,更多的是通过设计方法--例如,采用灵活的顶层设计,留有余地的接口,抽象类来实现,而敏捷式开发,更多的强调是,你做出来多少个需求要求你完成的功能特性,其实,从某种程度上说,敏捷和较为完善的设计,是背道而驰的。因为敏捷要求的是完成可交付的功能--用户可用。而好的设计,是强调的通过较为周到的考虑,将架构合理的搭建起来--这个时候还远远没有到用户可以用的程度。

现在好多人喜欢谈敏捷,其实,敏捷,意思不大,就是开发流程短平快,可是如果做不好,往往会适得其反,拥抱变化,敏捷给的解决方案是--勇气,重构,而要知道,即便你有天大的勇气,即便你能重构来重构去,也远远抵不上一个设计完善的软件架构的巨大价值。

打个比方,敏捷就是某个小国政府,今天政变一把,张三搞一套政府班子,明天李四再政变一把,再搞一套政府班子,搞来搞去,都在拥抱变化,可是屁用没有。

而好的架构设计,就像美国的国父们仔细坐下来,琢磨独立宣言,琢磨政府的三权分立架构,使得有一个持续可用,优美合理,能够扩充,接纳改进的良好政治框架一样。

同志们,脑袋是否清晰了一点?

                   

5
JackGao
2013-10-12 12:31

我不这么认为!

banq
2013-10-13 11:37

敏捷软件工程方法的真正意图是:通过开发管理的敏捷促成软件系统敏捷,而很多人忽略这个目的,结果导致人忙的要趴下,系统还是老样,这真是缘木求鱼。

人敏捷得像猴,系统还是熊孩子。

走向即时反应,就是让系统变得敏感敏捷,符合达尔文的适变生存。

go reactive宣言 http://www.jdon.com/45811

showerxp
2013-10-15 23:08

2013-10-13 11:37 "@banq"的内容
人敏捷得像猴,系统还是熊孩子。 ...

说的真贴切。

我认为软件建模和敏捷开发是两个不同的思考方向。软件建模关注与业务、归纳、抽象,适应需求变化,敏捷开发如何高效实现。两者完全不是一对排斥的矛盾体,我觉得甚至可以将敏捷开发运用在软件建模的过程,就如“just do it”。

很多人视敏捷如神典,找到理论基础,陶醉于精妙的代码,高效的运行。但是他们不肯将敏捷精神用在需求分析、软件设计。这种现象的逻辑:我们足够敏捷,以至于如果需求变化能快速丢弃原系统(或者大幅改动)而重新实现。

咳,人家爱因斯坦做的两个小板凳都舍不得丢弃,用来做对比。程序员怎么舍得丢弃自己呕心沥血加班得来的软件代码呢?

banq
2013-10-16 11:20

>我们足够敏捷,以至于如果需求变化能快速丢弃原系统(或者大幅改动)而重新实现。

在系统初期,丢弃也是一种前进,通过折腾代码获得认识提高。

是摸着石头敏捷过河,还是首先进行顶层设计,这个选择问题在实际生活中也到处存在。

不管选择哪种方式,目标都是能使系统本身更加敏捷,更具有扩展性 可用性和可靠性。

如果系统很差,开发管理虽然敏捷,那不是围着一堆破铜烂铁在跳舞吗?小型项目的代码可以全部丢弃,一个复杂项目呢?

当然,复杂项目开始阶段,采取敏捷方式,也许能提升队伍对系统的认识层次,抛弃一定代码是值得的,但是项目开发了五年,这么多代码不是说扔就仍吧?

3Go 1 2 3 下一页