诺记敏捷之前世今生
诺记敏捷之前世今生

诺记敏捷之前世今生

不久前诺基亚宣布停产生产塞班智能手机,业内人士和媒体开始热议塞班之败的原因。微博上也有很多网友开始将塞班甚至是诺基亚之败跟“诺基亚不是最早做敏捷的么”关联起来,甚至得出一些类似于“敏捷害死了诺基亚”或者“敏捷也没能救得了诺基亚”之类的结论。作为几乎较完整地经历了诺记(包括前诺基亚网络也即现在的诺基亚西门子通信,简称诺西;以及诺基亚手机部门)。

我叫徐毅,现在在诺基亚功能手机北京研发部门担任敏捷及精益教练,在此之前,我短暂地供职过上海惠普的企业服务业务部门,再往前,就是我至今为止职业生涯中经历最长时间的前诺基亚网络(现称诺西)杭州3G研发中心。诺西杭州最早是在2005年底开始第一个Scrum及敏捷试点项目,我在第二个月以专职测试人员身份加入;2008年开始转为内部的专职敏捷教练;如今在诺基亚功能手机部门。所以,我自认为还是有一定的资格可以跟大家介绍一下诺记敏捷的历史。

当然了,诺基亚和诺西都有着好几万的雇员,业务遍及全世界,而研发中心也有很多个, 业务线也很多,而且诺西除了前诺基亚网络的部分还有合并进来的前西门子通信的人员和业务,所以我不可能可以概括全部,但至少我可以从我所见所闻和所知道跟大家闲聊几句。关于我自己的职业生涯信息,或者其他个人信息,可以通过如下链接深入了解:

故事正式开讲。

2005~2006年 前诺基亚网络,IPA

年初我还是一名小小的测试工程师,刚刚被母公司前纬创杭州(=前士通资讯,=前杭州超软)派遣到前诺基亚网络杭州研发中心,作为一名外包方员工加入其3G传输平台系统的软件测试工作。主要担当测试及测试自动化方面的工作,而且也主动加入了当时新成立的Linux平台部门,这也为后来加入试点项目买下了伏笔。

2005年底,吕毅找到我问我要不要加入正在进行中的一个叫ATCA-IPA的项目,他们正在尝试一种叫做Scrum的新式软件开发方式,目前有三名开发人员,需要一名专业测试人员的加入。搜索阅读了大量文章,我并未犹豫多久,就决定加入这个项目。后来我慢慢地才知道,这竟然是敏捷大转型的开端;而且以我所了解的情况,这应该也是国内最早的Scrum试点项目,可能敏捷的个人实践者很多,但一则多是尝试XP实践,二则规模不大,总之,在Scrum这一块,我们应该是最早的先行者了。

项目一直延续到2006年底,我们团队(团队名:Grid;集体投票得出,取意当时热门的网格计算技术)还获得了项目的公开表扬,因为我们不但保证了高产出,而且还很好地探索了当时所知的各种敏捷实践(主要是XP范畴内的诸多实践,包括单元测试、TDD、结对编程等等)。如今我还依然记得在Greenwich会议室里,和李程远、孟贤、周函一起奋斗的场景,也记得我和ScrumMaster许俊因为测试自动化策略和Scrum做法而争得面红耳赤的样子,真是一段美好的时光。

能够在敏捷试点方面有好的成果,后来观察了很多其他组织实施敏捷之后,我才意识到,当年我们能够成功的关键在于我们有极其强大的支持团队。它包括,

  • 业内专家:Craig LarmanBas Vodde(时任内部敏捷转型团队负责人),和其他我未曾见面的大牛。
  • 内部专家:主要是指我后来也加入的Flexible Company团队,全球范围内支持诺西内部所有敏捷转型。成员包括Petri Haapio等;以及来自内部测试卓越团队的Jukka Savela
  • 里应外合:吕毅曾师从Ken Schwaber;而我则是对Scrum有着极大的兴趣;后来加入的@秦之远@hanzhi窦也都对敏捷有着非常积极的态度。

后来团队也变成了两个,项目增加了很多新鲜血脉,没记错的话,@秦之远@hanzhi窦都是在这个时候加入的。项目将近尾声时,@terry尹哲短暂地担当了一阵子我们团队的ScrumMaster。

遗憾的是,虽然我们在技术、产品(传输平台系统,非面向消费者的终端产品)和敏捷实践方面有着令人瞩目的成绩,但在当时前诺基亚网络和前西门子通信合并的大环境之下,诺记ATCA-IPA产品在权衡之中被领导层决定放弃,转为使用前西门子通信据说已经达到商用水平的系统(不过貌似后来也取消了……),我们的敏捷试点项目也就就此告一段落。

对我来说,个人收获主要在于:体验了Scrum、敏捷开发模式;理解了测试人员如何在敏捷环境下工作(参考我2010年敏捷中国大会的演讲《Be Modern Agile Tester》);参与制定了DI(Development Item)流程中的测试(DIT)流程;尝试了和开发结对,也尝试了和测试结对;等等。

2007~2008年 诺西,3G传输平台研发部

虽然前面的Scrum试点项目因为大环境缘故被取消,但高层很认可其试点效果,于是才有了后续的大范围推广。时任该产品线研发老大的Tero Peltola下定决心,要通过敏捷提升软件研发实力,影响多达五六百人的产品线敏捷转型就此拉开帷幕。时至今日仍在延续,并以扩散至其他产品线,但各个产品线的实施效果则有很大不同,这是后话,这里先不讲。

话说这个敏捷大转型,我后来认为至少有一个极大的失误,那就是,之前的Scrum试点团队人员被直接安排进入下一代新产品研发,而没有被整体考虑放入老产品的600多人里面去散播敏捷知识和经验、促进转型顺畅进行。与之相反,我们采取的是一种Big-Bang形式的转型,直接转为基于Scrum的敏捷模式,就像我常说的,一夜之间,所有的项目经理岗位全部消失,他们必须再选择担纲其他角色,例如ScrumMaster、产品负责人等等(这段记忆或许不对,如有朋友仍记得内情,请不吝告知)。

我自己则跟随着前试点团队直接进入了下一代新产品FemtoGW的研发,和产品线分属两条线各自进行自己的敏捷实践和转型。诺西属于全球性企业,加之刚刚合并,因而也导致FemtoGW面临着三线开发的局面:我们在杭州负责传输平台的开发,意大利米兰负责驱动层部分的开发,而印度班加罗尔则负责应用层的开发。更复杂的是,杭州采用了完全敏捷化的开发方式,而和我们有较强依赖关系(平台依赖驱动)的米兰则选择跟随采取了半敏捷的方式,位于班加罗尔的印度同仁们则依然是瀑布型(应该是CMMI吧)的传统开发方式。

敏捷和瀑布对接所面临的问题,我们就曾经历过一次事件,我个人对此印象很深刻。某天中午时分收到印度同事来信,说他们发现了一个bug,需要我们团队的帮助。我时任团队(团队名:Thunder;取意雷霆一击)ScrumMaster,我判断认为不需要现在打扰团队,可以等到Scrum日会时再告知团队成员并商量处理方案,于是乎,从班加罗尔-杭州这个角度来看的话,我们并未作出回应。让我吃惊的是,下午大概2~3点的时候,又收到对方的一封邮件催促,邮件内容大意是,要求我们尽快或立刻调试解决此bug,他们有50多名测试人员因为这个bug的阻碍而无法继续干活……

FemtoGW项目扩张很快,我们很快又填充了很多前西门子的同事,也增加了很多新招聘进来的同事。不得不说,就我所接触过的那几位前西门子的同事,的确能力很强,包括丁俊华、滕帆(两人最开始都在Thunder,后来去其他团队担当ScrumMaster,也是我们虚拟架构师团队的成员)等,以及和我不争不相识的测试同仁刘哲文。当然,我还见识了出自华为的卢红旭同学敢加班敢熬夜的牛逼精神,就是可惜这小子花了太多时间在炒股上。

王婆卖瓜,自卖自夸。要问我谁最棒,我一定告诉你,那就是我们Thunder团队的兄弟们(包括几位姐妹)最棒!虽然一直都是人来人往,但Thunder的精神却一直延续着。我还记得他们都是(如有遗漏,敬请谅解,并联系我加进来):李程远、丁俊华、滕帆、陆宏斌(后继任ScrumMater至今)、胡振东、张博涛胡笳、Zhao Congxin(女)、张翠香。我依然记得,曾经,因为Sprint即将结束,我们却被一个小bug给困扰无法通过持续集成,我和陆宏斌、胡振东一起加班奋战到凌晨3点多终于搞定,带着极大的满足感打车回家,但是……等我到家门口一掏裤兜才发现忘记拿钥匙,兜里总共只有100来块前,刚好够打车到公司往返的路费……

我还记得,第一个Sprint,我们就100%全部满足了DoD的所有要求,这几乎是我们团队甚至项目所有团队的唯一一次,而且这个DoD的还设定得非常苛刻,没记错的话,我们要求代码覆盖率必须超过85%、圈复杂度低于5。也正因为太苛刻难以达成,后来就降低了其中的一些要求。不过,其中有一条要求到最后也没有改变或者是拿掉,那就是:DONE意味着除了在本机或测试机上测试通过,还必须在CI环境下测试通过。这其实是一个非常苛刻的条件,团队越多越苛刻。能够做到这一点,时任部门经理陈濯非(昵称:Trophy;他虽不在项目里挂名,但却非常关注和投入这个项目)的大力支持功不可没,我们从一开始就明确了CI纪律必须遵守不得违反,一旦build失败所有人都不准check-in代码。为了帮助团队做到这一点,我们组建了一个虚拟的CI团队,我记得至少包括我、@秦之远、黎晰和其他几个开发,组成类SWAT团队。专门负责照顾CI实践的健康运转,如果CI出现问题,例如build失败,我们就要集合起来,去定位问题然后分发问题甚至直接解决问题,确保CI系统中的build一直正常。而@秦之远也就是从这个时候,开始钻研CI,并逐渐成长为组织内当仁不让的CI专家。

@hanzhi窦是我们的产品负责人(Product Owner,简写为PO),在此之前,他是我们CCC(Chorus Competence Center)的几名技术专家之一,有着深厚的技术积累。加入FemtoGW项目后,就走上了敏捷的道路,成为了一名PO。关于PO这块的工作,和他交流、学习是上佳之选,我就不再废话。不过有一点,我想要告诉大家,FemtoGW项目包括老产品近600人的研发,我们用来管理产品列表的工具都是Excel。我想老窦对我最深刻的印象,估计是“刺头”,每次Sprint评审会议,30几好人济济一堂,总能听到我抗议、反驳其他团队介绍其需求已经DONE的结论,我坚持要求严格地按照DoD的标准判决,DONE就是DONE,NOT-DONE就是NOT-DONE,没有中间的灰色地段。尤其是在所有团队连续三四个月都无法DONE掉任何一个用户故事(因为CI的build一直fail),老窦非常想要通过DONE来增进团队的成就感、提振团队士气的时候,我却一如既往的坚持不妥协(呃,Thunder团队自己也无法DONE,CI影响到的是所有团队)……

当时,我们还对一个重要实践进行了尝试 —— ATDD(Acceptance Test Driven Development,接收测试驱动开发)。我则几乎全程参与了这个尝试,但我个人感到非常遗憾的是,后半程王献接手后,他跟老窦一起把它从一个实践变成了一个流程。我跟王献和都是好友,但这个操作,我个人确实难以认同,因为我认为ATDD的关键就在于互动和交流,这个流程则极大地削弱了它们的作用,或者说“解除了对它们的依赖”。

当时在组织内有好几个改进措施,都给ATDD的尝试打下了基础。

  1. 对robotframework的全面采纳和推广:我是测试自动化组最初的两名成员(我和俞森,组长是邹仲毅)之一,经历了多个工具的兴衰,时任robotframework内部培训师和测试自动化教练。robotframework的试点非常成功,也很适合敏捷这种研发模式,所以被大范围推广,以图提高自动化比例。这个工具本身就是面对接收测试(Acceptance Test,敏捷下有了新的含义,和过去的UAT不同)的,也支持ATDD。
  2. 用户故事兴、功能SPEC衰:敏捷转型对我们当时沿用的研发模式和流程产生了极大的冲击,其中就包括FRS(Feature Requirement Specification),此feature非彼feature,不是敏捷环境下常说的特性,可看做是多个模块构成的一个小功能集。当时对于开发和测试来说,这是一份非常重要的文档,它是开发和测试的依据。转向敏捷之后,有了用户故事,FRS就显得有些多余,然后陈学凯牵头在想办法如何能妥善地处理或转化这份文档的内容。商讨过程中,结合robotframework测试用例的一些特点,我提出了“Executable Requirement”(可执行需求)的设想,我想这跟Gojko Adzic在《实例化需求》中提到的“Living Documentation”(活文档)有异曲同工之妙(ps. 他也采访过我哦,英文版鸣谢名单里有)。
  3. Elisabeth Hendrickson:这主要是对我个人的影响。Elisabeth是敏捷测试方面的专家,曾获得敏捷联盟2010年的Gordon Pask大奖,她曾开办有Quality Tree公司提供敏捷、敏捷测试方面的咨询,由于刚刚加入了Pivotal Labs公司,她已经不再经营此业务。我非常有幸能够在我迷茫和犹豫的时刻,参加了她的敏捷测试和ATDD培训(5天),这位受人尊敬的专家(据Michael Bolton八卦说,好像是Brian Marick吧都认为跟她抢单失败一点都不丢脸)也和我有相似的观点,让我倍受鼓舞,更加坚信我的测试理念和坚持并非不切实际也绝不理想化。她介绍ATDD的文章,可以在她网站上免费下载,点击这篇博文即可。
  4. 对持续集成纪律的遵守:因为我们对持续集成相关纪律的坚决执行和绝不姑息,使得我们可以长期拥有可工作的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 VilkkiRan NymanSami LiljaWolfgang Steffens,德国的Hans NeumaierPeter 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 NymanSami Lilja在Espoo时讨论DX200的多地协作coaching事宜;和Wolfgang Steffens探讨他专长的产品管理相关话题;和吕毅在北京合作辅导,还结识了张绍鹏赵卫他们;等等……

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

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

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

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

我在这段时期的个人经历在我参加2012年敏捷中国大会的演讲《敏捷教练之路》(山寨版演讲录音)中有所体现。

ps. 我们的敏捷转型能够开展得比较热烈,应该跟大环境也有一些关系。加入Flexible Company后,我翻阅团队内部维基网页,其中记载了08年在芬兰召开的一次公司内部敏捷大会,大会的开场白是时任COO的一段视频影像,视频里他告诉我们,当时诺西的研发成本中,软件开发的部分已经超过50%(或60%,记不太清了),我们亟需提升软件研发的质量和速度,而敏捷就是一个契机,所以我们必须向敏捷和精益转型。

2011~2012年 上海惠普,ES,资深敏捷顾问

2011年,受到猎头诱惑,决意前往惠普探究以商业的方式传播敏捷,加入了其APT团队(Agile Portfolio Team)。主要团队成员包括:郑立黄灵、孙长虹、邹骏庄万俊,People Manager是郭继菁。还有面试了我,却被调入其他团队的李文生同学……

惠普的经历和本文主题无关,不描述。

2012年~  诺基亚,MP,敏捷及精益教练

2012年,再次被猎头召唤,最终来到之前压根就不考虑的北京,加入了诺基亚功能手机部门,担任敏捷及精益教练。跟业内人称乔帮主的乔梁做了同事。

原本一直以为同是诺记,其文化氛围应该跟我以前待过的前诺基亚网络差不多,来了之后才感受到,其实并非如此。从组织结构,到工作流程,到一些细微处的文化灵活度,或多或少都有区别。而且在敏捷方面的历程也不一样。原本一直以为,诺基亚手机业务也是很早开始实践敏捷,但从交谈中得知,这边是从2009年才开始推广敏捷和精益方式,牵头人是Maarit Laanti。不过,这可能只是功能手机(Mobile Phone)业务部门的情况,根据一些从原Symbian业务转过来的同事们说,他们在塞班早就已经使用敏捷很久了。

至于业内广为流传的“诺基亚测试”,的确名副其实,绝对不假。因为Bas在发明此检查表的时候,属于前诺基亚网络的雇员,而前诺基亚网络则是诺基亚的旗下企业,因此,称之为“诺基亚测试”的确不假。但很有可能当时,诺基亚网络业务和手机业务之间的交流并不密切,虽然网络业务正在尝试和进行着敏捷的变革,可能手机业务部门并不知情吧。

塞班业务,我并不了解,但可能还不能够跟诺基亚的手机业务完全等同起来看待。塞班最开始应该算作是是独立运作的行业组织,后来因为略显颓势,诺基亚才把这块业务整体买下,靠自己独立支撑和发展。它们的敏捷历程,我不清楚。

2013 我们继续前行

nokia-nsn

(先发于“让敏捷飞-敏捷联合社区站点”,经许可转载)

一条评论

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据