敏捷质疑: 结对编程, 代码集体所有权

Q: 结对编程、责任共享，完全是胡说，代码找不到作者，开发人员哪里会有责任心!

A: 这个疑问基于一个假设: 开发人员的责任心来自于问责制度, 开发人员只有在恐惧的驱使下才会细心去编码.

我不知道你的职位是什么, 你或许是某个大中型企业的中高层领导, 或许手下有不少的人, 但你不会得到手下的尊敬, 他们只有"畏".

或许在对死亡之类的恐惧面前, 人类会爆发出强大的力量, 对于医疗系统, 军事系统, 心存敬畏之心是对的. 但日常生活中, 人们在荣誉而不是恐惧的驱使下, 更能发挥自己的潜能

Pair都希望通过展示自己的知识得到彼此的尊敬, 都希望代码轮转到其他同行手中时得到对代码质量的赞赏.

是的, 即使代码不署名, 团队依然清楚谁的代码写的好, 因为结对和轮换, 因为版本控制系统.

但是, 你, 管理者, 不需要知道哪块代码是谁写的, 不需要知道引起重大损失的Bug是哪个开发者引入的. 所有的事情都是整个团队一起完成的.

事实上, 你真正想知道的, 是整体上谁优秀, 谁需要提高, 或者谁真的不适合. 有其它比代码署名更好更有效, 而且不会把整个团队笼罩在恐惧的阴影下的方法.

Q: 那是什么方法?

A: 这涉及到整个考评体系的转变. 举个例子, 团队应该作为一个整体被考评, 客户的反馈, 带来的利润, 造成的损失, 都应该只到团队这一级, 荣辱与共.

团队内部每个成员的考评, 应该由团队自己完成, 成员之间经历了轮换结对, 谁优秀, 谁需要提高, 谁不适合, 都会有共识, 伪装不了.

Q: 你是说同行互评? 别扯了, 我只要弄好人际关系, 随你怎么评. 况且尤其是中国人, 抹不开面子, 怎么好意思当面说人家坏话.

A: 这是另外一个观念的转变, 必须借助于团队文化达成共识: 同行互评, 是帮助你发现自己的不足, 帮助你提高, 不是指责或贬低你. 如果你真的不合适, 同行互评会更快的让你认识到这一点, 从而努力提高或尽快选择其它的道路.

至于面子问题, 依然需要团队文化, 在秉承"沟通, 反馈, 勇气", 心态开放的团队里, 当面反馈反而更易接受.

另一方面, 大家都心智成熟, 如果一个人令周围的人都不爽, 难道真的因为面子的问题忍受下去?

Q: 怎么结对编程, 责任共享扯出这么大的动静来? 还要颠覆公司的考核体系?

A: 是的, 结对编程是 XP 实践中最具争议的一个. 反对它的开发者不在少数, 但更大的阻力来自老板的本能反对.

我们不幸生活在口号的时代. 或许领导们习惯了喊口号, 而从不考虑让口号"落地", 从不关注口号的实施. "合作"是不是能把耳朵磨出老茧的口号? 有什么具体行动? 结对编程就是最具体的一种合作啊.

老板们对它的质疑更多的是效率上. 其实就像TDD增加了整体代码量但不是工作量一样, 结对编程并非像直觉的那样降低了效率, 而是失之东隅, 收之桑榆, 甚至鱼与熊掌兼得.

几个俗套但不亲身体验就无法体会的论断:

1. 不是总希望员工像驴一样干活不要偷懒吗? 为什么不让员工互相监督? 有人坐在旁边盯着你的屏幕, 你能上网,打游戏,和女朋友聊天? 天亮就干活,一直到天黑

2. 不是总担心员工跳槽带来损失吗? 为什么不趁他还在的时候就让团队把他所有的知识都吸收干净?

3. 不是总担心有人写烂代码吗? 不是一直觉得code review流于形式效果不理想吗? 还有比结对/轮换结对更彻底的code review形式吗?

4. 不是总想取长补短, 优势互补吗? 不是总想达到"臭皮匠顶诸葛亮"的效果吗?

5. 不是总担心新员工成长太慢吗?

6. 不是总希望团队气氛融洽, 互帮互助, 没人跳楼吗?

原文转自：http://www.ltesting.net