看板

如今，敏捷软件开发团队已经能够将正在进行的工作 (WIP) 量与团队工作能力相匹配，从而利用相同的 JIT 原则。这在整个开发周期中为团队提供了更灵活的规划选项、更快的输出、更明确的重点和透明度。

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

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

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

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

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

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

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

看板团队只关注眼下正在进行的工作。团队完成一个工作项目后，会将下一个工作项目从待办事项的顶部移除。产品负责人可以在不干扰团队进度的情况下自由调整待办事项中工作的优先级，因为当前工作项目之外的任何变动都不会影响到团队。只要产品负责人将最重要的工作项目置于待办事项顶部，开发团队就会明确地知道这些项目将给企业带来最大价值。因此，您无需像在 Scrum 中一样进行固定时长的迭代。

对看板团队来说，周期时间是一项重要指标。周期时间指的是一个工作单元通过团队工作流所花费的时间，从工作开始的那一刻起，到工作交付的那一刻结束。通过优化周期时间，团队可以充满信心地预测未来工作的交付情况。

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

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

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

例如，典型的软件团队可能有四个工作流状态，分别是待办、进行中、代码审查和已完成。他们会选择将代码审查状态的 WIP 限制设置为 2。这一限制似乎很低，但却有充分理由：开发人员通常更喜欢编写新代码，而不是花时间审查别人的工作。低限制可鼓励团队特别注意处于审查状态中的事务，并在提交自己的代码审查之前审查他人的工作。这最终缩短了整体加工时间。

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

持续交付 (CD) 是指频繁向客户发布工作。持续集成 (CI) 是指在一天当中以增量方式自动构建和测试代码。两者共同组成了 CI/CD 管道，这也是开发团队（尤其是 DevOps 团队）在保证高质量的同时加快软件交付的关键。

看板和 CD 互为补充，相辅相成，因为这两种技术都注重即时（以及逐一）交付价值。团队向市场推出创新的速度越快，他们的产品在市场上的竞争力就越强。而看板团队专注的正是：优化与客户之间的工作流程。

看板和 Scrum 虽然具有一些相同的概念，但它们是截然不同的两种方法，不应将它们混淆。

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