|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-07-02
emarket 写道 非常同意您的观点，新手和高手的相对性。
但是pair programming 是在干活， 不是在培训（当然有些人也可以把它当作副产品）。 学东西完全可以业余时间学，如果公司要培训 送去上个培训班也行。 自学花一个月的东西 pair能够一周搞定 确实有点夸张。 很多东西如果不能系统的学习 而只是听别人说，很难做到举一反三的。 当然我也不否认和高手pair有画龙点睛的效果，不过自己还得花大力气去画龙才行。 引用 taowen 2 小时前 新手和老手不是一个工作年限上的问题.新手可能是一个有十多年java经验的开发者,但是已开始到一个RoR项目上,他就是一个新手.所以从这个角度再来看,一个项目有非常多的理由不能配备足够的所谓的"高级程序员".想让一个项目从一开始到结束都全部配备水平均等的程序员,是不现实的.从整个产业的角度来讲,每年都有那么多新毕业的学生,他们肯定是需要成长的.pair从我看来无论在项目内还是在整个公司角度,都是最有效的"知识迁移"和"人才培养"的手段.而且,也不光是一个新带老的问题.pair在促进交流,提高团队成员对所有代码的责任感等很多方面都有作用. 任何有过管理实际项目经验的客户,对于这种情况的存在都是知道的.没有谁会天真的要求软件开发公司把他们所有的SA,SE都放在他的项目上.他是付不起那么钱的.因为这样算上软件公司要付出的很多机会成本(一个SA,可能就能带一个新的项目). 表面上来说,成本是增加的.但是这种成本是固有存在的.如果团队或者公司有一个人需要去了解一方面的知识,公司就需要投入成本让他成长.这种成本可以体现为一个人,低效地去自学去提高一两个月.也可以体现为两个人,效率稍低地工作一两个星期. 自学的东西当然有，这些东西一般情况下，只能是个人下班回家自己学去，除非是没有项目或者是公司专门的培训。 一般讨论的当然是这些学习不能解决的问题，否则要工作经验干吗？这类的学习必须是工作中才能掌握的。 既然是工作中才能掌握的，pair的方式就是效率极高的一种带新人的方式。 |
| 返回顶楼 | |
|
发表时间：2008-07-03
PP这个东西，我一开始就觉得不行，最起码没有自由了。
PS，要是领导一定要求我PP，那么必须是MM，否则GG我就走人 |
| 返回顶楼 | |
|
发表时间：2008-07-03
比较赞同= =虽然以前没这么想过～
|
| 返回顶楼 | |
|
发表时间：2008-07-05
其实我很想尝试PP，可惜没有机会。。。
|
| 返回顶楼 | |
|
发表时间：2008-07-07
一天全pair也太离谱了一点,我们以前公司一般一天就是pair 2-4个小时
|
| 返回顶楼 | |
|
发表时间：2008-07-07
不讲什么？
|
| 返回顶楼 | |
|
发表时间：2008-07-09
pp是咋回事？两个共用用一台电脑？
如果不是，pair就不能相互勾结，获得娱乐时间？ pp更多是强调讨论的价值，思维互补，轮休，代码监督吧？ 思路决定出路！ |
| 返回顶楼 | |
|
发表时间：2008-07-14
icewubin 写道 emarket 写道 另外有时候两个绝顶高手pair也会有问题,首先从benefit来讲，不大，TDD, refactoring, DI, Pattern已经能够如火纯清，用不着另外一个人看着，多性能处理器似的大脑，已经能够递归到第N层。反而意见的分歧往往会抹杀创造的火花，而提出折中的方案。 这只能说明其中一个真正的懂沟通的人也没有，高手也是要学习沟通技巧的。 首先在结对模式下，主要负责编的高手可以不需要反复对自己的构想进行复查，因为有另一个人帮你看着，没有后顾之忧，效率是极高的，不知道搂主有没有体会。 同时帮你看着的那个高手，不能因为意见的分歧而打断你，要么事先和你讨论好，要么暂时妥协先跟着你的思路走，然后等你告一段落后再重构。 方法是死的，人是活的。 效率极高有，但是很少 ，跟所作的东西和pair的人有关，所以觉得PP不值。 一个有着这么强的适用局限的方法，注定是不会普及的。 |
| 返回顶楼 | |
|
发表时间：2008-07-14
icewubin 写道 emarket 写道 非常同意您的观点，新手和高手的相对性。
但是pair programming 是在干活， 不是在培训（当然有些人也可以把它当作副产品）。 学东西完全可以业余时间学，如果公司要培训 送去上个培训班也行。 自学花一个月的东西 pair能够一周搞定 确实有点夸张。 很多东西如果不能系统的学习 而只是听别人说，很难做到举一反三的。 当然我也不否认和高手pair有画龙点睛的效果，不过自己还得花大力气去画龙才行。 引用 taowen 2 小时前 新手和老手不是一个工作年限上的问题.新手可能是一个有十多年java经验的开发者,但是已开始到一个RoR项目上,他就是一个新手.所以从这个角度再来看,一个项目有非常多的理由不能配备足够的所谓的"高级程序员".想让一个项目从一开始到结束都全部配备水平均等的程序员,是不现实的.从整个产业的角度来讲,每年都有那么多新毕业的学生,他们肯定是需要成长的.pair从我看来无论在项目内还是在整个公司角度,都是最有效的"知识迁移"和"人才培养"的手段.而且,也不光是一个新带老的问题.pair在促进交流,提高团队成员对所有代码的责任感等很多方面都有作用. 任何有过管理实际项目经验的客户,对于这种情况的存在都是知道的.没有谁会天真的要求软件开发公司把他们所有的SA,SE都放在他的项目上.他是付不起那么钱的.因为这样算上软件公司要付出的很多机会成本(一个SA,可能就能带一个新的项目). 表面上来说,成本是增加的.但是这种成本是固有存在的.如果团队或者公司有一个人需要去了解一方面的知识,公司就需要投入成本让他成长.这种成本可以体现为一个人,低效地去自学去提高一两个月.也可以体现为两个人,效率稍低地工作一两个星期. 自学的东西当然有，这些东西一般情况下，只能是个人下班回家自己学去，除非是没有项目或者是公司专门的培训。 一般讨论的当然是这些学习不能解决的问题，否则要工作经验干吗？这类的学习必须是工作中才能掌握的。 既然是工作中才能掌握的，pair的方式就是效率极高的一种带新人的方式。 “工作中才能掌握的“ 不能推出 “pair的方式就是效率极高的一种带新人的方式“ 1. pair是一对一 效率显然低于一对多 2. pair的时候高手的思路 （解决问题） 明显别于 培训的时候的老师的 思路 （传道授业）。 3. 代新人的成本不能bill给customer. |
| 返回顶楼 | |
|
发表时间：2008-07-14
emarket 写道 icewubin 写道 emarket 写道 非常同意您的观点，新手和高手的相对性。
但是pair programming 是在干活， 不是在培训（当然有些人也可以把它当作副产品）。 学东西完全可以业余时间学，如果公司要培训 送去上个培训班也行。 自学花一个月的东西 pair能够一周搞定 确实有点夸张。 很多东西如果不能系统的学习 而只是听别人说，很难做到举一反三的。 当然我也不否认和高手pair有画龙点睛的效果，不过自己还得花大力气去画龙才行。 引用 taowen 2 小时前 新手和老手不是一个工作年限上的问题.新手可能是一个有十多年java经验的开发者,但是已开始到一个RoR项目上,他就是一个新手.所以从这个角度再来看,一个项目有非常多的理由不能配备足够的所谓的"高级程序员".想让一个项目从一开始到结束都全部配备水平均等的程序员,是不现实的.从整个产业的角度来讲,每年都有那么多新毕业的学生,他们肯定是需要成长的.pair从我看来无论在项目内还是在整个公司角度,都是最有效的"知识迁移"和"人才培养"的手段.而且,也不光是一个新带老的问题.pair在促进交流,提高团队成员对所有代码的责任感等很多方面都有作用. 任何有过管理实际项目经验的客户,对于这种情况的存在都是知道的.没有谁会天真的要求软件开发公司把他们所有的SA,SE都放在他的项目上.他是付不起那么钱的.因为这样算上软件公司要付出的很多机会成本(一个SA,可能就能带一个新的项目). 表面上来说,成本是增加的.但是这种成本是固有存在的.如果团队或者公司有一个人需要去了解一方面的知识,公司就需要投入成本让他成长.这种成本可以体现为一个人,低效地去自学去提高一两个月.也可以体现为两个人,效率稍低地工作一两个星期. 自学的东西当然有，这些东西一般情况下，只能是个人下班回家自己学去，除非是没有项目或者是公司专门的培训。 一般讨论的当然是这些学习不能解决的问题，否则要工作经验干吗？这类的学习必须是工作中才能掌握的。 既然是工作中才能掌握的，pair的方式就是效率极高的一种带新人的方式。 “工作中才能掌握的“ 不能推出 “pair的方式就是效率极高的一种带新人的方式“ 1. pair是一对一 效率显然低于一对多 2. pair的时候高手的思路 （解决问题） 明显别于 培训的时候的老师的 思路 （传道授业）。 3. 代新人的成本不能bill给customer. 1.应该说是不特别占用时间的情况下，结合实际项目的一种带新人的方式，同时能完成工作任务，不需要以后太多的交接和沟通成本。这个效率极高，是这样的出来的。 2.刚才说过了，和特别的一对多的培训是不能比的，不是那种不完成生产任务的培训时间。 3.没有说要把带新人的成本bill给customer。现实是很多项目一般都是1老带1-3新，或者2老带2-5新，以此类推。很有可能的一种状态是，为了“快速”完成项目，分配好任务以后，各管各。结果，代码风格多达3种以上，新人不断的问老员工问题（也顺带打断老员工的思路，一打断就直接加间接浪费老员工15分钟，这是有科学依据的），某个新人或者老人因为“救火”或者离职导致巨大的交接成本，还因为代码风格不一致，之后接手的人如同落至地狱（还会蹦出“与其让我改这垃圾代码，不如让我重写”的让项目经理发毛的语录），等等，鲜活的例子太多了，请问这些不用customer付账么？国内的情况来说一般customer才不管呢，多半就是项目延期而已，付账的是公司自己啊。 4.说的直白点，在软件过程管理非常不规范的国内公司；在大部分人非常不喜欢写文档，写了也懒的积极更新的国内程序员；在国内程序员大部分会不自觉的上QQ、MSN聊八卦等等情况下，结对还是效益不错的。当然啦，没必要8小时结对嘛，开个玩笑，如果真的8小时结对，还能省一台电脑的成本和电费。 |
| 返回顶楼 | |
