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