敏捷项目管理实践

背景：

我们是一家专为政府开发软件的企业，前些年可能是项目任务多、或是管理上的问题，大部分的项目不管是进度、质量上都出现了问题。所以2013年開始採用项目管理的方式。试图解决这些问题。眼下项目管理流程分为6大阶段：1项目计划、2需求调研、3概要设计、4具体设计、5开发、6測试（并且每一个环节会有审核）。

实施了项目管理流程以后，由于每一个环节都预留了对应的时间。并且各环节都会有审核，所以需求方面比曾经有了显著的提高。

可是由于一些外部原因（需求变更、相关政策调整）项目还是会常常切换。导致计划也无法正常完毕，并且使用瀑布模型以后响应速度也变慢了（当需求发生改变，导致须要更新需求、概要、具体、计划等文档。并且须要又一次审核）。所以我一直觉得敏捷开发是比較适用的,所以我设想的项目管理流程是也以敏捷做为模型的。

敏捷项目管理流程：

1.收集用户需求

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

2.设计系统功能

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

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

备注1：要写多少设计文档、写到什么程度。可能依据项目的复杂程度都有所不同。可是依据我的经验、大部分信息化系统通常都不会过于复杂，所以我的做法是写一个概要设计，仅仅对某些复杂功能额外加入具体设计。事实上设计到底须要细化到什么程度主要还是要开发者说了算的。写到开发者觉得理解的程度就好了。

3.工作分解

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

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

4.制定项目计划

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

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

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

5.分配任务