通过敏捷交付大型项目

Question

当更广泛的项目跨越多个sprint时，如何在每个sprint结束时交付可能可移植的代码？

Answer 1

正如Sklivvz所说，你的问题不太清楚，但你在其中一条评论中提到：

但是，如果一个项目包含多个故事，这些故事作为一个单元才有意义，而且数量太多，无法在一个sprint中交付，那么这是如何工作的呢？

故事应该跟在投资后面。

投资中的I代表独立，这意味着你的故事不应该在sprint之间有依赖关系。您应该将它们分解得足够小，以便能够在sprint中开发它们。

潜在的可运输性，并不意味着你必须发货，但产品所有者总是可以选择发货。例如，如果您正在开发的产品不符合最小可行产品的特性，那么您的产品经理可能不想发货。但是，更好的做法是尽早发布(而且经常发布)，这样用户就可以对这些特性提供反馈。也许最初的一组用户是您公司的内部用户，或者来自友好的客户。

Answer 2

我不清楚为什么不！

敏捷的思想是，您的项目有可变的范围，但预先确定的时间。所以，你把所有的东西都写好了，并确保在每一个时间框里，事情要么已经完成，要么被排除在外。

从这个意义上说，在每个时间框边界(迭代)上都有可移植的代码。如果您的工作单元(故事)跨越多个框，那么您的团队将不会取得任何进展，直到他们能够运送任何单位。当然，由于这个确切的原因，你的故事需要尽可能的小。

一个项目可以运行任意数量的迭代，直到有有价值的事情要做。

换句话说，敏捷项目必须具有可变的范围，根据定义，应该可以在每次迭代时结束它。

Answer 3

它可以通过部署在可供客户使用的暂存环境上交付，也可以通过打包到安装程序中来交付，安装程序允许将其部署到任何需要的位置。

它需要包含这些环境中所需的任何更改--比如新的配置文件、db模式更改等等。这些更改应该作为部署包的一部分(作为手动步骤，或者更好的自动化步骤)捆绑在一起。

当然-没有一个答案。与您团队的其他成员(请记住，这包括DEV、QA、业务和‘客户’)在这个项目中确定向您的团队交付此/Potentially可移植代码/意味着什么。那就这样送过去。然后讨论一下那是怎么回事。那就改进它。

做有时间限制的实验，反思发生的事情，适应/改进并决定另一个实验.也就是说，IMNSHO，‘敏捷’。