当更广泛的项目跨越多个冲刺时，如何在每个冲刺结束时提供潜在可运输代码？
答案 0 :(得分：1)
我不清楚为什么不呢！
敏捷的想法是您的项目具有可变范围但预先确定的时间。因此，您需要对所有内容进行包装，并确保每次都完成或排除任何内容。
从这个意义上说，你每次都有框架边界（迭代）可以发送代码。如果您的工作单位（故事）跨越多个方框，那么您的团队将无法取得任何进展，直到他们可以运送任何单位。当然，出于这个确切的原因，你的故事需要尽可能小。
项目可以运行任意次数的迭代，直到有宝贵的事情要做。
换句话说，敏捷项目必须具有可变范围，并且根据定义，应该可以在每次迭代时将其包装起来。
答案 1 :(得分：1)
正如Sklivvz所说，你的问题不是很清楚，但你在其中一条评论中提到：
但是，如果一个项目包含多个故事，这些故事只作为一个整体有意义并且数量太多而无法在单个冲刺中传递，那么它是如何工作的？
故事应遵循INVEST。
INVEST中的 I 代表 Independent ，这意味着您的故事不应该在sprint之间具有依赖关系。你应该将它们分解得足够小，以便它们可以在冲刺中发展。
可能发货，并不意味着您必须发货，但产品所有者始终可以选择发货。例如，如果您正在开发的产品不符合Minimum Viable Product的功能，那么您的产品经理可能不想发货。但是，最好（尽早）发布，以便用户可以提供有关功能的反馈。也许最初的用户群是您公司内部或友好客户的内部用户。
答案 2 :(得分：0)
它可以通过部署在临时环境中供客户使用，也可以通过打包安装到允许将其部署在任何所需位置的安装程序来提供。
它需要包含此类环境中所需的任何更改 - 例如新配置文件，数据库架构更改等。这些应作为部署包的一部分捆绑（作为手动步骤或更好的自动化步骤）。
当然 - 没有一个答案。与您团队中的其他成员（请记住，这包括DEV，QA，业务和'客户'）确定在此项目中向您的团队提供此/潜在可交付代码的意义。然后以这种方式交付。然后讨论如何解决问题。然后改进它。
进行时间框实验，反思发生的事情，调整/改进并确定另一个实验。也就是说，IMNSHO，'敏捷'。