软工+C(4): Alpha/Beta换人

注：在一次软件工程讨论课程进度设计的过程中，出现了这个关于 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!]
例如，可以设计情景游戏，通过情景体验，看到换人机制是一种不错的选择（新队友，新环境，新协作）：

在限时游戏环节内，组织学生分组，一组3人，游戏的要求是在10分钟的竞赛游戏后，给2分钟每组必须有一个人到一个中间的“转会”平台，每组同时需要在这个转会平台招募一个新人，然后进入下一轮10分钟竞技。一共进行3轮，3轮后每个人都换过一组。

@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:
①可能潜意识里觉得离开==淘汰。实际上还有可能是平步青云或者另谋高就什么的.
②也有可能真的是淘汰。在公司里工作，你就保证不会被开除吗