这是《落叶》文集里第 79 片落叶，希望你能喜欢，不为别的，只为这份坚持。
再敏捷的流程，也得以人为本，由此可见敏捷团队有多重要，今天我们来聊聊在组建敏捷团队时最容易犯的“十宗罪”吧。
“十宗罪”之一：害怕改变
Change is always hard. 因为人人都害怕改变，特别是从一种非常成熟、稳定，并且已经习惯成自然的方法或流程，转而使用一种自己从未接触过的，或者说只是有一些了解的新方法，肯定会有一种惯性抵触。所以在团队组建初期，实施 Scrum 流程的时候，阻力肯定会很大，因为主动性不够，而导致效率和质量也会不高。
这时候，Scrum Master 不能一味地只是加强宣贯和培训，而是需要多从一些利益点出发，让团队成员看到如果按照 Scrum 的流程去做，会带来什么样的好处，会产生什么样的利益，这样他们才能更好地认识到新流程的优点，会更愿意接受它，会更主动地去按照流程标准做事情。
这就像我们在其他方面做出改变一样，只有当人们看到新的改变会给他带来巨大利益的时候，人们才会越积极主动地去改变。
“十宗罪”之二：不完整的职能结构
敏捷理论中的确有提及，在 Scrum 团队里，应该要淡化角色之分，不要区分什么开发或者测试，理想中的团队应该是每个人都能胜任不同岗位上的工作，简单来说，就是开发写完代码，也可以去测试，测试也可以去写代码。所以很多团队在组建时，就开始参照这个说法，认为只要人数达到了 Scrum 的标准即可，在资源不足的情况下，就会模糊角色职能，我就见过一个全是开发组成的 Scrum Team，PO、SM、Dev和QA 都是开发人员组成的。
他们忽略了一个前提，就是理想的 Scrum Team 可以这么做，或者说这只是 Scrum Team 的一个理想目标，先不说最终能否实现吧，但至少我认为，在初期，没有可能做到这一点。
在 Scrum Team 组建的初期，还是应该各司其职，每个岗位都有对应的人员担当，当团队磨合的相对成熟之后，再开始在某个 Sprint 里开始尝试交叉角色去承接任务，或者类似角色轮岗的形式，而且这也应该是在某个或某些 User Story 里去小范围的实践，这个周期理论上不会短，因为这已经不是简简单单地模块交叉开发或交叉测试那么简单了，这是岗位交叉了，对团队里每个成员的综合能力要求非常高。
而且个人认为，现在很多公司的研发团队，因为在初期招聘时，因为不同时期有不同的需求，开发和测试人员其实并没有达到理想敏捷团队里所要求的那样，可以既做开发，又做测试。而且，大多数公司对于人员的诉求，其实还是偏专一型的，另外，从人力成本上来说，也不太可能有公司能同时供养很多全栈型的工程师。
所以，我其实还是倾向于，在一个 Scrum Team 里，角色不能模糊，岗位不能缺失，架构层面或管理层面的人力资源不能交叉使用，但可以多团队共享，执行层面的人力资源可以交叉使用，但最好不要多团队共享。
作者简介：14 年测试经验 + 11 年项目管理经验 + 11 年团队管理 = 一个测试老兵
