让您的项目清清楚楚，看上去明明白白：

       介绍了上述几个技术性的Team内容后，下面才是VSTS更具“突破性”进步的部分——对于项目生命期管理的支持。项目管理已经被堆砌成许多大部头的书籍，而且专业领域越来越细化，但是总体而言不管方法如何，都是要在“特定的时间段内”、“在要求的资金范围内”、“安排特定的人员”、“按照相应的要求”完成相应的项目。VSTS结合了Project和SharePoint Portal 之后上述所有内容的管理都在一个平台内完成了，也就是一个Team Project的过程。上述因素中具体Team中每个成员都“完成”了（笔者认为看到“在做”还不够明确）什么更加重要，以往项目经理看到的都是一个个报告，报告里开发人员会给出一个个百分比，测试人员同样也会给出一条条曲线，然后经理爬出一个表格告诉高层或者客户代表，您的项目已经如何如何了。好像一切都是无懈可击，可您真的对自己的项目进展报告有几分信任呢？什么叫一个UserInformation类完成了70%了呢？VSTS也许可以更好的给您一个相对更确实的答案，这些又依赖上文提到的Foundation Server。

        对于项目的管理工作而言，除了在VSTS中建立一个Team Project之外，恐怕一开始考虑的包括两个方面：需求的收集和采用何种过程方法，前者您只需要让Project连上Foundation Server，就可以把需求的内容及其各种附件一股脑的保存在一起，对于后者Foundation Server则是通过一组模版的方式帮助您完成，无论您使用的是CMMI还是MSF。之后就可以根据项目参与角色的分工不同分解任务，接着在VSTS中各个参与者就可以看到自己要做什么，而且如果您定义的任务本身是个可以并行且流水的话，那么整个Team的工作也就可以沿着多个并行的任务分支走下去：

l         架构师通过VSTS的分布式系统图作出总体的框架，并做出总体的对象系统划分。

l         部署人员通过VSTS的System Diagram了解到未来的部署环境。

l         设计师根据用户需求里绘制的UI原型了解到怎么把一个更好的体验呈现给用户。

l         开发人员使用VSTS的Class Diagram Designer设计出详细实现的逻辑结构，并用它与其他同事交流。

l         测试人员根据需求设计各种测试用例。

l         各个开发组长则可以随时根据需要分析组内成员的代码质量，进行代码复查。 

上面的整个过程都始终在一个潜在的，最初通过VSTS Foundation Server选择的流程模型中自动的流转着，随着这个流转过程的继续，相应的报告更多地从产品的实际开发过程中根据相关工作成果产生的，而不是某个人拍拍脑袋估计的一个个百分比。所有的这些都被VSTS记录下来，因此无论您的高层是个过程改良的热衷者，还是个“我不关心听过程、我只关心结果”的铁腕人物，VSTS都可以帮助你准备好各种报告。同时，随着产品的不断发布，VSTS的版本控制也非常有用，配合上Setup Project之后项目相关的部署人员也自然而然的被VSTS吸纳到一起，这样做有个明显的好处——减少了歧义，所见的也就是Team Project中实实在在在做的。 

使用VSTS管理项目后，还有个不知道算是好还是不好的作用，就是想偷点懒似乎不那么容易了，因为很多的东西VSTS都显眼的摆在那里。

总结：

       VSTS的功能跨度比起之前的Visual Studio似乎不小，但站在项目不同角色的角度看，综合微软以往产品的发展，又都是那么水到渠成。如果说以前的Visual Studio是每个程序员实现自己职业理想的工具化，那么VSTS则是开发团队释放整体开发潜力的平台。

        VSTS is for team potential and passion.