|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-06-27
自学和training有帮助,但是和pairing不是替代关系.
对于有的时候不必要pair的问题,同意你的观点.我在工作中,做spike的时候就是solo的.但是做完了spike,做story的时候就一定要pair,因为spike的东西往往是有难度不好弄的东西,不和别人的pair,别人就可能看不懂这块代码.如果你roll off了,这块代码可能就没人敢碰了.于是请假回个家可能都会被同事的电话打扰. |
| 返回顶楼 | |
|
发表时间：2008-06-27
引用 1. 如果是solo, 我一天最多工作2-3个小时，其它时间用于update自己的knowlege和research。用于交流（大部分是争论和说服）的时间完全可以节约下来。 而且最大的好处是可以working from home.没有必要一定要去office 2. solo的艺术在于个人时间和工作实践的统一，所以老板不会觉得你在surf internet. 但是pair之外的个人时间，大部分老板还是想不开的(我要去pay那人在天涯上灌水？)。当然你可以argu我是在看技术网站，但是你不能保证其他人就不看风月网站。 1.如果你的工作就是这么安排，有较多的research，那没有问题，你可以每天只pair 2-3个小时，这是你工作性质不同引起的，大多数的开发人员是不可能被boss安排成这样的 2.对于第二点，也是很关键的，敏捷不只是程序员甚至不只是项目经理的事，也是公司管理层面的事情，需要将敏捷的思想传播到公司的每一层并得到他们的理解，也就是要让boss明白让员工每天去天涯灌水1小时(只是个例子)可以提高工作质量。所以敏捷导师的作用就非常巨大， 他需要跟不同的人，进行不同层面的沟通，这也是一个长期的过程。 |
| 返回顶楼 | |
|
发表时间：2008-06-28
什么东西就是思想再好，要是乱用，死用，别有用心的用，那也是垃圾的，结对编程更多引导的是整个团队的高度交流，更透彻的需求分析，程序设计，并非只有两个人才是这个过程的起点和终点！
|
| 返回顶楼 | |
|
发表时间：2008-06-28
我还是比较赞同PP的，但PP并不是对任何人都合适。
我们公司的一个过程管理的Leader曾经说，XP，包括PP，最适合高度成熟和高度自律的程序员。这句话我非常赞同。 不要让Senior和Junior PP，那是虐待。 一个tutor和我一起解决问题，体验PP的时候，我连走神的想法都没有。。。 |
| 返回顶楼 | |
|
发表时间：2008-06-30
早就看Xp中提出的结对编程不顺眼了，不过一个写程序，一个写测试还是值得借鉴。
|
| 返回顶楼 | |
|
发表时间：2008-06-30
任何企图去除个人效应的目的都是适得其反
微软大概也是这个毛病 |
| 返回顶楼 | |
|
发表时间：2008-07-01
yh_private 写道 来简单说下我的pair，现在可以说是一个老手一个新手在结对，新手完全可以自己干好所有的事情，他知道需求，老手对需求知道的要少些。
我们每天早上可以拿出时间两个人去读新闻，然后看资料，做点自己喜欢的事情，大概一个小时左右之后我们开始pair，我们并不担心看新闻聊天所浪费的时间，因为我们可以用两个小时的时间去做4个小时所做的事情。 （这并不是说pair可以直接提高编程效率。） 中午休息之后也是一样地。一个小时可以喜欢做什么就做什么 另类情况？？ |
| 返回顶楼 | |
|
发表时间：2008-07-02
protti 写道 yh_private 写道 来简单说下我的pair，现在可以说是一个老手一个新手在结对，新手完全可以自己干好所有的事情，他知道需求，老手对需求知道的要少些。
我们每天早上可以拿出时间两个人去读新闻，然后看资料，做点自己喜欢的事情，大概一个小时左右之后我们开始pair，我们并不担心看新闻聊天所浪费的时间，因为我们可以用两个小时的时间去做4个小时所做的事情。 （这并不是说pair可以直接提高编程效率。） 中午休息之后也是一样地。一个小时可以喜欢做什么就做什么 另类情况？？ 你指的另类情况是？我说的新手是指这个家伙也在软件也干了一段时间了，最近一直混在当前项目里。老手刚从别的项目调来。 顺便回复下emarket，你说的很有道理，写代码的确不会在时间上提升75%，我们也严格控制速度。保持1+1=1.5左右，但你在结对时有没有发现。两个人在一起的时候精神很集中。我们都关QQ GT MSN，不看网页可以说是满效的两小时，和一个人松散的4小时比起来慢不了多少。而且代码的质量会提高很多，我们也很少因为开发时找个莫名其妙的错误耽误10几分钟的时间。 最后关于你说早上先pair，我想这个事情可以灵活的去做，并不一定要早上，并不一定要什么什么时间来放松，我们要的是花点时间把两个人的状态都调整好，这样开始才会高效，如果一个人在不停的干活，边上那个鬼却似乎要睡着了，那就没有必要pair了不是？ |
| 返回顶楼 | |
|
发表时间：2008-07-02
emarket 写道 用两个小时做4个小时的事，说法有点夸张 （我只你把它归结到pair programming），刚才还有个朋友说如果老手不合和新手pair会以2-3倍的速度完成task。 一般的用XP的公司都没有说8个小时pair的， 6-7个小时属于普遍。不过我很难赞成你们用用两个小时的时间去做4个小时所做的事情是pair programming的结果。
假设 A和B, 分别完成task1, task2, 需要 4小时， 也就是 8 man hour. 但是你们如果pair了2小时完工， 需要4 man hour. task1从原来的4 小时 （4 man hour）缩减到 1 pair小时 （2 man hour）. 也就是说pair可以从某种角度提高工作效率by 75% 我个人觉得不大可能，人的因素肯定占很大比例。 我们公司还有个有趣的现象就是有一个iteration我们发现我们的velocity突然提高，最后究其原因 那周我们没怎么pair... 其实我想在我公司提倡的恰恰和你相反，早上大家来了先pair一个小时，然后该干么干什么去， 如果意犹未尽，可以继续，但是下午最好不要再pair了。 引用 来简单说下我的pair，现在可以说是一个老手一个新手在结对，新手完全可以自己干好所有的事情，他知道需求，老手对需求知道的要少些。
我们每天早上可以拿出时间两个人去读新闻，然后看资料，做点自己喜欢的事情，大概一个小时左右之后我们开始pair，我们并不担心看新闻聊天所浪费的时间，因为我们可以用两个小时的时间去做4个小时所做的事情。 （这并不是说pair可以直接提高编程效率。） 中午休息之后也是一样地。一个小时可以喜欢做什么就做什么 效率提高不仅仅是你眼前开发上的，代码质量（因为结对某种意义上来说就是即时的review），新人培训成本，未来的维护和交接成本也是要一起考虑的。 |
| 返回顶楼 | |
|
发表时间：2008-07-02
emarket 写道 另外有时候两个绝顶高手pair也会有问题,首先从benefit来讲，不大，TDD, refactoring, DI, Pattern已经能够如火纯清，用不着另外一个人看着，多性能处理器似的大脑，已经能够递归到第N层。反而意见的分歧往往会抹杀创造的火花，而提出折中的方案。 这只能说明其中一个真正的懂沟通的人也没有，高手也是要学习沟通技巧的。 首先在结对模式下，主要负责编的高手可以不需要反复对自己的构想进行复查，因为有另一个人帮你看着，没有后顾之忧，效率是极高的，不知道搂主有没有体会。 同时帮你看着的那个高手，不能因为意见的分歧而打断你，要么事先和你讨论好，要么暂时妥协先跟着你的思路走，然后等你告一段落后再重构。 方法是死的，人是活的。 |
| 返回顶楼 | |
