注：在一次软件工程讨论课程进度设计的过程中，出现了这个关于 Alpha/Beta换人机制的讨论，这个机制在不同学校有不同的实施，本篇积累各方观点，持续跟踪。
Talk(1)
@Coach: [Something is important，We Can..]
① 第6、7 周的事情，可以一周做完，建议放在第4周来做， 原来第4周的单元测试往后推一周， 这样同学们不会连续三周都有写代码的工作，给一些同学一个喘息和赶上来的机会。
② 第8、9、10周的事情可以合成两周.
③ 最大的风险是， 连续五天的冲刺时间太少，同学们刚能同步写代码，就停止了。 别的学校都是10天。 至少要连续7天 （同学们可以用周末的时间，由他们自己定）。
④你觉得应该在alpha / beta 之间强迫每一组必须送走一个队员， 然后这个队员自己找下家么？有些学校的同学感情上受不了这个， 但是这个措施对于 “打酱油” 的同学是很好的警戒。
@Teacher: [Interesting, BUT..]
没考虑过，感觉有点残酷，不过确实能起到警戒的作用
@Coach: [Since...]
否则会出现 “劣币淘汰良币” 的情况： 一些差学生就是不干活， 导致团队其他人也不想干活，最后没有产品出来。 老师也不好给团队项目打分。
@Teacher: [First we try, then we trust..]
可以在刚组队完成时，宣布其规则，让他们有心理准备
@Coach: [And...]
① 每班都有助教， 我觉得这是可以解决的。
② 另外，还有情况是有优秀的同学， 作了一个项目后，想试一下别的项目， 所以她要换组。 这也要鼓励。 另一个理由是： 换组的同学， 就会看到别人写的代码， 在别人写的代码上做改进， 这是软件工程非常重要的环节。 她就会意识到代码规范和文档的重要。
@Observer: [Question?]
① 会不会引起同学之间矛盾。感觉应该去培养团队合作性。你目前团队就是 这个情况，团队负责人应该想如何解决这些问题。而不是重组团队，这样差的学生也不可能改进什么。
② 一门课学的好不好不能最终去衡量这个学生综合能力。我们允许差的学生存在一个团队中。我更觉得适合在团队中找一个合适负责人，目前你团队有差的学生，团队负责人要去想怎么解决这个问题，让你的团队更优秀才对。这样可以培养团队合作精神更好。
@Coach: [In fact, It is...]
① 引入这个机制的一个原因就是同学间的矛盾。 因为大多数同学当初组队的时候都没有细想，就在一起了， 结果发现后来脾气、技术都有矛盾。 要有一个释放的渠道。否则被迫在一起没有意思。
② 在我们的经历中， 一些是脾气、技术方面的矛盾，导致一个人要主动离开。
③ 并不是说谁最菜，谁就走。 走的人，大多数是投入太少。
④ 你说允许差生存在一个团队中， 但是如果这个差生就是甘于做“最差” 不想干活，怎么办？ 把他送到其他小组， 他能够有再次学习的机会。 就像我们上课也给一些同学挂科， 这是治病救人的态度。 如果所有的课程都禁止挂科， 但是校领导要求老师 “想办法去解决问题” ， 老师能怎么解决呢？ 优胜劣汰，是自然规律， 早一天让同学有切身体会， 早一天他们会醒悟。
@Manager: [Change Your Perspective... ]
① 学生入学后，也有因为和室友合不来而换寝室的，也有大家能够从始到终都相处好的，两种方式没有孰高孰低。
② 任何组织，都存在类似的情况，既可以流动以保持活力，也可以大家在内部互相做出让步来调整自己，这都要看团队内部的情况如何而定，不可一概而论。
③ 在企业里工作的人，和在高校的老师的感受往往有些不同。高校几乎是不流动的（静态思维或由此而生），而企业则是铁打的营盘流水的兵，所以视流动为常态，合则留，不合则去。因此，在企业工作的人，也会把矛盾和冲突看作常态，设想多种解决思路，而不是只有内部消化这一条路。所以，只不过是学生换个团队，老师们就会觉得这有点『残酷』，但真实的世界不就是这样的吗？
④ 学生的流动，是一种资源组合的优化。也是一种组织结构的优化。原先的团队不能取长补短，学生自发调整后，变得更能取长补短了，这就是组织结构得到了优化，等同于资源组合的优化。
@Engineer: [Think different?]
① 在这个环节设置上，我倾向于要改变认知，旧的认知好像是这样的：
● 换人是残酷和伤害感情的
● 只有一个队伍里做的最差的会被换掉
● 不换人更有团队凝聚力，换人好像团队就会乱掉
② 但是事实上是否一定是这样呢？
● 有的人想要换到别的更好的团队，希望得到更高水平的锻炼，但是不敢或者没有机会
● 有的人希望团队的效率更高，但是别人说他要考研，要干别的事情
● 看上去一团和气，但没有一定的约束，实际上也不能形成凝聚力
③ 可以改变一下我们对换人的认知，通过在心智上重新定义“Alpha／Beta换人”：
● 合理的换人机制，让人才在团队间得到自由流动的机会
● 换人的过程中，需要重新融入其他团队，接触其他团队的代码、文档，对工程产生需求
● 在合理换人中，结对编程、项目文档、解BUG、敏捷、共同远景、责任驱动的深度需求。
● 换人是自然的，是软件工程的一个合适的训练环节
@Engineer: [Build a program!]
例如，可以设计情景游戏，通过情景体验，看到换人机制是一种不错的选择（新队友，新环境，新协作）：
@Assistant: [The big problem of small change.]
感觉最大的问题出现在“决定谁离开”这个时候.
@Engineer: [Case]
学校里面比较不好模拟真实情况，真实情况下，绝大多是是自由选择离开。我第一份工作的时候，招了一个新人，但是他迟迟无法融入团队，和所有人都没办法说到一块，后面我们决定就解除和他的合作了。过了一年后，我自己因为个人发展原因，我自己离开了这个团队。第二份工作，在1年内团队里有好几个新人因为城市压力，选择离开。中间又有好几个临时到团队里落个脚，呆一段时间自己离开的。大部分是自由离开的，自由离开一般也是因为各种博弈选择。
@Assistant: [How about this?]
不是有个团队分么？分数按从大到小排名，统一决定某个名次的学生离开团队如何？这个名次每学期随机一次。这个是老师决定的，不会有团队不知道该让谁离开的问题。而且具有一定的随机性，学生们无法事先知道谁离开，也就无法提前做出准备.
@Engineer: [Build a new program?]
也就是说，如果决定不出来，那就写一个程序，随机换人？那就可以改为：
①如果团队自己可以决定换谁，那就他们自己换。
②否则，就交给“市场程序”，让“市场程序”，随机挑选。
③在面临“市场程序”的随机洗牌的时候，也许大部分团队希望自己掌握命运。
@Assistant: [Gamelization!]
小于等于6个的话，可以在班级的微信群里用微信的骰子来决定，公开公正，主动掌握命运比被动来得好，不过也需要一定的勇气。
@Coach: [Experience!]
有启发，实际上，团队里的小组换人大部分都是积极的，正面的。我们在课程中设计合适的环节，让学生在实践中体验到这个过程。
Talk(2)
@SoftwareTeacher:
Alpha/Beta之间换人是《构建之法》教学的一大特点， 请看这里的详细解释
http://www.cnblogs.com/xinz/archive/2011/05/16/2048044.html
@StudentA:
团队中如果存在文章中的“有人”，可以理解，不存在的话，强制又是为了什么
@SoftwareTeacher:
我们教学的过程中， 还出现过一个团队， 做完 alpha， 所有人都离开了， 因为团队没有任何凝聚力，做的项目也很差。
@StudentA:
这样的话 会不会出现 划水人员循环流动的这种结果
@SoftwareTeacher:
了解足球吧？ 最喜欢什么队？比如足球教练在训练的时候， 把所有队员分成几组打教学比赛， 然后又把他们拆开，重新组队比赛，收集各种数据， 决定谁的能力和状态好。 这个是很正常的训练内容吧。那么， 我们在软件工程课中， 也有类似的做法。
@StudentA:
我先谈谈自己的看法吧。首先，大家并不是第一天认识，已经一起学习了两年，彼此之间也都有点了解。能够组成一个队，首先便说明了自己对团队内部人员的认可，不然干脆就不要加入这个队。既然是自己认可的，我觉得应该要对自己的选择负责到底，哪怕是后来发现自己当初看走眼了，原来某某竟是文章中的“有人”。一个团队中的队员，并不仅仅只是队员，更多的是伙伴。如果团队中有人想要谋求更好的发展，作为伙伴，当然不会去阻止他。但是伙伴不应该把任何人推出一个团队。好像听说以后公司中的项目都会有人员流动，但是我们还只是学生，我们组队不存在任何利益关系。
@SoftwareTeacher:
写得不错。 但是这个课程就是有项目是分两个阶段的， 在两个阶段之间要有人员流动。 你可以要求： “在alpha 阶段对我们团队分常认可， 写高质量的代码+文档， 即使你走了之后， 新人能很快接收你的模块， 把最好质量的软件做出来” 。 我觉得这也很好啊。
@TeachingAssistant:
我之前在上软工课程的时候也有过这样的想法，但经历了阿尔法阶段后反而对换人有所认同。PM，也就是队伍里需要统筹大局的人，要以产品/项目的质量为保障。在这种前提下，如果有比较优秀的同学出走团队，可以视作跳槽；如果有表现平平的同学出走，他也可能是去了一个更适合他的队伍，做着更适合的项目呢。我之前曾作为PM与室友组队，在团队答辩时的感受就是：尽量别跟特别亲密的人组队。
@StudentB:
StudentA你的情况是在于团体各个成员都做得不错, 也没有一个成员想要离队的情况吧?
@SoftwareTeacher:
欢迎探讨，《构建之法》的书和教学方法就是在不断的质疑，探讨，改进中提高的。 这不是“经典”， 而是不断变化的方法论。
@StudentB:
这种情况下，不如这么想：我们一直知道代码规范、手册、文档的重要性，但如果对于自己的代码一直没有真正训练和考察成效的机会。让一名新鲜血液加入项目组，就可以通过这名新成员是否能迅速上手项目，来检验之前编码规范等工作的成效了。
@TeachingAssistant:
团队之间的合作需要是两个独立的子项目拼成一个共同的大项目，这一点上并不是每个团队都能受到锻炼的。如果你们愿意，也可以考虑2-3个团队一起做一个大项目，每个团队分别独立负责一个小项目。但最后团队答辩时依然以你们负责的小项目为评分依据。这样一来，你们换人可以在合作团队间互换，以模拟组里的流动工作。但我不推荐这样做，风险很大。尤其是涉及到团队之间的合作与对接，情况远比想象的复杂。
@StudentA:
你推荐我们应该也不会这样做。。
@StudentC:
如果出现整个团队配合很好，队员都不想离开的情况呢？
@StudentB:
如果真的遇到了这种情况说真的我也比较为难。不过呢，现实世界中肯定是流动才是常态，不流动才是不正常。老师能想出这个设定我觉得也是用心良苦，能让我们在学校就可以提早见识一下，拥抱常态。如果不是换掉哪一个人都很舍不得的情况下，我觉得提前在学校里有这个见识也是不错的。
@TeachingAssistant:
相信我，团队阿尔法阶段以后不会舍不得。
@StudentD:
个人看法：分组对抗中 球员的适应能力 与陌生团队的磨合 也是很重要的考量 也能够发掘球员本身的潜力 那么也适用于在软工中作为交换的学生 这是我的理解 但是也有这样一种情况：一种团队 所有的成员经过了系列的磨合 已经能够得到好的效果 并且都不愿意离队。认同邹老师和助教前辈们的说法 不过我的看法是 可以不强制要求 但是如果有人有要求 或者在进行团队人员的评估中发现不合适（不合适的标准也需要探讨 比如有的人积极性不高）则进行转换。
@StudentA:
臣附议，这大概就是我最后想要说明的情况，还没到最后阶段，就被你给说了。
@Yet Another SoftwareTeacher:
①不强制要求，最终大多数组都不会换人。也许我们有固定认知，也许我们有没尝试但不希望体会的。
②强制要求，体验一次，最终再来评价其得失利弊。 不会全部是利，也不会全部是弊。看到不一样的风景。实施了才能迭代改进。不试试，不知道什么样是真正最适合自己的。
③To improve is to change, to be perfect is to change often. 如同xx级实验班首次要求动态滚动时，你们也不同意的。两年过后，你们不都认同了吗？软工组队中期更换不是淘汰，有人高就 有人离开，换一个组，加一个新成员. 让老师当坏人。alpha阶段后，总有你或你觉得有人离开比较好.
@TeachingAssistant:
我理解大部分组不换人的根本原因还是脸面过不去。组长不好意思换人（因为不是强制的），队员不想走（因为不是强制的）。
@StudentA:
是的 在我刚才的说法中 如果选择一个成员离开 要有标准 比如 个人申请 视为跳槽 比如积极性不高 视为淘汰.
@TeachingAssistant:
①可能潜意识里觉得 离开==淘汰。实际上还有可能是平步青云或者另谋高就什么的.
②也有可能真的是淘汰。 在公司里工作，你就保证不会被开除吗