估算工作

估算工作

• 实用的项目估算方式

  • 通过对比历史数据进行估算：也许可行但是项目是非线性的
  • 通过Delphi 和宽带 delphi方式进行估算，好于项目经理自己估算
    • Delphi 方式：项目经理把团队召集一起，阐述项目有关事宜，大家提问并且写下自己的任务列表和时间估算，同时注明自己对项目的预设条件。然后收集任务列表并进行复查，看是否可并行。项目经理把估算加在一起，得到项目整体估算
    • 宽带Delphi方法：一小组专家会暂时代替项目团队产生任务列表和估算并提交任务列表，预设条件和风险
    • 问题：由于每人只负责估算项目一部分且通常是按架构切分的，会估算过低。应对方式：估算时任务大小和持续时间分开考虑
  • 何时不应相信团队的估算
    • 估算因人而异，做法如下
      • 了解团队，想清楚对每个人在项目中的估算提供多少反馈
      • 去掉每个任务任何额外的缓冲时间，为了确保得到最准确的估算
        • 使用顺序或者迭代式生命周期，估算时可以考虑约束理论：取估算时间长度的一半，再取20%放到缓冲区。不够的话拿缓冲区时间。
        • 增量或者敏捷生命周期，项目经理要收集已完成工作所花费的时间并与估算对比
        • 提供一个信心百分比，一个日期范围或者考虑三个日期：最佳状况，最有可能，墨菲日期
    • 何时向估算中加入松散时间，作为最后一招。跟团队成员定义出一个 估算质量因子
  • 小心顺序式生命周期的估算陷阱
    • 一开始就要估算并要安排整个项目的时间表，项目还很陌生估算会偏差，有时100%-400%之多
    • 一开始就整个项目估算是个陷阱，可先开发一些测算这些时间（试探性开发），然后看项目中有多少类似工作并以迭代方式得到估算
    • 利用信心百分比和日期范围，知道估算的不确定性有多大
  • 使用自信些范围进行估算
    • 不要使用对结束日期的单点估算
    • 后面趋势斜率会变小
    • 不确定锥形：在项目管理中，不确定性之锥描述了项目中不确定性量的演变过程，即不确定性不仅随着时间的流逝而减少，而且也随风险管理，特别是决策的确立而减小。在一个项目开始时，对于产品或工作要求知之甚少，所以估计值有很大的不确定性，上下浮动很大。随着越来越多的研究和开发，对项目了解的信息越来越多，不确定性趋于下降，当所有剩余风险已经终止或转移时，则趋于减少0％。
  • 使用日期范围进行估算
    • 使用日期范围而不是一个确定的日期，让项目不至于受过早承诺之苦
  • 使用三个日期：最佳状况，最有可能，墨菲日期
    • 最佳状况：项目最早的可能完成日期
    • 最可能日期：将一些经验系数，缓冲时间纳入考虑之中，或将估算加以延伸之后，得到的就是最有可能日期。 但也只有80%-90%的把握
    • 墨菲日期：可以在最可能的日期之上加入一些经验系数
    • 估算需要准确性而不是精确性，偏离的差距而不是几时几点完成
  • 在估算时分开考虑人物的大小和持续时间
    • 可以解决习惯性低估工作量的问题
    • 任务大小是指它的规模，可用斐波那契数列来粗略估算任务得到任务的相对大小。
      • 项目团队估算以往准确：用到21，后面用40，60，80，100
      • 有时正式估算前，可以安排探索式开发，以决定任务的真正大小
      • 不善估算的团队，使用21，40，100而非60，80等中间数字
    • 估算持续时间
      • 取出所有为2的任务，看是否大小差不多。如果是，估算这些大小为2任务会持续多少时间，然后除以2就是任务为1大小的持续时间-人时。 设为基本因子，乘以任务相对大小即得到其他任务的持续时间
      • 任务越大，不确定越大，可以进行任务拆分
      • 使用人时估算而非理想日
  • 规划扑克： 整个团队参与
  • 在估算前用试探性开发收集数据：时间更短，2-3 hours/60 hours
  • 让估算更容易提示
    • 估算只是大概值–猜测。给出日期范围，以便别人知道是猜测
    • 很多开发人员是很乐观的
    • 完成一项任务总是要花费比预计更多的时间
    • 估算小块工作更容易
    • 项目经理和团队需要练习估算并收集反馈，没有反馈的估算毫无价值
    • 做好反复估算的准备
    • 如果项目经理必须遵循某个截止日期，那就别估算了。按优先级排序进行开发。敏捷生命周期
    • 如果项目被限制的很死，就用时间盒把各个阶段和任务包围起来
    • 如果任务过大，不容易估算可以先探索性开发

• 用里程碑切分项目

  • 使用基于可交付物的规划来安排任务
  • 将里程碑（或迭代）的结束时间安排在一周之中的某天，周二或周三但不要周五以看到真正的进展，减少加班

• 团队能够不做哪些事情

  • 能做哪些事情的思维方式基于下列假设
    • 人不是稀缺资源
    • 日程安排其实无关紧要
    • 开发成本不是驱动因素
  • 能够不做哪些基于以下假设
    • 对需求的理解是稀缺资源， 理解特定需求，并知道对客户的价值所在，并全心全意交付这些需求才是需要做的
    • 日程安排至关重要，没时间重做也不能留下技术债
    • 项目成本非常重要，应该管理起来

• 身背多个项目时的估算

  • 无法估算，无法预测多任务成员能在此项目中投入多少时间，什么时候投入，需要时可在
  • 多任务会浪费20%-90%的时间
  • 身背多个项目时造成项目延迟，无法按要求交付，无法按质量交付的最大原因

• 主动安排人们进行多任务

  • 项目有些人不必专职投入，如DBA或GUI设计
  • 项目经理可以主动安排人们进行多任务
  • 项目经理会为此付出一些代价：背负多任务的人要完成的工作会花更多的时间，但确保一周只完成同项目的工作，而不是做两个项目

• 使用波浪式规划

  • 不要一开始就把整个项目规划做出来
  • 波浪式规划就是一个持续不断而且很详细的日程安排，只覆盖几周。完成一周再继续安排下一周。四周的波浪式规划比较合适
  • 项目进行中牢记每个里程碑

• 决定迭代的持续时间

  • 迭代时间限制在一到四周， 迭代越短，需求重新排序更容易，更容易适应可能发生的变化
  • 迭代规划时间要短，否则花太多时间在规划上，则没有充足时间开展项目

• 尽可能使用小石子进行估算

  • 小石子就是大任务拆分成小任务，每个小任务不超过两天，通常一天。也就是用户故事
    • 当任务不清楚时创建并使用小石子： 新产品研发或研究项目，用问题来知道一项任务何时完成
    • 如何得到小石子： 每个人都可以划分自己的小石子， 而不是项目经理，技术带头人或架构师定义，否则就是用小石子进行微管理
    • 为何使用小石子： 帮助每个人都能理解项目的任务以及之间的相关性，暴露任务之间的依赖性。有助于创建更准确的日程

总结： 绝对不要提供确定的项目结束日期。 任务越小，估算起来越容易。寻求估算的准确性而非精确性