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

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

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

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

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

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

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

我不这么认为!

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

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

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

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

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

说的真贴切。
我认为软件建模和敏捷开发是两个不同的思考方向。软件建模关注与业务、归纳、抽象,适应需求变化,敏捷开发如何高效实现。两者完全不是一对排斥的矛盾体,我觉得甚至可以将敏捷开发运用在软件建模的过程,就如“just do it”。
很多人视敏捷如神典,找到理论基础,陶醉于精妙的代码,高效的运行。但是他们不肯将敏捷精神用在需求分析、软件设计。这种现象的逻辑:我们足够敏捷,以至于如果需求变化能快速丢弃原系统(或者大幅改动)而重新实现。
咳,人家爱因斯坦做的两个小板凳都舍不得丢弃,用来做对比。程序员怎么舍得丢弃自己呕心沥血加班得来的软件代码呢?

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

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

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

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

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

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


个人觉得,复杂项目中应该持续的完善一个敏捷的构架或者平台。

敏捷的前提,是首先搞清楚,不敏捷是怎么做的,有哪些地方可以敏捷起来,哪些地方是必须按部就班做的。

就像土八路,先变成正规军,然后再进行大裁军,现代化,高效化。

现在是好多土八路还没变成正规军,连游击战都打不好,就忽悠说,我敏捷了。

从零开始,摸着石头过河不是敏捷精神。真敏捷是站在巨人的肩膀上,多读书,多学习让自己获得一个比较高的起点才能做到真的敏捷。各种先进的业务分析、建模技术,各种设计原则、模式,各种优秀的架构设计方法,各种软件开发过程最佳实践等等,越学的多,越敏捷。指望一个啥都懂不了多少的初学者敏捷,这现实吗?

敏捷是对于高手而言。

能开发出程序的,都可以算上高手了。我认为敏捷最值得提倡的就是‘’just do it'的精神。

楼主应该没有在生产环境应用过敏捷。真正的敏捷需要几个核心实践:TDD、持续集成和重构,能做到这几个,叫不叫敏捷都无所谓了。
[该贴被sinaID12260于2014-08-02 08:24修改过]

你在这里不负责人的发表评论,我只问你一个,你真的明白敏捷的深刻含义吗?你真的认为你举的例子准确吗?你会为你的这些评论负责吗、你是个负责任的人吗?