随着时代的发展，越来越多的企业开始进行敏捷转型，在软件开发过程中采用敏捷的方式，期望可以提升效率，改善质量。敏捷也不再局限于互联网行业，很多传统行业——包括银行、保险、电信等等也逐渐开始认同敏捷的开发方式和流程，在企业内部的系统开发过程中把敏捷与原有的流程相互融合，以更好地适应高速、快节奏所带来的不确定性，从而达到更好地体现 IT 部门价值的目的。
对于管理者来说，在实施敏捷转型的过程中，非常重要的一个环节就是要打造高效协作的敏捷团队。我们经常会说，在当前的管理中，如果能够把人管理明白了，其他很多都可以水到渠成地做好。按照管理学大师彼得·德鲁克的观点，因为软件开发是知识工作，每个成员都是知识工作者，所以单纯凭借流程和工具是无法让事情良好运转的，只有管理者能够关注每个成员，发挥出每个人的主动性和积极性，在合适的时间、合适的岗位上完成合适的工作，才能够更好地保证敏捷转型的成功。
团队的特征
在组织中，我们一直强调团队的重要性？那么，团队有哪些特点呢？
在这里所说的团队（Team），并不是说组织架构上的团队，因为并非是一些人在一起工作，就可以是团队。很多时候，那样的组织形式是团伙（Group）而不是团队。
那么团队和团伙之间有什么区别呢？二者最本质的区别就在于：
• 团队拥有有共同的目标；
• 成员会通过相互之间的协作来达到这个目标。
在此首先要注意的是，团队的目标和团队成员的个人目标可能会不一致，所以这就需要对二者进行平衡，或者说要把个人的目标和团队的目标相结合，那样才能够让每个成员更好地为了团队的目标而努力。
然而，在有些时候，需要团队成员为了共同目标对个人目标做出一些牺牲。比方说：在其他成员需要帮助的时候，是否可以暂停自己手头的工作提供帮助？我会认为这是「舍得」的问题——有了「舍」才会有「得」，团队中的每个成员都一样，都需要在特定的时候为了共同的目标而做出自己的「舍」，但我相信，能量是守恒的，在团队中的付出和收获也一样，即便帮助了一个小伙伴，不能从对方那里「得」，也一定会从其他小伙伴那里「得」。如果团队成员都能够做到这一点，那么才能够称得上拥有共同的目标。
其次，如何进行良好的协作，是每个团队必须要解决的问题。协作的前提是，每个人都有其各自的特征，有其擅长的领域和不擅长的领域，管理者要做的就是要让合适的人做合适的工作。
根据贝尔宾团队角色理论，每个人在团队里面的行为特征会有以下九种，每一种都会有其优缺点：
• 鞭策者：目标感强，充满活力，有干劲；但容易起争端；
• 执行者：能够按部就班把工作完成；但缺乏灵活性；
• 完成者：关注细节，力求完美；但易于焦虑，不授权他人；
• 外交家：能够与外部联系并获取资源；但容易「三分钟热血」；
• 协调者：愿意分配工作，澄清目标，促进联合决策；但容易被人认为不干活；
• 凝聚者：团队的润滑剂，善于调节气氛；但在做决定时会犹豫不决；
• 智多星：富有想象力，创新力强；但可能不修边幅，不善沟通；
• 审议员：风险意识高，善于分析；但行动缓慢；
• 专业师：在专业领域努力追求知识；但可能听不进其他人的建议。
上面每种角色都是在团队里面不可或缺的，没有完美的个体，只有完美的团队。管理者要做的就是识别出每个人的行为特征，并与合适的岗位需要相匹配。比方说：项目经理更需要协调员和鞭策者的角色；专注于创新的产品经理需要是外交家和智多星的角色；需求分析人员需要是外交家和执行者的角色；开发人员需要执行者、完成者的角色；测试人员更需要是审议员和完成者等等。
除此之外，团队的组织架构要尽可能扁平，因为在不同的阶段，需要不同角色的团队成员来引领，这样，可能在团队中没有太多领导的头衔，但每个人在合适的时候都会具备相应的领导力，为团队做出必要的贡献。比方说：在计划阶段需要鞭策者和协调员来引领；在创意阶段需要智多星和外交家来引领；在执行阶段需要执行者和凝聚者引领；在收尾阶段需要完整者和专业师来引领。
想要做好敏捷转型，就需要打造出平衡而完整的团队，整个团队的每个成员都各司其职，而又相互协作，才能够实现团队的共同目标。
敏捷团队的特征
敏捷团队的特征用一句话来描述：主动、持续地学习和改进。
虽然是非常短的一句话，但我们会发现，这里面的四个词都有非常重要的意义。
1.主动
我们期望敏捷团队的每个成员都有非常高的主动性和积极性，最理想的状况是形成自组织、自管理的团队。
这仅仅靠外部激励是不可能达到的，因为外部激励就是有的时候，大家的绩效就会提升，没有了，绩效就会恢复原样，甚至于会有下降。而且，我们还会发现，有时候外部激励不仅不会带来绩效的提升，反而会带来绩效的下降。典型的外部激励就是薪资和奖金，我们很多人都会遇到这样的情况：拿到了奖金，但还是不满意，因为很多时候会有比较，从而涉及到是否公平的问题。
既然外部激励无法真正达到激发团队成员主动性和积极性的目的，我们就需要寄希望于内部激励。内部激励最大的特点就是：激励和工作是合二为一的，工作本身就是一种激励，那样的话就可以在工作的过程中获得非常大的收获和成就感。
对于每个人来说，内部激励都不一样，对此，管理3.0的理论中有很好的总结：
• 好奇（Curiosity）——有很多事情可以探索和思考；
• 荣誉（Honor）——因为工作体现了你的价值而感到自豪；
• 认可（Acceptance）——同事认可你所做的以及你本人；
• 能力（Mastery）——工作对你的能力有挑战但在可控范围之内；
• 权力（Power）——你有足够的空间来影响身边的人；
• 自由（Freedom）——你在工作和责任方面独立于其他人；
• 关系（Relatedness）——你与工作中其他人有良好的社会关系；
• 有序（Order）——你有足够的规则和策略来创建稳定的环境；
• 目的（Goal）——你生命的目的也体现在所做的工作中；
• 地位（Status）——你有很好的职位并被同事所认可。
作为管理者，重要的是要识别出每个团队成员的内驱力是什么，然后根据情况分配不同的工作，从而达到内部激励。
2.持续
曾经看到过这样的理论，在当前时代，对一个人来说，非常重要的除了智商、情商之外，还有坚毅的能力（或者叫做毅商）。对于团队也是同样，想要真正做好一件事情，一定需要一段时间的坚持，浅尝辄止，或者在遇到一点点失败就终止，就无法体会到敏捷转型能够给团队带来的真正的好处。
经常会有团队很开心地和我说，我们已经开始做敏捷了，这可能意味着他们开始尝试以下行动：
• 每天开始开站会了；
• 开始把开发过程拆成两周一次的迭代了；
• 开始竖起一块任务板来管理大家的进度了；
• 开始写一些自动化测试了；
• 开始做持续集成、每日构建了；
然而，过一段时间再问他们，还在持续做吗？经常得到的答案是：因为某某原因，已经停止了。有可能是有些小的成果，让团队感觉即便没有这些实践，同样也能够做到；有可能是有些小的失败，这样大家会抱怨，都是因为做「敏捷」才这样；还有可能就是因为大家的任务突然变得更紧张，所以就没有时间再去尝试新的东西了，因为本来也是抱着“试试看”的心态。
不管怎样，这样做过的团队都会觉得，自己已经经历过「敏捷」了，下次再有团队做敏捷转型的时候，就会以「过来人」的身份给出很多建议，甚至会说：「敏捷就那么回事儿，不会有什么作用，我们尝试之后就是那样」。然而，这样的情况只能说是做了一些敏捷实践而已，短短的时间里面很难领略到真正的敏捷是什么。
另外，正因为那些实践都是改变，都会让人跳出舒适圈，刚一开始的时候一定会有很多不适应的情况，这也正是无法坚持下来的原因所在。只有坚持一段时间，经过多次的重复练习，才能够慢慢适应，也才能够体会到这样的改变会给个体、给团队带来什么样的收益。
3.学习
对于团队成员来说，要不断地提升自己，这样才能够让团队也不断提升和进步。真正意义上的敏捷团队成员都非常善于学习，能够用最短的时间，花最少的精力，学习到最多的知识。因为只有掌握的知识足够多，才能够先纵深发展，再水平发展，逐步达到「T」型人才的标准，更好地适合当今时代的需要。
想要达到上述的效果，团队成员最先需要学习的就是「如何学习」，提升自己的学习能力。这是在学校的课程列表里面所没有的一个科目，所以需要自己有意识、有目的地进行学习。另外，每次学习就像是投资一样，要考虑 ROI（投资回报率），投入一定的时间和精力之后，就可以学习到能很快应用在团队工作中的知识，那样会对团队起到更大的帮助。
对于团队来说，不仅需要每个人的硬能力，比方说：
• 分析需求的能力
• 设计系统的能力
• 编写代码的能力
• 测试的能力
• 运维的能力
还需要各方面软能力，比方说：
• 与人沟通的能力
• 团队协作的能力
• 探索新事物的能力
• 谈判的能力
• 安排、计划的能力
因此，团队的成员应该根据自己的岗位、职责和任务，选择离舒适圈最近的学习圈知识，既在理论上也在实践中不断学习，从而对团队做出更多贡献，更好地为了团队的目标而努力。
4.改进
如果一个人能够每天都有进步，那么很快就会成为很厉害的人，成功就会离他越来越近。相信大家都知道1.01和0.99法则： 1.01的365次方等于37.8；0.99的365次方等于0.03。这是一个非常惊人的结果。
那么一个人应该如何以最有效的方式来改进自身呢？我会推荐每天用「三个黄金问题」的方式来给自己做回顾，这三个问题分别是：
• 今天我什么事情做得好？
• 今天我什么事情可以做得更好？
• 今天我学到了什么？
对于团队来说也是一样，我们也许要用最快的频率来做改进，从而不断进步。这也正是为什么我们要把开发的过程拆分成两周一个迭代，并且在迭代结束的时候一定要做回顾会议的原因所在。
曾经和团队算过一笔账，如果每两周做一次回顾会议，并计划并落实两项改进措施（不一定是大的改进措施，可能会是在很短时间就可以完成的改进），那么在一年之中，扣除节假日，至少还可以做20次回顾会议，这就意味着团队可以在一年中完成四十项改进。如果真的能够达到这个目标，相信一年过后的团队会有完全不一样的样子。问题就在于团队是否真正能够主动、持续地做这件事，并把每件改进措施都落到实处。
团队进行敏捷转型的准备
为了更好地进行敏捷转型，管理者自己要清楚，同时也需要让团队成员知道几件事情，从而为敏捷转型做好思想上的准备。
1.敏捷转型是一种突破，所以要打破一些框架
不管是敏捷的管理模式与传统的管理模式，还是敏捷的开发模式和传统的瀑布式开发模式相比，都有非常大的不同，因此敏捷转型需要作出非常大的转变，这必然会给组织以及每个人带来一些改变甚至是冲击。特别是对于研发团队的成员，他们的工作模式都会有很大的变化，比方说：需要参与更多的会议，如每日站会、评审会议、回顾会议等等；需要更多与人交流；工作节奏会更快，因为需要在很短的时间就要交付拆分后的故事；需要更透明，更开放，更多承诺等等。而这些转变很可能都是需要突破大家头脑中存在的思维束缚，或者打破规则、制度上的一些框架。
每个人都喜欢在自己的舒适圈里面，对于组织也是一样。然而，想要成长，想要适应外界新的变化，我们就需要不断地跳出舒适圈，当然不能一下子跳到恐惧圈，那样的话，步子就迈得太大了。我们需要做的是突破一小步，到学习圈里面去，尽管有一点儿不舒适，但还是可以忍受的。那样的话，就可以通过不断地重复练习，把它逐渐拉到舒适圈里面。这样，个人和组织的舒适圈就会不断扩大，也就具备了更好适应外部变化的能力。
2.敏捷转型是一个持续的过程，需要不断从失败中学习
敏捷转型并不是个简单容易的过程，而且，根据企业、组织、团队的具体情况不同，采用的方式和手段也会有所不同。很难找到一个放诸四海而皆准的标准模式，采用了之后就会顺利完成敏捷转型。
而且，既然是一个长期的过程，那么就难免在过程中会有波折，甚至可能会受到来自于各方面的反对和抵制，我们很可能会在那个时候，认为敏捷转型已经失败，因为看到的情形和我们期望的样子大相径庭。
然而，真正的失败=暂时不成功+放弃，是否真的失败，更大程度上取决于我们是否在出现问题的时候选择放弃，一旦做出那样的选择，就真的失败了，这不仅让之前付出的时间、精力、金钱成为一种浪费，而且会让很多人在这个过程中受伤，不再有勇气做出变革。
所以，是否能够坚持做下去，在失败中学习，不断总结改进，突破思维限制，找到更好的解决办法，是敏捷转型是否能够成功的重要因素。
小结
如果团队已经了解到敏捷转型是一个长期而艰巨的过程，需要做出很大的改变，团队成员相互了解各自的优势和劣势，能够取长补短、相互协作，并且真正理解敏捷团队要能够主动、持续地学习和改进，那么我们可以认为我们已经为敏捷转型从各方面做好了充分的准备。
作者：侯伯薇 JACK HOU （ CSPO，CSM，CSP，CIPT）快乐的程序员，十余年多领域软件开发经验；《软件系统架构》《修改代码的艺术》译者；英国皇家工会 CIPT 认证培训师；英国贝尔宾团队角色认证顾问。
点击这里，了解更多关于 Teambition 的故事