全部
问答

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

huoji 2004-06-17 02:46:43

...全文

341 点赞收藏 21

写回复

21 条回复

切换为时间正序

当前发帖距今超过3年，不再开放新的回复

发表回复

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

没用结队编程，不敢做评论。但是ＸＰ的一些思想是非常值得借鉴的！我个人觉得软件工程就是在解决一个关系的问题．从外部来讲，有开发人员和客户的关系，开发人员和开发人员的关系，开发人员和测试人员的关系；从内部来讲，代码之间的关系，如包之间的依赖关系，类之间的关系等等。我们怎样有效的合理的去处理和协调这些关系，ｘｐ给了我们一些可供参考的经验。其实就像现实生活中一样，各种关系处理好了，如鱼得水；不好则。。。呵呵！写程序就是用代码去描述你眼前的世界，最终归属到你是怎样看待这个世界里各种事物之间的关系的！个人之见，敬请斧正！

回复赞