刚加入一个新的团队不久，适应环境，熟悉，了解每一个团队成员，学习业务，也经历从坚持到转变思维再到坚持的过程。这过程中有纠结,有欢笑,有痛苦.
这使我对如何组建一个团队，陷入了深深思考，以至于无法自拔。
我所经历过的团队模式基本上可以分为：管理型梯队模式，协作型敏捷模式，
管理型梯队模式的特点是团队成员的构成应该根据角色职责属性，选择不同能力，经验的人，从这个角度又可分为大跨度型，比如：可由7，8年以上经验的和2年左右经验的成员组成。小跨度模型，比如：可由2年，5年，8年甚至10年以上经验的成员组成。协作方式则应该依靠过程方法，管理手段维持团队的运作，更多的依靠个人角色职能，明确成员的职责范围，加强执行力。
协作型敏捷模式要求团队成员的能力，经验，思维模式趋同，依靠团队的共识和流畅沟通达成目标。
简单的说，梯队型模式主要依靠的过程方法+角色分工+执行力，敏捷模式依靠的是能力+高质量的沟通。
我目前的团队应该属于两者兼顾模式，团队的组成基本属于梯队模式，但管理模式和氛围又趋向于敏捷模式。这样就会产生一些问题，比如不同能力，经验的成员，经常会在沟通过程中遇到障碍，而这里小跨度模型又要比大跨度模型问题复杂很多，大跨度模型基本可以达到认同和肯定资深成员的经验价值，而小跨度模型成员经验相差不大，意识形态上会趋向于认同自己，尤其是对于程序员这个特殊的职业，而当发生分歧时，也不能靠经验价值胜出，对于同样的问题和概念基本都有自己的理解。这种情况下，成员的积极性越高，可能效率越低下，而产生这种情况并不是因为人的问题，因为任何情况下人的积极性高都是值得鼓励的。而是错在团队的管理，动作方向和方针上，这个时候作为团队领导应该重新思考团队的模式和结构存在哪些问题。不应该一味的强调沟通和尤其忌讳在业务观点上支撑任何一方。
在我看来，即使是有相同的工作经验（工龄），能力差别也会很大，然这是组建团初期就应该考虑和甄别的。这里假定为能力，经验基本相近的场景，即便是看过同一本书，也可能会产生不同的理解。然尔沟通过程中，资深人员可能会做无用功，自身的产出效力会变的低下，而经验，能力不足的成员可能就会阻碍整个项目的发展和质量。尤其居于领导岗位的人员，情况会更严重。有管理职能的角色不能证明自己的论点正确的时候，就不应该过重的描绘自己的意图，这样会给成员带来压力。因为业务能力可能并不是他的专长，这个时候要明确自己的角色职责。认同和肯定资深成员的业务能力，而不应该质疑，这样做会损坏资深成员在团队中的权威，降低其作用，从而在团队中产生臭味，以至于影响整个团队的效率。
总之在梯队型团队中过度的强调沟通的价值， 可能会对项目进度，团队协作的效率起到不利的效果。
记得《敏捷软件开发：原则、模式与实践》中有这样的一段描述：
一个优秀的团队成员未必就是一个一流的程序员，一个优秀的团队成员可能是一个平均水平程序员，但是却能够很好地和他人合作。合作，沟通以及交互能力要比单纯的编程能力更为重要，一个由平均水平程序员组成的团队，如果具有良好的沟通能力，将要比那些虽然拥有一批高水平程序员，但是成员之间去不能进行交流的团队更有可能获得成功。
这段话，一方面说平均水平，沟通质量高，另一方面说高水平，但沟通不好，并没有说不平均水平的时候沟通效率的问题。这其实不是任何人的问题，有问题的是管理模式，因为能力的差别会使他们的沟通不在一个频道上。当然对于只讲敏捷概念的书中，这种问题是不存在的， 因为在敏捷式团队建设的原则上已经提出了要求。当一个成员的知识水平和思维方向与团队明显不能融入的时候，说明他不适合这个团队，无论是领导者，还是普通成员。所以这样的探讨并没有价值，但事实情况并不是都会像理论上那么理想，所以对于一个团队的领导者，建立者的能力，知识结构，管理风格就提出了更高的要求。
究竟是梯队，还是敏捷，这要看具体的场景而定，然尔混用两个模型就会产生很多严重的问题，同时也失去了两种模型划分的意义，当然这种情况很有可能是因为领导者的能力所导致的。团队成员的构成到底是应该按照管理模型的需要去选择，还是应该根据人员的素质，能力去选择模型，这是一个很现实的问题。
