敏捷和精益路线图的替代方案：第1部分，功能集思考
许多团队和组织尝试创建四分之一的路线图。 这是我看到的问题：
- 团队花费大量时间来估计他们可能会做什么，然后他们选择适合一个季度的工作。 他们感到或被要求致力于所有工作。
- 产品经理和项目组合经理依赖团队来完成团队承诺的所有工作。 他们经常使用团队的承诺来创建外部日期。
一次计划整个季度通常会变成“推式”计划-团队将一切都推到一个季度中。 如果每个人都聚在一起，那是一次昂贵的会议，结果令人怀疑。 团队改变工作方式的适应性和弹性较小。 以我的经验，团队需要在前几次迭代中更改他们的工作。
四分之一的计划，尤其是跨多个团队的计划，具有以下假设：
- 所有功能部件均具有均匀的功能部件分布。 也就是说，特征集A具有与特征集B相同数量的特征。
- 所有功能部件的值都相似。
- 所有功能的到达率都是可以预测的。
- 团队可以正确地估计他们四分之一的工作量。
很少有人或团队可以准确估计四分之一的工作量。 如果您使用史诗和主题的思想，那可以帮助人们意识到作品的规模。 另一方面，人们具有上述假设，尤其是功能集中所有功能的价值的平均分配（您称其为史诗或主题）。
这是另一种选择。 考虑一下功能集（这有助于解决这个问题），计算功能，MVP（验证业务假设）和MVE（通过实验学习一些小知识）。
让我讨论特征集和计数特征的想法。 您会发现我在写作中没有使用史诗和主题。 这是因为团队和工具之间的定义不一致。 我使用功能集来描述一项工作的所有功能。
这是一个例子。 您可能需要产品中的“报告”。 报告通常包括按某种类型的搜索。 你可能想要：
- 产品报告
- 地理报告
- 客户或客户类型的报告
您甚至可能希望根据用户限制某些类型的报告。 现在我们遇到了一个安全问题，它需要不同的功能。
不要将“报告”作为史诗或主题，而应将报告视为功能集。 （我将其分为“按产品划分的报表”，“按地理位置划分的报表”，“按角色划分的报表”，“按客户划分的报表”等。请注意，这开始帮助更高级的人意识到“报表”太大了，他们需要考虑各种报告的MVP和MVE。
现在，我们可以将功能集创建为集思广益活动：
- 在三个团队（开发人员，测试人员，PO / BA /其他人员）中，以最快的速度编写卡片以集思广益所有报告。 我经常将其设置为7分钟。
- 在时间表结束时，与团队中的其他所有人聚在一起，看看他们的牌。 通过删除重复项并拆分它们意识到需要的功能来组织卡片。 我经常将其设置为7分钟。
- 添加此功能集中的所有功能。 团队的想法是什么？他们是否认为需要在较小的团队或较大的团队中花更多的时间进行头脑风暴？ 如果是这样，再花7分钟进行头脑风暴。 （我更喜欢较小的团队，但就是我。）然后再次进行重复的删除/拆分。 如果他们认为自己具有更多功能，则这是一项功能强大的功能，我们可能对此了解不足。 我要求团队同意他们承诺的最多三个MVP和三个MVE，因为未知数太多。 假设团队可以使用这些功能（功能集不太大），请继续执行第4步。请根据需要循环此步骤，但是如果超过两次，请问团队成员的关注点是什么。
- 计算功能集中的功能。 是的，算一下。
- 查看该团队的历史周期时间（团队将项目从“就绪”转移到“完成”所需的时间）。 如果团队尚未计算出周期时间，则假设团队对其进行了集结/评估，则每个功能都需要三天。 为什么是三个？ 因为那是一个起点。 可能不正确。 但是，如果没有有关周期时间的历史数据，那么没人会知道 。 我发现，当团队平均每个故事思考3天时，他们往往会蜂拥而至，这有助于提高工作量。
- 现在，对于基于时间的四分之一路线图，请计算团队在12周内可以提供的故事数量。 这就是循环时间如此重要的原因。 团队可以尝试致力于这项工作，并在进行过程中查看他们的位置。
这与我所看到的估计方式有何不同？
- 团队不会估算任务。 他们坚持功能。
- 他们不尝试做详细的估计。 他们使用历史周期时间数据（如果有）或每个功能3天的SWAG进行计数。
- 他们可以在30分钟内“估计”整个功能集。
不是我不喜欢估计。 我发现对我和与我一起工作的团队来说，四分之一的估算是无用的-太大了。 事情发生了变化-某人想要一件事情更多，而又想改变另一件事情。 我发现如果我们尝试估算任务，它的用处甚至更少。 很多时候，“如果Rob承担了这项任务，那将是半天。 如果我这样做，那将是3天。” 取而代之的是，让团队一起工作（群居或暴民），他们可以以最“了解”该人的方式完成工作，并解释该人的所作所为。
我坚持功能，而不是任务。 这是因为客户购买了功能。 我想了解MVP和MVE，因为我们将以这种方式学到最多的知识。 我需要反馈。
对于基于时间的四分之一的估算，我没有万灵药。 接下来，我将讨论创建比整个季度都小的波动。