1.1.2 软件开发问题

然而在目前的软件开发过程中经常还会或多或少地存在以下一些问题。

（1）版本管理难以控制

项目源代码和相关文档的版本控制，对项目来说是至关重要的，当前常用的几个版本管理工具有：Visual Source Safe （VSS）、Concurrent Version System（CVS，并行版本系统）、Rational ClearCase & ClearQuest（CC）、Team Foundation Server （TFS）、Subversion（SVN）等，这些版本管理工具中，有些不支持多人对一个文档的同时操作（尤其是源代码）、有些支持多人同时操作，但功能还不能满足大规模软件开发过程的需要，如自动合并的功能。这几个版本管理工具的功能对比如表1-2所示。

（2）项目沟通不够畅通

在项目实施过程中，团队成员由于分工不同而承担不同任务，项目经理负责控制项目进度、协调项目组内部和客户之间关系，需求分析师负责调研需求形成需求文档，开发工程师负责功能开发，测试工程师负责软件测试，因此需要团队所有成员有效地分工协作。但是随着网络技术的应用与发展，项目所涵盖的范围越来越广，项目变得越来越庞大、角色更多、分工更细、团队也愈加分散，这主要表现在以下方面：

● 有的项目成员在一起工作，但是也有很多不在一起工作；

● 由于分工的细化，有些角色的成员只负责某一方面的工作，如需求分析师只负责需求；

● 有些角色成员并不会参与整个软件过程；

● 角色的差异导致许多问题无从解决，或者无意识地对计划产生了分歧；

● 不同角色的成员有不同的沟通方式，对同一问题的不同理解，或者具有某种角色的成员不善于沟通（如有的开发人员性格内向、独立、自尊心强）；

● 团队里还有小团体；

● 项目管理者与项目参与者之间的沟通存在问题。

案例&场景

项目经理小张最近负责了一个电子商城的项目，这个项目不是一个太大的项目，但是这个项目对小张来说绝对是一个“难做” 的项目，因为客户的要求大大超出了项目需求分析说明书和项目详细设计说明书里所指定的内容。

本来项目在6月30日就通过了详细设计说明书，客户（甲方）也在详细设计说明书上签字盖章了，为了签这个字，小张可是没有少熬夜，加班加点，眼睛红通通的，花了3个星期连改了7个版本。虽然客户签了字，但是还有遗留的一个大问题没有解决：客户还没有最终确认网站首页。

马上就要进入开发阶段了，无奈之下，小张只好调整了开发计划，让开发团队开发后台管理功能，要美工接着做一个新版本的首页。而小张一方面要接着同客户沟通首页的问题，另一方面还要掌控项目的最新情况。

三天后，新的首页发给了客户，小张等待客户确认。过了两天，客户还没有任何反馈，小张有些着急，电话告知对方（客户），可客户没有收邮件，还没有看到新版本的首页。但客户抽出10分钟看后仍不满意，并且列举了一些同类型网站的例子。由于小张不懂美工设计，所以决定把页面设计与沟通的事情直接交给美工与客户确认。小张只是每天询问美工界面的进度和客户反馈的情况。

半个月后……

后台管理开发已经接近尾声，按照项目进度安排，准备开始开发网站前台。棘手的问题是，网站首页已经改了5个版本，客户还是不满意，并且提出了如下的十几条修改意见：

①主页黄色调，以黄色为主；

②顶部搜索条以上全部修改；

③导航菜单和子菜单颜色不同，每一块一个颜色；

④滚动新闻：背景修改，小喇叭不好看；

⑤图片采用CSS+DIV，不要采用Table；

⑥链接：蓝色，标题、链接文字大小不同、加粗；

⑦大区域颜色可参考其他网站，包括按钮风格，大气、松散一些；

⑧新闻资讯、产品展示列出子类信息；

⑨首页菜单，添加团队订制，只有一个引导页；

……

见到这些问题，小张只好打电话约客户，明天和美工一起去拜访客户，以解决首页设计问题。

这个案例中，有三个角色：项目经理小张、美工和客户。从小张的角度来看，项目经理的职责就是管好项目，项目的任何问题都是项目经理的问题，经过这次事件，小张总结如下。

● 没有及时沟通，如给客户发送邮件以后，要电话正式告之或者通过MSN、QQ等即时通信工具告之客户。

● 积极主动与客户沟通，了解客户深层次需求。

● 在不熟悉的地方需要专业人士的经验，如界面友好性、易用性上，一方面征求美工意见以及设计思路和特点，另一方面可以在项目组内部先征求意见，准备好一些客户可能会提到的问题及应答。

● 在具体技术实现上，要有保留地同客户沟通，如是全面采用CSS+DIV布局还是某些地方采用Table展示，要具体情况具体分析；图标文件是采用单文件还是一个文件使用CSS展示，这些问题要从用户的角度向客户解释；重点突出客户关心的问题，而不是和客户讨论技术问题，如哪种技术时下最流行、最好。

● 转变角色，从开发人员（小张是开发人员出身，并且在项目中承担一部分开发工作）的角色转变到项目经理的角色上，在Coding的时候也能很快地从项目经理的角色转变为开发者的角色。

● 尽可能多地考虑细节问题，Web应用程序是要做给大家看的。

从小张的角度分析了项目沟通中存在的问题，读者也可以从美工、客户、小张的上级、开发人员这些角度去分析项目中存在的问题及解决方案。

上面列举的这些问题都妨碍了正常的项目沟通，也是项目管理过程中常见的一些问题。为了使团队有效地运转，就必须理顺信息交流渠道，采用一些项目管理的方法保证沟通能够正常进行，而且必须让它与成员的日常工作行为相吻合。项目经理在项目实施的过程中，必须认真对待项目的干系人，同他们建立并保持持久的、而不是断断续续的沟通关系。我们都知道沟通的重要性，但是在很多情况下还是没有做好沟通，其根本原因在于以下几个方面：

● 和客户沟通时，需求理解不同；

● 项目组内部没有一整套完整的沟通机制，如工作例会、通气会、专题会议、专题评审会，以及团队建设会议、电话会议、非正式会议、邮件；

● 没有一个完善的平台来消除项目中的信息不对称；

● 没有及时了解到项目的进度和风险。

（3）缺乏集成软件开发工作平台

近年来，虽然软件开发生命周期（Software Development Life Cycle, SDLC）工具已经大量使用了捆绑工具的方法，但是仅仅捆绑工具并不能实现工具集成，而一些常用的集成只是用在数据层和展示层。由于工具的集成性比较弱，很多软件开发中的工作就只能通过手工的方式来进行，下面是一个来自微软的案例。

在“Microsoft信息技术 （IT）”内，Enterprise Application Services （EAS）-e*BIS开发小组由17到21名团队成员组成。这些团队成员组成一个协作小组，其中包括项目经理、项目主管、开发人员、测试人员和支持成员。e*BIS IT开发小组致力于为e*BIS业务单位提供文档转换服务的各种集成项目。完成一个e*BIS项目的管理和开发要使用多种工具和应用程序。SDLC流程中使用的工具和应用程序大都互不相连，无法提供在项目进程中团队成员可轻松地协作和沟通的集成环境。在使用VS 2010之前，e*BIS IT开发小组的工作流程如图1-3所示。

部署VS 2010后，e*BIS IT开发小组使用VS.Net、Microsoft Office Professional 2003、Microsoft Office Project Professional 2003、Microsoft Windows SharePoint Services，将整个SDLC流程集成到一个解决方案中。节省了开发人员时间，使得团队协作更加便利、团队沟通更加顺畅。

现在e*BIS IT开发小组可以作为一个团队高效地工作，合作完成项目流程。包括项目经理、开发人员、测试人员和支持成员在内的每位团队成员都可以使用同一个共享数据源推动项目流程。外部手动流程不再牵制团队的生产力，并已集成到解决方案中。

（4）软件过程选择不当

使过程采纳与过程变得复杂之间存在一个矛盾，即在开发阶段、测试阶段和系统运行与维护阶段开发人员既是最关键的一环，又是最薄弱的一环，不适合的团队成员（特别是整个开发团体）的工作风格，将遭遇到很大的困难，其面临的挑战就是如何平衡可预见、可重复过程的生产效率和创新。当未形成这种平衡时，每一个人都挣扎于成本消耗与实现任务目标的矛盾之中。软件开发的多数过程都以文档为中心，在这种情况下，他们需要额外付出超出维护日常活动的正常流之外的努力。无论团队使用特定的、灵活的或者常规的过程，每一支团队都可以受益于自动且集成的软件开发过程。

（5）软件质量控制

软件的质量是检验软件产品的重要指标之一，只有保证了软件质量，软件项目和软件项目管理才有实际的意义和价值。在国内软件业开始起步的时候，软件企业在质量管理方面比较落后，大部分的软件企业没有设置专门的测试组织和招聘专职的测试人员，软件产品的质量完全依赖于程序设计和编写者的技术水平和工作效果。

虽然国内一些软件企业在2000年左右开始建立内部的测试小组，但仍然只起到了“事后检验”（即在已集成的版本上进行的一些基于用户操作层面上的测试和检验）的作用，大部分的产品质量缺陷仍然无法及时和较全面地被发现和解决，更不用说“预防缺陷”。

即使建立了这种具有“事后检验”功能的测试小组，但由于没有必要的支持，以及人力资源投入严重不足，导致测试小组在软件质量上的贡献和业绩表现不佳。同时由于对产品质量的认识缺乏全面的理解，仅仅建立一个测试小组对产品质量的提升是很有限的。

案例&场景

例如，我国台湾某公司导入微软VS 2010整合性开发平台工具之后，提供专业分工的设计概念，依角色进行所有项目活动分类，让项目成员可以明确了解其权责，依不同负责的职务，在相同平台上进行异地协同开发。透过工作分解结构（Work Breakdown Structure, WBS）展开项目，工作项目可连结源代码与文件，有效减少开发时间，保证了项目质量，并使项目成员不需再切换多种工具平台及重复汇报工作进度。

开发团队对于VS 2010最常运用的功能，是以Team Foundation Server进行工作产品版本管理。在项目质量管理上，使用了VS 2010自带的单元测试、系统整合测试及Bug管理等功能，大大提高了项目质量。透过多维度的自动分析报表，让所有项目成员包含项目经理、高阶主管，可以随时掌控项目开发的进度及质量，进而预估项目实际完成日期。如今，旧系统升级改写的第一阶段已于2008年底顺利上线，在重构系统的过程中，提高了项目质量，更获得高级主管一致的认可及赞赏，并要求其他信息部门效仿，不仅如此，所建立起来的开发方法论亦可用来要求外包供应商，不论是自行开发或是委外发包，都将依循相同标准。

（6）项目需求管理

在软件需求中，目前存在的问题是：

● 客户放大需求；

● 项目经理需求加工；

● 分析人员技术加工；

● 编程人员断章取义。

根据CHAOS Report发布的报告显示，项目失败的十大败因中，与需求相关的有5个，其中缺乏用户参与（12.8%）、不完整的需求（12.3%）、需求变更频繁（11.8%）、不切实际的用户期望（5.9%）、没有清晰的愿景和目标（5.3%），这些因素累计占比接近50%。由此可见，需求在软件开发过程中的重要性。

案例&场景

如某石化企业的开发虽然采用了微软的MSF（Microsoft Solutions Framework）软件开发方法论，但针对石化行业企业项目的特殊性，VS 2010平台中的部分管理模块必须做相应的调整，于是对企业的研发团队针对需求分析管理等需求在VS 2010平台上做了二次开发，形成一个特有的模板来支持产品的需求分析功能。VS 2010平台的这种灵活性使得其可以充分满足石化行业企业的项目需求，既提升了开发效率，也保证整个开发过程的规范性。“我们利用VS 2010平台来支持开发，在实践过程中不断去摸索，不断修正开发过程，然后发布适合我们团队和研发中心的一个模型。”某领导说。

“我们按照规范的要求进行数据的收集、检查、分析、对比，这样有利于我们在统一平台上进行沟通，提升管理水平。”某领导说。

……

针对石化企业客户的经营管理软件很难产品化，因此企业的业务模式主要是根据客户的管理需求以项目的方式提供解决方案。而针对项目的软件产品研发具有很强的定制特性，同时也需要通过CMMI认证来解决个性化产品的稳定性问题，VS 2010平台正好为这种开发需求提供了一个既灵活又规范的统一平台。