似乎无论我的项目是什么,我都能相当快地完成80%的工作.用户和管理人员兴奋地认为事情已经提前了,但令人讨厌的20%的工作剩余似乎需要4倍于之前的80%.当我们对项目进行定期检查或站立时,我觉得这是一个破纪录的说"是的,到目前为止事情已经好了,但还有很多事要做......"
在大多数情况下,我的估计相当准确,但我是人.说服用户最后20%的工作确实占用80%的时间的最佳方法是什么？看起来越来越多的用户和管理层认为IT很容易,而且有些手指就会发生魔术......
一般来说,我们会按照我认为相当低的水平来跟踪任务.不一定在创建标签或文本框中,但我们非常详细...我们还跟踪我们对所有任务的估计完成情况,当您处于项目中间时,我认为这是一个比原始估计更重要的数字.
我认为这取决于对用户和管理层的看法.即使他们可能知道完成的估计,他们仍然会对他们所看到的情绪和看法感到失望,并且估计的数字会退居二线.这就是我想弄清楚如何控制或管理期望的方法.
一旦完成,不要向他们展示前80%.滴水喂它们.
即使考虑到霍夫施塔特定律,它也总是比你预期的要长
但我离题了.
最好的做法是悲伤的体验.SCRUM方法对某些类型的软件开发非常有用,因为它们不断地将发布日期更新为更准确的日期.(关于scrum的快速视频)
也许您需要将正在处理的任务/功能分解为更小的单元,用于安排工作和签入/报告.例如,我的日程表中几乎从未有过任何持续时间超过两天的单项.
然后,不是每天在Scrum上说"我正在为我们的新木偶制造商工作"两周,你可以说"我正在为muppet制造商选择眼睛选择器".
如果您正在按计划进行工作,并且您的日程安排准确(意味着它们同时占80%和20%),那么管理层确实应该没有问题.如果他们暗示他们可以减少分配的时间因为你"差不多完成"然后向他们展示那些尚未实现的规范部分.
我假设您使用某种形式的功能规范来详细说明应该做什么,它应该如何表现,以及它必须处理的边缘情况.如果是这种情况,那么担心管理层的情绪和看法对我来说似乎很奇怪,他们应该能够将规范与你的工作进行比较,或者阅读你的日程安排以了解剩下的内容.
你如何估计工作量？你说"令人讨厌的20%的工作剩余时间似乎比之前的80%长4倍",但是你是如何得出"20%"的工作剩余并且"80%"是做了什么？显然估计是错误的 - 实际上只有20%的工作完成,剩下80%.
在软件开发中,很难提前很长时间给出准确的估计.唯一的方法是将工作分成小的可管理部分(每个可能少于10个小时).您只能准确估计后续步骤.
一些有助于估计进度的实践可以在Scrum中找到.在下一个冲刺期间(一个月或更短时间)将完成的工作范围在冲刺开始时确定,并对每项工作进行粗略估计.然后在冲刺之后,团队可以反思已经完成了多少进展,仍然缺少了多少,估计有多准确,以及什么减慢了团队的速度.在Scrum和其他敏捷方法中,重要的一点是快速反馈已完成的工作以及我们在项目中的进度.我建议您阅读更多相关信息.ÓlafurWaage在其消息中链接的关于Scrum的视频给出了一个很好的快速介绍.
估计时间是我的经验：
如果您不能肯定地说某项任务将花费不到4个小时，那么您将无法准确估算该任务。将其分解成较小的部分，然后递归重复。
进行这样的时间估算不是一件容易的事，它需要时间，您基本上必须将整个项目分拆成可管理的部分，这意味着对需求的任何更改都将导致时间表的更改（令人惊讶的是吗？ ）
最大的问题是我们无法预见所有细节（也许说20％？让您剩下80％未被估计...）-正如其他人已经指出的那样，请参阅SCRUM。
管理层很少“接受”如此详细的时间估计，因为它将“花费太长时间”来实施。
但是，由于管理层对赚钱感兴趣，因此他们也对偷工减料感兴趣。因此，您应该根据所涉及的现实生活情况，确定可能的弯路并做出复杂的妥协。在管理层的支持下，您什么都不做可以完成最后20％的很多工作（我猜这是一种悲伤的方式，但仍然是事实）。
因为代表最终产品的最后20％的作品的最后80％实际上是在抛光和消除错误并适应变化的要求等。因此，可能会有一些有限的第一个版本等很有创意。
京公网安备 11010802040832号 | 京ICP备19059560号-6 
