评估软件评估:不切实际数字的确定迹象?

• 一个人完成了评估,而不是使用基于共识的评估(以充分理解隐含的需求范围),例如 Wideband Delphi
  • 尤其是如果进行评估的人不是执行评估的人!! -我曾经参与过一个项目,据别人估计,在给出任何要求之前60天。就说我不是一只快乐的兔子吧
• 没有时间记录。
• 没有时间提升(就学习和团队规模而言)。

没人说过,所以我会的。显而易见的答案是,如果您有软件进度估计,那么这肯定是不现实数字的迹象。是的,评估软件的方法有很多,但没有一种在任何方面都是准确的,无论是形状还是形式。通常的情况是设定了最后期限。如果任务被高估了,那么额外的时间就会花费在使结果更好上。如果任务被低估,那么就要牺牲一些东西来满足交付(比如测试和特性)。

我知道这个答案不是人们想相信的,但估计总是一种猜测。通常情况下,开发人员甚至无法预测到一天结束时他们将完成多少工作。你期待着他们在未来数月/数年的时间里猜测一些他们甚至还不确定真正涉及到什么的事情。

对于您的问题,唯一不容易给出不切实际结果的实用答案是使用工作表,该工作表根据您公司以前的历史进行猜测。不幸的是,这不能解释估计员错过的任务。至少这可以给出大概的数字。

除非你一次又一次地开发同一个精确系统的仿制品,否则任何认为他们已经发现了这一点的人都是在自欺欺人。涉及的变量太多了。

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

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

• 高层体系结构;
• 测试时间;
• 上升时间;
• 缺陷处理;
• 记录时间;
• 相关培训;
• 依赖性(例如,在团队B交付阶段1之前,团队A不能做他们需要做的事情);
• 风险。

第二种类型的任务估计,通常要低得多。对于这种估计,它应该是一个简单的任务分解(没有任务大于5天)。

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

• 管理层的估计是什么 想被告知吗?
• 是吗 估计很符合实际情况 下一个月的计划装运日期 释放
• 管理层有奖励吗 那些给好消息更多的人 人们会报坏消息吗?
• 是 在知道谁之前准备好的估计 你会在做这个项目吗?
• 做 有人想要那一点 估计
• 有没有历史 软件迟到了?
• 这正常吗 开发人员将被转移到其他 在项目的中途完成任务?
• 有 部分或所有开发人员放弃了 将糟糕的估计作为 浪费时间?

数一数你得到肯定或可能答案的问题数量。

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

• 无交叉参考
• 估计量的背景
• 细节 -正如在几篇不同的文章中所说的,我喜欢看到这两个特性的细节,以及完成每个特性所需的任务。我看到的大多数评估都没有在正式的演示中显示细节,但是如果你问做评估的人,他们应该在某处有一个文件。但愿这不是沾有啤酒和番茄酱的餐巾纸的背面。:)
• 记录的假设
• 平衡生命周期 -不管任务如何分解,设计、代码和测试的比例是多少?文档、与外部系统的集成和发布后支持如何?那些非常重要的额外事情(系统管理员、CM专家、管理工作)怎么样?
• 松弛的 -我相信廉价的公司守护进程会来折磨我,但时间表和成本应该会有一些松懈。如果在一个有经验的人看来,这个估计值是雄心勃勃的,具有侵略性的,那么它很可能太低了。估计几乎从来不会太高。

一个很好的启发是看看测试时间和开发时间是否大致相同。这是估计的一个好迹象。

如果他们不能给你一个估计的细目,那就是一件坏事。通常是很多可能被遗忘的小事情的迹象。他们不需要提供完整的原始细分,只需提供如下细分:

• 要求
• 测试
• 打包和部署

他们应该使用标准模板来计算他们的估算。他们不需要在每一列中都列出一个数字,但他们会按照模板列出所有可能的任务。这样,在进行估算时,模板可以用来激发人们的思维。

如果估算过于精确,例如0.25小时的增量,那么对我来说,这是一个坏消息。

是否缺少需求捕获、测试、部署和向任何Ops小组移交等内容?如果其中任何一个丢失了,那就是那种会回来咬你的东西。

编辑:

嗯

• 是的编译器 估计可用并愿意 与其他高级项目进行讨论 成员?如果不是的话,这通常是一个问题 涉及

• 估计数是否已发送给客户 之前 经验与教训 开发人员的技能是 知道。两点估计可能会有所帮助 但只是在某种程度上。

• 在有机会查看评估之前,您会被告知您承诺在特定日期提供所有描述的功能。

如果您看到其中一个或多个,您可能会有一个错误的估计:

• 单点估计:估计值应与一系列可能的日期或置信值相关联
• 任务粒度不足:一个大的任务桶通常表明功能没有得到很好的理解(这是一个特别的问题,因为理解不好的问题通常被低估)
• 无假设和/或风险的表述
• 为通常被跳过或低估的项目(例如构建脚本、文档、部署等)分配的工作量不足

我同意萨蒂什的观点,我非常喜欢史蒂夫·麦康奈尔的《软件评估:揭开黑色艺术的神秘面纱》。他有几个清单,这些清单在审查和/或编制估算时很有用。

我完全同意Dunk的观点, 糟糕估计的第一个迹象 仅仅是一个庞大的详细的前期计划。估计值正是这个,近似值,否则我们称之为估计值 准确的

要考虑的最重要的一点不是 精确 估计的数目,但 . 如果有第三方为您做评估,那么请查看他们的成功或失败历史,与他们过去的客户交谈,并确定他们的可靠性。

总而言之,从敏捷的角度来看,我们试图在项目期间获得更一致的估计的一些方法是:;

• 使用相对尺寸标准(S、M、L、XL)而不是基于时间(理想天数)。
• 关注复杂性而不是时间
• 始终使用团体评估,而不是单人评估
• 在整个项目中经常收集评估,通常在每个sprint开始时收集
• 在确定故事的复杂性时,使用以前冲刺的反馈
• 跟踪速度,以确定相对大小

表3、6或12个月的估计值(基本上是任何 圆形的 (数字)充满猜测的味道。通常,当你猜到你选择了一个比你想象的更大的整数时——四分之一、半年等等——通常都是可疑的。我更喜欢根据实际开发迭代(无论大小)进行估算。

什么是显而易见的,而不是如此 软件薄弱的明显迹象 手

在对手头的任务缺乏详细了解的情况下给出的估计通常是不好的。

也许您可以采取的一般方法是检查需求中的项目是否与估算中的项目一致。如果你想快速检查相对大小,如果一份10万字的简报有100字的估计,那就不可能是正确的。

另外(正如其他人所说)检查是否提到了分析、编码、调试、测试、集成、应急等。这表明一些想法已经进入其中。

在各个阶段都有成功和签准标准是一个很好的迹象。如果他们有一个确定的点,至少完成了10%,如果估计是错误的,你很早就知道了,并且有机会适应。如果在“完成”之前没有检查点,那么在到达该日期之前,您可能不知道自己落后了。

评估人员与工作人员的熟悉程度如何?

我经常看到有一个普通人做这项工作,即使团队是由背景非常不同的个人组成的。最有可能的是,任务和专业不完美地排在一起,你得到了一个C++服务器端程序员,他们最终完成了你的GUI或者数据库…有时,团队经理并不真正欣赏团队成员的长处,因此,如果因为团队忙于上一个项目而要求他自己提出估算,你会发现所讨论的工作实际上只适合团队的一部分(不激励、缺乏技能等)

评估估算的另一个有用方法是将其与以前类似项目的实际投入进行比较。用于比较的最佳数据将是该组织已完成的以前项目的工作数据。如果没有组织历史数据,您可以尝试根据行业基准对估算进行基准测试。

我在上面写的很多东西都归功于这本书:

软件评估:揭开黑色艺术的神秘面纱 史蒂夫·麦康奈尔

我对照人力来核对估计。虽然不是一个非常精确的启发式方法,但很明显,如果一些大规模的工作只有一个或两个dev分配给它,那么任务的估计是不正确的

一个好的估计将有一个好的细分,涉及项目的所有阶段。

它几乎肯定不会在方便的日期完成。

它将包括各种各样的风险。

如果在开始时有延迟,那么在结束时也会有延迟(表示为从开始算起10-12个月,如果我们现在开始,则表示为2010年第1季度左右,而不是2010年1月项目尚未开始时的情况)。

假设和依赖性将清楚、显著地列出。

编辑:这部分取决于项目所处的阶段。早期但准确的估计是一个警告信号,特别是在没有指定置信区间的情况下。这听起来像是一个普罗克斯特式的估计。

以下任何一项:

• 这是一个大项目,没有描述一个简短的高层战略
• 该项目不是围绕逐渐交付的业务价值而构建的
• 整个项目有“详细”估算(与之前的项目相关)
• 第一阶段没有详细的估计,或者这些估计有问题。

“四到六周” ,当没有分解为较短的任务时。。。