“伟大的使用Visual Studio的程序员，他继承了整个项目团队的光荣的传统，盖茨大叔这一刻灵魂附体！程序员一个人，他代表了整个团队良好沟通精诚合作的历史和传统！在这一刻！他不是一个人在战斗！还有项目经理，架构师，测试人员！他不是一个人！！”
个人程序英雄主义一去不复返了
图1，程序超人
求伯君！
王江民！
鲍岳桥！
以及如雷贯耳的盖茨大叔！
他们凭借自己的个人才华，在当年用双手敲出了风靡一时的各种软件，最终成就了自己，成了令众人羡慕的英雄。
现在的程序员越来越多，但是“英雄”的名字再也没有听说过了。在那个盖茨大叔认为“无论对谁来说，640K内存都足够了”的年代，程序员可以凭借自己的个人才华，用双手敲出一个独立的软件，一个完整的系统，就像求伯君的WPS，王江民的杀毒软件一样。但时至今日，要完成一个比较完善的软件，对于单个的程序员来说，已经是不可能完成的任务，只能是汤姆克鲁斯的“MISSON IMPOSSIBLE”了。Windows XP的代码超过2000万行，加上各种其他组件，代码量接近3000万，那么Windows 7的代码量就更加可想而知。如果现在你还梦想着一个人完成一个系统，我只能说你是程序员中的“唐吉坷德”，是当代的“愚公”！
如果你还做着个人程序英雄的美梦，是时候醒醒了。
你不是一个人在战斗
图2，你不是一个人在战斗
从你的座位上站起来，看看人头攒动的开发大厅：
对！你不是一个人在战斗！
现在已经不是一个人就完成整个软件，包办软件整个生命周期的需求分析，架构设计，编码，测试甚至后期的维护的时候了。现在的软件开发，已经成为一个分工明细的工厂化制造。在为了开发一款软件而组织起来的项目组中，有负责管理的跟技术无关的项目经理、有负责系统整体架构设计的架构师、有负责编码实现的程序员、也有负责测试的测试人员。
在以往的时候，项目中的这种种角色，各自使用自己的工具软件进行工作，长枪短炮齐上阵好不壮观。项目经理使用Project，Excel等制定项目计划，进行任务划分和分配，架构师使用Rose进行架构设计，而开发人员则使用Visual Studio进行编码，到了测试人员那里，他们又使用开源的CPPUnit等工具进行测试。这些工具软件被简单松散地集合在一起，几乎可以称得上八国联军了。各个软件之间无法进行信息流的沟通，软件开发流程和项目管理流程两者是完全分裂开的，导致信息在项目内部的阻塞，造成项目成员之间的沟通不畅。
微软看到了这种软件开发趋于团队作战的趋势，同时也看到了这种近乎单兵作战各自为政的现状，所以在Visual Studio Team System中提供了协同一致的应用程序生命周期管理工具，让参与软件开发的各种人员，从架构师到开发人员，从项目经理到测试人员，都能够更加容易地在整个应用程序生命周期管理(ALM)过程中进行协作。是的，你不再是一个人在战斗！
Visual Studio Team System为项目团队中的各种角色提供了合适的工具，并且将这些工具以Team Foundation Server为核心整合在一起，增强了软件开发团队中的沟通与协作，使得整个团队不再是单兵作战，而是成为一个有机的整体。
We say UML
如果一个东北人到了四川，他可能会怀疑自己是不是还身在中国；如果一个程序员听架构师对他大讲特讲什么系统层次，组件构件，他可能会怀疑架构师是不是来自火星，怎么就听不懂架构师所讲的东西。这些问题，都是语言不通造成的。
在以往的开发中，架构师用各种各样的图表来描述系统的架构，而程序员更容易理解的是实际的代码。当架构师向程序员描述整个系统架构的时候，程序员往往会因为不熟悉架构师的语言或者表述方式而对系统的架构有所误解。这就像两个说着不同语言的人，产生误解是难免的事情。
现在，我们有了解决的办法：我们都说UML这种统一的语言。
UML已经成为了建模语言的事实标准，架构师都习惯使用它来描述系统的各种行为，而程序员也能够很好地理解这种建模语言并用编程语言将它们实现。这样，当架构师和程序员都在说同一种语言的时候，团队中的沟通就更加顺畅了。
图3，We say UML
在Visual Studio 2010中增加一个新的项目模板，叫做“建模项目”，通过这个模板，我们可以快速创建一系列UML图，目前可以创建UML 2.x 13个图中的5个，另外还可以创建层图和有向图（.dgml）。
图4，Visual Studio 2010中的UML图
在架构管理方面，VSTS 2010通过新的架构浏览器(Architecture Explorer)和架构层图(Architecture Layer Diagram)，以图形化的方式描述系统架构，从而使得项目中的技术人员或非技术人员都能以模型透过图形化的方式进行协作，以及定义企业与系统功能。现在连项目经理都可以自豪地说：现在我终于可以听懂架构师在说什么啦！
打通团队沟通任督二脉
一个软件项目最大的成本是什么？
硬件投入？不是！
人员培训？不是！
请客吃饭？不是！
沟通成本！没错，沟通成本是一个软件项目的最大成本。
在一个软件项目中，因为沟通不畅而引起的成本随处可见：需求分析师因为和架构师沟通不畅，导致架构师的设计并不是客户的需求；架构师因为和程序员沟通不畅，导致程序员实现的并不是架构师的设计；程序员因为和测试人员沟通不畅，导致测试人员并不能完全覆盖程序员的所有代码，完成程序员所需要的所有测试工作。可以想象，最后出来的产品跟客户的真正需求相差了十万八千里。
项目组中团队成员的沟通都很重要，但是最重要和最频繁的沟通应该是程序员和测试人员之间的沟通：程序员需要根据测试人员的测试报告对软件进行调试，以修复其中的bug；而测试人员也同样需要程序员提供的代码更改，进行更加有针对性的测试。为了打通这项目沟通中最重要的任督二脉，VS2010提供了一系列有力的工具。
在项目实践中，程序员往往抱怨测试人员提交的Bug无法重现，是一些无效的Bug。现在VS2010提供了一个全新的功能：高级按键精灵。它可以全自动录制测试的整个过程，可回放，可以定制的测试。这样开发人员在看到测试人员录制的测试过程之后，可以轻松地重现所有Bug。另外，VS2010中也推出了虚拟实验室自动化处理方案，名为Visual Studio 2010 Lab Management。当测试人员在虚拟机环境下测试并找到一个软件Bug的时候，只用一个基本的点击就可以把整个环境的镜像点(多个虚拟机)记录下来。他可以把这个镜像点的链接，作为附件自动内嵌在Bug报告中，同时可以选择包含更多的信息，比如带时间坐标的视频，操作记录，历史调试记录等等。程序员得到这个软件Bug报告后，不必询问测试人员到底做了什么，以及重新配置 Bug重现的环境。只需点击链接，即可得到一个基本的实验室环境视图，其中可以包括多个虚拟机环境，他可以用一次点击就可以恢复所需的整个环境状态。开发人员就拥有了整个环境，包括历史环境下的调试工具和代码，找到导致软件Bug的事件发生的顺序和流程。这样，重现测试人员提交的代码再也不是难事了。
另外一方面，程序员在修改代码之后，测试人员就需要重新运行所有测试用例，虽然代码修改并不会影响其中的某些测试用例。测试人员常常也会抱怨，程序员为什么不告诉他们，哪些测试用例受到影响需要再次运行，而哪些测试用例不会受到影响。为了解决这个沟通问题，VS2010提供了两个重要的新视图：测试影响视图(Test Impact View)和代码变更视图(Code Changes View)。
图5，Test Impact View
通过这两个视图，程序员可以更加了解代码修改对测试的影响。当开发人员变更代码的时候，测试影响视图会分析哪些测试需要运行以验证代码变更。这将帮助测试人员只运行必要的测试以对代码变更进行验证，从而对签入的代码充满信心。新的测试影响视图显示了代码变更后必须运行的测试的列表，同时显示了每个测试所影响到的代码变更。而代码变更视图则显示了所有代码变更的列表，同时显示了为了验证这个代码变更所必须运行的测试。这样就避免了运行全部测试来验证某一个小的代码变更所造成的浪费，使得测试更加高效。
用VS2010打通程序员和测试人员之间沟通的任督二脉，自然整个项目组沟通舒畅，神清气爽，开发效率自然提高不少。
本文转自高阳 51CTO博客，原文链接：http://blog.51cto.com/xiaoyinnet/409290 ，如需转载请自行联系原作者
