Azure DevOps中的看板

Question

我们计划在DevOps项目中使用看板。然而，看起来我仍然需要创建迭代(例如14天)并映射看板小部件，以显示14天周期内的在制品。

因此，在本质上，我仍然需要创建迭代。相应地，后续的理解是，我需要为迭代做冲刺计划。这是正确的理解吗?还是我漏掉了什么？

谢谢

Answer 1

这里有两件事：

First，看板主要用于可视化您的工作状态或流程。它是交互式的，因为您可以在工作项从一种状态进入另一种状态时更改工作项的状态。看板董事会并不真正依赖于sprint本身，但提供了一个用于监控进度的累积流程图。它是与跟踪sprint任务相关的任务板。

Second，WIP limits用于限制正在进行的工作项的数量，并可以帮助识别流程瓶颈并提高团队的效率。这些数字是为每个阶段设置的，并作为软约束，可以在以后重新访问。

是的，你必须create the iterations and iteration dates，尽管他们可以根据你的节奏，和map your Team's work flow to Kanban columns！

其他参考资料：

• Kanban Basics
• Kanban quickstart
• What is Kanban?
• If如果你想重新评估你的流程模型，给this doc一个事先的阅读。

希望这能澄清！

Answer 2

嗯，看板关心的是流程。这需要对排队论有一定的了解。例如，一个方面是利特尔定律。这需要交货率。因此，我发现请求该指标是有效的(不需要迭代！)当看板应该被支持的时候。

其次，看板关心的是平衡。如工作到达率和离职率之间的关系。同样，如果这些指标可以开箱即用，那就太好了。

(我教看板课程BTW)

DORA指标需要一些类似的东西:部署频率。我假设它可以在名称中带有"DevOps“的产品中立即可用。