潘正磊谈微软研发团队管理之道

先给我们介绍一下你自己和你自己现在所做的事情吧？

我是在1992年大学一毕业就参加了微软，一开始是做开发程序员，就是Developer，最开始开发的项目是Microsoft Access，现在也是微软卖的很好的一款产品。在Access开发了几年之后，我转做另外一个产品叫Visual Interdev，那是我们微软第一款针对网络Web做的开发工具；那之后我在Visual Basic团队做Developer Manager，就是开发经理的职位，当时我们整个从VB6到VB.NET 转型，所以跟.NET做平台开发，是一个非常艰苦的项目。之后还在Visual Studio里做了一系列的职务，包括开发总监，包括我们Visual Studio Team Architect的产品总经理，包括Visual Basic的产品总经理。现在是Visual Studio Applications的产品总经理，像我们刚才所说的，主要我们这个团队做的是针对企业的开发工具。

你是从一个基层的开发人员一直走到现在，那我想，在你整个过程中应该是有很多的感触，特别是从一个开发人员然后到一个管理职位，在整个过程中有没有什么比较难忘的事情？

因为已经工作十几年了，所以说，确实有很多故事了，我觉得比较难忘的几个故事，还是跟我们最高层打交道的时候比较有趣。我们在做Visual Interdev的时候，那是我们第一款针对Web的产品，当时微软对Web的定义、对Internet的战略不是非常清晰。记得我们跟Bill Gates在做产品Review时候，他一开始对我们这个产品是有些意见的。他说，你这个产品做出来以后，对Windows有什么好处或者是坏处。这是一个挺尖锐的问题，让我们所有人回去都要好好想一想。

还有最近我们在做另外一款产品Review的时候，也是跟我们Steve Ballmer，我们的CEO，跑上来我就要给他做一个演示Demo，我们的CEO就说现在所有演示都不要做，他叫我们最资深的副总裁，“你就到黑板上面去，把你们这个产品要做出来的三个目标先给我写上去，写完以后我们再做演示，看你这演示有没有达到你这三个目标”，这个跟Steve Ballmer做Review常常会碰到这种情况。

他会直接帮你梳理你的产品目标？

他会用你很意料不到的方法来问你，因为一般我们去做这种总裁Review都是有准备好一套PowerPoint，有一套我们自己的思路，他就会从你的思路之外问一些问题，保证你确实能够解释出来你为什么要做这个东西，然后你的思路是什么，你的战略是什么，这是一些蛮有挑战性的东西。

在你的个人从开发人员到一个团队管理的过程中，在做团队管理的时候有没有遇到一些困难、一些比较难忘的事情？

做团队管理的时候，因为团队管理最主要的是几大块：第一，你要造就一个非常强的团队。这中间有很多（差异），你这团队是你自己接手的，还是这个团队是你自己一个一个雇佣进来，这个完全是不同的。还有和你的Partner（合作）团队，因为微软很多项目需要好多几个团队来一起合做才能做好，那跟你Partner的这个运行过程中也有很多的这种Interaction（互动），有的时候如果大家的战略目标不一样，就会造成很多各种各样的问题，那所以这都是有很多故事的。我现在一下想不出来一个特别好的、最有挑战的。因为从组建团队中，这么多年走过来，基本上什么场景都碰到过了，所以我还真一下想不出来一个最好的故事，或者是说最有挑战性的故事。

其实我也了解到在你整个的发展过程中，到最后成为全球微软有两千多个总经理，你是为数不多的华人，那么从整个阶段来看，你是如何去总结自己的这段历史？

我觉得微软现在华人的总经理比较少，但是我觉得从长远来说肯定会越来越多，这实际上是我们在九几年有大量的大学毕业生开始出国，然后开始在美国，或者这种（国外的）地方开始就业有关。我相对来说出国比较早一些，所以我进微软也很早。那像九几年之后，95、96，包括90年代末期，有大批的中国员工进入微软，所以我相信这以后的华人工程师或者华人总经理，各方面只会越来越多。那另一方面，在微软或者是在很多大企业里，自己的一步一步都是要慢慢走过来，然后都是要脚踏实地，最主要的是要想到说你对这个团队有什么贡献，你对你的客户有什么贡献，如果能够比较的专注于某方面工作的话，那我觉得在成长中是很有好处的。

进入微软的华人很多，工程师也很多，但我想也淘汰了很多，最终可能会有一个人冒上来，而且这个人就是你，我想问一个比较直接的问题，你觉得为什么会是你走到今天这个位置？

我觉得每个人的长处是不太一样的，我觉得我自己的长处，第一是技术方面还不错，因为一开始在做工程师，如果你技术上面做不好，是不可能往上走的。另一方面，我觉得我对资源整合这一方面是比较强的，我的一个强项是我很快就能看出我下面的员工他们最适合什么，他们不太适合什么，那把他们放在最适合于他们的工作岗位上。这样第一能够是最大的调动他们的积极性，第二整个团队可以成一个非常高效的团队。

而且我在管理人员方面，很多跟我做了很多年的员工，愿意跟我做很多年，所以这也是作为一个领导者应该比较重要的素质。

我觉得是这些是可以学的，但有些可能有的人就会比较容易一些，比较自然一些，有的人可能就是要学的更多一些。

但是我想在你的团队里面应该也有一些能力非常强的，比如说他的存在会让你有所威胁，那么在这种情况之下，你是如何和他们相处的？

你看，我这个考虑思路跟你完全不一样，我不会觉得我团队里面有谁对我是有所威胁的，我的出发点就是我希望能够培养一批人才，如果有一天我能够不用去上班了，而且我的团队还可以执行得非常好，这才是我的目标，所以我是希望有人能够来代替我。

因为微软里面包括很多公司是这样的，有挑战性的工作是非常多的，如果我这个工作做完了，如果我下面培养出一批人才，能够取代于我的话，那还有更加具有挑战性的工作在等着我去做，所以这个思路不是说有这个人会对我造成危险性，而是我如果有一天能够找到一个，或者请到一个比我更强的员工，这是一个非常高兴的事情，非常令人振奋的事情。

实际上在我的职业生涯中也确实有过这样的经历，我那时候在做Visual Basic开发经理的时候怀孕了，我知道会休蛮长的产假，而且一度还动过可能不回来上班的想法，做全职妈妈的这种心思，所以我那时候就把我下面的一个开发主管，一个开发主管一直培养他，而且当时就是培养他到最后，我去休假之前，说那这个团队就交给你了。等我五个月休完产假回来之后一看，那个团队虽然是我打造的，交给他之后他还是管理的非常好。我说太好了，那你就来做开发经理。那个时候我就去做了我们Division另外一个工作，整个部门的开发总监。

就像我说的，这世界需要能人的事情非常的多，所以你是一个能干的人你不要有这种危险感，因为需要你的地方是非常多的。

所以我想，一个人的自信对于他的整个的成长是非常有帮助的？

实际上我觉得如果在微软来说，如果你没有自信，那你可能很难从一个开发工程师往上走非常的远。因为在微软我们招的都是，真的是世界上英文词叫“cream of the crop”，都是最最顶尖的大学生，或者是外面有经验的人。在这样一种环境中，你怎么样能够跟大家交流，怎么样可以说服大家同意你的观点，怎么样听取别人的反馈，自信心实际上是一个非常基本的素质。如果你没有这个素质，就是作为一般的开发工程师也不会走的太远的。

另外我比较好奇的一点，比如说在你整个的几个阶段里面：有基本的开发人员，然后到一个比如说项目经理、一个产品的带头人，然后再成为一个产品的总监，最后成为总经理，那么这几个段它有什么特别的不同吗，除了你管理的人越来越多？

那是有非常大的不同的。作为一个开发工程师来说，你最主要的是要把你的代码写得越快越多越好。因为你对产品的贡献是鉴于你代码的数量，你写代码数量直接就反映成你对这个产品功能多少的体现，你的代码行写得多，那这个功能才增加得多，你写的代码行是最难的那部分，那才说明你对这个产品最主要的核心部分有贡献，这是作为开发工程师。

作为一个开发主管来说，就是我们叫Development Lead，第一方面，作为管理者，你对这个团队的价值，不仅仅是说你自己写了多少行代码，这相对来说是比较少的，最主要是你这个团队对整个产品的贡献是什么，那还是基于你这个开发的功能有多少，然后你这个功能是不是做得好，你架构是不是做得好，但是你的核心价值是把你这些资源都组合起来，然后能够帮助你团队的员工扫平障碍，让他们非常顺利地开发。

像我最开始做管理的时候，我只管理了三个员工，有一个员工如果做得慢一点，那我最多周末去加一加班，他没有做完帮他补做完就完成了，我觉得相当简单的一件事情。等我那个团队长到10个人的时候，你就发现，第一，不可能我周末再来加班，也不可能把10个人里面有两三个人可能要做的慢一点，如果按同样的比例来说，我不可能把这两三个人要做的东西都做完了。那这个时候你要做，就是我们从这个Skill来说，如果要整个团队都能够非常顺利高效，你就要想“我怎么样让这十个人互相之间能够（协调好）”，就是很多程序是有顺序的问题，把顺序问题安排好，有些东西可能要需要一些决定，尽早的把决定做好，下面的架构可以做好，跟其他团队的关系要搞好，因为他们可能有些东西要拿来，他们先做完之后我们才能做，所以有很多东西Dependency Management，这些东西全部都要管理好，就像造房子，管理一个项目一样。这样管理好你这十个人才能都是马不停蹄、非常高效地把这个东西做好。

等你做开发经理的时候，开发经理因为不是一个第一线的管理者，而是第二线的管理者，这个时候最最有挑战性可能是，你很多东西要通过你第一线的开发主管传达到下面去，如果你开发主管对你说的话不认可，那你的观念、决定不一定真正能够传达到最下面的开发人员。而且你下面的开发主管可能每个人都还要管一摊不同的东西，你怎么样让他们之间能够互相配合、互相合作，从一个大局上面来看你整个这个开发团队缺什么，有的时候他们开发主管在那里面做，他不一定会知道说，我实际上比较缺一个真正能帮我把这个架构搞在一起的人，或者一个特别懂客户的人，那要把这个全部都想清楚，真正打造一个非常强的团队，这又是另外一套的艺术，我觉得。

在微软如果你不懂这产品（技术），你是没有办法做一个合格管理者的，你不仅要做人员的管理者，你还要做这个产品的定义，而且还要跟你的团队交流，什么地方是应该做的，什么地方是不应该做的。

是多重角色了？

对，因为从开发经理来说，我在美国喜欢说三个P，你要管理产品（Product），你要管理人员（People），你还要管理流程（Process），这三样东西都要抓起来，你才能作为一个合格的开发经理，然后让整个团队都能高效地运行。

他和现在的总经理有很大的区别吗？

非常大的区别，因为从开发经理来说，他还只是主要是管开发团队的。开发团队总的来说只是占了可能是1/3。总经理跟产品经理是两个不同的概念，产品经理是说你管一个产品，那总经理你是管多种产品，像我刚才所说的，实际上我现在这个组里面有三种不同的产品。

那这三种不同产品很多时候会有不同的进度表，发布时间会不一样。怎么样把里面相同的东西能够整合出来，让大家最有效地利用，而且还要针对每一个产品有他特别的开发。怎么样管理这一套产品线，而且跟我们的市场部，跟我们的营销部，跟我们的DPE（开发工具及平台事业部），那些合作都是在这个层面上面是完全不同的。而且在这上面你就更要想说，这几个产品，就像我们叫Portfolio（投资组合），就好像如果你要是投资，你可能有些放风险基金，有些放银行存款，有些是放外汇，你还要再从比较高的角度上，看你每一个产品到底里面放多少的资源进去，为什么这个产品放这么多资源，而且要看你成功的定义是什么。

而做一个产品的开发经理，这么多资源实际上已经分配给你的，你在这个资源的基础上面把它做到最大最好，所以这还是不同的概念。

更加强调统筹的作用，那我们回到技术层面来讲，在你的身上可以看到一个，我认为他是微软一个研发团队的技术变迁史，或者一个缩影。那么我想问的问题是，在你的理解当中，从你进入微软研发团队一直到现在，在整个的产品的开发过程中，主要经历了哪几个比较重大的阶段？

我觉得这个问题非常好，因为你让我回想了一下。确实有几个非常大的不同（阶段）。

在我进微软的时候还是微软比较新，很多产品还是刚刚第一代，像我那时候做Microsoft Access，现在已经无穷代了。那时候刚刚是第一版，当时发布时非常振奋人心的。如果打一个比喻，就比较像我们80年代刚刚开放的时候，那时候商品比较少，用计算机的人数少，相对来说需求也少。所以那个时候从微软来说，只要发布产品就会有很多的用户来使用。因为我们有很多很基本的需求，而市场上却都没有。那我们发布的产品只要大面上不错的话，就可以非常容易地满足用户的需求。从Word第一版开始发行的时候，前面几版你可以想有很多很多基本的功能是，现在觉得都是肯定是应该有的，但是当时都是很新的东西。

但是产品在做了时间久了之后，等你发布第五版、第六版、第七版、第八版的时候，这时有很多基本的用户需求已经满足了，在那个前提上怎么样把你的产品更上一层楼，这实际上就变成一个相对来说比较困难的问题。很多时候，像我们的Office团队最大竞争者不是别人，是前面一个版本的Office。所以在一开始我觉得我们在微软里边定义产品的时候，比方说90年代初，跟客户沟通之后我们就是用一个Waterfall（瀑布式开发模式）这种Model，因为我们觉得我们知道这个产品应该做什么，我们就把它做完了，然后放在外面市场上，相对来说一定是卖得不错的，卖得很好的，所以这是我们比较成功的一个模式。

自己可以主导？

当然我们还是要跟客户有反馈，一开始要跟客户研究，但是我觉得相对来说做得少，而且相对来说比较容易满足客户的需求。因为那时候大家的基本需求有很多都没有满足。等到我觉得差不多就是99年、2000年，就是差不多那个阶段，我们那时候很多产品已经开发了好几代了，等到那个时候我们就有一个危机，因为我记得是差不多是2000年的时候，那时候客户对我们的满意度相对来说比较低，而且我们跟合作伙伴的关系相对来说比较僵一点，在美国还有很多的诉讼案，那个时候我觉得实际上是微软处于一个比较低潮的阶段。但是从那之后，我们确实就开始转型了，我觉得一个最基本的理念，我自己有这个感受，一开始就觉得说我们可以定义这个产品，定义了以后就做，做完以后卖，这是我们最开始的运营模式。

大概是2000年之后，我们就发现对用户反馈的需求变得非常多，而且一个版本一开始跟用户反馈一次是远远不够的。从开发模式来说，开始时我知道什么是对的，我知道用户需要什么，我只要开发什么，这是我们本来的模式。在那之后，我们的模式时我不太确定用户确实需要的是什么，我们可能要先做一些prototype，试验品出来，让用户去体验一下，体验完了以后再给我们反馈，这是不是他们确实要的，我们在这个反馈基础上再更改。所以你可以看出来整个流程，一开始的想法跟后来想法是不太一样的，而且我们在2000年以后，在后面的开发中，对用户的反馈的需求比以前是大大增加了，而且我们fundamental mindset（最基本的理念），从一开始我绝对知道什么样是一个对的产品，到我不太确定，那我需要跟用户多次反馈，才能知道真正什么是对的产品，那这两个其实是非常不一样的开发模式。我们之后开始用这种开发模式之后，因为微软作为一个很大的团队，确实也碰到很多的挑战，因为很多时候你要想改一点东西实际上是非常难的。

涉及到方方面面。

方方面面，我就喜欢说，像你要是自己想在家里后院造一个小房子，你怎么改都没有关系。但是你要想造金茂大厦，造到一半想改一点什么东西，那你可以想到有很多的东西要配合。你如果要改一点东西，那对你的电梯、电路、楼层、重量，都有很多的考虑因素在里面。

那作为一个大的开发团队，你怎么样能够同时满足客户的需求，又能够在你的架构基础上能够做这种改动。因为最后你的产品还是要满足客户需求，才能够有卖点。你怎么样做这么一个调整，这也是我们在前七、八年中慢慢转型的过程。那相反过来，你如果看，拿我们Visual Studio作为一个例子，从08年，我们前面几个例子看到我们开始大量的出我们叫CTP（Community Technology Preview，社区技术预览版），而且跟我们的客户、开发人员的交流变得非常的透明，很多时候我们很早就把我们想做什么，愿意做什么，有的时候把我们写的Spec，就是产品定义放在网上，给我们的MVP（微软最有价值专家）先让他们反馈，我们现在做很多这样的工作，在这之前都是没有的。

对于你们内部的开发团队来讲，产品的设计方面是有很大的挑战，也是一种很大的转型。那么你们在自己做开发的过程中是不是也有一些分为几个阶段来呢？

对！如果是按以前的开发模式，那你可以想到我们更多的是这种，我们现在决定要做这些feature（功能），这些功能需要这样这样，那就是一条线做下来，最后把它发布就可以了。

就像瀑布模型一样的？

对。如果你要是想象做的功能可能需要在做的过程中调整的话，你中间的每一个开发阶段，就要设计一个跟用户反馈的过程，然后真正把那反馈拿回来，然后在下面一个过程中做调整。同时你还不能把你的那个发布日期改动的太多，所以你就可以看到这个难度实际上是增加了很多。

在每一个改变的环节上，根据刚才我们的交流，他应该是客户来进行推动的。那还有一个问题是，在什么时候你们认为这是一个改变的时机，认为这个开发模式应该改变了，这个产品设计的模式应该改变了，你们做决定的时候，有没有某一个观点来刺激着你们去做这种改变呢？

没有，因为微软很多事情不是Top-Down，不是从上面这么Drive（推动）下来的。第一，从管理层来说，我们比较注重抓的是用户的满意度，看他的满意度如何，就能体现我们跟他一开始交流的够不够。另一方面，比方说我们这个产品真正是有多少用户反馈，而且是把这些反馈做到了产品里面去，这也是我们可以衡量的、量化的。而且很多时候微软有一个团队开始做一个比较好的模式，那其他团队会说，这个模式不错，他也开始借鉴。所以我们这个转型也是慢慢转型，不是说一下子，整个全部团队开始转型，不是这么一个过程。

可能是某一个团队他先采用了某一种方法，然后其他团队开始慢慢的效仿，应该从底下往上推？然后从小到大这么一种方式？

说的非常对，因为我们不是Top-Down。从上面管理来说，你要抓的是最后的那个结果，你想看到的结果是什么，那么你鼓励下面团队去实验不同的方法能够达到这个结果，有的试验可能比较成功，有的试验可能不是很成功，那么你再把成功的这种方法，然后再在其他团队里面推广，一般多半都是使用这种模式比较多。

微软的高层他不会认为就是，OK了，所有的开发团队应该采用这么一种统一的开发方法来去做，他没有这么一种强制的要求吗？

绝对没有，因为微软的产品线非常的长，有各种各样的产品。开发方式实际上就是我们说的Process（流程），很多时候根据你这个产品不一样，各方面会不一样的。那我对Process理解是这样，就说Process是应该帮助你的开发更有效、更快，很多时候我们觉得Process非常烦琐，时间上会让你慢下来，实际上这个不是它的（目的），它就是没有达到要求。用另外一个比喻，其实像我们来的路上都是有很多红绿灯，有的地方是有那种转盘。像美国还有一种就是叫Four-Way Stop（四向停车），就是你到那边停下来看看左边、右边有没有车，没有车就可以通过。那他实际上都是不同的管理交通方式，管理这个车流量的一种方法，根据不同的地点，你要选择最适合地点的一种方法，有的地方如果车流量不是很大，用这个Four-Way Stop就可以了，有的地方可能有六、七个不同的出口，那用转盘是最合理的。有的地方，在美国比方说有的地方你停了电，本来有红绿灯的地方，你停了电就变成了Four-Way Stop，那时这个地方一定是堵车堵得不得了，因为红绿灯可以帮助流量的增加。

开发的管理方法也是非常类似的，根据不同的项目你要选择对你来说比较合适的方法。如果是一个比较小的项目，你用一个heavy weight(重量级)的方法那就是不合适的。这是为什么微软不会从上面说你一定要用什么样的方法，他考核得是你最后那刻做出来的结果，你的结果是怎么样，能不能在你所承诺的时间里面把东西做出来，你做出来东西用户是不是认可，你做出来的东西后面是不是有很多质量问题，还是说很好用。你在做下面一个版本的时候，就可以反映出你前面做的架构好不好。如果你前面做架构延伸性非常差，你第二个版本相对来说就会多花时间，因为要把前面重新（改造）。

遇到很多兼容性的问题？

对，所以这种才是比较硬性的考核标准，那下面用什么样的方式，你自己应该去选一个对你团队来说最合适的方式。

那我们再具体一点，就是你作为一个开发团队的负责人，肯定在整个的团队管理生涯当中，采用了很多新的技术，很多的新的开发方法，那你是有一种什么样的观点来评估这个技术、这个方法是不是应该用在自己的团队里面？

一般还是看结果。我本人是比较愿意去试验新的方法，我会让一个feature crew (功能小组)去试验这个方法。然后给他一段时间，他来给我反馈，这个不管是方法还是新的工具，他有什么优点，他有什么缺点，因为很多时候你想是想不出来，你还一定要去试，试了之后才知道它到底是好用还是不好用，它什么地方好，什么地方不好，就跟车一样，你得要去试开一下。然后在这之后，根据他的好处跟坏处，你还再可以跟现有的方法再看，再评估一下，你是把它全盘拿过来呢，还是把它改动之后再引用，或者有没有什么办法把它好的地方能够结合到现有的方法之中，不好的地方把它抛开不用。

你每换一个开发工具，或者是每换一个开发流程，尤其是团队大了，相对来说实际上是一个比较难的事情。因为你对整个开发、测试，还有工程师，你都要进行一个训练的过程。所以一般来说，我并不鼓励有什么是最热门的，我们都来试一下，因为这个是不太可能达到效果的。很多时候如果一个新的办法在推行之中，大家对这个方法不熟悉，很多时候员工也会有抵触情绪。因为我本来这个用的很好，我也知道怎么用，它里面好的、坏的我都知道了。那现在你如果是一个新的东西，我对它第一不知道，第二没有感觉，然后第三现在我就是不知道怎么跟大家合作，那一开始可能会有生产效率的这种降低。所以从这种方面来说你都要考虑进去，尤其是团队大的话，有的时候是在现有方法之上，说哪些是一定要改动的，哪些是不能改动的，那很重要一方面就是把这个理念，你为什么要改，你不是教你这个团队方法，你要把你想最关键解决的这个问题，为什么你要做这个改动，你现有方法你觉得最最不好的问题是什么，你要把这个问题跟团队讲清楚。那团队在理解了这个东西而且他也认可的情况下，比方说我们以前的开发方法是假设我们知道用户需要什么的，我们现在开发方法是假设我们并不完全知道用户需要什么的。这是一个非常基本的理念不同，你把这个要跟团队讲清楚，那他真正能够明白体会了这个问题之后，那再接下来他会和你一起改进他的工作方法。

工作方法不是我来改进的，是我的团队来改进的。因为他在日常工作（开发、测试）中发现了问题，发现什么是更好的解决方案，他要有这种主观能动性，他要明白我想解决的问题是什么，他才能够主动帮我来想更好的解决方法。那想出解决方法之后，我们大家再分享，一般都是这样。

很多可能都是从底下往上冒出来的？

绝大多数。因为我每天不在那里做开发，我不可能知道什么是最好的解决方案，确实要每天在做的人才会在他做的过程中发现说，我们这个地方好像浪费了很多时间，我们有没有什么好的方法把它给解决一下。他如果是这个涉及比较广，他会跟我们有一个汇报的过程，因为他可能会问我要资源，或者要其他的东西，那在这个时候我会给一些比较方向性的东西：这个问题我早就知道了，但是我现在决定不解决，因为可能有其他的方方面面的原因，所以我不解决；或者说这个想法非常好，我给你资源，你去给我做一个试验原型出来，然后我们再来看一下，这是非常常见的。

那我想作为一个比较成功的技术研发团队的管理者，给我们其他团队的负责人，如果提三点建议有没有什么好的建议？

我觉得对中国团队来说，有些是不是适合国情我就不知道了，但是我先说一下三点建议：

第一，就是真正的要有这种自信心，要去培养你的接班人。而且是不仅是你要培养你的接班人，每一个重要的职位下面都要有一个接班人，而且这个需要和你重要职位的人一起在培养，因为这是打造一个长久的成功的团队非常重要的一点。因为你没有这种传帮带的话，那你这个团队也许是现在可以把这个产品做出来，如果你们有重要人员离职之后，你还能不能是一个成功的团队，这是一个非常重要一点。

第二点，你怎么样能够调动员工最大的积极性，而且我觉得有的时候中国的员工不够主动，你让他做他会做得非常好，但是你不跟他说的事情，他也许就不做。这个我看得比较多，不管在美国和中国的华人员工里面都是比较常见的一个问题。作为一个管理者，你怎么样能够让他能够非常主动把问题告诉你，而且把解决方案也告诉你，这个是从微软文化上面来说是非常重要的一件事情。

第三个方面，从微软来说是人脑加电脑，从我们做IT来说是人脑加电脑，那实际上最主要的还是人脑，那你是不是真的培养员工，真正是让员工在你团队里的重要性充分的发挥了出来，只有在这个时候员工才认可你的管理的方式，才能认可他是这个团队的一员，才能想到怎么样在这个团队里面发挥最大的重要的作用，那这也是我觉得开发管理者应该多思考的问题，和多做的事情。

还有没有其他想和我们读者做分享的呢？

我觉得我们中国IT员工，从IQ上面来说非常的高。而且尤其从钻研角度来说，也是非常（努力），真的是。我们在微软自己就觉得我们在中国招的大学生素质，比我们在美国招的大学生素质要高，真的是从那个IQ上面来说。

但是，我觉得有一些可能文化上面的东西，可能会限制这些员工的发展。我看到比较多的是，有的时候员工他们碰到一个问题，我觉得可能是考试考太多了，他们看到一个问题，他们不太会去跟旁边的人，一起跟周围的团队里面的人，或者跟美国团队人一起交流，一起想最好的解决方案，能够把大家不同的观点整合起来。很多的时候看到他们自己在非常辛苦地在干。那苦干之后真的是做出来成果就说，你有没有考虑到一二三四五六，那你有没有跟这个人这个人去谈过，好像这方面做得相对来说比较差一点。因为我觉得我们考试的模式就说你不能问别人，你都要自己解决。

我们在工作中都是，你不可能一个人把方方面面都考虑全，这是不可能的。所以你一定要跟你团队里面的人搞好关系，一定要把团队里面帮你一起想这个问题，还有什么其他的观点，而且能够非常坦然的把这个观点结合到你的解决方案中去，那我觉得这方面相对来说就是相对弱一点。而且就是这种主动性比较差，如果你没有跟他说要做什么事情，你交代的我都做好了就完了。那这两方面我觉得中国员工需要想一想怎么样加强的地方。

感谢您接受我们的采访。

谢谢！

 

 

 

我了解到，Visual Studio整个研发过程中是非常好地实施了敏捷，取得了不错的效果。能不能请你介绍一下，在你们从传统的研发过程过渡到敏捷过程中，有没有经历什么一些比较好的故事？

我们实际上做敏捷转型也是因为之前有一些不太好的经历。微软在做Visual Studio 2005的时候，实际上可能延误了将近一年，而且因为各种质量问题，做完之后我们还要打一些补丁。所以作为一个开发人员来说，我认为Visual Studio 2005是一款初期做得比较失败的产品，虽然我们之后通过SP（Service Pack，补丁包）来完善它。这个产品做完之后，我们开了几次高层会议（讨论）我们怎么能够让我们下一个产品提高质量、准时发布。

当时，Visual Studio 2005的开发团队已经大约两千多人，让两千多人做同一款产品，并让这么多功能质量达标，相对来说是一个比较难的管理问题。我觉得Visual Studio 2008相对来说就，做得是非常成功的。从第一版Beta(公开测试版)开始，我们的用户反馈就非常好，他们觉得我们Beta 1的产品质量基本上可以达到我们之前的RTM（Release to Manufacturing，发布给生产厂商）的质量。

我们开发Visual Studio 2008的时候，就是我们整个大部门转型，采用敏捷开发的过程。那我来介绍一下当时我们是怎么做的。

第一，我们发现，如果从CLR（Common Language Runtime，公共运行时）、到Framework、到上面的Visual Studio这三层，同时有大改动的时候，这个是最难的。如果说CLR是我们的地基，Framework是我们的钢筋水泥，那Visual Studio就是我们上面盖的这个楼，三个东西一起改的时候，同时要建这个房子就比较困难。我们就采取了Framework有改动，但是它的基本（core）是不能改动的。如果你对我们.NET Framework比较熟悉，就知道2.0版本是最小的，然后3.0是加在它的上面延伸出来的，3.5又延伸。但它的核心的东西并没有太大的改动，我们就采用这么一个模式：我们给用户足够多的新功能和新功效。这样就保证Visual Studio建于它的基础之上，能够有非常稳定的地基。

在Visual Studio 2008中，实质上我们做了很多的工作。最大的功能就是LINQ (Language Integrated Query)功能，对编译器来说是一个非常、非常大的改动。对我们整个编译器结构的要求，和新加的功能，是很有挑战性的。当时最大的编译器当然是Visual Basic跟C#这两个编译器。我们先花了很多时间做了一个非常强大的prototype，并很早就把prototype给我们用户来反馈，帮助我们设计语言的性能，当时VB和C#都有这么一个prototype，而且我们很早让MVP使用。但是这个prototype最后有多少真正做到产品里面？非常少，不到10%。这就是我们从敏捷开发里面（借鉴的）：先要以最快的方法明确用户的需求，一开始我们先是做了这个工作。从做prototype过程之中，我们还学到了什么是容易的，什么是难的。因为很多软件产品，可能一开始用来演示的80%的产品是非常快就可以做好的，但是接下来这20%的难点，可能需要你花80%的时间去做。

最后一公里比较困难？

最后的一公里是非常困难的，尤其是在你的产品会被几百万人使用的时候，会有很多不同的场景，你在开始做演示的时候都不需要考虑到，但你最后把它做成一个产品的时候，是一定要把它做好的，否则你就需要打很多补丁。

我们在做prototype的过程中，第一，我们明确了用户的定义；第二，我们也对架构上面哪些地方是比较难的，那些地方需要花很多时间去思考才能把它做好，有一个非常深的理解。第三个好处就是，我们发现VB跟C#，虽然是由两个完全不同的code base组成的，但是在做LINQ的功能，有一些东西是可以分享的，所以从资源组合上面，我们在做完prototype之后，发现有一部分东西是两个小组可以做成一个模型。

可以共享的。

虽然语言的表达方式完全不一样，它下面有一部分生成的东西是一样的，这样两个小组可以共享。在没有做prototype之前，我们这种设计是不可能实现的，做了prototype之后不管是用户定义、架构、分享，都有了更明确的思路。有了这个思路之后，我们再来做这个项目的规划就会比较清晰。比如，第一个里程碑我们需要做出来一个什么东西，而且我们考虑是两方面的：第一方面，是从用户的体验上面来说，哪一些语言的东西可以放进去了；另一方面，是从架构上来说，哪些最最基本的架构工作可以做好了，做完这个架构工作。在第二个里程碑，我们可以实现更多的用户体验；那另一方面，可能再去开展另外一些的架构工作，所以是这么一层一层做下来的。

通过不同的迭代逐渐就完善这个产品？

所以Visual Studio 2008这产品我们做得非常成功，我们大概本来说是九月份要发行，基本上是十月份发行。对一个几千人的大团队，能够做这么大一个LINQ功能，而且我们跟其他的部门，像SQL Server有很多的合作关系，能够把这些都管理好，把产品做成，最后准时发布，这也是我们用了敏捷之后，一个比较大的成功案例。

另外一个比较成功的敏捷开发经验就是，我们试用了我们自己的产品。

微软内部有一个优良（传统），我们自己叫“Dog Food”，就是“吃狗粮”（指自己试用自己开发的软件）。我们在做2008的时候，就Dog Food了Team Foundation Server这个产品，每一个团队把他想做的东西，把用户的场景都放在这个大的服务器里面。作为微软的高层，在任何时候都可以把这些信息汇总，虽然不可能知道每一个项目做到多少，但可以从大面上知道哪些用户体验已经实现了，哪些用户体验还在做，从宏观上面，可以比较快（了解）。如果这个团队看上去这部分可能做得还差得比较远，那这个版本的这个功能我们就不做了，这种决策层上面的问题就比较容易解决。从一个50人的开发团队来说，你可以说有一些用户场景，这个版本是支持的，另一些用户场景，可能这个版本来不及做了，放到下一个版本去做，在这种决策的时候，你可以非常清晰地看到本来计划是什么，已经做到什么，而且场景我们都是要求有一个优先顺序的，按最重要的先做，不重要的相对晚做。

这有包含一些敏捷的思想在里面吗？

对，这实际上都是包含敏捷的思想。因为敏捷里面最重要的一个思想就是backlog（代开发事项），你的产品都有一个backlog，有哪些东西要做的，然后有一个优先级，全部都要按优先级排序，哪一个是最重要的，哪一个是第二个，哪个是第三。

排完序之后，每个团队根据自己现有资源划一条线，觉得哪些场景是应该可以做好的，哪些场景是不能做的。划这条线之后，作为一个决策层，你同意不同意团队的观点？很多时候，我跟我团队交流，他给我一二三四五划了这些场景，我说不对，你划到线下面的这个，比方第十五个实际上是非常重要的，它应该放到第三个。我们这样改动后再看一遍，我现在同意你这个排序了。但是你这条线划得我可能不同意，因为你可能划到第十个，那我觉得说接下来的十一到十五也是非常重要的，如果这个版本没有这些功能在里面，我认为这个版本是卖不出去的。作为管理层我有这个决策权，这时团队可能跑回来跟你说，可是我只有这么多的人，资源不够，怎么办？这个时候两个非常重要的方法，第一个最简单的是加资源；第二是加时间，这也是一种资源；第三个比较难点，你要团队回去，把他每一个做的用户场景，更仔细地分析一下，每个用户场景后面都应该有一个cost information，这个场景做出来需要多少的资源。有的时候看到他这个用户场景（会发现），为什么这个用户场景需要这么多的资源，跟你想象中的是否有出入，作为一名懂技术的管理者应该有个差不多的概念。为什么这项资源花这么多，这是对还是不对，这个时候你要做一个深入分析，阐述这个场景里面具体要做一些什么东西，有些什么考虑，认为比较难的东西是什么，这样才能说明你为什么花了这么多时间和资源。

在讨论的过程中，很多时候你就会发现，他也许设计的场景太复杂了。我给你举个例子，我们做很多界面上东西，像“drag and drop”，我看到有一个用户场景，用户可以用undo、redo、cut、copy、paste，这个需要花这么多时间吗？后来发现他们设计的是一套非常完善的方案，第一，undo和redo可以是多层的；第二，两个界面之间切换之后还是可以实现的。比方用一个车，场景是我给你一辆自行车就可以了，他可能给我的是一辆非常非常优秀的奔驰，实际上是用不着的，这个资源实际上是比较浪费的，没必要做那么好，因为用户他不认为这个需要做这么好。这时候你要跟你的团队交流，我们不用做一辆奔驰轿车在这里，可能做一个最基本的就够了。反过来说他这场景是不能没有的，一定要有，但是足够好就可以了，那这个足够好的定义就需要管理层跟团队去反复研讨。我们常常说这是一个hard cut，这个东西我也觉得很好，但是从资源上面来说不够了，我们还是放到下一个版本，我把它砍掉之后，我知道我肯定会听到用户反馈的，但是从这个总体的宏观的管理角度来说，我是一定要做这个决策的。

这都很好的融入了敏捷的思想在里面。

这里面都很好地融入了敏捷的思想，因为：第一，我们做完决策之后，就是像我刚才说的我们这个十到十五（条要做的），重新放在优先级列表里面。做完这一套东西之后，尤其是做Visual Studio，我们把很多想做的东西，做成一个可点击的PPT，像产品演示一样。实际上我们花的精力相对来说是比较少的，因为我们并没有真正去设计它下面怎么架构，它真正的用户界面是什么。但是它给了用户一个非常直观的可视性，这个产品大致可以这么操作。我们做出这么一套图形之后，把这套图形给我们的用户演示，包括我们MVP等等。给他们演示之后，他们说这方面很好，这个地方不好，我们就可以马上改进，不会花费很多资源，但是它把你的想法变成一个可视化的东西，否则你跟用户交流也是非常困难的。

你已经形象地告诉他我要做这么一个东西。

对，所以在做这个产品之前，我们先把它变成一套可以看得见的东西。那用户就可以说，我喜欢这个，我不喜欢那个。这是非常容易做到的，而且是非常行之有效的方法。这里面要多次和用户反馈，我们一开始的优先级，最优先要做什么… … 用户反馈之后，我们拿它来作为我们的执行计划，把它分成一个一个里程碑.每个里程碑做完之后，我们再拿已经做好的东西跟用户去进行交流: 产品做到这个地方，你觉得还有什么地方（需要改进）。用户看到一个真正的产品时候，还会有很多想法，比如这个场景能不能实现？我可能说这个场景我现在没有时间做。他会说，你可不可以在这边加一个接口，你要加一个接口的话，那我就可以把我的东西嵌入在里面。这个相对来说可能是比较容易做到，而且又对这个产品的拓展性有好处，那么用户在我给他做成的基础上面能够加入他自己的东西，这些东西很多时候是跟我们的用户交流之后改进的。

但是Visual Studio他的技术团队在自己实施敏捷的时候有没有遇到一些挑战？从传统的开发模型过渡到一个全新的开发模型，有没有遇到什么问题？

对于Visual Studio开发来说最常见的问题，可能与我们中国的客户并不完全一样，因为我们碰到的问题是跟我们团队人数有关系。中国的开发团队规模可能大多是50、100，200差不多就是上限了。我们的Visual Studio开发团队大约两三千人，就像军队管理一样，你管理50个人、100个人、500个人、1，000个人、2，000个人，协调的难度会非常不同。如何在2，000多人的团队，同时每一个小的团队差不多是50到100人，实行敏捷开发？在这个过程中，怎么样能够把所有的数据汇总起来？作为管理层，你可以很清晰地知道你这个团队到底做到什么程度了，什么地方是做得不错的，你可以放心的；什么地方是遇到了很大的困难，这个团队可能是一个非常重要的团队。比方说，如果是CLR 团队碰到了问题，那它的影响面是非常大的，因为我们所有的东西都构建在它之上。你怎么知道哪一个团队做到了什么程度，所碰到的困难是什么，采用些什么方法来补救，这些都是我们做得比较多的地方。从一个小的团队来说，也会碰到这种问题，但只是规模和扩展没有这么难就是了。

还有作为管理者，比方说一个50到100人的团队，你下面可能有7个、10个不同的功能组，在做不同的东西，你怎么知道每一个功能组实施到什么地方了，他做得好不好？功能组一般来说互相之间是关联的，有很多时候你去找一个功能组，也许他说我正在等前面那个人做完，我才能实施下面一步，那你对这种关联的理解是不是很清晰？这些是最常见的问题，实际上是Dependency Management（依赖关系管理）。我跟你解释一下，因为我们组太大了，很多东西需要CLR 团队先做，做完之后，要交给C# Compiler团队，再做下面一个功能，C# Compiler团队做完之后呢，我才能把它接过来，再做我下面的东西，这是非常常见的一个开发场景。这时候我们在做一开始prototype的时候，先需要定义几个大的里程碑，而且每个大的里程碑在你结束的时候，都要说清楚，哪一组跟哪一个组有哪一些可交付的，要做到这个里程碑里面的。在里程碑结束的时候，你可以非常快地一目了然，是不是每一个deliverable都已经做到了？如果有哪个deliverable没有做到的话，你可以很快的知道他下面的影响是什么。因为有时一个部分没完成，下面可能有一串的东西都没有办法做。我们很多这种数据的汇总都是在我们自己Team Foundation Server里面做的，我们用Team Foundation Server 的Reporting Feature把我们一开始把数据都放进去。这样的话就很明显可以看出来，虽然团队可能把这个deliverable做到了，但也许质量有问题，你怎么知道他这个东西的质量是不是合格？

还是影响其他的？

对，有的时候他说“我做完了”，但是我根本就不能用，每跑一步都是有很多臭虫（bug）蹦出来，这也是很常见的问题。所以我们设计了一套比较严格的Quality Gates，你自己功能组做完之后，要通过所有测试程序，你才能把功能放到我们总的数据库里面。这套东西包括localization（本地化），因为我们的产品都有很多种语言版本，你localization有没有做过、测试过？像德文的字符串会非常的长，可能英文本来这么长的一句，变成德文就会长一倍，这时在你屏幕上显示，会不会有什么东西给砍掉，这种测试有没有做过？我们还有做代码覆盖率，你的代码覆盖率跟单元测试有没有写完，你的单元测试有没有写到50%、60%代码覆盖率，没有达到这个程度，我们是不允许你check-in（签入）的。另外你有没有测过新功能对原来的性能有没有任何影响，原来的性能，比方说应该是0.5秒就跑完的，你加了新功能之后，是否现在变成要0.7秒或者1秒才跑完？另外，你有没有做集成的测试，这些东西都是我们Quality Gates一部分。所以你做一个东西要把这些东西全部都满足了，才能让你允许你到软件包里面去。这样每进来一个东西，都是相对来说比较高质量的东西，这也是我们在Visual Studio 2005版本里学到的一个比较惨痛的教训，因为在做Visual Studio 2005的时候，我们并没有采用这种方法，所以很多程序做到一半，差不多可以演示了，我们就让它Check-in了。因此之后，我们花了很长很长时间使每一个功能真正达到高质量，但是这个性能已经放在产品里面去了，又很难把它再给拿出来，所以当时产品延期（的原因）跟这个有非常大的关系。我们现在改变做法，每一个功能组做的每一个功能，都要达到高性能，你才能把它集成进去，这样你等于是每一步每一步都是稳扎稳打。从一个产品的质量来说，基本上是我每一个产品放进去之后，如果不做其他的产品，再花几个月让它整个集成稳定一下，就应该可以把它发布的，到这样的程度才让你集成。这从敏捷开发来说，你可以很快地体现这个价值，这也是一个敏捷里面非常重要原则之一。

也有人说在Visual Studio这个产品中去集成敏捷开发项目，完全是微软的一个应景之作。因为敏捷现在很热，在这个产品里面去集成敏捷可能更加好卖，因为微软可能没有完全理解敏捷的精髓，它里面有个原则：个体和交互胜过过程和工具。你对这个看法有没有什么自己的解释？

我给你讲个故事。我在微软Visual Studio做过一个职位──开发总监，开发总监这个职位实际上非常有趣的。怎么样让类似Visual Studio有几千人的开发团队能够互相协调、共同前进，是一个很关键的事情，因为你面对的对象是几千位工程师。比如，我们自己会推动很多不同的流程，你跟他们说，一个工程师没有遵循一个什么流程，把我们每天的Build给破坏了。今天你提出要遵守这个流程，过两天你说你要遵守那个流程，或者这边再加一步，在那边再加一步，在这个时候你会发现你可以给他们很多流程上面的规矩，你要做一二三四五，但是他们是记不住的，他们在做的同时他们有很多考虑。

不是流程化的东西？

不是流程化的东西。我后来就发现，如果没有一个工具去帮助实现这些规矩的确话，你要靠每一个工程师都记住这些规矩，那是非常非常难的，基本上是不可能的。所以，我们就做了另外一套东西。在工程师把代码check-in之前，我们要求他做可能有六、七步不同的东西。而且我们常常又发现一个比较常见的问题，再加一个步骤，这个时候如果有上千，就算有几十个工程师，保证每一个人都记得有这么一回事情并做到，实际上是很难的事情，这是人员管理上面的一个难题，因为工程师有很多要考虑的东西。你要是真觉得什么规则是非常重要的话，就把它做到工具中，所以每个开发工程师，在check-in之前，要做code review，要跟对应的测试工程师做buddy test（伙伴测试），看看有没有问题，之后还要做unit test （单元测试）， 跑一堆测试工程师的测试，把这些事情都做完，才能够check-in。我把这套东西全部变成了一套工具，然后就变得非常简单。比方说，谁帮你做code review了，你把那个人的名字放进去，测试工程师帮你做buddy test是谁，把他名字放进去，你的unit test，跟你下面的测试，以及后面的集成测试，我们用工具帮你跑了，跑完以后确实没有问题，就帮你自动check-in。全部做成工具化后，这套流程对工程师来说是非常简单的，如果单元测试要加新程序进去，我就把它做在工具里面，工程师也不用记，工具跑下来没有问题就可以帮工程师check-in，如果不行就打回来。所以，工具是起到一个辅助的作用，工具不能保证你什么样是最有效的，这需要团队的管理者跟团队一起去决定。工具不能帮你决定现在去北京还是去上海，还是去三亚，这个问题要团队自己解决。但是工具帮你最快实现目标。

因此我们自己运用了很多Agile方面的东西，试用我们自己开发的Team Foundation Server，所以我觉得我们对敏捷的理解是基于我们工具实施上的，并不是我们的应景之作，应该是用我们的教训，把它变成了一个工具，我们自己在用，也希望我们用户也能够使用。

我也知道在Visual Studio新版2010里面，MSF 5.0，比从前有了很大的改进，能不能给我们简单的介绍一下，它主要的改进是在什么地方，特别在敏捷开发方面？

我们Visual Studio Team Foundation Server在2010版本里确实有非常大的改进。从最简单的来说，我们2005和08的Team Foundation Server，从一开始的Setup，把它这个安装起来，就是一个相对来说比较困难的事情。我们在这上面其实做了很多的投资，（把它变成）非常简单，就是下一步、下一步，帮你全部设置了。

从敏捷开发来说，我们很多的团队，尤其50、100人、200人的团队，他们下面肯定有些有关联的分支，我们在Team Foundation Server分支的管理上面，在2010也有非常大的提高。举个我们Visual Studio的例子，Visual Basic Compiler是一个分支，C# Compiler是一个分支，C++ Compiler又是一个分支，我团队在做的SharePoint Tools又是一个分支，Office Tools是另一个分支，这些都是不同的分支。这之间有很多关联，在Team Foundation Server 2010里面我们有一套可视化的东西，你可以知道每个分支是从哪一个分支上面延伸下来的，就像树一样。很多时候，你会知道哪一个check-in的东西可能会需要搬到另外一个分支上，可以让你非常简单易行地管理它。而且从敏捷开发上面来说，这里面有些非常重要的项目管理，包括burn-down chart，集成以前资源，资源里还有多少工作需要进行，我们在Excel上全部帮你实现了，帮你管理这些报表。同时，因为SQL Server是Team Foundation Server的数据库，你可以很容易用SQL Server的报表功能来生成你领导所需要的报表。

很多时候团队需要共享资源，在微软每天早上一个开发工程师进办公室后需要知道前一天晚上的build出来没有，在什么地方，有没有什么问题。你昨天晚上睡觉的时候，也许中国的测试团队，给你找到了很多的臭虫，又发现了什么问题。晚上集成build后，我们会运行一整套测试，测试里面又出现了什么问题，今天还有哪些本来要做的backlog任务、工程要做，这些东西你现在作为一个工程师，可能要去各个地方通过不同的工具来把它找到。在Visual Studio的Team Foundation Server里面，我们给你做了等于是一个门户，每一个工程师一上班，对所要的东西都一目了然，这是在我们SharePoint Server的基础上面做的。

我以前在做开发经理的时候，盯得最紧的，第一是还有哪些开发任务没有做，另一方面就是每天产生的臭虫。每一个人产生的臭虫，我都非常快地看一遍，这对开发管理人员来说非常重要，不是说我真的想知道这个臭虫应该怎么解决，我会很宏观地看一下，有个大致印象，这个产品里面哪个部分臭虫特别多，然后可能过了一星期发现，为什么我这一部分一个臭虫都没有看见，这可能是因为开发人员特别厉害，也有可能是这个测试人员特别差，或者协调中间忘了，测试人员根本就不知道有这么一个场景。作为管理者，你要有这种宏观概念，而且可以很快地生成一些报表，知道这个到底有没有问题。

如果你的开发团队比较大，几十人开发团队，一个开发人员比较好，做得又快又好，另一个开发人员可能改这个臭虫改得很快，但下个星期他改的臭虫里又生成很多臭虫，这是很常见的问题。虽然他臭虫改得很快，他生成速度也非常快，说明他改的过程中没有考虑周到，那你怎么能够知道这些开发人员到底在做多少事情。在敏捷开发里，你还要知道同样一个任务，给这个人和那个人，两者可能需要的时间是不一样的。怎样定义分配多少时间、监督每个人是否按时完成，你给他规定的时间是否准确。因为你第一个里程碑的时候可能定义不准确，也许这个任务对第一个人来说太简单了，你给他三天，他两天就做完了，那么下一次，有类似的任务，你给他两天就够了。对另外一个工程师，也许他觉得这个任务比较有挑战性，要花的时间相对比较长。这些数据你都要汇总之后，你才能做你下一个里程碑的规划。如果你不去考虑这些问题，你下一个规划做出来一定有很多的错误。敏捷开发另一个很重要的基本原则，你每做一个规划，每做一个迭代，都是一个学习的过程，你什么地方做的对，什么地方做的不对，你把这些经验再放到下一个迭代的规划里面去，这样你每一个里程碑都比上一个做得更好，更贴近你想做的，跟你实际做到的越来越吻合，这才是敏捷开发的精髓之一。这是一个逐步完善的过程，如果没有敏捷开发这个精髓，我跑上来，就把我下面五个里程碑全部给换了，中间要再调整其实是非常困难的。

最后一个问题，对于那些想基于Visual Studio去实施敏捷的团队，比如50到100人的团队，能不能给出三到五条建议来？

第一，希望大家赶紧开始使用我们的Team Foundation Server，因为Team Foundation Server在2010版本中另一个很大的改进，就是对“跨平台”的支持。以前大家都认为它只适合用.NET或者C++的项目，我们在Team Foundation Server2010版本中大大提高了对“跨平台”的支持。Team Foundation Server实际上是开发了一个平台了，上面有很多Web Services，和API，有一个Teamprise公司就是用这些API另外做了一套客户端，可以在Mac上面跑，也可以在Linux、Unix上面跑，也可以集成在Eclipse里面。我们刚刚收购了Teamprise，（通过）这个公司，我们会进一步支持这种跨平台的模式。这样很多项目，用户常常会用Java做服务器端，用.NET做客户端。这时，如果你把两个项目分开管理，实际上不是一个最好的方式，现在我们给你Team Foundation Server，你可以在同一个服务器上把整个项目，不管你是用什么平台来做，都可以把它整合在这个服务器上。而且它和我们的Microsoft Project，也有非常好的集成，那就给管理者很大的便利。真正的大的50、100人团队到底在做什么，有哪些问题，哪些东西是你需要去关心解决的；哪个团队做得好，对项目最后的影响是什么；哪些用户的场景已经做出来了，现在开始跟用户的交流了，这些问题就会变得非常的一目了然，这是第一方面。

第二个方面，刚才说的工具，是给管理者提供的。但有了这个工具，并不等于取代了管理者的重要性，管理者还是主导的。你要建立一个高效的团队，团队成员之间，互相要有一种非常合作的（精神），要有同样的目标，大家都知道在做什么，工具只能帮助你进行这种交流，但是管理者的工作程度和难度并没有完全减轻。因为你每设计一个目标，需要团队的认可，让他们能够全心全意地、目标一致地前进，这种精神、这种力量，不是说哪个工具可以帮你做到的，还需要管理者实现这些事情。

最后，我们在用Team Foundation Server进行敏捷开发的时候，要时时刻刻记住敏捷最重要的精髓，不要让过程化的东西来妨碍我们的思维，不要把自己放在一个条条框框里面，敏捷一定要一二三四五。敏捷最最重要的是，根据不同的用户场景、需求，可以很灵活地调整实施方案。这个项目上用法成功了，并不等于说这套方法在另外一个项目上完全可以照搬的。你还要分开来考虑不同的因素，可能客户需求不一样，下面工程师的质量、长处各方面会不一样，因而实施方案会有不同。记住敏捷就是用最好的方法帮你来实现你的项目，它最主要的是跟用户有非常多的交流，帮助你的团队能够团结一致地、很快地朝一个非常明确的目标行进，这些才是敏捷的精髓。

感谢你接受我们的采访。

谢谢。