关于强制转会的说明
Q：转会的流程是什么样子的？
转会的流程如下： a)一轮迭代后，组A的任何成员都可以选择跳槽到其他组，但要求其他组能够接受这名成员。 b)由于每组至少需要5人，因此，若组A有多名同学跳槽，导致组A缺少开发必需人数，则视为组A解散。
Q：一个团队里如果有多人要求转会怎么办（解散的流程是什么样子的）？
一个团队若有多人“跳槽”并影响项目开发，则视为团队“解散”，将根据“解散”的流程进行操作。 解散的操作如下： a)一轮迭代后，组A可申请解散，需提交申请书，并作解散后反思，随后组A成员安插在其余各组，组A原有项目中断。 b)若有多组申请解散，则对这些组进行组员重组，重组组将接手解散组的团队项目。 c)若有更好的方法，欢迎讨论。
Q：为什么会有人想要转会呢？
解释一下可能的情况：
- 我很牛逼，我把我们组的项目弄好了，并且剩下的成员能够继续开发，我看到另外一个组需要我这样的人才，于是我决定跳槽去帮助他们
- 我在这个团队待不下去了，不能发挥自身的价值，决定去其他组
- 我们这个团队技术上都过关，但是团队相处不融洽，于是决定解散
- 我们发现，我们这个项目对我们来说太难了，我们不能继续进行开发，于是决定解散
Q：我们为什么要进行这一环节？
- 这是《构建之法》教学的一大特点，请看这篇博客中“真实的项目”一段： http://www.cnblogs.com/xinz/archive/2011/05/16/2048044.html
在这门课中, 我鼓励学生做自己决定的项目,但是要求他们要做”真实的项目”。既然真实，就会有人员流动的问题，因为：
- 有人想去做更好的项目
- 有人离开公司（退课）
- 有人和团队中的人合不来
- 有人觉得自己应该得到更多报酬 （分数，钱，股票），不愿意在原来的团队干了
- 有人做得很差，团队觉得没有他更好...
这样才会有人员流动，才要让软件保持“可维护性”,否则项目没法活下去。所以，我们在团队项目的alpha阶段后，强制所有团队必须有一个人离开。这个人要自己找能接纳自己的团队（不是原团队）。
有不少同学做过了一个项目alpha版，觉得应该尝试别的项目，他就可以利用这个机制在一学期内做两种项目，有更多的体验和收获。
有的同学抱大腿，打酱油，不想出力，那么，团队就把他请出去，他自己再找别的团队证明自己的价值。 这不是挺好么？
- 从另一个角度：我们可以要求转会的这名同学，留下高质量的代码和文档，使得在他转会之后，新人能较快地接手他的模块并参与到新的团队中，把最好质量的软件做出来。
邹欣老师：在我们讲课的这几年中，有助教来来往往，走的也不少，但是整个《构建之法》的方法仍然在不断提高。如果我们一旦走人，所有的经验都丢失了，那在现实世界中能做好事情么？
福大助教畅畅：我们一直知道代码规范、手册、文档的重要性，但如果对于自己的代码一直没有真正训练和考察成效的机会。让一名新鲜血液加入项目组，就可以通过这名新成员是否能迅速上手项目，来检验之前编码规范等工作的成效了。
Q：一个团队中的队员不仅是队员，更多的是伙伴，伙伴为什么要把伙伴推出团队呢？
助教刘乾的回答：我之前在上软工课程的时候也有过这样的想法，但经历了alpha阶段后，反而对换人有所认同。PM，也就是队伍里需要统筹大局的人，要以产品/项目的质量为保障。在这种前提下，如果有比较优秀的同学出走团队，可以视作跳槽；如果有表现平平的同学出走，他也可能是去了一个更适合他的队伍，做着更适合的项目呢：D
Q：为什么要*强制 *指定同学转会呢？
福大教师张栋：不强制要求，最终大多数组都不会换人。
福大助教刘乾：大部分组不换人的根本原因可能还是脸面过不去。组长不好意思换人（因为不是强制的），队员不想走（因为不是强制的）
Q：我们团队可以没有人转会吗？
不可以。原则上是不允许的，如果有特殊情况，必须有充分的理由申请，由老师审批同意才行。
这个链接记录了关于“转会”的讨论，请看： http://www.cnblogs.com/math/p/sec004.html
