“E7” 欢迎你

衡量发布版本的规模

谢谢所有给我们发送的反馈的人们。这些反馈中的很大一部分都是积极正面的，对此我们表示感谢。我正在尽我所能的回复这些邮件、和团队里的成员进行讨论。大家都在畅所欲言地分享各具体方面上的看法、愿望和请求。我喜欢收到这些邮件，也很喜欢阅读大家的评论。这真是棒极了。我只是想让大家知道我并不可能回复每一封来信。我们将从建议我们该添加什么样文章的角度来看这些邮件和评论——我们知道将来我们会有大量的讨论，我们也非常高兴能够开始了。

在这篇帖子里，我希望继续“Win7团队”那篇文章所开启的话题——这里我们将有关团队的内容扩展一下，给大家带来更多有关我们对发布版本计划的讨论。这个有关主（major）或者次（minor）发布版本的对话，与我们开始计划时我和我的老板之间的对话非常相像:-)

当我们开始计划这个发布版本的时候，有些人可能会想我们所要决定的第一件事情就是Windows 7（client）是否要成为一个“主发布版本”。我将它双引号引起来是因为，这其实不是一件由你所决定的事情，它也不是一个具有简单答案的事情。发布版本的规模和功能特性本身以及你如何看待这些功能特性都有关。有人甚至会问，被称作为一个主发布版本是否是一种褒扬。当工程师开始计划一个产品时，我们将决定我们的开发队伍会有多少比例的人将为这个发布版本工作以及整个的日程计划——用户们将产品拿在手上后他们每个人自己将决定这个版本是否是“主发布版本”，当然我们自己也会有一个自己的看法。在服务器博客（server blog）里，我们讨论了我们日程表，我们也分享了对于Windows 7客户端和服务器发布版本规模的看法。

我们的目标是打造一个优异的Windows 7发布版本。

对于所有的客户来说，他们总有一种看法，认为一个主发布版本就是真正拥有为我准备的功能特性的版本。而一个次发布版本就是一个对我来说没有任何新东西的版本。如果这样，在计划一个主发布版本的时候就会非常简单——只要确保这个版本包含了适合所有人的功能特性（并且为了保证性能，它不能包含任何额外的功能，即使其他人想要这些功能）！作为工程师，我们都知道这样的设计过程实际是不可能的，特别是时常我们会发现两个客户要求功能特性完全相反。实际上，当我写这篇帖子的时候，我连收到两份邮件，其中的一份说“没有任何人会去关心触摸屏这种没有意义的东西”，而另一份说“（Win 7需要）更多高级/健壮的‘触摸’功能”。当你收到这些大家主动提出的零散建议时，你会看出它们会意见相左。我相信大家也能从这个博客的评论中看出这一点。

让我们以一组（但是不代表全部）不同用户的角度来看看发布版本规模：终端用户、开发人员、合作伙伴、IT专业人员和有影响的人士（influential）。

终端用户从判断一个发布版本将有多大的角度来看，是最简单直接的。对于一位终端用户来说，如果他们希望出去购买一份升级版本或者买台新的PC，那么这个版本就是一个了不起的家伙。我们就会将其称为主发布版本。看起来足够简单，而且主发布版本对所有人来说都是好东西。另一方面，我们也可以想象，一个主发布版本确实非常酷而且大家都希望买来用，但是他们也希望使用他们现有的PC，而这版本可能会需要更多的内存、可能还需要目前没有的升级驱动或是需要某些特别的硬件使其能充分发挥功能。这样看起来一个主发布版本又有点因此失去点光芒。当然，我们都知道，大家真正需要的是让它运行在他们所想要的硬件上——那么它将使一个他们想要的伟大产品（不管它是主版本还是次版本）。

开发人员通过不同的角度看待一个发布版本。很明显，对于开发人员来说一个版本是不是主发布版在于它是否具有新的API以及他们的软件能利用到的新功能——同样的简单明了。也有可能是这样的情况，上一个版本有了很多的新API，大家只是刚刚熟悉了使用它们，所以这时他们真正希望的是能完善这些API并且提高性能。这时有人可能会觉得这第一个版本是主版本，第二个是次版本。但是如果你看看软件产品的历史，经常是这些“次”版本最后成为了主版本——Windows 3.1，Office 4.2，或甚至是Windows XP SP2。每一个这样的例子里，对于开发者来说他们的目标是成为“次”版本，但是在市场的眼里他们却是“主”版本。开发人员希望使用新API的原因是由于要区别开他们的产品，或者是他们能集中精力在具体领域里的专业知识上，而不是为了调用新API而调用它们。从这种角度来说，如果一个版本能将ISV的时间解放出来，让他们能集中精力在那些对于他们来说更主要的事情上，因此他们乐意在新API上赌一把——这个版本会就可能是一个主版本。

合作伙伴代表了这样的一组人群，他们制造PC，硬件和其他我们认为Windows是系统中一分子的基础设施。合作伙伴倾向于以创造机会的角度来看待一个主发布版本，而一个次发布版本就是一个有很多改动的版本，这样它就创造了提供新硬件和基础设施给用户的机会。另一方面，与之前版本的不兼容性如果意味着合作伙伴需要停下来并且重新审视之前的工作以满足Windows新发布版本要求的话，那么它可能会被认为不那么的好。如果由于某些原因，他们决定不去做这样的工作，那么这个发布版本就会被认为是一个次版本，因为它缺乏业界的支持。所以我们再次看到，大的改变可以通过主或者次发布版本的角度来看待。

IT专业人员因其工作特性通常被划归为保守人士，对于改变也就通常持有保守看法。由于其角色的业务本质，对于任何软件产品的评估都在于投资的回报。所以对于IT专业人员来说，一个主发布版本会是一个能带来显著的业务价值的版本。这种业务价值可以被定义为例如对软件部署和管理的主要投资。然而对于终端用户或是开发人员来说，可能对这些同样的功能特性是否成为主发布版本或者次发布版本一部分并不感兴趣。

有影响的人士是所有的那些从事为我们所开发的软件提供建议、分析和观点的业务的人士。这些人通常以“变化”作为尺度来看待一个发布版本。大的变化就等同于主发布版本。一个大的变化可以是“重新构架”，例如我们从Windows 9x到Windows 2000的转变所看到的——即使这些产品看起来是一样的但是外壳之下却有很多可以谈论的变化。所以对于测评人员和分析师来说这绝对是一个主发布版本。大的变化也可以是用户界面上的变化，因为这可以引来大量的讨论而且也可以很容易看到所有的变化。不管是哪一种，这种对主发布版本的定义也可以被看作是不那么好的特性。重新构架意味着潜在的不兼容性。新的用户界面也意味着重新学习以及远离自己所熟悉的东西。

我们已经看到大量的评论，我收到了很多的邮件讲到重新构架Windows是一个主发布发本的标志。我们也接收到很多反馈提到一个主发布版本就是不提供对老版本支持的版本。如果让我来总结一下就是，大家通常觉得如果我们照这样的方式做的话将会带来其他的重要好处——重新构架将获得更好的性能，和老版本划清界线可以使用更少的内存。和这样的观点争论总是挺棘手的，因为我们在将一个已知的状态和一个我们正在改善的状态做比较，但是我们还不知道我们可能会引进什么、弄坏什么或者哪些不会被改善。所以，与其定义一个与实现相关的主发布版本，我想定义如何算是成功而不管使用了什么样的实现更有意义一些。我们将来一定还是会继续这方面的讨论——这里可以有很多的交流。

其中的关键一直都是平衡。如果我们准备好足够多的人力的话，我们可以为所有的用户带来大的变化。如果小而影响大的变化是在某个正确时间点的正确选择，我们将会加入这些变化，他们将来也会作为一个主发布版本记入历史。

我们已经谈论了日程和我们组织团队的方式，那么大家应该对这个项目的“输入”有些认识了。如果我们认真地倾听并且看对了努力的方向，那么每一类的客户都将找到觉得产品值得的部分。如果我们在产品的沟通上做好了有效的工作，那么即使那些可能成为“问题”的部分，如果在业界更广的范围来看，也会是一部分人受益匪浅之时总体上所有人都受益的情形。

以我们的角度来看，为了打造Windows 7客户端操作系统，我们动用了所有的工程团队并且制定了重要的日程计划。以任何的定义来说这都使它成为一个重要的产品。我们希望Windows 7成为一个优异的发布版本。

我希望这能帮助我们认清，当为每种类型的客户决定版本该有多大时，这个观点将是唯一标准。

--Steven

（译者注：最近由于项目较紧而没有及时地翻译博客的文章，希望大家谅解。随后我们将会陆续将未翻译的文章补上。—— 赵科平）

Windows 7 团队

感谢所有发表评论和给我发送邮件的人们。我非常欣赏我们所开始的讨论。当这个博客开博的时候，在我们的走廊里大家都摩拳擦掌。介绍Windows开发团队看起来会是一个不错的开头。本篇日志就将提供这个团队的概况。

在切入主题之前，让我们先谈谈大家期望从这个博客得到什么。首先，先聊聊我所收到的评论和邮件。我收到了很多很多——周末的大部分时间我都在花在阅读邮件和评论上。这里面确实有些主题。我可以说大部分的反馈都是非常热情的，为此我们也很感谢大家。最常提到的请求就是讨论Windows的性能或者说就是“让Windows更快些”。这个话题有很多可以说的，所以我们也会在接下来的几个月里好好谈谈。也有很多具体的请求——经常代表了某个问题所有可能的方面，例如有些朋友说“请把<x>去掉吧（或者是不要再做<x>了）”，然而其他的人却说“不管你做什么，千万要保留<x>（或者做<x>），这很重要”。对我个人来说，这个博客的很大一部分就是讨论任何问题的各个方面。即使有些事情看起来只有正反两面，但是也证明他们会有很多细小的问题。例如，有的人建议对于启动性能来说最好的方式就是在空闲时间之前不要启动任何东西，而有的人觉得推迟加载感觉像是他们慢下来了，还有的人建议最好的方式就是提供一个启动管理器，让所有人都来选择该启动什么。所有的这些都有值得讨论的优点，而这也说明即使对于那些看起来很直接明了的请求也会有它的微妙和复杂之处。

第二，让Jon和我都该惊讶的是有一些朋友质疑日志的“真实性”。有的甚至还猜测这些日志是“代写”的或者这个博客只是一种活动手段。我正在Windows Live Writer里敲键盘输入这篇日志然后点击发布。这个博客绝对是货真价实——敲错键盘、错误和所有其他的东西。这些日志没有经过任何其他的中间环节或者别人的修改。我们会有团队里的成员为此贡献，但是我们所有日志的作者就是日志的签名者。我们将为所有的日志使用一个用户名，因为这样可以保证博客的安全和所有权清晰，但是日志将由按发布按钮的那个人签名。（如果我加入到评论之中，我会使用我的msdn用户名：steven_sinofsky。）

第三，我们添加日志的频度和我们何时会涉及到“Windows 7的功能特性”。当我们写下说我们将会“定期地”添加日志的时候，我们的意思是我们不会有一个日志的时间表或是日历，我们不会承诺一个人为的频度——这与通常的博客也不相符。我们确实期望能遵循大家已经熟悉的IEBlog的模式。顺便说一下，在我的内部博客上还从来没有人由于说我贡献的不够而指责过我。:-)

正如我们在首篇日志里所说的，我们认为谈谈Windows 7的建造将会是很好的一件事情，而在我们跳到产品本身（“为什么”和“什么”）之前，这第一步就是先介绍建造产品的工程师们都是谁。

下面就让们来和这个团队见见面吧…

很容易将Windows团队想成是一个组或者一个实体，然后偶尔某个人会站出来代表这个团队——她或者是在会议上做个演讲，写本大家都熟悉的书或者文章，又或是可能有个博客。在Microsoft里，Windows产品真的是整个公司的产品，所有开发小组的人们都以这样或那样的方式为此做出贡献。这里所说的Windows工程团队由Jon和我共同管理。Jon管理着核心操作系统，包括很多东西，有内核、设备基础构架、网络、以及工程工具和系统（所有的这些都是客户端和服务器共享的）。我来自Windows客户端体验团队，也包括很多东西，有外壳和桌面、图形和媒体支持。Windows产品的另外一个很重要的部分是Windows Media Center，它和Microsoft所有的TV支持产品（IPTV、扩展器等等）一起管理。

为一个庞大的团队构建组织结构有很多的事情要做，但是最重要的部分就是计划团队的工作。这个计划过程和意识到提升Windows 7总体的一致性和协调性这一目标是统一的。所以我们并不说这是一个大组织、或者两个团队，而是说Windows 7工程团队是由25个不同的功能特性团队（feature team）组成。

一个功能特性团队代表一批负责Windows 7某个具体部分的人——代码、功能特性、质量和总体开发。功能特性团队代表了工作的所在地和团队间的合作。这也提供了一个更具管理性的大小——功能团队可以被容纳进一般的会议场所、可以一起去看电影等等。一个功能特性团队平均有40个开发人员，但是具体的团队大小各不相同。一个功能特性团队有两个部分：这个团队做什么和团队由谁组成。

Windows 7的功能特性团队听起来像是我们所熟悉的Windows各个部分。由于Windows的平台特性，我们有很多团队在几个发布版本之间保持得比较稳定，然而有些团队是全新的，或者代表了比较新的领域，他们由一些新的代码和形成了这个团队的基本代码组成。有些团队为服务器做了很多的工作（例如虚拟机的工作），而有的是负责Windows 7之外的大产品（例如Internet Explorer）。

总的来说，一个功能特性团队包含了对架构性组件和跨Windows应用场景这样一个组合的所有权。“功能特性”总是一个比较灵活的词，有的人认为功能特性是用户界面里的一个元素，而其他的人认为功能特性是传统的架构新组建（如TCP/IP）。我们对它的理解是场景和架构之间的平衡，使我们有点对点（end-to-end）的恰当覆盖，也有架构的合理部分。我们试图避免的一件事情就是将“底层逻辑”和“用户界面”分离，这样团队就可以负责点对点的工作（例如，“Find and Organize”同时开发搜索的索引器和用户界面）。Windows 7的一些主要的功能特性团队包括（按字母序）：

• Applets and Gadgets （小程序和边栏应用）
• Assistance and Support Technologies （协助和支持技术）
• Core User Experience （核心用户体验）
• Customer Engineering and Telemetry （用户工程和遥测）
• Deployment and Component Platform  （部署和组件平台）
• Desktop Graphics （桌面图形）
• Devices and Media （设备和媒体）
• Devices and Storage （设备和存储）
• Documents and Printing （文档和打印）
• Engineering System and Tools （工程系统和工具）
• File System （文件系统）
• Find and Organize （查找与组织）
• Fundamentals （基础）
• Internet Explorer （包括IE8 down-level）
• International （国际化）
• Kernel & VM （内核与虚拟机）
• Media Center （媒体中心）
• Networking - Core （网络 – 核心）
• Networking - Enterprise （网络 – 企业）
• Networking - Wireless （网络 – 无线）
• Security （安全）
• User Interface Platform （用户界面平台）
• Windows App Platform （Windows 应用平台）

我想以这篇日志的目的来看，这些名字已经足够直观了——我们在添加更多的日志时，团队成员将会指明他们所在的团队。这将让你了解Windows的子系统以及我们是如何将一个重大的项目细分到有意义的团队去的。这是一种实践方式，因为你经常希望以一组层的形式开发代码以获得高效率和性能（自下而上），但是终端用户可能会跨层体验，而IT专业人员可能希望自上而下地管理一个桌面系统。我承认有的时候这可能有一点太像内部人士的认识，因为你看不到这其中存在的一些有趣的事情。例如，平板、墨水（inking）功能和语音识别、multi-touch和协助同在User Interface Platform团队。其原因就是对共享所有这些“输入”机制的基础设施的架构需求，即使可能不会有人跨越使用所有的这些层。这样当我们设计管理输入的API时，开发人员就能看到所有的用户交互模式都通过一组API完成的好处了。

我们的功能特性团队的另外一个方面就是他们的确切组成。一个功能特性团队有三个核心工程科目组成：软件开发工程师（software development engineer，简称sde或者dev）、软件测试开发工程师（software development engineers in test，简称sdet或者test，抱歉，我还没有对外写过它的工作描述）和程序经理（program manager，简称pm）。拥有所有的这三种工程科目是Microsoft的独特之处，这还甚至引起了一些研究人员的注意。上面给出了我原来的博客对dev和pm介绍的链接（我还欠着一篇有关SDET的）。

这几种角色最简短的介绍就是：dev负责架构和代码、pm负责功能特性集和规格说明、而test负责验证而且是用户体验的最终辩护者。每个人都对质量和性能负责，每个都带着他们的个性到工作来。对于任意一个功能特性，每个dev、test和pm都作为同级（字面上和概念上都是如此）工作。以我们是如何工作以及如何确保我们以平衡的方式开发Windows 7来看，这是“权力平衡”的重点。从组织形式来看，我们的dev为dev工作、sdet为sdet工作、而pm为pm工作。也就是说我们是以这些“工程功能”来组织的。这就能使两个最优化成为可能——对专业知识和领域的专注，以及有能力保证我们不会各自闷头组建产品，而是将产品看作为一个整体。

我们将这三个科目放在一起介绍是因为我们以下面的比例创建功能特性团队：n个开发人员、n个测试人员和1/2n个程序经理。这个比例在我们的团队里是比较稳定的。在Windows 7项目里，每个功能特性团队平均有大概40个开发人员。

我们的工程团队还有一些核心成员，他们跨整个产品工作：

· Content Development（内容开发）——作者和编辑，他们创建在线帮助、web网站、SDK文档和开发文档。

· Product Planning（产品计划）——负责客户研究和学习以选择功能特性。产品计划还通过版本发布的设计和开发协作，协调我们和业内合作伙伴。

· Product Design（产品设计）——为Windows 7开发总体的交互模型、图形语言和设计语言。

· Research and Usability（研究和可用性）——创建显示现有的产品和提出的功能特性与用户如何工作的领域和实验室研究。

有人已经说过，Windows团队太大了，已经大到会引起工程问题的程度。同时，我要指出的是，单单这些评论，就能看出对各种功能特性和对Windows作出改变的巨大需求。建造Windows需要一批人，而且它确实是一个大项目。我看待这个问题的方式是，我们的工作就是让Windows团队具有合适的大小——这听起来陈词滥调，但是我的意思是，团队不应太大或者太小，它应该能被有效的管理而使团队的工作反映出团队的大小。我想起了Amadeus里的一幕：国王觉得Marriage of Figaro包含了“太多的音符”，而莫扎特却说“陛下，里面的音符和要求的一样多，不多也不少”。对于国王提议莫扎特删掉一些音符的建议，莫扎特只是问道“您想删掉哪些？”当然，团队里的成员代表了我们实现功能特性以及开发点对点场景的方式，所以这其中的挑战是要有正确的团队和和正确组织以最大化完成这些的能力——不要太多也不要太少。

我向自己保证过日志的长度不要超过4页，我差不多达到这个目标了。评论都很棒，这将帮助我们为将来的日志定下方向。我希望这篇日志能提供一些额外的背景信息。

--Steven

提供E7的翻译版本

非常感谢大家阅读我们的博客。我们已经得到了大量的支持，也收到无以计数的邮件。E7的新特点之一就是为这个博客提供其他语言的翻译版本。我们将翻译作为开发团队添加日志的一个延伸——这使得Windows 7的技术团队在添加日志的同时还要查看评论和对话（并且帮助我翻译我们接收到的邮件）。

因为这些因素，在日志的英语版本和翻译版本之间可能会有一些延迟。这是为了将这些工作在开发团队内部完成所作出的一种折衷。为此我们提前向大家道歉，但是希望大家知道我们正在为此所作出的努力。

Engineering Windows 7 – “E7” 欢迎你

欢迎来到我们在Microsoft的全新博客- Engineering Windows 7博客（简称为E7）上的第一篇日志。E7将由两位Windows 7产品的高级工程经理Jon DeVaan和 Steven Sinofsky主持。Jon和Steven以及工程团队的其他成员将参与到这个博客里发表日志、进行评论。

以本篇文章开始，我们将开始一起展望“Windows 7”项目。我们知道大家有很多和这个项目各个方面相关的问题，也知道大家都渴望了解在Windows下一个发布版本里有些什么。相信我们，能够开始谈论这个版本我们同样感到兴奋。自从Windows Vista发布后的这18个月里，我们的团队一直在为下一代Windows产品努力工作。

技术热衷者、博客主和那些对Windows充满激情的人们代表了我们对这个博客的读者定位。我们通过这个博客，为我们正在如何打造Windows 7的这个话题打开了双向讨论之门。Windows面对着每一个大规模软件项目所面对的挑战——挑选功能特性、设计、开发并且高质量地交付它们。此外，Windows还面临着满足各类不同用户需求的挑战。作为一个团队以及团队中的一员，我们继续以此责任共勉。

我们坚信，Windows 7的成功需要对如何平衡所有的这些兴趣以及如何在Windows的规模之上发布软件进行开放、坦率的双向讨论。我们承诺并且将会通过这个博客提供这样的对话机会。

计划一个像Windows这样的产品牵涉到对所有类型客户的系统学习。对于这个版本的计划，自这个项目启动之初我们就已经与大量的用户和合作伙伴（PC制造商、硬件开发人员、企业用户、开发人员等等）一起工作。我们还通过遥测（用户体验改善计划）、可用性研究和其他手段继续广泛的用户学习。这个博客即将探索的一个领域就是我们从用户和市场那里学习到的各种介绍发行版本的方式。

在这个秋天我们有两件对于开发者和整个相关业界都很重要的事件。十月二十七号的Professional Developers Conference （PDC）和之后一个星期的Windows Hardware Engineering Conference （WinHEC），将是我们首次提供有关Windows 7 深入技术信息的聚会。这个博客在接下来的两个多月里将定期添加有关该版本开发幕后的日志以提供背景信息，而且在产品的发布时我们也会继续。

在酝酿这个博客的过程中，我们已经看到很多博客在讨论Microsoft可能会对Windows 7相关的沟通控制的更多一点（可能有人会说这明显是一个有所保留的陈述）。作为一个团队，我们在 “透露消息”以及我们都容易在完全理解功能特性之前就不经意地开始谈论它们方面上，肯定吸取了一些教训。对于Windows 7和发布之前的沟通，我们的初衷是确保在我们真正谈论它时能够对我们所谈论的东西有相当的自信度。我们最先想到的是保证我们没有打乱资源分配或是给数以万计、深切地关心并且已经对Windows的革新作出大量投入的合作伙伴和客户带来策略上的不清晰。

和透漏消息相关的是，我们将确保不会对该发布版本作出最后让大家扫兴的期望 – 例如功能特性没能实现、说好的没有兑现、或是某些我们最终不提供的支持。从开发Windows 7的第一天开始，我们作为一个团队就保证要做到“承诺并且交付”。这就是我们的目标：与大家分享我们所将要完成的事情、为什么我们要做这件事情、以及高质量地按时发布。

对于这个博客我们很兴奋。作为Microsoft企业网内活跃的博客主，我们俩都期待着转移我们的注意力，将能量播撒到Microsoft之外的社区去。我们知道写日志的方方面面，希望能从中得到乐趣、提供重大的信息、同时也犯一些小错误。我们知道我们会说错或者所说的会被听成并非我们的本意。对此我们并不担心。我们所期望就是，让我们以相互尊重和使Windows 7成为一个重大发布的共同目标为基础展开对话。

我们希望能“定期”添加日志。我们将会查看评论，而且也一定会加入到评论之中，并在需要时添加后续文章。我们将确保Windows 7开发团队的成员也如此地代表他们自己。虽然我们希望这样的对话是开放的，如果您愿意也可以发送电子邮件到steven.sinofsky@microsoft.com。特别是当建议我们在博客里讨论的话题时，电子邮件是一个很好的方式。

好了，我们在这里总结这篇欢迎日志，希望大家保持关注并且加入到这个有关Windows 7开发工程的对话中来。

Steven and Jon

Translated by 赵科平