小型软件项目，通常是指工作量在3-12人月之间的项目，在小型软件开发企业中，这类项目一般是放任自流，少有管理。在这类项目中，项目经理的角色常常由公司老总或部门老总亲自充当， 项目往往具有投资少、人员少、时间紧、需求不明确等特点。由于针对小型项目，缺乏科学有效的管理方式，或企业难以负担类似于大型软件开发的管理成本，这类项目的开发过程往往会产生诸如项目进度难以控制、产品缺陷多、后期维护工作量大、客户满意度低、文档缺乏等诸多问题。一项调查表明，大约有70%的小型软件开发项目超出了预期时间，90%以上的项目费用超出预算。因此，小型项目迫切需要引入适度的开发管理。本文将针对小型软件项目开发过程中的核心管理问题给出一些行之有效的解决方案。
一、需求管理
对于任何类型的软件项目，需求阶段都是最重要的阶段，需求管理是整个软件项目管理的重中之重。需求管理通常包括两个大方面的问题：需求收集分析与需求变更管理。
首先，对于需求收集与分析，核心风险来自于需求不明确。由于客户和软件开发团队的背景不同，对同一问题的理解自然存在差异。这些差异如果不能在需求的最初阶段尽量弥合，那么必然导致需求增加与需求更改。因此，在需求分析阶段，要求需求分析人员具有丰富的客户沟通经验，必须多花一些时间，充分了解用户的目标与工作过程，站在客户立场上，设身处地考虑问题，帮助用户将模糊的需求清晰化，将简略的需求明细化、完善化，将混乱的需求逻辑化、条理化。
其次，任何项目都无法承受频繁的需求变更与需求增加。因此，除了在需求收集阶段需要尽可能将需求细化外，还需要在适当阶段尽量冻结需求。公司的销售人员往往倾向于接受用户模糊的要求，并暗示用户“什么都好商量”。这往往给项目后期甚至项目完成后又频繁更改需求，甚至导致项目严重拖延、开支严重超出预算埋下祸根。因此，在需求细化的后期阶段，必须“拉下脸来”，就需求冻结和后期需求增加的费用支付方式和客户达成共识。
二、关注项目设计的灵活性
对于中小型项目，在设计过程中，必须关注设计的灵活性。在实际的项目中，即使在需求阶段花再多的经历，也没法完全避免开发阶段的需求变更。因此，在架构设计中，尽可能采用灵活的设计就至关重要。对于项目设计人员，可以借鉴RUP(Rational Unified Process)中基于组建的体系结构思想，利用基于独立的、可替换的、模块化组件的体系结构管理复杂性，提高重用率，构建有弹性的、能适应变化的、易于理解的、有助于重用的体系结构。
三、开发进度管理
开发进度管理，主要需要关注如下几个方面：
1. 任务分配、人力资源分配、时间分配要和工程进度协调;
2. 任务分解要合理，并且尽量并行化;
3. 对项目进度控制要尽量细致，并且在实际执行过程中审查要严格;
4. 针对项目中不容易控制的部分，譬如技术难点、来自于客户的时间拖延要做好充分的准备;
5. 要为测试、缺陷修正和预期的需求变更预留足够的时间;
如有必要，还应采用适当的协同进度管理工具。
四、开发团队管理
对于开发团队管理，要做到分工明确、因人施用。根据水平的高低，合理分配工作量。并且关注团队内部的交流沟通结构，避免“互相等”和“误解”。尽量让每个人的工作量饱和化。在项目开始以后，要尽可能保持团队稳定，避免人员变更给团队带来的协作混乱。
五、配置管理和SQA
软件配置管理(SCM)的主要作用是标识、控制、和状态统计。
这些功能的意图是维护和跟踪功能、配置、产品、产品基线、需求规约和其他文档的变更，软件版本的描述;跟踪变更申请，问题报告和解决记录，提供配置控件委员会(CCB)会议纪要等。
软件开发之后的变更需要从多个侧面加以注意:
1. 任何返工都是有代价的
2. 将资源用于返工则无法开展新项目
3. 如果变更不能精确的标识和控制，那么软件的版本就会因为未知和没有记录的修改而无法跟踪
4. 如果变更没有考虑到所有的副作用，那么对于一个变更所引起的连锁反应的跟踪是非常费时间的
5. 变更次数的增加会使系统面目全非
当项目经常变更时候，SQA是非常重要的。SQA应该进行Pareto分析和趋势分析以确定引起变更的根本原因。SQA同时要保证系统的影响是可跟踪、可测试和可验证的。SQA的一个主要目标是在开发的早期发现问题，避免其进入下游开发中。
六、文档管理
对于小型项目，首先，必须有文档要求，否则后期的修改、维护、升级都会变得异常困难;其次，对文档的要求应该“适度”，即够用即可。一切以便于后续工作为目标，不做过于繁琐的要求，不应把大量精力投入进过于繁琐的文档编写。此外，还应注意文档的版本控制，保证文档和代码的一致性。
评论