什么时候停止编写用户故事并开始编码？

在发现第一个冲刺的故事时，您如何知道何时停止写作并向前发展？

我问了几个我认识的人，基本上我得到的答复是，它取决于项目所处的环境以及整个项目的时间安排。

有什么标准的方法可以知道何时停止编写用户故事，如果是的话，其基础是什么？它如何应用于未来的冲刺？

充实故事后，您需要估算每个故事-假设您按优先顺序排列故事，并且已对故事进行了充分的阐述以供开发。

当您估计有足够的迭代次数时，请开始编码。

当您拥有完整的产品积压订单，以及所有情况的完整的用户案例时。然后将它们分为迭代，然后开始编程。

这两种活动不是对抗性的。

故事写作是关于在提供业务价值的约束下定义所需的需求。

开始编码发生在冲刺的中间。要开始冲刺，唯一的先决条件是定义的sprint积压工作-由PO（故事编写者）确定优先级，并由团队选择。

当实现故事的边际收益与定义的函数的实现成本和实际运营成本为负时，您应该停止编写故事（=停止项目）。

当故事被理解（分析）并且定义了测试和实现（设计）时，您应该开始在Sprint上下文中进行编码 -经典的软件开发方法。

当故事变得足够细致以变成可编程逻辑时..以及程序员何时可以授予与sprint时间轴相适应的一定数量的故事点。

一个故事估计为50小时/每个故事点将很难（IMO）进行长达一周的冲刺。.进一步分解故事将使其他人可以承担任务的各个部分，但是如果代码不能并行开发，那么可能就这么短了。

有什么标准的方法可以知道何时停止编写用户故事，如果是的话，其基础是什么？它如何应用于未来的冲刺？

我个人并不了解标准方法。实际上，这取决于您的方法论和客户的期望。

我发现最好从客户那里获得“足够”的故事作为开始就开始编码。正如其他人所说，这可能是一次迭代，但是可能会更多。您对足够量的衡量应以打算向客户发布工作代码的频率为指导，而不是让客户给您提供无休止的故事列表（其中许多故事可能永远不会完成，可能会更改或可能不会做到）请在主要发布截止日期之前完成），最好先问问客户前3-5个最重要，最优先的功能。完成这些操作并将其发布给客户后，您将收集下一个最重要的3-5个功能，依此类推。根据您的迭代可能持续多长时间要求更多或更少。

您的客户或合同或期限可能会指导您何时真正停止索要故事，但是与此同时，您一直在索要故事，并且每次迭代都停下来。当您和客户达成协议，认为产品足够完整时，您可以决定如何处理客户可能还没有给您的剩余故事。

这种方法的主要优点是最终可以为客户预先提供最大的价值，并且随着项目的发展和时间的流逝，您交付给客户的价值量会减少到客户可以创造价值的程度。有关他们可能希望从未真正使用过的“功能的最后20％”的决定。它也减少了浪费在琐碎和低优先级项目上的时间，将优先级和调度迭代的责任（和压力）放回到了客户身上，而这一切完全基于客户的需求。但这并不意味着您不应该为客户提供指导，以避免在与客户讨论需求时可能出现的困难调度瓶颈。

如果您想在更广泛的背景下更详细地描述此方法，请阅读Poppendeicks的精益软件开发。

您永远不会停止编写故事。仅当您有足够的故事可用于sprint 1时，您便会进行sprint计划，并且您的团队将根据sprint积压工作开始工作。

产品负责人将继续整理产品待办事项列表，即编写更多的用户故事，将大的故事（例如史诗）分解为较小的故事，详细说明故事的接受标准，确定优先顺序...