1 / 40

编程任务估算的艺术

编程任务估算的艺术. Adriana Lopez 龙腾世纪 2 （ Dragon Age ）开发总监 II. 我们为何来到这里 ?. 个人估算的改进. 问题. 是否曾有人要求你为某项任务提供一份估算 … 最后却被证明错得离谱 (>2x)? 结果你经历了什么后果？. 后果是什么？. 游戏质量差 与其他团体的协作差 在你的上司或同事面前，你的可信度受损 哦，又要加班 接二连三地加班. 综述. 基本概念 何谓估算？ 为何估算有难度？ 如何使估算变得更简单？ 问题？. 何谓估算 ?. 估算 …. 是对一项任务工作量或其复杂程度的预测。

trey
Download Presentation

编程任务估算的艺术

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 编程任务估算的艺术 Adriana Lopez 龙腾世纪 2（Dragon Age）开发总监 II

  2. 我们为何来到这里? 个人估算的改进

  3. 问题 • 是否曾有人要求你为某项任务提供一份估算… • 最后却被证明错得离谱 (>2x)? • 结果你经历了什么后果？

  4. 后果是什么？ • 游戏质量差 • 与其他团体的协作差 • 在你的上司或同事面前，你的可信度受损 • 哦，又要加班 • 接二连三地加班

  5. 综述 • 基本概念 • 何谓估算？ • 为何估算有难度？ • 如何使估算变得更简单？ • 问题？

  6. 何谓估算?

  7. 估算… • 是对一项任务工作量或其复杂程度的预测。 • 应该反映出固有的不确定性： • “我想这任务将花3到8天。” • 应该由实际从事该工作的人员来提供。

  8. 估算… • 具有准确度与精确度两个方面。 • 准确的估算 —— 实际值在估算范围内。 • 避免范围太大（范围太大的估算没有价值）。 • 精确的估算——范围很小。 • 避免那些没有数据支持的容易产生误导的所谓精确。

  9. 估算… • 让项目能对其资源进行计划与组织。 • 准确且精确的估算使得项目能按时、按预定方式完成。

  10. 为何估算有难度？

  11. 低估与高估 • 研究表明，编程人员通常会低估完成一项任务所需的工作量。

  12. 不完整的要求 • 在项目进行中过早提出。 • 在大家还不不知“它”是什么之前，就估算“它”要花多长时间。 • 用户不清楚自己想要什么。 • 我看到“它”时就知道。 • 我们没有问恰当的问题。 • 要记得同时征询到功能性及非功能性要求。 • 区分不完整要求与不稳定要求

  13. 不确定性圆锥体 是项目管理的术语，用于描述项目各阶段的不确定性水平 由Steve McConnell推广普及的一个术语。 估算可变性 项目生命期

  14. 个人估算做法 • 提供低估算的压力 • 管理层需要达到某个目标。 • 来自同伴的压力。 • 记住： • 更低的估算 != 更好的程序员 • 避免“即兴的”估算

  15. 个人估算做法 • 被省略的活动 • 编程活动 • 非编程活动 • 没有理由的乐观 • 支持某估算的理由未以数据为依据。 • “我们现在更聪明了” • “不可能那么糟”

  16. 个人估算做法 • 主观性 / 偏见 • 获得某特定结果的愿望（有意识或无意识的） • 不熟悉的问题领域 • 缺乏经验。 • 缺乏历史数据 • 将你的估算建立在以往绩效的基础上。

  17. 项目混乱 • 区分目标与估算 • 确认一下，是要求你进行切合实际的估算，还是要求你达到某个目标。 • 不要提供“即兴的”估算 • “即兴的”估算可能变成目标/承诺。 • 学会对要求进行协商。

  18. How do we make it easier?

  19. 规划 你卷入了什么样的情形?

  20. 你卷入了什么样的情形? • 项目组长关心的是，要完成议定的工作范围，全部工作量是多少。 • 总工作量是个别任务的总和，并且基于你所认为的该项工作的复杂性/规模 • 采用估算技巧来解答这个问题。

  21. 技巧1：设定一根基线 • 基于时间的估算: • 工作小时数 • 理想天数 • 复杂性估算: • XP (经验分) • 复杂性分 • 头痛之事 • 啤酒 • 允许范围： 1,2,3,5,8,13,20… • 实际工作是以实际时间（例如:小时）进行衡量的。

  22. 技巧 2: 协作 • 减少个人偏见。 • 如果没有协作： • 该估算将取决于问到谁，什么时候问。不要想当然地认为最可靠的估算来自于那些最能说的人。 哎，伙计，这得花多长时间? 2 Zzzz 5

  23. 技巧 3: 三角系 • 将新工作与以往的工作相比较。 • .需要历史数据。 • 要前后一致！

  24. 技巧 4: 分解 • 将大的任务（用户故事）细分成具有以下特点的小的任务（用户故事）： • 你更熟知的 • 只需花短短数天时间 ~ 10,000 XP A – 2 XP B – 3 XP C – 1 XP

  25. 规划 • 运用这些技巧来达成一个受以下方面影响最小的估算： • 被省略的活动 • 无理由的乐观 • 主观性 • 偏见 • 不熟悉的问题领域

  26. 规划 • 要记得记录下你的估算！ • 要得到先前任务的数据，你必须着手开始将估算写下来。 • 在执行期间，将其作为帮助你监控及改进自身绩效的一个工具。

  27. 执行 80% 的时间花在20% 的工作上

  28. 记录下实际花费的时间 • 处理许多个人估算问题的最有效方法。 • 关键是要有一项明确、不含糊的任务。 • 明确的任务让你能够区分缺陷与变化。

  29. 你的时间都花在何处？ • 练习：在下一个用户故事（user-story）或任务中，请试着跟踪你的时间使用情况。观察一下你把时间都花在了何处。

  30. 回顾 我是如何做的?

  31. 我是如何做的? • 问以下问题： • 你工作有多快？ • 你的估算与实际结果有多接近？ • 我是否忘了对有利于下次任务估算的某事项作出预测？

  32. 对结果进行分析 • 有用的计算 • 速度 • 你工作有多快？ • 相对误差大小 (MRE) • 你的估算与实际结果有多接近？

  33. 例子 – Part 3a, 速度 • 速度是指单位时间完成的工作量 • 分数: 7 XP / 3个日历日 = 2.3 XP / 日 • 工作量: 9.5 小时 / 3个日历日= 3.2 小时 /日

  34. 例子 – Part 3b, 相对误差大小（MRE） • MRE 等于ABS (实际 – 预期) / 实际 • ABS (9.5 – 7) / 9.5 = 0.26

  35. 更新未来预算 • 不要为了得到一个更好的结果数据，而在任务结束时，对原始预算进行篡改。 • 估算会随时间而变化，对之要有预期。 • 随着项目的进展，要求将被喜欢或全盘改变。 • 记住“不确定性圆锥体”

  36. 总结 • 提高估算的准确性与精确性，是我们每个人的责任。 • 警惕不良个体估算做法 • 运用协作技巧 • 收集并分析数据 • 运用分析来改进未来估算

  37. 总结 • 找到一种适合自己的方法。 • （要确保该方法仍适用于你的项目）。

  38. ¿问题? • “对于由非定量方法得出、并且由管理人员基本凭直觉认可的估算，很难对其进行有力、可信的辩护。” • Fred Brooks

  39. 参考 • 由Construx Software 提供的10x软件工程学（Software Engineering ）课程(http://www.construx.com) • Steve McConnell所著的《软件估算》（Software Estimation） • Mountain Goat Software (http://www.mountaingoatsoftware.com/)

More Related