敏捷开发讨论


国内大多数软件开发公司都在从瀑布模型向增量开发模型转变,那么如何才能在转变的过程很好的把握住 敏捷 呢?

敏捷开发的xp实践(还有UP,SCRUM,Evo,Crystal)和MSF都提倡角色的对等关系,由SCRUM Master来驱动,它要求程序员都参与各个角色

这样,就导致很多资深的程序员感觉自己不重要了,并且在国内很多程序员都不愿把自己的知识共享给他人。

还有很多程序员习惯了以前的开发模式,自己在公司独立掌握一块,谁都无法参与进来,即使有人参与进来,他也不愿意把他掌握的知识交出来。

如何才能开展敏捷开发,请各位发表意见,让大家分享一下,谢谢!

为什么不能修改啊?郁闷

自己顶一下先,

个人看法:

现在不管是DDD,MDD,FDD,Color modeling, MDA 还是MOF都不是软件开发的重点

我觉得首先你得建立一支好的团队。角色,责任等明确。
其次就是项目采用的开发模型,如Agile(XP,SCRUM,Crystal,UP,Evo),瀑布模型,
再就是架构的思考:DDD,MDD,FDD,Color Modeling,MDA
最后TDD

不知各位见解

>很多资深的程序员感觉自己不重要了,并且在国内很多程序员都不愿把自己的知识共享给他人。

>还有很多程序员习惯了以前的开发模式,自己在公司独立掌握一块

这两个问题其实我在"面向对象与领域建模"一文中说了:
http://www.jdon.com/mda/modeling.html

其实还是没有找到一个双赢的解决之道,这条道路其实就是领域建模。

资深程序员可以从领域建模中体现自己的价值,别看这张UML模型图好像没有什么,其背后隐藏的经验和教训非亲历者不知,因此,这就象一本武功秘籍,很多人看了以后,觉得很简单,但是就是无法练就武功,更不用说画出图来,当然,也有少数人去研究画图技巧,如UML,这些都是妄图快速入门而不得要门的表现,唯一捷径就是:勤学苦练。

这些都是资深程序员的价值。

相反,如果资深程序员在软件架构上倚老卖老,就显得落后了,因为软件架构不断进步,人类思想总是进步的,所以,新的架构总是比老的好,更简单。在这个方面,资深程序员需要不断学习,让新的人参与进来(不过,这不象建模,不是人力可阻挡的)。


资深程序员应该在软件架构上奉行拿来主义,以最好最简单的架构实现自己的模型。

当大家都明白以上道理时,新老程序员才会双赢。


谢谢Banq!

看了你的文章,受益不少,特别是SOA与DDD的评论,可见精辟。

关于软件的复用有个核心的问题在于:构件与组件,现在有很多程序员好像对架构有很多误解,主要体现在对构件与组件之间的区别没能弄清楚,所以经常会到如:xxx_lib.jar(CRUD的集合,也就是model了), xxx_view.jar, xxx_controller.jar这样的文件,也就是把MVC放在三个不同的文件中,好像就表示这就是现今流行的MVC三层架构了,更有甚者将CRUD作为一个Web Service单独发布。

对于color modeling在rose中,如何将它与use ceses, analysis object(sequence diagram), Design class进行映射?

我现在做项目主要采用迭代增量方式(agile practice : XP,Evo,Scrum,UP etc), 架构, 分析 , 构件 , 设计 ,TDD , Refactoring这样一个流程进行软件开发,在这个过程中我发现risk management有更好的控制。

以上三点, 请Banq和各位给点意见,先谢了!

做过几年开发,有点想法,不要盲目跟风去追随所谓的“好的”方法, 没有一个方法能适应所有的环境或背景,方法只有适合不适合。
高层文档
建模
框架,架构的选择
充分沟通
迭代开发
持续继承
代码所有制
自动测试
重构
项目进度的跟踪
工具使用

这几点是我认为对一般软件项目技术上是否能成功,需要注意的地方,一点看法,
欢迎大家批评指正补充展开

>也就是把MVC放在三个不同的文件中,好像就表示这就是现今流行的MVC三层架构了

MVC模式本质是解决流程界面的松耦合,根本目的是为业务对象服务,如果追求形式,将MVC放在三个不同的文件中,我不知道是将什么放在jar中,目的是为重用业务流程? 如果是这样,应该是业务层重用(选择工作流等),而不是表现层MVC的重用。

>对于color modeling在rose中,如何将它与use ceses, analysis object(sequence diagram), Design class进行映射?
CM是很早期的分析,介于use ceses和analysis object之间,CM是不能直接映射到设计阶段的,这时如果使用Evans DDD的方式详细建模,就能够和Design Class直接映射了。

我个人觉得现在社会所谓流行的RUP模式多数是在炒概念或者只浮于形式而不得其思想---或许我太悲观了(毕竟形式到思想的真谛需要一个过程,而且形式也是一种进步吧)。
我个人决的敏捷也好,XP也好都是经历传统的RUP方式痛苦的经验的总结,目标驱动是最明显的特征---其影响的手段是测试先行。而敏捷的东西加入以人为本的特征,理论都在满天飞,但是在工作中却没有太多灵活运用,所谓因地制宜,因材施教,不能抱这这些形式东西就当作真理,而不明其真谛,不能根据项目实际的情况作出比较适当的调整,这是我在国内软件公司的体会。相反我现在在香港一家NCSI的公司一个项目组中,他们使用可以说各取所需的RUP的方式,没有很多教条主义限制。没有错,他们项目stage 管理十分严谨,不能有任何偏差---对客户的和合约的执行力很强,但是内部的项目管理基本很灵活,根据项目和自己项目组情况灵活调整,使用方式基本基于IBM 的体系---但只限当作工具使用,例如使用IBM modeler /RSA/IRAD/SCM--IBM CC 等,项目进度由于开发实际委托给国内的一家外包公司,自己只是负责需求和架构和详细设计以及项目管理。我们也出现了delay现象,但是我们主要根据情况调整我们自己的plan和rup 的方式基本还是能把握住主体进度,其中我们使用形式上RUP 方式有BDD(面向业务),SOA的敏捷和迭代,在项目松动时又走传统的瀑布型的。其目标只有一个在危急时使用项目成本尽可能小的马上见效果的,在允许情况下为项目的风险和控制好的方式。
其实项目的目标就是动起来,其实控制风险和成本,要在必要的实际情况作出最合理的折中方式。没有完美的方式/形式,只有权衡最没风险地达到项目的目标。

recher观点很好,我们需要根据实际情况来选择RUP或敏捷。

再结合楼主观点"现在不管是DDD,MDD,FDD,Color modeling, MDA 还是MOF都不是软件开发的重点,我觉得首先你得建立一支好的团队。角色,责任等明确。"

我想谈谈我的看法:

RUP或敏捷都流于形式,我们不必一定给我们的方式取个名称,名可名,非常名。

当然,问题关键也不是在于"建立一个好的团队",这也是围着鼓边敲鼓,我们需要一个切实可行的解决之道。

围绕领域模型的不断推进才是切实的项目开发解决之道。

不断推进过程中,有时使用传统的瀑布型的;但是有时得螺旋式上升,否定之否定的迭代。

原因很简单:领域模型不同于其他模型,它将分析和设计完整统一起来,从而将整个开发团队的工作上从本质上和需求联系在一起,如果再配合以灵活可拓展的架构,那么整个开发工作就可以达到软件开发最高境界:需求变化有多快,软件就变化有多快。

我觉得这是一个很简单有效的道理,就象现代战争已经进入信息化战争一样,电子信息技术就是打赢现代战争的根本之道,而不是喊几句口号就可以的;DDD是现在软件开发工作的根本解决之道,它虽然是一个名词,但是它不同于以往那些名词,如果简单从名词排列上认为DDD不过是众多名词之一,那就不理解"名可名,非常名"的意思了。


>围绕领域模型的不断推进才是切实的项目开发解决之道
>问题关键也不是在于"建立一个好的团队",这也是围着鼓边敲鼓,我们需要一个切实可行的解决之道。


Banq,好像有点误解我的意思。

诚然,域模型确实很重要,但它是建立在人的基础之上的,也就是需要一个好的团队,首先它得有业务方面的专家,还要有系统设计方面的好手,否则,业务分析的再好,没有很好的架构和设计,以及正确的开发模式,很难获得项目的成功。

>名可名,非常名
要想达到这样的程度,首先得有“名”,然后再到“非常名”。就像设计模式一样,最开始你如果没有一个“名”,何来的“非常名”,正如剑道:手中有剑,心中亦有剑。手中有剑,心中无剑。手中无剑,心中亦无剑。剑的最高境界是无剑。

我曾见过很多程序员,拿着个名词,MOF。当然,还有对应的UML图,就到处说自己是架构师,还有很多程序员说他在一个项目中运用了所有的设计模式,很可笑,别说gof的24种设计模式已经是非常深奥的了,还有很多新的设计模式。每一种设计模式还有其变体。懂得适时而用才是关键。很多时候,我在重构的时候,总要去掉不少的设计模式,换之以更简单的实现方式。


所以,在开发项目中,人的因素至关重要,其次才是开发,当然,我也非常同意Banq的领域模型的说法。

中国真正有多少人真的懂设计模式
真的理解设计模式
真的能把设计模式应用起来
真的是一个值得怀疑的事情

说一个事情,我读研究生的时候有一门课程好像叫面向对象什么的,老师主要讲如何用面向对象的思想,课程结束的时候要求每个人用面向对象的思想设计一个系统,我不是一个好学生,所以一直到前一天的时间我花了2个小时用C++ builder写了人员管理小程序(老师、学生等等),就是简单的CUID,不过界面很花哨,不过可没有用到什么面向对象的东西,直接直接操作access。可是上去之后俺就开始说,这老师、学生都是人,然后泛化,中间用到了XXX模式来解决数据库替换问题,用XXX模式来完成人员查找算法的替换问题,用XXX模式提供统一的界面给用户,最后老师给我大大的好评,得了满分优。

不是说在沾沾自喜什么,只是觉得好像现在的大学课程真的跟上了时代潮流,但是真的有多少老师真的明白自己教的东西??如果自己都不明白又怎么去教会自己的学生那??

项目中永远是人的因素是最不稳定的。好的项目一群好的程序员开发会赏心悦目,一群不好的程序员开发基本上就是往水里扔钱。

一个好的工具是成功的一半,尤其对这些敏捷开发,更是如此.同意楼上所讲的,目前好的工具并不多见,ScrumWorks 和VersionOne 显然不是很好,而且价格太贵.如果有哪个团队正在或将要采用Scrum,不妨试一试AgileTime,这是一个不错的工具,看得出该系统的开发人员对Scrum有很好的理解:打开www.agiletime.com.cn,然后用AT1026/demo登入.

一个好的工具是成功的一半,尤其对这些敏捷开发,更是如此.同意楼上所讲的,目前好的工具并不多见,ScrumWorks 和VersionOne 显然不是很好,而且价格太贵.如果有哪个团队正在或将要采用Scrum,不妨试一试AgileTime,这是一个不错的工具,看得出该系统的开发人员对Scrum有很好的理解:打开www.agiletime.com.cn,然后用AT1026/demo登入.

努力学中设计模式中

-------------------------------------------------------------
java comm,Java USB,RXTX
rs232-rs485/rs422 converter,usb to rs232/rs485/rs422
keeping communicate fast and easy
http://www.hexin-tech.com.cn/
-------------------------------------------------------------

敏捷如何处理知识积累的问题?

对于一些外包公司,在某个项目上可能已经开发了3个月,有了n多的程序;如果这时候外包公司撤换一批人员,那么在短短的几天或者十几天的交接过程里,新人很难理解掌握已有的知识。经过几次这样的撤换就会导致……以前的程序没人敢动,没人明白。

敏捷的文档化或者说知识积累要做到什么程度?

看到大家讨论的这么兴高采烈,看完了以后觉得真开心,因为我们中国有这么一批人一直在探讨着怎么去实现我们的思想!
爽!向大家学习!我大三,对敏捷开发方法不了解,但是我也有同样的一个问题就是某个项目换人了,敏捷开发方法怎么去适应这种变化,是不是敏捷开发方法还是要跟其他的开发方法一并使用?