|
这个主题共有 12 回复 ／ 1 页 [
]
|
|
|
|
|
|
敏捷开发讨论
|
发表: 2006年12月23日 18:33
|
回复
|
|
国内大多数软件开发公司都在从瀑布模型向增量开发模型转变，那么如何才能在转变的过程很好的把握住 敏捷 呢?
敏捷开发的xp实践(还有UP,SCRUM,Evo,Crystal)和MSF都提倡角色的对等关系，由SCRUM Master来驱动，它要求程序员都参与各个角色
这样，就导致很多资深的程序员感觉自己不重要了，并且在国内很多程序员都不愿把自己的知识共享给他人。
还有很多程序员习惯了以前的开发模式，自己在公司独立掌握一块，谁都无法参与进来，即使有人参与进来，他也不愿意把他掌握的知识交出来。
如何才能开展敏捷开发，请各位发表意见，让大家分享一下，谢谢！
|
|
|
|
|
|
Re: 敏捷开发讨论
|
发表: 2006年12月23日 18:43
|
回复
|
|
为什么不能修改啊？郁闷
自己顶一下先，
个人看法：
现在不管是DDD,MDD,FDD,Color modeling, MDA 还是MOF都不是软件开发的重点
我觉得首先你得建立一支好的团队。角色，责任等明确。
其次就是项目采用的开发模型，如Agile(XP,SCRUM,Crystal,UP,Evo)，瀑布模型，
再就是架构的思考：DDD,MDD,FDD,Color Modeling,MDA
最后TDD
不知各位见解
|
|
|
|
|
|
Re: 敏捷开发讨论
|
发表: 2006年12月25日 15:22
|
回复
|
|
>很多资深的程序员感觉自己不重要了，并且在国内很多程序员都不愿把自己的知识共享给他人。
>还有很多程序员习惯了以前的开发模式，自己在公司独立掌握一块
这两个问题其实我在"面向对象与领域建模"一文中说了:
http://www.jdon.com/mda/modeling.html
其实还是没有找到一个双赢的解决之道，这条道路其实就是领域建模。
资深程序员可以从领域建模中体现自己的价值，别看这张UML模型图好像没有什么，其背后隐藏的经验和教训非亲历者不知，因此，这就象一本武功秘籍，很多人看了以后，觉得很简单，但是就是无法练就武功，更不用说画出图来，当然，也有少数人去研究画图技巧，如UML，这些都是妄图快速入门而不得要门的表现，唯一捷径就是：勤学苦练。
这些都是资深程序员的价值。
相反，如果资深程序员在软件架构上倚老卖老，就显得落后了，因为软件架构不断进步，人类思想总是进步的，所以，新的架构总是比老的好，更简单。在这个方面，资深程序员需要不断学习，让新的人参与进来（不过，这不象建模，不是人力可阻挡的）。
资深程序员应该在软件架构上奉行拿来主义，以最好最简单的架构实现自己的模型。
当大家都明白以上道理时，新老程序员才会双赢。
|
|
|
|
|
|
Re: 敏捷开发讨论
|
发表: 2006年12月26日 03:28
|
回复
|
|
谢谢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和各位给点意见，先谢了！
|
|
|
|
|
|
Re: 敏捷开发讨论
|
发表: 2006年12月26日 17:26
|
回复
|
|
做过几年开发，有点想法，不要盲目跟风去追随所谓的“好的”方法， 没有一个方法能适应所有的环境或背景，方法只有适合不适合。
高层文档
建模
框架，架构的选择
充分沟通
迭代开发
持续继承
代码所有制
自动测试
重构
项目进度的跟踪
工具使用
这几点是我认为对一般软件项目技术上是否能成功，需要注意的地方，一点看法，
欢迎大家批评指正补充展开
|
|
|
|
|
|
Re: 敏捷开发讨论
|
发表: 2006年12月27日 10:44
|
回复
|
|
>也就是把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直接映射了。
|
|
|
|
|
|
Re: 敏捷开发讨论
|
发表: 2006年12月28日 23:32
|
回复
|
|
我个人觉得现在社会所谓流行的RUP模式多数是在炒概念或者只浮于形式而不得其思想---或许我太悲观了（毕竟形式到思想的真谛需要一个过程，而且形式也是一种进步吧）。
我个人决的敏捷也好，XP也好都是经历传统的RUP方式痛苦的经验的总结，目标驱动是最明显的特征---其影响的手段是测试先行。而敏捷的东西加入以人为本的特征，理论都在满天飞，但是在工作中却没有太多灵活运用，所谓因地制宜，因材施教，不能抱这这些形式东西就当作真理，而不明其真谛，不能根据项目实际的情况作出比较适当的调整，这是我在国内软件公司的体会。相反我现在在香港一家NCSI的公司一个项目组中，他们使用可以说各取所需的RUP的方式，没有很多教条主义限制。没有错，他们项目stage 管理十分严谨，不能有任何偏差---对客户的和合约的执行力很强，但是内部的项目管理基本很灵活，根据项目和自己项目组情况灵活调整，使用方式基本基于IBM 的体系---但只限当作工具使用，例如使用IBM modeler /RSA/IRAD/SCM--IBM CC 等，项目进度由于开发实际委托给国内的一家外包公司，自己只是负责需求和架构和详细设计以及项目管理。我们也出现了delay现象，但是我们主要根据情况调整我们自己的plan和rup 的方式基本还是能把握住主体进度，其中我们使用形式上RUP 方式有BDD(面向业务),SOA的敏捷和迭代，在项目松动时又走传统的瀑布型的。其目标只有一个在危急时使用项目成本尽可能小的马上见效果的，在允许情况下为项目的风险和控制好的方式。
其实项目的目标就是动起来，其实控制风险和成本，要在必要的实际情况作出最合理的折中方式。没有完美的方式/形式，只有权衡最没风险地达到项目的目标。
|
|
|
|
|
|
Re: 敏捷开发讨论
|
发表: 2006年12月30日 11:35
|
回复
|
|
recher观点很好，我们需要根据实际情况来选择RUP或敏捷。
再结合楼主观点"现在不管是DDD,MDD,FDD,Color modeling, MDA 还是MOF都不是软件开发的重点，我觉得首先你得建立一支好的团队。角色，责任等明确。"
我想谈谈我的看法：
RUP或敏捷都流于形式，我们不必一定给我们的方式取个名称，名可名，非常名。
当然，问题关键也不是在于"建立一个好的团队"，这也是围着鼓边敲鼓，我们需要一个切实可行的解决之道。
围绕领域模型的不断推进才是切实的项目开发解决之道。
不断推进过程中，有时使用传统的瀑布型的；但是有时得螺旋式上升，否定之否定的迭代。
原因很简单：领域模型不同于其他模型，它将分析和设计完整统一起来，从而将整个开发团队的工作上从本质上和需求联系在一起，如果再配合以灵活可拓展的架构，那么整个开发工作就可以达到软件开发最高境界：需求变化有多快，软件就变化有多快。
我觉得这是一个很简单有效的道理，就象现代战争已经进入信息化战争一样，电子信息技术就是打赢现代战争的根本之道，而不是喊几句口号就可以的；DDD是现在软件开发工作的根本解决之道，它虽然是一个名词，但是它不同于以往那些名词，如果简单从名词排列上认为DDD不过是众多名词之一，那就不理解"名可名，非常名"的意思了。
|
|
|
|
|
|
Re: 敏捷开发讨论
|
发表: 2007年01月01日 01:54
|
回复
|
|
>围绕领域模型的不断推进才是切实的项目开发解决之道
>问题关键也不是在于"建立一个好的团队"，这也是围着鼓边敲鼓，我们需要一个切实可行的解决之道。
Banq,好像有点误解我的意思。
诚然，域模型确实很重要，但它是建立在人的基础之上的，也就是需要一个好的团队，首先它得有业务方面的专家，还要有系统设计方面的好手，否则，业务分析的再好，没有很好的架构和设计，以及正确的开发模式，很难获得项目的成功。
>名可名，非常名
要想达到这样的程度，首先得有“名”，然后再到“非常名”。就像设计模式一样，最开始你如果没有一个“名”，何来的“非常名”，正如剑道：手中有剑，心中亦有剑。手中有剑，心中无剑。手中无剑，心中亦无剑。剑的最高境界是无剑。
我曾见过很多程序员，拿着个名词，ＭＯＦ。当然，还有对应的ＵＭＬ图，就到处说自己是架构师，还有很多程序员说他在一个项目中运用了所有的设计模式，很可笑，别说gof的24种设计模式已经是非常深奥的了，还有很多新的设计模式。每一种设计模式还有其变体。懂得适时而用才是关键。很多时候，我在重构的时候，总要去掉不少的设计模式，换之以更简单的实现方式。
所以，在开发项目中，人的因素至关重要，其次才是开发，当然，我也非常同意Banq的领域模型的说法。
|
|
|
|
|
|
re:敏捷开发讨论
|
发表: 2007年02月14日 11:18
|
回复
|
|
中国真正有多少人真的懂设计模式
真的理解设计模式
真的能把设计模式应用起来
真的是一个值得怀疑的事情
说一个事情，我读研究生的时候有一门课程好像叫面向对象什么的，老师主要讲如何用面向对象的思想，课程结束的时候要求每个人用面向对象的思想设计一个系统，我不是一个好学生，所以一直到前一天的时间我花了2个小时用C++ builder写了人员管理小程序（老师、学生等等），就是简单的CUID，不过界面很花哨，不过可没有用到什么面向对象的东西，直接直接操作access。可是上去之后俺就开始说，这老师、学生都是人，然后泛化，中间用到了XXX模式来解决数据库替换问题，用XXX模式来完成人员查找算法的替换问题，用XXX模式提供统一的界面给用户，最后老师给我大大的好评，得了满分优。
不是说在沾沾自喜什么，只是觉得好像现在的大学课程真的跟上了时代潮流，但是真的有多少老师真的明白自己教的东西？？如果自己都不明白又怎么去教会自己的学生那？？
项目中永远是人的因素是最不稳定的。好的项目一群好的程序员开发会赏心悦目，一群不好的程序员开发基本上就是往水里扔钱。
|
|
|
|
|
|
re:敏捷开发讨论
|
发表: 2007年05月25日 23:48
|
回复
|
|
|
一个好的工具是成功的一半,尤其对这些敏捷开发,更是如此.同意楼上所讲的,目前好的工具并不多见,ScrumWorks 和VersionOne 显然不是很好，而且价格太贵.如果有哪个团队正在或将要采用Scrum,不妨试一试AgileTime,这是一个不错的工具,看得出该系统的开发人员对Scrum有很好的理解:打开www.agiletime.com.cn,然后用AT1026/demo登入.
|
|
|
|
|
|
re:敏捷开发讨论
|
发表: 2007年05月25日 23:49
|
回复
|
|
|
一个好的工具是成功的一半,尤其对这些敏捷开发,更是如此.同意楼上所讲的,目前好的工具并不多见,ScrumWorks 和VersionOne 显然不是很好，而且价格太贵.如果有哪个团队正在或将要采用Scrum,不妨试一试AgileTime,这是一个不错的工具,看得出该系统的开发人员对Scrum有很好的理解:打开www.agiletime.com.cn,然后用AT1026/demo登入.
|
|
|
|
|
|
re:敏捷开发讨论
|
发表: 2008年03月05日 21:54
|
回复
|
|
努力学中设计模式中
-------------------------------------------------------------
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/
-------------------------------------------------------------
|
|
|
|
注册
登陆
上一主题
下一主题
