如何使用自动亲和表估算用户故事

故事点还是天数，或者两者都用？

人们经常争论在估算用户故事时是否应该使用故事点或故事小时（或天数）。有些人认为我们根本不需要计算故事点和团队速度。虽然不同团队可能有不同的看法，但大多数敏捷项目确实会进行故事估算，并将其视为确保项目按时且在预算内完成的非常有用的工具之一。

用于故事估算的亲和表

在Visual Paradigm在 Visual Paradigm 中，我们不将故事估算视为一种冲突或谈判过程，而是一种团队建设过程，使任务协作和工作量对团队中的每个人都能清晰透明。用户故事工具通过亲和表赋能团队，实现故事估算过程的自动化，同时消除技术探索（spike）。此外，可视化亲和表支持同时以故事点和故事小时进行实时估算。当你拖动一个故事时，故事点和小时会同时显示，即使故事仍在移动中。只需将故事放在团队认为估算合适的网格中即可。

亲和表是如何计算的？

要理解亲和表中故事点和天数是如何自动估算的，我们需要明白：水平网格代表工作量，从左到右逐渐增加；而故事开发的复杂性（如新技术、新领域等）则从上到下逐渐增加。

由于用户故事的开发天数上限不应超过冲刺周期长度（否则说明该用户故事过大需要拆分，或冲刺周期设置过短需要延长），因此右下角网格的天数也应等于冲刺周期长度。基于这一假设，故事估算可以自动计算。

用于估算的用户故事亲和性

用户故事的估算永远无法达到100%的准确，事实上没有任何方法可以做到这一点。为了提高估算的准确性，我们首先确定冲刺周期长度（例如两周或10个工作日），然后对几个我们感觉最熟悉、最有把握估算的用户故事进行估算（例如5天，确定性为中等）。在这种情况下，你应将该故事垂直放在中间位置（表示确定性或风险水平），水平方向也放在中间（工作量等于5天，即冲刺周期长度10天的一半）。然后可以将其作为其他用户故事估算的参考点。问问自己：这个用户故事所需的工作量是否比参考故事更多或更少？不确定性是否更高或更低？当你将更多用户故事放入亲和表后，可以对比多个用户故事，判断其相对位置是否合理，再适当调整，使其更公平。这个过程更像一种艺术而非工程。应在团队会议中讨论完成，而非引发冲突。随着团队逐渐成熟，估算的准确性通常会不断提高。

通过项目探索消除风险

根据敏捷词典，Spike 的定义是：

“一种旨在回答问题或收集信息的任务，而非直接产出可交付的产品。有时会产生一个用户故事，只有在开发团队实际完成某些工作以解决技术问题或设计难题后，才能对其进行良好估算。解决方案是创建一个‘探索’（spike），即一种以提供答案或解决方案为目的的工作。”

在估算用户故事时，我们不仅考虑开发工作量，还要考虑其中涉及的风险和不确定性。通常在冲刺正式开始前，会创建一个探索（spike），以管理为公平估算其他用户故事所需完成的工作。