诺基亚实施敏捷软件开发的前世今生(3)

　　对持续集成纪律的遵守：因为我们对持续集成相关纪律的坚决执行和绝不姑息，使得我们可以长期拥有可工作的build;当然也因为我们在SCM(问@秦之远)和测试自动化两方面(问我)取得的一些成就。虽然ATDD实践本身，严格来说并不依赖自动化，全手工方式进行测试，也可以使用ATDD实践，但缺少测试自动化和持续集成的话，Scrum就无法提高成效、迭代增量式也就难以真正体现其威力。

　　至于老产品那600多人的转型，吕毅作为其中一大需求领域的部门经理，有很直接的体会;以及其他很多的同事，就不再一一列举了。这个过程绝不是蜜月之旅，相反，经历了长时间的混乱(有点像团队模型中的磨合期)。从矩阵式按职能划分的组织结构，直接转变为按产品需求领域划分、以跨职能特性团队为基本构成单元的组织结构，IPA经历了近半年的混沌期。随后才渐渐地摸出门道，走上正轨。我记得，后来我曾问过王献：从你质量经理的角度看，咱们的敏捷转型是成功的吗?(他时任质量经理，后掌管杭州质量部门，现已转战另一产品线。我、俞森、王献，从前纬创到外派诺基亚一直都是队友，后来各自有各自发展道路：俞森测试一条路走到黑;王献转战质量;我则移情敏捷。)他说：各种质量指标、交付速度等都有提高。

　　关于这场转型，可以阅读转型中期时，我和王献为《程序员》写的一篇文章“敏捷实践的七个方面”，描述了我们眼中这场敏捷实践所经历的误区和陷阱。这篇文章后来在公司员工论坛上被骂得很惨，被认为是说了公司的坏话，影响公司形象，王献还因此感到很内疚，也许我脸皮比较厚，我倒觉得这是纯技术角度的讨论交流，希望分享我们的经验教训，当时还希望能抛砖引玉，也听听其他业内公司的敏捷实践经验，可惜回声寥寥。

　　2008~2011年，诺西，Flexible Company

　　2008年底，在Bas Vodde怂恿下，我鼓起勇气申请了公司内部敏捷转型支持团队(昵称：Flexible Company)的职位。可能是因为团队内好几位同事都已经对我有印象，所以我还算挺顺利地就加入了这个优秀团队。团队的起源跟Bas有关，公司内敏捷的星星之火也是由此地点燃。Bas当年在杭州主持质量管理工作，觉得沿用老的方式无法解决质量困境，觉得敏捷可能可以，然后就和Craig Larman搭上了线，开始在公司内部(主要是芬兰，05年才来到杭州)以program的形式开展试点。因为其意图是为了让产品研发变得更加灵活、敏捷，所以取了Flexible Product Development这个名字。后来他们又觉得，仅仅只是产品研发变得灵活还不够，必须要整个公司都变得灵活起来才行，遂改名为Flexible Company。再后来，他们觉得敏捷这事不是一时半会的事情，不是一个临时性的工作，以program的方式很难实现，于是就固定下来变成了一个团队。

　　逐渐地，由于无法兼顾，Bas Vodde为了专注自己的咨询公司odd-e，选择了离开诺西;Petri Haapio继任开始管理这个团队，但他随后也离开诺西，加盟曾获欧洲最佳雇主荣誉的芬兰咨询公司Reactor Innovations掌管其咨询业务;此时，团队的LM(Line Manager，直线经理)Kati Vilkki决定自己接手管理这个团队，也正是在此时，我加入了。

　　团队成员有：芬兰的Kati Vilkki、Ran Nyman、Sami Lilja、Wolfgang Steffens，德国的Hans Neumaier、Peter Braun，匈牙利的Paul Nagy，印度的Jerry Rajamoney，中国的我，以及仅有几面之缘的匈牙利人Gabor Gunyho。

　　出于地缘上的考虑，我的支持范围主要是国内的四个研发中心：杭州、成都、上海、北京。但我们团队会定期不定期地安排全体聚会，讨论、交流、分享经验教训、集体学习(例如：Pepe Nummi给我们培训Facilitation;请Craig Larman给我们培训Agile Modeling and TDD Workshop;请Elisabeth Hendrickson介绍如何设计一个游戏，可惜我却错过了……)我们还很重视co-coaching，只要有可能我们一定会选择两个人结对coaching，除了Jerry以外，我就和团队里几乎所有人都结对过，这对于我们相互理解、共同学习有很大的帮助，而两个人从不同的角度看待同一个问题(被coaching对象)也能够做到更全面些。写到这里，我不自觉地想起我和Paul一起在成都site做coaching的时光，也忘不了我快速穿过车流走到马路对面，他却被截在马路当中面对着双向飞驰而过的车流束手无策、一脸惊恐的样子;还跟Sami Honkonen一起在成都辅导TDD;和Kati Vilkki在成都辅导Self-Organized Teams和Lean Software Development;和Hans Neumaier在成都辅导PO、敏捷估计与规划;和Peter Braun在上海辅导Scrum、敏捷和Lean;和Ran Nyman、Sami Lilja在Espoo时讨论DX200的多地协作coaching事宜;和Wolfgang Steffens探讨他专长的产品管理相关话题;和吕毅在北京合作辅导，还结识了张绍鹏、赵卫他们;等等……

　　这段经历让我学到了非常非常多，根本就不可能罗列完。但有一项收获影响了我的关注方向，也影响了我后来的发展。

　　曾经，在IPA所经历的那些敏捷实践、敏捷转型，以及在公司员工论坛上受到的各种待遇(因为转型带来了巨变，很多人在论坛上骂爹骂娘，作为论坛上可谓唯一坚定支持敏捷的灌水王，我长期被骂得狗血淋头。虽然很郁闷，但也非常感谢他们其实也磨练了我的心智，提高了我情绪自控的能力)，我一直问自己“Why me?Why me?!”

　　然而，当我成为一名专职的敏捷教练，开始进入到更多的不同产品线、不同文化和风格的组织之中后，我开始意识到，其实我曾遭遇过的问题、困境，都不是特例，换一个地方、换一个环境、换一批人，同样的剧情还在上演。一切的根源都在于人。也许敏捷，是一场运动，是一系列实践，是一类方式;但敏捷转型，它只和“人”有关系。

　　同样我也开始意识到，面对变革，人们的本性是拒绝(参考责任模型、Satir改变曲线、变革八步骤等等;后来我发现，管知时同学最近很爱研究“TOC之六层抗拒”，似乎很好用)，赢得并建立信任才是任何敏捷转型必须要做的第一步。偏重于技术实践、管理实践，却忽视人或企业文化的敏捷转型，几乎可以肯定其结果是失败。技术能力当然重要，但仍不是敏捷转型的关键;若信心决然真要做成敏捷转型，就务必认识到，其本质就是一种组织级别的转型，而这种规模的转型，不可能靠发动一小波狂热分子的积极推动就可以奏效，不管他们是来自于技术团队的基层人员还是管理层的高级管理人员，都一样无效。组织转型，必然需要动员整个组织的力量，上下齐心、各守乃业，方可业无不成。

原文转自：http://letagilefly.com/post/2013/03/%e8%af%ba%e8%ae%b0%e6%95%8f%e6%8d%b7%e4%b9%8b%e5%89%8d%e4%b8%96%e4%bb%8a%e7%94%9f-10201.html