[软件工程]交换编程方法的深入讨论

下面是交换编程方法在smth上的讨论对话，其中有人提出了相当好的讨论观点。
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
1
发信人: qingrun (青润), 信区: SoftEng
标 题: 交换编程方法介绍
发信站: 水木社区 (Wed Aug 11 23:07:58 2010), 站内
图片没有单独做出来，需要看图片的可以看附件中的图片。2007年在中国软件质量年会上的关于交换编程的session的ppt在青润上传的资源中可以下载到。
交换编程的相关文章连接介绍：
[技术讨论]交换编程实践与延续：http://blog.csdn.net/qingrun/archive/2007/01/04/1473733.aspx
[技术讨论]结对编程与交换编程的对话：http://blog.csdn.net/qingrun/archive/2006/12/07/1433588.aspx
交换编程csdn官方blog发布了网络版本：http://blog.csdn.net/programmer_editor/archive/2006/12/07/1433092.aspx
[技术讨论]关于结对编程实践的一段对话：http://blog.csdn.net/qingrun/archive/2006/12/10/1437443.aspx
[团队管理]结对编程引出的话题——企业管理与程序员规划的对话（修改总结稿）：http://blog.csdn.net/qingrun/archive/2006/12/12/1440190.aspx
[技术讨论]关于交换编程实践的交换周期问题 ：http://blog.csdn.net/qingrun/archive/2006/12/20/1450091.aspx

※ 修改:•qingrun 于 Aug 13 09:48:35 2010 修改本文•[FROM: 119.6.72.3]
※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.6]
附件: 敏捷开发模型实践之交换编程.rar (3001KB)
此主题相关图片如下：各个阶段的交换编程方法.JPG (30KB)

[本篇全文] [回复文章] [本篇作者：timshaw] [回信给作者] [进入讨论区] [返回顶部]
2
发信人: timshaw (去SofeEng(软件工程)小侃吧), 信区: SoftEng
发信站: 水木社区 (Wed Aug 11 23:34:00 2010), 站内
看到0%吓坏了，-_-b
【 在 qingrun (青润) 的大作中提到: 】
: 图片没有单独做出来，需要看图片的可以看附件中的图片。附件是2007年在中国软件质量年会上的关于交换编程的session的ppt。
: 1 引言
: 在传统的开发过程中，往往是一个人从一个模块的需求调研开始，然后作分析、设计、编码、单元测试，接着才会交给第二个人（专职测试人员）进行其他测试项目。这样的开发过程会因为开发人员的变动而对项目的进展产生较大的影响，所以就有人提出项目中编码人员的重要性远比
: ...................

※ 来源:•水木社区 newsmth.net•[FROM: 183.37.152.*]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
3
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 00:02:11 2010), 站内
0%？什么地方？
【 在 timshaw (去SofeEng(软件工程)小侃吧) 的大作中提到: 】
: 看到0%吓坏了，-_-b

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.6]
[本篇全文] [回复文章] [本篇作者：piggestbaby] [回信给作者] [进入讨论区] [返回顶部]
4
发信人: piggestbaby (吃的胖胖的(~~**~~)), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 10:01:49 2010), 站内
同吓
【 在 timshaw (去SofeEng(软件工程)小侃吧) 的大作中提到: 】
: 看到0%吓坏了，-_-b

※ 来源:•水木社区 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回复文章] [本篇作者：piggestbaby] [回信给作者] [进入讨论区] [返回顶部]
5
发信人: piggestbaby (吃的胖胖的(~~**~~)), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 10:17:05 2010), 站内
我从几个方面来反对交换编程:
1. 项目的不同阶段， 需要的技术是不同的， 程序员切换技术需要很长的准备，来回交接工作其沟通量非常不小， 代码质量难以保证
2. 需要对项目整体每一部分和流程都非常清楚, 只有极其优秀的员工能适应这种切换,不符合软件工程大生产的螺丝钉思想， 也不能保有公司的技术和商业机密
3. 交换编程挫伤了程序员的隐私， 从根本上看, 它想让项目中的任何人都是可替代的，但是程序员本身都是希望自己在某个方面有深入丰富的经验， 并且凭之成为升值加薪的砝码，从根本利益上是与员工的个人利益相违背的， 执行时必然导致员工积极性不高，并且互相推诿
当然结对编程则有浪费人力资源之嫌， 同时很难对结对的两人能力进行评估，两人水平如果一个高一个低，则成了师傅带徒弟， 如果两个低， 还不如不结对， 如果两个都高， 那老板肯定不干了。
另 外我想说， 不要拿实验的数据来推断真实工作数据， 实验数据大家都没利益冲突， 玩了命想弄好一个项目，真实工作大家都是老油条，对自己没有利益的事一分心思也不想付出。软件工程重要的是人的因素， 如果一种管理方式如果不能保证促进员工的利益，那想的再好定的再完美， 没人愿意当包身工
【 在 qingrun (青润) 的大作中提到: 】
: 图片没有单独做出来，需要看图片的可以看附件中的图片。附件是2007年在中国软件质量年会上的关于交换编程的session的ppt。
: 1 引言
: 在传统的开发过程中，往往是一个人从一个模块的需求调研开始，然后作分析、设计、编码、单元测试，接着才会交给第二个人（专职测试人员）进行其他测试项目。这样的开发过程会因为开发人员的变动而对项目的进展产生较大的影响，所以就有人提出项目中编码人员的重要性远比
: ...................
※ 修改:•piggestbaby 于 Aug 12 10:28:24 2010 修改本文•[FROM: 119.253.176.*]
※ 来源:•水木社区 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回复文章] [本篇作者：kabbesy] [回信给作者] [进入讨论区] [返回顶部]
6
发信人: kabbesy (三冠王), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 10:35:56 2010), 站内
赞
完全同意
坚决不支持把软件工程走到数据化的极端
这个大幅度背离了以人为本的核心
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 发信站: 水木社区 (Thu Aug 12 10:17:05 2010), 站内
:
: 我从几个方面来反对交换编程:
: 1. 项目的不同阶段， 需要的技术是不同的， 程序员切换技术需要很长的准备，来回交接工作其沟通量非常不小， 代码质量难以保证
: 2. 需要对项目整体每一部分和流程都非常清楚, 只有极其优秀的员工能适应这种切换,不符合软件工程大生产的螺丝钉思想， 也不能保有公司的技术和商业机密
: 3. 交换编程挫伤了程序员的隐私， 从根本上看, 它想让项目中的任何人都是可替代的，但是程序员本身都是希望自己在某个方面有深入丰富的经验， 并且凭之成为升值加薪的砝码，从根本利益上是与员工的个人利益相违背的， 执行时必然导致员工积极性不高，并且互相推诿
:
: 当然结对编程则有浪费人力资源之嫌， 同时很难对结对的两人能力进行评估，两人水平如果一个高一个低，则成了师傅带徒弟， 如果两个低， 还不如不结对， 如果两个都高， 那老板肯定不干了。
:
: 另外我想说， 不要拿实验的数据来推断真实工作数据， 实验数据大家都没利益冲突， 玩了命想弄好一个项目，真实工作大家都是老油条，对自己没有利益的事一分心思也不想付出。软件工程重要的是人的因素， 如果一种管理方式如果不能保证促进员工的利益，那想的再好定的再完美， 没人愿意当包身工
:
: 【 在 qingrun (青润) 的大作中提到: 】
: : 图片没有单独做出来，需要看图片的可以看附件中的图片。附件是2007年在中国软件质量年会上的关于交换编程的session的ppt。
: : 1 引言
: : 在传统的开发过程中，往往是一个人从一个模块的需求调研开始，然后作分析、设计、编码、单元测试，接着才会交给第二个人（专职测试人员）进行其他测试项 目。这样的开发过程会因为开发人员的变动而对项目的进展产生较大的影响，所以就有人提出项目中编码人员的重要性远比
: : ...................
:
: ※ 修改:•piggestbaby 于 Aug 12 10:28:24 2010 修改本文•[FROM: 119.253.176.*]
: ※ 来源:•水木社区 newsmth.net•[FROM: 119.253.176.*]

※ 来源:•水木社区 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回复文章] [本篇作者：kabbesy] [回信给作者] [进入讨论区] [返回顶部]
7
发信人: kabbesy (三冠王), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 10:36:46 2010), 站内
不过师傅带徒弟是可以的
但是一定要保证好频度
不能走极端
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我从几个方面来反对交换编程:
: 1. 项目的不同阶段， 需要的技术是不同的， 程序员切换技术需要很长的准备，来回交接工作其沟通量非常不小， 代码质量难以保证
: 2. 需要对项目整体每一部分和流程都非常清楚, 只有极其优秀的员工能适应这种切换,不符合软件工程大生产的螺丝钉思想， 也不能保有公司的技术和商业机密
: ...................

※ 来源:•水木社区 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回复文章] [本篇作者：kabbesy] [回信给作者] [进入讨论区] [返回顶部]
8
发信人: kabbesy (三冠王), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 10:39:40 2010), 站内
交换编程只能适合高薪养廉，降低成本效费比，极端追求程序质量的场景
国内大部分企业是达不到的
我认为即使是google也不可能全盘使用
而thoughtworks这种咨询导向的it公司就更不足为据了
（它根本不是以软件生产率为目标，而是以各种新颖的软件理论为目标）
【 在 qingrun (青润) 的大作中提到: 】
: 图片没有单独做出来，需要看图片的可以看附件中的图片。附件是2007年在中国软件质量年会上的关于交换编程的session的ppt。
: 1 引言
: 在传统的开发过程中，往往是一个人从一个模块的需求调研开始，然后作分析、设计、编码、单元测试，接着才会交给第二个人（专职测试人员）进行其他测试项目。这样的开发过程会因为开发人员的变动而对项目的进展产生较大的影响，所以就有人提出项目中编码人员的重要性远比
: ...................

※ 修改:•kabbesy 于 Aug 12 10:40:28 2010 修改本文•[FROM: 124.205.138.*]
※ 来源:•水木社区 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回复文章] [本篇作者：timshaw] [回信给作者] [进入讨论区] [返回顶部]
9
发信人: timshaw (去SofeEng(软件工程)小侃吧), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 12:23:14 2010), 站内
原来thoughtworks是咨寻为主啊？我以前还没注意到。
【 在 kabbesy (三冠王) 的大作中提到: 】
: : 发信站: 水木社区 (Thu Aug 12 10:39:40 2010), 站内
:
: 交换编程只能适合高薪养廉，降低成本效费比，极端追求程序质量的场景
:
: 国内大部分企业是达不到的
: 我认为即使是google也不可能全盘使用
: 而thoughtworks这种咨询导向的it公司就更不足为据了
: （它根本不是以软件生产率为目标，而是以各种新颖的软件理论为目标）
:
: 【 在 qingrun (青润) 的大作中提到: 】
: : 图片没有单独做出来，需要看图片的可以看附件中的图片。附件是2007年在中国软件质量年会上的关于交换编程的session的ppt。
: : 1 引言
: : 在传统的开发过程中，往往是一个人从一个模块的需求调研开始，然后作分析、设计、编码、单元测试，接着才会交给第二个人（专职测试人员）进行其他测试项 目。这样的开发过程会因为开发人员的变动而对项目的进展产生较大的影响，所以就有人提出项目中编码人员的重要性远比
: : ...................
:
: ※ 修改:•kabbesy 于 Aug 12 10:40:28 2010 修改本文•[FROM: 124.205.138.*]
: ※ 来源:•水木社区 newsmth.net•[FROM: 124.205.138.*]

※ 来源:•水木社区 newsmth.net•[FROM: 183.37.126.*]
[本篇全文] [回复文章] [本篇作者：raynorli] [回信给作者] [进入讨论区] [返回顶部]
10
发信人: raynorli (Rey), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 14:02:08 2010), 站内
我想在电子产品设计，例如原理图，嵌入式开发，调试过程中使用结对开发
1个工作者，1个辅助者，随时切换
原因：
1，更好的质量，减少错误
2，遇到障碍时，可以防止单个人思维钻牛角尖，导致精疲力尽也无法解决
3，因为工作者的劳动强度更大，经常切换可以降低结对内（心理上）的疲劳感
4，辅助者可以随时构建文档，防止在设计完成后再补
5，关键技术掌握在2个人手里，人员流动影响小
6，可以以师徒关系构建结对，同时完成对新人员的培训

【 在 kabbesy (三冠王) 的大作中提到: 】
: 不过师傅带徒弟是可以的
: 但是一定要保证好频度
: 不能走极端
--
※ 来源:•水木社区 http://newsmth.net•[FROM: 114.249.209.*]
[本篇全文] [回复文章] [本篇作者：oldwatch] [回信给作者] [进入讨论区] [返回顶部]
11
发信人: oldwatch (一条叫java的鱼◎谷歌将死，高墙早立), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 15:13:36 2010), 站内
en，这年头以十八摸为代表
高档民工都走咨询路线
【 在 timshaw (去SofeEng(软件工程)小侃吧) 的大作中提到: 】
: 原来thoughtworks是咨寻为主啊？我以前还没注意到。

※ 来源:•水木社区 newsmth.net•[FROM: 116.228.66.*]
[本篇全文] [回复文章] [本篇作者：canper] [回信给作者] [进入讨论区] [返回顶部]
12
发信人: canper (洗衣粉), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 15:20:39 2010), 站内

什么时候我能走这路线就好了
【 在 oldwatch (一条叫java的鱼◎谷歌将死，高墙早立) 的大作中提到: 】
: en，这年头以十八摸为代表
: 高档民工都走咨询路线

※ 来源:•水木社区 newsmth.net•[FROM: 113.65.155.*]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
13
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 18:24:31 2010), 站内

【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我从几个方面来反对交换编程:
: 1. 项目的不同阶段， 需要的技术是不同的， 程序员切换技术需要很长的准备，来回交接工作其沟通量非常不小， 代码质量难以保证
中国的程序员哪个不是从头干到尾的？几乎每个人都必须或者被迫从头做到尾。所以，你这个理由是不充分的。
: 2. 需要对项目整体每一部分和流程都非常清楚, 只有极其优秀的员工能适应这种切换,不符合软件工程大生产的螺丝钉思想， 也不能保有公司的技术和商业机密
这个问题，貌似你根本没有看完全文呀。另外这个问题和1的问题是相同的。至于商业机密的问题，呵呵，不要太扩大化了，这不是交换编程这类开发方法要关注的内容。
: 3. 交换编程挫伤了程序员的隐私， 从根本上看, 它想让项目中的任何人都是可替代的，但是程序员本身都是希望自己在某个方面有深入丰富的经验， 并且凭之成为升值加薪的砝码，从根本利益上是与员工的个人利益相违背的， 执行时必然导致员工积极性不高，并且互相推诿
你错了，这里面没有隐私问题，如果一个人的代码根本不能拿给别人来做开发，他的代码质量根本就是无法保证的，您的这个问题和2中的安全和保密问题是直接对立冲突的，我有点不知道您到底是为程序员考虑还是不为程序员考虑了。
: 当然结对编程则有浪费人力资源之嫌， 同时很难对结对的两人能力进行评估，两人水平如果一个高一个低，则成了师傅带徒弟， 如果两个低， 还不如不结对， 如果两个都高， 那老板肯定不干了。
结对编程是很明显的浪费，即使是师傅带徒弟效果也不如我的交换编程更好更合适，授人以鱼不如授至于鱼，企业对员工的要求往往不是一个
: 另外我想说， 不要拿实验的数据来推断真实工作数据， 实验数据大家都没利益冲突，玩了命想弄好一个项目，真实工作大家都是老油条，对自己没有利益的事一分心思也不想付出。软件工程重要的是人的因素，如果一种 管理方式如果不能保证促进员工的利益，那想的再好定的再完美， 没人愿意当包身工
注意：我没有那实验数据来推断实际工作数据，这一点更证明您没有仔细看我的文字，您是带着抵触情绪来分析我的内容了。我文中很明确的说了，只有德国人的实验采用了有经验的开发人员，而其他的都不是如此！我的意思应该很明白了。
所以，我觉得您提出的这几个问题都不是问题，或者批判对象搞错了。

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
14
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 18:26:38 2010), 站内

【 在 kabbesy (三冠王) 的大作中提到: 】
: 交换编程只能适合高薪养廉，降低成本效费比，极端追求程序质量的场景
: 国内大部分企业是达不到的
: 我认为即使是google也不可能全盘使用
: 而thoughtworks这种咨询导向的it公司就更不足为据了
: （它根本不是以软件生产率为目标，而是以各种新颖的软件理论为目标）
您似乎把结对编程和我这个交换编程搞混了吧？
结对编程才是如此。

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
15
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Thu Aug 12 18:27:29 2010), 站内
所以后来提到的其实是交换开发方式，这个方式就可以在很多行业进行实用，可以很好的获得高质量和较高的效率。
【 在 raynorli (Rey) 的大作中提到: 】
: 我想在电子产品设计，例如原理图，嵌入式开发，调试过程中使用结对开发
: 1个工作者，1个辅助者，随时切换
: 原因：
: ...................

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回复文章] [本篇作者：zhangmike] [回信给作者] [进入讨论区] [返回顶部]
16
发信人: zhangmike (克强总~~~~~~~~~~~~~~理不是偶), 信区: SoftEng
发信站: 水木社区 (Fri Aug 13 09:41:17 2010), 站内
很难有一种新的方法就能适用所有的情况
结对编程、交换编程应当都有适用的地方。
结对编程近年来谈的比较多。也有一些组织报道了。
交换编程还是新说法。具体操作层面不知是否有实例？
从时间上来说。一般是多久交换一次？

【 在 qingrun (青润) 的大作中提到: 】
: 中国的程序员哪个不是从头干到尾的？几乎每个人都必须或者被迫从头做到尾。所以，你这个理由是不充分的。
: 这个问题，貌似你根本没有看完全文呀。另外这个问题和1的问题是相同的。至于商业机密的问题，呵呵，不要太扩大化了，这不是交换编程这类开发方法要关注的内容。
: 你错了，这里面没有隐私问题，如果一个人的代码根本不能拿给别人来做开发，他的代码质量根本就是无法保证的，您的这个问题和2中的安全和保密问题是直接对立冲突的，我有点不知道您到底是为程序员考虑还是不为程序员考虑了。
: ...................

※ 来源:•水木社区 newsmth.net•[FROM: 114.94.94.62]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
17
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Fri Aug 13 09:45:48 2010), 站内

【 在 zhangmike (克强总~~~~~~~~~~~~~~理不是偶) 的大作中提到: 】
: 很难有一种新的方法就能适用所有的情况
: 结对编程、交换编程应当都有适用的地方。
: 结对编程近年来谈的比较多。也有一些组织报道了。
: 交换编程还是新说法。具体操作层面不知是否有实例？
这是我06年正式提出的，文中有介绍02-03年间就用过，此前我用过结对编程。
: 从时间上来说。一般是多久交换一次？
关于如何交换，文中有张图，看附件，这里不好文字配图，所以，没有嵌入图片，图片上写的很清楚每个阶段该做什么操作，什么时候做交换。
交换的两种，亮亮交换和轮流交换，都在不同的阶段使用，各有各的用处和好处。

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.3]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
18
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Fri Aug 13 09:48:01 2010), 站内
上一张图。
【 在 zhangmike (克强总~~~~~~~~~~~~~~理不是偶) 的大作中提到: 】
: 很难有一种新的方法就能适用所有的情况
: 结对编程、交换编程应当都有适用的地方。
: 结对编程近年来谈的比较多。也有一些组织报道了。
: ...................

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.3]

此主题相关图片如下：各个阶段的交换编程方法.JPG (30KB)

[本篇全文] [回复文章] [本篇作者：zhangmike] [回信给作者] [进入讨论区] [返回顶部]
19
发信人: zhangmike (克强总~~~~~~~~~~~~~~理不是偶), 信区: SoftEng
发信站: 水木社区 (Fri Aug 13 09:54:35 2010), 站内
thanks.
从图中看，是在一个类似瀑布型的生命周期下，需求、设计分阶段进行的。一般想来 诸
如需求阶段的时间在1~3个月左右，那么交换一次的时间就在15~30天左右？

【 在 qingrun (青润) 的大作中提到: 】
: 上一张图。

※ 来源:•水木社区 newsmth.net•[FROM: 114.94.94.62]
[本篇全文] [回复文章] [本篇作者：kabbesy] [回信给作者] [进入讨论区] [返回顶部]
20
发信人: kabbesy (三冠王), 信区: SoftEng
发信站: 水木社区 (Fri Aug 13 10:11:29 2010), 站内
以我的经验——这个流程复杂了，而且缺少具体执行细节，不是个可推行的方案
如果能简化成单线，最多一个分支，就好了
【 在 qingrun (青润) 的大作中提到: 】
: : 发信站: 水木社区 (Fri Aug 13 09:48:01 2010), 站内
:
: 上一张图。
: 【 在 zhangmike (克强总~~~~~~~~~~~~~~理不是偶) 的大作中提到: 】
: : 很难有一种新的方法就能适用所有的情况
: : 结对编程、交换编程应当都有适用的地方。
: : 结对编程近年来谈的比较多。也有一些组织报道了。
: : ...................

※ 来源:•水木社区 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
21
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Fri Aug 13 10:20:15 2010), 站内
这个图只是建议在某个模型下的交换方式，不代表一定，你可以用任何的开发过程模型来匹配交换开发方式都可以，需要注意的就是到了编码阶段和测试阶段一定选择两两交换，此前采用轮流交换，这样效果会比较好。
当然一切可以根据人员情况团队情况调整。
【 在 zhangmike (克强总~~~~~~~~~~~~~~理不是偶) 的大作中提到: 】
: thanks.
: 从图中看，是在一个类似瀑布型的生命周期下，需求、设计分阶段进行的。一般想来 诸
: 如需求阶段的时间在1~3个月左右，那么交换一次的时间就在15~30天左右？

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.3]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
22
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Fri Aug 13 10:22:57 2010), 站内
看来又被误会了，呵呵。
这个是我一般建议的全程建模方法论下的交换编程的实践方式，你用其他过程模型也可以采用，参考我前面那个帖子的内容。
不需要僵化的认定必需如何如何，关键是解决团队的稳定性和可持续性的问题，降低人员变动风险。
另 外，我不是为了企业开除员工考虑，希望大家不要再把我推出的这个方法论变成了企业管理方面的js考虑，那不是我的本意。很多东西和方法论的推出都不是为了 某个目的，也可能被某个目的所利用。但是，这里只能建议在正常的交接过程中，保持团队稳定和开发稳定的情况下的方式。呵呵。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 以我的经验——这个流程复杂了，而且缺少具体执行细节，不是个可推行的方案
: 如果能简化成单线，最多一个分支，就好了

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.3]
[本篇全文] [回复文章] [本篇作者：darkelf9] [回信给作者] [进入讨论区] [返回顶部]
23
发信人: darkelf9 (整理屋子), 信区: SoftEng
发信站: 水木社区 (Sat Aug 14 16:52:29 2010), 站内
全程建模/交换编程最大的缺陷是什么？
什么场景最适合？
什么样的技术含量项目最适合？
相对于其他方式的最大优点是什么？
感觉一种方法如果相对于其他方法真的有很大的优点
应该很容易推广才是
不至于推广了3年还没有一个很明显的成功案例

【 在 qingrun (青润) 的大作中提到: 】
看来又被误会了，呵呵。
这个是我一般建议的全程建模方法论下的交换编程的实践方式，你用其他过程模型也可以采用，参考我前面那个帖子的内容。
不需要僵化的认定必需如何如何，关键是解决团队的稳定性和可持续性的问题，降低人员变动风险。
另 外，我不是为了企业开除员工考虑，希望大家不要再把我推出的这个方法论变成了企业管理方面的js考虑，那不是我的本意。很多东西和方法论的推出都不是为了 某个目的，也可能被某个目的所利用。但是，这里只能建议在正常的交接过程中，保持团队稳定和开发稳定的情况下的方式。呵呵。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 以我的经验——这个流程复杂了，而且缺少具体执行细节，不是个可推行的方案
: 如果能简化成单线，最多一个分支，就好了

※ 来源:•水木社区 newsmth.net•[FROM: 114.243.229.*]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
24
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Sat Aug 14 17:33:41 2010), 站内
首先，多谢关心。
【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 全程建模/交换编程最大的缺陷是什么？
注：全程建模和交换编程没有直接关系，没有必要一起提。
交换编程自身没有大的缺陷，其不足之处在文中有足够的描述了。
: 什么场景最适合？
: 什么样的技术含量项目最适合？
: 相对于其他方式的最大优点是什么？
这几个问题，文中的表格已经说得很清楚了。
: 感觉一种方法如果相对于其他方法真的有很大的优点
: 应该很容易推广才是
: 不至于推广了3年还没有一个很明显的成功案例
这个问题，实话实说，就是我个人在推动，也没有做什么宣传和特殊的推动形势，我没什么名声，影响力也不大，所以，推不动也是正常的。呵呵。
关于是否有优点，直接看我文中的内容，和对比表格，这个表格丢失了表格框所以比较乱，去看程序员2006年的那一期可能会好些，也可以看附件中的图表。然后对比反思自己开发中经历的东西，应该很容易对比理解出来。
至少国内有一些朋友的公司在使用这个开发方法了。

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.119.10]
[本篇全文] [回复文章] [本篇作者：darkelf9] [回信给作者] [进入讨论区] [返回顶部]
25
发信人: darkelf9 (整理屋子), 信区: SoftEng
发信站: 水木社区 (Sun Aug 15 21:20:09 2010), 站内
看了一下表格，从我的开发经验角度出发，对我所处的情况意义不大
文档中介绍的交换编程的核心优点是
1.减少离职风险
2.团队稳定性
3.增加交流
逐个来看
离职风险确实是每个团队都遇到的问题，但是离职的人也需要做分析，并不是所有人的
离职都会对团队造成很大影响。团队内普通人员离职在一般情况下不会造成什么大的影
响，找个人来接手就是了。至于说因为一个普通人员离职造成某一个模块需要重新设计
，那唯一说明的是团队技术负责人不称职，首先要找一个好的技术负责人，而不是去试
验各种管理方法。
真正有影响的我感觉有两类人
a. 团队核心，例如技术负责人，或者有一定技术门槛，学习门槛的核心技术掌握者，或
者复杂业务逻辑掌握者
b. 长期维护某一个老系统的人
交换编程对这两类的意义都不大，对于类型a, 关键是要找对的人，有意识的做培养和b
ackup,同时给这些人足够的待遇，沟通，重点放在留人上面。对于b,比较不好办，老系
统往往用的技术比较古老，而类型b的人独一无二的是长期处理这些老系统的经验，这个
不是靠着简单的交换编程能够替代的。
交换编程对于那些普通开发者之间的“可替换性”效果感觉最好，可惜从实践上看，这
类人的离职影响是最小的
我个人觉得对于离职问题，最重要的是团队本身技术统一，保证所有人都有最基本的技
术共识，最基础的培训
其次就是保证关键人的稳定
关于团队稳定性问题，说句实话和开发方式关系很小，以我的经验，离职原因主要是待
遇，工作强度，是否受重视，领导能力，家庭影响（例如搬迁)，发展前途，公司前途等
等，我还没有见过一个主要因为开发方式离职的。
增加交流 确实有一些帮助，只不过，对于团队来说，采用scrum的每日会议或者是定期
的技术讨论也可以达到类似的效果
而且交流受团队氛围，工作强度，团队人员的构成很多因素影响，交换编程 的帮助有限

【 在 qingrun (青润) 的大作中提到: 】
: 首先，多谢关心。
: 注：全程建模和交换编程没有直接关系，没有必要一起提。
: 交换编程自身没有大的缺陷，其不足之处在文中有足够的描述了。
: ...................
--
※ 来源:•水木社区 newsmth.net•[FROM: 114.243.229.*]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
26
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Sun Aug 15 21:54:51 2010), 站内
多谢这样的评价和分析。这样的分析和争辩是有意义的。
【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 看了一下表格，从我的开发经验角度出发，对我所处的情况意义不大
: 文档中介绍的交换编程的核心优点是
: 1.减少离职风险
: 2.团队稳定性
: 3.增加交流
: 逐个来看
: 离职风险确实是每个团队都遇到的问题，但是离职的人也需要做分析，并不是所有人的
: 离职都会对团队造成很大影响。团队内普通人员离职在一般情况下不会造成什么大的影
: 响，找个人来接手就是了。至于说因为一个普通人员离职造成某一个模块需要重新设计
: ，那唯一说明的是团队技术负责人不称职，首先要找一个好的技术负责人，而不是去试
: 验各种管理方法。
这个情况您分析的不全面，有些系统设计是的确存在这样的问题的，后面你也提到因为待遇或者某些情况的原因辞职，即使辞职走人，可能矛盾只是集中在某一个人身上而不是所有人的身上。
至少对比起来，交换编程在这方面要比单人编程有效得多。
如果是单人编程的方法，可能这个人做的需求到设计到编码，无论哪个阶段出现问题都会带来风险，所以，你这个分析比较片面。
当然，一个方法的推出不可能适应所有的团队，但是同比能得到一些较好的效果就足够了，我没打算像结对编程那样被人吹嘘的如何如何，而实际上除了很少的公司以外没有哪个真得在应用。
: 真正有影响的我感觉有两类人
: a. 团队核心，例如技术负责人，或者有一定技术门槛，学习门槛的核心技术掌握者，或
: 者复杂业务逻辑掌握者
: b. 长期维护某一个老系统的人
: 交换编程对这两类的意义都不大，对于类型a, 关键是要找对的人，有意识的做培养和b
: ackup,同时给这些人足够的待遇，沟通，重点放在留人上面。对于b,比较不好办，老系
: 统往往用的技术比较古老，而类型b的人独一无二的是长期处理这些老系统的经验，这个
: 不是靠着简单的交换编程能够替代的。
: 交换编程对于那些普通开发者之间的“可替换性”效果感觉最好，可惜从实践上看，这
: 类人的离职影响是最小的
这个可真得不见得，每个人都是在成长中的，刚开始也许只是普通开发者，随着时间的延长和工作任务的不断安排，每个人的重要性都在不断提升，对于企业而言，为 什么会给一些老人较高的工资即使有可能他的能力还不如某个新人，也有这方面的一些原因存在。所以，您这个分析也比较片面，只是对于项目周期少于半年的可能 更符合您所说的这个情况，一般开发半年以上的人都会涉及到多个模块和多方面的关联关系，不是简简单单的可以替换或者离职影响最小就能解释的。
只要 离职就可能带来风险，这个人所开发的模块和过去开发的系统的维护和后续开发的风险，在国内目前企业道德不规范，员工道德也比较混乱的状态下，不可能不以最 坏的考虑来分析每一个人或者每一个公司，当然，具体的公司有具体的情况，有些人可能在某些公司觉得很舒服，但是，同样的环境同样的公司对于其他人来说就是 不舒服的，所以，一切都是可能存在冲突和风险发生的。
: 我个人觉得对于离职问题，最重要的是团队本身技术统一，保证所有人都有最基本的技
: 术共识，最基础的培训
: 其次就是保证关键人的稳定
培训真得不能保证人的稳定性。
: 关于团队稳定性问题，说句实话和开发方式关系很小，以我的经验，离职原因主要是待
: 遇，工作强度，是否受重视，领导能力，家庭影响（例如搬迁)，发展前途，公司前途等
: 等，我还没有见过一个主要因为开发方式离职的。
: 增加交流 确实有一些帮助，只不过，对于团队来说，采用scrum的每日会议或者是定期
: 的技术讨论也可以达到类似的效果
您提到了scrum，注意，我对比的是单人编程方式，另外，每日会议和定期交流并不一定能提高团队氛围，这个我在不同的项目中参与和实践过多次，有很多时候，这样的方式还会引起一些技术人员的反感。
: 而且交流受团队氛围，工作强度，团队人员的构成很多因素影响，交换编程 的帮助有限
另外，你所说的会议是另一个方法的内容，和交换编程应用的场景是不同的，所以，他们之间是相互补充，而不是相互冲突的，所以，你这个例子并不恰当，前面您也没有举出足够有力的证据说服我。

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.4]
[本篇全文] [回复文章] [本篇作者：darkelf9] [回信给作者] [进入讨论区] [返回顶部]
27
发信人: darkelf9 (整理屋子), 信区: SoftEng
发信站: 水木社区 (Mon Aug 16 23:01:09 2010), 站内
我感觉是不是我们的行业有一定差别？
我做过的行业包括互联网行业和游戏行业，没有接触过ERP行业
在我6、7年呆过的团队，见过的团队，带过的团队，见过两位数以上的人员离职
对于那种单个非核心员工离职，真的没有看到过非常大的影响
按照劳动法，员工离职要有1个月的交接时间，这个基本能保证一般员工所负责的工作交
接了
造成比较大影响的例子见过几个
例子1：
部门原来的技术老大自己写了一套底层，用这套底层搭建系统。后来这个老大离开了，
这个底层在使用中遇到了性能问题，没有人能够解决。最终是用一套开源系统代替了这
套底层。
这个案例用交换编程似乎没什么帮助，这套底层本身的技术含量很高（在当年环境下)，
实现相当的精巧，并不是随便一个人就能交换的。而后面几年中出现的性能问题，从以
后和这位老大的沟通看，是因为他当时没有想到这套系统会遇到那么大的规模，设计的
时候没有考虑。
最后用开源系统代替这个底层，原因也是因为这套底层落后了，有类似开源系统开
发人员的专注程度，社区的反馈、文档、熟悉的开发人员数目要远远强于自己公司一个
闭门造车的底层。如果技术方向出了问题，任何管理方法都没有意义。
例子2：
网游开发，接近内部测试，还有不少bug没有解决，还有新功能要开发，开发团队核心成
员全体跳巢。当时立马从其他部门紧急调了2个能力强一点的，然后大批招聘，很多人都
是刚毕业的或者只有1、2年工作经验的新手。虽然后续的开发、运维遇到了很多困难，
但是最终还是撑过去了。有一句老话说的好，地球离开谁都能转，人员的离职当然会造
成影响，但是也没有必要去夸大，特别是对于普通员工的离职

我回帖里面 保证基础的培训的 目标 本质是不是保证员工的稳定性，而是提高在员工离
职的时候其他同事接手的速度

【 在 qingrun (青润) 的大作中提到: 】
: 多谢这样的评价和分析。这样的分析和争辩是有意义的。
: 这个情况您分析的不全面，有些系统设计是的确存在这样的问题的，后面你也提到因为待遇或者某些情况的原因辞职，即使辞职走人，可能矛盾只是集中在某一个人身上而不是所有人的身上。
: 至少对比起来，交换编程在这方面要比单人编程有效得多。
: ...................
※ 来源:•水木社区 newsmth.net•[FROM: 114.243.229.*]
[本篇全文] [回复文章] [本篇作者：darkelf9] [回信给作者] [进入讨论区] [返回顶部]
28
发信人: darkelf9 (整理屋子), 信区: SoftEng
发信站: 水木社区 (Mon Aug 16 23:12:53 2010), 站内
另外，读了一下交换编程的实际操作，感觉实践中操作有一定难度
最直接的，这些人的绩效如何评估？如果某一个模块出了问题，是设计的问题还是实现
的问题？
从开发实践上看，我经历的团队不一定有超级高手，但是总会有层次性的人员梯队
某一个模块大框架的设计至少要和技术头或者小组长来沟通，
很多时候一个模块或者一个部分都是分给某个小组来做，具体实现可能不了解，但是大
体的设计小组内部都还比较清楚
很少存在某一个模块的设计完完全全一个人做，其他人一点都了解的情况
我感觉PPT里面举的例子事实上也有问题，没有区分核心模块的设计和普通模块/简单模
块的设计
对于普通模块/简单模块，即使完完全全都是一个人在弄，以后的切换成本也很低，交换
编程也许会带来好处，但是意义并不大
而对于核心模块，一般情况下要么是几个老程序员一起讨论，要么是技术老大出手，似
乎交换编程对这种模块的设计和维护也没有什么意义

【 在 qingrun (青润) 的大作中提到: 】
: 多谢这样的评价和分析。这样的分析和争辩是有意义的。
: 这个情况您分析的不全面，有些系统设计是的确存在这样的问题的，后面你也提到因为待遇或者某些情况的原因辞职，即使辞职走人，可能矛盾只是集中在某一个人身上而不是所有人的身上。
: 至少对比起来，交换编程在这方面要比单人编程有效得多。
: ...................
--
※ 来源:•水木社区 newsmth.net•[FROM: 114.243.229.*]
[本篇全文] [回复文章] [本篇作者：piggestbaby] [回信给作者] [进入讨论区] [返回顶部]
29
发信人: piggestbaby (吃的胖胖的(~~**~~)), 信区: SoftEng
发信站: 水木社区 (Mon Aug 16 23:39:00 2010), 站内
我的看法，好的软件工程方法应该符合以下原则:
1. 有效配合传统的管理方法， 而不是试图取代或改变原有流程
传统的管理方法有上千年的经验累积， 它的核心缺点软件工程基本不能避免, 也并非只有软件行业才会出现这些问题， 软件工程只能起到辅助的作用， 不能与传统管理基本原则相违背
2. 注重个人发展和权责分明，只有充分尊重员工， 给予员工长久发展的潜力，才能够吸引人才， 团队的发展就是个人的发展，要重视人的因素， 试图以牺牲个人利益来维护集体利益是不可取的。
3. 注重长远发展而不是短期突击, 而极限编程往往注重于短期的效率而忽视长远利益，如果长久突击必然导致人心惶惶，效率低下。我觉得这也是大型企业很少采用极限编程的原因。

【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 另外，读了一下交换编程的实际操作，感觉实践中操作有一定难度
: 最直接的，这些人的绩效如何评估？如果某一个模块出了问题，是设计的问题还是实现
: 的问题？
: ...................
--
※ 来源:•水木社区 newsmth.net•[FROM: 123.113.40.*]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
30
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Tue Aug 17 07:34:53 2010), 站内
这个问题比较独立，我先回答这个，今天中午的飞机，另一个话题就只能回到北京后再回复了。
关于绩效管理的问题，我08年出了一个可度量绩效模型，您可以去看看，我觉得，不仅针对新方法的绩效，对于原来的绩效评估也有比较好的效果，我那套方法虽然前期周期长，但是真正实施起来效果还是不错的，至少比目前那些常规的绩效方法对于软件开发来说更适合或者更务实一些。
某 个模块的问题，这个应该是比较容易评估出来的，因为每一步都有评审的配合，如果是设计的问题，只需要验证设计到代码是否没有被变更过设计框架即可，我建议 的UML模型从设计导出代码，如果是代码编写人员擅自变更了代码框架，出了问题就是编码人员的责任，如果不是这个原因，而且代码通过了单元测试，那么问题 就肯定是设计的问题。这个应该市不难确定的。
【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 另外，读了一下交换编程的实际操作，感觉实践中操作有一定难度
: 最直接的，这些人的绩效如何评估？如果某一个模块出了问题，是设计的问题还是实现
: 的问题？
: ...................

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
31
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Tue Aug 17 07:45:12 2010), 站内

【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我的看法，好的软件工程方法应该符合以下原则:
: 1. 有效配合传统的管理方法， 而不是试图取代或改变原有流程
: 传统的管理方法有上千年的经验累积， 它的核心缺点软件工程基本不能避免, 也
: 并非只有软件行业才会出现这些问题， 软件工程只能起到辅助的作用， 不能与传统管
: 理基本原则相违背
这一条我认为不一定。
传统管理方式上千年的积累，未必适合新的方法和新技术的发展，比如说，如果你按照汉朝军队的管理模式来管理宋朝，那明显是不合适的。同样，很多其他例子也是比较好找到的。
新技术必然带来新的革命性的进步，每一步都是需要流血需要付出一定代价的，只要这一步代价付出之后真得起到了进步的作用，那就是值得的。
如果没有一定的验证性结果，是可以坚持原有的管理办法，这个并没有错，毕竟人的意识和理解都是需要过程的，不是一个跨越式的，而大部分人应该是渐进式的。所以，在推动新方法的过程中，需要的是一种理解，相互的理解，相互的尊重，在这个基础上探讨讨论争论都是有意义的。
: 2. 注重个人发展和权责分明，只有充分尊重员工， 给予员工长久发展的潜力，才能
: 够吸引人才， 团队的发展就是个人的发展，要重视人的因素， 试图以牺牲个人利益
: 来维护集体利益是不可取的。
这个我完全同意。
现在的问题是大部分企业不尊重员工，不考虑长远发展，所以，很多时候是无奈的。
另外，交换编程的最大的目的是同一个模块可以有多人商议，这样可以避免一个人从头干到尾，结果思路陷入某个牛角中而无法出来的境地，这种情况并不鲜见。
: 3. 注重长远发展而不是短期突击, 而极限编程往往注重于短期的效率而忽视长远利
: 益，如果长久突击必然导致人心惶惶，效率低下。我觉得这也是大型企业很少采用极
: 限编程的原因。
极限编程其实不是短期效率的提升，比如结对编程的前三个月适应期就不短了，国内很多项目甚至就是一个月两个月的，甚至客户要求一两个星期的都有。
这 也是社会发展的必然，国内软件业承接了国外90年代初期的起步点开始了自己的发展，每一步发展都被国外企业的商业利益所推动，往往被他们利用。而国内的老 板和客户往往被国外几个快速发展的企业的经历所吸引，认为软件业也是一个快速暴富的行业，很少有企业能够静下心来一步一步推动，意识上产生的问题其实是十 分严重的，只是大家往往忽略了这一层的现象对我们项目进展和开发过程产生的影响。
我觉得，这个分支继续深入有点接近国家发展阶段甚至资本积累阶段的内容，就不适合这里讨论了。

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
32
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Tue Aug 17 08:46:52 2010), 站内

【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 我感觉是不是我们的行业有一定差别？
: 我做过的行业包括互联网行业和游戏行业，没有接触过ERP行业
: 在我6、7年呆过的团队，见过的团队，带过的团队，见过两位数以上的人员离职
: 对于那种单个非核心员工离职，真的没有看到过非常大的影响
应 该是有一些行业差异的，业务系统开发其中一点是对用户业务的理解，如果对用户业务不熟悉，哪怕你技术水平高，企业也很难接受你。这个和游戏开发是不同的， 游戏开发本身来说除了技术以外，没有太多的业务层的差异，游戏本身就是让大家玩得，基本上来做软件开发的人玩游戏应该都不是需要什么特殊学习的，应该说， 游戏的业务逻辑上的实现会比较为复杂的行业业务逻辑要简单一些。
: 按照劳动法，员工离职要有1个月的交接时间，这个基本能保证一般员工所负责的工
: 作交接了
而 且，如果是做游戏开发的，基本上术语相差不大。我02年在上海的时候的弟兄，后来有四个人进入了巨人，一个是技术总监，一个是技术副总，这两个哥们应该都 身价过亿了。他们也都是从行业软件开发过去的。至少我02年8月份离开上海的时候，其中三个都还在原来的公司，并没有离开。
: 造成比较大影响的例子见过几个
: 例子1：
: 部门原来的技术老大自己写了一套底层，用这套底层搭建系统。后来这个老大离开
: 了，这个底层在使用中遇到了性能问题，没有人能够解决。最终是用一套开源系统代
: 替了这套底层。
: 这个案例用交换编程似乎没什么帮助，这套底层本身的技术含量很高（在当年环境
: 下)，实现相当的精巧，并不是随便一个人就能交换的。而后面几年中出现的性能问
: 题，从以后和这位老大的沟通看，是因为他当时没有想到这套系统会遇到那么大的规
: 模，设计的时候没有考虑。
: 最后用开源系统代替这个底层，原因也是因为这套底层落后了，有类似开源系
: 统开发人员的专注程度，社区的反馈、文档、熟悉的开发人员数目要远远强于自己公
: 司一个闭门造车的底层。如果技术方向出了问题，任何管理方法都没有意义。
恩， 这样的情况在行业软件开发中也出现过，一般来说涉及到一些较大的行业是不允许使用开源软件的，但是，2004年我的确见过有著名的电信软件公司在给电信某 些省份公司的系统中使用了电信从未允许也从未验证过的mysql，tomcat等中间件和数据库，也就是招标的人根本不懂，所以，就被糊弄过去了，说实 话，这些系统的上线让我感到关系的强大和电信内部it技术人员和技术知识的匮乏。
: 例子2：
: 网游开发，接近内部测试，还有不少bug没有解决，还有新功能要开发，开发团队核
: 心成员全体跳巢。当时立马从其他部门紧急调了2个能力强一点的，然后大批招聘，
: 很多人都是刚毕业的或者只有1、2年工作经验的新手。虽然后续的开发、运维遇到了
: 很多困难，但是最终还是撑过去了。有一句老话说的好，地球离开谁都能转，人员的
: 离职当然会造成影响，但是也没有必要去夸大，特别是对于普通员工的离职
这 个情况行业软件中也遇到过，而且很常见。2003年我们开发的系统，一下子上线十多个省+集团公司，我们当时忍受只有13人，根本不够，大量的bug和需 求的变更以及新需求的提出，我记得当时的集团公司的需求变更/新需求提出/bug管理的文档达到了500多页，每页平均至少两个以上，也就是两个多月的时 间。如果不是非典给我们争取了3个多月的时间，5月份正式上线被推迟到了8月份，我们当时就死菜了。
: 我回帖里面 保证基础的培训的 目标 本质是不是保证员工的稳定性，而是提高在员
: 工离职的时候其他同事接手的速度
恩，理解了。
其实交换编程的方式也可以在一定程度上提高接手速度，因为你必须做到你开发的代码和文档都能让其他人看懂看明白，否则，评审和接手过程都会受到较大的影响。
至少在一定程度上比单人开发要好一些，当然，在接手的过程中必然会产生一定的时间延迟，不过，这样的延迟却可以提高内部对这个模块多方面的分析。
一个人如果要把自己的模块交给另一个人，一方面是要代码结构或者文档结构清晰，描述准确，另一方面接手的人的问题他也必须能够解答，这样的过程就能使得他不断反思前面是否做得有问题或者是否可能出现一些问题。这样的交流过程和方式肯定比单人开发要好得多，有效得多。

※ 来源:•水木社区 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回复文章] [本篇作者：piggestbaby] [回信给作者] [进入讨论区] [返回顶部]
33
发信人: piggestbaby (吃的胖胖的(~~**~~)), 信区: SoftEng
发信站: 水木社区 (Tue Aug 17 10:44:25 2010), 站内
我觉得你的理解可能与你的行业真的有很大关系
交换编程从理解上来看， 怎样的内容才是可交换的， 人和人是可替代的
要满足以下条件:
1. 工作技术含量不高， 技术类似
2. 工作业务逻辑简单
3. 工作为同一模块的两个小的子模块
4. 工作协同子模块之间有清晰的接口设计

采 取传统的分工方法, 是不是就不要求代码结构或者文档结构清晰了呢? 从设计的角度来说， 交换编程设计到如此详细的 API， 就很难达到。设计一般仅保证模块之间大的接口， 对内部细粒度设计详细的 API往往是画蛇添足，这些工作应该是实现者的责任， 实现者应根据需求自由调整内部结构。所以要求交换时有足够文档和清晰的结构， 既不符合极限编程， 也是无法满足的.

从工作 内容划分来看，交换编程两人的工作明显应该属于完整的一块，强要划分给两人完成，只能是工作量比较大 。交换编程带来的沟通难度和工作量， 可以类比为一个人要去修正另一个人的 bug( 其实我们经常交换，呵呵 ), 交换的一方是否有责任去检查另一方的代码实现题， 交接的一方接到代码后是去主动理解原有代码， 还是依葫芦画瓢狗尾续貂呢， 或者是对原有代码压根不满意自己另起炉灶呢， 交换时发生了问题怎么办, 最后集成出现了问题怎么办, 由于交换导致的项目拖延谁来负责任， 这可真是难题
交换编程和结对编程在本质上有所不同， 结对编程的两人始终处于同一环境下， 同一思路， 实际上沟通量很小，沟通主要是由于技术交流引起的，属于有效交流。 而交换编程， 沟通主要是工作切换引起的， 交流的目的很复杂， 有效性也值得怀疑

【 在 qingrun (青润) 的大作中提到: 】
: 应该是有一些行业差异的，业务系统开发其中一点是对用户业务的理解，如果对用户业务不熟悉，哪怕你技术水平高，企业也很难接受你。这个和游戏开发是不同的，游戏开发本身来说除了技术以外，没有太多的业务层的差异，游戏本身就是让大家玩得，基本上来做软件开发的人玩游
: 而且，如果是做游戏开发的，基本上术语相差不大。我02年在上海的时候的弟兄，后来有四个人进入了巨人，一个是技术总监，一个是技术副总，这两个哥们应该 都身价过亿了。他们也都是从行业软件开发过去的。至少我02年8月份离开上海的时候，其中三个都还在原来的公司，并没�
: 恩，这样的情况在行业软件开发中也出现过，一般来说涉及到一些较大的行业是不允许使用开源软件的，但是，2004年我的确见过有著名的电信软件公司在给电 信某些省份公司的系统中使用了电信从未允许也从未验证过的mysql，tomcat等中间件和数据库，也就是招标的人根本不懂，�
: ...................
※ 来源:•水木社区 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回复文章] [本篇作者：qingrun] [回信给作者] [进入讨论区] [返回顶部]
34
发信人: qingrun (青润), 信区: SoftEng
发信站: 水木社区 (Tue Aug 17 22:08:27 2010), 站内

【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我觉得你的理解可能与你的行业真的有很大关系
: 交换编程从理解上来看， 怎样的内容才是可交换的， 人和人是可替代的
: 要满足以下条件:
: 1. 工作技术含量不高， 技术类似
: 2. 工作业务逻辑简单
: 3. 工作为同一模块的两个小的子模块
: 4. 工作协同子模块之间有清晰的接口设计
您的这几条要求都是没有必要设定的，实际上不需要如此设定，我当年实践的项目业务逻辑是相当复杂的，而且是各个模块之间的开发进行交换，可能从工程设计模块到商务模块，也可能到财务模块，这些交换每一个都不是简单的业务逻辑实现，每一个模块下面都可以划分出很多子模块。。
: 采取传统的分工方法, 是不是就不要求代码结构或者文档结构清晰了呢? 从设计的
: 角度来说， 交换编程设计到如此详细的 API，就很难达到。设计一般仅保证模块之
: 间大的接口， 对内部细粒度设计详细的 API往往是画蛇添足，这些工作应该是实现
: 者的责任，实现者应根据需求自由调整内部结构。所以要求交换时有足够文档和清晰
: 的结构， 既不符合极限编程， 也是无法满足的.
那您的设计是做到什么程度？类，模块？还是类内部的实现细节？
您有没有看过欧美和日本外包的设计？
: 从工作内容划分来看，交换编程两人的工作明显应该属于完整的一块，强要划分给
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这个完全没有必要如此假设，这个假设也是不存在的。上面刚回答过。
: 两人完成，只能是工作量比较大 。交换编程带来的沟通难度和工作量，可以类比为
: 一个人要去修正另一个人的 bug( 其实我们经常交换，呵呵 ), 交换的一方是否有
: 责任去检查另一方的代码实现题，交接的一方接到代码后是去主动理解原有代码，
: 还是依葫芦画瓢狗尾续貂呢， 或者是对原有代码压根不满意自己另起炉灶呢， 交
: 换时发生了问题怎么办, 最后集成出现了问题怎么办, 由于交换导致的项目拖延谁
: 来负责任， 这可真是难题
: 交换编程和结对编程在本质上有所不同， 结对编程的两人始终处于同一环境下，
: 同一思路， 实际上沟通量很小，沟通主要是由于技术交流引起的，属于有效交流。
: 而交换编程， 沟通主要是工作切换引起的， 交流的目的很复杂， 有效性也值得怀
: 疑
您这个也是假设性的，不妨实践一下在看看您这个评论是否合适。结对编程的沟通量并不小，而且也不是单一因为技术交流引起的，业务上也会引起交流，我实践的时候就是这样的感受。交换编程也是如此，为何交换编程的有效性就值得怀疑？
您的这段评论完全是猜测方式的评论，并没有有效性的评论内容，我不知道您是否实践过结对编程，因为交换编程您肯定没有实践过。

※ 修改:•qingrun 于 Aug 17 22:59:59 2010 修改本文•[FROM: 162.105.200.220]
※ 来源:•水木社区 http://newsmth.net•[FROM: 162.105.200.220]
[本篇全文] [回复文章] [本篇作者：piggestbaby] [回信给作者] [进入讨论区] [返回顶部]
35
发信人: piggestbaby (吃的胖胖的(~~**~~)), 信区: SoftEng
发信站: 水木社区 (Wed Aug 18 07:48:57 2010), 站内
我这恐怕是天天都在交换编程
因为项目很多，彼此之间相关，随时来一个任务都可能派发到随机的一人身上
正是这种经验引起我对这种方式的反感
老板的意思不仅仅是保证团队稳定性， 还有保证每个人都任务很充足
总之目的很复杂， 开发人员机械完成， 谁也不负责任
交换编程试图解决的问题，我想在传统的管理方式中， 人才梯队， 培训等等能很好的解决
试图用交换来解决这些问题， 有点吃力不讨好
也许交换不交换并不重要， 也许交换的速度快了， 仅仅是两个人配合比较流畅
也许心情高兴了， 自然速度就会加快
我想并不用把交换编程和结对编程想像的如此神秘
我们每天都在和别人配合进行工作， 两人同时讨论一个问题， 一起去解决或实现一个问题
这 种经验很普遍。 另外不要假定实现人员就不需要自己独立设计， 实现的难度也很难大也有自由发挥性， 如果能详细设计到你所说程度， 保留设计人员就足够了， 交换不交换都很稳定。 结对编程是两人同时完成任务，一起讨论设计，一起定下实现方案，一起实现， 两人是同一思路。 而交换编程是 自己设计， 自己定下实现方案， 自己实现一部分， 对方拿到代码， 对方观察设计， 对方思考是否