迭代过程中的功能请求

Question

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

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

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

1. 以标记实施
2. 在trunk中实施

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

感谢。

Answer 1

您拥有的选项是减少迭代的长度。这样他们必须等待的最长时间是两周。

当经理想要引入新功能时，它只会包含在下一次迭代的待办事项中。他们在不到两周的时间内需要它真的很重要吗？除了严重的安全问题或致命的崩溃之外，我对此表示怀疑。

将迭代长度减半不应使开销量增加一倍。 If it hurts, do it more often.

Answer 2

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

如果您没有发布分支，则可以使用

创建一个发布分支

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

其中1234是上一版本的修订版。

Answer 3

暂时忽略您的项目方法，在提供此类功能后，您的回购的最终状态应为：

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

你如何到达那里取决于你的repo布局及其约定，但这里有两个选项（看起来与你不喜欢的相对应）：

1. 在当前标记（或清理的现有版本集成分支）的新分支上，完成功能/错误修复，创建新标记并释放，并将标记合并回主干。这是一个很好的选择，因为它可以最大限度地减少错误修复发布不需要的更改如果发生很多变化，合并回主干可能会很困难。

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

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

就您的项目方法而言，如果要容纳该功能，您必须;

1. 缩小当前迭代的范围
2. 当前迭代的延迟释放
3. 获取其他资源（开发人员）或加班以构建功能

......或者这些的一些组合。

Answer 4

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

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