什么是看板_看板是线性的

什么是看板

A typical Kanban board usually shows a series of steps or activities that work passes through. In software development, this may take the form of work items passing through some sort of discovery step when analysis or design happens, to a building or development activity, before it passes through a validation or testing stage. Such a visualisation often shows that work items move from the left-hand side of the board to the right.

典型的看板通常会显示一系列工作通过的步骤或活动。 在软件开发中，这可以采取工作项目的形式，当分析或设计发生时，工作项目将通过某种发现步骤，到达建筑物或开发活动，然后再经过验证或测试阶段。 这种可视化效果通常表明工作项从面板的左侧移动到右侧。

Kanban has its origins in manufacturing, most famously as part of the Toyota Production System (TPS). In manufacturing plants, it is possible to see a product being built in a linear manner as it passes through the various work stations where specialist activity takes place. The shell of the body of the car passes various assembly points. The engine is added at one, the gearbox at another, at others the clutch, doors, tyres etc. Each incremental addition contributes to the car emerging as a completed product as it passes along the assembly line.

看板起源于制造业，最著名的是丰田生产系统(TPS)的一部分。 在制造工厂中，有可能看到产品以线性方式构建，穿过了进行专门活动的各个工作站。 汽车车身的外壳通过各个装配点。 发动机在一个处被添加，变速箱在另一个处被添加，离合器，门，轮胎等被添加。每次增加添加都使汽车在沿着装配线通过时成为完整的产品。

Modelling the Flow

流程建模

Modelling product development for physical products in a manufacturing line in a left to right fashion is one thing, but does it really make sense to do the same for an intangible product where product development is complex, as is the case with software? Scrum is a proven strategy for addressing complex adaptive problems, a domain where any sense of ‘linearity’ is misguided, and progress is instead made through disciplined inspection and adaptation loops. Yet many Scrum teams — indeed all Scrum teams that I have been involved with — whether with a physical board or an electronic tool, use some form of visualisation that represents work passing along stages in this “left to right” way. Such a technique is a complementary practice in Scrum, one that is essentially taken from the Kanban practice of “visualisation of the workflow”.

从左到右为生产线中的物理产品建模产品开发是一回事，但是对产品开发复杂的无形产品(例如软件)做同样的事情真的有意义吗？ Scrum是解决复杂的自适应问题的一种行之有效的策略，在该领域中，任何“线性”感都被误导了，而是通过严格的检查和自适应循环来取得进展。 但是，许多Scrum团队(实际上是我参与过的所有Scrum团队)，无论是通过物理板还是电子工具，都使用某种形式的可视化来表示工作以“从左到右”的方式进行。 这种技术是Scrum中的一种补充实践，它实质上取材自看板“工作流程的可视化”实践。

Scrum teams often see this concept of linearity breaking down. For example, an item reaches a validation stage, only for a defect to be discovered. Some teams will send the item “backwards”, back to a development step to be fixed, or even further back for analysis work. Very soon, items on the board are seen to be jumping around in different directions, maybe even skipping over steps in the workflow on the way. While not a prescribed rule in Kanban, many would forbid this from happening, with a policy stating something like “work only goes in one direction, from left to right.” How can that be practical? The order of activities on the work would appear to be non-linear. Does that mean that a visualisation of a linear set of steps of work is unsuitable for complex product development? And by implication, is Kanban a far from perfect approach to take in the complex domain?

Scrum团队经常看到这种线性概念被打破。 例如，一个项目到达验证阶段，仅针对要发现的缺陷。 一些团队会将该项目“向后”发送，返回到固定的开发步骤，甚至进一步发送回进行分析工作。 很快，板上的项目就会朝着不同的方向跳跃，甚至可能会跳过工作流程中的步骤。 尽管看板中没有规定规则，但许多人会禁止这种情况发生，其政策规定“工作只能从一个方向到从左到右”。 那怎么可能呢？ 工作上的活动顺序似乎是非线性的。 这是否意味着线性的工作步骤可视化不适合复杂的产品开发？ 言外之意，看板是否不是完美的方法来应对复杂领域？

Work as Value

作为价值工作

Kanban, as applied to the complex domain, is much more than visualisation and work in progress (WIP) limits. There are a number of characteristics that one would expect as a minimum to meet the definition of a Kanban system. One such requirement when applying Kanban practices to Scrum, for example, is having a clear definition of the work items. The key here is that this work item definition must be in units of value, whether this is customer value, business value, knowledge acquisition value or some other measure of value. Granular tasks are great for development teams to self-organise and manage their work, but what we are interested in for a true Kanban system is the visualisation of the flow of these units of value, not granular tasks that do not deliver meaningful value by themselves. With Scrum teams, these are typically expressed as Product Backlog Items.

应用于复杂域的看板不仅限于可视化和在制品(WIP)限制。 人们希望至少可以满足看板系统定义的许多特征。 例如，将看板实践应用于Scrum时，此类要求之一就是对工作项有明确的定义。 这里的关键是，此工作项定义必须以价值为单位，无论这是客户价值，业务价值，知识获取价值还是其他一些价值度量。 细粒度的任务非常适合开发团队自我组织和管理其工作，但是我们真正的看板系统感兴趣的是可视化这些价值单元的流动，而不是不能单独提供有意义的价值的细粒度任务。 在Scrum团队中，这些通常表示为产品待办事项。

Why is this important in this discussion? When we model the flow of work items as units of value, activity on the item may well be non-linear. However, while the dominant activity on a piece of work in the complex domain is non-linear, the value being added is linear. Put another way, the act of working on an item, by whatever function, should be an act of adding value. At times, progress may seem to be halted or even go backwards, however, this is all part of the discovery and knowledge acquisition process — value-adding concepts in their own right in any empirical process. Modelling the flow of value-adding activities is a core concept that Kanban can bring to Scrum to enable greater transparency, and inspection and adaptation opportunities.

为什么这在讨论中如此重要？ 当我们将工作项目的流程建模为价值单位时，项目上的活动很可能是非线性的。 但是，尽管复杂领域中某件作品的主要活动是非线性的，但所添加的值却是线性的。 换句话说，通过任何功能对项目进行操作的行为都应该是增加价值的行为。 有时，进展似乎会停滞甚至倒退，但是，这都是发现和知识获取过程的一部分-在任何经验过程中，增值概念本身就是权利。 为增值活动流程建模是看板可以带入Scrum的核心概念，以提高透明度，检查和适应机会。

We can, therefore, think of each step in the workflow as steps in the knowledge acquisition and feedback process instead of handoff between functions. Let’s return to our earlier example of an item that has progressed to a testing phase and a defect has been found. In this case, we are discovering new knowledge about the main work item through the act of validation. A useful and common practice to give visibility of what is happening is to leave the original item where it is, and create a new item that represents the defect to be worked across the board until it catches up with its parent.

因此，我们可以将工作流中的每个步骤都视为知识获取和反馈过程中的步骤，而不是职能之间的交接。 让我们回到前面的示例中，该示例已进入测试阶段，并且已发现缺陷。 在这种情况下，我们通过验证行为发现了有关主要工作项目的新知识。 可视化发生情况的一种有用且通用的做法是将原始项目保留在原处，然后创建一个新项目，该项目代表要全面处理的缺陷，直到赶上其父项为止。

In Summary

综上所述

Adding Kanban practices can be a powerful strategy for enhancing Scrum. Visualising work as units of value and the value-adding activity this work goes through, along with the other Kanban practices such as limiting work in progress and active management of work items in progress has radical effects on what it means for collaboration, self-organisation and empiricism.

添加看板实践可以成为增强Scrum的强大策略。 将工作可视化为价值单位和这项工作所经历的增值活动，以及其他看板实践，例如限制进行中的工作和对进行中的工作项进行积极管理，对协作，自我组织的意义产生了根本性影响和经验主义。

Feature photo by Jon Tyson on Unsplash

乔恩·泰森(Jon Tyson)在Unsplash上​​的特色照片

Do you want to write for Serious Scrum or seriously discuss Scrum? 您要为《严重的Scrum》撰写文章还是认真讨论Scrum？

翻译自: https://medium.com/serious-scrum/is-kanban-linear-6f304131cf58

什么是看板