您将根据这些数据做出什么决定？

您的团队是否必须保留两套“书”？ 您有一个灵活的路线图可以看到您的前进方向。 您的即将完成的工作积压得很少。 您经常交付商品。

而且，您团队中的某人保留了甘特图，因为经理想要以他们喜欢的形式查看团队的进度。

您的团队讨厌将敏捷计划转换为更传统的计划。 完成工作需要时间。 而且，通常情况下，更传统的计划有时会鼓励在太低的水平上估计“全部”项目。 （这是“多少”思考的症状。

如果您在这个泡菜中，您的经理可能会认为您的敏捷团队不会经常重新计划。 该经理可能会假设您的团队仅将敏捷方法用作交付方式。 如果团队以敏捷方法使用经验主义，那么这些经理就会错过团队可以更连续地进行计划的想法。 这就是我试图在该图像中显示的内容。

您有几种方法可以解决此问题。 您可以按照我上面描述的那样，以您现在拥有的最佳估计来保留两组“书”，并继续更新这两组计划。 您可以向经理提供比经理可以管理的更多的信息。 或者，您可能会问其他问题。

安抚经理

A团队以这种方式处理请求：团队采用了每个功能集。 他们集思广益，想出了最小的故事。 然后，他们根据成本，价值和投资进行估算：该项目的成本是多少？ 第二部分 。 然后，他们使用功能集或功能集的一部分创建了临时里程碑。

他们将这些故事插入了甘特。 让经理们疯狂地看细节。 经理们做了什么呢？ 查看何时完成功能集。

团队A确实存在一个问题：每个功能集都在增长和收缩，而不是可预测的数量。 因此，某些功能集“很早”。 有些是“晚”。 （请参阅敏捷和精益路线图的替代方案：第1部分，在功能部件中思考不可预测的功能部件到达的问题。）

他们为创建甘特图买了项目喘息空间。 而且，他们不可能“坚持”到甘特。 他们使用敏捷方法并与客户合作。 这意味着功能和功能集已更改。 团队对此表示满意。 但是，甘特图需要经常更改。

尽管A队提供了甘特图，但该图没有用。 而且，敏捷项目经理Sue必须对其进行维护。

苏决定开始提问。

根据数据询问决策

苏问了这个问题：

您会根据数据做出什么决定？

当您问这个问题时，您可能会了解一些我的客户学到的知识：

• 有时，经理们想知道何时可以安全地发布产品。
• 一些经理想要基于日期和估计来管理项目组合。
• 一些经理想“知道”“一切都在轨道上”。

我认为使用数据来宣布产品是合理的。 我并不擅长使用估算来管理项目组合，但我可以理解为什么他们想要它。

至于“知道”进度：甘特图无法告诉您这一点。 这就是名为“计划工具永远正确”的计划游戏。

计划工具可以帮助人们回顾过去工作的过去数据。 而且，过去的数据至少有两个问题：

• 我们很少重复做同一件事。 这次会有所不同：要解决的问题，团队，代码库。 以前的项目数据通常不会预测该项目的数据。
• 太多的团队没有捕获团队成员在项目中实际产生的加班。

您确实可以访问任何项目中的真实数据。 实际数据是周期时间，即团队将功能从“就绪”列中移出后花费的时间。 有关价值流图和周期时间计算，请参见帮助经理可视化他们的问题 。

什么数据很重要？

我希望演示者知道我们何时能步入正轨。 演示还可以告诉我们是否即将完成。

以我的经验，太多的项目在继续，因为我们需要“全部”。 我们通常不需要全部。 我们需要的少得多。 而且，如果我们能够通过频繁的发布来检验我们的假设，那么我们可能根本不需要做太多事情。 演示可以告诉我们是否做得足够。

如果需要图表，请考虑产品积压的燃尽图。

您可以查看每个功能集随时间的进度。

有时候，产品积压的积压并不能向管理层解释其决策的效果。 在这种情况下，我喜欢功能表。

功能图显示完整功能的消耗，总功能数量的消耗以及剩余功能的消耗。

想要了解所有这些日期和进度的问题之一是，经理常常会嘲弄这些功能。 他们想在很短的时间内补习更多。 或者，由于某些原因，他们想添加更多。 这些图表可帮助经理查看所需的数据。

记住，我在这里谈论的是敏捷团队，这些团队定期提供价值。

没有基于数据的决策

有时候，当团队问经理时，经理说：“我没有将数据用于任何决策。 甘特人是我对这个项目的了解。”

那是一个敏捷的转换问题。 这些团队正在向敏捷文化过渡。 那个经理不是。 经理可能不知道他或她应该做什么。 经理更有可能尚未将他/她的信念和价值观改变为敏捷文化的信念和价值观。

如果您的经理希望您保留不利于团队的数据，请理解原因。 管理者并不愚蠢。 他们可能没有意识到可以使用哪些数据来做出哪些决定。 帮助他们学习。

问一个问题，“您将根据这些数据做出什么决定？” 帮助人们了解他们的文化和系统。 并且，避免“两套书”的问题。

翻译自: https://www.javacodegeeks.com/2019/09/decision-make-based-data.html