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

posted @ 2017-03-11 21:05 ffl 阅读(...) 评论(...) 编辑 收藏