从去年开始，公司的人员流动比之前频繁许多。35人的开发团队,1年内有8到9个人员变更。这到底是不是正常，我并不知道，不过到很想谈谈关于离职的问题。如何管理项目中人员离职？
当有大量同事开始离职，或是在考虑的时候，可能首先要做的第一件事情是想想：到底发生了什么事情？为什么大家开始离职，出现了什么问题？你自己是不是也有同样的困境？你是不是也应该选择新的机会？
人员的频繁流动对于IT公司来说，是共同面临的难题，我想原因一般不外：
1. 薪水和预期不符
生活是需要成本的。不仅如此，薪水的多少也和公司对个人的认同有很大关系。当然不同的公司因为效益不同，同样的职位,薪酬也可能是天差地别的。当小小的鱼缸装不小长大的鱼儿的时候，自然会被转移到大的鱼缸里。无论如何，当其他条件都相同的时候，大家都是期望能拿到更多的钱的。
2. 糟糕的行政管理制度
不论在什么公司，都可能碰到让你抓狂的行政管理制度 ... 这个时候，可能最好的选择只有走。当然除了纯行政的，项目的管理也可能有同样的问题。
3. 没有成就感的工作
虽然工作是主体，却不是影响人离职的最重要的原因。每天在公司呆8个小时，有时比在家的时间还多，如果是没有意思的工作，真的是一种折磨。
4. 没有前途没有目标
很少有人能只活在当下。如果没有发展的前途，每人能安心的工作。
5. 令人不快的工作环境
人也人打交道永远没有固定模式，我想每个地方都可能有和你“水火不容”的人存在，如果矛盾激化，自然呆着难受。也可能是公司办公环境太“简约”，让你如坐针毡。
其实什么原因都好，只有一点是统一的，那就是人总归是要离开的。只有很少“有大志”，“有远见”的公司，才能真正意识到如何珍惜人的价值！不过打工的伙计就考虑不了那么多了。既然避免不了，作为 Scrum master 还是想想怎么应对才是？
1. 做好文档
不论在什么时候，文档都是相当重要的。千万别认为Agile，是没有文档的，如果你那么做了，结果就是巨大的悲剧。
文档是必须的，但是文档做多少，就是敏捷考虑的东西了。如果大家靠口述就能传承所有的东西，那可能只需要记录一个目录就可以了。如果做不了，那么就看需要记录多少，记录得有多详细了。文档不仅可以把知识保留起来，而且记录文档的过程也是很好的机会对知识总结，能够写清楚的知识，往往才是真的理解了的东西。文档的缺点在于，它一旦被创建出来，就开始失效，如何有条理的定期整理是必要的，当然会暂用不少时间。另外让文档能随时被所有人访问到，是极其重要的，wiki是不错的工具。不过恰当的时候，打印的文档，意义也很重大。
2. 做好 Pair Programming
结队编程在由一个某方面知识更丰富的专家和新人组合的时候，就能起到知识传递的作用。就好像最古老艺人的口口相传一样，这是最有效的知识传递方式。当然前提是，必须做好“真正的”结队编程，而不只是拿表面现象当成真实，事实而非的结队编程会毁了一切，糟糕的结队编程就没有细致的文档来的有效了。
而且 Pair Programming也可以更广范围来理解，不要认为只能是Pair，也可以是 3个，4个，或正整组的人。目的是集中大家的智慧思考问题，分享知识，形式是可以根据具体情况，灵活多变的。
3. 不要关键先生
这只是一个检查的方式。如果发现工作中出现了某个关键先生，某些事情，必须要他来决定，操作 ....那么流程一定有需要改进的地方。如果这样的人离职，而没有其他人能接手他的工作，那么等待你的只能是悲剧。 我们不可能期待所有的人都成为全能先生，每个人都能替代其他人并不是好事情，这样的团队缺乏必要时的深度，虽然什么都能做，可能什么都做不了特别好。但是必要的协作小组，能够知识和技能在某几个人之间进行传递，把由于某个人离职的影响降到最低。
只考虑到避免某个人离职带来的影响，还是不足够的。如果整个团队都离职呢？还有什么能做吗？ 当然，好的文档能够让新的接手软对轻松一点。不过你要做得应该是尽量避免这种情况发生。
当有人离职是，或多或