从累积流程图中删除已发货的项目

发布于 2024-08-11 00:26:20 字数 464 浏览 4 评论 0原文

我刚刚在我的团队中实施了看板并开始跟踪 项目随时间的状态。我们已经到了我们即将要做的事情了 在这个系统下发布我们的第一个版本,我有一个问题 关于如何处理已完成的工作项目。

我们有一个状态“已完成”,表示已完成的工作项 客户接受并准备发货。这个想法是删除项目 完全来自于发货时或原样的电路板 被认为是“完成”(对于诸如基础设施任务之类的事情, ETC。)。然而,如果我们从完整中删除项目,CFD 会花费很大的时间 下降(例如,我们现在有 11 个已完成的项目,相比之下 至 14 个处于“活动”状态的项目,例如,未积压)。我没问题 这,因为它很清楚地显示了发布的时间,但我还没有 见过任何已发布的差价合约可以做到这一点。我见过的每一个差价合约似乎 永远呈上升趋势。

是否有任何形式的共识或“最佳实践”(所有 该术语暗示的警告)支持或反对删除 差价合约中的项目?值得注意的是,我正在跟踪已发货/ 出于工程和端到端周期时间的目的,已关闭的项目, 但这些指标是单独跟踪的。

I've just implemented kanban on my team and have started tracking the
states of items across time. We've come to the point we we're about to
ship our first release under this system, and I've got a question
about what to do with finished work items.

We have a state "completed" that represents a work item that has been
customer accepted and is ready to ship. The idea is to remove items
completely from the board as they are shipped, or as they are
considered to be "done done" (for things like infrastructure tasks,
etc.). However, if we remove items from complete, the CFD takes a big
dip down (for instance, we have 11 completed items right now, compared
to 14 items in "active" states, e.g. not backlog). I'm okay with doing
this, as it quite clearly shows when releases happen, but I haven't
seen any published CFDs that do this. Every CFD that I've seen seems
to trend upwards forever.

Is there any sort of consensus or "best practice" (with all the
caveats that that term implies) that speaks for or against removing
items from the CFD? It's worth noting that I am tracking shipped /
closed items, for purposes of engineering and end-to-end cycle time,
but those metrics are being tracked separately.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

微暖i 2024-08-18 00:26:20

哇,这里没有很多看板操作:)

在 kanbandev 邮件列表上对这个主题进行了一些讨论后,我决定继续跟踪这些内容。我已将之前的“已完成”阶段更改为“准备发货”(仍包含在我的板上),并创建了一个名为“已发货/已关闭”的新状态。已发货/已关闭不在看板上,但我在单独的电子表格中跟踪它(我在其中跟踪其他事项,例如交货时间等)。

Wow, not a lot of Kanban action around here :)

After some discussion on this topic on the kanbandev mailing list, I've decided to go ahead and track these. I've changed my previous "Completed" stage to be "Ready to Ship" (still contained on my board), and created a new state called "Shipped / Closed". Shipped / Closed isn't on the board, but I keep track of it in a separate spreadsheet (where I'm keeping track of other things like lead time, etc.).

萌︼了一个春 2024-08-18 00:26:20

您可以做的是使用发布 ID 作为单独的字段,从 CFD 中过滤已发货的商品。如果您确实在运行看板,那么您会在工作流程的不同阶段持续拥有 WIP,因此您不希望丢失当前项目的状态。当已发布的项目从图表中删除时,您应该会看到整个图表在发布时“下移”,但这也应该为您提供正在进行的项目的一些连续性。

您可能还想在版本超出范围之前保存 CFD 的快照,以便通过工作流程查看项目状态更改之间的增量,以便您可以了解增量与当前版本的比较情况。增加的增量(通过给定时间 CFD 中各个工作流程阶段之间的水平距离变大来表示)表明您应该考虑工作流程约束;团队不可能永远变得更好,但也不应该变得更糟。

What you could do is use a release ID as a separate field for filtering already-shipped items out of your CFD. If you're really running kanban, then you have WIP continually, at different stages of the workflow, and so you don't want to lose the status of current items. You should see the entire chart 'shift down' at a release as the released items drop off the chart, but this should also give you some continuity on in-progress items.

You might also want to save a snapshot of the CFD before the release drops out of scope, in order to look at the deltas between state changes for items through the workflow, so you can see how the deltas compare for the current release. Increased deltas, shown by greater horizontal distances between the various workflow stages in the CFD at a given time, indicate a workflow constraint that you should look at; teams can't get better forever, but they shouldn't be getting worse.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文