关于敏捷项目的管理办法

关于敏捷项目的管理办法

   最近几年逐渐热门起来的敏捷项目管理，相对以传统的PMP,它更加主张开发团队的自组织和自适应，而传统的PMP则更加主张项目管理团队，尤其是项目经理的过程预判和趋势监控。

   由于敏捷适应和多变的特点，往往给人有一种雾里看花的感觉。因为它没有PMBOK很清晰的列出5大过程组、10大知识领域和49个详细过程方法。其实敏捷也存在具体落地的方法，只是很多时候都是“养在深闺人不识”。

   在众多敏捷项目管理派系中，Scrum+看板方法最为常见。其实很多敏捷项目都是从看板或任务板开始着手落地的，看板方法是遵循渐进变革的敏捷项目管理方法，因其不需要改变现有组织团队的层级架构，备受管理者的垂青。

   以下介绍一个“小而美”的敏捷项目是如何分步骤落地实施的。  

一、明确公司愿景

企业可以制定符合其公司级的愿景(Vision)和核心产品研发的路线图。      

二、定义产品经理

针对具体产品，指定客户或来自公司业务部门的人员成为产品经理。

三、定义用户角色

通过头脑风暴法、名义小组会议、亲和图、虚拟人物和极端人物等方法明确使用产品或系统的用户角色。

四、定义用户故事

产品经理和团队成员共同拟定所有可能的用户故事，每个用户故事的描述基本包括3部分，它们是用户角色、实现功能和所预期的价值。需要考虑涉及非功能性需求的用户故事，比如系统必须能够支持1000个并发用户的同时访问，保持全年99.99%的系统可用性。这些用户故事的描述与系统的验收息息相关。测试人员可以进一步与产品经理讨论和确定每个用户故事的测试验收条件。

五、估算用户故事

团队成员可以通过宽频德尔菲(Delphi)和计划扑克等方法来估算每个用户故事的工作量。工作量的单位可以是故事点或理想日。产品经理和团队成员基于每个故事的价值和花费成本一起排列所有用户故事的优先级。

六、拟定发布计划

召开发布计划会，确定发布的频次，以及每次发布所包含的迭代次数和迭代长度。估算开发团队的速率，即工作效能，可以用每次迭代能够完成多少个故事点来表示速率。将具体用户故事分配到指定的迭代中，通过用户故事地图的方式展示发布、迭代和用户故事之间的关系。

七、迭代开发测试

召开迭代计划会，把用户故事细化为开发任务，启动本轮迭代开发。开发人员在开发的过程中可以应用结对编程、代码评审和持续集成等极限编程(XP)敏捷实践。在开发过程中，通过每日站立会、看板、燃尽图和累计流量图等方法对开发任务的完成情况进行可视化管理。产品经理和测试人员进一步论证和补充每个用户故事的验收条件，并把验收条件与每个用户故事进行关联。通常会把验收条件写到在看板上每个故事卡片的背后。另外，组织可以应用(验收)测试驱动开发(ATTD)的方式来指导开发人员的代码编写工作。

八、迭代评审回顾

召开迭代评审会，对本次迭代所完成的开发任务进行验收。召开迭代回顾会，发现本轮迭代的改进机会，有效的应用到下轮迭代中进行持续改进(CSI)。