敏捷软件开发ASD-09-敏捷估算和计划.pptVIP

敏捷估算与计划 尹俊文 国防科学技术大学计算机学院 Agenda 问题和目标 估算规模 针对价值的计划 进度安排 跟踪和交流 敏捷计划的工作机理 A Case Study 1 问题和目标 敏捷估算和计划中问题和目标 计划的目的 计划失败的原因 敏捷方法 1.1 计划的目的 估算和计划是困难的，而且通常是不准确的 Project Management Institute 数量级的估算，误差范围+75%~-25% 预算估算，误差范围+25%~-10% 确定性估算，误差范围+10%~-5% 估算不确定性锥 计划的原因 良好的计划过程通过以下方法得到项目价值: 降低风险 减少不确定性 更好地支持决策 建立信任 传递信息 敏捷计划的特点 关注作出计划的过程更甚于作出的计划 鼓励变化 产生易于修改的计划 延伸到项目的整个过程 1.2 计划失败的原因 基于活动而不是基于特征的计划 多任务导致进一步的推迟 没有按照优先级开发特征 忽略了不确定性 估算变成了承诺 基于活动而不是基于特征的计划 活动不会提前完成 帕金森定律：Work expands so as to fill the time available for its completion. 一个预期5天的计划，其潜台词就是开发人员可以用5天来完成任务 延误沿着进度表向后传递 活动不是独立存在的 多任务导致进一步的推迟 项目成员身兼数职对生产率会产生可怕的影响 多任务的背后——满负荷工作 提高速度的假象 满负荷的开发人员和满负荷的高速公路是一样的！ 没有按照优先级开发特征 许多传统计划的制订都假设所有识别的活动都可以完成 因为所有活动都可以完成，所以在客户看来，开发团队的工作顺序是相对偶然的 这样的结果是随着工作期限的迫近，团队不得不放弃一些特征 这些特征的放弃是用户愿意的吗？ 有一个故事叫《最后期限》 忽略了不确定性 传统的计划方法缺少对不确定性的认识 忽略了产品的不确定性，而且假设初始的需求分析可以得到产品完整和正确的规范 进度表通常表述为单个的绝对日期 是不是表述为为各时间范围更好呢？ 处理不确定性的最佳方法是迭代！ 估算变成了承诺 任何估算都包含了一种可能性，否则就不是估算 估算表明一项工作在估计的时间内完成的可能性 一个软件明天完成的可能性为0，而100%能完成的时间期限是20年，那么在此期间完成的可能性为0～100%的一个值 把估算等同于承诺，是一个严重的问题 明天下雨的可能性是99%，你可以承诺明天肯定会下雨吗？ 2 估算规模 敏捷估算规模方法 基于故事点的估算规模 使用理想日的估算 估算技术 重估 故事点和理想日之间的选择 2.1 基于故事点的规模估算 一种简单有效的故事规模估算方法是从已经交付的故事中寻找一个相似的故事。 如果不能找到相同规模的故事，那么可以寻找更大的或者两倍规模的故事。 估算是团队努力完成的活动 故事点是相对的 故事点是一个用户故事规模的相对度量。 故事点是相对的 可以采用两种公共的方法进行估算 select the smallest stories of you’ll work with and these stories are estimated at 1 story point. Select a story that seems somewhat medium-sized and give it a number somewhere in the middle of the range you expect to use. assigned a story point value to the first story, each additional story is estimated by comparing it to the first story or to any others that have been estimated. Velocity Velocity is a measure of a team’s rate of progress. If a team completed ten story points of work last iteration, our best guess is that they will complete ten story points this iteration. Velocity Corrects Estimation Errors 2.2 Estimating In Ideal Days How long is a game of football play? Ideal time is time without interruption where you can