敏捷项目管理实践

背景：

        我们是一家专为政府开发软件的企业，前些年可能是项目任务多、或是管理上的问题，大部分的项目无论是进度、质量上都出现了问题。所以2013年开始采用项目管理的方式，试图解决这些问题。目前项目管理流程分为6大阶段：1项目计划、2需求调研、3概要设计、4详细设计、5开发、6测试（并且每个环节会有审核）。实施了项目管理流程以后，因为每个环节都预留了相应的时间，而且各环节都会有审核，所以需求方面比以前有了显著的提高。但是由于一些外部原因（需求变更、相关政策调整）项目还是会经常切换，导致计划也无法正常完成，而且使用瀑布模型以后响应速度也变慢了（当需求发生改变，导致需要更新需求、概要、详细、计划等文档，并且需要重新审核），所以我一直认为敏捷开发是比较适用的,所以我设想的项目管理流程是也以敏捷做为模型的。

敏捷项目管理流程：

1.收集用户需求

        把用户提出的需求原封不动的记录下来，这个阶段的重点是竟可能多记录一些用户需求、客户想法。收集需求的时候你可能会发现有些需求明显不合理、或者多个需求之间存在矛盾的地方，但是为了保留用户最原始的要求以及让收集需求工作变得简单，所以暂时先保留这些不合理、有歧义的需求吧（也可能是需求分析人员认识程度不够）。
阶段输出：用户需求单

2.设计系统功能

        一切相关的设计文档都放在这个阶段实施。主要的工作包括根据收集来的需求，从中筛选出合理的需求（排除不合理、相互矛盾的需求），进行功能设计。需要注意的是这里设计的功能点并不是最终的项目范围，这里除了有满足需求的功能以外，还会有一些提升用户体验的功能（锦上添花的功能），最终如何取舍还是要根据项目的进度、成本情况而定。又根据敏捷迭代的特写可以把这个过程产生的功能点看做是系统功能范围缓冲池，有新的需求或想法可以添加进去，然后根据实际情况从中筛选最终（阶段）的系统功能范围。

阶段输出：概要设计、详细设计（可能没有）、系统功能设计清单（重点是未列入系统系统）

备注1：要写多少设计文档、写到什么程度。可能根据项目的复杂程度都有所不同。但是根据我的经验、大部分信息化系统通常都不会过于复杂，所以我的做法是写一个概要设计，只对某些复杂功能额外添加详细设计。其实设计究竟需要细化到什么程度主要还是要开发人员说了算的，写到开发人员认为理解的程度就好了。

3.工作分解

此阶段就是识别出完成项目究竟要做多少事情即项目范围，包括1. 前期工作（需求调研、功能设计这些比较固定的步骤）、2.项目验收时需要哪些配套文档、3.系统功能范围、4.工作分解结构要求。这里最重要的当然是3系统功能范围，框定了最终的项目需要哪些功能。最后工作分解结构要求是对工作分解结构的要求进行详细的说明（主要是针对产品需求开发）备注：把功能中一些要求列举出出来，指导工程师开发及测试。

阶段输出：工作分解结构（大部分工作是指系统功能范围）、工作分解结构说明

4.制定项目计划

工作分解结构（系统功能范围）、及资源就能为项目制定项目计划了。当然这是一种比较理想的状态了，如果项目的需求不是非常清晰、或者可能需要同时在多个项目中切换工作那么推荐使用阶段计划（阶段需要实现的功能）。把根据功能点的重要性筛选一部分的功能作为阶段计划。

阶段输出：总体计划、阶段计划

备注1.起初的总体计划肯定是相当不准确的，通过阶段计划的执行、项目过程中的变更情况进行调整。

5.分配任务

根据当前计划中需要完成事项，布置相应任务。任务来源主要是工作分解结构的内容，还有一些保证项目正常进行的事项如Bug修复等。

阶段输出：任务单

6.汇报项目情况

项目经理在项目执行过程中需要对项目进行监控，监控内容主要包括：1进度情况（依据工作分解结构）、2阶段任务完成情况等。

阶段输出：项目报告