每个人都想知道该项目需要多长时间。 在本文中，我们将说明如何使用周期时间和计数故事同时向经理提供准确而不确定的预测，以及有关何时完全避免估算的建议。

Celeste感到压力。 她的经理巴里想对她的球队做出季度预测。 Celeste的小组研究了不止一种产品，这一事实使这项工作变得复杂：Barry想一次获得三个产品的预测。 他们每个人都是不同项目的一部分。

Celeste小组的程序员没有足够的信息来做出至少一些预测，尤其是整个季度。

Celeste决定向Barry坦白，看看他们的想法。 第二天她约好了并收集了数据。

那个女孩正好在上午10点到达巴里的办公室。 当她敲门时，巴里仍在打电话。 他示意她进去，举起一根手指说清楚：他将在一分钟内准备就绪。

她坐在办公桌对面的访客椅上。

巴里挂了个电话，转身说：“好，让我们讨论一下项目的时间，对吗？”

塞莱斯特点点头，说：“是的。 这似乎是在这种情况下可以做到的。”

巴里皱了皱眉，“看来？” 我需要具体的承诺。 没有“似乎”！”

Celeste舒适地坐着：“ Barry，您是否被迫发布这三种产品？”

“你是怎么发现的？” -巴里摇了摇头。 -如果您听取销售和营销方面的消息，那么如果我们现在不发布他们，将会发生灾难。 除了一切都会，我不知道该怎么回答。”

“但是上个月，您讨论了一个项目组合，” Celeste回忆道。 “我认为产品A是重中之重。”

“是的，”他说。 “而且产品B和C也是头等大事。”

Celeste翻了个白眼：“但是你知道只有一个主要优先事项，对吗？”

他说：“我知道，而且你知道。” “但是我的同事们不知道。” 我需要对您可以做的事情-义务，做个预测-然后您可以安静地呼吸。”

“首先我们应该开发什么产品？” Celeste问。

他说：“当然是产品A。” “他是报酬最高的人。”

“好吧，这就是我们要做的，”塞莱斯特说。 “我们很紧张，将在一个月内释放A。” 您的任务是让这些好人每周参加我们的演讲。 他们应该看看我们一周后会做什么。 如果他们不参加演示，我拒绝向他们提供任何信息。”

巴里向后倾斜：“等等。 我了解了该演示。 那另外两个月呢？ 你为什么不给他们任何信息呢？”

Celeste说：“如果我们只开发一种产品，我可以根据我们的开发周期来计算等级。 对于产品A，我们每周发布三到四个故事（用于自定义任务的代码）。 但是我们不知道产品B和C的真正开发周期。”

巴里点点头：“为什么不呢？”

“产品B和C计划在两个月到三个月内完成，” Celeste说。 -对于营销而言，这已经很遥远了。 问题在于，工作越远，营销部门与产品负责人澄清故事的“时间”就越少。 我们不知道在两个三个月内将需要实现哪些功能。 我们将不得不从头开始进行基于科学的假设（科学的野驴猜测，SWAG）。 这很正常，我喜欢和我的家伙一起做，但是我们需要更多细节。 哪个不是。”

“那么，如果他们不参加示威游行，为什么不告诉他们任何信息？” 问巴里。

“如果对他们而言，观察我们的进展并提供反馈并不重要，那么他们就不会在意时间，” Celeste说。 “他们希望我们承诺自己，而不承担任何回报。” 我为什么要花时间评估他们是否不想贡献？”

巴里同意将每月“时间表”“卖给”经理，这些经理向他施加压力，要求他设定截止日期。 Celeste将确保团队仅专注于产品A。她已安排每周一次的例会，以进行演示，以便团队展示其工作并接收反馈。

您会尝试做不同的事情吗？

术语估算-非平凡的工作

估计截止日期也是可行的。 许多团队在日常工作中制定了这样的惯例。 但是， 准确的季度估算通常需要一两个小时以上的工作。

评估季度绩效至少有两个问题。 通常，需求没有完全定义好，就像Celeste团队一样， 评估使团队脱离了项目的紧急工作。

问题在于，规划软件开发与规划公路旅行不一样。 如果您的城市有多个交通信号灯，则说明交通波动。 我住在波士顿的郊区，从那里到机场仅需20和90分钟。 通常是30到45分钟。 对于13公里的行程而言，这是一个很大的变化。

在这种旅行中没有创新。 我去过机场很多次，我知道几种到达那里的方法。 我有移动应用程序可以帮助我即使在旅途中也能找到最快的路线 。 尽管有些选项可以预测一些，但它们都不能保证特定行程会在20分钟内结束。

前往机场的行程是在预定的路线上进行的，并且有容易理解的障碍。 但是产品开发是另一回事。 这是创新。 换句话说，我们之前没有做过这样的事情。 如果不是这样，则我们不必编写新的应用程序或更新过时的系统 -我们将使用旧的系统 。

为了进行合理的评估，我们有几种选择。 实际上是三个：

• 您可以估计数量级。 我认为这对整个项目很有用。 “我们期望工作五到九个月。 当我们回答这些问题并完成复杂工作的这一部分时，我们会更加了解。” SWAG非常适合此类评估。
• 您可以收集有关需求的足够信息并提供合理的估计。 团队可能需要处理用户故事，以便以较小的时间间隔进行预测。
• 您可以选择在短期内（例如一两个星期）评估工作。 事实证明，最终预测并不完全正确。 但是通常它与结果足够接近，以免使要求这样做的人感到失望。

您需要经理的什么预测？

我注意到经理经常需要数量级的估计。 在这种情况下，团队可以做出预测并报告如下：

“我们相信这个项目将花费五个月，对这个预测的准确性有50％的信心。 我们对八个月的评估充满信心。 十个月就是90％的信心。”

这有助于管理人员了解信任范围。 如果他们想要100％确定性，则可能要花费14个月以上的时间。

您可以使用螺旋方法：“我们专注于明年第一季度。 我们不知道第一季度的确切时间，但我们认为我们可以解决。” 随着项目的进行，您可以指定：“我们正在更新1月中旬至3月中旬之间的估算值。” 学到更多后，说：“如果没有暴风雪，在二月的某个地方。” 然后在一月您可以说：“二月的第三周。”

我还建议使用三个日期范围：“乐观的日期是一月。 最现实的是​​2月底。 最悲观的是四月底。”

无论如何，永远不要给出明确的评估。 它会诱使圣·墨菲（来自墨菲定律）从事您的项目并做令人讨厌的事情。

在某些情况下和某些命令中，客户可能需要其他信息。 在这里，您可以与他讨论正在实施的特定功能，以了解不确定性。

使用周期时间而不是评估

我不喜欢软件项目或其他IT项目（尤其是敏捷项目）的实施期限预测。 相反，我更喜欢团队发布很小的故事或按周期时间评估工作。

如果您不熟悉该术语：

• 用户故事描述了客户或用户如何将产品用于一种功能目的（“我想保留位置”或“我需要发布智能城市数据以满足透明度要求”）。 故事不同于从数据库和API角度看产品的开发人员的故事。
• 周期时间是指团队发布一个故事所需的总时间。 这包括活动的开发时间和工作期望的停机时间。

这个想法是要了解产生有用的东西（历史）所花费的平均时间。

就Celeste而言，她知道一个团队每周可以为产品A制作三到四个故事。对于许多团队来说，故事计数的工作原理与其他评估方法一样。

如果团队从未使用过类似产品，则以前的周期时间将不适用于该新产品。 团队可能不知道如何精炼和拆分故事，以便每周制作几个故事。 此外，她可能不知道代码的状态以及是否有足够数量的测试。 如果您的团队从事故事的工作超过三天，请不要担心预测。 计算故事，不要比平常做更多的事情。

当团队开始在一两天内处理故事时，您也无需进行评估。 通常，简单的计算会更容易，更准确。

为什么不使用速度？

您已经注意到，我建议使用周期时间和故事计数，而不是用速度来估计项目时间。 因为速度是一种替代。

例如，我每天走路以保持健康。 我每天遵循相同的路线，跟踪我的相对速度。 在晴朗的晴天，我每小时行走约5.6公里。 在下雨天或炎热潮湿的日子，速度会降至4 km / h。 在雪或冰中，我根本无法外出，在这种情况下，我的速度为0。

我要走同一条路线。 （是的，这很无聊，但这是我的问题）。 虽然我走的距离相同，但根据情况的不同，旅行的时间也不同。 这里的条件类似于您的团队的代码库和测试。

如果故事足够小，则速度对应于循环时间。 但是，经理们经常尝试评估具有很大故事的项目。 计数会更简单：“我们可以在一个周期中完成一个或两个故事。 您想选择哪个或两个故事？”

拒绝评估不是骗局

当Barry与同事讨论问题时，其中一位说：“拒绝评估截止日期是一个骗局！”

巴里回答：“不正确。 您要我们发布产品，对吗？”

答案是“当然。 B和C。”

“问题是他们需要轮流完成，”巴里回答。 -如果您确实需要产品A，则对其余产品进行预测有什么意义？ 我们可以开始工作并展示我们的进步。 完成足够的工作后，我们将重复B和C的过程。此外，您将有时间澄清B和C的要求，以便为我们准备故事。”

Celeste的团队在一个月内完成了大部分项目A。 产品B的发布花费了更长的时间-接近两个月。 并且由于公司从产品A和产品B的发行中获得了足够的收入，因此减轻了产品C的发行压力。

知道您的经理需要什么等级。 根据需要呈现她。 如果您没有时间，请开始工作。

评估IT项目：经验教训

• 不要包括任何特定的数字或日期。 取而代之的是，要对及时发布充满信心地给出一个数量级的估计值。 或根据您控制的因素提出短期估计。
• 将项目目标划分为定义软件功能的用户案例。 然后根据您可以处理的用户故事数量进行估算。
• 做出任何承诺之前，请确保您了解要求。