使用基于迭代的敏捷创建里程碑

我一直在指导几个有问题的团队：他们喜欢迭代工作。并且，它们具有不在里程碑边界上的里程碑。他们该怎么办？（我建议使用流程，您应该已经听到了他们的回应。嗯，也许不是。）

这就是人们想要这些里程碑的原因：

这是一个示例：假设您正在开发基于学校的产品。您不能在分级期间中途更改产品的分级部分。但是，您可以在分级期间结束之后和下一个分级开始之前的任何时间更改分级部分。也许您知道潜在客户将在三周内进行一次大型演示。您希望该新评分产品作为该演示的一部分。您需要进行两周的迭代，这通常是一件好事。

您可以将连续交付用于产品的其他部分，而不是用于分级。您需要实现此里程碑，并且它不在迭代边界上。

这是我过去在团队内部处理此问题的方式。团队按故事顺序对故事进行排序，并完成功能。 PO接受这些功能，并且团队在内部发布或带有标志以阻止客户使用新功能。

故事要小。仅仅因为里程碑需要它“全部”，并不意味着故事可能很大。

团队可以将此工作标记为“完成”，但是该工作不会被释放。

此面板显示已完成但尚未发布的工作。现在，团队知道该怎么做了。这不能解决迭代边界之外的不同时间的发布。以下是一些选项：

对于定期完成功能集工作的团队，团队就完成了。但是，对于那些刚开始敏捷但并不每天都完成一些小功能的团队呢？

团队制定了每周发布的节奏。每个星期的某个特定日期或时间，团队都会发布完成的内容。是的，这是每周一次的项目发布培训。

我的一位客户尝试了此方法。那时他们发现自己的订单不足以快速获得故事反馈。

他们一直在使用具有三列的常规Scrum板：“就绪”，“进行中”和“完成”。工作在“进行中”列中不断堆积。然后，当邮政总局终于有时间回顾这些故事时，他拒绝了一半以上。团队一直在黑暗中工作。

团队创建了这个董事会，以便他们可以看到工作在哪里。附带的好处是，PO可以看到他该何时看故事了。（这两个委员会位于“ 创建成功的敏捷项目”中。）

某些使用迭代的团队直到迭代结束或超过那个时间才具有完整的功能。那是因为他们不能自行部署。（如果您有一个程序，我写了关于如何组织程序团队以确保您可以在“ 敏捷和精益程序管理”中进行部署的文章。）

如果您不能作为一个团队进行部署，请确保您的董事会拥有所需的准备部署和部署列数。与部署人员一起为您的部署创建每周或每两周一次的节奏。作为一项好处，您将学到每个人需要做的事情，以使部署更快，更容易。

我的经验法则是，如果您有里程碑要实现，请考虑使用流程，而不是迭代。提高您的部署节奏，以实现里程碑。

翻译自: https://www.javacodegeeks.com/2017/07/creating-milestones-iteration-based-agile.html