Q: 那互不相让怎么办?
A: 几种实践:
-
卷入更多的人讨论, 时间窗;
-
先选择其中一个人的意见做做看看;
-
不要选择夹生饭, 即妥协出来的方案通常集中了两种方案的缺点.
其实结对编程对开发者的冲击最大. 把你的工作重点从与机器打交道变成了与人打交道. 把你从虚拟的机器世界拉回到现实世界. 把程序员重新变回成"人", 练习人与人之间的交流.
工作上的争论, 对事不要对人.
Q: 强势的人主导怎么办?
A: 这个问题很快能够被整个团队发现. 团队需要和强势的人沟通, 提醒, 碰到问题不应该一味维护自己的方案. 但通常本性难改, 这时其他成员在发生此类问题的时候如果坚信自己的方案有可取之处, 要坚持不要放弃, 可以扩大讨论范围, 卷入更多的人讨论.
项目经理和初期的敏捷教练需要特别关注此类问题, 因为它有可能把结对变成假结对, 只是表面看是两个人.
Q: 难道一定要结对? 个人编码时代一样产生了无数优秀的软件, 而且更能体现作者的思想和个性.
A: "一定"这类词只应出现在几个基本定理中, 其它场合通常是错的, 而且总会给措辞追咬者提供把柄, 有时甚至你只是说某个东西好推荐使用, 他也能理解成你说的是"一定"要用某个东西
至少两个极端情形下, 结对并不强制:
-
复杂, 初期需要静心思考的问题, 可以分头行动, 各自有了理解或解决方案或时间窗到了再来讨论. 言语在思考的过程中也会帮忙, 但我们都知道对有些问题, 言语只会打扰思路.
-
一堆琐碎毫无技术含量的工作, 不得不手工完成, 只是考验耐心, 自然不妨分头行动, 效率肯定比结对要高
Q: 几对开发者同时讨论各自的问题, 太吵了!
A: 小点声.
Q: 又说Pair之间要交流, 要讨论以便周围的人听到后可以及时发现偏差以节省时间. 到底要小声还是要大声?
A: 安静的讨论
Q: 如果代码集体所有, 那某个模块出错，此时已经有超过5对开发者编辑过此模块代码，那么谁来改?
A: 团队来改. 如果要在某个模块上增加新功能, 此时已经有超过5对开发者编辑过此模块代码, 那么谁来添加?
Q: 我想修改某段代码, 想找原作者了解一下思路, 可根本不知道是谁.
A: svn praise/blame. 然而更应该发生的是:
文章来源于领测软件测试网 https://www.ltesting.net/
