故障发生前为什么敏捷团队的成功？

     9有一天，一月，我参与日常微信智沙龙的发展，他讲述了一个成功的团队的故事了第一个敏捷。失败后，故事，著名的人从一个特定的公司实例。伟大。

后沙龙，丰满老王整理博客《一个成功敏捷团队的失败历程》。（转载在 http://blog.csdn.net/zhangmike/article/details/40950267 ）

本文试着从我的视角来分析下为什么？

首先来看其前期为什么成功？

     1，项目经理首先选用了Scrum。决定实施自己主动化測试，同意測试落后开发一个Sprint

     2，美国老大不惬意。要求开发測试必须同步。制定强制要求，引入TDD（被老大逼迫使用的）

     3。项目经理进一步要求，开发者必须參与集成測试Case的编写

     以上看起来是命令驱动的结果。将常见的敏捷实践用起来了。

那么为什么后期失败呢？

    1，项目经理和測试Leader离开团队，尽管来了一位美国架构师，但后来他也离开了。

    2，原測试人员的顶头上司（測试部门经理）转变了职能

    3，没有人真正关心质量。原来的敏捷实践-结对。TDD被放弃，自己主动化測试用例不再维护

咕咚老王对于前期成功的分析是“前一个产品开发阶段的敏捷。是权威下的“敏捷”。之所以成功。不是形成了真正敏捷的自组织团队。而是在项目管理人员的个人权威之下。实施了真正的敏捷实践。”

      所以能够看到，真正的敏捷实践能够带来团队的成功，尽管没有形成真正的敏捷自组织团队。

     咕咚老王在文中推荐了敏捷教练/Scrum Master。这是一个不错的解决方式。

但除了这个解决方式之外，还是否有其他方案呢？  笔者推荐例如以下的2个方案

1，保持权威，既然权威敏捷带来了成功，何不发挥这样的方式。

2，将形成的好实践落在团队章程上，形成组织+团队双重监督

对于保持权威，即是让续任的项目经理继续坚持好的实践，续任的项目经理要相同的理解敏捷实践。理解当中利弊，能够做出权威的正确决策。这事实上是对一个组织的项目经理培养机制的考验。一个成功的项目经理晋升了，续任者不可能有前任相同的看法和经验。中国人信奉新官上任三把火。续任者总是有些不一样的。“萧规曹随”尽管也是国人古代的智慧。但貌似在中国用得不多。

  眼下而言。培养权威的项目经理较之培养合格的敏捷教练，我觉得培养前者更easy些。

在东方官文化下。合格的敏捷教练实在是太稀缺了。

而对于团队章程。即是将团队得到的好做法记录下来。在Scrum中推荐制定完毕定义DoD，这事实上就是团队章程，或者说章程的一部分。

团队章程在每一个（或者每2个）迭代的回想会议上得到更新的机会。把最新的好实践加到团队章程中。

增加的方式能够是自组织的方式，也能够是权威方式。

权威方式获得的团队章程将高于权威，也即是团队章程不会被权威轻易的改动。

团队章程的形成会对权威形成制约。

这样固化后的共识不会留下个人权力的工作人员由于消散。

版权声明：本文博客原创文章，博客，未经同意，不得转载。