什么是敏捷开发

敏捷 开发是一个术语，用于描述迭代软件开发。 迭代软件开发通过在短增量完成工作（通常称为 冲刺， Sprint）来缩短 DevOps 生命周期。 冲刺通常长达一到四周。 敏捷开发通常与传统或瀑布式开发形成鲜明对比，后者会提前规划大型项目，并根据计划完成它们。

每次冲刺交付生产质量代码都需要敏捷开发团队来加快速度。 所有的编码、测试和质量验证都必须在每一次冲刺 (sprint) 中完成。 除非团队已正确设置，否则结果可能低于预期。 虽然这些失望提供了很好的学习机会，但开始之前，学习一些关键教训会很有帮助。

区别于传统的瀑布开发模型，敏捷开发是一种几乎万能地适合现代化软件开发（也包括其他工业项目开发）的一种工作流程/方法论。

什么是瀑布开发模型（传统/经典项目管理） https://coding.net/help/docs/collaboration/pattern-choice.html

业界普遍认为瀑布模型是由温斯顿·罗伊斯（Winston Royce）于 1970 年提出的。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，以便于协作。瀑布模型将软件生命周期分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

另外，瀑布模型非常强调文档，前一个阶段的输出就是下一个阶段的输入，文档是各阶段衔接的唯一信息。从瀑布模型角度出发，在设计和记录不充分的情况下，如果团队成员在项目完成之前离开，知识就会丢失，项目可能很难从损失中恢复过来。如果存在可以正常使用的设计文档，新团队成员甚至是全新团队都应该能够通过阅读文档来接手项目。

瀑布模型指的是在软件开发过程中，由项目管理人员（项目经理）将开发流程分解为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，在每个活动周期，项目人员依具体需求输出对应的 文档/代码 文件等内容。瀑布模型非常强调文档的全面具体，因为上一个活动流程的输出 文档/产品 会作为下一个活动流程的输入。文档是各阶段衔接的唯一信息。

其实 Royce 最早提出这个模型时，并不是为了力挺瀑布。恰恰相反，他指出了瀑布模型可能会存在较大风险，因为在面对经常变化需求的项目时，瀑布模型毫无价值。但也许意外往往也暗含着某种必然性，瀑布模型提供了一种结构化、易于理解的阶段线性流程；它还在开发过程中提供了易于识别的里程碑。由于这个原因，瀑布模型被用作许多软件工程课本和课程中开发模型的开始示例。截止目前它依然是软件开发企业使用的重要开发模型之一，瀑布模型可适用于要求和范围固定的产品，产品本身牢固稳定且技术易于理解的项目。

Royce 真正提出的是改良版瀑布模型，他将原型设计放到了和瀑布模型并重的地位，而这个原型设计就类似于敏捷当中的一次迭代，通过一次迭代来验证项目的可执行性，从而降低风险。接下来我们来看看迭代思想是如何在 Scrum 当中被深刻使用的。

使用瀑布模型开发存在一些缺点，尤其是面对经常变更需求的项目时更是如此。改良版的瀑布模型更加适用于实际的项目开发中，它的特点是将原型设计放到了和瀑布模型并重的地位，而这个原型设计就类似于敏捷开发当中的一次迭代。

什么是 Scrum 敏捷开发

Scrum 是一个解决复杂多变问题的框架。基于经验主义和精益思维，采纳了一种迭代和增量的方法来优化对未来的预测性并控制风险，帮助团队和组织创造价值。

1986 年竹内弘高和野中郁次郎阐述了一种新的整体性的方法，他们将这种新的整体方法与英式橄榄球相类比：由一个跨职能团队在不同的阶段完成整个过程，团队“作为一个整体前进，把球传来传去”。该方法能够提高商业新产品开发的速度和灵活性。

这一类比在经历了千禧年之交的引用与演进之后，终于在 1995 年奥斯汀举办的 OOPSLA ‘95 （计算机协会 ACM 的一个年度性会议）上，由杰夫·萨瑟兰和肯·施瓦伯联合发表论文，首次提出了 Scrum 概念。二人在接下的几年里合作，将理念结合经验与业界最佳实践，形成了我们现在所知的 Scrum。2020 年二人发布了最新版 Scrum 敏捷指南（ https://mp.weixin.qq.com/s/At5NXNnTfZH91beK73lN3A ）。

Sprint (冲刺，也可理解为迭代)是 Scrum 的核心，在这里创意转化为价值。它们是固定时长的事件，为期 1～4 周。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。实现产品目标所需的所有工作都发生在 Sprint 内，包括 Sprint 计划会议、每日站会、Sprint 评审会议和 Sprint 回顾会议。

Scrum 的生命力在于面对多变的市场时，它提供的“小步快跑”思路。产研团队通过“把手弄脏”来得到产品的快速反馈，从而改进产品。为了能够保持紧凑的迭代节奏，Scrum 框架对项目管理过程中信息和流程的“透明度”要求很高：透明使检视成为可能，经常性的“检视”可以快速发现项目中存在的问题；检视使适应成为可能，针对发现的问题可以快速调整。Scrum 实践可以让组织拥有应对变化的能力。

Scrum 敏捷项目管理模式提供了以迭代与事项（史诗、用户故事、需求、缺陷、任务、子工作项）为核心的任务协同工具。面临一个大型任务时，可以将其作为「史诗」进行编写，再具体至工作细节的需求、任务、缺陷管理等。敏捷协作的关键在于先快速发布一个有效但不完美的最简版本；每一次迭代都包含规划、设计、编码、测试、评估五个步骤。在这样不断改进产品，添加新功能的正向工作流内，通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。

Scrum 敏捷开发关键词

1. Sprint (冲刺、迭代)：将一个大型项目拆解为若干 Sprint , 一个 Sprint 持续 2 周左右

2. 史诗：将项目开发中的一个大型任务称为史诗（实际开发中可选）

3. 故事点：参考数值如下，由具体团队规定，可将一个中等复杂度/工作量规模的任务故事点定为 3 或 5，基于此任务标准，将较为简单/低工作量的任务故事点定为 1，2（1/2 极简），将更高复杂度/工作量的任务故事点定为 8，13，20，40 等（一般故事点大于 5 的任务都需要进行拆分，拆解为故事点小于等于 5 的任务）。

1. 需求：同软件开发需求

2. 任务：将大型的史诗任务或一个 Sprint 拆解为一个个子任务

3. 缺陷：同软件开发中的 bug

4. 子工作项：将一个需求拆解为若干子工作项

传统项目管理和敏捷开发的区别

首先来看看在理念方面，两者有何不同。项目管理的铁三角是围绕着范围、成本和时间展开的。传统项目管理的特点是强计划驱动，需求范围固定下来后才可分配人员和时间，并在项目推进过程中积极跟踪和控制风险。敏捷项目是价值驱动的，在敏捷项目管理中，先固定了成本与时间，需求在交付期间频繁细化，在固定的时间盒中优先交付高价值的需求。

• 传统项目管理模式和敏捷项目管理模式并不是全然互斥的关系，两者是有着各自的特点和适用的场景，并且两种项目都有数字化的诉求。

如何选择协作模式（传统项目管理 or 敏捷开发）

需求稳定性

需求稳定 0 分————需求不稳定 10 分

业务与 IT 互动性

业务与 IT 互动难度高 0 分————业务与 IT 互动难度低 10 分

项目影响

关键系统关联度高 0 分————关键系统关联度低 10 分

系统模块化程度

系统模块化程度低 0 分————系统模块化程度高 10 分

环境开放度

环境开放度低 0 分————环境开放度高 10 分

检测结果

得分 0～20，我们更加推荐使用经典模式；

得分 30～50，我们更加推荐使用敏捷模式。

以上来自 CODING 官方文档的选择方法建议，但是这里笔者认为，评价一个项目能否使用敏捷开发并不需要参考类似需求稳定性、环境开放度等因素，笔者认为基于 Scrum 敏捷开放进行的项目管理方式适合于 90% 以上的软件项目开发。因为相比传统的项目管理方式（或者未使用任何项目管理方式），Scrum 有很多不可替代的优点：

• 及时反馈的各种会议，比如每次一个 Sprint 结束后召开的 Sprint 回顾会议，团队每个成员都可以提出自己在上个 Sprint 参与过程中的感悟，提炼总结出各种优缺点反馈于团队
• 保证代码质量。Code Review (代码评审) 不是 Scrum 敏捷开发的特色，任何软件开发团队都可以定时作 Code Review, 但在 Scrum 敏捷开放中，尤其是项目伊始，团队的每个研发人员都应该就自己开发的相关功能（一般是比较复杂，有代表性的功能）作 Code Review，一般来说，在项目开发前期的每个 Sprint 中，团队的每名开发人员都应该发起不少于一次的 Code Review。这个次数可在项目进入中后期后相应减少。定时定量的 Code Review，可极大提高团队总体的编码质量，提升团队成员的研发水平和经验。
• 让每个团队成员都有参与感，不至边缘化任何成员。这也是在软件项目开发中常见的一个问题，尤其是在规模稍大的团队中更可能发生，团队的少部分成员因为参与度、经验水平的不足等常常在团队推进项目中被边际化，可能其他成员的任务繁重，忙不过来，但是少部分成员无所事事。而 Scrum 敏捷开发在一定程度上可以较好的缓解此类问题，比如每个 Sprint 启动会议上，团队所有成员都会到场进行讨论，包括各个需求任务的拆分，以及对应人物的故事点，每个任务故事点的赋予是需要团队所有成员表决的。这些都可以让所有成员动起来，参与起来。

为什么我们需要敏捷开发

在企业研发团队的过程中，我们发现不少团队碰到了类似的问题：

• 团队成员声称完成了自己的大部分任务，但团队实际交付的需求却寥寥无几？
• 由于某些问题导致工序一直处于等待状态，怎么识别和处理这些延迟？
• 成员之间不知道互相都在干什么？各自鸵鸟式地进行着工作。
• 当你计划分派任务给某个成员，对方告知他之前收到来自高层的直接任务指派，所以没空。
• 你经常在思考究竟哪些工作是最重要的？如何避免被无穷无尽的项目与工作淹没？

敏捷开发 + 看板视图的方式可以帮助我们很好的解决此类问题。

看板（Kanban，来源于日语）最初是丰田汽车公司的大野耐一于20世纪50年代发明的，当时是从超级市场的运行机制中得到启示，将看板作为一种生产、运送指令的传递工具而被创造出来的。

一个软件的开发流程可以看作是一段自来水管道，特性需求从一个端进入，经过改进的软件从另一端涌出。在管道内部，存在着各种各样的工事，有的是非正式的临时工序，有的是正式的阶段性流程，而整个管道的吞吐量就代表着团队的工作效率，如果任务不流动就造成了阻塞，从而产生了瓶颈。

​完整的看板包含了5个泳道：

• Backlog 存放待开发的用户故事卡片

• ToDo 存放当前冲刺阶段的待开发任务卡片

• Doing 存放当天开发中的任务卡片

• Test 存放已开发完毕，需要测试的任务卡片

• Done 存放已测试且已验收通过的任务卡片

任务卡片在各个管道中的流动就是燃尽图的动态表现，通过看板，我们能够很直观的发现项目瓶颈，除了看可视化项目进度，看板还有哪些优势呢？

看板优势

1. 通过看板，我们能将冲刺任务限定在一个已知的能力阙值内，根据每天的任务交付速度来平衡团队的工作需求。

2. 看板提供了视觉化的直观管理感受，每个人的任务一目了然，能够快速的暴露出影响团队效能的瓶颈，团队应该专注于解决问题以维持稳定的流量。

3. 看板能很好的展示下下游环节的当前状态，每个人聚焦当前任务，完成一个任务再开启下一个任务，拉动式生产，不堆积任务导致影响后面的环节。

4. 看板能够建立稳定的任务节奏，始终如一的可靠交付，这能够帮助团队和利益方合作伙伴建立稳定的信任关系。

电子看板还是物理看板？

• 建议以电子看板与物理看板相结合的方式来进行任务管理
• 以电子看板为主，主要是因为电子看板的状态实时性更高，查看起来更加方便快捷
• 物理看板主要用于日常站会及需求讨论会议中

如何进行 Scrum 敏捷开发

• 明确敏捷开发流程

• 明确项目总体需求，包括我们需要开发一个怎样的软件，受众群体/客户是谁？在前期的项目可行性分析及需求收集阶段，需要输出初步的需求文档及产品待办事项（Product Backlog）清单

• 项目启动会议，在这个会议上，明确 项目名称，总体需求，确定项目开发需要使用的前后端技术栈及项目管理工具、平台等

• Sprint 计划会议（Sprint Planning Meeting），又称为迭代/ Sprint 启动会议，这个会议，一般在上个 Sprint 结束后，下个 Sprint 即将开始前发起，由全体项目人员参加，在本会议上明确本次 Sprint 的迭代时间周期（一般为 2 周左右） ，计划工作内容等。在本会议上或会议后，立即形成本 Sprint 待办事项列表，也即子任务列表，这些子任务列表一开始会出现在看板的 Todo 栏中，由相关开发人员认领任务进行开发（或由管理人员安排）

  • Sprint 计划会议上输出的任务事项，一般还会由与会人员投票讨论形成故事点

  • 故事点估值参考方式：

    • 用的团队估算方法是扑克估算，具体操作流程如下:

      1、每个团队成员分发一套写着0、0.5、1、2、3、5、8、13、20、40等的卡片。

      2、产品负责人负责讲解需求待办列表挑选出来的需求，团队成员提出自己的疑问，产品负责人一一解答。

      3、团队成员进行估算，选出自己估算结果对应的卡片盖在桌上，不要告知其他团队成员。

      4、所有人都确认自己的估算结果后，大家一起翻开卡片，展示自己的估算结果。

      5、团队评估估算结果，让给出估算点数最大和最小的成员分别陈述自己给出当前结果的理由，团队讨论，消除分歧，得到一致的结果。（这一步尤为重要，讨论过程是团队分享知识和经验绝佳机会。）

• 每日站会（Daily Scrum Meeting），在每个 Sprint 开发中，一般在每个工作日固定时间（如早晨）开启时长约 10 分钟的每日站会，在这个站会上，相关开发和测试、UI 设计人员、产品经理（非必须）、项目经理（非必须）

  • 通常，在这个会议上，与会人员需要回答：

    • 1. 我昨天做了什么？
    • 2. 我今天打算做什么？
    • 3. 是否存在障碍？

  • 当然，每日站会未必一定要参会人员回答这三个问题，为什么？

  • 过度执着于招式反而会陷入反模式。 比如在每日站立会议上的三个提问也会带来的不少问题：当 Scrum Master 询问每个成员时，成员们依次作答自己的一亩三分田耕得如何，使得站会成为了每个成员的工作进展拷问，大家关注的焦点就不再是实现 Sprint 目标的进展。

    中国团队在实践 Scrum 时，“三个提问”往往是入门时的第一招式。但总是带着热情开始，数周后流于形式，尬场更是经常。理解 Scrum 的精神内核比掌握具体形式和工具更为重要，仅模仿形式即认为团队已经开始了 Scrum 是一种错觉。“中国特色敏捷”之下产生了更多披着敏捷皮的瀑布，项目通常“前松后紧”，只在最后的链条测试发布阶段需要紧张加班，研发团队松紧不定。

  • 每日站会的目的在于及时沟通项目进度，只要能达到以上目的，未必要每天回答“三个问题”，团队成员应该站在更高的立场上，去看待项目开发

• Code Review（代码评审/代码审查，非必须）会议，由软件开发人员针对其具体开发的功能模块，在编码完成后召集相关人员（如项目组前端、后端等）进行代码实现细节的评审，针对会议上团队提出的改进优化细节，现场修改或会后修改相关代码

• 测试点评审会议（非必须），由测试人员根据 Sprint 计划会议上拆出的子任务表梳理得出的测试点，之后测试人员召集本测试点涉及相关人员进行评析的测试点评审会议

• Sprint 回顾会议（Sprint Review）,通常在一个 Sprint 基本结束后，由项目经理召集所有项目组成员进行冲刺回顾，回顾上个 Sprint 中，团队成员有哪些做的好的地方，有哪些做的不好的地方

  • 通常，由团队成员将相关意见匿名写在小纸片上，之后贴出

  • 项目经理和团队成员讨论这些意见

  • 在以后的 Sprint 中，如何保持团队做的不错的地方；如何改正团队的不足之处

• 项目阶段性交付，将上个迭代开发完毕的内容发布至预发布等环境中，由项目经理/产品经理/领导/客户等审查

如何进行项目管理

• 推荐使用 CODING（ https://coding.net/ ） 软件进行项目进度管理（如何使用 CODING 进行敏捷开发 - CODING 帮助中心）
• 也可以使用类似 CODING 的项目管理工具/平台，如 TAPD，Microsoft Azure 等
• 以下截图为 CODING 中的常用功能，如 Sprint 建立，看板，任务项等

总结

Scrum 敏捷开发是一种非常适合现代软件开发管理的工作模式。一般需要一个既懂技术，又明白管理的资深项目经理（此类人才往往是千金易得，一将难求的）担任领头人，借助 CODING 等辅助工具，高效地进行软件开发。

参考：

https://coffee.pmcaff.com/article/3046349388378240/pmcaff?utm_source=forum&newwindow=1
https://zhuanlan.zhihu.com/p/514549925
https://coding.net/help/docs/collaboration/manage/view.html#custom
https://coding.net/help/docs/collaboration/best-practice/scrum.html
https://coding.net/help/docs/collaboration/pattern/scrum/intro.html
https://mp.weixin.qq.com/s/At5NXNnTfZH91beK73lN3A
https://www.bbsmax.com/A/A2dmm6p7de/