Category: Scrum

Scrum Framework

诺记敏捷之前世今生

不久前诺基亚宣布停产生产塞班智能手机,业内人士和媒体开始热议塞班之败的原因。微博上也有很多网友开始将塞班甚至是诺基亚之败跟“诺基亚不是最早做敏捷的么”关联起来,甚至得出一些类似于“敏捷害死了诺基亚”或者“敏捷也没能救得了诺基亚”之类的结论。作为几乎较完整地经历了诺记(包括前诺基亚网络也即现在的诺基亚西门子通信,简称诺西;以及诺基亚手机部门)。 我叫徐毅,现在在诺基亚功能手机北京研发部门担任敏捷及精益教练,在此之前,我短暂地供职过上海惠普的企业服务业务部门,再往前,就是我至今为止职业生涯中经历最长时间的前诺基亚网络(现称诺西)杭州3G研发中心。诺西杭州最早是在2005年底开始第一个Scrum及敏捷试点项目,我在第二个月以专职测试人员身份加入;2008年开始转为内部的专职敏捷教练;如今在诺基亚功能手机部门。所以,我自认为还是有一定的资格可以跟大家介绍一下诺记敏捷的历史。 当然了,诺基亚和诺西都有着好几万的雇员,业务遍及全世界,而研发中心也有很多个, 业务线也很多,而且诺西除了前诺基亚网络的部分还有合并进来的前西门子通信的人员和业务,所以我不可能可以概括全部,但至少我可以从我所见所闻和所知道跟大家闲聊几句。关于我自己的职业生涯信息,或者其他个人信息,可以通过如下链接深入了解: LinkedIn职涯档案:https://www.linkedin.com/in/kaveri 在下的个人网站:http://kaverjody.com/ about.me页面:http://about.me/xuyi 故事正式开讲。 2005~2006年 前诺基亚网络,IPA 年初我还是一名小小的测试工程师,刚刚被母公司前纬创杭州(=前士通资讯,=前杭州超软)派遣到前诺基亚网络杭州研发中心,作为一名外包方员工加入其3G传输平台系统的软件测试工作。主要担当测试及测试自动化方面的工作,而且也主动加入了当时新成立的Linux平台部门,这也为后来加入试点项目买下了伏笔。 2005年底,吕毅找到我问我要不要加入正在进行中的一个叫ATCA-IPA的项目,他们正在尝试一种叫做Scrum的新式软件开发方式,目前有三名开发人员,需要一名专业测试人员的加入。搜索阅读了大量文章,我并未犹豫多久,就决定加入这个项目。后来我慢慢地才知道,这竟然是敏捷大转型的开端;而且以我所了解的情况,这应该也是国内最早的Scrum试点项目,可能敏捷的个人实践者很多,但一则多是尝试XP实践,二则规模不大,总之,在Scrum这一块,我们应该是最早的先行者了。 项目一直延续到2006年底,我们团队(团队名:Grid;集体投票得出,取意当时热门的网格计算技术)还获得了项目的公开表扬,因为我们不但保证了高产出,而且还很好地探索了当时所知的各种敏捷实践(主要是XP范畴内的诸多实践,包括单元测试、TDD、结对编程等等)。如今我还依然记得在Greenwich会议室里,和李程远、孟贤、周函一起奋斗的场景,也记得我和ScrumMaster许俊因为测试自动化策略和Scrum做法而争得面红耳赤的样子,真是一段美好的时光。 能够在敏捷试点方面有好的成果,后来观察了很多其他组织实施敏捷之后,我才意识到,当年我们能够成功的关键在于我们有极其强大的支持团队。它包括, 业内专家:Craig Larman,Bas 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来块前,刚好够打车到公司往返的路费……

Tagged with:

Definition of Done & Acceptance Criteria or Conditions of Satisfaction

First let’s list all the terminologies, and the abbreviations I’ll use in this blog post: Definition of Done (DoD) Acceptance Criteria (AC), also called Confirmation, or Conditions of Satisfaction (CoS) (Here lets’ say AC = Confirmation = CoS, there may

敏捷中国2012大会北京站:后记

(If you’re not a Chinese reader, please directly go to the three SkyDrive links in the last 2 paragraphs, and you can share it with your Chinese friends or colleagues. Thanks!) 9月13-14日,北京京仪大酒店,2012年的敏捷中国大会北京站终于落下了帷幕。顶着执行副主席的头衔,我和袁店明主要负责搭建评委会以及keynote话题评审,虽然上海和深圳站尚不知道会如何处理,但至少北京站已顺利举行。 如果要问我参加大会的感受,其实我都不太讲得出来。第一天上午要主持全体大会,自己却没有多少时间能专心听Neal Ford、王洪超、Ritchard Markelz的演讲,忙着处理一些琐碎的事情,中途还抽时间见了几个网上交流却未曾见面的朋友。第一天下午也比较遗憾,说起来我都不记得为何没能去听演讲,反正印象中午餐后回到会场附近就被几个难得碰头的敏友们给拖了过去聊天,等到俺回过神来,第三个演讲都已经开始了。作为组织者,倒是比较诧异听到的一些参与者反馈,貌似分论坛二结束得特别早,其他两个论坛第三个演讲才刚开始,他们已经全部三个演讲结束,不知道原因何在。另一个遗憾是本打算去听听同事乔梁的演讲,结果赶过去发现是钱安川在演讲,原来他们交换了时间……又没能赶上感兴趣的话题…… 第二天,遗憾继续。我主持分论坛五,结果第一位讲师仝键(他的名字谁能发准音的话,语文真是学得不错了……)路上塞车,差不多晚到了10~15分钟,也没有足够的时间可以调试一下投影仪设备,还得更新他的材料到投影的电脑中,还好的是现场听众对话题本身还是很感兴趣,结束后一堆人围上来问问题。第二位讲师杜伟忠则在滔滔不绝中忘记了时间,还好随后就是午休+午餐,就算拖上一个小时也不会有太大影响。 第二天下午,我自己是第一个演讲,所以早早地吃完午饭还特地回房间稍事休息(可能太忙碌了,导致近段时间很疲倦)。这次的演讲不知道听众感受如何,我倒是对自己有些不太满意的地方:1,本来已经设想好各个部分介绍花多少时间,结果一开始讲就陷进去了,越讲越细,导致后来时间失去控制,本来打算45分钟结束的内容硬是用了一个小时(“敏捷教练之路”演讲材料下载);2,整个过程我自己也有录音,发现和王立杰相比,我的声音低沉很多,怎么就洪亮不起来呢?3,还是很胖…… 还比较欣慰的就是,演讲结束后,还是有好几位听众感兴趣过来问问题,跟一位挺漂亮的MM在会议室外聊了半天,针对他们公司的情况和问题(主要是在转向敏捷的过程中QA该何去何从)谈了一些我的看法和建议,然后就把当天下午的第二个演讲时间给错过了。再后来,就是被文老师和李忠利拖过去,等任发科抵达会场后,咱管理3.0译者聚会了……现场再跟姜信宝和程显峰一帮人瞎聊半天,就已经是大会结束了…… 不过倒也不遗憾,其实我觉得吧,在会议现场,听听演讲,有些许片段的思绪,然后再和新知旧识针对这些话题深入交流探讨,收获其实也很大。我倒并不期待从各位嘉宾的PPT中看到太多的信息,或者追求很多“干货”,更多的是在于我们自身的领悟。也许回头我可以再写一篇博客,讲讲参加大会时如何能有所收获。 末了,附上本次大会官方微博@AgileChina敏捷大会分享出来的讲师材料(部分,一些材料应讲师要求并未公开分享):微盘链接;我的SkyDrive链接。

Story Points & Hours: Jeff Sutherland’s View

Jeff replied to one question on Quora regarding Story Point & Hour estimation: Agile Development: Agile Development: how do I estimate story points, and how do I decouple them from hours? Basically he mentioned 3 research reports, which reported similar

Quote Ron Jeffries on Velocity

In previous post “Velocity is Story Points per Sprint?”I mentioned that velocity could be the accumulated story count / accumulated sprint, and I saw it from Ron’s reply in one scrumdevelopment group discussion. Unfortunately I didn’t save that post, and

Velocity is Story Points per Sprint?

One colleague was complaining about the Velocity practice, one part is the definition of Velocity, he says: In Scrum, we define velocity as the average of the story points finished by the team in the last “x” sprints. Well, I

Scrum/Agile Starter Kit

If you’re new to Scrum, and wants to know how you can start, this is the post for you. Please kindly comment on this post to provide your thoughts and your recommendations on whatever resources helped you on your journey

总结Scrum实施经验时勿犯归因错误的毛病

说明:本博文最早发布于本人的新浪博客。 最近和@陈加兴以及@孟晓林Ralph交流时,感到比较痛苦,和@拯救与逍遥等朋友的交流则感觉顺畅很多。似乎大家在讨论同一个东西,但又总觉得似乎讨论不到一个点上去,有点各说各话的感觉,非常不给力。也许彼此都觉得对方的逻辑有些许奇怪、不对劲的感觉,却说不出来,也评不下去。今天因为@孟晓林Ralph的一条微博,大家讨论很给力,偏题也很壮观。内容如下“对于一把菜刀而言,它有其特定的属性,而这些属性决定了它适用于什么,可以干什么和不能干什么等;它只是一个被应用者,它被用去干什么完全是握着它的那个人决定的;它代表的是一种解决问题的思路,只有理解了这个思路,才可能把它用的更好。敏捷这个玩意和菜刀有啥区别么?”。其实,很多东西都具备着不同的身份,例如Scrum。 Scrum是一种敏捷软件开发方法,特色在于它是一个框架,具体的骨肉需要额外填充。 Scrum框架是一个工具,用来指导企业、组织的软件开发工作(或任何工作),它有自己的使用手册(参考其定义),但使用者可以根据需要选择自己的使用方式。 Scrum还是一系列认证的品牌,还被当做是光鲜的外套,也被当做是发泄愤怒的靶子,等等。 另外,我自己写东西的风格是希望内容是严谨的,有逻辑性,不犯归因错误的毛病。但目前许多总结Scrum或敏捷实施经验的文章,或多或少,或有意或无意的,都有很多不准确的地方。 实践出真知。没错,Scrum就是从实践中总结出来的,但是再用回到实际环境中使用时,其效果不见得会等同于其来源的那些实践。 找准问题根源。Scrum或敏捷实施失败会有很多原因,将它归咎于任何单一的因素都是不严谨的态度,不管是企业自身环境还是作为工具的Scrum或其他软件开发方式。 传达信息最好专业点。我不太喜欢写哗众取宠的文章,也许过分了点,但我认为任何人都不应该写这样的文章。如果我要总结Scrum实施的经验,我就不会简单的说“Scrum是狗屁”或者“Scrum万岁”。私下的情感发泄需要,但是博客或文章或微博的受众太广泛,而平面文字的理解总是存在被误读的可能,所以需要小心。 接下来我们看看讨论中具体的一些细节(申明:我没有任何攻击他人的意向,同样的错误我自己也会犯,只是拿出来当做例子分析而已,请谅解。)以下文字为节选,为避免误解,请阅读完整的讨论记录,点击如下链接:http://weibo.com/1794616154/eACaMoVgZUP。 陈加兴:不用敏捷我们也能把项目做好,就跟不用某些价值观洗脑我们依然能够做到相互信任与尊重一样。【个人意见】其实“相互信任与尊重”不就是价值观吗?敏捷明确地提及并推崇了一些价值观,但并不是说除了敏捷就没有别的方法论或是啥的提倡这些价值观了。敏捷的特点无非是说,看吧,我自己秉持一些价值观,为了秉持这些价值观,在面临某些选择的时候,我需要用一些原则来指导自己做判断,而这些原则会引导我走向那些符合自身价值观的选择。 孟晓林Ralph:那么请教一下,敏捷所关注的信任、尊重这类“真正重要的地方”的原因是什么呢?难道其他的项目管理方式就不是以信任和尊重为基础和前提条件的么?难道以为需要信任和尊重就要忽视自身的责任么?【个人意见】看到孟兄这条评论时我顿时觉得血液沸腾心跳加速,同样是问号,这三个问题让我非常直接地就认定为是“反问句”,而且感受到一种咄咄逼人的气势,非常难受。其中的第2和第3个问题犯了二分法(binary)的错误。第二个问题潜在的意思是(当然也可能是我误会了),孟兄认为有人或者我在指责其他项目管理方式不以信任和尊重为基础和前提条件,首先就得说我压根没有这个意思,也没有任何地方说过这句话,如果我脾气不好,可能就直接翻脸了,毕竟这有点泼脏水的嫌疑;其次孟兄可能觉得我们说敏捷提倡信任和尊重就意味着别的方法不提倡,这绝对是先入为主的二分法作祟。第三个问题,至少我从来没说过需要信任和尊重就要忽视自身的责任,再没有引用我的具体话语的情况下,反问我是否表达了某个意思,这样的形式不礼貌。而且,孟兄的话语中有把信任尊重和自身责任放在对立面的嫌疑。 陈加兴: 核心要表达的确实有些不清,主要是两点:1.Scrum所关注的有些偏离技术本身,如任务领用中设计阶段没有清晰划出来;2.它所倡导的“价值观”需要更 高心智水平才能真正实践。【个人意见】第一点就显示出对Scrum的误解,因为Scrum自身(请参考Scrum Alliance上的定义)就是一个框架,我的总结是它主要关注项目、组织(人)、事务的管理,而不是具体细节的操作。所以指责它偏离技术本身,这就是个伪命题。第二点,价值观是没有前提的,秉持某种价值观就意味着你要克服现实世界中的困难去做到,而不是意味着要让你的价值观去吻合现实世界。 孟晓林Ralph:呵呵。信任和尊重同样需要前提。【个人意见】同上,我并不认为信任和尊重需要前提。我很难理解这样的观点,这并不符合逻辑。如果你认为对方需要满足某个前提你才能信任,那么在对方满足前提的过程中,你究竟是在信任人家呢还是不信任人家呢?我认为它们需要的是后续观察而已,信任就像是授权,对方靠谱,就多信任多放手一些;对方能力有限或不太靠谱,那么降低点期待,自己多留意多照顾。信任有度,无前提。 孟晓林Ralph:我自认为我的想法很简单,一个事情不是因为某点好他就好,某点不好他就不好,而具体的环境决定了我们最重要的任务到底是什么。【个人意见】这有点唯现实论(我自己造的词,不晓得准不准)的感觉。其实“具体”和“最重要”就是一个很大的话题。而Scrum或者说敏捷就是明确指出了“最重要”的目标,例如“通过持续不断地及早交付有价值的软件使客户满意”,而把具体留给了实施者或实施组织自己,根据企业的具体情况,制定出达成目标的操作方案。 孟晓林Ralph:我认为从概念的角度去解析概念,如若用事实去证明来的稳妥。【个人意见】我非常想解释清楚我对这个观点的看法,能力有限,希望能讲清楚。正所谓很多时候眼见都不为实,更不要说看待事实的角度不同,总结也是很不相同。我主张对于概念的解析应引用其原始的定义,而对于实际操作中的问题,则要分割概念本身以及概念的具体实现,从而RCA(Root Cause Analysis)才不会有失偏颇。如若归因错误,便会证明出一个不同的甚至是错误的观点,其危险性在于通常会引导人把有限的注意力放在错误的地方,浪费掉有限的精力、财力、物力去改进。要Correct RIGHT Thing,必须要先Identify RIGHT Root-Cause。 本文并没有讲解一个知识点或知识体系,是为了我自己可以比较集中的、系统些回答讨论中的一些焦点,如有任何异议或不理解,请通过微博或博客评论和我联系。

CSM Training by Kane Mar (21~22 April 2010)

After the Shanghai Scrum Gathering 2010, I went to Chengdu helpping Outsofting on CSM training by Kane Mar. Kane is a Certified Scrum Trainer, he argued combining Scrum and XP with Ken Schwaber at 2001, you can find more information

I Ran Out of Silver Bullets, Now What? @ Shanghai Scrum Gathering

This is my presentation “I Ran Out of Silver Bullters, Now What?” at Shanghai Scrum Gathering 2010. In this presentation, I talked about symptoms applying Scrum. No doubts, beginners or junior practioners will definitely meet those in their Scrum implementation.

Top