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

发表于:2013-03-20来源:letagilefly.com作者:徐 毅点击数: 标签:敏捷
对持续集成纪律的遵守:因为我们对持续集成相关纪律的坚决执行和绝不姑息,使得我们可以长期拥有可工作的build;当然也因为我们在SCM(问@秦之远)和测试

  对持续集成纪律的遵守:因为我们对持续集成相关纪律的坚决执行和绝不姑息,使得我们可以长期拥有可工作的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