一个成功敏捷团队的失败历程

昨天经过微信沙龙，分享到了一个案例，讲述的是从成功到失败的过程。

不少人可能疑惑，不少案例都是从失败到成功，这个怎么反了。不少成功背后都有其缘由，可能很励志，但从失败中咱们可以获取更多。毕竟咱们的知识大多源于失败而非成功。

故事是这样的（括号中的是笔者的情绪表达 :)）：

（在好久好久之前……）某公司成立了一个团队，开发一款全新的产品。产品的开发模式是产品需求获取和开发同步进行，团队构成为：项目经理带领开发和测试两个子团队，每一个子团队各有一名Leader。产品经理在开始仅提出最基本需求，根据内部用户的反馈，不断改进需求。（哇噢，很酷！）。这就致使了持续发布的需求。开发流程选用了Scrum。（用到敏捷啦*_*）。开发测试同步进行，最先几个Sprint，采用纯手工测试，仅限功能测试。（噢~，会成功么？）。纯手工的问题马上暴露：没法回归。（出现问题了吧~）。形式所迫，引入自动化测试。（还好，纠正的及时 :)）。项目经理很权威，马上决定实施自动化测试，同时保留部分新功能的手工测试。但问题依然存在，当开发人员不参与测试，测试相对于开发的滞后是必然的。这个gap没法逾越。

项目经理容许测试落后开发一个Sprint。（看来要违反敏捷中“完成”原则了。）测试工程师们通过努力，达到了这个标准，中国team表示很满意；但美国老大不满意，要求开发测试必须同步。（看来老大仍是理解敏捷的。）因而制定强制要求，要求开发人员必须写单元测试，由此引入了TDD。（哇！原来这个神器是被老大逼迫使用的。）同时测试架设CI，并引入测试覆盖率统计工具，若是新功能的测试代码覆盖率低于阈值，则不容许checkin代码。（持续集成也有啦。手舞足蹈中~）。项目经理进一步要求，开发人员必须参与集成测试Case的编写，这一点其实并无很好的执行，但靠着项目经理我的的权威和测试工程师的努力，产品就这样发布了。反馈很是不错，Bug不多，且没有任何致命的Bug。（耶~成功啦~，此处掌声如雷！）。总结经验，感受产品的质量很高，能到达这个质量，与开发和测试同步进行有直接关系。因此此产品1.0发布以后的开发中，但愿敏捷过程更加推动了一步。

成功发布了一个产品后，团队又接受了开发另一个新产品的任务，类型与前者相似。团队将敏捷推动到了第二阶段：全功能团队，Scrum+pair programming+TDD。（此处能够有掌声！）（满眼都是羡慕的小星星，结对都用上啦！）。开发测试不分，先后端不分，全部工程师都一概结对编程。因为招聘时对测试人员的要求高，所以Coding技能并不比开发人员差。这时没有QA和Dev的差异了，两我的之间会自由交换角色。团队终于从半敏捷转为全敏捷！（其实前面已经很敏捷啦~）。

可是从这时起，一个负能量的变化却在暗流涌动：项目经理和测试Leader因升职或其余缘由而调离团队，整个团队中没有人再关心质量。可是问题并无马上暴露，由于前一个项目中遗留的资产（Test frame work、Test case等）还能继续使用。还有一点就是美国团队引入了一位精力充沛的Architect，这位老兄天天20小时盯着项目，还会本身手动的去进行测试。（美国牛仔？）。他成了项目中惟一一个关心质量的人，不断的督促团队成员去写测试Case。到这个阶段，整个项目依赖着前一个项目的积累和Architect的我的英雄主义推行着。

依赖着这套貌似很酷的“敏捷”，项目坚持到了产品的发布，但你们都知道这个项目的质量是没法和前一个产品相比的。（我这时问了一个问题：团队中是否有敏捷教练或相似的角色？回答是没有。）故事尚未结束，原测试人员的顶头上司（测试部门经理）转变了职能，但团队中QA engineer的report line并无改变。至此，团队内外，已经没有人关心质量了。以后持续了一段时间的结对编程，可是TDD已经被放弃了。（神器被首先抛弃了。）。CI虽然还在运行，但每次运行时执行的Test Case已经好久没有增长过新的，旧的则无人维护以至被关掉了。（测试通不过怎么办？不测试就好了呗 :)）。以后所谓的敏捷团队，就是产品经理的Story，以及团队成员天天去完成这些Story。他们以为已经“完成”了，就Checkin。整个团队陷入了噩梦的状态，若是产品经理不去确认，没有人知道这些程序是否可以运行起来。

最终的结果是，曾经开发新产品Bug不超过两位数的团队，如今沦落到一个新的功能完成后，都没有人去测试一下的状态。（呜呜呜~，大哭！）。

是什么致使了这样的结果？下面是笔者的一点感觉：

1. 前一个产品开发阶段的敏捷，是权威下的“敏捷”。之因此成功，不是造成了真正敏捷的自组织团队，而是在项目管理人员的我的权威之下，实施了真正的敏捷实践。当权威再也不存在时，实践也就没法坚持下去了。
2. 敏捷团队中没有敏捷教练/Scrum Master。许多人认为这个角色在国内的公司内是没法获得认同的，由于他既不开发也不测试，对产品没有贡献。而这个案例偏偏对此做了很好的注释。咱们是关心一我的的成本被“浪费”？仍是坐视一个团队的成本被浪费？以前的那个项目经理这个角色是不是“浪费”？（关于此点当时有所讨论，分享者认为项目经理与敏捷教练是不一样的，项目经理的责任更多，而敏捷教练则不多。笔者认为这是一个误解，项目经理的责任，包括权利被整个团队继承和分担了，其中项目总体管理这个责任的一部分就放到了敏捷教练身上。同时，敏捷教练也承担了更多其余敏捷相关的责任。笔者我的认为：当团队成员都对敏捷有了极致的理解，敏捷文化高度盛行的时候，敏捷教练也就不须要了。也就是说，敏捷教练必定要作本身的掘墓人。）
   敏捷教练的角色之因此重要，就是由于TA在引导你们遵循敏捷实践的原则和价值观，遵照敏捷的纪律，最终促使团队走向成功。
   缺乏了敏捷教练，就没有人关注团队中那些误差和障碍，甚至当这些问题摆在面前时，你们也是熟视无睹。好比案例中：对TDD的抛弃、对“完成”定义的抛弃。
3. 没有敏捷教练的角色，带来的另一个弊端就是没有人宣扬和传输敏捷的价值观和文化，没有人对团队成员进行敏捷教育。从而使得团队只是一个权威下的“敏捷”团队，而非最终造成一个自组织的敏捷团队。

 9/28日更新：
刚刚看完Ken Schwaber和Jeff Sutherland合著的《30天软件开发 告别瀑布拥抱敏捷》，其中在第8章——“在企业中应用Scrum”——中有这么一段话，对此类案例作了精辟的总结：咱们已经见过太多例子，在企业内的其余人尚未真正懂得如何用新的方法思考和工做，转型尚未在企业内扎根时，发起人就因为晋升或离职离开了原来的岗位。当发起人高官离开以后，以前取得的进步将灰飞烟灭，而刚被淹埋却没有根除的旧文化又会卷土重来。以前取得的优点和持续改进的习惯也会随着时间的推移渐渐减弱。

欢迎你们板砖伺候！