看板
如何使用看板方法进行软件开发
看板在当下的敏捷和 DevOps 软件开发团队中非常著名,但事实上,看板的工作方法可以回溯至 50 多年以前。20 世纪 40 年代末,丰田开始按照超市的货架囤货方法优化其工程流程。超市仅存储刚好满足消费者需求的产品数量,这种做法优化了超市和消费者之间的流通。由于库存水平符合消费模式,超市通过减少其任何时候所持有的超额库存量,大大提高了库存管理效率。同时,超市仍然可以确保消费者所需的产品始终有货。
当丰田将相同的系统应用于工厂车间时,其目标是更好地调整其库存量,以便与材料的实际消耗量保持一致。为了在工厂车间内以及向供应商实时传达库存量,工人们会在两个团队之间传递卡片或“看板”。当生产线上使用的材料耗尽时,看板会被传递到仓库,说明需要什么材料以及所需材料的确切数量等。仓库会重新准备好这种材料,然后将其运送到生产车间,并将他们自己的看板交给供应商。供应商也会准备好这种特定材料,然后将其运送到仓库。虽然此流程中的信号技术自 20 世纪 40 年代一直在发展,但“即时”(或 JIT)生产流程仍然是其不变的核心。
面向软件团队的看板
如今,敏捷软件开发团队已经能够将正在进行的工作 (WIP) 量与团队工作能力相匹配,从而利用相同的 JIT 原则。这在整个开发周期中为团队提供了更灵活的规划选项、更快的输出、更明确的重点和透明度。

虽然此框架的核心原则不受时间限制且适用于几乎所有行业,但软件开发团队仍在敏捷实践方面取得了特殊的成功。在某种程度上,这是因为软件团队一旦理解基本原则就可以开始实践,开销很低甚至没有开销。与在工厂车间应用看板(其中涉及更改物理流程和增加实质性材料)不同,软件团队唯一需要的实体物质就是板和卡片,而这些内容甚至可以是虚拟的。
看板
所有看板团队的工作都围绕着一块看板展开,它是一种用于实现工作内容可视化和优化团队中工作流的工具。虽然实体板在一些团队中很受欢迎,但虚拟板是所有敏捷软件开发工具中的重要功能,因为它具有可追溯性、更易于协作且可从多个位置访问。
无论团队使用的是实体看板还是虚拟看板,其功能都是为了确保团队能够实现工作可视化和工作流标准化,并且能够立即识别和解决所有蓝酷虎和依赖关系。基本的看板有一个三步式工作流,即待办、进行中和已完成。但这一工作流也可根据团队的规模、结构和目标进行调整,以满足任何特定团队的独特流程要求。
看板方法依赖于工作的全面透明度和团队工作能力的实时沟通,因此,看板应被视为团队工作的唯一真相来源。

看板卡片
在日本,看板的字面意思是“视觉信号”。对于看板团队而言,每个工作项目都可以用看板上一张单独的卡片来表示。
在看板上用卡片来表示工作的主要目的,是让团队成员以高度可视化的方式跟踪工作流中的工作进展。看板卡片包含与特定工作项目有关的关键信息,可让整个团队全面了解工作项目的负责人、所做工作的简要说明、工作的预计完成时间等内容。虚拟看板上的卡片通常还会提供屏幕截图和对经办人有价值的其他技术详细信息。这让团队成员可以查看任何给定时间点的每个工作项目的状态,以及所有相关的详细信息,从而确保加大关注力度、提供全面可追溯性以及快速识别屏蔽程序和依赖关系。
看板的优势
看板是当今敏捷团队采用的最受欢迎的软件开发方法之一。看板可为各种规模的团队提供任务规划和吞吐量方面的额外优势。
灵活规划
看板团队只关注眼下正在进行的工作。团队完成一个工作项目后,会将下一个工作项目从待办事项的顶部移除。产品负责人可以在不干扰团队进度的情况下自由调整待办事项中工作的优先级,因为当前工作项目之外的任何变动都不会影响到团队。只要产品负责人将最重要的工作项目置于待办事项顶部,开发团队就会明确地知道这些项目将给企业带来最大价值。因此,您无需像在 Scrum 中一样进行固定时长的迭代。
聪明的产品负责人会在在考虑更改待办事项时与开发团队沟通。例如,如果用户故事 1-6 都位于待办事项中,那么用户故事 6 的预估工作量可能会视用户故事 1-5 的完成情况而定。始终与工程团队确认工作变动是个不错的做法,可确保不会出现意外情况。
缩短时间周期
对看板团队来说,周期时间是一项重要指标。周期时间指的是一个工作单元通过团队工作流所花费的时间,从工作开始的那一刻起,到工作交付的那一刻结束。通过优化周期时间,团队可以充满信心地预测未来工作的交付情况。
共享技能组合可以缩短加工时间。当只有一个人拥有技能时,这个人就成为了工作流中的一个瓶颈。因此,各团队都会采用代码审查和指导帮助等基本的最佳实践来传播知识。共享技能意味着团队成员可以从事复杂工作,从而进一步优化加工时间。这也意味着,如果工作出现瓶颈,那么整个团队可以群策群力,让流程再次顺畅运行。例如,不是只有 QA 工程师才能进行测试,开发人员也可以参与。
在看板框架中,由整个团队负责确保工作流程顺利进行。
减少瓶颈
多任务作业降低了效率。任何时候,运行的工作项越多,进行切换的上下文就越多,从而妨碍了完成率。这也是为什么看板的主要租户要限制在制品 (WIP) 数量的原因。在制品限制会由于缺乏焦点、人员或技能而在团队流程中凸显出瓶颈,以及备份的重要性。
例如,典型的软件团队可能有四个工作流状态,分别是待办、进行中、代码审查和已完成。他们会选择将代码审查状态的 WIP 限制设置为 2。这一限制似乎很低,但却有充分理由:开发人员通常更喜欢编写新代码,而不是花时间审查别人的工作。低限制可鼓励团队特别注意处于审查状态中的事务,并在提交自己的代码审查之前审查他人的工作。这最终缩短了整体加工时间。
可视化指标
核心价值观中有一条着重强调了要在每次工作迭代中不断提高团队效率和有效性。而图表为团队提供了一种视觉机制,确保他们能够继续改进。当团队能够看到数据时,就更容易发现流程中的瓶颈,并消除这些瓶颈。看板团队使用的两种常见报告是控制图和累积流量图。
控制图显示了每个问题的时间周期以及团队的波动平均值。
团队的目标是缩短问题从产生到解决的整个时间周期。在控制图中看到平均周期缩短就意味着成功。
累积流量图可显示处于每种状态的事务的数量。通过查看任何指定状态下增加的事务数量,团队可以轻松发现障碍问题。处于“进行中”或“审查中”等中间状态的事务尚未发送给客户,当工作向上游合并时,这些状态中的障碍可能会增加出现大规模集成冲突的可能性。
持续交付
持续交付 (CD) 是指频繁向客户发布工作。持续集成 (CI) 是指在一天当中以增量方式自动构建和测试代码。两者共同组成了 CI/CD 管道,这也是开发团队(尤其是 DevOps 团队)在保证高质量的同时加快软件交付的关键。
看板和 CD 互为补充,相辅相成,因为这两种技术都注重即时(以及逐一)交付价值。团队向市场推出创新的速度越快,他们的产品在市场上的竞争力就越强。而看板团队专注的正是:优化与客户之间的工作流程。
Scrum 与看板
看板和 Scrum 虽然具有一些相同的概念,但它们是截然不同的两种方法,不应将它们混淆。
Scrum | 看板 | |
周期 | 固定时间周期的 Sprint(例如,2 周) | 连续流程 |
发布方法 | 经产品所有者批准,在每个 Sprint 结束时 | 持续交付或团队自行决定 |
角色 | 产品所有者、scrum 主管、开发团队 | 没有既定角色。一些团队可获得敏捷开发导师的帮助。 |
关键指标 | 速度 | 周期时间 |
变更理念 | 团队应尽量不在 Sprint 期间对 Sprint 预测进行变更。这样做会降低预估的准确性。 | 可随时变更 |
一些团队将看板和 Scrum 的理念融合,形成全新的“Scrumban”工作方法。他们借助 Scrum 执行固定时间周期的冲刺并设定角色,同时利用看板关注在制品限制和周期时间。然而,对于刚刚开始实施敏捷开发的团队,我们强烈建议您选择其中一种方法,并运行一段时间。日后可以不断变换方法,尝试新花样。
免费开始使用 Jira 看板模板
查看和推进最重要的工作,最大限度地提升效率。