服务世界开发未来 : 团队故事

态度决定深度——写在惜别STB中国团队之际

STB China Blog — Mon, 29 Jun 2009 03:59:00 GMT

两天后，我将离开微软中国研发集团服务器与开发工具事业部（以下简称STB中国），但我不会走得太远——新的部门是在北京的微软大中华区开发工具及平台事业部。作为STB中国团队的创建者之一，做出这个决定对我来说并不容易；不过我很肯定，经过多年的磨练和砥砺，STB中国团队今天已经站在了一个更高的平台上。所以，对这个创新机构的未来，我充满了信心。

2005年初，STB中国在上海成立。这几年里，我们和华东地区的产业伙伴紧密合作、不断向新的目标发起冲锋。在这里，我想借助我们的博客，谈谈过去四年多来我的一些粗浅感受——以及这个不断成长的团队是多么让我自豪。

在中国设立服务器与开发工具研发团队的构想萌生于2004年。在总部的大力支持下，我从雷德蒙返回故乡上海，组建创业团队、确立发展目标、锁定研发方向。几年过去了，回头看看，我深刻地感受到，跨国企业本土化研发的深度完全是取决于“态度”——客观地说，无论在哪个行业，你都很难找到这样一家公司，她是如此渴望在经营、管理、研发、合作等各个方面都深深融入中国本土，并梦想着成为中国IT产业的一部分。她就是微软。

在微软，你几乎看不到那种大多数跨国公司“通行”的、任用不懂中文的外籍高管的情况；更重要的，在许多全球性企业都以简单的项目外包和产品汉化作为其在中国从事本土化研发的重大进展的背景下，微软却真正地做到了把中国视为创新基地，做到了资源最大化、团队本地化、研发核心化、合作多元化和产品定制化。

今天，微软中国研发集团的北京、上海和深圳团队都已成为微软全球研发体系和中国自主创新事业的重要链环。

创新实力和产业影响力的持续增长无疑是令人兴奋的——以我身处的STB中国团队来说，在过去的一年里，我们便迎来了一个个值得骄傲的瞬间。例如，去年春季发布的微软三大企业级软件产品就是我们与STB世界各地团队共同奋斗的成果。之后，我们又陆续为包括微软第二代高性能计算产品、最新的Azure云计算平台在内的多项技术和产品研发做出了重大贡献。再如，去年问世的中国第一台百万亿次超级计算机曙光5000A正是我们与本土伙伴并肩作战的结晶——去年夏天，我们和曙光的团队紧密协作，最终“交出了一份满意的答卷”、“创造了中国高性能计算的历史”——不少朋友可能不清楚，曙光5000A有两个很有趣的“唯一”，首先，它是当时全球超级计算机TOP 10中唯一的非美国研发的产品；其二，它还是十强机中唯一一款采用Windows HPC Server 2008的高性能计算平台。

“扎根中国”，我们希望把这个承诺落到实处。无论是开发工程师、测试工程师、项目经理、架构师、甚至管理者，不知道客户最终想要的是什么，我们永远不可能做出能为客户产生价值的产品。因此，除研发工作外，STB中国团队还积极通过各种渠道与中国本地客户和合作伙伴建立联系，在微软中文技术论坛上回答问题，在技术大会上演讲。

打难打的仗才能锻炼好队伍 —— 正因如此，在团队建立之初，我们就将研发方向锁定在对公司具有战略意义、对全球用户而言至关重要的那些项目上。我想，这也会为STB中国团队今后的创新实践指明方向。

态度决定深度。在惜别STB中国之际，我坚信不久的将来，随着与客户和合作伙伴的深入交流，不断将各方需求融入到产品研发过程中，这个团队可以在中国做出世界一流的研发。

两天后，也就是我在微软的第十五年，我将从服务器与开发工具事业部的研发部门调任至技术推广部。在新的岗位上，我会负责在整个大中华区推广微软最新技术的创新应用：协助我们的合作伙伴及独立软件开发商改进商业模式、提高自身能力；支持中小企业快速成长；为开发人员和相关专业的师生们提供创新经验和技术资源等等。

STB中国的同事们，过去四年多来，每时每刻我都享受着与各位携手工作的过程。我也坚信，在未来的日子里，我会随时关注更多来自STB中国的成就与贡献，我也期待着在今后的工作中、在与客户的互动和交流中能与大家再度携手。

让我们继续一起加油，为我们的客户创造新的商业价值！

谢恩伟

洒向人间都是爱

STB China Blog — Tue, 16 Jun 2009 12:45:00 GMT

不知不觉，离2009年5月12日已经过去了一个多月，而离2008年那个令全中国人民刻骨铭心的日子也相距了一年之久。然而，岁月的河流对去年发生的汶川大地震似乎显得无能为力。时间，并没有如潮水般将那段记忆从人们心中洗刷淡去；记忆，却在时间的沉淀中愈发清晰。

我依然记得去年5月12日的情景。那天下午天气很好，办公室里安静得只有自己思考的声音。忽然，Outlook弹出公司发送的一封新邮件，在第一时间向全公司的员工告知了发生在天府之国那令人震惊的消息。接下来几天的捐款公司上下所有人更是慷慨解囊，有些部门的老板甚至发起了员工捐一元，自己就对应捐两元的竞赛，丝毫不怕个别员工会“恶意”捐款让老板“破产”的风险。

在一年后的今天，一年多前所发生的一切依然历历在目。带着让灾区更快更好地重建起来的强烈愿望，5月22日下午，服务器与开发工具事业部的公民责任委员会向在紫竹办公的近400位员工发起了“纪念5·12一周年公益义卖活动”，向全体员工征集义卖物品，号召大家参与这次义卖，并将义卖所得全部捐献给灾区。而我有幸受邀为这次的义卖活动主持。

活动从策划发起到进行义卖仅短短几周时间，但义卖现场却热闹非凡，气氛丝毫不差庙会。许多员工捐出了自己的私人物品，摆放在义卖现场竟从大会议室的前门到后门摆满了两大排。捐出的物品更是琳琅满目，从精装书籍，生活用品，护肤品，手饰，婴儿用品，工艺品，到电子用品等等，还有人特地自制了一些蛋糕送到现场参加义卖。每件物品的起价并不高，很多都从个位数起价，但到场的同事都踊跃竞拍，从10元竞价到上百元，甚至上千元。每一个人都发挥出前所未有购物狂的潜质。而每一位竞拍成功的人，无论出价多少，都获得了周围人充满感激的热烈掌声。身为主持，站在台上，看着大家争先举手竞拍，看到一件件拍品都发挥出比它本身更多的价值，心底不禁有股暖流涌动。

而各部门的老板们的捐赠就更令人惊呼：捐时间和私人服务！有的老板捐出了4个小时1：1教授DJ技能，有的捐献晚餐时间亲自下厨做特色法式大餐外加品酒常识，有的捐出双休日充当司机和导游游览水乡同里，还有的干脆就捐半天的贴身服务，至于是什么，就由出价的人说了算咯。当然，老板的时间都是蛮贵的，但仍不乏买主。大多数老板们都被不同部门的员工抢购一空，除了某位卖高尔夫时间的老大。不是因为底价太高，或是因为老板没有人缘（恰恰相反的是此位老大用“人见人爱，花见花开”来形容最恰当不过），看来高尔夫作为贵族运动在本分的IT员工中还是比较缺乏市场。

其实类似的自发性活动在服务器与开发工具事业部并不少见。在汶川大地震一周年前夕，高性能计算与SQL Server两个团队分别奔赴四川走访受灾群众安置点和学校，捐款捐物。而公民责任委员会作为服务器与开发工具事业部中由员工自发成立的组织，时常为同事们提供各类志愿活动信息，甚至精心组织多项富有新意的公益活动。在这样的氛围里工作，能感受到的不仅是身边（以及自己）的每个人对工作和技术的热情，更能感受到人与人之间的关怀。我们知道物资捐赠的也只是绵薄之力，但我们相信无数个绵薄之力加在一起，就能让爱散播在社会的每个角落，让我们居住的家园变得更美好，无论是今天，或是更灿烂的明天！

郭晓颖

转载:旅行中的志愿者

STB China Blog — Mon, 11 May 2009 23:10:00 GMT

原文发表地址：http://blogs.technet.com/chinahpc/archive/2009/05/11/volunteertrip.aspx

4月24日到29日，HPC中国研发团队和一些家人朋友，还有现已回到美国工作的前部门经理Alex Sutton，一行22人去了四川省旅游，不仅游览了绮丽秀美的九寨黄龙，还访问了震区都江堰的受灾群众安置点，最开心的是在我家乡的山村小学里见到了好多可爱的小朋友。相信不少朋友都听说过“多背一公斤”这样号召旅行者出行时多背一些物品给贫困山区小孩的故事，而这次把我们的集体旅游与志愿者行动结合起来，则是我们HPC全体成员的共同心愿。成行之前，作为一名积极的志愿者，我推荐了两个选项：去都江堰市龙池镇云华村，捐献旧笔记本电脑协助上海市闸北区热爱家园青年社区志愿者协会（下文简称“热爱家园”）开展电脑培训班，这是我去年曾经实地考察参与了前期调研的项目；或是访问捐助我家乡县城里大山深处的“夫妻小学”，从我搜到的南充日报报道来看他们的确非常需要帮助。让人喜出望外的是，最后我们不仅去了云华村，大多数的同事还去了我的家乡，好好利用了我们公司的每人每年三天的志愿者假期。我相信我们大多数人都乐于助人，但往往有这样那样的顾虑让我们不能成行，身体力行做个志愿者，并没有想象的那么困难。

24日，从上海飞到成都，我们没时间休息，就汇同热爱家园的职员陈佩赶赴云华村，到了都江堰，“岷江黄浦江水水相融，上海都江堰心心相连”的大幅标语格外显眼，有名的板房区“幸福家园”显得秩序井然，路边很多楼房的裂缝仍然清晰可见，但更多的是推土机和起重机在热火朝天地重建家园。而我在将近一年的离别之后重访故地，忍不住客串做起了导游，向大家介绍眼前的情景和地震时的故事：这块空地，曾经停放了好多军车搭建了好多帐篷，“铁军来了”、“有困难，找铁军”的横幅格外暖心；那条二王庙后门的公路上，曾经有检疫人员不辞辛劳地向来往车辆喷洒消毒剂；还有多次出现在新闻联播的紫坪铺水库，曾经有无数冲锋舟运走受灾群众，运来物资运来官兵运来希望。

（多次出现在新闻联播的紫坪铺水库）（仍在抢修中的龙池隧道）

（云华村板房区） (搬运物资到板房区）

车开了近三个小时，穿过还在施工中的隧道，开过还在修建的龙池公路，终于到了龙池镇云华村的受灾群众安置点，也就是上海建工援建的板房区，上次来这里调研的时候，我还在上海建工的厨房蹭了几顿饭呢。可能是乡亲们还在劳动，小孩们还在上学，我们并没有见到太多村民，把5台笔记本电脑、若干路由器集线器插线板和长长短短的网线放在热爱家园的云华图书室后，我们走进一家农户，一位大姐和一位老奶奶热情地和我们聊了起来，从她们那熟悉的乡音中，我听到隐隐的伤痛，却流露出更强的坚韧与希望，还有一份真诚的感谢。我们带的东西并不多，也没有时间把网络环境全部搭好，只希望这一点点帮助对即将开展的电脑培训班有些作用。大山里的孩子和青年，急需电脑和互联网来获取信息，学习知识，建设自己的家乡。在返程的车上，我代表四川人由衷地感谢我的同事们愿意大老远地来看看震区，大家都说我太客气了，Ming更是说道：打在手上，全身都会痛，四川人民受灾了，全国人民都心痛。地震过去快一年了，我们见证灾区同胞自强不息重建家园，我们祝福灾区同胞平安幸福安居乐业。

（等待图书室管理员）（村民们搬进板房前的临时居所）

（Ming与老乡聊天）（我们在云华图书室外的合影）

4月28日，游完九寨沟和黄龙的美景之后，超过半数的同事跟我回家乡南充市营山县。不巧的是，连接成都和营山的达成铁路因为扩建施工暂时关闭，于是我们从成都十陵汽车站搭乘客车，耗时4个小时，匆匆吃了午饭，又坐上县团委老师帮我们联系的面包车沿着盘山公路开了2个小时，最后在崎岖的山路上步行了半个小时，到达了我们的目的地合兴乡糖房村大垭口“夫妻小学”。当我们抬着黑板提着礼物走近小学，远远地就听到了小孩子们嘹亮的歌声，心一下子被感动充满了。紧走几步，我看到了眼前的画面，廖老师正领着站得整整齐齐的小孩子们大声唱歌，他们最大的也只是在上二年级啊，歌声轻灵稚气，眼神清澈纯净，笑容天真无邪。还有不少学生家长，围了上来，老乡们不善言辞，但一看就知道是已经站在这里等了我们很久。

（通往“夫妻小学”的崎岖山路）（搬运黑板）

（从附近赶来欢迎我们的小村民）（小朋友们唱歌欢迎我们）

老师领着学生们回到教室，幼儿园一个教室，一二年级一个教室。简陋的教室有一面是土墙，有一些大的裂缝，夏天很热，教室光线很暗，廖老师走上教室中间的一张课桌上，伸手拉了开灯的绳索，然后带领幼儿园的孩子们一起念自制黑板上的bpmf拼音，孩子们认真地齐声背诵帮助记忆的口诀“广播电台播播播”(b)，“两个门洞摸摸摸”(m)，窗外的我们和家长都开心地笑了，我想我们都看到了未来的希望。接着廖老师把两个教室的孩子集中到一起，带着他们唱起了一首“爱心叔叔”的歌，我们都很感动，不知道这是不是廖老师自己谱词谱曲的。第一排一个小女孩，长得有点像我的小侄女，我拉着她的手，问“你喜欢读书吗”，她一点也不怕我，也用小手拉着我的大手，扑闪着大眼睛说“喜欢，语文数学我都喜欢”。校长让我们给学生说些什么，因为有的小孩子听不懂普通话，George让我代表大家说说话。而我望着满满一教室可爱的小朋友，和充满期待的老师家长，一时不知说些什么好，他们需要太多的东西，而我们能提供的又太有限。最后我问了一堆问题：你们喜欢读书吗？你们喜欢你们的阳老师吗？你们喜欢你们的廖老师吗？阳老师和廖老师非常地辛苦对吗？我们都要好好学习好不好？得到的则是小孩子们一次更比一次大声的肯定回答。Alex用中文跟打了招呼，孩子们也都兴奋地叽叽喳喳，要跟见到的第一个老外交朋友。最后我们回到教室外的空地，George向校长和老师捐赠了我们带来的物品，大家还当场捐出七千多元，用于教学点的房租等校舍建设。

（廖老师带领小朋友学拼音）（Alex向小朋友问好）

（“夫妻小学”全貌） (教室窗外的学生家长）

（George代表我们捐款、捐物）

校长和老师承诺会将这笔钱的用途告知我们，而我们每个人离开的时候也在心中思考着这样一些问题：怎么样才可以更好地长期帮助这些老师和孩子呢，如果我们有更多的资源，怎么样才能有效地利用起来呢，目前由我们公司或者个人来直接负责运营是不现实的，是不是有合适的非营利组织可以合作呢？这些问题尚在思考、探讨之中。如果您有意愿、有资源帮助大山深处的老师和孩子，有扶持他们长期发展的推荐方案，我们期待倾听您的声音。

魏臻

重装上阵 - BizTalk Server 2009

STB China Blog — Tue, 05 May 2009 07:05:00 GMT

5月1日，BizTalk Server的第六个正式版本 —— BizTalk Server 2009正式发布了，共有9个语言版本一起亮相，其中当然包括了中文简体版:)。这篇文章向大家介绍BizTalk Server 2009中有什么新增的功能和改进的能力。

更新的平台支持

Windows Server 2008, SQL Server 2008和Visual Studio 2008是微软近期发布的重要平台产品，BizTalk Server 2009将全面支持新的平台，并保持对现有平台的支持，具体如下：

· 操作系统：Windows Server 2003 SP2, Windows XP SP3, Vista SP1, Windows Server 2008

· 数据库：SQL Server 2005 SP3, SQL Server 2008

· 开发工具：Visual Studio 2008 SP1, .NET Framework 3.5 SP1

用户可以通过对新平台的支持而直接获得收益，比如：

· 更好的虚拟化：虚拟化是提高硬件利用率并降低运营成本的好方法，而通过借助Windows Server 2008和HyperV, 我们可以实现BizTalk Server的高性能虚拟化部署，包括实现64位虚拟机，多虚拟处理器以及enlightened设备等。

· 通过支持SQL Server 2008而获得更好的数据库性能，同时维持对SQL Server 2005而保护用户的现有投资。

· 通过支持Visual Studio 2008增强开发人员体验和团队生产率。

提升开发人员和团队生产率

BizTalk Server 2009在开发方面不仅仅是简单地支持在Visual Studio 2008中创建BizTalk项目，还通过提供了一系列新特性来提高开发人员和团队的生产率。

· 新的应用程序生命周期管理（ALM）支持: BizTalk Server2009提供了对Team Foundation Server(TFS)的支持，使开发团队可以像开发其他.NET项目一样地管理BizTalk项目, 比如通过TFS与Project Server集成进行项目管理，对Bug进行追踪，并且使用MSBuild实现自动构建。

· 增强的开发人员生产率：BizTalk Server 2009改进了BizTalk项目系统，提供了与其他Visual Studio项目相同的用户体验。BizTalk Server 2009还实现了若干新特性，比如对Map的单步调试从而简化对复杂Map的开发和调试，以及通过生成代码框架实现对Artifacts（如Schema, Map和Pipeline）的自动化单元测试。

增强的SOA和Web Services集成能力

BizTalk Server 2009进一步完善了其作为SOA集成服务器的全方位集成能力。

· 新的Web Services注册: BizTalk Server 2009包括了UDDI Services 3.0，提供了对服务的注册和发现机制。

· 新的行业（LOB）适配器: BizTalk Server 2009 为Oracle E-Business Suites和SQL Server提供了两个新的适配器。

· 增强的IBM主机系统集成: BizTalk Server 2009增加了一个新的WCF WebSphere MQ 通道，并且新增了一个新的针对主机应用程序的WCF服务，将传统Transaction Integrator暴露给.NET Framework开发人员。另外，BizTalk Server 2009还包括了对CICS，IMS，CICS HTTP，DB2，DB2/400，DB2 Universal Database，和WebSphere MQ等最新版本的支持。

· 增强的企业服务总线（ESB）导航：通过ESB Guidance 2.0实现企业服务总线（ESB）使用模式。

增强的B2B集成能力和设备连接能力

· 对EDI和AS2协议的增强支持：EDI/AS2仍然是重要的B2B集成手段，BizTalk Server 2009对已有的EDI/AS2特性进行了一系列的改进，比如支持多消息附件，自动配置消息转发，端到端保持文件名等。

· 新的Mobile RFID平台和设备管理：BizTalk Server 2009为多种移动设备提供了一个新的轻型平台，简化了移动应用程序的发展，这样的移动应用程序可以通过RFID实时读写商业信息。BizTalk RFID Mobile包括了对增强的设备管理的支持，以及使用PowerShell和System Center Operations Manager2007管理和监控RFID基础结构的能力。

· 新的RFID工业标准支持：支持关键工业标准（包括LLRP，TDT，TDS，WS Discovery和不完全EPCIS支持）。

我们对BizTalk Server 2009的贡献

最后，自我宣传一下:)，服务器与开发工具事业部的中国团队在BizTalk Server 2009的开发中发挥了举足轻重的作用：

· 北京团队负责了BizTalk Server 2009整体的测试工作。

· 上海团队负责了UDDI Services v3.0的全部开发和测试工作。

马仲男测试主管

Visual Studio Team Architect团队的敏捷开发（第二部分）

STB China Blog — Mon, 09 Mar 2009 05:35:00 GMT

我希望大家都度过了一个快乐的春节。我也享受了一段轻松的假期——大部分时间宅在家里接待朋友和他们的家人，同时去杭州做了短暂的旅行。

十分感谢你们通过博客或者私下里给我的反馈。我希望在这篇博文中回答一些你们提出的问题。同时，为了延续整个系列的行文思路，我也会涉及一些我们团队计划sprint的方法以及sprint过程中发生的事情，并穿插着回答你们提出的那些问题。

首先，我想说的是，不存在敏捷无需计划的神话。可是，敏捷开发中的计划的确和传统软件开发中的计划有着很大区别。正如我在上一篇博文中所说，我们针对利益攸关方(stakeholders)给出的上层需求创建了带有优先级的产品待开发事项(product backlog)。这一带有优先级的任务列表形成了最基本的sprint计划。在这一过程中，我们一般遵循三阶段的步骤：在主管间进行的预计划阶段，所有团队成员都参加的计划阶段以及包含利益相关者的计划提交阶段。这里的关键是：计划是在所有成员的通力合作中进行，最重要的是由组员自发来制定标准、而不是依赖于某个项目经理。

预计划阶段在上一个sprint的最后一周进行，在这一阶段中，团队中分别带领项目经理，开发和测试的几位主管会聚集到一起讨论出在即将进行的下一个sprint中，需要开发的故事(story)列表。这个过程取决于很多因素，其中最重要的是：上一个sprint的进展情况，从利益相关者那里得到的反馈，需求或故事优先级发生的变化以及预计的团队速度。项目经理(有时甚至是开发人员或者测试人员)在阐述故事的时候会尽量简短到只描述出目标、故事的简单介绍以及故事的具体流程。我们发现OneNote很好的满足了我们这一需求(稍后会给出一个故事的截图)。

产品待开发事项总是列出对客户有价值的条目，同时它也可以增加这个团队要求的条目。但是，只有那些最终会给客户带去价值的条目才可以出现在待开发事项中。举例来说，创建并维护一个持续集成服务器以持续保证最终产品的质量，这样的条目被允许出现在待开发事项中的。

计划阶段通常在sprint的第一天进行。在开会前，项目经理会把OneNote页面的链接发送给组员，以便大家评估，并且为计划会议做好准备。通常，组员会在OneNote页面中交换意见，从而在会议之前澄清那些不明了的地方。在计划会议当天，团队组员会聚集到一起，过一下所有的故事，解决之前发现的任何问题，把故事进一步细分成一些任务，并描述每个故事的验收测试。组员同时也会对完成这些故事所需要的时间做一个大致的估计，然后根据这些估计决定在这个sprint中，团队可以完成哪些故事。

计划提交阶段在之后的一天进行，主管会再度聚集在一起并且向利益相关者介绍团队承诺完成的任务。此时，利益相关者可以提出建议对优先级进行调整。比如，如果团队成员可以完成故事A，B以及C，但是不能完成D和E，利益相关者可以建议团队在这一个sprint中完成A,B,D以及E(假设D和E消耗的总时间和C相同)。然后，项目经理会把这些故事输入用来管理我们项目的Visual Studio Team Foundation Server。

注：我们花了好几个sprint来学习并总结出以上这个计划流程。这就是sprint回顾(我会在以后的博文中提及)发挥的重要作用。

现在，让我来回顾一些针对我上一篇博文提出的问题：

在sprint中的变化以及干扰

有一位朋友提了这样一个问题，变化是敏捷方法的核心，那么团队应该如何应对sprint过程中发生的变化呢？诚然，快速有效的应对变化是所有敏捷方法的核心部分，然而，在sprint过程中的干扰始终对生产力有着不良影响。在我们的团队中，我们总是尽量避免sprint过程中的干扰，把变化延缓到下一个sprint中。因为我们把sprint的长度控制在4个星期，所以对于那些变化，意味着他们平均需要等待2个星期。:) 最起码，我们希望团队在应对变化之前，先完成那些计划了的故事。这一策略当然需要利益相关者的支持，并且在之前就达成一致。干扰对团队的影响很容易观察到，方法之一就是留意团队速度的下降。(比如在燃尽图上看到曲线的变化)

代码重构：

另一个问题是该怎样应对因需求改变导致的重构现有代码。当研究一个新的设计时，重构是有效的方法；当代码量不大时，重构也不是一个大问题。然而，一旦你的代码量开始变大，重构的代价就会变得很昂贵。由于利益相关者的反馈和需求的变化，我们也曾有相当一部分代码需要重构。在考量代码重构问题时，最重要的依据是重构对于产品和团队的影响。

举一个例子，我们曾不得不改变当一个图形被拖动到另一个图形内部时的产品行为。因为在最初设计这一行为的时候，我们的信息不够充分。在初期的实现之后，我们注意到有一些人已经对这一行为记录了bug，因为他们认为产品的表现和他们的预期不同。我们针对这一情况采取了下列的方法：1）收集更多的反馈以明确预期的行为；2)提供了一个穿刺(spike)方案（译者注：Spike指在产品线的外部开发的试探性的原型系统），调整了产品的行为；3)对穿刺方案进行代码复查和“伙伴测试”确保解决问题。（译者注：伙伴测试指找产品组成员帮忙适用产品的新功能，以查找问题）4)对已发生的变化撰写单元测试。

另外，我需要指出的是，在任何的重构过程中，自动化测试的好处都不会被过分夸大。它能够确保正在进行的代码改变不会给产品的其他部分带来计划外的破坏。

架构与设计

尽管我们应该预期到设计和实施中会有变化发生，然而，就如我之前提及的，当代码量增大时，对代码的改变和重构的代价呈非线性的增长。面对这个问题，预先进行一定程度的架构与设计就带来了好处。这里的架构与设计并不需要非常具体化，其目的是能够刚好鉴定出在之后的实施中可能面对的主要问题。当然，说起来容易做起来难J。在项目的初期，当上层的需求齐备了，也有一个初步的产品待开发事项列表时，就可以开始进行上层架构了。尽管这可以通过纸笔或者任何建模工具来完成(我们希望在Dev10发布之后，你们会用Visual Studio Team Architect完成这项任务)，你将会需要开发一个原型来支持你的设计与架构。我们发现这一步骤对项目的成功非常有帮助。对有一定复杂度的项目，你可以通过这个方法来确定应使用的技术，明确依赖关系等等。对团队来说，这也是对其各自的自动化框架加强建设的好时机。

OK，我已经讲了很多形而上学的东西。下面让我展示一些截图，把我们团队在sprint计划阶段进行的工作映对到我在前文中所讲述的方法原则。

下面的这些截图展示了我们团队在sprint计划以后讨论出的故事列表。同时，你也会注意到一些不同的团队成员留下的评论。其中的交付编号是在TFS中对应的标识号码。

一个用户故事从用户角度描述了一个需求功能点。一个好的用户故事包括需求功能的描述，谁需要它，怎么使用它，为什么需要它。

Spint计划中的重要一环是让团队对“完成”的定义达成共识。在我们对“完成”的定义中，编写并且运行通过验收测试是重要内容之一。验收测试是在软件交付之前进行的黑盒测试。在我们的语境中，它意味着用户故事的核心内容实现得如同预期的那样。

一个验收测试应该满足两个条件：1)产品的拥有者应该能够根据它鉴定用户故事已经被实现。2)开发人员应该能够根据它检验他们是否已经开发出了预期的功能。我们不开发那些不能被检验的功能。

下面是我们所创建一个典型用户故事的具体组成部分：

接下来，你会看到一个示例故事以及基于这个故事展开的讨论。<作者注：为了节省空间，以及展示团队成员间的合作，在复核阶段对问题展开的讨论，我做了手工编辑并把他们合并在了一起。〉最重要的是对故事的讨论是团队在动手实施之前的协作，团队在那一时刻已经达成了一致。在这里，我们把对质量的要求往上流推进到很早期的阶段，甚至在团队动手开始写任何一行代码之前，我们已经开始为产品质量作了努力。事实证明，这一办法在之后节省了我们很多的时间精力。如下图所示，团队讨论并解决了关于可用性，可实施性以及可测试性的问题。

这篇博文中，我已闲庭信步于sprint计划阶段，不多言了。下一篇中，我会就sprint的实施阶段展开进一步的讨论。

Ramesh Rajagopal

Visual Studio Team Architect 中国团队经理

翻译：朱永泰

校译: 林裕科

Visual Studio Team Architect 团队的敏捷软件开发（第一部分）

STB China Blog — Wed, 21 Jan 2009 02:20:00 GMT

在最近几次与客户面对面的交流中，我有幸分享了我们团队如何在日常工作中进行敏捷软件开发。毫无疑问，这在中国开发人员中是个热门话题，我也想利用博客这个平台与更多的读者进行书面的交流。当然关于敏捷开发利弊得失的争论有不少，而相关的开发模式也分成了TDD (Test Driven Development), Scrum, XP(eXtreme Programming)等流派。就我个人而言，一个团队是否严格遵循某种既定的敏捷方法并不重要，但一定得选择并采用一种（或几种）最适合自己开发团队和开发项目的。我认为重要的是团队能否遵循《敏捷软件开发宣言》所涉及的12条原则。

在我深入这一议题前，请允许我介绍一下团队：我们属于微软开发工具部（Developer Division,以下简称DevDiv），这个部门拥有几千名软件工程师，核心产品Visual Studio系列的用户从软件开发爱好者一直到大型企业里的专业开发人员及架构师。

大量而且复杂的依赖关系、代码改动、紧迫的开发周期等因素使管理软件开发生命周期并按时发布高质量的Visual Studio产品极具挑战性。为了降低风险和复杂度，DevDiv在开发Visual Studio 2008过程中采用了功能分支架构(Feature Branch Structure)和功能小组模型(Feature Crew Model)。其实这一方式之前已在Office开发团队的实践中取得不错的效果。它的最大好处之一就是使负责某个功能的团队在独立开发过程中有更大自由。由于篇幅所限，在这篇博文中我将侧重介绍我们团队是如何进行敏捷软件开发的。

我们团队负责Visual Studio系列中的Visual Studio Team System Architecture Edition，帮助架构师、运营经理及开发人员以可视化方式构造面向服务的解决方案、降低（软件产品开发的）复杂度。目前我们已开发了基于UML和DSL几个建模工具。这基本上是一个全新项目。

从产品开发来看，我们属于全球分布式开发，团队分布在三大洲的四个城市，包括亚洲的上海，北美洲的雷德蒙和夏威夷，以及欧洲的剑桥。为了尽可能减少分布式研发对团队间交流所造成的障碍，我们尽量使功能小组的成员集中于一地。基本上，每个功能小组的核心部分都在某一个城市完成，在其他城市可能会有个别工程师参与相关开发。例如，我们在上海就有一个功能小组，其他一些工程师在雷德蒙的公司总部工作。但有时，基于客户场景的特殊要求，我们也会将一个功能小组拆分成若干个，由多个城市的团队同时开发。

在本文后半部分和之后的系列文章中，我所谈及得敏捷软件开发流程都是同一个功能小组所遵循的，即是我们中国团队所遵循的。

我们中国团队主要负责开发基于UML的核心图形设计工具，包括即将发布的Logical Class Designer, Use Case Designer。此外，我们还负责在项目中提供建模元素视图功能的Model Explorer。我们所采用的敏捷开发方法是Scrum的修改版。就如我之前提到的，我们认为敏捷开发方法和技术没有哪一种是万灵丹，适合自己才是最好的。我们的团队中已有两位工程师参与过Scrum实践，也因此促成我们最终选择了它。

下面是一个我们敏捷软件开发流程的概要视图：

产品待开发事项（Product Backlog，视图的左上角）可以被视作一份这个团队以优先级排列的、需要完成的功能需求单：来自相关产品利益相关者（Stakeholders）对产品提出一系列高端要求。例如，我们最初的要求是为客户增加逻辑级（更抽象的）和物理级（更靠近代码）建模提供支持，由此衍生出了高端功能需求，诸如开发在逻辑级方便客户生成逻辑模型、兼容UML的关系图和开发帮助创建无力模型的DSL关系等。然后我们会对将要支持的UML关系图种类按优先级进一步分解（UML共有13种不同的关系图）。产品利益相关者的意见会驱动整个优先级选择过程，最终我们得出五个最重要的关系图：Logical Class Diagrams, Use Case Diagrams, Sequence Diagrams, Activity Diagrams 和Component Diagrams。于是，团队依据当时对产品和市场的了解，以故事标题的形式完成一份产品待开发事项。无疑，整个开发工程中一旦要求发生变化，也会导致需求排列优先级的变更。

在与客户的交流中，我被问得最多的问题之一是是否需要在敏捷开发过程中创建架构模型设计。和咨询公司一样，我的答复也是：视情况而定:)。围绕Big Design Upfront (BDUF), You Are Not Going to Need It (YAGNI)以及让团队在开始实施新功能时“重构”现有的代码/设计等所存在陷阱的争论也不少，其中有不少值得借鉴。尽管如此，我坚信设计初期存在这么一个阶段可以尽责地做架构设计以生成高端架构。例如，你打算建一个网上贷款流程的应用程序，你可能需要决定在这个架构里有几层。当然，能有这样一个基于最初要求的，并可能随着项目进展有所变更的架构是很重要的。在我看来，重构在敏捷开发中有其重要地位，但是如果是变更基础架构的“大重构”代价就太大了。如果大家感兴趣，我将在之后的文章中与大家探讨架构在敏捷软件开发过程中所扮演的角色。

在我们团队所遵循的敏捷软件开发实践过程中，我们的项目被分解成类似Scrum的若干个四周sprints或迭代开发周期。尽管没有测试驱动开发(Test Driven Development)或结对编程(Pair Programming)，但我们的开发人员会编写单元或签入测试（Unit/Check-in Test）来检查功能，开发和测试工程师也会在一起调试、调查或评审某个特定问题和变更等。我们还会使用极限编程（eXtreme Programming）中的使用者故事（User Story）模式。事实上，我们的产品待开发事项和每个迭代周期中的待开发事项（Sprint Backlog）都会以故事的形式被追溯。这些使用者故事就是描述一个系统的最终用户会如何使用某个特定功能。

通常，我们都会在一个Sprint阶段的最后一周计划下一个Sprint阶段：通常负责某个功能的团队（主要是主管们）会依据团队需要侧重的故事来进行由下至上的计划；然后再与产品利益相关者对项目中故事优先级的规划相协调；协调后的需求优先级清单一般会在Sprint的第一天完成。团队于是评估这些使用者故事，并完成设计初稿、实施成本，确认故事完成的标志。依据这个设计和成本，团队将承诺这个Sprint将完成的内容。

今天先谈到这里，下一篇博客我将谈谈我们团队在Sprint阶段的运作。

祝各位读者新年平安、喜乐！

Ramesh Rajagopal

Visual Studio Team Architect 中国团队经理

翻译：郑洁

校译:钱量

转载: SCCM 的昨天，今天与明天——潘正恺 (Kenneth Pan) 专访

STB China Blog — Thu, 08 Jan 2009 06:00:00 GMT

近期我们又有一个中国研发团队(System Center Configuration Manager)开博了:http://blogs.technet.com/msdchina/。这个团队也是服务器与开发工具事业部在中国最先建立的三个团队之一，先后参与发布了System Management Server 2003 SP3、System Center Configuration Manager 2007及其Service Pack 1、R2。

[原文发表地址] http://blogs.technet.com/msdchina/archive/2008/12/29/sccm-kenneth-pan.aspx

[原文发表时间] Monday, December 29, 2008 11:20 AM

潘正恺 (Kenneth Pan)是System Center Configuration Manager的掌舵人，负责整个产品团队的发展方向，领导整个产品团队进行产品研发，并协助产品的销售和售后支持工作。圣诞前夕，他来到上海，与上海的SCCM研发团队共同工作，抓住这个难得的机会，我们对他进行了一次专访，从访谈过程中，潘正恺为我们展现了SCCM产品十几年来风风雨雨的历史：

问：请问您是何时加入微软的？能不能简要介绍一下您在微软的经历？

潘正恺：1992夏天，我还在University of Washington的时候，就以实习生的身份加入微软，当时我的第一个任务就是为当时的SMS 1.0写代码。那时候的SMS还是一个全新的产品，内部代码叫Hermes(即古希腊神话中宙斯和凡世之间传递消息的传令官)。那时候我参与的部分是负责文件压缩解压的功能，以提高不同站点之间传输文件和信息的效率。之后，我逐渐开始接触后台服务端的各种组件。

当我成为正式员工的时候，那时的SMS团队还只有为数不多的人员。直到现在将近200人的规模，这十几年来，我一直在这个团队中工作，从Developer, 到Lead Developer，Developer Manager，到现在的PUM(Product Unit Manager)，从这份工作中，我得到了无尽的乐趣和成就感。

问：我们知道从1992年开始，Microsoft开始研发SMS 1.0 版本，当时是什么原因促使Microsoft向这个新的领域进军？

潘正恺：其实在一开始这并不是一个全新的产品，在92年的时候，Windows NT 3.1还未正式发布。为了促进Windows 3.1的销量，当时Windows团队的一位项目经理提出一个新的功能，要让Windows NT能管理域中各台机器的硬件资产，例如硬盘，内存等等，这个功能当时是设计为Windows NT核心功能中的一部分。后来Microsoft的高层看到这个功能之后，敏锐地发现这可能是一个新的机会，完全有可能独立出来单独作为一个产品发售。所以就有当时的SMS 1.0。但是这个产品在初期的时候，也是命运多舛，从1.0版本到2.0版本之间，几乎每半年高层就要有一次讨论，来决定这个产品到底作为一个独立产品还是作为NT的核心功能。但当SMS 2.0发布，产品销售收入达到1亿美金之后，这样的讨论就再也没有举行过。

问：据我所知，我们在SMS 2003发布的时候，销量有了一个突破性的增长，包括现在的SCCM 2007，销量也非常惊人，那您认为这些成功的背后，其核心优势是什么？

潘正恺：其实销量增长最快的时候，是我们发布SMS 2.0的时候。当时的原因，是由于正遇上了Y2k的危机，很多公司购买了SMS 2.0来解决他们公司内部的Y2K问题，在帮助我们的客户解决千年虫问题方面，SMS 2.0发挥了至关重要的作用，为客户节约了大量的人力物力。而当我们的客户部署了SMS系统之后，他们逐渐发现其实这个软件还有很多非常实用，能解决公司实际问题的功能，这些功能逐渐被客户所接受，应用在企业IT管理中，客户也就此认同SMS这个产品确实能给他们带来价值。

而说到SMS 2003，当时最大的原因是其良好的补丁管理功能。2003年，正是各种蠕虫病毒横行的时候，企业的网管经常忙得焦头烂额，帮每一台机器打最新的补丁，而当时WSUS(即Window Software Update Services)尚未推出，唯独SMS 2003提供了在企业内部分发，安装补丁的功能，所以当时的客户们趋之若鹜，纷纷在企业内部部署SMS。

到了SCCM 2007，OSD成为最大的亮点，加上更完善的补丁、软件分发管理功能，使2007成为一款非常全面、完善的系统管理软件。

问：从SMS 推出开始，一直到现在的SCCM 2007，过程中市场占有率的变化情况是怎样的？

潘正恺：在SMS 2.0的阶段，市场上还没有一个占统治地位的产品，大大小小的各类产品群雄纷争，各自有自己的一席之地，到了SMS 2003，基本上就是几家公司占据了主要的市场份额，像Landesk, Altiris 等都是我们的主要竞争对手。经过这两年的发展，目前的市场占用率情况显示，SCCM 2007 + SMS 2003 的市场份额，已经成为这个市场中的No. 1

问：我们知道，目前研发团队正紧锣密鼓地开发下一代的SCCM，请问下一代的产品会带给我们哪些激动人心的特性呢？

潘正恺：下一代产品中，我们将支持全新的面向用户的软件部署分发模式。在以前的版本中，IT管理员都是针对计算机来进行管理，分发软件。而在现在的企业办公环境中，一个员工拥有多台电脑，或在家里办公，以及使用诸如手机这样行动设备来处理邮件的需求已经变得非常普遍，面向用户的软件部署分发模式就此应运而生，以解决企业遇到的这些问题。可以想象，在将来的企业IT管理中，用户为中心的管理方式将逐渐成为主流。

问：SCCM这个产品从一开始的一个小产品，到现在成为微软企业管理软件中的支柱产品，您觉得一路走来，这个产品的成功秘诀是什么？

潘正恺：最重要的原因是：我们永远把客户的需求放在第一位，认真倾听客户的需求，设身处地地站在客户立场上，理解他们的需求，以及为什么他们需要这样的功能。客户至上的宗旨，给我们带来的结果是，在每一个版本推出的时候，都成功地掌握了客户最迫切的需求，从SMS 2.0的Y2K，SMS 2003的补丁管理，到SCCM 2007的OSD，无不如此。

问：那以目前的经济形式来看，您觉得对SCCM的市场前景，是好消息还是坏消息？

潘正恺：有好的一面，也有坏的一面。好的一面是，SCCM最大的目标，就是节约客户IT管理成本，在现在这样的经济形式下，可能会促使更多的客户来部署我们的产品，以更好地削减成本。坏的一面是，客户可能会放慢升级新的操作系统的脚步，从而间接地影响升级换代SCCM新版本的需求。所以综合来看，可能影响不会太大，但这要等我们实际的数据出来以后，才能有一个比较确切的结论。

问：我们看到在SCCM 2007的时候，产品名字修改了，从SMS到SCCM，当时是出于怎样的考虑来做这个决定的呢？

潘正恺: 这要从System Center这个品牌说起，当时微软内部负责这块业务的副总裁预期，企业IT管理类的软件，年销售量可以到10亿美金，但当时公司内部没人相信这个预测。当时的IT管理类软件，主要就是SMS和MOM，为了促进销量和建立品牌，所以创立了System Center这个品牌，这个举措也是仿效Office的品牌效应。而一旦SMS归到System Center品牌下，再叫System Center System Management Server 就不是特别合适了，所以才会改成现在的名称。现在回过头来看，这块的年销售量已经到了8亿美金，很接近当时的预测了，也可以看出当时这个品牌的树立，对产品所带来的利益和影响。

问：所以不是因为怕和短信的简称混淆罗？

潘正恺: 不是不是，我们的产品推出比短信的广泛使用还要早不少。主要还是为了品牌战略的关系。

问：您在这个产品已经工作了十几年，这段时间内，最令您激动和最令您沮丧的分别是什么时候？

潘正恺: 基本上大部分的时间都是非常快乐和富有成就感的，最困难的时候是在SMS 2.0的时候，当时质量控制还没有达到今天的水准，整个团队通宵达旦地工作，经历了几个Service Pack，才把质量提高到令人满意的程度。最高峰的时候，上百个测试人员坐在那里手工测试我们的产品，修改Bug。在这之后，我们就逐渐完善了一系列的流程，认识到了自动化测试的必要性，把自动化测试提到非常重要的位置上。

问：在这么多年的开发过程中，您有没有一些有趣的事情可以和大家分享一下？

潘正恺: 数据有时候很枯燥，有时候又很有趣，让我们看看以下这些数字：

· 在SMS 1.0发布的时候，我们所有的安装程序，是7张软盘，当时已经是一个非常庞大的软件了。而现在，恐怕一张DVD已经装不下:)

· 刚刚开始的时候，整个团队就5-6个人，而现在上海和美国两地的团队加起来已经接近200人

问：我们这个博客主要的来访者都是我们产品在中国市场的客户或者潜在的客户，在采访的最后，您想对他们说些什么？

潘正恺: 我很高兴能有这样的机会和中国的IT Pro们有这样直接的交流，中国市场对我们的产品来说真的非常重要，从私人角度，作为一个中国人，我也非常希望自己管理的产品能在中国市场蓬勃发展，帮助到中国的企业。

这里有两点想跟各位交流：其一，SCCM这样的产品，安全性真的非常重要，像IE这样的产品，如果有了漏洞，影响还只是一台机器，而如果系统管理软件有了漏洞，入侵者可以对整个企业的机器为所欲为。因此我们投入了大量的时间，精力，资金在安全性方面。希望各位在将来选择产品的过程中，多重视，比较产品和解决方案的安全性问题。

其二：SCCM不仅能节省企业成本，更重要的是，它能帮助企业建立一套良好的IT管理模式，业界的一些最佳实践，都在我们的产品中有良好的体现，这对于改善企业IT管理非常有帮助。

非常感谢Kenneth今天接受我们的采访，希望今后还有更多的机会和Kenneth交流。

如果，您对SCCM有什么问题或建议，或者有什么问题想直接问Kenneth的，可以在这里留言，我们会及时回应。谢谢您对本博客的关注并敬请期待更为精彩的更新。

郭昱旻

项目经理

亲历北京Top 500

STB China Blog — Wed, 31 Dec 2008 05:33:00 GMT

[原文发表地址] 亲历北京Top500

[原文发表时间] Tuesday, December 30, 2008 7:33 AM

金秋的北京，一年中难得的好天气，人们还沉浸在08年奥运会的喜悦中，而一项影响中国高性能计算发展的大事，也正在紧锣密鼓地进行 – 近两千台新研制开发的曙光5000A机器从已天津工厂运抵北京！这么多的机器太沉，一楼的地面无法承重，找不到合适的数据中心，造价两亿元的这两千台高性能计算服务器暂时落户在中科院计算所的地下车库里。

中国人的力量和速度再一次让世人惊叹：地下车库的改建，制冷水管的铺设，整个临时数据中心的建成一共只用了十天时间，夜以继日的努力只为了一个共同的目标 – 那就是11月中旬即将在美国奥斯汀举办的第21届超级计算机大会。世界权威的Top 500超级计算机排名将在这次大会上正式公布，跻身前列是每一个中国高性能计算工作者的梦想！

作为微软高性能计算中国开发团队的一员，我也有幸加入到这次影响中国高性能计算历史的努力中！曙光，是中国高性能计算的代表企业，与微软公司的结缘始于2007年底。一向依托于UNIX/LINUX高性能操作系统环境的曙光公司，对刚刚踏入高性能计算领域并于2006年发布第一版高性能计算产品Windows Compute Cluster Server 2003的微软公司，产生了浓厚的兴趣。这一过程是艰难的，压力与希望同在，挑战与机遇并存。

9月15日刚刚成功发布微软高性能计算的第二个版本Windows HPC Server 2008，我们来不及任何的休整，一行四人立刻踏上了北京的征程。清楚地记得第一次踏进中科院的地下车库，憋闷的环境，数千台机器共响的轰鸣声立刻让我觉得透不过气来。简易的工作台，没有任何的噪音隔离和防护措施，这就是我们接下来一个多月里需要战斗的地方。来不及多想，放下简单的行囊，立刻加入到这1920个节点部署Windows HPC Server 2008系统的工作中。这是第一次Windows HPC Server 2008产品在这么大规模的计算集群上部署和应用，我们的心情真是既兴奋又紧张。旁边来自曙光，AMD等各家高性能计算领域的同行们也都看着我们，想看一看初出茅庐的Windows HPC Server 2008到底表现如何。在基于Windows部署服务（Windows Deployment Service）的裸机部署模式的强大支持下，部署工作进行得异常顺利。部署完成后Windows HPC Server 2008简单易用的管理操作平台显示出了对近2000个计算节点的强大的管理能力，深得同行的赞誉，我们也终于舒了口气。

然而接下来的工作远没有期待中的这般顺利。一个刚刚搭建的数据中心，全新的硬件，全新的软件，对于一个至少需要连续运算7-8个小时才能取得较理想计算结果的基准测试来说，任何一个环节的细微差错，例如网络连接的松动，电源过热，15360条内存中任何一条内存的故障都会导致整个测试运行的失败。我们甚至发现，在如此大规模尚未经过时间考验的计算集群上，取得一个有效的测试结果都是相当的困难。当有节点发生故障时，我们需要和曙光的硬件工程师，来自Mellanox/Voltaire的网络工程师一起，登录到故障节点，查找可能的软件、硬件或者网络的问题，并对问题进行记录和总结。曙光也设立了简单的工作台，进行现场的故障硬件修复。如果用四个字来形容当时的工作状况，那真是“没日没夜”。从数据中心的搭建到最终Top 500的提交期限，一共只有不到一个半月的时间，每个人都不愿浪费一点点可以进行故障排查或者运行测试的时间，所以常常忘了外面是白天还是黑夜。经常拖着疲惫的身体走出计算所的大门，才意识到，早起的人们已经开始了晨跑，原来熬夜也是这么容易习惯的。更多的时候，我们也只是在车库角落里搭建的临时床，甚至机柜旁伴随着近2000台计算节点的轰鸣声席地而睡。

我们感激曙光公司在如此大规模的计算集群上率先采用刚刚发布的Windows HPC Server 2008产品的信任，但作为Windows HPC Server 2008在如此大规模的计算集群上的首次尝试，大家也曾犹豫和怀疑过。继9月29日取得116.3TFlops的运算结果之后，我们在将近10天的时间里一直无法取得任何的突破，眼看着提交结果的期限一天一天接近，怀疑的声音也开始出现。Windows HPC Server 2008真的是如此大规模计算集群的正确选择吗？在这样的质疑声中，顶住压力，永不放弃是我们的唯一选择。记得当时美国总部团队的老板们正在上海访问，和上海的团队讨论下一个版本的计划，但是在Top 500项目的巨大压力下，上海开发团队的主管严治庆于当晚就飞回了北京，还记得他那个时候诙谐地说：“不是天不助我，而是时机未到”。越是这样紧张的时候，越是要镇定，我们总结了前段时间屡屡失败的教训，为每次基准测试程序的运行制定了详细的准备步骤：包括各个节点的排查，网络状况的检查，小规模测试等等。虽然每次这些准备工作都需要花费2个小时左右的时间，但我们发现这对确保测试运行的成功率发挥了至关重要的作用。在10月9号的早晨，顶着巨大的压力，我们终于突破了140T的大关，我们终于证明了自己，证明了Windows HPC Server 2008对于大规模集群计算的能力，我想这是我们在Top 500道路上最艰难也是最重要的一个结果，连曙光的同行都表示没想到你们真的能跑出这个结果！

在整个Top 500的项目中，和我们一起并肩作战在中科院计算所地下车库里的还有一位法国朋友，他就是来自微软法国团队的Xavier Pillons。Xavier有着丰富的Top 500基准测试的经验，但是他表示像这次如此大规模的集群以及如此艰难的测试他还是第一次遇到。虽然作为他的第一次中国之行，Xavier在29天的时间里只得空休息了2天，但是他对此次的中国之行非常兴奋，记得在10月13号167.4TFlops之后的庆功宴上，Xavier自豪地说：“我们创造了中国高性能计算的历史，我很高兴成为其中的一员”！

在临近提交结果期限的两天，经过一次次地改进和测试，我们又取得了新的突破，180.6TFlops的结果，78%的效率对于Windows HPC Server的历史，对于中国高性能计算的历史都是划时代的，也为我们一个多月的辛勤工作，无数的不眠之夜交上了一份满意的答卷！在11月中旬召开的世界超级计算机大会上，我们非常荣幸地跻身全球超级计算机前十的行列，并成为在美国之外唯一一个进入前十的超级计算机集群！当怀抱奖状的时候，成绩的取得已经成为了过去，我们会怀抱更大的热情和理想做好Windows HPC Server的下一个版本，也祝愿中国高性能计算行业的发展越来越红火！

丛兰兰
HPC中国研发团队项目经理

从卓越工程的角度看微软中国开发团队的成长 (三)

STB China Blog — Wed, 20 Aug 2008 13:00:00 GMT

从卓越工程的角度看微软中国开发团队的成长 (一)

从卓越工程的角度看微软中国开发团队的成长 (二)

高效率的工具

工具的使用在人类历史发展中起到关键作用，一个时代通常因使用某种工具为标志。例如石器时代的标志是石制工具，铁器时代是铁质金属工具，信息时代是以现代通讯设备和计算机为标志。总之，工具使人们的生产效率大大提高，是人类革命性进步的重要组成部分。同样，在软件开发中，也离不开工具。

在软件开发中，最常用的工具是集成开发环境（IDE）和源代码管理控制系统，集成开发环境包括编辑器（Editor）、编译器（Compiler）、链接器（Linker）和调试器（Debugger）等。Visual Studio Professional（专业版）就是这样的集成开发环境。源代码管理控制系统是一套客户端-服务器（Client-Server）系统，服务器存储源代码，它可以支持多个客户端提交代码并管理控制源代码的版本，它还可以在没有冲突的情况下自动合并客户端和服务器有差异的同一文件，在有冲突的情况下允许客户端手动解决冲突。这样一个系统会使一个开发团队的多名工程师有效地提交代码，而不用担心提交的代码会把别人的修改覆盖掉。另外值得一提的是Visual Studio 2008整合的代码分析工具，它可以自动找出代码中的错误，包括常见的缓冲区溢出等，虽然它也会找出一些并非是错误的地方，但能找出一定百分比的错误也会使这一工具受到青睐。

代码中的漏洞也被叫作虫（Bug），软件开发测试工程师如果发现问题会记录到数据库（Bug Database）中。微软的Product Studio就是这样的一个产品，它是一个团队协作的工具，软件开发测试工程师把发现漏洞（Bug）纪录在Product Studio，项目经理会对bug做triage，软件开发工程师会改动代码修复漏洞。有时开发团队也会用Product Studio来管理工作任务，把任务象bug一样来管理。Product Studio对提高团队协作效率有很大贡献。

这么多的工具，开发人员在用不同工具时，需要切换，不是很方便。Visual Studio Team System 2008（VSTS 2008）把以上的这些工具集成在一起，开发团队中的项目经理，软件开发工程师，软件开发测试工程师都用同一个工具VSTS来进行日常工作，这好像制造业采用了流水线设备，比以前车间里用不同工具制造出产品的部件再用其它工具组装出产品，效率有极大的提高。这样的一些工具常把流程也做在其中，人员在使用工具时也就按照流程来做了，这是今后开发工具发展的一个重要方向。

CLR/Silverlight团队建立一年多了，队员对各种工具的使用已经非常娴熟了。WinForms团队虽然只有几个月，大家对各种工具的使用也上手了。目前两个团队都开始使用Visual Studio Team System 2008 ，我相信随着VSTS 的不断改进，我们的高效工具会使团队的效率达到最佳。

结束语

年轻的中国开发团队经过严格的人员挑选组队、人员培训、对技术和领域知识的掌握、高效工具的使用、简捷有效的流程的建立以及不断的经验积累，相信一定会成长为一支优秀的开发团队。

部门经理徐鹏阳

从卓越工程的角度看微软中国开发团队的成长 (二)

STB China Blog — Mon, 18 Aug 2008 08:00:00 GMT

上篇我们讨论卓越工程系统中的人才因素，本篇探讨第二个重要因素——流程。

简捷有效的流程

人是有思维的、有创造力的，可是在做一些具体事务时却容易出一些低级的错误。这时流程会帮助减少这样的错误来保证产品的质量。流程如果太繁琐会降低效率；没有流程，质量又没法保证。所以要有一个平衡，要建立一套对产品开发最合适的流程也就是简捷有效的流程。我想大家对软件产品开发的周期，例如市场调查、产品需求、计划、产品设计、产品实现、测试、调试、修补漏洞、质量过关、产品发布已有了解，在此不多谈了。我想以产品实现和测试的流程为例来说明这段流程对软件质量保证的重要性。

我在雷德蒙工作时，曾有个兄弟团队的资深软件开发工程师干过这样一件事。产品开发进入修补漏洞的后期，在这个阶段只有重要的漏洞才能去修补，而且代码提交前要经过伙伴测试（Buddy Test），这样做的目的是要保持产品质量的稳定性，可他过于自信了，在没有经过伙伴测试就把代码提交了。结果他的提交使第二天的每日构建（Daily Build）通不过多个重要的测试用例，兄弟团队也没法儿用它进行其它测试，白白浪费了一天时间。这件事对这位仁兄来说肯定是个教训，也说明流程是有作用的，不按流程做会导致一些影响很坏的错误。

在开发团队中会有很多软件开发工程师，他们都要提交代码，尽管他们会很认真的编写代码，有时也难免出错。我们常用代码评审（Code Review）这一流程中的重要步骤来保证代码的正确性。一个工程师写的代码会由另一个或几个工程师包括软件开发测试工程师来做复审。这样，代码经过多双眼睛的审核，正确性会较高。有些开发团队会要求软件开发工程师提交代码时，要先把提交放入提交排队系统，这个系统会对每个提交做必要的测试，测试通过后系统才会正式提交代码。经过这样一个流程，代码出错的可能性进一步降低。伙伴测试和提交排队系统有异曲同工之效，都是在代码进入源代码管理控制系统前对提交的代码进行必要的测试来保证代码的正确性。伙伴测试会花费软件开发测试工程师的时间，提交排队系统也需要工程师花时间来维护，各有千秋。我带领的CLR/Silverlight上海团队与相应的美国队伍共拥有七、八十位软件开发工程师，提交代码要通过一个提交排队系统，提交前要经过代码评审。

另外，也可以采用伙伴构建（Buddy Build）或滚动构建（Rolling Build）。伙伴构建是指一个工程师提交代码前或后由另一工程师帮忙做构建来验证提交代码没有构建问题。滚动构建是由一个计算机系统自动完成的，它周期性地同步源代码管理控制系统中的当前源代码后进行构建验证，也可以自动做一些测试，有问题它会自动发邮件给相关人员。WinForms上海团队组建不久开始建立流程，因为只有几个软件开发工程师，所以正在考虑采用每日构建（Daily Build）和滚动构建（Rolling Build）。

每日构建（Daily Build）出来后，软件开发测试工程师会针对它进行一系列的测试包括版本验证测试（Build Verification Test）和临时手动测试（Ad hoc manual Test），另外还会不同周期地做全面自动测试（Full Automation Test），压力测试（Stress Test），性能测试（Performance Test），安全测试（Security Test）等等。这些大多都是事先根据测试计划写好的自动测试，同时会把在测试中发现的问题记录下来，软件开发工程师会相应地进行调试解决，项目经理会对所有发现的问题做Triage（会审），Triage这个英文词的原意是一个根据伤员的伤病情况来决定先给谁后给谁处理伤病的流程，这个词在这里的意思也就很容易理解了。

测试在产品开发中对质量把关起到至关重要的作用，在整个流程中是必不可少的环节。这也是为什么微软在甄选软件开发测试工程师时也会很严格，软件开发测试工程师能力并不会比软件开发工程师差，只是在软件开发中分工不同，侧重点不同。

现在，我带领的CLR/Silverlight团队和WinForms团队各自有一套简捷的流程来进行开发测试，虽不完全一样，但都是很有效的。总之，流程是为了保证产品质量而设的，定然不能缺少，但也不能太过复杂，否则会降低效率，也会影响人的创造力和能动性。

部门经理徐鹏阳

备注:近期将更新《从卓越工程的角度来看微软中国开发团队的成长 (三)》

从卓越工程的角度看微软中国开发团队的成长 (一)

STB China Blog — Fri, 15 Aug 2008 06:30:00 GMT

在进入正题以前，我们来想象一下人类祖先在石器时代后期开始种植农产品的情景。最早发现农作物可以种植的人类祖先可能不小心把种子掉在地上，第二年春天雨季后发现长出了植物并结出果实，而秋天的收获激励他们有意识地在下一年去重复这一过程，他们挖坑埋种子的工具是石质的。经过很多很多年的进步，人类经历了农业革命、铜器时代、工业时代，直到现在的信息时代；播种农作物的工具由石质发展成铁质、钢质，由铲发展到犁，由牛拉的单犁发展到机械化拖拉机拉的多排犁；农作物种植的过程也由根据节气听天由命发展成机械灌溉、大棚种植和基因工程等现代种植方法。然而不管它怎样发展，有三样东西贯穿始终，那就是人、工具、方法或过程。

同样，一个工程系统也是由人、流程和工具组成的。人在这个系统中是最重要的因素，因为流程是由人来制定的，工具是由人来使用和操作的。但这并不是说，系统中只有人就够了，流程和工具都不需要了。流程可以帮助避免因人的主观因素而产生的错误，工具可以比人工手动成百上千倍的提高效率，所以人、流程和工具在一个工程系统中缺一不可。工程在计算机软件领域是指采用系统的流程来设计、开发和传递产品及服务。卓越工程是指在工程上能达到杰出和优异。既然软件开发也是工程范畴的，那么开发团队的成长也就离不开优秀的人才，简捷有效的流程，和高效率工具这三个卓越工程系统中的重要因素。当然开发团队的成长还包括沟通、团队协作、团队文化和团队士气等等。我在这里只从工程系统中的三个重要因素来谈。

优秀的人才组成优秀的团队

一个团队的建立需要有合适的成员加入。从招聘开始就对人才进行严格的挑选，微软的招聘哲学是要“最好中最好的”。那么什么样的人会加入我们的团队？正直诚信、有责任心、尊重他人、对客户和技术有热情、自我完善、敢于接受大的挑战、有想象力和创造力等等。当然以上是基本素质，我们也要看设计、编程和测试等能力，这是因为我们是软件开发团队，软件开发的基本能力是非常必要的。

微软招人看重的是个人能力和团队协作精神，学历并不是最重要的。我在微软亚洲工程院工作的时候，曾邀请一位美国团队资深架构师为工程师们做讲座，他在自我介绍中提到他没读完本科，我开玩笑说微软的架构师好像都没读完大学（大家都知道比尔盖茨先生没读完本科就从哈佛出来创办微软，他退休前的职称就是总架构师）。我举这个例子不是想让大家都从大学辍学，我也认识一些微软架构师不但读完本科还拥有硕士或博士学位，我想说的是学历可以说明一个人在学校取得的成绩，但不能代替工作能力以及在工作中能获得的成果。

微软员工入职后会参加入职培训和其它一些培训，但培训本身并不能使员工马上适应工作。员工入职后的前三个月通常会有一个“良师益友（Mentor）”，由有经验的老员工担任，帮助新员工熟悉工作。员工会被安排一些具体任务来“导入”以后需要做的工作。员工以后的职业学习和成长也是由培训，向其他人学习和工作中的锻炼组成的。工作中的锻炼占绝大部分，向其他人学习次之，培训只占一小部分，培训中的内容如果不通过工作中实践很难变成自己的东西，所以在工作中的锻炼成长最重要。当然向其他人学习，包括向“职业良师益友（Career Mentor）”学习有很大益处。“职业良师益友”是一些愿意帮助别人的资深员工，他们可以给员工的职业发展出谋划策或用自身做榜样。这些是员工入职初和以后成长的一个基本模式，每个员工的道路不尽相同，但有一点是相同的，那就是员工作为自己职业发展的驱动者要自己寻找锻炼的机会，经理提供帮助和指导，公司提供支持。

我刚加入服务器与开发工具事业部中国团队时，第一个向我汇报的员工对编程很有激情，他从12岁就学会用BASIC语言编程，大学时主修计算机，之前在一家外企公司做了两年软件开发工程师。一进入我的团队，就被分配到一个全新项目组，所以我们没能为他指定一位项目上的“良师益友”。但他并没有因此而退却，主动向美国团队要了资料，又找了相关的书来读，很快就上手开始修漏洞了。他还把所学到的知识整理、编写成文发表在MSDN杂志上，让更多的人来了解这项技术。没人期望一个还处在熟悉一项技术过程中的工程师写成这样一篇文章，并能发表在MSDN这样重要的期刊上，当然也包括我。在写这篇文章的过程中他既锻炼了自己，也展示了其自学能力，最重要的是他给自己创造了成长的机会，通过给自己不断地创造成长机会，他很快成为一个技术骨干，大家有问题都会去问他。

中国开发团队大多由年轻人组成，是微软分布式开发中的新生力量。我们通常会向美国团队 “借用”几个资深工程师来这里帮助招聘和训练本地员工。当然，我们也会把优秀的中国员工送到总部做短期融合培训，主要是和美国团队一起工作，了解公司文化和产品开发流程，以及与美国同事建立良好合作关系，便于以后开展工作。今年三月，我在组建WinForms（Windows Forms, .NET平台的一部分）团队时，就有三名本地员工前往雷德蒙进行短期培训，之后加入的新员工也通过阅读各类资料、动手实践来掌握WinForms的开发测试，如调查并修补漏洞，分析并写测试用例等。美国资深测试主管也受邀来上海帮助员工增加在这个领域的知识，熟悉开发流程和提高技术能力。同时，员工之间也定期交流各自的学习心得共同提高。当然，在共同发开产品的过程中，与美国同事之间频繁的视频、电话会议也帮助我们年轻的工程师们更快接手更多新工作。目前，拥有一名经理，一名项目经理，三名软件开发工程师，三名软件开发测试工程师和七名外包软测试工程师的WinForms团队已初具规模，承担了WinForms全部主要测试任务，并且可以开始修补漏洞和新功能的调研工作。这个团队能在很短的时间内承担起重要的任务，有成为一个优秀的团队潜力，虽然还有很长的一段路要走，但为今后成长为优秀的团队奠定了扎实的基础。

部门经理徐鹏阳

备注:近期将更新《从卓越工程的角度来看微软中国开发团队的成长 (二)》

转载: 关于团队文化

STB China Blog — Fri, 04 Jul 2008 01:05:00 GMT

原文地址：SQL Server Culture

中文翻译：丁晓宁邓昀

在上一篇关于SQL Server中国研发团队的文章中，我提出“文化”是团队建设中领导层面临的最重要的挑战之一。我们如何确保团队伴随着“正确的”文化而成长？究竟什么才是“正确的”文化呢？在这篇文章中，我想比较深入地探讨这个问题。

    让我们首先从“文化”这个词的定义谈起。韦氏词典将“文化”定义为：
    主条目：culture 读音：['kʌlʧə]
    功能：名词
    词源：Middle English，cultivated land，cultivation，from Anglo-French，from Latin cultura，from cultus, past participle
    综合的人类知识、信仰和行为的一种模式，这种模式取决于学习能力和传播给下一代的能力 b：一个种族、宗教或社会团体的习惯信仰、社会形态和物质特征 c：一个机构或组织特征性的一套共同的态度、价值观、目标和实践 d：与一个特定领域、经济活动或社会特征相关联的一套价值观、约定或社会习俗。

如此说来，文化是指共同的态度、价值观、目标和行为。每个组织都有一种文化，无论这种文化是刻意培养出来的还是自然演化而来的，或是这二者的结合。有时候，一个组织会很明确地用语言描述出他们希望培养的价值观和文化属性。但是，大多数人都无法理解甚至不记得一个组织“强制”的文化应该是什么，这一点并不让人惊奇。我们每个人都伴随着某种文化背景成长，但估计很少有人会说，他们是通过阅读一份文档中的价值观描述而获得这种文化倾向的。多数人都是通过日常生活汲取文化营养，包括每日体验、行为、反应、正面或负面的反馈和累积，并且从接触到的不同的社会角色像我们的长辈、上司及同事感受文化影响。随着时间的推移，这些价值观念和行为模式就根植在我们的脑海中，我们自己也成为 “已有文化”的一部分，并开始向组织内的其它人传播这种文化。

研究显示，无论是个人抑或团体、组织，一旦染上某种文化就很难改变或“去除”。同时，就长期影响而言，要区分成功的组织和平均或低于平均水平的组织，“文化”元素是一个更可靠和更重要的衡量因素，其可靠性和重要性远远超过商业策略、一项具体的技术或流程优势，甚至超过特定的领导力优势，不论这种领导力是如何有魅力或富有远见的。恕我直言，这就是为什么让一个团队伴随着“正确的”文化起步是如此重要，不论每个组织如何定义“正确的”文化。

对一个像SQL Server中国研发团队这样的组织而言，显然很多“正确的”文化是遵循我们位于雷德蒙的“母团队”而来的。当然，这是在中国，我们会理解和适应以使我们自己的本地特色融入到文化中。但一些本质特征仍然是从雷德蒙的母团队中继承而来的，正是这些特征界定了我们是谁，以及我们的行为特征。那么，这些所谓的“SQL Server文化”是哪些呢？很难为这个积累多年的文化给出准确定义或归结为几个关键点，但我尝试在这里列出几点我认为是SQL团队文化的核心：

系统文化

我们是一个系统的团队。我们创建关键业务平台软件，数以万计的组织利用我们的软件建立和运行关键业务应用，而这些应用又被全世界范围内的数万人群使用，一天24小时，一年365天地不间断应用。我们开发的软件有着数年的生命周期，实际上往往是几十年。任何错误或弱点，无论它存在于我们的设计阶段、实现阶段或流程、方法学中，都可能而且肯定会被表现出来。所以对人的素质要求门槛很高！在这种环境下要取得成功，我们需要一种专业级工程师的思维（见下文）。业余选手不适合！

IC文化

建设关键性系统软件是需要数年时间来学习的。我们常常在招聘工程师时告诉他们，尤其是对那些刚从大学毕业的人们，甚至要3到4年后他们才能真正在岗位上完全发挥生产力！虽然这听起来有点夸大，事实上是真的如此。工程师要学会客户需求的是什么，如何将其转变为一个产品或功能，什么是好的设计与坏的设计（或伟大的设计），如何权衡利弊，如何有效地撰写强大、安全、可靠、高可扩展性、高性能的代码，而且要易于维护和易于获得领域内的支持，要以有效的方式与团队一起工作，所有这些是需要数年之久才能学会的。这是一个由聪明的新的毕业生转变为专业级工程师的过程，这中间不存在任何捷径。

那么什么是IC呢？IC是微软术语，指个体贡献者（Individual Contributor，简称IC），与领导或经理相对应。在我们这样依赖高度技术技巧与知识的事业中，我们要非常重视个体贡献者。如果每一个聪明的工程师都打算在自己四年职业生涯后停止做开发而仅做管理工作，我们是无法建立像SQL Server这样的产品的。我常常列举这个统计数字：微软全球范围内有几十个或许数百个副总裁，但只有14个院士（我们很幸运，有2个院士在SQL Server）。我的意思并非是说副总裁不重要，但在微软，当然在SQL Server部门也绝对如此，我们非常重视那些愿意将整个职业生涯贡献给技术开发的人。在某种意义上说，比尔盖茨就是一个终极IC，当然他有下属，但他的主要角色是公司的首席软件架构师，帮助把握公司的未来技术方向。在微软，无论怎样强调IC角色和深厚技术知识的重要性都不过分。

事实上，我相信这一点是基础的基础，以至于我此刻想谈得远一点，而并非仅指SQL Server、微软或任何特定的公司。在我亚太区的旅行中，许多人表达了这样的信念或希望：亚太地区作为一个整体（尤其是几个特定国家如中国和印度）在世界经济体系中应该越来越多地承担起技术领导地位。显然，亚太地区有着丰富的人才，为这种可能提供了必要的条件。不过在我看来，同样毫无疑问的是，如果亚太地区真的要做到这点，即由在这里的实验室和公司主导长期的产品线和产业创新，就必须要创造一种重视深度技术成就的文化。在目前的环境下，当我和大学生们谈起他们的职业抱负时，10个里面就有8个想在毕业的几年内成为管理人员。说实在的，我们无法期望在这样的基础上建立下一代的技术领导地位。我认为就整个亚太区生态系统而言，而不仅仅是指某一特定公司或团体，建立一种重视深厚技术知识和IC的文化是势在必行的。

创新文化

数据库产业是一个成熟的一个产业：30多年的历史，每年全球超过200亿美元的年收入，人们很容易认为在这个阶段创新不再是这个产业驱动性的力量了。这样想就大错特错了！在之前的文章从数据库到全面的数据平台，我描述了该领域面临的前所未有广度和深度的挑战。为了应付这些挑战，创新必须是我们基因中的一个核心价值观，否则我们将很快没落。创新是可大可小的，技术上的创新或流程上的创新，但创新必须是深入到每个员工的日常生活和呼吸中的价值观。SQL Server有着创新的传统，甚至从根本上改变了这个成熟的产业，包括领先的易用性和自动化管理、在核心平台上集成BI功能、显著的简化开发者体验等。今天，我们继续着这一传统，在下一版本的SQL Server中有着许多突破性的创新如实体数据模型等。我们绝对需要在未来发展中继续注重创新。

聚焦客户

在今天这种超级紧迫的环境中，很容易仅仅关注竞争对手而忘记了客户。但至关重要的一点是，只有服务好你的客户才能击败竞争对手，而不是相反。聚焦客户，这不是某一个特殊部门或角色的工作。当然，公司肯定设有专门面向客户的部门，像我们的客户支持服务（Customer Support Services，简称CSS）和其他各种领域的组织。但聚焦客户是组织中每个人工作的重要职责。无论你是一个开发者、测试者、项目经理、架构师、甚至管理人员，不知道客户最终想要的是什么，你不可能做好你的工作！没有比失去与客户的联系更容易在行业里落后的了。在我们的团队中，每一个成员都有一项强制性的工作，那就是花一部分时间在客户上，不论是通过新闻组、论坛还是参加客户会议，或其他各种方式。

做正确的事

我可以继续讨论一些SQL Server和微软重视的其它价值观，例如尊重多样性、开放性、诚实但尊重、接受大挑战等，虽然这些都是非常棒的价值观，我们的确非常重视，但如果你什么都谈了，那就等于什么都没谈。所以我想以一个简要的价值观来总结，我称之为“做正确的事”。这听起来可能有点蠢，但这却是我们在SQL Server团队赖以为生的价值观。无论工作内容是关于顾客的，关于产品的，或是一个内部问题，这是指导我们日常工作的座右铭。我想举几个例子说明。我敢肯定，每个SQL Server客户直到今天都还记得Slammer蠕虫病毒。这一事件彻底改变了我们SQL Server团队的软件开发方式。当蠕虫病毒来袭时，我们其实刚刚通过一轮安全压力测试并发布了SQL Server的SP3，SP3实际上修补了蠕虫病毒所利用的漏洞。然而，一旦事情发生了，问题不再是我们是否已经发布了补丁。我们必须帮助客户备份系统，尽快地以安全的方式恢复系统运行。就短期而言，SQL Server团队费了很大力气给出工具和指导方针，帮助顾客恢复自己的系统。但我看到的是我们努力所带来的长期变化，我们开发过程的变化、我们备灾的变化、我们整个安全方针的变化。在过去几年中，这些努力的结果已经证明了自己，SQL Server已经证明自己是市场上最安全的产品之一。这意味着我们将不会再有弱点或漏洞吗？显然，答案是否定的。然而，我们可以说的是，我们每天都在努力着，努力使这种事件发生的可能性尽可能降低；而且如果这样的事件再次发生，我们已经在时刻准备着响应。

我想举的另一个例子是SQL Server 2005中的数据库镜像（Database Mirroring，简称DBM）功能。DBM是该版本中最重要和最受欢迎的功能之一，显然我们面临着压力要发布该功能。然而，快临近SQL Server 2005发布时，情况变得很清楚，我们没有时间把这个功能放到产品中了（无论是在微软内部或一些选定的客户那儿）。像DBM这样关键的功能，我们需要一段时间来证明它已经足够在生产环境中应用。所以，我们面临艰难的抉择，延迟发布或无论如何都要发布DBM或者把DBM从该版本中去掉。这几个选择没有一个是容易的，如果容易，我们就不会在这儿谈论它们了。但最后，我们决定正确的做法是先发布SQL Server 2005但并不标明DBM符合生产环境使用标准，在随后的时间完成产品测试，然后在SP1中标明DBM符合生产环境使用标准。当然，短期内该决定也带来了一些痛苦。但现在回头看，客户会告诉我们，他们欣赏我们的加倍小心和努力，以确保这项功能在他们投入生产使用前是完全合格的。

但愿这两个例子能让你知道什么是我们所说的“做正确的事”，实际上还有很多此类的例子。这篇文章已经够长了，就不再举例了。我希望大家都能明白，当我们提到“SQL Server文化”时它意味着什么。要确保我们SQL Server中国研发团队在未来几年中伴随着这种根深蒂固的文化印记一起成长，这是一个有意义的挑战。也是我们决定建立这个团队时所制定的核心承诺的一部分。

下次再聊 —加油，再见！

Prakash（孙博凯）

坚守在产品开发的最后一道防线上

STB China Blog — Thu, 03 Apr 2008 06:30:00 GMT

——介绍微软的SDET

不一样的SDET

首先，我要强调的是这篇文章讨论的是微软的Software Development Engineer in Test，中文翻译为测试开发工程师，简称SDET。不同于以手工或者脚本帮助测试的软件测试工程师 (STE, Software Test Engineer)，SDET是用编程方法结合正确的测试方法学来确保软件符合正确的设计和用户的需求，这里强调的是用编程语言来设计程序并完成自动化的高效测试。下面我就细说一下我们SDET的不同之处。

首先，SDET和SDE具有一样的设计和编程能力，这是我们筛选简历的基本条件之一。无论在美国还是中国，我们从大学招来的SDET都要具有Computer Science的背景，不一定是Computer Science系毕业的（虽然有不少人的确如此）。几所美国大学甚至开设了软件测试博士站，我原来的产品组就聘用了一位软件测试博士。SDET的代码和设计要比SDE的代码(产品)还要有更高的稳定性和坚韧性（Robustness）。产品有专人（就是SDET!）来测试，一个版本一个版本地发布。但是SDET的代码没有这种阶段性，只要它要测的功能还在，SDET的测试代码就得执行下去而且得无误！即便测试的一线管理者，就是测试主管，也同样需要有开发、设计能力。

第二个不一样是对开发式创造性思维的独特要求。这种独特性体现在SDET设计的测试用例的完整性。SDET需要有开放性的思维，才可能设想到千千万万用户的各种需求，他们来自五湖四海，有不同文化、不同年龄、不同职业等等。同时，SDET又不能迷失在用户的个案中，需要从众多案例之中，选择有代表性的进行重点测试，以点概面，用有限的时间达到较高的测试覆盖率。

第三个独特之处是SDET的工作在微软软件开发过程中扮演着确保高品质产品的重要角色。因为SDET在整个过程中始终扮演着用户的角色，对一个产品从开始编写代码到最后发布的整个过程有全盘的了解，更能对用户的体验感同身受。SDET必须与PM、SDE紧密合作确保正确理解用户需求和产品功能设计的正确性，同时还要保证产品的可测试性。比如，一项功能或设计是不可测的或是用户不需要的，SDET可以要求PM或SDE修改设计说明或功能说明甚至提供修改意见。需要特别指出的是，SDET对软件质量的Sign Off也是微软所有产品中期和最终发布的前提条件之一。

SDET的职业发展

那么微软SDET的职业发展机会又是如何呢？总的来讲，和微软其他专业的同事大同小异，主要有几个方向：

继续做SDET，级别一级一级往上升，责任和影响力也越来越大。有些产品组设有技术主管乃至软件测试架构师，一般不管人，其领导能力体现在技术上，负责整个产品的测试框架工作包括自动化系统的设计、新工具的开发和现有系统的改进等等。他们对这个产品组的贡献和影响力很大，不仅限于测试团队，甚至可以对Dev和PM等专业产生推动作用。
乐于帮助他人成长的SDET可以选择往软件测试主管，软件测试经理等的管理人员道路发展。软件测试主管通常带领3至7位 SDET，负责产品一个或几个关键构件的质量；软件测试经理监督一个产品组的测试工作，设计主要测试计划书和时间表，并经常会管理2至4位测试主管。顺便透露一下，服务器与开发工具事业部中国团队的总经理就曾经是一位测试开发工程师，并历经测试主管、测试经理，产品总监，测试总监等多个测试专业的岗位。很明显，这个过程需要具备战略性思维方式、有效沟通、团队协作，决策和执行等诸多能力。

当然，如果个人兴趣发生变更，技术带头人也可以通过一定培训转为培养、发展人才的管理人员，管理人员也可以回到技术带头人的轨道。SDET也有转为SDE或PM的，甚至转入技术咨询、支持或市场方向，最终的职业道路不外乎是上述的两个大方向。

SDET的日常工作

除了之前提及的在产品设计阶段审核并批准PM的功能说明和SDE的设计说明外，SDET也要制订相关的测试计划书和时间表，比如，为什么产品中必须提供这个功能，而不是其他的；为什么这个版本应该实现这么多功能；设计测试用例去决定什么应该测试，什么可以暂时放在一边，需要什么样的自动化测试系统，需要新的测试工具与否，测试所需要的时间等资源的预计等诸如此类。

在测试计划书和时间表审议通过后，每位SDET接下来的主要任务是用合适的编程语言去测试产品，需要考虑是共享他人的工具或代码，还是自己重写；SDET的代码的可维护性要很强，因为没有人给SDET写的代码找Bug，当然代码出错误，SDET得自己分析原因并进行修理。SDET同时不断找Bug，分析Bug产生的原因、跟踪处理Bug的进展。SDET 其它的日常工作还包括对现有系统的改进，当前系统的性能报告等等。

SDET的乐趣

做SDET没有比找到厉害的Bug更高兴的了，这会让SDE折服，让PM对产品更有信心。成功的SDET会到处听到人们在讨论他或她找到的Bug。如果找到产生这个Bug的背后原因，大家更会竖起大拇指！

做SDET都想让微软其他人采用自己发明的测试方法或工具来发现新bug！SDET承担着微软公司内部的诸多系统和工具的开发和维护工作。许多工具被内部几万人使用，这些系统和工具的开发涵盖了所有开发产品所必需的流程，技术含量更加不俗。整个微软有数千SDET，有在操作系统部的，在Office组的，在服务器的，做硬件的（譬如XBOX，ZUNE），更有Services。他们的产品各不相同，如果能研究出一个通用并且高效的做法，其它组的人必然会欣然接受。我们服务器与开发工具事业部就有一位刚从大学毕业不久的SDET，工作第二年就开发了一个UI Compliance方面的自动化测试工具，已被多个中美产品组的测试团队广泛使用，并正在申请相关专利，这也是一件值得骄傲的事情。

最让SDET自豪的是用户喜欢使用自己测试的产品，并让他们的工作更轻松、便捷。

我还清楚记得我在微软的第一次发布产品的经历。那时我在MSXML组做SDET, MSXML3.0刚发布时，我总是惶惶不可终日，生怕自己的产品支持工程师来电，说自己负责的那个领域有问题，或者是newsgroup上有人报告坏消息。一天过去了，没事，一个周过去了，还是没事，一个月过去了，还是没事，心情渐渐放下，自傲感开始上升。最后，几个季度过去还是没事，我就彻底放心，可以大胆地告诉他人，我们产品质量没问题，我做到了！

优秀的SDET

不是所有的Computer Science毕业生都适合做SDET，除了上文提到的设计和编程能力、独到的创造性外，一位优秀SDET还需要：

有测试天赋；
细心，什么都逃不过SDET的眼睛；
能建立精确的bug报告，提供简洁和准确地重现步骤和调试信息；
追求高质量的测试代码和测试工具；
有主人翁精神；
不断自我批评，寻找可能的测试遗漏点
对自己的工作负责。

卓越的SDET

主动拓展自身工作范围之外的技能和知识；
能平衡产品质量保证与产品发布时限；
是软件测试和软件测试原则的最佳传道者；
愿意做任何能最终使软件发布的努力；
在整个开发过程中始终被视作能解决问题的人物；
不断推动软件质量和跨部门交流与合作。

谈了这么多，你是否对Software Development Engineer in Test这个专业有了全新的认识呢？

对测试感兴趣的你还等什么，快加入我们的队伍吧！！！

吴光安

（注：本文作者为微软中国研发集团服务器与开发工具事业部高级测试主管）

Technorati Tags: Software Development Engineer in Test,SDET,Microsoft

一次难忘的产品发布经历

STB China Blog — Wed, 19 Mar 2008 00:00:00 GMT

上星期四（3月13日），我陪同Bob Muglia(负责服务器与开发工具事业部的高级副总裁)参加了在北京工人体育馆举行的“英雄由{此}诞生——微软2008新一代企业级应用平台与开发技术开发大会”，并有幸接受了多家媒体的参访。在这个7，000多位IT和开发人员出席的大会上，Windows Server，Visual Studio和SQL Server 首次一同亮相。在微软工作14年里，这是我在全世界各地参加的最大一次发布会；更让我兴奋和自豪的是我们这支成立仅三年的中国团队已经为这三个微软企业级旗舰产品做出了重要贡献。

以Visual Studio为例，我们非常重要的理念就是怎样把应用程序开发做得更高效，更容易使用，帮助开发团队的合作更流畅。上海团队负责研发了2008版本中的Class Designer，最大的亮点就是首次为C++代码提供了可视化支持，让全球150多万使用Visual Studio进行C++代码编程的开发人员，能够轻松、高效地了解基于C++语言的软件的设计思路、代码结构及其中各种关键类的关系等信息。

我们在Visual Studio 2008中另一个重要贡献是首次集成的一系列WCF开发工具（Windows Communication Foundation）：帮助开发人员在1分钟之内快速创建出一个简单的WCF服务，同时提供一个托管进程及一个测试客户端来运行和调试该服务。在过去，开发人员需要亲自手工来完成这些繁冗的工作；每当服务接口或配置发生变化，他们需要自己去更新其客户端，整个过程累积起来可能要耗时数小时，甚至数天。此外，这个新工具还显著降低了WCF技术的门槛——即便是初学者也可以轻松自如地使用这些工具来学习和掌握WCF技术。

我们上海和北京的服务器与开发工具团队在Windows Server 2008和SQL Server 2008中的“智”造同样层出不穷，包括新服务器操作系统中的多个数据访问组件、UDDI Services，所有SQL Server版本升级/支持工具与SQL Server集成服务等等，这里就不再一一详述。

我们的研发人员中有不少刚从高校毕业两、三年，能在短时间内有如此成就实属不易。正是因为这些朝气蓬勃、勇于挑战的工程师们使我坚信我们可以在这里做出世界一流的研发，不断为用户带去与众不同的精彩体验，引领企业级技术的创新浪潮。

谢恩伟

寻找和留住人才：在华跨国企业的管理挑战<节选>

STB China Blog — Thu, 13 Mar 2008 23:00:00 GMT

将员工继任计划视为人才管理战略的关键组成部分，微软在这方面成绩也很突出。他们认为要保有人才，“重要的是要让员工认识到，他们无论从技术晋升阶梯或是管理晋升阶梯均可以取得卓越的成就。中国的员工希望能够有一个领导或经理的头衔，但是真正的大挑战是建立人才发展和职业晋升的通道。”Hoskin 说。美国人力资源管理协会的此次调查发现，由于中国的变化速度远远超过世界其他国家，所以人力资源管理者必须能够提供迅速满足员工发展需求的机会，否则大量的人才就会流失到那些能给他们提供更好机会的企业中去。但是我们也必须注意到中国的员工面对企业和国内市场的快速发展，也呈现出急躁、急功近利的短视取向，因此必然产生这样的矛盾，即如Hoskin所说企业只给“拥有必需的技能”的员工提供“拥有更多责任和义务的岗位”。因此企业在进行人员流失管理时，必须分清哪些员工是企业真正需要的核心人才，进而给予良好的发展空间。 ...(read more)

服务世界 开发未来 : 团队故事

态度决定深度——写在惜别STB中国团队之际

洒向人间都是爱

转载:旅行中的志愿者

重装上阵 - BizTalk Server 2009

更新的平台支持

提升开发人员和团队生产率

增强的SOA和Web Services集成能力

增强的B2B集成能力和设备连接能力

我们对BizTalk Server 2009的贡献

Visual Studio Team Architect团队的敏捷开发 （第二部分）

Visual Studio Team Architect 团队的敏捷软件开发（第一部分）

转载: SCCM 的昨天，今天与明天——潘正恺 (Kenneth Pan) 专访

亲历北京Top 500

从卓越工程的角度看微软中国开发团队的成长 (三)

从卓越工程的角度看微软中国开发团队的成长 (二)

从卓越工程的角度看微软中国开发团队的成长 (一)

转载: 关于团队文化

坚守在产品开发的最后一道防线上

——介绍微软的SDET

一次难忘的产品发布经历

寻找和留住人才：在华跨国企业的管理挑战<节选>

服务世界开发未来 : 团队故事

Visual Studio Team Architect团队的敏捷开发（第二部分）