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
