软工+C(2017第4期) Alpha/Beta换人

// 上一篇：超链接
// 下一篇：工具和结构化

---

注：在一次软件工程讨论课程进度设计的过程中，出现了这个关于 Alpha/Beta换人机制的讨论，这个机制在不同学校有不同的实施，本篇积累各方观点，持续跟踪。

@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!]
有启发，实际上，团队里的小组换人大部分都是积极的，正面的。我们在课程中设计合适的环节，让学生在实践中体验到这个过程。

TO BE CONTINUE...