社区
研发管理
帖子详情
有多少公司现在在用XP(快速编程)方法开发项目的?
huoji
2004-06-17 02:46:43
rt
...全文
383
21
打赏
收藏
有多少公司现在在用XP(快速编程)方法开发项目的?
rt
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
21 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
huoji
2004-06-23
打赏
举报
回复
to aawolf(羌狼) :
其实刚开始签订合同时就应该保证合同的可扩展性,一切不应说死,至少要说: 如果由于需求发生变更,该合同某些条款将依赖后来签订的协议为准等等。而一切的需求变更,由于是客户提出的,每次需求变更记录上都应该要求客户签字确认。这样到项目结束时用户就无法行问罪之师了。这些都是项目经理的问题,一个好的项目经理是懂得怎麽处理这些情况的。
huoji
2004-06-23
打赏
举报
回复
to asj:
国内的客户水平低,这实在是没有办法的事情。虽然如此,但从项目经理的角度来说,他必须能够处理好和客户的沟通。因为这是他的职责。反过来说,有些迭代甚至是需要强制性的。不论客户需不需要,每到项目做到一定阶段时,就应该让客户看到产品的原型,并且要求他表态。如果他不表态,则认为他已经默许了。这样继续做下去到最后客户说不满意,己方也没有责任。
我可能比较幸运的是,我的客户一般都是国外客户。他们的态度比较积极,所以反复迭代的效果良好。
至于编程方面,我还是觉得结对编程有他本身的局限性。两个人结对,虽然能缩短编码迭代的时间。但这种迭代对一个高水平的程序员来说是没有必要的。保证一个程序的好坏主要还是依赖测试。虽然两个人结对可能会把程序中的一些问题在测试前得到解决,但这样的问题相对于结对的代价来说实在是微不足道的。我倒觉得与其两个人都编程,倒不如一个人专管编程,一个人专管测试来得更好一些。
aawolf
2004-06-23
打赏
举报
回复
同意火鸡的部分说法,XP的确充分考虑了用户需求变化的问题。但是,我们的开发活动开始和结束都是要有合同依据的。
刚开始如果客户不约定合同需要完成哪些功能的话,客户不放心。而最后的版本经过多次迭代后,可能已经与合同规定的大相径庭。那我们如何完成合同呢?如果我们不能按合同约定来完成这个项目,那么,客户随时有需求,我们随时都要改,那什么时候算是个头儿呢?
另外,对于结对,我认为这个过程不是老带新的过程,而是一个相互交流、把不同思想融汇到一段程序中的过程。不能让一个刚毕业的学生和一个十年工作经验的老程序员搭档,那样的话,老程序员说什么就是什么,学生未必能听懂,更不要谈指出错误或者提出自己的思维了。那样就是照猫画虎了。
我觉得《敏捷软件开发》中关于保龄球那个例子恰到好处,两个人拥有一些共同的知识基础,比如UML、OOP等,这是两个人交流的基础。而一个是UNIX Hacker,而另一个人在过程中毫不客气地指出了他的风格问题。这样,两个人就有一种良性的交流,其实这也是两个人相互交流、相互学习的过程。
当然,这一切都建立在相互信任的基础上,如果把两个正在竞争开发部经理的人放在一起,恐怕两人的心思都不在编程上了。自愿原则,是结对编程的基础。所以,在这个问题上,管理层不能左、也不能右,采取一种顺其自然的方式,支持但不强制。
asj
2004-06-23
打赏
举报
回复
to:huoji(火鸡)
我认为你还是在一个实际的(最好小型的)项目中真正实践一下xp。有些看法可能会和现在不同。从你所说的看了,我觉得你还是根据推测来对各项实践进行判断。
xp对客户的要求并不止是看的进展这么简单。事实上,因为客户所处的机构的管理方式和文化。一般来说无法作到唯一客户(很多问题负责联系的人说了不算,也没有足够权限的人进行协调),而进行计划游戏,在有些机构的文化中简直就是天方夜谈。我曾经因为告诉客户一个版本可能推迟2周承受了几乎要把我撕毁的愤怒,但是换个方式,如果你告诉他们项目按时完成了,到时候再进行1个月的调试才实际能用,客户不会有任何怨言。因为在他们的文化中作出决定是很冒风险的事情,会承担责任的,而技术问题是谁也无法左右的。所以他们宁愿项目延迟半年可用,也不会去告诉领导开发期要增加1周。
出于同样的原因,根本不用希望这样的客户会进行版本的特性划分,他们唯一的回答就是:“不论先作哪个,最终这些功能都是要实现的,对吧?”,得到肯定的答复后,他们对于迭代啊版本啊就完全漠不关心了,只是到时候得到一个按时完工的回答就满足了。计划游戏中“功能——时间”进行权衡的精神完全消失,退化成为一个开发进度的承诺。
这些都涉及到了客户方面组织和文化的变化,基本上是不可能实现的。一般来说,如果采用xp。最终开发团队中的人(项目经理或产品经理)会充当事实上客户的角色,作为那个不太理想的现实客户的接口。但是因为项目经理或者产品经理并非真正的最终客户,因而这种代理关系往往会加入很多失真的因素。另一方面,客户的角色往往会和他担当的经理角色发生冲突。这些都和xp增加客户与开发团队间交流,去掉分析员角色的精神向违背了。
至于结对编程,我的建议还是请先尝试再作结论。有些人可能真的不适合这种方式。但是没必要阻止自己进行一下试验。
你说的先需求分析,再模块编程,最终code review。这个我觉得不仅仅是结对不结对的问题。这个反馈循环对于xp来说太长了。当你真的能够把这个循环缩短到几个小时中,可能就会明白结对为什么对xp如此重要了。
huoji
2004-06-23
打赏
举报
回复
关于客户问题,我觉得比较好解决。实际上从客户的角度来说,一个有责任心的用户,他本身也希望能尽快看到项目的进展。所以反复迭代用户时可以理解并且欢迎的。当然首先还是要让用户了解这种开发意图的必要性。另一方面,由于反复迭代,用户的需求已经尽可能的融入到了系统中,在项目末尾的时候,反倒不会出现层出不穷的需求变化了。所以我觉得测试驱动开发确实是一种非常好的方法。我已经把他用在了工作中。但结对编程,不敢苟同。因为两个人的思维方式总是存在差异。对两个水平很低的程序员来说,结对编程确实能减少犯错误的可能性,但对高手而言,互相讨论着做项目,本身思想方式就难以贯通。从这个方面来说,我觉得首先用brain storm方式做好需求设计,项目结尾时做好code review就足够了。单独某个模块的编程工作,还是有单独的人完成的好。
asj
2004-06-23
打赏
举报
回复
呵呵,突然发现你的名字里把xp叫做了“快速编程”
asj
2004-06-23
打赏
举报
回复
看了你的回复,感觉你对xp还是有些了解不充分的。
比如需求变更书面签字记录,还有迭代对高水平的程序员没有必要。这些都不是xp的作法。当然,这并不是说这些方法没有效果,只是说它和xp的精神与思维方式是不同的。在这样的环境下讨论结对,其实得到的不是结对编程在xp中的作用。这个就好像用汇编作一个程序,发现uml还没有流程图有帮助,就认为uml无用一样。
讨论这么多,并不是想强调一定要结对,或者一定要100%的实施xp。具体的选择还是要按自己的需要进行的。但是在判断某项技术是否适用的时候,应该是充分了解,并在适用范围内讨论才是有意义的。否则像现在这样再怎么探讨也是没多大效果的。
最后的建议还是,如果有机会,不妨试验一下。没有必要一开始就告诉自己什么什么一定行不通。另外,充分了解后再试验会使成功率更高一些。
关于高手和高手结对或高手和新手结对的问题,有一本《结对编程技术》里有充分的讨论。如果真的有兴趣,可以看看。
aawolf
2004-06-22
打赏
举报
回复
对不起,说错了,测试驱动开发和重构之间有相互依存关系。而结对边城是Code Review的极限状态,和测试驱动开发没有依存关系。
我现在感到困惑的一点也是在用户这里。我们如果无法实现确定程序的边界的话,我们如何与客户签订合同呢?当程序接近完成的时候,我们如果应付层出不穷的需求变化呢?
而客户对于每次迭代中的变化会采取一种什么样的态度呢?
尽管这些不应该属于XP的讨论范围,但如果真正使用XP时,无疑会受到这种困扰。
asj
2004-06-22
打赏
举报
回复
做过一些尝试,但是还没有进行全公司的推广
测试驱动和结对编程是最基本的。不过我倒不觉得结对需要依赖于测试驱动。
感觉其实最难的改变并不是开发者第一眼看来不习惯的东西(比如结对),而是客户方面的。比如现场客户,还有小版本发布时如何让客户真正的进行反馈。这个需要客户方面全面的融入项目中,而不是以前那种:“我给你钱,到时候你把软件给我就行了。”的方式。
xp对客户的要求相当的高,这个事实上是一个目前没有良好定义的领域。比如如何得到一个唯一确定的客户,客户是否愿意进行计划游戏。我感觉事实上这些已经超出了xp的范畴。可以作为专门的需求分析领域的问题了。
cpluser
2004-06-22
打赏
举报
回复
没用结队编程,不敢做评论。但是XP的一些思想是非常值得借鉴的!我个人觉得软件工程就是在解决一个关系的问题.从外部来讲,有开发人员和客户的关系,开发人员和开发人员的关系,开发人员和测试人员的关系;从内部来讲,代码之间的关系,如包之间的依赖关系,类之间的关系等等。我们怎样有效的合理的去处理和协调这些关系,xp给了我们一些可供参考的经验。其实就像现实生活中一样,各种关系处理好了,如鱼得水;不好则。。。呵呵!写程序就是用代码去描述你眼前的世界,最终归属到你是怎样看待这个世界里各种事物之间的关系的!个人之见,敬请斧正!
liubaoding
2004-06-22
打赏
举报
回复
是啊
值得大家讨论的事情
不要这么一句话就否定拉
你想证明你自己的观点要拿出理由来
aawolf
2004-06-22
打赏
举报
回复
在XP中大家可能最关心的就是结对编程。但是结对编程需要依赖于测试驱动开发。在刚开始的时候,大家完全可以用Code Review的方式来替代结对,当大家对XP逐渐熟悉后,可以考虑结对编程。
如果逐步实施XP的话,我宁可从测试驱动开发开始。
redguardtoo
2004-06-21
打赏
举报
回复
说"结对编程是垃圾"我心理上很难接受.
那么多大师难道都错了?楼上有没有试过结对编程呢,还是仅仅是"觉得"?
我只是在项目中稍微试用了一点有自动测试,和结对(结对检查代码而已)味道的项目管理措施,就显著地改善了项目的质量和效率.
如果楼上认为结对是垃圾,那么什么不是垃圾,该不会是瀑布吧?
huoji
2004-06-21
打赏
举报
回复
结对编程是垃圾,我觉得行不通的
Dualing
2004-06-21
打赏
举报
回复
问一下:XP是什么啊?
li_new
2004-06-21
打赏
举报
回复
估计国内应该不多,看看现在国内的软件行业多么的急功近利,老板会愿意pair-programming?这是要多花Money的!
tuti
2004-06-21
打赏
举报
回复
huoji(火鸡)
结对编程是垃圾,我觉得行不通的.
自己试都没试过,少谈什么垃圾不垃圾.
zhaoxichao
2004-06-18
打赏
举报
回复
XP真正要做到太难了,但是可以采用它有效的一些思想和方法
mycsdnid
2004-06-18
打赏
举报
回复
没有哪个公司会比较规范地使用软件工程方法的
wolfAone
2004-06-18
打赏
举报
回复
几乎出于研究中
加载更多回复(1)
极限
编程
XP
xp
简介
在软件工程领域,随着
项目
复杂性的增加和用户需求的不断变化,敏捷
开发
方法
应运而生,而极限
编程
(Extreme Programming,简称
XP
)便是敏捷
方法
中的一大亮点。它由知名软件
开发
专家Kent Beck提出,并在软件
开发
界引起...
实战突击 PHP
项目
开发
案例整合.pdf
对于有经验的
开发
者,本书提供的案例和代码能够帮助他们
快速
搭建
项目
框架,避免重复劳动,提高
开发
效率。 综上所述,这本书通过一系列实战案例,不仅让读者掌握了PHP语言的
项目
开发
技能,还帮助读者了解了软件工程...
Java极限
编程
.rar
Java极限
编程
是一个深入探讨如何在Java
开发
环境中应用极限
编程
(
XP
)原则和实践的主题。极限
编程
是一种敏捷软件
开发
方法
,它强调
快速
反馈、简洁代码、持续集成和团队合作。免积分意味着这个资源可能是免费提供的,...
敏捷软件
开发
.pdf
敏捷软件
开发
是一种以人为核心、迭代、循序渐进的软件
开发
方法
。它强调
快速
和灵活地响应变化,以适应不断变化的需求。...通过这种
方法
论,团队能够更好地管理
项目
中的不确定性,从而提高软件
开发
项目
的成功率。
21天学会java(完整中文版)
《21天学会Java》是一本专为Java初学者设计的教程,旨在通过简洁明了的方式,让读者在短时间内
快速
掌握Java
编程
基础。本教程涵盖了从安装Java
开发
环境到编写和运行Java程序的全过程,适合想要
快速
入门Java
编程
的人群...
研发管理
1,268
社区成员
28,284
社区内容
发帖
与我相关
我的任务
研发管理
软件工程/管理 管理版
复制链接
扫一扫
分享
社区描述
软件工程/管理 管理版
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章