谁应对软件质量负责?

  原文地址: Who Owns Quality? 作者:Alan Page, 微软卓越测试工程总监,How We Test Software at Microsoft (中文翻译为《微软的软件测试之道》)一书的作者之一。 翻译:樊聪、林俊彦        应Adam Goucher的要求,再贴一篇《微软的软件测试之道》的文摘。顺便说一句,Adam写了一篇关于《微软的软件测试之道》的书评, 但Linda Wilkinson的书评以标题胜出(译者注:Linda比Adam早用了同样的书评标题)。        这是第16章的一部分,有关于质量的。我对这部分内容深信不疑,也希望能够听到你的观点。        多年前,当我提出“谁应对质量负责”这个问题的时候,得到的答案几乎都是“测试团队应该对质量负责”。现在我再问这个问题,答案通常是“每个人都应该对质量负责”。有些人或许觉得这是个不错的答案,然而软件工程研究所(SEI)的W.Mark Manduke曾这样写到“当质量被宣布成为每个人的责任时,就意味着没有人真正被指定为它负责,质量问题也就淹没在如今各种紧急情况之中,无人搭理了。”他得出结论:“当管理层真正确立了一个质量文化,每个人才会确确实实地对质量负责。” [1] 建立一个人人都真正对质量负责的体系需要一种质量文化。没有这样一种文化,所有团队都会在质量上作出牺牲。开发团队可能会为了节约时间而省略代码审查;项目管理团队可能会在需求规格说明书上偷工减料,或者对“完成”的定义敷衍了事;而测试团队可能在开发周期里更改他们对测试通过率和覆盖率的目标。不管在建立质量保证流程上花多少精力,工程团队总是习惯于在质量实施过程中制造一些例外,以便在最后期限到来时完成产品或者达成其他目的。为了赶上产品发布日或其它期限而灵活变通固然重要,但质量常常也因为没有明确的负责人而受到损害。        整个测试团队可能负责质量保证的各个方面,但是在倡导或者影响整个组织接受质量文化上,他们不太会是最好人选。高级经理可以提倡重视质量,但他们有充分理由将重心放在团队管理、产品发布和业务运作上。虽然他们可能也把质量目标放在心上,却很难成为质量文化的倡导者。在大部分团队中,管理领导团队(通常是开发、测试和项目管理部门的领导者)承担着对质量负责的重任。这些部门领导负责并推动团队的软件工程,并且站在团队首要位置上评估和实施基于质量的工程实践。不幸的是,高质量软件和高质量软件开发工程实践看上去很少是他们在任何产品开发周期中的所关心的主要问题。        有高级管理团队对质量文化的支持还不够。在质量文化中,每位员工都能对质量有影响。在制造业中,很多最重要的质量改进都来自工人的建议。比如在汽车制造业,日本的汽车工人平均一年提出28个建议,而其中80%都被采纳了[2]。        理想情况下,微软中所有专业工程师都在提出如何提高产品质量的建议。一个没有质量文化的团队,这些建议非常少,其中得到采纳的更是凤毛麟角。对质量文化的淡漠也将影响团队成员在应对工作中其他挑战上的激情与投入。     [1] STQE Magazine. Nov/Dec 2003 (Vol. 5, Issue 6) [2] The Visionary Leader, Wall, Solum, and Sobul

0

如何提升工作中的影响力

上个月,微软女性员工协会上海分会举行了2010财年第一个以职业发展为主题的座谈会,邀请了六位高级经理与大家交流在工作中提高自身影响力的经验和建议。作为一位在微软相当成功的管理者,潘正磊女士结合自己在微软十多年的职业生涯,首先与上海员工分享了她对这一话题独到的见解。以下是潘正磊女士开场演讲的文字整理。        回到阔别了十几年的故乡——上海让我倍感兴奋,这个城市的蓬勃生命力让我倍感激动。培育人才同样是一件令人激动的事,尤其是为华裔员工、女性员工提供职业指导和咨询。过去几年,这一直是我在美国总部工作的一部分。我经常会为他们的努力而感动,也会因为他们的成功而骄傲,更让我颇感成就。很高兴,回到上海三个月后还能继续这样的工作。        今天,我们的主题是如何提高自身在工作中的影响力,我想用三句话来概括我对这个话题的一些思考。 知己知彼 Self Awareness & Interpersonal Awareness        进入到第一个话题“知己知彼”之前,我先分享一段担任Visual InterDev开发主管期间的经历。当时我们团队来了一位刚被提拔的开发经理,我和另几位开发主管直接向他汇报,自然我们都会与他有定期的1对1会议,沟通各自的工作进度。几乎每次当我陈述完一个问题,他都会迫不及待地提出他的解决方案。我当时的反应就是“我到这儿来不是因为我没有自己的解决方案,而是来告诉你我正在做些什么事情。”在我看来,这两者是完全不一样的。        在这之后很长的一段时间,他还是一直习惯性地建议我如何如何处理问题。通过平日的观察,我也发现他更喜欢花时间对技术和产品进行深度探讨,而非团队管理。于是几个月后,我找了一个机会跟他说,“我觉得你做软件架构师说不定会更有意思。”而他自己也觉得这个建议不错。几个星期后,他真的转去做架构师的工作,我们团队也迎来了一个新的开发经理。        我觉得这就是一个有关影响力的典型例子。毫无疑问,我不能决定我的老板到底是做开发经理还是架构师。我只是觉得他比较适合,并让他对自己的优势也有了一个全新的认识。与此同时,我也让其他的主管意识到他对架构师的工作更有热情。整个过程中在一定程度上体现了下属的一种影响力。        任何一位微软的高管,在做每一个重要决定前都会去听取相关人员的反馈和建议,以确保自己考虑了问题的方方面面。如果我们希望将自己的信息传达给这些决策者,当然需要找到那些他/她会听取意见的关键人物,通过他们来延伸我们的影响力。因此,当我们要向另一个人或另一个团队提出一个方案以完成某项工作,就要仔细考虑以下几个问题: 1) 这个方案能给对方带来什么帮助或好处?为什么对方需要花时间和精力考虑或参与我们的方案?这个方案对他们来说有多重要? 2) 我们是否找了一个合适的人来提出我们的方案?他/她是否能为他/她的团队做决定? 3) 对方是否充分了解我们的想法?我们是否提供了足够的信息? 4) 决策者是否充分了解我们的要求及问题的背景?        总之,要提高自身的影响力很重要的一点就是知己知彼,既要了解自己需要什么,更重要的,是要了解对方需要什么。 言行一致Credibility –Say What You Do; Do What You Say!        开始我们往往只能影响一些非常细小的事情,在这些细小的事情上获得成功后,我们的信誉会随之有小小的提升,继而可以影响稍微大一点的事情。随着我们个人信誉的不断提升,我们所能影响的范围也会越来越大。所以,在提升影响力的过程中,另一个重要因素就是个人信誉。        那么如何才能提高个人信誉呢?答案就是四个字:言行一致。所言即所行,所行即所言。不要多承诺、少兑现,也不要少承诺、多兑现。        为什么言行一致那么重要呢?原因就在于我们的个人信誉来自于我们以往工作中的表现。绝大多数的公司新人都是从零信誉开始的。不管我们在面试中的表现如何出色,不管面试官给我们多正面的评价,对我们所加入的团队来说,我们还是新人,我们的信誉还得从零开始积累。只有当我们具备高信誉时,比如在别人眼中我们是开发软件或测试软件方面的专家,才会有人主动花时间来倾听我们的建议和想法。        要提高我们在公司的信誉,第一步要树立我们在自己团队中的信誉,这和加入团队的时间、为团队做出的贡献、个人的职业背景等等有关。当我们还是个新手的时候,如果想对一个很大的项目提出建议,应该先和上司沟通。假如他/她欣赏我们的想法,他/她就会继续和他/她的上司沟通,通过上司来提出我们的建议。这是因为他们具有较高的个人信誉和更大的影响力。尽管最后不是我们自己直接提出建议,但是在这一过程中,我们如何层层扩大自己的影响力,或者促成某个项目的完成,是很值得思考的。 问题 不等于 解决方案 不等于 结果!Problem != Solution !=…

0

穿越成长:我在微软总部的丝绸之路(二)

穿越成长:我在微软总部的丝绸之路(一)   办公室的大门永远敞开        在上海工作久了,刚到总部的时候,拥有了想去找美国同事就能直接去他们办公室找的权利,还真是不适应!在总部工作最大的好处就是大多数同事随时在线或在办公室里,有邮件说不清的事情可以立刻当面讨论,让人心里特别踏实。而在上海的时候,常常是一封邮件过去要等一个晚上才能得到回复,如果碰巧有理解错误,得再一封信过去解释,来来回回地一个问题可能要几天才能解决。而在总部,可能解决同样的问题只需要一个小时!        很多同事的大门永远敞开着,随时就能过去请教问题或讨论问题。我也从中受益匪浅。面对面的交流,让我更深地感受到微软人的友好和亲切。有一次,我们遇到一个SharePoint问题,需要确认特定情况下的用户输入和期待的产品行为。几个邮件来回之后,我们意识到最有效的方法应该是见面讨论。于是当天我们就赶到了17号办公楼的SharePoint团队,坐进了一个测试人员的办公室,和他一同在电脑前仔细讨论了产品行为,一个小时后,问题解决了!我们击掌相庆!        另一次我印象很深的是去Team Foundation Server(TFS)团队的一名资深PM的办公室,在半小时内完成了我之前以为很艰巨的任务,也让我感受到微软信息渠道的通畅!在Developer Division(开发工具部),我们已广泛使用TFS来跟踪多种工作项,而每个工作项的模板是由TFS团队统一设计管理的。一次我们团队希望能在模板中添加一个域来记录每个功能的性能测试结果。这虽然是小小的要求,但是模板的改动将会影响到上千名开发工具部工程师的使用。于是,我先向产品组提交了这个要求,经同意后又提交给了整个Visual Studio大组,一番讨论之后得到批准,接下来就需要决定如何进行这个改动。就这样,我找到了TFS团队的PM。在他的办公室里,我们在电脑前仔细查看了TFS工作项现有的结构和已有的工作项的域,讨论了可能的添加和设计的方式,最后决定复用一个已有的域来满足我们的需求。半个小时之后,我刷新了TFS工作项,看到了新的域已经准备就绪!        开放的办公室文化,同事们的友善和帮助,让我很快适应了总部的工作节奏,也让我了解到一些看起来困难的事(尤其是在上海的话!)其实并没有那么难。   我在微软三年啦!        今年3月29日是我来微软三周年的纪念日。一早我就在办公室门口摆上了三磅的巧克力。这是微软的传统 —— 一年=一磅巧克力。路过的同事停下拿块巧克力,认识的不认识的,我们也顺便聊几句。很喜欢这样的传统。其实不仅是纪念日、生日、刚来微软的新人、产品里程碑的时候,大家都会在办公室门口摆上一些零食,所以很多时候能在走廊里找些吃的!即使是去到其他办公楼,在不相识的同事办公室门口也可以拿块糖,顺便打个招呼。        有时候大的产品里程碑时,还会有更大规模的庆祝Party。整个产品组聚到一起,有啤酒和各种饮料,还有薯片等零食,然后大家一起开心的玩Xbox 360的“吉他英雄”。看平时严肃的老板拿着麦克风吼着摇滚,大家都乐不可支。        还有一次,我们集体庆祝了St. Patrick’s Day ( “爱尔兰日”)。大家准备了许多绿色的道具,把每个人都打扮得“绿色洋溢”,又享受了一个放松的周五下午!:-)   硝烟纷飞的Ship-room        Ship-room是很有微软特色的会议之一。        当产品临近发布的时候,Ship-room便成立了,会议上会决定哪些缺陷会在这个版本中修复、哪些缺陷不修复,并审查整个项目的进度,确保产品能按时发布。参与者通常是Release Manager(产品发布经理)及每个功能团队的代表。临近发布的时候,气氛开始紧张,即使一个很小的改动,都可能引发连锁问题,进而影响产品的如期发布。因此Ship-room会议必须严格把关,确保只有极其必要的修复才能签入到产品代码中。另一方面,每个功能团队都希望能尽可能多得修复缺陷。因此Ship-room的会议时常硝烟纷飞。        进入询问阶段 (Ask Mode)以后,如果一个功能团队希望签入一个修复,则必须由一个代表将缺陷提交Ship-room审批,而这个代表最好有超强的抗压力,因为在这个会议上各种问题和不同意见会从四面八方狂轰滥炸过来。我在总部期间有幸来到这著名的“战场”,目睹各位代表们舌战群儒,深切地感受到了公司对产品质量的严格把关精神,也学习到了唯有从用户至上的角度出发才能在这场“战争”中取胜。衡量每一个缺陷的关键中的关键是,这个修复带给用户什么样的利益?如果一个修复无法为用户提供更好的体验,那么其它一切都免谈。代表们需要为每一个缺陷提供一个扎实的用户体验的场景,对用户有益的修复才有可能获得Ship-room开出的签入通行证。        目睹了Ship-room的“严苛”要求,深知获得Ship-room通行证的艰难,给了我很多的启示。现在,每做一个设计的决定时,每遇到一个问题时,我都会想起那些在Ship-room中被“子弹”攻击得体无完肤的代表们。一个个隐藏着的问题,都像一个不定时炸弹,随时发生。而炸得越晚,伤亡越惨,几乎没有补救的机会。让前线战士免受伤害的方法,就是及早发现并解决问题!   直面客户 – 你希望我们怎么做?        在总部期间,我还参加了好几次与客户面对面交流的活动。给我感受最深的一次莫过于3月的微软全球最有价值专家(MVP)峰会了。这个峰会聚集了全球MVP与微软开发团队直面互动。整整一个星期,开发团队向MVP们介绍各个正在开发的产品信息,其中很多信息都是未公开的。除此以外,MVP们也可以直接向开发团队提出他们对产品和技术的反馈和需求。与其它公开讲座不同,MVP峰会更像一场互动的讨论会。        峰会上,微软开发团队最常用的开场白就是“这些是我们正在考虑的新版本功能,你希望我们在其中怎么做选择?”有时,我们让MVP挑选他们希望我们做的优先级最高的三个功能;有时也用虚拟问题“如果你有100元,你会投资哪几个功能?”。但无论用哪种方式,我们都能从中获得许多宝贵的信息和意见。MVP们往往能提出很有见地的想法,也常常带给我们更多启发。这些反馈的意见都会成为我们产品设计的重要砝码,每做一个决定时,都会先问问自己“用户想要什么?”,再想想,用户会喜欢和赞同这个设计吗?如果这一关过不了,那么可能需要重新考虑了。   飞回上海        六个月的时光不短也不长,冬去春来,转眼六月了。我还意犹未尽之时,却要收拾行囊了。这次,我的大箱子里除了来时的生活用品,更是装满了沉甸甸的收获。学到了许多,却感觉还有更多的未知。六月的西雅图微风和熙,与来时的瑟瑟寒冬相比恍若隔世,而我,也仿佛经历了一次成长的穿越,在时空变换之间完成了一次历练。…

0

穿越成长:我在微软总部的丝绸之路(一)

      略过连绵的皑皑雪山,飞机徐徐停落在西雅图机场的那一刻,我知道我的生活将翻开崭新的一页。从未在上海以外的城市居住过的我,带着两个装满了生活用品的大箱子,我的兴奋和期待在西雅图潮湿的空气里蔓延开去。在这里,我为期六个月的丝绸之路即将展开。   我有很多师傅       尽管不是第一次来微软总部工作,却是第一次拥有挂有我铭牌的办公室。来之前,我师傅(Mentor)就为我安排好了办公室。和我同屋的是一个同组的PM,一个开朗的印度小伙子。有些人喜欢独享办公室的私密,我倒是很开心有人可以一起工作和聊天。一个人呆在屋子里未免有点孤单!       师傅的办公室里有一张特别宽敞舒适的大沙发。洒满阳光的午后,靠着柔软的沙发,每周在师傅的办公室里和他的一对一谈话都是我最享受的时光。我的师傅是一位资深项目经理(PM)主管,他参与过许多产品的设计开发,有强烈的客户至上的理念,对客户需求和市场情况都有深刻的洞察。可以说,他绝对是我的偶像(Role Model)!每次和他聊天, 我都能深深体会以用户需求为本的设计理念,以及他对于每个设计细节的关注。尽管我们不在同一个功能团队里,但他总能对我正在设计的功能提出好的建议和想法,并提醒我关注一些还没考虑到的情况,这也促使我对自己的每个设计都反复斟酌、精益求精。阳光、沙发、和师傅的谈话,这一场景已如同定格的影像留在我心里。如今我已回到上海,但每次设计功能或与客户交流时,我都会先问问自己,如果是师傅的话,他会怎么做、怎么说?       之前,我和师傅的谈话都通过电话沟通,有时候会错过许多表情和肢体的语言。到了美国之后,面对面交流的机会让我更加感受到沟通不仅是有益的,也应该是非常令人享受的!       除了师傅,我还与其他功能团队的许多资深和高级PM主管进行了交流,这都得益于我在上海的经理为我牵线搭桥,让我充分利用在美国的机会多学习、多交流。因为身处不同团队的关系,我常常跑到其他办公楼里去他们的办公室聊天,这也让我有机会顺便参观了其他团队的走廊“风景”。例如,在TFS团队的走廊里贴满了大大小小的图表和照片,有的是团队进度表,有的展示Team Foundation Server(TFS)使用情况,还有团队外出活动的有趣照片,更有记录着客户对TFS需求的列表!相信团队成员每次经过这个走廊都会提醒自己客户需要什么,也会为自己的工作而自豪!       和这些PM主管的聊天同样令我受益匪浅。我们大约每两到三周见一次面,聊的内容比较随意。有时我会给他们讲我正在做的产品/功能,而几乎每次我都能从中得到额外的收获。虽然我们在进行不同产品的设计开发,但他们往往结合以往经验或他们的产品角度给出全新的建议和看法!这一过程使我学习到如何从不同的角度来看问题,也令我再次感受到:对不熟悉的产品,也能提出设计的思路和想法,看来PM对产品的设计完全出自本能!   我需要三头六臂       到了美国之后,我有机会参与到多个产品项目中。合理安排好多个同时进行项目的工作,是我在上海工作中没有尝试过的。有时候,我真觉得自己需要三头六臂才能把事情做完!然而,多任务并行的能力恰恰是PM需要具备的关键素质,所以我很珍惜这难得的历练机会。       我当时(同时)参与的项目有这样几个 – Pro Tools 功能在Visual Studio 2010 Beta1里的 发布 一个Pro Tools的设计变更(Design Change Request, DCR) – 与SQL Server团队合作 RIA Services工具 (实时提供智能标签功能) – 与RIA Services团队合作 (现已改名WCF Services) SharePoint 扩展开发工具 – 与SharePoint团队Developer Platform Evangelist合作      …

0

欢迎访问Spec Explorer中文博客 http://blogs.msdn.com/sechina/

    Spec Explorer是微软发布的一款与Visual Studio紧密整合的基于模型测试的工具。用户可以通过Spec Explorer对一个软件系统的期望行为进行建模,并自动生成能够在Visual Studio的测试框架下运行的测试代码。模型可以用当前主流的程序设计语言C#开发,然后通过Cord语言脚本对模型进行配置和裁剪。     我们用Spec Explorer这个名字是因为该工具可以自动探索规格说明(即Specification,简称Spec)的所有潜在行为,并将其行为模型表示为状态机。一次探索的输出有可能非常巨大,所以Spec Explorer提供了Cord语言对输出进行裁剪,并选出测试中真正关心的场景。如果你曾经接触过其他使用状态机的工具,你会发现Spec Explorer能够高效的解决状态爆炸的问题。     Spec Explorer 最初来自于微软研究院的科研项目,现已发展成为基于模型测试的工具族中最新和最强大的工具。Spec Explorer由属于微软中国研发集团服务器与开发工具事业部的团队和微软总部团队共同进行研发和技术支持。   中国团队 美国团队       Spec Explorer已经被大量用于微软内部技术团队的测试,并已在Windows协议测试工程(超过两百工程师参与并协同工作)中取得了巨大成功。     Spec Explorer 2010在近期已经通过MSDN DevLabs对外发布。我们将使用这个Spec Explorer中文博客发表技术文章,与中国的开发人员们分享心得体会,希望大家能够下载并试用Spec Explorer,并通过MSDN论坛或者博客给予反馈,帮助我们更好的改进产品。                                                                                                                                                                                                                           李想    

1

释放热情,跃动越精彩

      2009跃动越精彩微软中国研发集团(CRD)上海运动会在啦啦队热情洋溢地开场舞中“火辣辣”地拉开序幕。我们的美女工程师啦啦队员们一出场,就引爆了现场第一波“high”的高潮。                   接下来是我们的 Walter Wong为本次运动会致开幕词。那天下午的阳光很灿烂,而我们的Wong总笑得比阳光更灿烂哈!     本次运动会是在紫竹办公室附近的华师大体育场馆内举行,应该算是微软服务器与开发工具事业部中国团队(STB China)的主场了,那就让我们一起看看东道主的选手们发挥得如何吧!     首先进行的是4*100接力跑。赛场上选手们奋力前冲的状态是否让你想起羽泉的那首《奔跑》?“随风奔跑自由是方向,随风飞翔有梦作翅膀。。。”       举办这次运动会是希望运动给大家的繁忙工作增添一份轻松快乐。 看看上面的这张照片,连摔跤都摔得那么开心,看来大家确实感受到“跃动”带来的快乐了!      这两张照片的名字叫“飒爽英姿跳沙坑”你同意不?^_<      拔河比赛应该算那天下午所有比赛中最神奇的一场比赛了。第一局占据左边比赛场地的队伍败下阵来。第二局交换场地后轻而易举反败为胜,扳回一局。第三局再次回到左边场地又一次败给了右边场地的参赛队。难道右边的场地有神人助阵?这场比赛真是应了古人“天时地利人和”一说啊!     游泳比赛是最清凉的项目了,但是报名参赛的选手却少得可怜,只有STB China的6位帅小伙参加,毫无悬念最后奖项也都被东道主包揽了。乘此机会为明年的游泳比赛拉拉人气。是不是被这绿盈盈的池水吸引了呢?心动不如行动,明年的游泳比赛期待更多人的加入哦!     我们两位老大的击球姿势倒是不错,那战绩如何呢?Prakash(右)说”Almost”。好吧,重在参与嘛!     羽毛球比赛场上各参赛队打得热火朝天的气氛带动了场下的观众,赛后很多观众也拿起球怕过了把瘾。     什么运动看着让人揪心?足球!什么运动更让人揪心?中国足球!!看了咱STB China哥们儿的足球比赛,你那颗被咱国足浇得拔凉拔凉的心是否又暖起来了呢?     摄影师抓拍的这几个瞬间太赞了!!!改明儿《灌篮高手》要拍真人版的时候绝对应该到我们这儿来选主角。瞧瞧,咱这三分球投得多帅气啊,不活脱三井寿的翻版嘛!还有底下的这两位兄弟带球上篮多cool啊!可貌似离篮筐还有不小的距离哦,这,这,这跨得过去吗?!@,@     经过一番拼搏,足球比赛和篮球比赛的冠军奖杯都花落STB China家。两个冠军参赛队纷纷留影纪念(上图为篮球队,下图为足球队)。在颁奖典礼热烈的气氛中,本次“跃动越精彩”运动会落下了帷幕。     那个阳光灿烂的午后我们一起尽情释放热情,收获快乐,相信一定会在我们大家心中留下一段美好的回忆!                                                                                                                          马洁芸

0

微软产品开发中的“战争与和平”

    冲突是微软开发工作时的常态,每个微软新产品的孕育过程概莫能外地充斥着质疑、抗争、苦闷、忐忑……理念的交击、智慧的冲撞让软件开发的各个阶段都弥漫着硝烟,直至产品发布,然后又要迈入下一个循环。对于微软工程师们来说,这样的经历就仿佛是一次次痛苦但不乏惊喜的涅槃。     这篇博客记录了微软Windows Server 2008 R2*中国团队的一些真实经历与感悟,例如“暗藏杀机”的季度性产品评审会议;微软工程师如何“向用户学习”;软件开发过程中只有对错、没有“权威”……     *Windows Server 2008 R2是与Windows 7同步研发、同时面世的微软新一代服务器操作系统。     Windows Server 2008 R2今天在北京正式发布,由我们负责开发的Active Directory Administrative Center(活动目录管理中心,以下简称“ADAC”)也将真正开始接受IT管理员们的检验。     为迎接这一天,我们准备了非同寻常的一年半。有过重重压力,有过混乱无序,甚至怀疑过这是否是“不可能完成的任务”。而当Windows Server 2008 R2预发布版本问市后,美国权威IT技术信息杂志《Windows IT Po》在一篇新功能点评文章中,将ADAC评价为最受关注新功能第一名,这让我们高兴了好一阵子——我们收获的不仅仅是一件令团队成员自豪的产品,更重要的是,我们证明了中国研发团队的能力。     在我们在踏上新的征程之时,谨以三个幕后故事来记录我们的努力和过往那些“硝烟弥漫”的日子。   测试主管Jun的故事:从虚无缥缈到事实     Windows Server 2008 R2即将发布第一个测试版时,Jun正在美国参加一个季度性产品评审会议。当时,他的测试团队因为对ADAC采取了与美国不一样的测试策略,在产品开发前期更激进地寻找bug,最后挖出了538个,“荣登”活动目录整个产品线所有新旧产品bug数榜首,并几乎与“活动目录”其他产品的总bug量相当——作为团队代表,如果Jun无法让管理层信服,整个中国开发团队能够在Windows Server 2008 R2发布前解决这些问题,那么这个项目很可能会被砍掉,这意味着十多位工程师一年多的努力将化为泡影。     当Jun不厌其烦地阐述、分析,并反复强调ADAC一定能够和Windows Server 2008 R2一起发布的时候,“活动目录”产品线的总经理,一位白胡子老者(真的很像圣诞老人)笑眯眯地转过头说:“你知道在英语中我如何来描述你的结论(可以和Windows Server 2008 R2 一起发布)吗?我比较喜欢这个单词:illusion (虚无缥缈)”。     那一刻,虽然Jun嘴上依然挂着笑容,但是阵阵冷汗已在后背泛起… …在强迫自己冷静之后,Jun回答道:“我们看到的不只是静态的数据,还是一个发展的趋势,基于bug数量递减的速度和趋势,我依然有信心,我们能够完成这一产品。”     不知道是被中国团队的执着所打动,还是真的相信了Jun的“趋势论”,总之“圣诞老人”在会后并未将这个项目从Windows…

4

11月6日、7日北京,我们TechEd见

      2009年微软技术大会(TechEd)中国下周就将在北京召开了,服务器与开发工具事业部的中国研发团队将派出31位项目经理、软件设计开发工程师和软件测试开发工程,与中国程序开发者和IT从业人员分享我们最新的产品开发。以下是我们负责的课程、动手实验室和专家交流区列表,希望能在大会现场与大家面对面交流。 针对程序开发者: 时间 课程标题 主讲人 课程简介 11/6 9:25-11:40 WUX301 用Silverlight进行高效的RIA商务应用开发 郭晓颖 类别:互联网新技术 本讲座将为您介绍用Silverlight 3构建商务应用的传统体验以及.NET RIA Services为基于Silverlight及ASP.NET的商业应用开发注入的新活力。 11/6 9:25-11:40 DEV201 在大型研发团队中玩转Agile — 微软研发团队敏捷开发最佳实践(英文课程) Ramesh Rajagopal 钟鸣 类别:开发工具与技术 本讲座将为您介绍微软的Visual Studio研发团队如何将敏捷方法具体应用于实际的软件开发,并且带来巨大效益的经验分享。 11/6 14:25-16:45 ARC321 多核时代: 并行计算进军主流 朱金生 类别:软件架构及云计算 本讲座将为您介绍微软正探索发掘的一种全新方法,让开发人员通过并行计算来充分利用多核性能,从而开发出在现代多核系统上运行的极具吸引力的全新用户体验。 11/6 15:50-17:00 DEV311 用Visual Studio 2010构建SharePoint 2010应用实战体验 陆榕 类别:开发工具与技术 本讲座将带您全面领略将在Visual Studio 2010中发布的SharePoint 开发工具,包括全新的工程和项目模板等。 11/6 17:15-18:15 BAP303 BizTalk Server…

0

Win 7、关雎以及那些成长的岁月

    Win 7是我所用过的操作系统中最好的。靓丽的界面、优秀的软硬件兼容性、高效的运行性能、体贴合理的安全设计等诸多新特性,无一不昭示着Win 7在操作系统发展史上里程碑式的地位。对我和我的同事而言,Win 7的意义不仅于此,我们更是她两个核心组件MSXML和WDAC的幕后推手,一手包办了从功能设计、开发到测试的全部工作。     作为Win 7重要的核心组件,MSXML和WDAC支持着包括Office、IE、Windows Live、SQL Server等诸多微软产品的运行,它们的稳定性、安全性和性能对于整个操作系统 重要性是不言而喻的。     技术的演变,有些是渐进的,有些则是颠覆性的。比如,集成电路上的晶体管数目依照摩尔定律发展,纵然指数级增长速度很快,但是依然有规律可循,仍然属于渐进式的演变;晶体管取代电子管、集成电路取代晶体管,却是颠覆性的技术变革。多核(Multi-Core)以及虚拟技术(Virtualization)就是这样颠覆性的技术,慢慢影响着信息产业的大趋势,为硬件制造商带来了前所未有的机遇。这两项技术将显著改善设备性能,并通过硬件集中化来降低成本,最终在整个产品生命周期内取得最佳的收益,而且也符合如今节能环保的趋势。然而,这对于我们Win 7开发者而言却是一个不小的挑战。     编程模型的改进,以及硬件条件的变更,使得原来可以忽略不计的小概率事故频繁发生。更令人苦闷的是,但凡这样的事故发生就一定是随机事件,重现问题本身不容易,追踪并确认原因困难,修复它更是难上加难了。在计算机教科书上极其普通的一行源代码,在新的硬件环境下就可能成为麻烦制造者——谁会想到就是这样不起眼的源代码,变成了难缠问题的罪魁祸首?并且,一再地不请自来。很多人都把它们叫做臭虫,对我们这群倜傥的年轻工程师而言,既来之则安之嘛。凭借以提高客户体验为己任的责任心和恒心,仔细研读汇编代码,多方查询资料,经过多少个日日夜夜,就差没去烧香拜佛,一个顿悟,突然圆满解决了问题。恰似《关雎》中所描述的一幕:“参差荇菜,左右流之;窈窕淑女,寤寐求之; 求之不得,寤寐思服;悠哉悠哉,辗转反侧……”     在开发工程师们“辗转反侧”的同时,测试开发工程师们也开始了他们“悠哉悠哉”的忙碌。这两个组件在微软操作系统中都有着近十年的历史,代码随着产品的不断变迁,也越来越复杂。为确保测试的有效性并排除干扰信息,我们一边编写新测试用例,一边对原先的测试用例进行大量修订。同时,为了加快测试迭代周期,尽快发现产品中存在的缺陷,我们对原有的测试流程进行了大量优化,整个测试周期从三天降低到一天,让缺陷无所遁形,有效地保证了Windows7的开发进度产品质量。     或许许多用户们对Vista的认知就是硬件配置要求高、性能差。实际上,在高配置硬件上的表现,Vista超过了Windows XP,表现欠佳的往往是低配置机型。当然,用户的需求永远是最重要的, Win 7能否在入门级硬件环境下轻松运行,便也成为用户满意与否的关键指标之一。由于MSXML和WDAC在Win 7中的广泛应用,我们团队自然而然上了性能优化部门的重点关注名单。平均微软年龄才一年半的我们,与美国那些资深工程师相比,无疑在技术上有着不小的差距。虽然也研习过各个操作系统,在一些原理、细节上,我们还是有许多疑惑。然而勤能补拙,深奥的原理并不能阻挡我们渴求完美,但凡遇到不明白的地方,记下笔记,在与美国同事紧密交流的间隙,彻底把问题弄懂并融会贯通为止。这样,在下一次会议中,我们就又能与那些资深工程师们“谈笑风生”了。最终,我们完成了对代码近乎逐行地优化,降低了对其他组件的耦合,减少了对系统内存资源的占用。Win 7能够运行如飞,其中有我们的一份辛劳。     虽然我们负责的两个组件没有靓丽的用户界面,永远只在后台默默支持Win 7以及诸多应用程序的高效运行,不过,让用户欣喜于这款最时髦、最迅捷的操作系统,就是对我们最大的回报。     最后,让我用Fort Minor的Remember the Name来总结这段与Win7一同成长的岁月: It’s just ten percent luck Twenty percent skill Fifteen percent concentrated power of will Fifty percent pleasure Five percent pain And…

0

微软“资深”实习生解密实习通行证

    微软不少Title前都加上Senior来表示这位员工的资深,比如 Senior Vice President, Senior SDE, Senior Test Manager。按照这个逻辑,如果在Intern前加上Senior不就是资深实习生?!     最近,我有机会独家采访了四位已在微软中国研发集团服务器与开发工具事业部 (以下简称STB China)实习半年以上的同学,与正在准备投简历找工作或者实习机会的同学分享他们一些经验。 Qi:计算机应用技术专业研三学生。来STB China实习已有13个月了,参与安全产品的开发。通过同学推荐知道实习生招聘,在www.joinms.com上递交简历,一轮电面,三轮面试后拿到offer。 Lei:通信与信息系统专业研一学生,已在Visual Studio实习半年多,SDET(即软件开发测试工程师)实习生。通过学校BBS知道实习生招聘,将自己的简历投寄到BBS上公布的邮箱,www.joinms.com上递交简历,一轮电面,三轮面试后拿到offer。 Wen:电子工程研二学生。在高性能计算团队担任项目经理已有7个月了。一直以来就知道微软有实习生计划,通过实习同学递交简历,经过一轮电面和四轮面试(包括“午餐面试”)拿到offer。 Terry:计算机应用技术专业研二学生,已实习两年,不久前从Lab(实验室)转学至User Experience Design(用户体验设计),算得上是STB China“骨灰级”senior intern。在校园宣讲会上递交简历,后经同学推荐,经过四轮面试拿到offer。 1. 寻找实习机会时,你会有哪些方面的考量? Wen: 俗话说,女怕嫁错郎,男怕入错行。所以我先确定自己想要从事的行业(narrow down the industry)。因为一个人一旦踏入职场以后,可能在公司之间跳来跳去,但是要在行业之间跳来跳去是件非常困难的事情。基本上你进入这个行业,以后就可能一直在这个行业发展,最多跳到相关行业。所以一开始找实习的时候,进入什么行业要想好,可以选择和专业相关的行业,可以选择自己感兴趣的行业,也可以选择那种不限专业的行业,比如咨询、投资业。 2. 面试时,你觉得自己哪方面的能力最吸引微软面试官? Lei:面试官通过一个面试除了看你现有的能力外,更看重的是你有没有可发展的潜力。我面试的时候,一个工程师让我写code,他都没有让我写完就说“Okay”,“Enough”,“从你写得这个code里我看出来你有写code的功底”。然后让我写test case。写好后他说“从你写得这个test case中我看出你很有逻辑性”。 3. 微软是否给实习生提供专门的培训? Lei:我觉得自己运气很好,赶上了两个给正式员工的培训,一个叫“Engineering at Microsoft”,另一个是给新进测试开发工程师的培训。 “Engineering at Microsoft”培训上一个发言者说的话给我留下深刻印象。他说,“你在这个地方肯定有很多东西是不会的,你肯定要问别人。有两个极端,一个是‘always ask’,一个是‘never ask’, 两个极端都不可取。”一开始在我只知道10%的情况下,我连方向都还没有,请人指个方向。得到了大方向以后自己查资料学习,这样等到了50%的时候再请教一下,等到了最后差不多的时候再跟人家确认一下。 另外,微软奉行的是“授人以鱼不如授人以渔”,导师或是同事一般不会告诉你看什么具体资料,而是告诉你可以通过哪几个网站获得你需要的信息。 在另一个给新进软件测试开发工程师的培训上,Adam说得话也让我印象深刻:“你们现在在这里,不是因为你们现在多么行,而是因为微软觉得你们以后会很行”, “Someone knows nothing, no one knows…

0