迭代流程_什么时候应该从迭代过渡到流程？

迭代流程

我正在写程序管理书的一部分，讨论如何保持所有小东西以保持动力。 有时，为了保持工作量小，团队从迭代过渡到流程。

在某些情况下，您可能会考虑从迭代过渡到流程：

• 产品负责人出于商业原因希望在迭代中更改功能的顺序，并且您已经在进行一到两周的迭代工作。 是的，您有很多零钱。
• 您会感觉好像您在执行“死亡行军”敏捷项目。 您从一个迭代进入下一个迭代，总是挤满太多迭代。 您可以使用更多的团队来处理积压工作。
• 您正在一次迭代中处理太多项目。 没有人在管理项目组合 。

当我在2009年执教负责地理分布程序的程序经理时，这就回到了我的家。其中一个功能团队负责“喂饱”所有其他功能团队的数据库。 它们具有自己的功能，但是访问和数据库的功能集中在一个数据库团队中。 该团队尝试进行迭代。 他们有一个很小的一两天的故事。 他们在履行迭代承诺方面做得很好。 而且，他们总是觉得自己好像落后了。

为什么？ 因为他们有备份的请求。 进入该团队的请求的级别更改快于迭代持续时间。

当他们改变流程时，无论数据库需要更快地执行什么操作，他们都能够响应对不同报告，访问的请求。 它们不再是该程序的瓶颈。 当然，他们为每个功能使用了持续集成。 他们每天或隔天更新对数据库的访问权限，或数据库的功能。

整个计划恢复了势头。

这是一个简化的板。 我确定您的董事会看起来会有所不同。

在进行工作流程时，您的董事会中有一组固定的就绪项目（团队的待办事项），团队始终首先处理排名最高的项目。 根据进行中的工作限制，团队可能一次从“就绪”列中删除一个以上的项目。

产品负责人可以随时更改“就绪”列中的任何项目。 如果项目很大，团队将花费更多的时间来处理该项目。 学习如何制作小故事符合产品所有者和团队的利益。 这样，工作就可以快速进行。

如果您使用类似这样的电路板，再加上敏捷的路线图，则团队仍然可以大致了解产品的外观。 我们许多人都想知道全局。 而且，我们从董事会中看到了我们正在做的小事情。 但是，我们不需要进行迭代计划。 我们将下一项从“就绪”列表的顶部移开。

关于是否应从迭代过渡到流程，没有一个正确的答案。 这取决于您的情况。 您的产品负责人需要编写足够小的故事，以使团队可以完成这些故事并继续进行下一个故事。 敏捷是关于改变的能力，对吗？ 如果团队被困在一个太大的故事中，那就像被困在迭代中一样，等待迭代结束。

但是，如果您发现，特别是如果您是一个在程序中工作的功能团队，则需要更改自己的工作或执行的顺序比迭代所允许的频繁，请考虑逐步进行。 您可能会认为迭代过于局限了您的需求。

翻译自: https://www.javacodegeeks.com/2014/12/when-should-you-move-from-iterations-to-flow.html

迭代流程