Agile 101: Pair Programming & Simple Design
raimundox
要 了解pair为什么重要，就要了解pair的目的在何。当然了，大多数人都知道pair的重点在于知识传递，知识共享，持续走查，降低代码缺陷等等等等。 这些都是pair的优点，不过最重要的一点却常常被忽略——pair programing的最直接而又最根本的目的之一在于simple design。
上 图是著名的Ron Jefferies Model，可以看到XP最佳实践被划分成了一个一个的圆圈，而pair, TDD, refactor和simple design位于中心。这并不是说这四个实践就是xp的核心。jefferies model每一圈代表了xp实践过程中的不同关注点，最中心的是dev视角，其次是team视角，最外层是交付／管理视角。每圈上的最佳时间多少都有些紧 耦合，放开其他的不讲，我们专门说说dev圈，pair programing, tdd, refactor和simple design。
这 四个实践里只有simple design最虚也最重要。有一个问题已经被问过无数次了，"到底多simple的design才叫simple"。我对此也有一个近乎刻板的回答： team里所有人员都能够理解的design就是simple的。一旦立了标准，这四个实践的主从关系就一下子清晰起来——simple design是这四个实践的核心，其他三个实践都是它服务的。
首先做出一个设计，最简单的判断标准就是是否可测，一个不可测的设计基本上可以认为无法实现，于是TDD即是simple design的质量保证又是simple design的直觉验证。
refactor 是为了得到好的代码，那么什么是好的代码？simple design!!!这里有人不同意了，有人说只是要易于修改和扩展，可是扩展和修改也要别人看得懂才行啊...simple design是起码的要求嘛。实际上，XP中的refactor就是朝着simple design的方向重构过去的，也就是朝着所有人都能理解的代码refactor过去的。插一句题外话，为啥说好的架构的不是设计出来的呢？因为好的架构 至少应该是simple design的，而simple的概念有和人员相关...所以当你极尽能事show off你的pattern知识之后，得到复杂设计根本就不可能是好的架构。时刻紧记，架构是妥协啊...
最后，pair programming是simple design的实际检验！！！因为即便是最复杂的设计，只要是你自己想出来的，你都觉得它简单无比，里面充满了直白且显而易见的理由。可惜不幸的是，我们 要的简单，是对team里所有人的简单。如果你的pair不能理解你的设计，那么说明你的设计复杂了;如果你们两个人懂，但是swith pair的时候，换过来的人不懂，说明你的设计复杂了。pair programming(以及他那容易让人忽略的子实践switching pair)就是检验simple design的过程。pair programing + refactor就是时刻保证simple design防止过渡设计反攻倒算的过程。pair programming + refactor + tdd就是团结在以Deming同学built quality in的质量大旗下，坚定地与过渡设计做斗争的过程。据我观察，至少一半没有使用pair programming的团队中，simple design成了口号，而这一半中，至少又有一半最终放弃了xp放弃了敏捷（俺以前带过的团队就有这样的...默哀一下）。深刻的教训啊，我们来高呼一 下："pair programming是检验simple design的唯一标准！"。
最后说一下pair programming经济学，过多的假设我就不讲了。单说一点，有哪一位上班的8小时从来不上msn/yahoo/qq等im?有哪一位上班从来不上论 坛/不回贴/不发邮件?以我pair的经验来看，pair programming的过程中，两个人几乎不会用im，几乎不会逛论坛。你不好意思呀，毕竟不是你一个人的机器，毕竟是两个人的时间，毕竟你也不愿意给 同事一种懒散的印象吧？收回的这么浪费的时间，至少顶得过另外一个人的工作时间了吧？
冰云
唯一不同意的地方就是 "很多XP实施的失败都是由于没有采用pair
programming而造成的"
我认为最大的失败原因在于需求的分解和优先级排序，多数team这方面做的很不好。
最近面试了几个应聘BA的，问他们公司是怎么做的，他们几乎都说在需求分解和优
先级排序上没有任何的sense和practices。
raimundox wrote:
> pair programing是所有XP实践中争议最大的一个，但窃以为确实XP实施的关键关
> 键实践之一，甚至于，我认为很多XP实施的失败都是由于没有采用pair
> programming而造成的。
> 要了解pair为什么重要，就要了解pair的目的在何。当然了，大多数人都知道pair
> 的重点在于知识传递，知识共享，持续走查，降低代码缺陷等等等等。这些都是
> pair的优点，不过最重要的一点却常常被忽略——pair programing的最直接而又最
> 根本的目的之一在于simple design。
>
>
>
> 上图是著名的Ron Jefferies Model，可以看到XP最佳实践被划分成了一个一个的
> 圆圈，而pair, TDD, refactor和simple design位于中心。这并不是说这四个实践
> 就是xp的核心。jefferies model每一圈代表了xp实践过程中的不同关注点，最中
raimundox
这个句式你可以当虚拟语气来看....
li xiao
yans
一般来说在一个XP团队中没有也不需要一个full time PM的角色，有一个dev leader就足够了。
XP其实是一个面向programer的方法，PM思考问题的方式回合XP不一样。XP的这些可以理解是战术，保证programer能都正确的实现需求的武器； PM要考虑的则是战略，产品是不是正确的方向，resource是否足够在期限内完成开发，控制和解决各种风险等等。
至于XP, 能让团队中的programer使用合适他们，并能够让他们高兴的、高质量的完成开发的方法， PM是会毫不犹豫的支持。
大的项目失败，很少是因为战术问题，战略问题居多；如果是小项目小团队，战术也就是很重要的了。
-Yans
See you Wired:)
Jeff Xiong
第二，XP不是面向programmer的方法，而是面向价值的方法。我们做的每件事情不是为了让programmer高兴，而是因为它有最大的价值。
--
Jeff Xiong
Editor of InfoQ China: http://www.infoq.com/cn/
Contributor of CruiseControl.rb: http://cruisecontrolrb.thoughtworks.com/
冰云
要用于过程和风险管理，例如planning game总要有他参加吧。我们一般都是XP+
Scrum，在这样的过程里，PM是很有必要的。参见俺blog:
http://blog.nona.name/200703238.html
yans
1、让团队保持成长,保持良好士气
2. 交付高质量的产品
所以能让团队高兴也是一件很重要的事情. 开发人员是很喜欢xp的，比如pp,实践起来不但能搞提高代码的质量和效率，同时还能让coding变得比以前有趣。
xp的确能带来value, 但是如果你需要像一个更本不懂coding的人管理人员解释 为什么pp能带来vaule，那会是一件相当有挑战的事情:)
说到scrum，PM 或者高层管理人员,客户一般会比较喜欢scrum,他们能够很简单的就明白scrum能给他们带来value. 但是要programer也喜欢上scrum就有点困难,例如要让开发人员明白
daily scrum 是帮助他们了解大家都在做什么/什么人需要你得帮助或则你需要的人能不能帮助你，而不是每天都在催促进度,很难很难偷懒, 这对于scrum master有很高的要求.
所以pp要向其他人证明它的价值确实很有难度；pp也不是时候能够ＧＴＤ的关键.
Jeff Xiong
从前嘉陵江的纤夫拉纤的时候有监工在旁边抽鞭子，但这些监工实际上是纤夫共同出钱雇佣的，因为只有用这种方式确保每个人都全力工作，船才可能被拖到上游（客户得到价值，团队成功），大家才能收到钱（个人成功）。软件项目的管理者，又何尝不是被程序员雇佣来抽鞭子的？
yans
不同的人站在不同位置，有不同观点和需求，虽然大家共同的目标是一样的，但是却不能假设这些人就会理解和支持你。这种误解谁是存在，需要有人去做些什么来达成这种理解，PM就会在这里帮助团队获得必要的理解和资源。
我所说的，是实际中遇到的问题。客户／管理高层从来都不会是像程序员一样是ＸＰ的最随着，他们只相信value,而且希望是浅显易见得ｖａｌｕｅ．如果你遇到一个完全不懂xp的并且被刚被灌输了CMMX的经理，没有很好的沟通，就让程序员继续XP而不管高层管理人员的需求，很可能就会产生矛盾和潜在的内部风险。
PM角色可能在不同的团队有不同的定义，但是我觉得PM不应该是"管理者"，而是"服务员"。为团队创造最好的环境，让程序员专心做他们最善长的事情。那么至于XP or PP, 让团队自己选择最适合的，发挥团队最大的积极性和创造力，才PM对于是否如何XP是最正确的选择.
这话我觉得，有点低估程序员。程序员和PM（以及"高层管理人员"）一样，都是项目的一分子，追求项目的成功是大家的共同目标，只有I项目成功、团队成功才会有个人的成功。没有道理说只有管理者们才知道为客户创造价值的重要性，程序员就只知道追求自己高兴。
Xiaogang Cao
一直以来，我对项目经理的定位也是相当的矛盾。一方面，如果你程序写不好，或者不是技术大拿的话，在中国出现的普遍情况就是压不住人，程序员认为你连软件都不会写，怎么有资格来指挥我？包括前几天大家讨论的项目经理要不要写code就是这个情况。
另外一方面，和现在的很多项目的实际情况不太一样，很多程序员都是被项目经理的鞭子驱动的，对上级多有厌恶之情。如果最后矛盾爆发，大多以离职告终。这和老板或者经理对项目管理的漠视和对程序员的冷漠有关。他们认为：我付了钱，给你一个任务，你就要完成，其余免谈。不要顶撞，不要argue。
换句话说，程序员和老板对PM的理解都有问题。
我现在对PM的理解是：
鼓舞士气；
召开项目会议，保持项目的状态为所有人清晰理解；
指引开发的方向，和开发者、客户一起决定下一迭代的目标；
请大家补充.
Michael Chen
--
Michael Chen
--------------------------------
Blog: http://michael.nona.name
MSN: jzch...@hotmail.com
nemo
处理合作部门、客户的压力，协作需求，资源协调，保证项目组的程序员不要被不必要的压力所困扰。换句话说，PM的很大一部分工作是给程序员打杂，PM需要把对项目成功没有益处的板子或者压力挡在外面。
还有一点就是对于项目组内部的资源分配，保证所有人都在做他们最应该做的事情
foxgem
做好了，双赢；做差了，就是双输。
PM和程序员都是项目成员，只不过职责不同。个人认为不存在谁服从谁的问题，我想这也是现在大多数公司都在设立pm的同时还有
技术经理的原因。但是，为了方便和客户交互，一般是由pm负责。
yans
感觉的到很多开发人员都把PM当作敌人, 能有这样的讨论越多越好.
其实Project Manager是现在在中国缺少了解的角色,在很多情况下不论是老板还是程序员或则是其他的角色都不太理解.
其实PM是一个很有趣的角色, 工作方式和思考方式都和程序员非常的不同. 如果说到如何做一个好的PM, Xiaogao得blog里面提到了一点我很同意: PM最高境界,就是让自己成为一个"隐形"人, 团队没有PM再帮便抽鞭子就能高效的高质量的工作, 为客户和程序自己都带来最大的价值.
Project Manager, 也许被定义的太狭义了点, PM不应该只是关注与project的是否完成, 还应该包括让团队不断的成长, 成为一个"不需要PM的团队"; 做到了这一点PM才能算真正的成功.
可能很多需要鞭子的团队和PM对成功的定义只是完成project 而已.
还是说XP/PP, 之前我说过他是"面向程序员的方法", 我这样认为的一个很重要的原因是, XP的实践其实是能够帮助程序员快速成长的很有效的方法, 特别是对于junior 程序员. 一个团队如果能坚持的实践XP中的一些方法和工具完成几个项目, 我的经验是这些人中的不少人能够很快的(比没有这样做的快不少)成长为senior 程序员, 或则到其他的团队成为中坚力量而不管哪个团队
是否XP.
作为PM, 我对XP的最大的价值理解在这个地方.
Jeff Xiong
yans
温柔一刀
我觉得敏捷团队其实并不一定需要一个真正的PM
只需要有一个team leader角色就可以了
team leader的作用是召开会议，明确每天的开发任务以及项目的总体大概进程，保持团队成员清楚的知道项目目前的状态，保持团队沟通顺畅让团队
保持高昂的士气。还有个作用是敢于对项目的成败负责（当然团队每个成员都有责任）。
“和开发者、客户一起决定下一迭代的目标”，这个我觉得是BA的工作。
小的敏捷团队的team leader也可以由BA来做也是很合适的
On 3月29日, 上午9时54分, "Xiaogang Cao" <xiaog...@gmail.com> wrote:
> 昨天熊节的这个mail给我的冲击相当大，我一直在想监工的这个事情。
>
> 一直以来，我对项目经理的定位也是相当的矛盾。一方面，如果你程序写不好，或者不是技术大拿的话，在中国出现的普遍情况就是压不住人，程序员认为你连软件都不会写，怎么有资格来指挥我？包括前几天大家讨论的项目经理要不要写code就是这个情况。
>
> 另外一方面，和现在的很多项目的实际情况不太一样，很多程序员都是被项目经理的鞭子驱动的，对上级多有厌恶之情。如果最后矛盾爆发，大多以离职告终。这和老板或者经理对项目管理的漠视和对程序员的冷漠有关。他们认为：我付了钱，给你一个任务，你就要完成，其余免谈。不要顶撞，不要argue。
>
> 换句话说，程序员和老板对PM的理解都有问题。
>
> 我现在对PM的理解是：
>
> 鼓舞士气；
> 召开项目会议，保持项目的状态为所有人清晰理解；
> 指引开发的方向，和开发者、客户一起决定下一迭代的目标；
>
> 请大家补充.
>
>
>
> ----- Original Message -----
> From: "Jeff Xiong" <gigix1...@gmail.com>
> To: <agile...@googlegroups.com>
> Sent: Wednesday, March 28, 2007 4:29 PM
> Subject: [agilechina] Re: Agile 101: Pair Programming & Simple Design
>
> > 这话我觉得，有点低估程序员。程序员和PM（以及"高层管理人员"）一样，都是项目的一分子，追求项目的成功是大家的共同目标，只有项目成功、团队成功才会有个人的成功。没有道理说只有管理者们才知道为客户创造价值的重要性，程序员就只知道追求自己高兴。
>
> > 从前嘉陵江的纤夫拉纤的时候有监工在旁边抽鞭子，但这些监工实际上是纤夫共同出钱雇佣的，因为只有用这种方式确保每个人都全力工作，船才可能被拖到上游（客户得到价值，团队成功），大家才能收到钱（个人成功）。软件项目的管理者，又何尝不是被程序员雇佣来抽鞭子的？
>
> > On 3/28/07, yans <yan...@gmail.com> wrote:
> >> PM的职责有两个：
> >> 1、让团队保持成长,保持良好士气
> >> 2. 交付高质量的产品
>
> >> 所以能让团队高兴也是一件很重要的事情.
> >> 开发人员是很喜欢xp的，比如pp,实践起来不但能搞提高代码的质量和效率，同时还能让coding变得比以前有趣。
> >> xp的确能带来value, 但是如果你需要像一个更本不懂coding的人管理人员解释 为什么pp能带来vaule，那会是一件相当有挑战的事情:)
>
> >> 说到scrum，PM
> >> 或者高层管理人员,客户一般会比较喜欢scrum,他们能够很简单的就明白scrum能给他们带来value.
> >> 但是要programer也喜欢上scrum就有点困难,例如要让开发人员明白
> >> daily scrum
> >> 是帮助他们了解大家都在做什么/什么人需要你得帮助或则你需要的人能不能帮助你，而不是每天都在催促进度,很难很难偷懒,
> >> 这对于scrum master有很高的要求.
>
> >> 所以pp要向其他人证明它的价值确实很有难度；pp也不是时候能够ＧＴＤ的关键.
>
> >> On 3/28/07, 冰云 <icecl...@gmail.com> wrote:
> >> > 纯粹的XP团队我没见过，不知道情况。不过估计yans说的dev lead也至少半数时间
>
> >> > 要用于过程和风险管理，例如planning game总要有他参加吧。我们一般都是XP+
> >> > Scrum，在这样的过程里，PM是很有必要的。参见俺blog:
> >> >http://blog.nona.name/200703238.html
>
> >> > Jeff Xiong wrote:
> >> > > 第一，XP团队也需要全职的PM，每个项目都需要。
>
> >> 第二，XP不是面向programmer的方法，而是面向价值的方法。我们做的每件事情不是为了让programmer高兴，而是因为它有最大的价值。
>
> >> > > On 3/28/07, yans <yan...@gmail.com> wrote:
> >> > >> I am a PM:)
>
> >> > >> 一般来说在一个XP团队中没有也不需要一个full time PM的角色，有一个dev
> >> > >> leader就足够了。
>
> >> XP其实是一个面向programer的方法，PM思考问题的方式回合XP不一样。XP的这些可以理解是战术，保证programer能都正确的实现需求的武器；
>
> >> PM要考虑的则是战略，产品是不是正确的方向，resource是否足够在期限内完成开发，控制和解决各种风险等等。
>
> >> > >> 至于XP, 能让团队中的programer使用合适他们，并能够让他们高兴的、高质量的完成开发的方法，
> >> > >> PM是会毫不犹豫的支持。
>
> >> > >> 大的项目失败，很少是因为战术问题，战略问题居多；如果是小项目小团队，战术也就是很重要的了。
>
> >> > >> On 3/28/07, li xiao < swing1...@gmail.com> wrote:
> >> > >>> 如果有人做PM，会跳出来从另一个角度提看法吧。呵呵
>
> >> > >>> 在07-3-27， raimundox <x...@bjug.org > 写道：
>
> >> > >>>> "甚至于，我认为很多XP实施的失败都是由于没有采用pair programming而造成的"
>
> >> > >>>> 这个句式你可以当虚拟语气来看....
>
> ...
>
> 阅读更多 »- 隐藏被引用文字 -
>
> - 显示引用的文字 -
冰云
视情况而定，没那么绝对的事情
li xiao
jessi...@gmail.com
pair的时候，换过来的人不懂，说明你的设计复杂了。"
仔细想想，终于明白为什么总需要自己要一遍一遍为各位同事重复讲那过去的故事了。。。
一个客户端框架设计得那么复杂，别人都不懂，当然只有一遍一遍讲，可最终效果还是很差。。。
Simple Design真不是件容易的事。必须说服领导，让他接受80/20原则，永远做当前最重要的20%的事情，不去想那么多要兼容的，要扩展
的。。。。。
jessi...@gmail.com
但现实问题，PM的权利往往不够（没有权利支配项目奖，没有权利选择合适的成员，没有权利为成员加薪），再加上成本问题，PM一般都还要承担核心技术责
任，BA责任，因此一半情况下还是要冲锋在前，无法变成真正的幕后导演。
但在管理角度：我非常同意，就是要做好所有成员的绿叶。
On 3月29日, 上午11时54分, yans <yan...@gmail.com> wrote:
> 能看到这多激烈的讨论真是开心:)
> 感觉的到很多开发人员都把PM当作敌人, 能有这样的讨论越多越好.
>
> 其实Project Manager是现在在中国缺少了解的角色,在很多情况下不论是老板还是程序员或则是其他的角色都不太理解.
>
> 其实PM是一个很有趣的角色, 工作方式和思考方式都和程序员非常的不同. 如果说到如何做一个好的PM, Xiaogao得blog里面提到了一点我很同意:
> PM最高境界,就是让自己成为一个"隐形"人, 团队没有PM再帮便抽鞭子就能高效的高质量的工作, 为客户和程序自己都带来最大的价值.
>
> Project Manager, 也许被定义的太狭义了点, PM不应该只是关注与project的是否完成, 还应该包括让团队不断的成长,
> 成为一个"不需要PM的团队"; 做到了这一点PM才能算真正的成功.
> 可能很多需要鞭子的团队和PM对成功的定义只是完成project 而已.
>
> 还是说XP/PP, 之前我说过他是"面向程序员的方法", 我这样认为的一个很重要的原因是, XP的实践其实是能够帮助程序员快速成长的很有效的方法,
> 特别是对于junior 程序员. 一个团队如果能坚持的实践XP中的一些方法和工具完成几个项目,
> 我的经验是这些人中的不少人能够很快的(比没有这样做的快不少)成长为senior 程序员, 或则到其他的团队成为中坚力量而不管哪个团队
> 是否XP.
>
> 作为PM, 我对XP的最大的价值理解在这个地方.
>
> On 3/29/07, foxgem <jianhgr...@hotmail.com> wrote:
>
>
>
> > 同意，所谓PM就是排除万难保证项目进度。要达到这一目标，有不同的做法。
> > 做好了，双赢；做差了，就是双输。
>
> > PM和程序员都是项目成员，只不过职责不同。个人认为不存在谁服从谁的问题，我想这也是现在大多数公司都在设立pm的同时还有
> > 技术经理的原因。但是，为了方便和客户交互，一般是由pm负责。
>
> > ----- Original Message -----
> > From: "nemo" <nemo...@gmail.com>
> > To: <agile...@googlegroups.com>
> > Sent: Thursday, March 29, 2007 10:45 AM
> > Subject: [agilechina] Re: Agile 101: Pair Programming & Simple Design
>
> > > 作为项目对外的"形象代言"，保证项目组对外的承诺是一个声音；
>
> > 处理合作部门、客户的压力，协作需求，资源协调，保证项目组的程序员不要被不必要的压力所困扰。换句话说，PM的很大一部分工作是给程序员打杂，PM需要把对项目成功没有益处的板子或者压力挡在外面。
> > > 还有一点就是对于项目组内部的资源分配，保证所有人都在做他们最应该做的事情
>
> > > On 3/29/07, Michael Chen <mechil...@gmail.com> wrote:
> > >> 俺的blog写了一点：http://michael.nona.name/archives/163
>
> > >> > >> On 3/28/07, 冰云 <icecl...@gmail.com> wrote:
> > >> > >> > 纯粹的XP团队我没见过，不知道情况。不过估计yans说的dev lead也至少半数时间
>
> > >> > >> > 要用于过程和风险管理，例如planning game总要有他参加吧。我们一般都是XP+
> > >> > >> > Scrum，在这样的过程里，PM是很有必要的。参见俺blog:
> > >> > >> >http://blog.nona.name/200703238.html
>
> > >> > >> > Jeff Xiong wrote:
> > >> > >> > > 第一，XP团队也需要全职的PM，每个项目都需要。
>
> > 第二，XP不是面向programmer的方法，而是面向价值的方法。我们做的每件事情不是为了让programmer高兴，而是因为它有最大的价值。
>
> > >> > >> > > On 3/28/07, yans <yan...@gmail.com> wrote:
> > >> > >> > >> I am a PM:)
>
> > >> > >> > >> 一般来说在一个XP团队中没有也不需要一个full time PM的角色，有一个dev
> > >> > >> > >> leader就足够了。
>
> > XP其实是一个面向programer的方法，PM思考问题的方式回合XP不一样。XP的这些可以理解是战术，保证programer能都正确的实现需求的武器；
>
> > >> > >> PM要考虑的则是战略，产品是不是正确的方向，resource是否足够在期限内完成开发，控制和解决各种风险等等。
>
> > >> > >> > >> 至于XP, 能让团队中的programer使用合适他们，并能够让他们高兴的、高质量的完成开发的方法，
> > >> > >> > >> PM是会毫不犹豫的支持。
>
> > >> > >> > >> 大的项目失败，很少是因为战术问题，战略问题居多；如果是小项目小团队，战术也就是很重要的了。
>
> > >> > >> > >> On 3/28/07, li xiao < swing1...@gmail.com> wrote:
> > >> > >> > >>> 如果有人做PM，会跳出来从另一个角度提看法吧。呵呵
>
> > >> > >> > >>> 在07-3-27， raimundox <x...@bjug.org > 写道：
>
> > >> > >> > >>>> "甚至于，我认为很多XP实施的失败都是由于没有采用pair programming而造成的"
>
> > >> > >> > >>>> 这个句式你可以当虚拟语气来看....
>
> > >> > >> > >>>> On 3/27/07, 冰云 < icecl...@gmail.com> wrote:
> > >> > >> > >>>>> 我觉得你说的大部分都很对，我支持
> > >> > >> > >>>>> 唯一不同意的地方就是 "很多XP实施的失败都是由于没有采用pair
> > >> > >> > >>>>> programming而造成的"
> > >> > >> > >>>>> 我认为最大的失败原因在于需求的分解和优先级排序，多数team这方面做的很不好。
> > >> > >> > >>>>> 最近面试了几个应聘BA的，问他们公司是怎么做的，他们几乎都说在需求分解和优
> > >> > >> > >>>>> 先级排序上没有任何的sense和practices。
>
> > >> > >> > >>>>> raimundox wrote:
> > >> > >> > >>>>>> pair programing是所有XP实践中争议最大的一个，但窃以为确实XP实施的关键关
> > >> > >> > >>>>>> 键实践之一，甚至于，我认为很多XP实施的失败都是由于没有采用pair
> > >> > >> > >>>>>> programming而造成的。
> > >> > >> > >>>>>> 要了解pair为什么重要，就要了解pair的目的在何。当然了，大多数人都知道pair
> > >> > >> > >>>>>> 的重点在于知识传递，知识共享，持续走查，降低代码缺陷等等等等。这些都是
> > >> > >> > >>>>>> pair的优点，不过最重要的一点却常常被忽略——pair programing的最直接而又最
>
> ...
>
> 阅读更多 »
