project-management - 相处,Evidence-Based-Scheduling - 仅是估计值和work-plan它们所基于的表一样准确?

  显示原文与译文双语对照的内容

我已经使用了基于fogbugz的调度( 对于门外汉,Joel解释了 )的证据,有一个固有的问题我似乎无法解决。

系统的概率擅长告诉我一个给定的项目交付日期,考虑到任务的详细清单,包括项目 。 然而,它并没有考虑到在开发过程中,额外的任务总是会弹出。

现在,有garbage-can方法创建一个通用的任务/scheduled-item"最后一分钟攻击"或者"集成任务",等等,但这显然违背的想法聚集许多小的估计情况。

通常情况下,在项目的开发阶段,你意识到你的计划没有涵盖整个区域,因为这是开发之前没有开发的东西的本质。 现在 ~3 月项目很可能变成一个 6月项目,但不是因为你的估计是( 你可以是世界上最好的评估者,对于那些任务,你的初始工作计划就是这样的) ;而是因为你最后加一大堆的新任务,一开始就不存在。

EBS没有帮助你。 理论上是( 我觉得) 。 它可能会度量你在一个项目中添加的工作量,并在估算给定项目的剩余时间时考虑到它。 只是一个想法。

换句话说,EBS在任务基础上工作,但不是在项目/发布基础上- 但是后者是重要的。 这就是你的老板通常关心交货日期,不是时间完成每一项任务,而不是会的时间,如果你的计划是完美的。

问题 ( 是的,这里有一个问题,不要关闭它):

当你在FogBugz中使用EBS时,你的方法是什么,你如何解决上述问题,这似乎是计划延迟和mispredictions的主要原因?

编辑

阅读一些答案后,还需要一些思考:

如果它可以归结为不得不选择交货日期你舒适的展示higher-ups通过眯眼看delivery-probability图,选择 80%,95%或者 60% ( 基于什么,确切地说) 然后我们诉诸于普通缓冲/保理我们的估计。 在这种情况下,我们不能通过用例hour-sized估计步骤跳过细节? 通过强迫自己花一天多的任务分解成小块的工作没有我们只是deluded自己认为我们的计划是那样严格和彻底可以?

人们可能总是不正确的估计,甚至从不从过去的错误中吸取教训。 在这方面,拥有一个EBS系统肯定比没有一个。 但是,我们可以做的是,我们在计划方面还不够好? 我不确定这是否是一个可以通过类似的系统解决的问题。 我们的估计是错误的,因为对某些任务过于乐观或者悲观,并且忽略了系统延迟( 比如 ) 。 病假,主要 Bug 危机,通常是 ,因为我们缺乏关于需要完成的工作的知识。 另一方面,我们的计划通常是不完整的,因为我们在这个早期阶段没有足够的知识;而且我也不知道EBS-like系统如何填补这个空白。 所以我们回到了方法论。 我们需要找到一种方法来适应那些比voodoo-multiplication更好或者不完整的工作计划。

时间: 作者:

这是一个困难的问题。 可以使用历史原始估计小时: 最后估计时间比过去的里程碑和做一些合理的投影的工作多少个小时这个里程碑完成后会发现任务,但是当你观察、ebs( 然而,无论如何) 不这么做。

我做了三个让EBS工作的事情,因为它现在是( 很抱歉,在这里与其他答案重叠):

  1. 尽可能分解里程碑确定,以后可能会有不确定性的项目,但我通常很确定我要做第一 6周左右。 因此里程碑版本有 1 -2数月的工作帮我看看我们是否打开或关闭的任务我们知道。

  2. 如果我非常确信一个里程碑中的任务,我只是不知道这个里程碑,我看了一下EBS项目 50和 95年的发布日期,并设置了--的正式发布日期,以及它对项目和最终发货日期的影响。

  3. 如果( 2 ) 将不会工作,因为你需要这个ebs释放投影堆栈的未来版本正确,你是对的,现在最好的办法是做一个大的ol''东西我们会找出我们忘记了以后对每个开发人员的计划项目。 如果我必须要这么做,那我来简单判断每个新任务和减这一估计数从缓冲计划项,那就直接删除它的估计并关闭它时我想我们已经找到的所有任务。 这是一点牛仔,真的ebs的正确用法会说你应该充电时间为每个这些发现任务对最初的计划项目,但嘿,这是一个地方,你可能有一个更好的了解整体不确定性比ebs,所以我说去。

希望这至少有一些帮助;我同意这是ebs当前的问题之一。 它可以修复一些项目管理艺术,但希望EBS能在未来给它带来一些科学。

作者:

"但是,我们可以做的是,我们在规划方面的优势? 我不确定这是否是一个可以通过类似的系统解决的问题。 "

"预测未来"问题不能由工具或者进程解决。 你不能在这个游戏中成功。

  1. 你无法获胜。无法预测软件开发项目的未来。 软件开发是知识捕获。 如果你已经知道 everythhing,你就会做一个安装。 因为你正在构建的新软件,所以是一个或更多的事情你不知道(user-oriented或技术)。

  2. 甚至不能打破甚至。 因为每一个的变化都被惩罚,所以无法达到一个可以接受的预测。 如果你提供一个"初步设计"估计 6月,和用户双重特性集,你在麻烦你加倍的估计。 当你更多地了解用例和技术,调整你的计划时,你被指控"范围渐变"。

  3. 你不能退出游戏。 每个人都想要一个坚如磐石的软件产品,尽管这个事实并不存在。 而"不 indisputable"完全取决于你所呈现的人。 一些人想要一个价格,你永远不能运行,无论多么巨大--他们希望"总计"拥有成本。 其他人想要一个价格,你只有有 60%机会会议--他们只想要一个初始预算每年的这个发展努力。

你唯一的选择是尝试使用更灵活的技术首先使用"pay-as-you-go"模型构建最有价值的东西。 估计一点,构建一点,获得一些收入。

简而言之,你必须改变游戏,避免提供 rock-solid,不争,total-cost的所有权估计。 为第一个版本提供一个开发预算( 人们花费 * 时间) 和一个与特定特性绑定的版本。

如果你从最重要到最重要的地方构建,购买者可以随时停止花费,并拥有一些价值。

作者:

这个问题一直困扰着项目经理( 回到金字塔的所有路) 。

  • 我们在设计/分析中遗漏了一些东西。

立即修复很简单,但很痛苦。 你必须执行 change-request/change-order ( 为它付出的可能是疼痛的一部分) 。 你创建新的工作项,并调整日程。

长期修复也很简单,但不能保证是无痛的( 或者完美) 。 你必须估计较小的任务。 通常情况下,当任务在天或者周中估计时,我只找到这些类型的goofs 。

  • 无任务应该超过一天或者两天,( 例外: 路由任务,你有相同的倍数任务—— 比如 我ave 50形式,而且每一个需要的字体改变了所有的按钮、标签和文本框-> 50形式 * 2小时/形式=> 100小时)
  • 没有任务少于一个小时。 我不在乎这是不是一个换行。 你仍然需要提高,缓降,检查,检查,测试,提交一份tps报告, 等等 无论多小的任务。

如果我有一个任务,我知道要花费一个星期的时间,会发生什么? 你还没有做足够的分析。 必须有断点,可以将它的分解为至少两天。

编辑
添加的工作只是。 添加了工作。因此,它们成为新任务。 基于证据的调度( 或者任何其他计划和评估系统) 只是没有设置为处理添加的任务。 它没有固有的方式知道你有什么 unknown-unknowns 。 从那里我将你返回到上面提到的"长期修正"。 如果你不能在一两天内完成任务,你可能不知道它足够好地估计了。

你所能做的来处理unknown-unknowns包括一些保险的过程添加应急基金/时间。 通常情况下,我在紧急情况下预算 20% 。 所以当我第一次启动一个项目时,我创建了一个叫做突发事件的任务。 如果我遇到一个unknown-unknown,然后添加一个任务,估计和衰减相同数量的应急任务。

作者:

我一直在问同一个问题。 最好的我能想到的就是那些被遗忘的影响最小化任务经常重复,所以他们从不占多,说, 5%的预定时间为每个迭代。

但是我假设如果以下情况成立,EBS会有帮助: 于各个tasks,相关并以相同的方式每位员工以一致的方式"思念"任务,这使得每个人一贯偏袒猜测?

作者:

事实上,EBS为你提供了一个基于当前任务列表的发货日期( 你过去估计的历史精度) 。 它听起来像你想要它的未来:)

如果你发现你在计划阶段漏掉了一些东西,那么似乎任何软件都无法解释。 如果可能的话,它可能只是编写软件本身,然后世界将由机器人运行。

这是一个有趣的问题,因为它确实出现了很多,每次它做的时候,我都会感到困惑。 也许是我不理解你在问什么,但你写了:

"通常情况下,在项目的开发阶段,你意识到你的计划没有覆盖整个区域,因为这是开发之前没有开发的东西的本质。"

任何一个没有"未来讲述"模块的软件都能估计出你不知道的东西? 我并不认为这对任何方式都有意义。 我对答案很感兴趣,因为你不是第一个询问它的人。

我的猜测是,也许人们期望的EBS ( 告诉我将要发货的日期) 不同于EBS承诺的( 考虑到你给我的数据,我在这一天的概率是多少) 。 也许它是像火车和汤姆的电影,他看起来太吓人,所以电影真的很恐怖。 也许EBS听起来能预测未来,所以当它开始做类似这样的事情时,人们希望它真正做到。

作者:

如果你正在讨论作用域更改添加新任务,你应该在你的日程安排中对此进行缓冲

如果你谈论不理解一个问题,定义正确的任务之前,据估计,然后它可以治疗中断。 不要担心这些,只要保持时钟的运行,并让平均值的定律。

我相信Joel会有更好的答案,但这是我的选择。

作者:
...