问将故事点分配给积压中的假设

EN

没有任何关于故事点或scrum的东西使得将故事点分配到不可能甚至是困难的事情上，除非您在自己的过程中对定义进行了大规模的修改。故事点是一种基于复杂性的估计，与时间只有模糊的关系。在大多数情况下，故事点最终会变得更加基于时间，这使得将它们分配给任意的故事或问题更容易。其次，人们误解了什么是sprint --能够在每个sprint的末尾交付可移植的产品。故事和sprint旨在向产品所有者提供有价值的单位，这通常被误解为每个故事的工作代码。在假设驱动的发展中，“是”或“否”是有价值的部分，故事应该致力于如何获得“是/否”，以及如何处理“是/否”。在你验证了一个假设之前，不需要写或估计故事来充分发展和实施一个假设，而且在那个时候你应该有足够的洞察力来提供合理的估计。它甚至有可能和有用的故事，有一个输出的其他故事。

听起来，您遇到了一个共同的缺陷:单独收集需求，编写一堆东西，然后尝试将其抛到开发团队的墙上。这是一种很难打破的瀑布心态，另一种更好的选择是让您的开发团队的部分人员参与其中，以帮助您将这个想法转化为故事和需求。如果你已经有了很多东西，最好的解决方案就是把它写成一个逻辑的故事分解(作为第一遍)，并使用一些积压整理时间来重组和充实最初的故事。

至于产品所有者如何对这些项目进行排序，一旦它们被写成特性/史诗/故事，就变得很简单了。这就变成了一个简单的问题，就是知道假设A是否值得追求比新特性B或bug修复C更重要。如果假设D完全不知道设计一个后续测试的难度有多大，那么就制作一个故事来找出它，并对其进行优先排序。在sprint计划过程中添加“我想知道什么”可能是获得许多有价值的用户故事的有用方法，这些故事并不是真正的开发工作，但通常更有用。

我不是假设驱动开发方面的专家，但对它有一定的了解。以下是我要考虑的几件事：

1. 一个假设的充分实现可能需要不同的时间。在短跑时间箱中，这可能是个问题，因为在这个时间箱中，工作可以完成，但是实验需要时间来证明。当然，我们可以通过小的实验和真正连续的部署周期来减轻这一点，但是至少要承认这是一个风险。
2. 这个过程本质上是开放的。在满足条件之前，你不知道你已经完成了这项工作。假设你有一个项目：“我们相信，降低注册表格的复杂性将使它不那么令人生畏，并提高注册完成率。如果启动注册的完成率从10%提高到30%，我们就知道它成功了。”现在你做这项工作，在下一段时间里，它会增加到23%。你取得了积极的进展，但没有取得很大进展。你觉得它够好吗？你会不会回去简化这个过程，看看你是否能得到最后的7%？这是你的团队和组织必须非常擅长的谈话。
3. 就像任何开放式项目一样，你总是把工作投入其中而得不到好处，这是有风险的。XP中的Spikes这样的实践也有同样的问题，他们用基于任务的时间框而不是点来解决这个问题。一个基于任务的时间表实际上只是定义了我们愿意花多长时间在一个特定的问题上，然后我们应该重新组合并决定是否真的值得花更多的时间。所以，如果你使用我上面给出的例子，我们可能会认为我们完全可以花16个小时来简化页面。在那之后，我们想看看结果，看看是否值得花更多的时间。
4. 最后一个想法:不要过度投入到一种设计工作的方式上。假设驱动发展的想法真的很强大。用户故事也是如此。许多其他的工作方式也是如此。与我一起工作的每一个团队都会因为选择最适合这种努力的框架而不是只坚持一种方法而得到更好的结果。