敏捷项目时间管理的不同之处
传统项目时间管理方法 | 敏捷项目时间管理方法 |
---|---|
固定的范围直接决定项目的进度 | 范围在敏捷项目中是可变的。时间可以固定,并且开发团队可以只处理在特定时间框架内能够实现的需求 |
项目经理根据项目初期收集的需求确定项目时间 | 在项目进行过程中,Scrum团队反复评估在给定时间框架内他们能够完成的工作 |
在需求收集、设计、开发、测试和部署等多个阶段,团队同时处理所有的项目需求,并且对关键需求和可选需求同等对待 | Scrum团队以多轮冲刺的方式开展工作,优先完成高优先级、高价值的需求 |
团队在项目中后期,即需求收集和设计阶段完成后,才开始实际的项目开发 | Scrum团队显然在第一次冲刺就开始了产品开发工作 |
传统项目的时间更容易变化 | 在敏捷项目中,冲刺是在时间盒内完成的, 具有固定的冲刺周期 |
项目启动阶段,项目经理在对产品知之甚少的情况下,就试图预测进度 | Scrum团队基于冲刺的实际开发绩效来决定长期的进度计划。在项目过程中,随着Scrum团队对产品和开发团队的速度或速率的了解逐步加深,他们会调整时间的估算 |
- 敏捷时间管理方法
- 敏捷开发团队比传统项目团队更早交付产品,受益于更早的开发工作并在迭代中完成功能。
如何在敏捷项目中管理时间
-
敏捷方法论
- 敏捷方法论在进度和时间管理上同时提供战略和战术上的支持
- 战略级:早期的计划实际是战略级别,【产品路线图】和【产品待办列表】上的高层次需求可以帮助形成对整体进度的初步认识
- 战术级:为每次发布和冲刺所做的详细计划都是战术级别
- 发布计划阶段:可以将你的发布目标确定为在某个具体的日期前完成且可上市的最小的产品特性集
- 冲刺计划:选择范围,开发团队预估完成每项冲刺需求的相关任务所需要的小时数,【冲刺待办列表】可用于在冲刺过程中管理详细的时间分配
- 敏捷方法论在进度和时间管理上同时提供战略和战术上的支持
-
速率
- 速率简介
- 敏捷项目时间管理中,预算长期时间表的强大工具
- 速率就是一个开放团队的工作速度
- 可根据开发团队在每次冲刺所完成的用户故事点来测算速率
- 监控和调整速率
-
计算速率
- 平均速率:已完成的故事点数 / 已完成冲刺的个数
- 案例:平均速率:20 = 已完成的故事点总数:80 / 冲刺数:4
冲刺1: = 15 点
冲刺2: = 19 点
冲刺3: = 21 点
冲刺4: = 25 点
-
使用速率估算项目时间表
- 计算方法
- 合计【产品待办列表】剩余需求对应的故事点数
- 将故事点总数除以速率,可以确定需要进行的冲刺数量
- 如采用最悲观估计,则使用最低速率
- 如采用最乐观估计,则使用最高速率
- 如采用最可能估计,则使用平均速率
- 将冲刺的周期乘以冲刺数量,可以得到完成【冲刺待办列表】上的故事所需要的时间
- 计算方法
-
提升速率
- 移除项目障碍
- 规避避项目障碍
- 消除干扰
- 征求团队意见
-
有用速率的一致性
- 一致的冲刺周期:每次冲刺应该持续相同的时间
- 一致的工作时间:开发团队成员应该可以投入相同的时间
- 一致的开发团队成员:人员稳定
-
- 速率简介
-
从时间角度管理范围变更
- 新需求的加入可能对一个项目的时间表没有任何影响,仅仅做的是对需求进行优先级排序
-
多团队时间管理
- 多Scrum团队协作定义
- 项目很大,远不止 5 ~ 9 人
- 项目必须在某一个特定日期结束,而Scrum团队的速率不足以在此之前完成最有价值的用户故事
- 多团队工作分解
- 每个团队按照主题或者产品特性的逻辑分组来分解工作
- 思考主题的整体范围以及相互间的关系,这些工作任务需要被充分分解,以便各团队独立运作
- 配备集成团队,职责是将开放团队开放的可工作产品特性进行整合并实现交付
- 多团队结构
- 多Scrum团队协作定义
-
使用敏捷工件进行时间管理
工件 | 时间管理中的角色 |
---|---|
产品路线图:是将那些支持产品愿景的高层次需求按优先级排序的整体视图 | 产品路线图是对整个项目优先级的战略视图。产品路线图很可能不会指明具体日期,而是为各组功能给出大概的时间范围,并勾勒出产品上市过程的初步框架 |
产品待办列表:它是当前已知的全部产品需求的完整列表 | 在产品待办列表上的用户故事只有估算的故事点。当你知道你的开发团队的速率,你可以使用产品待办列表上的故事点总数来确定一个切实可行的结束日期 |
发布计划:包含可上市最小需求集合的发布计划 | 发布计划将会为特定目标确定一个预计发布日期,这个目标将包含可上市功能的最小集合。Scrum团队每次只会围绕一次发布做计划并开展工作 |
冲刺待办列表:包含了当前冲刺的需求和任务 | 在冲刺计划会议中,你可以估算待办列表上的每个任务所需要的小时数,在每次冲刺结束时,你根据冲刺待办列表上的所有已完成的故事点来计算出本次冲刺中开发团队的速率 |
敏捷项目成本管理的不同之处
- 传统成本管理和敏捷项目成本管理的对比
采用传统方法的成本管理 | 采用敏捷方法的成本管理 |
---|---|
成本与时间一样都是基于固定的范围 | 项目的进度,而不是范围,对成本的影响最大。你可以在固定的成本和固定的时间下启动项目,然后完成符合你的预算和进度计划的需求 |
在项目启动前,组织会估算项目的成本并为项目拨款 | 项目负责人常常在项目路线图阶段完成后才确项目的投资。一些组织甚至每次只为敏捷项目的一次发布拨款。产品负责人将在完成每次发布计划后确保提供资金 |
新的需求意味着更高的成本。因为项目经理是基于他们在项目启动时所了解到的少了信息做出的成本估算,所以成本超支的现象会非常普遍 | 项目团队可以在不影响时间或者成本的情况下,用新的、同等规模的高优先级需求替代低优先级需求 |
范围膨胀在一些人们几乎不使用的特性上,耗费了大量的资金 | 因为敏捷开发团队是根据优先级来完成需求的,所以无论产品特性是在项目伊始还是在第100天加入,团队都只关注那些客户真正需要的特性 |
项目只有在项目完成后才能产生收益 | 项目团队可以在项目初期就发布可工作的、能够产生收益的功能。从而实现自筹资型项目 |
- 如何在敏捷项目中管理成本
- 敏捷项目中,成本通常和项目时间直接相关
- 团队成本,以每小时或人均固定费率
- 硬件、软件、许可证,以及其他开销成本
- 敏捷项目中,成本通常和项目时间直接相关
- 创建初始预算
- 需知Scrum团队每次冲刺的成本以及任何额外资源的成本
- 额外资源成本:
- 硬件成本
- 软件、包含许可证成本
- 托管成本
- 培训成本
- 团队费用杂项,比如额外的办公用户、团队午餐、差旅费,以及可能的任何费用
- 案例:
团队成员 | 每小时费用 | 每周小时数 | 每周成本 | 冲刺成本(2周) |
---|---|---|---|---|
唐 | 80美元 | 40 | 3200美元 | 6400美元 |
佩吉 | 70美元 | 40 | 2800美元 | 5600美元 |
鲍勃 | 70美元 | 40 | 2800美元 | 5600美元 |
迈克 | 65美元 | 40 | 2600美元 | 5200美元 |
总计 | 160 | 11400美元 | 22800美元 |
- 利用速率来确定长期成本
- 通过提高速率来降低成本
- 移除障碍
- 通过减少时间来降低成本
- 放弃低优先级的需求,从而减少需要冲刺次数
- 确定其他成本
- 通过提高速率来降低成本