如何带领传统软件团队走向成功（四）

大家好，在经过了《如何带领传统软件团队走向成功（一）》《如何带领传统软件团队走向成功（二）》《如何带领传统软件团队走向成功（三）》三章之后，本系列分享就进入了尾声，今天就来和大家分享这个系列的最后一节：

持续优化改进 建立强有力的自组织团队

如果你读完前面三章，相信你也能感觉得出来，团队的持续改进之路其实就是团队的敏捷转型之路。

我讲的整个团队转型的过程，其实就是我作为一名新领导，空降到一个传统研发团队里，通过发挥自己的敏捷领导力，在不偏袒开发也没有迎合业务的基础上，不仅给开发人员营造安全的工作环境，培养他们的敏捷价值观，而且在质量提升方面我也发挥了作用，减少迭代返工。

并且引导和教练团队中的人员自身综合能力逐步提升，思想也随之改变。慢慢演变成团队所有人都能对什么是正确的事，如何正确的做事，作出更好的判断，继而走向持续改进的道路，建立起能自己做持续改进的自组织团队。

但这就圆满落幕了吗？当然不是，没有人能告诉我们敏捷的终点在哪里。Mike Cohn曾经说过：“你不是变敏捷了，而是变得更敏捷了”。敏捷或Scrum没有任何终极状态，变得更精通Scrum或更敏捷是一个持续的、永无止境的过程，追求的是日益精进。“我们终于实现了敏捷” 这样的说法没有任何意义，所以，我们团队的敏捷，还是需要继续坚持。

这里还也要跟你强调一下，虽然我讲述的案例中用的是敏捷的方法，而且也获得了很好的成效，但这并不代表我的敏捷实践是唯一的解决途径，或者说你自己团队的敏捷转型，就一定要照搬我的方式，一模一样来。每一个组织所处的环境各不相同，开发的产品也千差万别。

走出自己的敏捷之道

可能有的小伙伴，觉得别人的敏捷之路走得不错，我也照搬过来。那我就要打击一下你，没有的。没有人或者组织能带我们走一条预设好的、绝对能保证成功的路，我们必须要根据具体组织特有的目标、文化和复杂多变的环境，学习、检视并调整眼前的路。

想走别人的路并运用别人的学习成果，看上去似乎是一条敏捷的捷径。但是，世界上没有哪两个组织是相同的，甚至同一个组织中都没有哪两个团队是一模一样。

走别人的路不会让别人无路可走，只会让你自己无路可走。

学习过程当然也是不可避免的。我们需要快速地完成自己的认知循环，并且根据得到的经验认知来检视和调整。

当然，这也并不是说对别人走过的敏捷之路完全的置之不理。我们可以看看他们做了什么，借鉴吸收，想想他们为什么能够取得成功，但最终你得找到属于自己的敏捷之道。

不过，该坚守Scrum实践还是要坚守。比如，Scrum团队都应当由产品负责人、ScrumMaster和开发团队组成。他们都应当有迭代规划、每日例会、迭代评审和迭代回顾。

不过当然，每个团队或组织都应该有自己独特的方式。比如每日例会是Scrum的核心实践。如果不举行每日例会，就说明并没有采用Scrum。在每日例会中，每位成员介绍最新情况并了解其他团队成员的信息，让每个人都能了解工作的整体情况。但在每日例会开始后，应该由谁首先发言呢?每个团队都可以自己决定。

变革之路注定充满荆棘

另外，也不要指望Scrum过程不会出现问题。我敢肯定地说，到某个时候，肯定会出现阻碍敏捷顺利实施执行的障碍。

面对内部障碍，我们要依靠我们的自组织团队，充分地信任他们能够自己解决问题。

而对于大多数组织而言，维持现状是一股强大的力量，为了抵制这种倾向，要坚定、耐心，在组织变革中充当中坚力量。

要明白这种抵触很正常。给他们讲讲敏捷的价值观、基本原则和我们的想法，和他们共同工作，帮助他们走出困境。

不要与他们对立，而是和他们一起扫除障碍，让团队、开发工作和组织从敏捷的实施中获取最大收益。

解决问题的核心是人，敏捷也是如此

说了这么多，总结起来，其实我想表达的是：

敏捷本身就是由价值观、思维方式和最佳实践组成的，但是，这些本身并不能去解决我们所遇到的问题，解决问题的核心还是人，是一支贯彻敏捷价值观、用敏捷思想进行思考、充分贯彻敏捷最佳实践的自组织团队。

所以，当我们在使用敏捷时，不要担心事先是否能做够一次性到位。没有人做得到！绝大多数团队在前几个迭代都不会做得很好。这没有关系，我们只需要持续优化改进，建立起强有力的自组织团队，让Scrum团队在下一个冲刺都能比前一个冲刺做得好，就行了。