本文介绍了如何利用周期时间指标来优化工程团队的产品交付过程，探讨了产品交付周期的计算公式，并引用了一篇相关文章进行深入讨论。
产品交付周期计算公式
Delivery health is a key element of a healthy engineering team. At SafetyCulture we are not simply looking for delivery health. We aspire for world-class level excellence in how we deliver value to customers.
交付健康是健康的工程团队的关键要素。 在SafetyCulture，我们不仅仅是在寻找分娩的健康状况。 我们渴望在为客户提供价值方面达到世界一流水平。
This is particularly important to me as an engineering manager accountable for product delivery. I need methods and tooling that make it easy to support multiple cross-functional teams building some of the most critical components of our flagship iAuditor product. I recently had the opportunity to experiment with exactly that. The experiment was successful and I hope my learnings are useful to you.
作为负责产品交付的工程经理，这对我尤为重要。 我需要能够轻松支持多个跨职能团队构建我们旗舰iAuditor产品的一些最关键组件的方法和工具。 最近，我有机会对此进行了实验。 实验是成功的，希望我的学习对您有所帮助。
In a fast paced agile environment such as SafetyCulture the flow of a team’s work was identified as a key productivity indicator reflecting delivery health. In simple terms, you can think about flow as the average rate of getting things done as a team. Flow is the rhythm or pulse of the team’s delivery engine. For example, at SafetyCulture our product teams aim to deliver customer value every 3–5 days on average.
在诸如SafetyCulture之类的快速敏捷环境中，团队的工作流程被确定为反映交付健康状况的关键生产力指标。 简单来说，您可以将流程视为团队完成工作的平均速度。 流程是团队交付引擎的节奏或脉动。 例如，在SafetyCulture，我们的产品团队旨在平均每3-5天为客户提供价值。
Flow is the rhythm or pulse of the team’s delivery engine
流程是团队交付引擎的节奏或脉搏
Optimising for flow is better than other agile measurements such as velocity based on story points as it works in the language of the customer (wall clock time). Other benefits include improved predictability, streamlined team operations, boosted team morale and the ability to be truly agile when process or behavioural change is needed. For a detailed analysis of the benefits of flow versus other delivery health metrics I highly recommend Daniel Vacanti’s book “Actionable Agile Metrics for Predictability: An Introduction”.
针对流量进行优化比其他敏捷测量(例如基于故事点的速度)要好，因为它以客户的语言(挂钟时间)工作。 其他好处包括改进的可预测性，简化的团队运营，提高团队的士气以及在需要进行流程或行为更改时真正敏捷的能力。 对于流量与其他交付运行状况指标的好处的详细分析，我强烈推荐Daniel Vacanti的书“可预测性的可行敏捷指标：简介” 。
How do we measure “flow”?
我们如何衡量“流量”？
At SafetyCulture our teams manage work using Scrum, Kanban and all variations of styles in-between. We needed a metric that was agnostic to the iteration style of the team.
在SafetyCulture，我们的团队使用Scrum，看板以及介于两者之间的所有样式变化来管理工作。 我们需要一个与团队的迭代风格无关的指标。
The metric we chose to measure flow at SafetyCulture is the team’s cycle time. In simple terms, cycle time is the time between when someone starts working on a task and the time the task is done. Our goal is not to minimise the cycle time, rather it is to keep the cycle time stable within an agreed time range. The time range is defined by the team depending on the nature of the tasks undertaken. We found for most product teams in our environment a 3–5 days is a reasonable goal to aim for at this time.
我们选择在SafetyCulture测量流量的度量标准是团队的周期时间。 简而言之，周期时间是指某人开始处理某项任务与完成任务之间的时间。 我们的目标不是缩短循环时间，而是将循环时间保持在约定的时间范围内。 团队根据所执行任务的性质来定义时间范围。 对于当前环境中的大多数产品团队，我们发现3到5天是一个合理的目标。
cycle time is the time between when someone starts working on a task and the time the task is done
周期时间是从某人开始处理任务到完成任务的时间
We wanted to be able to answer questions like “what was our team’s cycle time in the last 7 days?” and “how stable was our team’s cycle time over a time period?”. Additionally we wanted a way to quickly visualise the cycle time trend and be able to drill down to the supporting data to derive actionable insights at any time.
我们希望能够回答诸如“我们团队在过去7天的周期时间是多少？”之类的问题。 和“我们的团队在一段时间内的周期时间有多稳定？”。 另外，我们还希望有一种方法可以快速可视化周期时间趋势，并能够随时向下钻取支持数据以得出可行的见解。
As we use JIRA for managing work, we first experimented with the built-in JIRA cycle time reports. Using JIRA’s built-in cycle time scatterplot went some way into answering the “what is our cycle time” question. However, we needed more powerful tooling to answer all our other questions above. We found that the “Actionable Agile” plugin for JIRA gave us most of what we needed. See some examples below for how we made the most of it.
当我们使用JIRA来管理工作时，我们首先尝试了内置的JIRA周期时间报告。 使用JIRA的内置循环时间散点图可以回答“什么是循环时间”问题。 但是，我们需要功能更强大的工具来回答上述所有其他问题。 我们发现， JIRA的“ Actionable Agile”插件为我们提供了我们所需的大多数东西。 有关如何充分利用它的信息，请参见下面的示例。
Here is an example of one of our team’s cycle time trend over time. The different colours indicating different types of work items like stories, bugs and tasks.
这是我们团队的周期时间趋势随时间变化的一个示例。 不同的颜色指示不同类型的工作项，例如故事，错误和任务。
At a glance we can see the average cycle time was 5.3 days and 64% of tasks were completed within the 5.3 days average. Productive conversations can be had immediately by looking at the graph around what it would take to have more work items completed within the desired cycle time. Or how we could break down work better so that some items that took a bit longer than our desired range could fit within it.
一目了然，我们可以看到平均周期为5.3天，平均5.3天之内完成了64％的任务。 通过查看在所需的周期时间内完成更多工作项所需要的图表，可以立即进行富有成效的对话。 或者我们如何更好地分解工作，以使一些耗时比我们期望范围长的项目适合其中。
Productive conversations can be had immediately by looking at the graph
查看图表可立即进行富有成效的对话
The trend on that graph is fairly stable except for some time periods which insightfully correspond to challenging times for that team such as losing key team members and on-boarding new ones.
该图上的趋势是相当稳定的，除了某些时间段，这些时间段深刻地对应于该团队具有挑战性的时间，例如失去关键团队成员和新员工入职。
Looking at such graphs in retrospect we can learn lessons about how to avoid similar spikes. Most importantly, looking at such graphs in real time helps identify spikes before they happen and take corrective action to optimise flow.
回顾这些图表，我们可以学习有关如何避免类似峰值的课程。 最重要的是，实时查看此类图表有助于在峰值出现之前识别出峰值，并采取纠正措施来优化流量。
How do we optimise “flow”?
我们如何优化“流量”？
The first step to optimising flow is to measure and visualise it and spend some time with the team understanding it. If the cycle time is not stable the team will typically discuss how to make it stable. Once stable, if the cycle time is longer than what the team thinks is healthy, the team will discuss what needs to be done to bring it within the desired time range. I have found all of these very productive conversations that always yield positive corrective actions where required.
优化流程的第一步是对其进行测量和可视化，并花一些时间让团队了解它。 如果周期时间不稳定，则团队通常会讨论如何使其稳定。 一旦稳定下来，如果周期时间比团队认为的健康时间长，团队将讨论需要做些什么才能使其在期望的时间范围内。 我发现所有这些非常富有成效的对话总是会在需要时产生积极的纠正措施。
Here are a couple of examples from the many interesting findings:
以下是许多有趣发现中的几个示例：
In one situation, Android pull requests were taking up to 12 days to complete. This was identified by the team’s cycle time trending upwards. We asked some more Android developers to help with code reviews, cycle time was restored and our Android delivery cadence was healthy again.
在一种情况下，Android拉取请求最多需要12天才能完成。 这是由团队的周期时间趋于上升所确定的。 我们要求更多的Android开发人员提供代码审查帮助，缩短了周期时间，并且我们的Android交付节奏再次恢复正常。
In another example, one of our engineers was leaving stories in progress for two or three weeks at a time, waiting to deploy them to production until after all sub-tasks had been completed. We discussed ways to optimise for incremental delivery to production, they adjusted their way of breaking down work and had a very positive impact on team delivery shipping value every few days to production!
在另一个示例中，我们的一位工程师一次将正在进行的故事搁置了两到三个星期，等待将其部署到生产中，直到完成所有子任务。 我们讨论了优化增量交付到生产的方法，他们调整了分解工作的方式，并且每隔几天生产就会对团队交付的运输价值产生非常积极的影响！
The result of corrective actions can be seen almost immediately, within a few days or weeks. Here is an example of another of our teams which optimised their cycle time from a spike of more than 20 days down to 5 days recently
在几天或几周内几乎可以立即看到纠正措施的结果。 这是我们另一个团队的示例，该团队优化了他们的周期时间，从超过20天的峰值缩短到最近的5天
The result of corrective actions can be seen almost immediately, within a few days or weeks
纠正措施的结果几乎可以在几天或几周内立即看到
Wish list
愿望清单
One thing I wished we had with Actionable Agile is the ability to share a link to a filtered view of a team’s analytics. A built-in ability to email us an updated cycle time report for each team at regular intervals would be greatly welcome too!
我希望我们在Actionable Agile中拥有的一件事是能够共享指向团队分析的过滤视图的链接的能力。 定期向每个团队发送电子邮件给我们的最新周期时间报告的内置功能也将非常受欢迎！
Closing remarks
结束语
Tracking team delivery health by using the team’s cycle time to measure and optimise the flow of work has been rewarding for our product teams at SafetyCulture. Cycle time conversations are becoming more and more part of our team culture. Every team member can easily understand how their work contributes to the team’s delivery rhythm. Work is flowing better than ever before with less streams of work being blocked and more incremental delivery across the board.
通过使用团队的周期时间来衡量和优化工作流程来跟踪团队的交付状况，这对于我们在SafetyCulture的产品团队来说是非常有益的。 周期对话越来越成为我们团队文化的一部分。 每个团队成员都可以轻松地了解他们的工作如何有助于团队的交付节奏。 工作流比以往任何时候都更好，更少的工作流被阻塞，更多的增量交付。
As useful as they are, cycle time scatterplots and trends are only the beginning of our exploration into team delivery metrics. Stay tuned for more updates on this topic. Or even better, come work with us, we are hiring!
循环时间散点图和趋势尽管有用，但仅仅是我们探索团队交付指标的开始。 请继续关注有关此主题的更多更新。 甚至更好，请与我们合作，我们正在招聘！
产品交付周期计算公式
扫一扫
644
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
