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