Visual Studio 2005 改善团队开发的人力负担与协调默契

VS2005创新的功能，都是为团队开发与管理，使所有开发角色均融入此平台中。

VS2005为落实软件开发生命周期与流程管理，而明确区分角色（但同一人可担任多种角色）与权责，让企业重新调整组织结构，却可能带来额外的人力负担，以及信息共享的困难。

角色与分责所增加的人力负荷
VS2005采用软件开发生命周期，作为企业在选择信息系统发展方法论（System Development Methodology）时的标准流程，其特征是将开发流程区分为几个连续阶段（3个~20个不等），标示着不同的系统发展成果，实作时则配合专门的技术角色（分析师、架构师、开发人员、测试人员与项目经理等），目的是容易管理、分层负责与确保软件质量。VS2005则在软件开发生命周期中定义出区分架构师（Architect）、开发人员（Developer）、测试人员（Tester）与项目经理（Project Manager），并将软件依角色区分为3种版本：Team Architect、Team Developer、Team Tester等，项目经理的权责则包含在Excel或Project上，可与Team System整合。

以工具区分角色的做法对大型开发团队而言，终于有对应的专属工具，但对中小企业而言，通常由一人扮演多种角色，而不同角色下工具却能强迫兼职的人不至于混淆工作，以致于难以追踪工作进度（这是造成中小企业软件项目常「重工（Re-work）」的原因）。

另一点附带的优点是应用软件生命周期对中小企业主管而言，仍是艰涩的观念，但微软却可以透过功能与版本的区分，再加上整合，使初学者跟着工具所规范的功能，即可以完成软件开发生命周期。

角色与分责是软件工程化的精神之一，我们可以用半导体制程的方法来比拟，生产线将晶圆的制作手续上区分为黄光制程、薄膜制程等，各制程紧守着本身的生产责任，达到整体流程标准化（SOP），而制程整合工程师负责排除制程缺陷问题，并确保高良率等。但角色与分责使得企业的开发团队中常一人分饰多种角色的问题，以及人力精简的目标又重回原点。为了角色与分责势必增加人力，但这对企业而言，原本因为信息单位只是消耗预算的单位而精简人力，若为了软件质量而朝向工程化，形成两难的局面。即使敏捷式开发方法能解决人力问题，但企业中开发角色的赋予，并非如工程师所愿。他们常因为主管的临危受命下担任救火队的角色，使得角色混淆问题严重，VS2005虽立意良善，但企业势必在现实与工具间取得平衡点，而且还要取得所有成员的共识，否则万用的瑞士刀只是用主刀来切水果，不免大材小用，而且这样的状况下，VS.NET 2003已能应付需求，不需要升级到VS2005。

团队协同作业难以沟通与培养默契
如果VS 2005只是区分版本，那么过于小看此次改版。软件开发生命周期注重反复式的过程，以逐步提升软件质量，而在反复改进过程扮演开发方向控管的操舵手：项目经理，不再置身事外。VS2005此次也针对项目经理开辟专属的工具：Team System，让项目经理与开发人员因为使用共通的工具而使用共同的语言沟通，不再像是局外人。

Team System也让开发工具转为开发与管理平台，让开发人员可以分享资源，更重要的是让项目经理可以从集中式平台监督软件项目。以往开发工具为单机版时，各成员的工作成果均保留在个人计算机，项目经理仅能透过威胁利诱的方式，才能汇整各成员的成果成为项目进度，但此时项目经理不但被架空，而且形同虚设。

为了管理创意成果供货商莫不绞尽脑汁，像Borland便在StarTeam产品中内建Repository（中央储存库），这是一种中央控管的数据库，用于有系统与结构化地储存软件开发过程的各式数据、图表与程序代码等。微软则在Team System连结SQL Server 2005达到相同的功能，而且N-Tier架构强迫软件工程师在开发过程便进入项目控管，而不是写完程序后才决定要不要归建到项目档中。这让开发更有效率，也让软件工程师专注在程序开发上，而不是与管理有关的琐碎、例行事务上。

VS2005触及开发团队合作的痛处，这牵涉到开发人员技术本位与文人相轻的老问题。「软件黑手（俗称Hard Coding的工程师）」与规画架构的架构师不平等的工作任务与负担，以及最后把关的测试工程师所背负的压力，都会在团队中形成各自为政的问题。最常见的是测试工程师与开发工程师难以取得协调，以及资历高于项目经理的资深工程师，对流程与管理的抗拒，特别是这些人掌握旧式语言（如corba语言）或旧型主机（Legacy System）的维护等，使得项目经理的权威受到挑战，以及对团队向心力都形成威胁。单从工具的角度无法面对这些问题，然而，以工具要求团队合作只是让问题浮上台面，但企业可能没有心理准备面对这个积弊。

项目进度控管与信息共享矛盾
VS2005实作软件项目管理，并不同于一般我们所谓的项目管理，目前技术上能实践的部份，仅只于与软件工程所要求的软件质量相关的绩核项目，例如原始程序代码或臭虫数量等。

项目入口网站（Project Portal Website）主要是突显出项目管理并非项目经理本身的事，而是所有关系人（Stakeholders）都应了解，随时随地都可看到最新进展。此外，软件开发项目的特性是集合各种技术专精的人员，入口网站有助于分享信息，这在台湾中小企业的信息项目正面临这个严重问题，也就是成员将技术信息藏私，以展现他在团队的地位。James Lewis提出两个建议，能让项目运作更有效率：

1.重要成员拥有较充足的信息时，许多的决定就可以自行处理，不必事事求教于项目经理。

2.信息具有自我组织的特性，当所有团队成员都能一同分享项目经理的信息，并加以使用时，对整个团队的帮助最大。

简单地说，无论是项目经理或工程师，对任何成员蒙蔽信息都会造成不满，并延烧到其它成员而瓦解向心力。微软也注意到信息分享在软件项目上的重要，当VS2005每次新增一个专案，便会对应在内建的WSS（Windows Sharepoint Services）上对应开启一个WSS网站，不仅用于项目现状与臭虫数量回报等。此入口网站也支持Excel与Project（VSTS可取代Project Server），项目经理在指派任务后，将任务分配上传到WSS网站或整合所有信息。现实中，信息部门常因为紧凑的接案与结案等过程，少有喘息空间，遑论有空分享信息与文章，而且入口网站的绩效报告是工作上的无形压力，多数人不会主动面对。

开发流程与创意、弹性的冲突
微软在VS2005工具中用于描绘软件开发生命周期的方法论（Methodology）称为：Microsoft Solutions Framework（MSF），涵盖软件开发与基础环境部署等完整流程的中介模型（Meta-Model）。VS2005内建两种主流的流程模板，分别是MSF for Agile Software Development与MSF for CMMI Process Improvement。顾名思义，前者适用于小型团队所使用的敏捷式开发流程，讲求测试与原型（Prototype）、较短的开发循环与持续整合等；后者则适用于大型开发团队，注重严谨的开发流程，并符合CMMI（Capability Maturity Model Integration）Level 3的要求。

开发工程师的毛病是技术本位，缺乏管理的思维，当然也缺少被流程制约的性格。另一个问题是他们常被项目挤压时间，而这些项目都是主管为了利润而接回来的，此时，他们会为结案而牺牲各阶段性流程上所需的报告、文件等成果，并视为末枝小节造成流程混乱。人们都知道工具是死的，但遵守制度考验着成员间的默契。

http://dotnet.csdn.net/n/20060404/88998.html