软件工程中的看板模型是什么?

什么是看板?
看板 是敏捷软件开发方法中非常流行的开发框架。它提供了一种透明的方式来可视化团队的任务和工作能力。它主要使用物理和数字板,让团队成员能够直观地了解他们正在处理的项目的当前状态。
看板起源于 1940 年代的丰田。看板在日语中的意思是“广告牌”。看板上有栏目和故事卡。栏目什么都不是,但工作流状态和卡片只是团队成员正在执行的实际任务的演示。
这些卡片传递的是即时生产信号:工作站只在实际需要时才请求零件,因此不会提前生产任何东西。看板保留了这一理念。它是一种叠加在现有流程之上的方法,而不是替代它,因此它适用于任何流程。 软件开发生命周期 您已运行的模型。
何时使用看板?
看板方法适用于工作进度难以预测,且需要在项目完成后立即发布的情况的团队。以下是使用看板方法的主要原因:
- Kanban 可用于任何领域,在软件开发中可以非常有效地使用。Kanban 项目管理有助于提高团队的效率。
- 这是一个基于拉动的系统。只要一个人有空,任务就会被拉动。
- 当你想随时发布你的工作时,应该使用 Kanban。它需要 git 分支,但这是可行的。
- 当您想随时更改优先级时,应使用看板。为此,您需要做的就是将此故事放在待办事项队列的顶部。
- 当您想要可视化您的工作,并且想要直观地看到您的任务的进度时,应该使用它。
契合度是决策的一半;下面的收益是另一半。
看板方法的优势
看板最强有力的论点在于,它能在不强制重组的情况下提升交付效率。无需更改任何人的职位,也无需强制执行迭代计划,看板就能让排队、阻塞和超负荷工作的人员在第一天就一目了然。每个人都能看到的瓶颈往往更容易得到解决。
持续采用看板方法的团队报告了以下益处:
- 更短的交货时间: WIP 限制减少了卡片等待的时间,而等待正是造成延迟的主要原因。
- 更高的灵活性: 紧急事项可以随时升至待办事项列表顶部,无需等待迭代。
- 更好的协作: 当一栏达到字数限制时,免费会员会帮助清除该栏内容,而不是创建新栏。
- 员工授权: 个人可以自行选择下一张信用卡并拥有其所有权,从而消除审批瓶颈。
- 可预测的预测: 历史周期时间可以提供基于事实的交付时间估算,而不是猜测。
- Less 浪费: 系统没有能力完成任何事情,就不会启动它。
这些结果源于看板实施中遵循的四个原则。
看板的四个原则
以下是看板的四大核心原则:
- 从你现在拥有的开始:看板系统建议逐步开展工作,从您目前拥有的开始。由于其实践之一是持续改进,因此您必须逐步改进系统。
- 同意追求渐进式、渐进式的变革: Kanban 建议对流程进行渐进式的改变,并且不能一次性对流程进行大的改变。
- 尊重当前流程、角色和职责: 再次,从您现有的东西开始,逐步改变流程、角色和职责。
- 鼓励各级领导行为:每个个体都可以充当领导者,为提高整体看板系统的效率提供想法。你不要以为这是管理层的活动,甚至团队中最年轻的成员也可以充当领导者。
原则描述的是思维模式。以下六项实践描述了将这些原则付诸实践的日常行为。
看板的六大核心实践
以下是看板的六大核心实践:
- 可视化工作流程这条原则建议使用看板(实体或电子版)来可视化工作流程。团队中的每位成员都必须看到自己的卡片以及其他成员的卡片。您可以根据看板布局将卡片移动到不同的列中。这大大提高了团队内部的透明度,也使解决障碍变得更加容易。
- 限制正在进行的工作:看板是一种基于拉动的系统,它通过限制正在进行的工作并让团队在给定的时间范围内完成任务来提高团队的效率。此 WIP 限制适用于工作流程从开始到结束。您可以使用正整数在列顶部应用限制。
- 注重流量:该原则关注流程和任何中断。如果出现中断或阻碍,必须永久修复。
- 明确政策:团队可以制定政策来减少返工,并将注意力集中在需要关注或更有效的领域。
- 反馈回路:反馈循环在看板中非常重要。它不仅存在于团队内部,还存在于多个团队、教练等之间。这有助于改善看板系统的整体健康状况。
- 持续改进:这是看板系统的核心原则。它表明您可以随时改进流程,从而提高效率。
实践需要负责人,看板处理负责人的方式与其他方法不同。 敏捷方法论.
看板的角色和职责
看板方法不规定新的职位名称,这是有意为之——第三条原则要求你尊重现有的角色。开发人员仍然是开发人员。然而,在实践中,随着看板的成熟,会出现两项新的职责,成熟的实现方案会明确地定义这两项职责。
此 服务交付经理 负责看板上的工作流程。此人会监控停滞不前的卡片,上报阻塞问题,确保各列的在制品数量在限制范围内,并主持评审会议,让团队检查自身的周期时间数据。 服务请求管理器 它拥有进入看板的内容,代表提出请求的客户,对待办事项列进行排序,使最有价值的项目位于顶部,并明确选择策略。
两者都是职责而非额外人手;通常由一人承担。关键在于有人负责流程,有人负责数据接收。他们管理的具体工作内容则放在其次。
看板卡
看板方法提倡工作可视化。它建议使用实体看板和电子看板,下图展示了这些看板列,卡片分布在各列中。
看板卡是看板上必不可少的部分,因为它代表了团队正在进行的工作。这些卡片将具有
- 优先
- 所有者
- 类型
- 截止日期
看板中的一列代表工作阶段,您可以在该列上设置 WIP(进行中的工作)限制。 WIP 限制表示该列上可保留的最大卡片数量.
由于看板方法采用的是拉取式系统,开发人员一旦有空,就可以将卡片从待办事项栏拉到开发栏。因此,这些卡片所在的看板值得我们仔细研究。
看板
看板 是一款敏捷项目管理工具,可帮助实施看板来管理个人和商业项目。它是一个物理或数字(JIRA)板,旨在帮助团队可视化他们在不同阶段和流程的工作。它还有助于使用卡片以列的形式表示工作阶段。
它有代表工作状态的列,例如
- 去做,
- 开发
- 测试与验证
- 完成。
每一列都可以有卡片 <= WIP 限制。卡片代表实际工作。
您可以使用正数来限制在制品数量,并且该限制数量可以放置在实体看板和数字看板的列顶部。团队中的任何成员都可以管理自己卡片的状态,整个团队都可以直观地了解工作流程。 Digi诸如板条之类的 JIRA 添加与自动循环时间相同的限制 trac接下来,我们将学习这些列所代表的看板工作流程。
看板工作流程
看板工作流程 是帮助团队在看板中定义明确政策和原则的一组步骤。它代表了在开发和交付周期的各个阶段进行工作时的规则和程序。看板工作流由特定任务的开始和交付之间的逐步过程组成。
Kanban 遵循的基本原则是, “停止开始,开始结束”。 借助 WIP 限制,可以完成更多工作。任何现代工具(如 JIRA)中都有可自定义的看板工作流程和状态。
以下是许多软件团队在工作流管理中遵循的基本状态。
| 州 | 理解任务 |
|---|---|
| 去做 | 任务第一次到达这里时就是这个状态。 |
| 准备进行分析 | 分析任务并完整添加需求。 |
| 准备开发 | 分析完成并可以开始开发。 |
| 在发展中 | 任务正在制定中。 |
| 准备测试 | 开发完成,现在可以开始测试了。 |
| 在测试中 | 任务正在测试。 |
| 准备发布 | 测试完成;可以发布。 |
| 发布/完成 | 发布。 |
请注意,“准备就绪”状态指的是队列,而不是工作。一张卡牌可以无限期地停留在队列中,因此移动卡牌的规则比状态本身更重要。
基于拉动的系统
看板是一种基于拉动的方法,任务是被拉动而不是被推动的。完成当前卡片后,您可以从看板的上一列中拉出一张新卡片。
有了 WIP 限制,看板有助于改善前置时间和周期时间。这两个时间之间的差距应该尽可能小。例如,我们有 5 名开发人员和 1 名测试人员;在这种情况下会发生什么?总是会有很多需要测试的卡片,它们会闲置并等待。
为了克服上述问题并提高效率,看板遵循具有 WIP 限制的拉动式方法,其中拉取的卡片数量有限。
因此,测试人员在完成手头的当前任务后,将从“准备测试”阶段提取任务。有了看板列(开发阶段)中的 WIP 限制,看板工作流程中就不会出现很多无人看管的卡片。
这种拉动式系统还有助于找到团队合适的生产速度。有了合适的生产速度,团队就能表现得更好。这一切都取决于一个数字:在制品限制。
限制 WIP(在制品)
在看板方法中,在制品限制了团队成员或整个团队一次可以处理的任务/卡片的数量。
WIP 限制可确保团队稳定工作并提高预测性,这在拉动式系统中至关重要。通常,WIP 限制决定由团队自己做出。
设置 WIP 限制的原因
设置 WIP 限制的原因如下:
- 它将注意力转移到完成任务上,因为个人每次只专注于一项任务。
- 它可以帮助团队了解他们的能力。
- 它提高了生产效率和周期时间。
- 它有助于避免任务堆积(在等待模式下)。
- 它能改善工作流程,使任务持续推进。
- 由于个人无需在不同任务之间切换,因此也有助于解决障碍。
⚠️警告: 限额设置过高与不设限额的效果相同——卡片排队时间延长,结算周期也随之延长。限额设置过低则会导致用户闲置。建议每次只调整一列的限额,并观察两周的结算周期。
这是理论的最后一部分;下面的章节将把它转化为行动。
如何逐步实施看板
看板方法很容易上手:第一步描述你目前的工作内容。让所有团队成员都参与进来,一起完成这一系列步骤。
- 绘制当前工作流程图。 将一件成品反向追溯到它经过的每一个交接环节。每一次交接环节都会形成一列,其中包括无人正式拥有的等待状态。
- 画出棋盘。 一列代表一个州,从左到右,最后一列写“已完成”。第一个月用一块贴满便利贴的白板就足够了。
- 写卡片。 给每件飞行物品贴上一张卡片,卡片上需注明优先级、所有者、类型和到期日,然后将其放置在与其实际状态相符的列中。
- 为每一列定义“完成”状态。 把退出标准写在黑板上。这种明确的政策做法可以防止卡片反弹。
- 设置初始在制品限制。 使用以下方法为除“待办事项”和“已完成事项”之外的每一列选择一个起始数字,然后将其写在标题上方。
- 同意拉动规则。 当自己所在列达到上限时,没有人会开始制作新卡牌;他们会帮助清理自己右侧的列。
- 每天巡视董事会。 从右到左,先看最老的牌,询问是什么阻碍了这张牌,以及今天谁可以解除阻碍。
- 先量好尺寸,再拧紧。 两周后,周期时间数据显示哪一列卡片存放时间最长。降低该限制或增加容量,然后重复上述步骤。
第五步是大多数团队都会遇到的瓶颈,因此这里介绍从业者常用的三种规模评估方法:
| 在制品尺寸测量方法 | 它是如何运行的? |
|---|---|
| 团队人数加一 | 人数上限等于该列的工作人数加上一个用于处理阻塞项的额外名额。最适合没有数据的新看板。 |
| 每人两到三件物品 | 将列中的人数乘以二或三;三个开发人员,每人两项,共六个人。 |
| 吞吐量 x 周期时间 | 将 WIP = 吞吐量 x 周期时间应用于您自己的历史记录,然后将限制值设置得略低于计算结果。 |
将第一个数字视为假设。将棋盘与正式的 敏捷测试 这样可以防止测试列成为瓶颈,下面的两个计时结果显示了它是否有效。
交货时间和周期时间
在看板方法中,提前期和周期期被广泛使用,两者之间存在区别,理解这一点很重要,以免混淆。
| 交期 | 周期 |
|---|---|
| 前置时间是指任务到达工作流程和离开工作流程(即任务已被发布)之间的时间。 | 周期时间是指任务到达“进行中”状态和到达“准备发布”状态之间的时间。 |
这里还需要理解的是不包括从准备发布到实际发布之间的时间。
Cycle Time = Work in Progress/Throughput
💡提示: 客户体验到的是交付周期;团队可控的是生产周期。交付周期过长意味着工作需要排队等待才能开始处理,因此在加快团队速度之前,应先解决订单接收问题。
理想情况下,交付周期和生产周期之间的差距应该尽可能小。看板方法使用累积流程图 (CFD) 来衡量交付周期和生产周期的历史数据。下一节将详细介绍该流程图。
累积流程图 (CFD)
CFD 是一种可用于所有主要 工作流管理工具 就像 JIRA。此图表衡量进入工作流程的工作卡/任务的总量以及随时间推移积累的已完成卡/任务的总量。
它可以帮助您估算预定时间内的平均交货时间和周期时间。
CFD 图可以提供指标或需要改进的问题区域。它能为您提供清晰的视图,您可以根据此图来调整团队的交付周期和生产周期。下面的累积流程图将每个状态绘制成彩色条带;不断加宽的条带代表瓶颈。
该图表通过四个量来解读:
- 交期:这是新卡片到达工作流程和最终离开工作流程之间的持续时间。
- 周期:这是卡进入工作状态和卡准备好发布的时间间隔。
- WIP:在制品(WIP)限制工作流程不同阶段中工作项的最大数量。
- 生产能力 :这是实际表现,它告诉我们在给定时间范围内实际交付的卡片数量。
Throughput = WIP/Cycle Time
这涵盖了工件、机制和指标。剩下的问题是看板与 Scrum 相比如何。
Scrum 对比。看板
以下是 Scrum 对比。看板如需了解更全面的信息,请参阅…… 敏捷开发与 Scrum.
| 争球 | 看板 |
|---|---|
| 争球 强调规划。它从冲刺规划开始,以冲刺回顾结束。举行了许多会议,帮助确保团队与接下来的步骤、优先事项以及从以前的冲刺中学到的知识保持一致。 | Kanban 可以随时做出改变。这意味着僵化程度较低, 事情可能会经常改变. |
| 它建议收集 时间测量 在冲刺期间制作 | 看板 推荐图表 了解团队在一段时间内取得的进展。 |
| 争球 不再? 要求团队做出承诺。相反,它关注的是冲刺目标和预测。 | 看板依赖于 时间限制和预测. |
| 它强调规划,因此 估计有非常重要的作用 在 Scrum 中 | 看板具有 无强制要求 进行估算。 |
| 所有的 每个人都有自己的角色 和责任。 | 没有 设置角色以便灵活 就个人职责而言。 |
| 迭代/Sprint持续时间是固定的。持续时间从 2 周到 1 个月不等。 | 看板是 不基于持续时间. 这是根据周期时间来衡量的。 |
| 团队是 必须承诺 特定量的工作。 | 无需承诺 对于团队来说这是可选的。 |
| 用这种方法 跨职能团队 非常重要,因为它们可以处理可能导致软件开发瓶颈的任何中断。 | 有 专业团队 很重要 |
| 这是 无法添加商品 持续迭代。 | 全新发布 项目可以轻松添加 如果有额外容量可用。 |
| 冲刺待办事项列表仅由 单队. | 多团队可以共享看板。 |
| 可交付成果是 由冲刺决定,其中必须完成一组工作并准备好进行审查。 | 产品和流程 持续交付 根据需要。因此测试和审查过程同时进行。 |
| Scrum软件开发方法 专注于积压工作. | 完全看板方法 专注于流程仪表板. |
| 所有的 团队成员有特定的角色 在 Scrum 中,主管决定时间表,产品负责人设定目标和目的,团队成员进行开发工作。 | 团队没有预先定义的角色。但是,可能仍会有一个项目经理;鼓励团队协作和共同努力。 |
| 最适合以下项目 改变优先事项. | 适合以下团队 稳定的优先事项 随着时间的推移,这种情况不太可能发生改变。 |
| 测量生产 使用速度 通过冲刺。 | 使用以下方法测量产量 周期 或完成整个项目所需的确切时间。 |
| Scrum 需要 彻底改变传统模式 到将要实施该项目的 Agile Scrum 模型。 | 看板 不允许剧烈变化 在项目中。 |
| 在 Scrum 中,整个eam 专注于协作并完成任务 提供优质的开发工作。 | 团队努力实现目标 并减少完成整个过程的时间。因此,缩短时间周期是这里成功的最大指标。 |
| 争球 强调时间表;无法将新项目添加到正在进行的迭代中。 | 看板本质上更具迭代性,因为它 没有具体的时间表.这样,只要有额外容量,就可以不断添加新项目。 |
| 总工作量为 批次/Sprints. | 整个项目是在 单线程工作项 流动。 |
| Scrum大师 充当问题解决者。 | 看板鼓励 每个团队成员都是领导者 并共同承担责任。 |
| Scrum 规定 时间盒迭代. | 看板重点关注 计划不同的持续时间 进行单独迭代。 |
| Scrum 帮助企业 节省时间和金钱. | 看板法 注重持续改进、生产力和效率。 |
| 稳定一致的沟通 各个层面的表现。 | 团队成员更有可能 更容易实现目标 因为看板的视觉特性。 |
| 这是 更容易适应不断的变化 因为短跑和定期反馈。 | 这是 设计用于稳定输出,客户需求的重大变化可能会导致看板失败。 |
| 该项目的总成本很小,这可能导致 更快、更便宜的结果. | 如果一项任务没有被正确估计, 项目总成本永远不会准确。在这种情况下,任务可以分散到几个冲刺中。 |
| 这种方法论 需要经验丰富的团队成员 仅此而已。所以,如果团队中没有专家,项目就无法按时完成。 | 没有 具体时间范围 每个阶段都会分配时间,因此团队成员永远不知道每个阶段需要花费多少时间。 |
| 在这个敏捷 Scrum 方法中, 更容易提供优质产品 在预定的时间。 | 它专为 规律、稳定的输出, 客户需求的重大变化会导致看板方法失效。 |
| 此 项目计划绝不会打扰 即使团队成员离开团队。 | 如果任何团队成员在开发过程中退出,可以 损害项目发展. |
| 有时每天开会 阻挠 团队成员。 | 过时的看板 可能会导致开发过程中出现问题。 |
| 大型项目可以轻松划分 进入易于管理的冲刺。 | 大型项目按以下方式处理: 连续流动 单个物品,而不是分成多批。 |


