有多少公司现在在用XP(快速编程)方法开发项目的?

huoji 2004-06-17 02:46:43
rt
...全文
383 21 打赏 收藏 转发到动态 举报
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)

1,268

社区成员

发帖
与我相关
我的任务
社区描述
软件工程/管理 管理版
社区管理员
  • 研发管理社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧