当前位置：首页 > article >正文

什么是敏捷（Agile）开发？Scrum和Kanban有什么关系？

article 2024/12/4 16:20:27

最近面试过程中被问到和敏捷开发相关的内容，在产品实际工作中经常会涉及到敏捷开发，但其实我自己没有系列了解过敏捷开发，除了考PMP的时候接触了下，大多数都是在工作中实践积累的，太接地气，为了稍显理论知识的充裕，还是想要弥补一下理论层面的一些“学术语言”！🤣

一、敏捷开发背景和起源

众所周知，产品从想法到原型图到UI设计图到开发到测试最终上线需要经过几个环节的流转，前前后后可能需要花上半个月到一个月的时间，需求比较复杂的时候可能需要花上几个月。在这期间的任意环节都有可能发生变化导致需求回退重新走上一步，下一步都会受限于上一步。此外还有可能涉及资源等的变化等等。

敏捷，常常会跟软件开发的瀑布模型（waterfall）来进行比较，waterfall是老式的开发周期比较长，敏捷一般是小量迭代的，适应快速的市场变化的。敏捷方法通过提供灵活、迭代的项目管理方法，改变了软件开发。敏捷方法中最著名的框架是 Kanban 和 Scrum。虽然这两种方法都旨在提高生产力和效率，但它们的运作原则和实践却截然不同。

二、Scrum

Scrum是一种为软件开发和项目管理团队提供的敏捷框架，允许团队为实现共同目标而自主组织和协作。这种框架提供了一种结构化的协作方式，使团队能够以渐进和迭代的方法交付具有高价值的产品。
在这里插入图片描述

流程：

PO从不同来源获取需求（用户故事）然后进行梳理，产生产品待办列表Product backlog；
组织Spint planing Meeting，和团队共同从Product backlog中挑出若干需要在Sprint结尾完成的内容，在Sprint Planning中进行分析和拆分，会议输出sprint backlog（这次sprint要做的事情）和sprint goal；
进行迭代开发，在每个spint期间，每天有daily scrum（每日站会：≤15min）；
每次sprint完成后输出可交付的产品增量increment；
在spint review对increment进行review评审（目的是展示Sprint成果，收集利益相关者的反馈，并更新产品待办事项列表。它关注的是产品增量，确保产品满足利益相关者或客户的期望。）；
同时有sprint retrospective会议去总结团队成员做得好的做得不足的。（目的是评估团队在前一个Sprint中的工作表现和流程，讨论如何改进未来的工作流程。它关注的是团队的工作方式，包括沟通、团队合作、流程、工具等。）

Scrum Master（即流程管理员或者项目经理）组织和把控整个流程。
在这里插入图片描述

构成

3个组件：product backlog、sprint backlog、increment
- product backlog：待办事项
- sprint backlog：某次sprint要做的待办事项，由product backlog挑选出来放入sprint backlog
- increment：是一次sprint完成后的产出，即 “产品增量”，是产品增加了什么、修改了什么
3个角色：product owner、scrum master、development team
- Product Owner（PO）：产品经理，即"产品所有人"，对product backlog负责；
- Scrum Master（SM）：即敏捷教练/项目经理/流程管理员，管敏捷流程的人
- Development Team：开发团队，由开发、测试等人员组成。
5个事件：sprint、sprint planning、daily scrum、sprint review、spring retrospective
- sprint：某次迭代周期要做的事情，如sprint 1 / sprint 2 …（一次sprint安排的量通常是 1-3周完成），一般命名比如 sprint 1 加数字；
- sprint planning：在这个会议中讨论并从product backlog挑出下次sprint要做的事情，输出有sprint goal和sprint backlog
- daily scrum：每日站会，也有叫daily meeting/daily standup/standup meeting，会上每个人一般会说明昨天做了什么、今天做什么、遇到什么困难
- sprint review：对交付内容（即产品增量）进行review，即审查结果（for产品）
- sprint retrospective：回顾会，会上讨论做得好的做得不好的，是一个总结类似复盘的会议。（for人）
3个文件：product backlog、user stories、burndown chart
- user story：用户故事，一般是用 “作为…我需要…以便…” 描述用户的需求
5个价值观：respect、openness、courage、commitment、focus

三、Kanban

Kanban是一种用于IT项目管理的工作流管理方法，它强调可视化工作、最大化效率和实现持续改进。这种方法专注于对正在进行的项目进行演进式的调整，以提高效率和减少浪费。分为物理看板和电子看板。

Kanban方法以价值流动为核心，不断发现团队中的瓶颈工序进行改进，使价值流动更加顺畅和快速。简单的说，就是保证软件的持续集成并且不让开发团队超负荷。

在这里插入图片描述
组成部分：

泳道（甬道）：每个泳道都是过程中的一个阶段。例如敏捷开发过程：建立需求池、搜集用户故事→ 评审需求、规划迭代→ 进度管理、团队协作→ 用例管理、缺陷追踪→ 评审回顾、总结沉淀。每个泳道可根据工作完成情况再进行划分。
WIP限制（Limit Work In Progress）：决定了每种情况下工作流中可以存续的最大工作量。限制是看板和其他管理系统最大的区别。在流程的每一步限制在制工作量（WIP），可防止生产过剩，并动态揭示瓶颈，以便在瓶颈失控之前得到解决。在Kanban方法的中，下游任务完成后，即可拉动上游任务下移，同时，只要生产力允许，即可新增需求。
卡片：团队需要处理的任何事。研发团队关注的是待交付的新功能，但是要注意按高优先级将待交付的需求排序再开展工作。

Kanban管理模式简洁而有力。一个简单的Kanban系统甚至可以由一张大纸板和贴在上面的便签组成。在这个系统中，大纸板上画有多个列表。一个列代表一个工作步骤，一张便签即代表一个任务。每个任务都经过这个工作流程从最左边的列流向最右边的列。

优点

1）可视化工作流程。所有的工作进度会全部显示在Kanban上，每一个人都可以一目了然了解自己的工作进度以及项目进度、流程以及瓶颈，能够增加团队之间的协作，使他们能够集中精力促进流程。

2）限制在制工作，可以避免任务切换导致的问题，并减少不断重新确定项目优先次序的需要。WIP 限制释放了看板的全部潜力，使团队能够在更健康、更可持续的环境中以比以往更快的速度提供高质量的工作。

3）管理并优化流程。Kanban能够动态地展示团队工作流程的瓶颈。一旦项目管理者发现某个环节影响到团队进度，t就可以及时调配相应的资源改进这个环节，使流程得到优化。

4）缩短开发周期。可以更好的发现问题，解决问题，从而找到更科学的方法提高开发效率。

四、Scrum和Kanban

在这里插入图片描述

工作方式

Kanban:
1. 适用于持续流动的任务管理，没有固定的时间周期（迭代）。
2. 工作项随时进入看板并处理，团队可以根据需要不断增加和减少任务。
3. Kanban强调可视化工作流程、限制正在进行的工作项（WIP 限制）以及持续优化流程。
Scrum
1. 适用于敏捷方法，工作被分割成时间固定的冲刺周期（通常为 1-4 周）。
2. 在每个冲刺开始时，团队从待办事项（Backlog）中选择一批任务，并计划在冲刺结束时完成它们。
3. Scrum 强调计划、回顾、每日站会、以及交付可工作的增量。

目标

Kanban：保持流程顺畅，持续交付价值，工作项按优先级处理，适合持续交付和改进的团队。
Scrum：通过固定周期的冲刺，在每个冲刺结束时交付一个可以交付的增量成果，适合迭代式开发的团队。

优先级和计划

Kanban：没有冲刺的概念，任务会按优先级排队，团队成员根据当前的工作量拉取任务。
Scrum：任务被提前计划好，冲刺开始后，团队承诺在冲刺结束前完成所有任务。计划完成后，在冲刺期间不允许添加新任务。

进度跟踪

Kanban：主要通过累积流图（Cumulative Flow Diagram）跟踪任务的流动，观察瓶颈和完成率。
Scrum：使用燃尽图（Sprint Burndown Chart）跟踪团队在冲刺期间完成的工作，评估能否按时完成目标。

任务的完成时间

Kanban：强调缩短单个任务的周期时间（Cycle Time），没有冲刺的结束时间，任务在流动中完成。
Scrum：任务必须在冲刺结束时完成，团队在开始冲刺时制定目标，并承诺在冲刺结束时交付成果。

总结

在这里插入图片描述

Kanban Board 适用于持续交付和流程优化，任务可以随时加入、优先级可以随时调整。
Scrum Board 适用于迭代式开发，团队通过冲刺周期进行计划和交付，固定周期内完成任务。
创建 Scrum Board 通常会间接创建一个项目，因为 Scrum 的工作模式依赖于项目的框架来管理冲刺、任务和进度。

五、实际应用

商家爱公司主要是通过TAPD进行项目管理，其实这个过程中两种管理方法都有用到，业务在TAPD建业务需求（原始需求），产品收集后（用户故事），产品或者产品团队内部进行需求评级和筛选（产品待办列表）后输出方案，拉着产研负责人进行需求评审（Sprint backlog）看在两周内能否完成预定的这些需求，迭代期间每日站会可能会涉及到阻塞或需求变更或产品代办列表变更等，完成一个小迭代（Sprint）后进行阶段性交付（iiincrement）以及迭代回顾方便调整下个sprint的内容，同时会进行复盘（retrospection）看看协作、资源等等整个过程中有可能优化的一些内容。一次循环往复不断迭代。
在这里插入图片描述