敏捷开发：最通俗易懂的敏捷开发描述，一看就懂

Posted 2021-10-19 IT管理圈

敏捷开发分类：敏捷开发的实现主要包括 SCRUM、XP（极限编程）、Crystal Methods、FDD（特性驱动开发）等等。其中SCRUM与XP最为流行。

同样是敏捷开发，XP 极限编程 更侧重于实践，并力求把实践做到极限。这一实践可以是测试先行，也可以是结对编程等，关键要看具体的应用场景。
SCRUM则是一种开发流程框架，也可以说是一种套路。SCRUM框架中包含三个角色，三个工件，四个会议，听起来很复杂，其目的是为了有效地完成每一次迭代周期的工作。在这里我们重点讨论的是SCRUM。
敏捷开发（scrum）是一种软件开发的流程，强调快速反应、快速迭代、价值驱动。

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；运用该流程，你就能看到你团队高效的工作。

敏捷开发的特点就是下面4句话：

「个体与交互」胜过「过程与工具」

「可以工作的软件」胜过「面面俱到的文挡」

「客户协作」胜过「合同谈判」

「响应变化」胜过「遵循计划」

敏捷开发（scrum）适用于竞争激烈，快速变化的市场。 敏捷的客户协作观念，快速迭代能帮助团队以最小成本，最快速度满足客户真正的需求。对比传统开发模式：

传统开发模式以文档为驱动，而敏捷开发提倡少写文档

传统开发模式下开发人员按照产品文档进行研发，过程中客户不参与到产品的验收和体验中，这样就会导致最后开发出来的成品并不是客户想要的。 而敏捷开发模式从开始就强调客户协作，分步提供产品模块客户体验。

敏捷模式采取迭代式开发，传统模式采用瀑布式开发

敏捷开发采取迭代式开发的形式，即每个阶段有每个阶段需要完成、并且能使用的产品，这一阶段只要开发某几个功能，且这些功能的产品必须是可以使用的，这一阶段产品完成之后与客户进行对接交付，再进行下一阶段的开发。

敏捷开发更适应变化

传统开发模式下软件开发过程是执行研发计划，而实际工作中，需求往往在开发过程中会产生巨大变化。敏捷开发更能适应不确定性强的产品和市场。

接下面我们来具体看一下执行scrum的套路。

Scrum的三大角色

产品负责人（Product Owner）

主要负责和客户沟通确定产品的功能和达到要求的标准，并指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果，一般是由产品经理担任。

流程管理员（Scrum Master）

问题清道夫！主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

开发主力！主要负责软件产品在Scrum规定流程下进行开发工作。人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；不论过程只问结果！只要能达到目标，不论任何工作时间、方式。

Scrum的组成

Sprint：指的是一次迭代，而一次迭代的周期最好是1-4个星期，也就是我们要把产品需求分布到各个周期完成，这个过程我们称它为Sprint。

Story：用户故事，也可以看做是用户需求点。

Task：story的进一步细分。为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task 的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。

Backlog：Backlog是Scrum中的一个专用名词，意思是待办工作事项的集合。在开发中需要明确2个Backlog。

Product Backlog ——产品待办事项列表，产品负责人量化用户需求，逐条列出实际需要开发的需求（Story）。

Sprint Backlog——任务列表，是一次迭代中需要完成的任务，主要是开发团队细化工作的列表。

燃尽图（Burn Down Chart）

是一个展示开发时间的图，但是展示的是每天累加所有任务的剩余时间。

燃尽图是用来跟踪sprint中未完成工作的情况。每做完一个sprint的用户故事就烧掉，最后烧完sprint也就完成了。用蓝色线表示计划走向，红色线则是实际走向，两条线共同组成了燃尽图。如下图，每一个点代表一个用户故事，或者故事点，或者可度量的工作量。所有点组成sprint。

4个会议

Sprint计划会

Sprint 计划会就是大家坐下来，PO 向大家介绍排好序的产品待办事项（Product Backlog），然后大家共同思考决定如何推进计划，梳理出 Sprint Backlog 来完成后续的工作。

每日站会

每位开发成员都要交代3点

昨天完成了什么

今天计划完成什么

是否有困难需要帮助

每日站会

上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的看板和燃尽图。

Sprint 评审会

当一个Sprint完成，这时就要进行最重要的演示会议，也称为评审会议，产品负责人和客户都要参加，每一个开发团队的成员都要演示自己完成的软件产品，然后被判定产品合格、成功、需要修改还是重新做。

Sprint 总结会

总结会议以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。

以上的会议都不需要准备PPT或者大量的文档，但要注意会议的时长。

使用鱼骨Scrum项目的开发步骤

1.产品负责人使用产品Tab收集产品需求（story）。

Product Backlog

2.开发团队根据Product Backlog列表，在Sprint计划会议中做工作量的预估和安排，确定需求提交研发，进入Story看板。

Story看板

3.确定Sprint周期（1-4周）和本次开发迭代冲刺的开发需求（Stories）。进入Sprint的story出现在Task看板。 在Task看板，研发团队可以拆分Story到任务进行协作。

Task看板

5.每日立会，团队更新Task看板，和Story看板，保持信息的同步。

功能强大的鱼骨精益看板能协助开发团队更好的实施SCRUM。