svn - 迭代过程中的功能请求

Question

我们正在通过以下方式开发我们的项目：

1. 功能请求列表
2. 估计
3. 编码
4. 测试
5. 标记版本 1.x

一次迭代通常持续 1 个月。但有时我们会立即收到项目经理的请求——“伙计们，我们非常需要这个小功能！ ” 这里开始一些我不喜欢的事情：

1. 在标签中实现
2. 在主干中实施

您如何处理迭代间的功能请求？

谢谢。

Answer 1

您可以选择减少迭代的长度。这样，他们必须等待的最长时间是两周。

当经理想要引入一个新特性时，它只是简单地包含在下一次迭代的积压中。他们在不到两周的时间内需要它真的足够重要吗？除了严重的安全问题或致命的崩溃之外，我对此表示怀疑。

将迭代长度减半不应使开销增加一倍。如果它很痛，那就更频繁地做。

Answer 2

暂时忽略您的项目方法，在交付此类功能后，您的 repo 的最终状态应该是：

1. 您有一个带有递增版本号的新标签，它与以前的标签之间的区别是新功能。
2. 开发主线（主干）也包含该功能，以便新分支获得该功能，而现有分支将在下次与主干同步时获得该功能。

你如何到达那里取决于你的回购布局及其约定，但这里有两个选项（这似乎与你不喜欢的内容相对应）：

1. 在当前标签的新分支（或清理的现有发布集成分支）上，完成功能/错误修复，创建新标签和发布，并将标签合并回主干。不错的选择，因为它可以最大程度地降低错误修复发布不需要的更改的风险。如果发生了很大变化，合并回主干可能会很困难。

2. 首先完成主干上的功能，将其挑选到新的/现有的干净发布集成分支，标记并发布它。很好，因为其他人更早地获得了您的功能/修复。合并到集成分支可能很困难，这可能会减慢发布速度。

我认为选项 1 是最好的，因为它通常会更快地发布，因为任何合并都会被推迟，直到更改被移植回主干，并且不需要的更改泄漏到产品中的风险较小。

就您的项目方法而言，如果您要适应该功能，您必须要么；

1. 缩小当前迭代的范围
2. 当前迭代的延迟发布
3. 获取额外资源（开发人员/秒）或加班来构建功能

...或这些的某种组合。

Answer 3

1. 更改行李箱上的代码
2. 将主干的更改合并到最后一个发布分支（cherry-picking）
3. 从发布分支创建一个新版本

如果您没有发布分支，您可以在之后创建一个

svn cp ^/trunk@1234 ^/branches/release-20130621

上一个版本的修订版在哪里1234。

Answer 4

如果可能，我们会尝试将变更请求移至下一次迭代。如果不可能 - 我们正在准备 ETA 和里程碑/演示/发布日期转移。

我们需要警告客户在迭代过程中的功能请求总是一件坏事。当他意识到时，他正在期待这样的事态。