Close

看板

如何使用看板方法进行软件开发

什么是看板?

看板是可用于实施敏捷软件开发的热门框架。它需要实时通信能力和完全透明的工作流程。工作项目在看板上直观显示,让团队成员可以随时查看每项工作的状态。

Kanban articles

[CONTINUED]

Kanban is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.

面向软件团队的看板

Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Kanban Board | Atlassian agile coach

虽然此框架的核心原则不受时间限制且适用于几乎所有行业,但软件开发团队仍在敏捷实践方面取得了特殊的成功。在某种程度上,这是因为软件团队一旦理解基本原则就可以开始实践,开销很低甚至没有开销。与在工厂车间应用看板(其中涉及更改物理流程和增加实质性材料)不同,软件团队唯一需要的实体物质就是板和卡片,而这些内容甚至可以是虚拟的。

看板

所有看板团队的工作都围绕着一块看板展开,它是一种用于实现工作内容可视化和优化团队中工作流的工具。虽然实体板在一些团队中很受欢迎,但虚拟板是所有敏捷软件开发工具中的重要功能,因为它具有可追溯性、更易于协作且可从多个位置访问。

无论团队使用的是实体看板还是虚拟看板,其功能都是为了确保团队能够实现工作可视化和工作流标准化,并且能够立即识别和解决所有蓝酷虎和依赖关系。基本的看板有一个三步式工作流,即待办、进行中和已完成。但这一工作流也可根据团队的规模、结构和目标进行调整,以满足任何特定团队的独特流程要求。

看板方法依赖于工作的全面透明度和团队工作能力的实时沟通,因此看板应被视为团队工作的可信唯一来源。

Agile Kanban Board | Atlassian agile coach

看板卡片

在日本,看板的字面意思是“视觉信号”。对于看板团队而言,每个工作项目都可以用看板上一张单独的卡片来表示。

在看板上用卡片来表示工作的主要目的,是让团队成员以高度可视化的方式跟踪工作流中的工作进展。看板卡片包含与特定工作项目有关的关键信息,可让整个团队全面了解工作项目的负责人、所做工作的简要说明、工作的预计完成时间等内容。虚拟看板上的卡片通常还会提供屏幕截图和对经办人有价值的其他技术详细信息。这让团队成员可以查看任何给定时间点的每个工作项目的状态,以及所有相关的详细信息,从而确保加大关注力度、提供全面可追溯性以及快速识别屏蔽程序和依赖关系。

The benefits of Kanban

看板是当今敏捷团队采用的最受欢迎的软件开发方法之一。看板可为各种规模的团队提供任务规划和吞吐量方面的额外优势。

灵活规划

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.

PRO TIP:

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. 

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

共享技能组合可以缩短加工时间。当只有一个人拥有技能时,这个人就成为了工作流中的一个瓶颈。因此,各团队都会采用代码审查和指导帮助等基本的最佳实践来传播知识。共享技能意味着团队成员可以从事复杂工作,从而进一步优化加工时间。这也意味着,如果工作停滞不前,那么整个团队可以群策群力,让流程再次顺畅运行。例如,不是只有 QA 工程师才能进行测试,开发人员也可以参与。

在看板框架中,由整个团队负责确保工作流程顺利进行。

减少瓶颈

多任务作业降低了效率。任何时候,运行的工作项越多,进行切换的上下文就越多,从而妨碍了完成率。这也是为什么看板的主要租户要限制进程中 (WIP) 的工作数量的原因。进程中的工作限制会由于缺乏焦点、人员或技能而在团队流程中凸显出瓶颈,以及备份的重要性。

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

可视化指标

核心价值观中有一条着重强调了要在每次工作迭代中不断提高团队效率和有效性。而图表为团队提供了一种视觉机制,确保他们能够继续改进。当团队能够看到数据时,就更容易发现流程中的瓶颈,并消除这些瓶颈。看板团队使用的两种常见报告是控制图和累积流量图。

控制图显示了每个问题的时间周期以及团队的波动平均值。

Pro Tip:

The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. 

Agile control chart | Atlassian agile coach

累积流量图可显示处于每种状态的事务的数量。通过查看任何指定状态下增加的事务数量,团队可以轻松发现障碍问题。处于“进行中”或“审查中”等中间状态的事务尚未发送给客户,当工作向上游合并时,这些状态中的障碍可能会增加出现大规模集成冲突的可能性。 

Cumulative Flow Diagram

持续交付

We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

Scrum 与看板

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

 

SCRUM

KANBAN
周期

固定时间周期的 Sprint(例如,2 周)

 连续流程
发布方法 经产品所有者批准,在每个 Sprint 结束时 持续交付或团队自行决定
角色 产品所有者、scrum 主管、开发团队 没有既定角色。一些团队可获得敏捷开发导师的帮助。
关键指标 速度 周期
变更理念 团队应尽量不在 Sprint 期间对 Sprint 预测进行变更。这样做会降低预估的准确性。 可随时变更

 

一些团队将看板和 Scrum 的理念融合,形成全新的“Scrumban”工作方法。他们借助 Scrum 执行固定时间周期的 Sprint 并获得角色,同时利用看板关注进程中工作的数量限制和时间周期。然而,对于刚刚开始实施敏捷开发的团队,我们强烈建议您选择其中一种方法,并运行一段时间。您以后可以不断变换方法,尝试新花样。 

Dan Radigan
Dan Radigan

敏捷开发在专业和个人层面上对我的影响都很大,因为我知道了敏捷开发是代码和生活领域最好的体验。在技术、摄影和摩托车赛的交叉领域,您会经常看到我的身影。在 Twitter 上关注我!@danradigan

Up Next