评估软件估算:确定的不切实际的迹象？

Question

在回答Ash发布的" 处理可怕的估计 "时,我分享了一些我学到并亲自用来发现弱估计的技巧.但我确信必须有更多!

当需要快速评估由第三方(同事,业务合作伙伴或外部公司)编制的软件项目估算时,在场景中使用什么启发式？

软件估算较弱的明显且不那么明显的迹象可以在没有详细了解手头任务的情况下被发现？

Answer 1

• 一个人已完成估算,而不是使用基于共识的估算(以充分理解要求的隐含范围),例如Wideband Delphi.
  • 特别是如果做估计的人不是执行者! - 在我提出任何要求之前60天,我曾经做过其他人估计的项目.让我们说我不是一个快乐的兔子
• 没时间提供文件.
• 没有时间提升(在学习和团队规模方面).
• 没有风险列表及其对时间表的影响.
• 对于意外情况没有缓冲 - 就最近的需求和风险而言.

Answer 2

没有人说过,所以我愿意.显而易见的答案是,如果你有软件进度估计,那么这是不切实际的数字的明确信号.是的,有很多估算软件的方法,但它们都不是以任何方式,形状或形式准确的.通常发生的是设定截止日期.如果任务被高估,那么花费额外的时间来使结果更好.如果任务被低估,那么就会牺牲某些东西来满足交付(如测试和功能).

我知道这个答案不是人们想要相信的,但估算总是一个猜测.通常情况下,开发人员甚至无法预测他们将在一天结束时完成多少工作.你期待他们在未来几年/几年内猜测他们甚至不确定真正涉及到什么的东西.

对于不容易产生不切实际结果的问题,唯一可行的答案是使用根据贵公司以前的历史记录提出的猜测工作表.不幸的是,这不会解释估算人员遗漏的任务.至少这可能会给出球门号码.

除非你一遍又一遍地发展同一个系统的敲门声,否则那些认为他们已经弄明白这一点的人就是在愚弄自己.涉及的变量太多了.

Answer 3

估算有两种类型:任务估算和项目估算.您可以将这些视为大小图片.

项目估算必须是高级别的(粒度通常不小于几天),并且必须包括以下内容:

• 高水平的架构;
• 测试时间;
• 加速时间;
• 缺陷过程;
• 时间进行记录;
• 相关培训;
• 假设;
• 依赖性(例如,在团队B提供阶段1之前,团队A不能做他们需要的事情);
• 关键路径(哪些部分可能决定项目是否下滑以及多少); 和
• 风险.

那些缺失的东西越多,估计就越不现实(或冒险).

第二种任务估计,通常低得多.对于这种估计,它应该只是一个任务分解(没有任务大于5天).

这些不倾向于解决上述问题,但其中一些可能是相关的,例如关于尚未做出的决策的假设(例如生产硬件).由于相关经验,背景知识或技能(因为该人或那些人可能最终过度使用),也可能值得确定谁能够和不能完成任务.

其他帖子提到测试时间应等于或超过开发时间.我强烈反对这一点.我已经看到8小时开发任务导致100多个小时的测试时间和80小时开发任务导致不到2小时的测试.在这两种情况下,测试时间都是完全合理的.这两者之间没有绝对的相关性.充其量,连接松散.

Answer 4

• 估计是管理层想要告诉的吗？
• 估算是否与下一版本的计划发货日期完全吻合？
• 管理层是否会奖励那些提供好消息的人,而不是给人们带来坏消息？
• 在了解谁将参与该项目之前,是否准备了估算？
• 是否有人想要在功能上实施这一点准备估算？
• 是否有软件迟到的历史？
• 开发人员通过项目中途转移到其他任务是否正常？
• 让一些或所有开发人员放弃评估糟糕的估计是浪费时间吗？

计算你得到"是"或"可能"答案的问题数量......

如果您对上述问题的回答大多为"否",那么可能值得详细查看估算值,看它是否包含此线程中列出的其他人的任务.

Answer 5

哇...我真的很喜欢toolkit的答案.

并且我同意任何估计都是有缺陷的,因为它假定估算器比任何估算器实际上在估算项目时更能解决问题.但是,我认为你还需要在开始之前至少估计山的大小.一些人认为是否值得尝试这样做应该先于任何努力,这就是估计的本质所在.

我确实想出了一些危险估计的指标:

• 没有交叉引用 - 如果无法通过至少两种不同的方式验证估计值,则可能不可靠.例如,我做过的最后估计我已经能够将工作细分为小特征块,并考虑我们的团队花了多长时间来做类似的范围特征.然后,我能够查看这些成本的总和,看看范围相对于我工作过的其他项目有多大.这是两种验证方式.
• 估算器的背景 - 如果这是一个软件估计由一个从未编写代码的硬件人员完成 - 非常害怕.更微妙 - 估算者的背景越接近项目的技术和问题领域越好.
• 细节 - 在几个不同的帖子中说了几种不同的方式 - 我喜欢看到各个功能的细节,以及完成每个功能所需的任务.我看到的大多数估计都没有在正式演示文稿中显示详细信息,但如果您询问进行估算的人员,他们应该在某个地方有文件.希望它不是用啤酒和番茄酱沾上纸巾的背面.:)
• 记录的假设 - 任何估算者都必须对该任务做出一些假设.这些应记录在某处,最好是在正式的文书工作中.当我看到一个没有多少记录的假设的简短提案时,我总是有点担心.他们是经过深思熟虑而未与客户沟通,或者他们没有被考虑过.我不确定哪一个更糟糕.不言而喻,这些假设也应该是合理的.
• 平衡生命周期 - 然而任务被分解,设计,代码和测试的比例是多少？文档,与外部系统的集成以及发布后支持如何？那些如此重要的额外事情(系统管理员,CM专家,管理工作)怎么样？
• Slack - 我确信廉价的企业守护进程会来,并且会让我失望,但是时间表和成本应该有些松懈.如果估计对于有经验的人来说看起来雄心勃勃且具有攻击性,那么它可能会太低.估计几乎不会太高.