1 产品不能确定的情况： 产品按迭代产生开发需求， 开发过程中采用敏捷项目管理
2 产品确定的情况： 开发周期采用迭代的方式， 过程中采用敏捷项目管理
3 以板报的形式召开敏捷会议：项目功能点-末启动的-已完成的-项目目标
WBS
需求确定之后，项目团队的一个非常重要的任务，就是将需求进行WBS，将其分解为可以执行的任务。
在分解任务的时候，需要注意几点：
- 任务分解尽量细致。按照scrum的实践，分解的任务，应该是一个人可以独立完成，最好在4-16小时之间。
- 任务分解应该完整，比如搭建测试环境，购买机器之类的看似无关的任务，也都应该列入任务列表。
- 任务的分派，应当由团队成员自愿认领为主，不要硬性指派。
- 任务类型应该认真选择，这关系到相关需求所处阶段的自动计算
项目进度
项目开展之后，如何来把控项目进度呢？有如下的手段：
一、召开每天的站立会议
注意，是站立会议，所以不能坐着开会。每天固定时间（具体时间根据团队情况而定），团队成员围站成一圈，然后每个人回答三个问题，昨天我做了什么，今天作计划作什么，有什么问题。整个站立会议不超过15分钟。注意事项：
- 不要坐着开会。
- 站立会议不要试着解决问题，大家更多的是沟通互相的进度，而不是解决具体的问题。具体的问题，会后讨论。
- 整个会议不要超过15分钟。
- 站立会议不是汇报会议，而是大家的沟通。及时发现问题。
- 非项目团队成员可以参加，但不能发言。
二、燃尽图
先来解释什么是燃尽图。燃尽图的英文名字叫做 burn down chart，先来看一个例子：
此图横轴为日期，纵轴为工时数。此工时数乃项目中所有任务剩余工时的综合，每天计算一下，形成坐标，然后把线连接起来，形成此燃尽图。
燃尽图的更新，需要配置定时任务
主要工具是燃尽图，而不是甘特图。这也恰恰反映了两种截然不同的管理思路。甘特图需要严格的设置过任务的起止时间和前置关系，是一种控制式的管理。而燃尽图则更关注于做完整体的项目还剩下多少时间。所以甘特图这些工具，实际上传统的瀑布式管理依赖的工具，包括关键路径等。很多项目经理热衷于制定周密的计划，精确的起止时间，然后通过各种各样的工具来控制项目，但往往项目会延期。是这些工具不够好吗？肯定不是。相反我觉得是这些工具太强大了，让人忽略了项目管理的本质。相反，燃尽图以赤裸裸的形式把当前项目的进展状态展现出来，项目的走势如何，一目了然。所以用好燃尽图，可以很好的把握项目的进度。