关于大锅饭的问题很多朋友有疑问，这里进行了一些说明，同时与结对编程进行了对比分析。
发信人: muser (负尽千重罪，练就不死心), 信区: SoftEng
标 题: Re: 交换编程方法介绍
发信站: 水木社区 (Thu Mar 24 14:07:10 2011), 站内
现在的思路好象把程序员超频至可以稳定的极限~~~
结对编程，一个人去拉粑，另外一个也许就得去尿尿。
最起码，一个人在找猎头打电话，就没办法向另外一个人交待。
两男人坐一起，你想上个网灌个水，没兴趣。很多码农是独语者。
两人的精神状态得同相。
每天8小时抖擞精神干下来...不读几次博士怕是培养不出这种素养。
交换...？工作业绩怎么衡量？搞不好成了吃大锅饭的了。
回答：
这里我先提一个问题：
大家平时做开发的时候，如果某个人就是在吃大锅饭，始终拖延进展或者技能不足，你怎么办？
难道你要等着所有的模块都开发完，然后等待这个模块的开发进展么？
这个时候，项目管理者或者负责人自然会对这个人提出疑问，要求他加快进度，或者不能承担就改做其他模块，这里就出现两个分支：
1、这个人改做其它模块开发仍然无法完成。
如此多了，我不相信领导会不考虑处理问题，比如辞退，扣除奖金等等惩罚措施。
2、改做其他模块完成了，原有模块谁来承接？承接者怎么办？
承接者的绩效如何衡量？难道不是一样的进行衡量计算么？——这里暂时不讨论目前的绩效管理模式的不合理的地方（如果非要合理的，参看我的可度量绩效管理模型中的一些建议，应该会有一些可操作的好一些的办法）。
既然有新的承接者，自然就会形成接近交换编程/开发中的绩效承接计算方式。
上面问题的另一个解决办法：领导安排人指导这个人进行该模块的开发，指导者的绩效如何计算？现有的绩效管理模式中也必须提供一些办法，哪怕是拍脑袋的方式进行的计算。
如此而来，交换编程/开发会形成大锅饭模式的疑问是不是解释清楚了？
其实，更多的人担心的应该还是结对开发中的大锅饭问题，因为两个人是同一个任务，无法衡量两个人在这个组合中各自的贡献问题才对，而不是交换编程的绩效问题。
不知道是否解释清楚这个问题，大家可以继续讨论。
【 在 loafer (狒狒) 的大作中提到: 】
: muser只是提醒我们应该尽量考虑“非理想环境”下如何去经营软件开发的管理，
: 不要理想化工作环境，或理想化参与开发的人员结构。
: 这本身是一种务实的态度，不对吧？
: ...................