8000字扫盲干货！互联网人必须掌握的敏捷工作方法

今天讨论的话题，也是一个作为互联网人绕不开的东西 —— 敏捷。多数互联网团队都会去搭建敏捷型的项目流程和管理模式，以期获得更好的投入回报。但是，多数情况下搭建的敏捷流程都不是非常有效，既不能解决效率的问题，往往还制造了更多问题。

尤其作为非开发岗位的产品、设计、运营，更是没办法搞明白敏捷是什么，只能机械的依据开发团队提出的流程执行，全程一头雾水。而且敏捷是目前面试环节中出现频率越来越高的一个词汇，在执行或想要执行敏捷流程的团队，都希望新招募的成员熟悉这些内容，可以快速融入团队的文化和流程之中。

所以，这篇分享就是作为敏捷的扫盲，用最简单的你们能理解的方式来解释它是什么。

更多扫盲干货：

一、敏捷 Agile 的基本认识

敏捷的英文原文是 Agile，是本世纪初兴起的一种新的项目管理方法论。敏捷不是一个凭空出现的构想，而是基于现实缺陷提出的解题思路，理解敏捷就必须理解它是如何产生的。

首先我们知道，软件开发这个行业在欧美从上世纪 60 年代就已经兴起了，到 2000 年的时候已经经历了快半个世纪的发展。而在这个阶段中，大多数软件的开发都是使用最传统的 “瀑布式” 流程。

瀑布式指的就是像瀑布一样从上到下倾泻落地的过程，它的本质是将项目的待办工作进行“有序”的规划，并依次完成。

比如你在周末准备花一天的时间给家里做大扫除，那你可能会先做个简单的计划：

1. 清理全屋的如饮料瓶、纸团、包装袋等固体垃圾
2. 将屋内凌乱的物件进行重新摆放和收纳
3. 清洗包含油烟机、空调等悬空的家电
4. 清理窗户、窗帘、架子等其它悬空的家具和装饰
5. 用强力清洁剂清理地面缝隙和厨房、卫生间角落
6. 完成全屋地板的清扫和吸尘
7. 使用蒸汽拖把完成所有地板的杀菌清理
8. 替换床品四件套，并进行洗涤晾晒

这就是瀑布式的管理模式，将所有待完成的任务罗列出来，并将它们以必要、合理、有序的方式进行排序。比如清洗悬空的家电、家具必然要在地面清理之前，不然先清理干净的地板等等又得被弄脏，还要花额外的精力再清理一次地板。

所以一样的工作目标，如果没有经过合理的计划就会产生很多工序上的矛盾，制造额外的工作量和时间，降低实现的效率。瀑布式的贡献，就在于完成指定目标时，能把所有工作内容都分解出来，并制定出合理的流程，提升执行的效率，减少所需的时间成本。

这种做法的好处有不少，目前很多行业也依旧在应用这样的方法，比如建筑施工、工业生产、大宗货运等，都会制定出清晰的瀑布式流程来确保项目的执行。早期的软件行业当然也使用这样的流程驱动，先进行需求规划，然后设计，再进行开发，完成测试后发布。

在早期，软件项目一方面规模较小，另一方面发布很多时候是需要刻录进软盘或光盘中，形成一个稳定、完整的版本进行备份和流通的。所以项目会有一个比较清晰的工作目标，围绕这个目标开展项目的规划和执行，那么自然瀑布式就会成为首选。

但这种做法随着整个 IT 行业的发展开始越来越受限，核心的原因随着项目规模越来越大，瀑布式开发的问题的弊端就越来越明显，那就是——软件开发不是建筑施工，做不到对多数工程细节的准确计算和规划。有大量的项目在进入到中后期阶段才发现非常基础的 BUG、漏洞、架构问题，导致项目要推倒重来。而这在正规的建筑施工中是不允许发生的，都要封顶了才发现地基打得不够深或低楼层承重柱数量设计少了……

还有一个问题，就是软件从立项到发布，能不能实现预期的效果也有非常大的不确定性。一方面用户不一定买账证实了项目的方向就是错误的，另一方面互联网加快了整个市场的发展节奏，促使产品需要进入更高频次的迭代和更新以适应市场的需要。

总结起来就是产品规模变大项目开发周期越来越长，而市场又需要越来越短的更新时间和迭代周期的矛盾。这个矛盾从上世纪末到本世纪初愈演愈烈，让各行业的开发工程师都苦不堪言。

于是，在 2001 年 2 月 11 日到 13 日，17 位美国程序界大佬举行了一次会晤，共同探讨软件开发的方法和经验，其中最重要的成果，就是起草了敏捷软件开发宣言（Manifesto for Agile Software Development），后续还有几位成员继续合作建立了敏捷联盟（Agile Alliance）。

宣言的内容包含 12 条基本的原则：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并以此调整自身的举止表现。

而这 12 条原则可以用 4 个基本的价值观概括，它们是：

1. 个体和互动高于流程和工具
2. 工作的软件高于详尽的文档
3. 客户合作高于合同谈判
4. 响应变化高于遵循计划

这就是敏捷的雏形也是核心思想，它的目的是树立一种解决问题的群体共识，而不是具体执行的方法论或行为。所以当瀑布式救不了当今的项目进度时，你就可以了解这些宣言内容，并以此为价值观来重建项目的工作方式和流程。

当然，不管你是宣言、价值观、原则还是方法论，都只是一些模糊的概念，需要建立一些更具体的明细方针用于执行，否则就只是空喊口号。而在敏捷为基础或基于敏捷做出改善的项目协作方式就陆续被提出，如极限编程（XP）、自适应软件开发（ASD）、特征驱动开发（FDD）、动态系统开发（DSDM）和 Scrum 等。

之所以提出不同的方式，是因为不同项目场景的情况差异巨大，在这个项目适用的不代表其它项目也能适用。虽然大家的目标相同，但自有国情在此，苏联走城市包围农村路线，而我们走农村包围城市的路线。

同时，上面提到的几种最常见的协作模式，也不代表它们百分百适用于你的项目，要都觉得不合适，团队可以创建独立的流程，如果选择了其中一种模式，也可以根据项目的实际情况做调整。

比如微软就在官网就写到他们的敏捷模式：

“At Microsoft, one such organization uses Agile to build products and services shipped under the Azure DevOps brand. This group has 35 feature teams that release to production every three weeks.”

翻译过来就是他们在 Azure 这款产品的开发上就实践敏捷，将整个项目划分成 35 个功能团队，并每三周发布一次产品。感兴趣的还可以在看完本章内容后去访问下面地址去查看原文，建议用英文原版阅读或使用 GPT 翻译不要看官网自动机翻的版本（根本看不懂）。

https://learn.microsoft.com/en-us/devops/plan/scaling-agile

了解敏捷，光知道这些概念肯定不行，所以下面我们肯定要具体学习某一种敏捷方法的细节，来建立更具体的概念。其中，Scrum 作为敏捷中最有代表性的的方法，是我们主要的学习目标，而其它敏捷方法就需要你们有兴趣的话自己去了解了。

二、Scrum的基本介绍

Scrum /skrʌm/ 这个词是一个橄榄球术语，表示争球的动作，它没有太官方或者大家普遍接受的准确翻译，所以一般直接用英文称呼它。

之所以用这个名字，是因为发明它的过程大量借鉴和使用橄榄球的比赛方式作为隐喻，球员需要协作争抢到橄榄球，并带球朝球门推进。这个过程不仅需要运动能力，还需要见招拆招、团队协作、快速冲刺，用尽一切手段朝目标迈进。

Scrum 这个词是在 1986 年被两个日本管理学者竹内弘高和野中郁次郎首次用于形容企业的管理上，但那时仅仅是描述了某种团队管理的理念，且不是针对软件开发流程。而后来这则信息在 90 年代被 Scrum 的主要创始人杰夫·萨瑟兰看到（敏捷宣言起草人之一），就用来命名自己所建立的团队协作方法上。

在随后的几年中，杰夫·萨瑟兰持续优化 Scrum 的内容和细节，直至敏捷宣言提出，它自然而然也就成为了敏捷的主要方法，然后才被广泛认识和应用。

我们目前学习的 Scrum 方法，是经过近 30 年改良和验证的版本（现在和我最早看到的版本就有很大的不同），其中有很多看似没有道理或者多余的步骤，都有充分的存在理由与必要性，需要抱着开放的心态去理解它们。

在介绍 Scrum 的流程前，首先要了解 Scrum 将整个团队划分成三个角色，每个角色要在正式实施前确认：

产品负责人 Product Owner

整个产品的直接负责人，制定产品的标准、交付日期和审核团队成果

敏捷教练 Scrum Master

负责帮助团队成员实践敏捷的流程，进行相关培训和引导前期的实践

开发团队 Scrum Team

产品的相关执行人员，以开发成员为主，也可以适当引入其它岗位

除此之外，Scrum 还会应用三个重要的项目工具：

需求列表 Product Backlog：

记录本次项目相关的产品需求列表，每一个需求包含对应的用户故事（User Story）

迭代列表 Sprint Backlog：

挑选出优先级高的要开始执行的用户故事（Sprint）的面板，反应进行中的需求

冲刺燃尽图 Sprint Burn Down：

用于表示时间和剩余工作量关系的一个图表，更直接的反应工作进度。

光看这些东西肯定是很让人费解的，所以下面我就要具体来介绍 Scrum 的执行流程了。

项目背景：

开发一个电商管理系统，产品经理们已经和领导、业务人员确定完相关的需求和明细，罗列了一大堆的需求出来，全部做完所需的时间至少需要半年起。在开始 Scrum 前，确定了其中一个产品经理作为 Scrum 的项目负责人，一个运维作为敏捷教练，参与的所有设计师和前后端程序员都是 Scrum 团队成员。

Step1.搭建 Scrum 产品需求列表

首先第一步，就是创建本次 Scrum 中的产品需求列表 Product Backlog，而这个产品需求列表和上面说的整个项目的需求列表是不同的。

原因是 Scrum 是有一定时间和范围限制，如果工作量过大，所需时间过长，会对整个流程造成很多负面的影响，且不利于敏捷本身的特性。所以项目负责人需要和其他产品、敏捷教练、主要负责人共同商议，从总的需求列表中拆分出一部分需求作为本次 Scrum 完成的对象。

通常，第一个 Scrum 要完成的工作肯定是项目中最重要的模块，可以以维持核心业务运作的标准进行筛选，比如创建商品、创建分类、用户管理、交易管理、物流管理等。而社交、网站统计、优惠券、分销这类功能就可以留给下个 Scrum 来完成。

产品负责人要把这些筛选出来的需求进行整理，放到一个列表中，作为本次 Scrum 的全部需求。可以是现实世界的任务看板，也可以是线上的表格工具。

看起来很简单，但实际上要完成的工作绝不只是把需求池的需求移动到 Scrum 需求列表而已，还要考虑需求的 “颗粒度” 和用户故事。

颗粒度指的就是需求的规模，需要耗费多少人力去完成。在原始的需求中，往往有一些需求的颗粒度很大，绝对不是一两天或一周内能完成的。比如实现物流管理模块，就得包含物流列表、查询筛选、物流详情、物流进度、费用结算等一系列操作和服务。

所以，产品负责人要在这个阶段直接对这些颗粒度很大的需求直接做拆解，把它们拆解成较小的需求，或者将一些非常零碎的需求合并成一个较大的需求，每个需求的颗粒度就应该是 2-5 天可以完成的级别。

然后就是整理这些需求的“用户故事”，这是 Scrum 中最重要的特性之一，即每条需求在具体应用场景中所实现的服务和功能。这里最大的思维挑战就是已经有了需求，为什么还需要用户故事？

原因就是需求仅仅只是一种死板的任务描述，比如要造一把锤子，以需求描述的话就是做个铁锤头，把它固定到木手柄之上，作为执行人我只要实现这个要求就可以了，至于后面锤头稳不稳，好不好用，是用于大型铆钉还是小图钉的场景就不归我管了。

但如果加入用户故事，那就是在需求下方还要额外增加一段：“用户使用这把锤子可以在较狭小的位置打上固线用的墙钉”。当这个要求一出来以后，应该怎么做这把锤子的思路立马就清晰了，因为我们要解决的问题更具体了。

而用户故事的应用在这里同理，虽然产品经理在一些需求描述中会提供非常具体、清晰的描述，但不可能覆盖所有需求。而产品负责人在整理 Scrum 需求列表时，就要确保每条需求都有清晰的用户故事并做出记录。比如使用表格工具管理需求列表，那就可以增加一个 “用户故事” 的表头，将每条需求对应的用户故事填写进该列。

用户故事是每条需求的存在的价值，也是后续分配任务时每一个团队成员所要完成的具体工作——不是把需求上的功能做完，而是实现用户故事中描述的内容。

完成上述内容以后，就可以进入到下一步环节中。

Step2.进行产品的需求评估会议

第二个环节叫需求评估会议，在产品负责人整理完产品需求列表以后，就需要邀请团队成员一起来探讨本次 Scrum 的所有需求了，和产品经理的需求评审会议有点类似，但不完全相同。

这个会议的主旨，一方面是产品负责人和所有团队成员展示和说明需求列表中的所有内容，另一方面，需要团队成员针对需求的可行性、优先级、工作量、用户故事发表建议，并挑选出下阶段要解决的需求有哪些。

在开发项目实施中，并不一定需求本身的权重最高优先级就最高，有时候一些看起来不重要的模块不做完，后面的其它需求就无法实现。所以哪些工作应该优先开展，就需要团队成员共同参与进来讨论。

而需要筛选出来的需求数量也不能太多，必须是马上能够开展的需求，而不是一下选了一箩筐出来进行积压，这样会扰乱团队成员执行的关注和效率。

同时，每一条要开展的需求，就可以统一称呼它为一个 Sprint，Sprint 直译叫冲刺，也是橄榄球的一个术语，含义是要准备冲刺去完成的工作。但这个工作的完成不是一次线性的实践而已，而是在后续的流程中加入检验，从而让工作进行回滚、修改、优化的多次调整，再实现最终的目标。

所以，在 Scrum 的环境中，每个 Sprint 也会被称为是一个迭代，不管是冲刺还是迭代指的都是 Sprint，尽量在学习和沟通中使用英文原单词，才不容易混淆。

Step3.迭代的计划会议

确定出迭代的内容后，再进一步就是迭代计划会 Sprint Plan Meeting。这个会议可以紧接着第一需求评估会议。目的是针对选出的 Sprint 做更进一步的评估，包括工时、目标、验收标准等等。还需要将每一条 Sprint 拆解成更细致的任务并记录到对应的任务列表 Sprint Backlog。

比如物流进度更新这个 Sprint，就包含前端的样式实现、物流订单的创建、仓库系统接口匹配、物流公司接口匹配、完结归档等多个功能模块。每个功能模块的颗粒度都应该在 1 天内完成，如果有明显要超出 1 个工作日都完成不了的，就需要做进一步的分解。比如物流公司接口匹配之前没有经验，还需要拆解成：选择方案、查看第三方文档、实现接口联调等。

这些被分解出来的任务，团队成员就要协商并认领相关的任务，展开正式的工作。这个过程可以以看板的工具进行记录，包含待办、处理中、已完成三种基本的状态。

其中，这些任务要不要准备用户故事这点就不是硬性的，因为很多工作的性质并不一定是实现功能，要认领任务的团队成员自己评估。而在任务分解出来以后，也就可以创建任务的燃尽图 Burn Down Chart，用于在后续反应 Sprint 的进度。

Step4.迭代的实施和执行

既然手上已经认领了项目，那么接下来就要正式进入项目实践环节了。每个团队成员同一个时间段手上应该只有一个任务在执行，在完成后再切换到下一个任务，而不是在每次执行前思考自己应该做哪个任务，也不会一个任务做一半轻易就切换到其它任务上去。

同时，实施环境里还要开展每日的站会 Daliy Scrum Meeting，每天早上（最好是早上）到公司后，用 15 分钟的时间相互分享当前工作的状态，包含昨天完成了什么，今天准备做什么，有什么问题需要协助，如果手动没有具体的任务，可以简单讨论下一个任务做什么。

站会的作用不是变成官僚式的日报应付领导，而是有效的反应自己的工作进展以及发出需要求助的信号。这样其它成员才能知道你的工作产出（是否对自己的工作有影响），并了解你需要哪些帮助可以提供给你，促进团队成员的沟通和协作，而不是仅仅使用线上工具让每个成员都成为孤岛，不符合敏捷中个体和互动高于流程和工具的原则。

每一次 Sprint 的执行，就是完成其中全部的任务，而燃尽图在这个阶段的作用就是帮助我们监控进度，每天站会产品负责人都可以简单展示和汇报下燃尽图的状况，让团队成员对进度有大致的了解。

通过这种方式，完成整个 Sprint 中的全部任务为止。

Step5.迭代成果的展示和评审

当一个 Sprint 完成以后，就要进入迭代评审会 Sprint Review Meeting 中，目的是将完成的 Sprint 更具用户故事展示给产品负责人、产品经理、相关成员评审。

这是个非常重要的环节，也是 Scrum 和瀑布流最大的区别，在过去软件开发的评审通常是最后阶段才进行，但 Scrum 中将评审提早到完成每一个需求模块完成后，开发团队就需要交付并进行演示用于评审。这么做的目的就是为了提早能发现问题，而不是把每个模块积累下来的问题合并到最后再解决。在编程项目中，如果问题积压过多，就会导致修改难度指数级上涨，所以要尽量避免这种不可控的风险。

同时，提早评审还有个非常大的优点，就是可以发现需求本身的缺陷，很多产品需求在构思的时候是一回事，真的落地演示时感受到的是另一回事，所以就产生需要修改和优化它的建议，让这个需求可以更完善。

在这个会议中，Scrum 团队就可以根据其他成员的反馈做讨论，对需要修改的内容创建出新的任务置入回对应的 Sprint 任务列表中，回滚到迭代的实施和执行中，然后迎接下一轮的评审。

只有当评审彻底通过以后，该 Sprint 才能算完成，然后归档进入后续 Sprint 的实施。

Step6.迭代的回顾

除了评审外，还有个关键的会议叫迭代回顾会议 Sprint Retrospective Meeting，它和评审不同的是主要由 Scrum 团队内部成员参加。目的是反思 Sprint 过程中存在的问题，类似项目复盘，花半个小时到一个小时的时间讨论有哪些地方做的好可以继续，哪些地方做的不好需要改进。

Sprint 回顾会议时间点比较难确定，有的团队会每周固定时间进行回顾，有的团队则是每 1-2 个 Sprint 完成以后再回顾。

同时，Sprint 回顾会议可以和需求评估、迭代计划会议做合并，每次完成回顾后，确定后续要完成的 Sprint，并拆解任务进行分配。

不管用什么形式还是频率，回顾流程是必不可少的。

形成复盘的习惯，才能获得更好的表现。

以上就是 Scrum 的基本流程了，经过这么长的解释你们肯定会想这也太麻烦了，光靠记住这流程就很困难了，遑论落地执行。所以，前面提到的角色——敏捷教练 Scrum Master 就是用来解决这个问题的，敏捷教练本身存在的目的，就是要协助用户执行敏捷的流程，提醒团队成员每个阶段应该做什么，在流程的执行上有什么问题并给出改进建议，确保敏捷流程能正确有效的应用起来。

但既然作为教练，这个角色的就不能是整个 Scrum 团队成员中的一员，因为他作为团队成员本身的职责是和教练冲突的，不仅时间精力不够，还容易在裁定上偏向自己不够客观。你不能既当教练又下场当运动员，所以敏捷教练通常是由外包人员，或熟悉敏捷的非 Scrum 成员担任，缺乏敏捷教练的项目是很难有效运作起来的。

最后，总结一下 Scrum 的特点。不管它有什么样的条例还是原则工具，说到底它的本质就是将整个项目切割成多个模块，且做一部分，就检查一部分，一边做一边发现问题改进问题，这样能尽可能提升项目交付的效率和质量。

而瀑布流虽然看起来在流程方法上简单，但是把检查工作留到最后在软件行业是不可行的，在没看见开发团队交付可演示的版本之前，你永远不知道他们会开发出什么东西，生产什么样的问题或 BUG。也不会知道上线前的修复和测试要浪费多少额外的精力和时间。

想象一下在平坦的沙漠中驾驶，如果你指定了一个方向前进，不回头看你永远不知道自己有没有走弯路……

敏捷的方法是反直觉的，因为它是在大量项目挫折中摸索出来的一种解决方式，是完全根据真实的软件开发场景定制的。而很多企业的管理者在使用传统的项目管理经验照搬到软件行业，就会发现完全行不通，这也造成了传统企业开发软件的效率极其低下，这在 B 端领域尤其严重。

很多时候并不是这些企业的开发水平差，而是沿用过时的项目管理模式，就只能以牺牲开发效率为代价。

如果没办法理解这些项目的问题是怎么出现的，瀑布式是怎么变得不适用的，就可以看拓展阅读下面的两本书：《凤凰项目》、《敏捷革命》

结尾

针对敏捷的分享先完成了上半部分，老实说重新理解敏捷的内容花了很长的时间，现在的流程和我快 10 年前掌握的有了很大的变化。同时因为敏捷包含了大量的术语名词，还涉及到中英文翻译和隐喻上的矛盾，所以解释起来特别的费劲。

而应用敏捷的更多优点，和敏捷如何与 DevOps 进行结合实践，我会在后续的分享中进行总结。

又是我认知突飞猛进的一天，不知道你们有没新的收获，没有也可以，随便你 ……

我们下篇再贱！

欢迎关注作者的微信公众号：「超人的电话亭」