ppt给的要求三选一，我看来看去也就只有第一条能做而且是最简单的了：介绍 CI/CD Pipeline 原理、使用工具与案例。

一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。大致由软件开发工程师、软件测试工程师，软件运维工程师这三种程序员来负责这个过程。

软件交付模型依次有瀑布模型、敏捷开发模型和DevOps模型。

瀑布模型是最早期的软件交付模型，就是等一个阶段所有工作完成之后，再进入下一个阶段。它的软件开发流程是这样的：软件开发人员花费数周和数月编写代码，然后将代码交给QA（质量保障）团队进行测试，然后将最终的发布版交给运维团队去部署。所有的这三个阶段，即开发，测试，部署。

但是，项目不可能是单向运作的。客户也是有需求的。产品也是会有问题的，需要改进的。随着时间推移，用户对系统的需求不断增加，与此同时，给的时间周期却越来越少。在这个情况下，笨重迟缓的瀑布式开发已经不合时宜了。于是就发展出新的软件交付模型——“敏捷开发（Agile Development）”。

敏捷开发能应对快速变化需求。每次开发一个部分就进行测试，然后再进行下一轮开发。通过重复交替进行开发和测试，可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。

而且，DevOps小步快跑的形式带来的版本变化是比较小的，风险会更小。即使出现问题，修复起来也会相对容易一些。

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。运维的部署部分还是没有参与其中。

DevOps一次词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。

快速的部署其实可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地相应。而且，DevOps小步快跑的形式带来的变化是比较小的，出现问题的偏差每次都不会太大，修复起来也会相对容易一些。

在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。

下图可见DevOps贯穿了软件全生命周期，而不仅限于开发阶段。

DevOps与虚拟化、容器、微服务

微服务就是将一个提供多种服务整体产品进行拆分，拆成各自提供不同服务的多个个体。微服务架构下，不同的工程师可以对各自负责的模块进行处理，例如开发、测试、部署、迭代。

虚拟化就是一种敏捷的云计算服务。它从硬件上，将一个系统“划分”为多个系统，系统之间相互隔离，为微服务提供便利。

容器不是划分为不同的操作系统，而是在操作系统上划分为不同的“运行环境”（Container），占用资源更少，部署速度更快。

虚拟化和容器，其实为DevOps提供了很好的前提条件。开发环境和部署环境都可以更好地隔离了，减小了相互之间的影响。

二、什么是 CI/CD 流水线？

在传统软件开发过程中，代码集成一般是在项目结束阶段一次性将所有开发人员的代码整合起来，这个整合过程花费大量时间和人力。而在持续集成（CI）方式下，代码集成每天都在发生，每次只需要花费几分钟的时间。

不同的开发人员各自编写自己负责部分的代码，然后上传到源代码库中合并， CI 服务器负责构建软件并测试是否能正常运行，将测试结果反馈给开发人员。

集成的代码即使通过了测试、能够成功的工作，也仍然不能直接投产，因为它还没有在类似生产环境中测试和验证以表明能够工作。

持续交付是在持续集成的基础上，将集成后的代码部署到更贴近真实运行的环境（类生产环境，production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试。

我们可以从每个环境的测试中获得新的反馈，如果出现了错误，我们可以更容易的理解问题到底在哪里，并且在代码进入生产环境之前修复它们。如果代码没有问题，可以继续手动部署到生产环境中。

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。这里强调的是：

1. 有部署的能力，但不一定部署

持续部署则是在持续交付的基础上，把部署到生产环境的这个过程自动化。

1. 持续部署是持续交付的最高阶段

工具、CI/CD、DevOps的关系：通过技术工具链完成持续集成CI、持续交付CD、用户反馈和系统优化的整合，实现跨团队的无缝协作(DevOps).

根据实际需要，选择合适的工具组合起来构建CI/CD流水线

到目前为止，我们已经了解了 CI/CD 流水线及其工作原理，还有相关的一些工具。接下来我们将介绍如何使用 Jenkins 构建CI/CD流水线，并自动化整个过程。

我们的目标是要将软件开发生命周期的整个过程都自动化，即从开发人员向代码库中提交代码开始，到将此代码投入生产环境中使用为止，全部自动化完成。

• 码云：基于Git的代码托管和研发协作平台，是一个供开发人员提交代码的仓库。
• Jenkins ：持续集成、交付、部署（软件/代码的编译、打包、部署）的基于web界面的平台，可安装各种插件处理任何类型的构建或持续集成。
• docker：保证开发环境和生产环境一致，方便部署。

开始构建CI/CD流水线

上传到码云上此项目的git地址上

普通的设置用户名、密码之类的

然后提示安装插件，选择默认的安装，等待安装完成。

在jenkins页面新建自由风格的软件项目。

在源码管理中，添加git仓库和用户名、密码配置，并且选择代码分支（这里是master）

在构建步骤中，添加2个步骤

• 1.顶级maven 选择maven版本（上面的全局配置中配的maven），添加maven打包命令

4、执行构建并启动服务

上面配置完成后，到Jenkins的Web主页，选择配置好的项目，菜单中点击立即构建，看到左边菜单里有执行的进度条，点进去后可以看到执行日志，如果启动服务成功，则可以到浏览器访问localhost:8080

如果下次构建该项目的时候，docker镜像和服务已存在，需要先删除镜像和服务

与大数据和PRISM（NSA的监控项目之一），DevOps（开发运维）如今是科技人士挂在嘴边的热词，但遗憾的是，类似圣经，每个人都引用DevOps的只言片语，但真正理解并能执行的人极少。根据CA的一项，45%的受访者并不了解DevOps的含义，其余则有17%认为DevOps只不过是炒作。

DevOps如今几乎成了创新的同义词，但其原本的含义却在业界的流传中被人们弃之脑后。在开发者圈子中，DevOps专业人士经常是被嘲弄的对象，例如下面这个专门恶搞的推ter帐号：.

饶是如此，DevOps也成了类似数据科学家的性感职位。虽然在一些企业，DevOps还只停留在纸面上，但更多的企业的业务发展确实需要DevOps专业人才，人才市场对DevOps技术人员的需求非常旺盛，根据科技人才招聘网站Dice.com最近的，今年9月份DevOps的招聘职位数量高达500个，而去年同期只有200。

事实表明DevOps口惠而实不至的口水词，根据IT自动化服务商Puppet Labs的最新报告《》，采用DevOps的企业的软件代码生产速度是不采用DevOps企业的30倍！同时将错误率降低了50%。

为了深入探讨DevOps这个话题，以及搞清楚为什么DevOps工程师在企业招聘市场一将难求，VB的记者近日采访了戴尔的云计算开发总监， George本人也经常写博客讨论搭建DevOps团队的好处。IT经理网将采访内容编译整理如下：

问：DevOps这个概念是怎么来的？

答：DevOps起源于亚马逊和Google这样的大型互联网公司，这些公司需要员工紧密协作，同时又不希望出现部门割据。

问：开发人员和运营人员的目标有很大差异吗？

答：是的，他们有着相反的目标，开发者一心都在创新上，让事情看上去更酷；而运维人员最关心的则是网站运行的平稳，不要宕机，但开发者可不会关心这个。

我记得2001年2月份发布的“”是一个里程碑，打那时起开发者开始关心如何走近客户，了解他们的真实需求。开发者开始更多关注如何加快开发周期，写出更容易实现的代码、更好的用户体验，而不是更酷的功能。

相比之下运维人员并未经历类似太多变化，于是DevOps模式应运而生。

问：敏捷开发到底什么意思？你认为这仅仅意味着快速吗？

答：简单来说，敏捷开发意味着更多的迭代：更早更频繁地发布产品更新。先把东西做出来，而不是像过去那样过于忧虑产品是否完美。这就是那个“永远beta版”的概念，30天把原型快速搞出来，然后看看人们到底怎么想。敏捷的字面意思就是快速改变的能力。

如果你能更快发布，你就能跟上市场的节奏随时调整。

问：DevOps与开源运动的关系是怎样的？

答：两者是并行的。DevOps是一个文化运动，借用了开源的很多协作概念，本质上是团队协作的文化。

问：企业如何从DevOps能力中受益？

答：DevOps的目标是流程的自动化——让代码完成过去手工的工作，从而大大节省成本。

DevOps的最终目的是提高你的客户响应能力。如果网站宕机了，你自然就无法服务你的客户了，你发现问题的速度越快，成本就越低。

DevOps团队的特点是能让你为客户提供更多功能，而且不会把网站搞垮。

问：DevOps通常适用于大企业还是斗志昂扬的小企业？

答：DevOps更多会与大企业有关。小企业的协作本来就不是很难。但是类似Google或Netflix这样的企业每天都会推送大量代码，出现bug的几率很高，而和这样的开发工具能帮助系统管理员将很多工作自动化，并应对最艰巨的基础设施挑战。

问：你最常听到的对DevOps的误解或疑点都有哪些？

答：DevOps不仅仅适用于高科技公司，我一年前听过一个网络研讨会，是关于中西部一个金融公司如何开展DevOps的，DevOps绝不是硅谷的专属品。

事实上任何希望变得更加敏捷的人都可以运用DevOps。以我的观点，DevOps是IT部门保持其存在感的一种方法。我们经常看到企业中的IT部 门被排挤，因为预算受制于其他业务部门。有了DevOps，IT可以更早地参与到业务流程中，IT主管们可以冲着开发团队嚷嚷：“嗨，伙计们！我们如何实 现这个需求？我们需要什么样的自动化工具？”，而不是像过去那样，搞出成吨的代码后黄瓜菜都凉了。

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。 它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

以下几方面因素可能促使一个组织引入DevOps：

1. 使用敏捷或其他软件开发过程与方法
2. 业务负责人要求加快产品交付的速率
3. 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
4. 数据中心自动化技术和配置管理工具的普及
5. 有一种观点认为，目前占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

   20世纪50年代~90年代，能够供会议通信场景和信息交流场景的基础条件并未达到让人们信息互通如同今日那般（2021）可以透过屏幕可以看到对方的面部表情。

   市场的信息交流并不频繁，用今天的视野去看，当时的商业环境进展是及其缓慢的，企业从信息传达，到落地可能需要数个月的时间，那个时候对于领导者的前瞻性眼光要求比今日高得多了，并非说今日的商业环境不需要前瞻性眼观了。

   对比20世纪50年代~90年代的商业环境，现今的商业环境出现了翻天覆地的变化，并且通信基础已经使得钱在地球上转一圈只需要8秒，人们可以随时随刻的开启视频会议，从决策的决定到传达到落地层只需要打开通信设备即可传达。

   现今人们接收到的信息也越来越多，思想、思维每天都受这些信息的影响，下一步的行动可能也会受到这些信息的影响。整个商业环境每天都日新月异的。这迫使企业更快的做出决策，更快的推出新产品到市场。

每个管理者，每个企业家都知道，企业一旦做大了，人员多了，很难很快的推出新产品。如同一个篮球运动员的身材发展那般。如果退役不打篮球了，那么身材很容易发福，一旦发福了，那么运动速度就会慢起来。即便这名运动员想要重新回到赛场，但是也要通过重新锻炼腰、腿、手等各个部位，注意是各个部位。那么企业能否也像运动员想重新回到赛场那样，把团队进行简化，小步快跑的方式来去实现这种拉动。在投篮时（新产品），身体可以迅速、华丽、敏捷的投入。

   这个问题相信无数学过敏捷，看过敏捷的书的小伙伴都会有这样的一个疑问在心底，什么是敏捷？怎么样才算是敏捷？这没有一个标准的答案，因为每一种管理方法论都是基于不同公司自身的发展和企业文化进行裁剪过的。

敏捷就是基于目前商业环境中，客户对价值交付的要求日趋紧迫。敏捷技术和方法将有效的管理各种颠覆性技术，特别是新的设计，和之前未做过的工作都是探索性的，随着可确定的工作日益实现自动化，项目团队也越来越多从事高度不确定的工作。

此外，敏捷第一原则将客户满意视为最高要求。为保持竞争优势，与时俱进，各组织不能只关注内部，而是要放眼外部世界，关注客户体验。

小型组织和初创公司能够更快的生产出满足客户需求的产品。商业环境的不断变化将继续促使大型公司采用敏捷思维模式，以保持竞争力和现有的市场份额。

小结：为了在短时间探讨可行性，根据评估和反馈快速调整，在这个调整过程中大公司，通过化整为零，大团队化小团队实现小步快跑的方式。

   团队成员成就感、归属感更强。

   更快的让产品投入到市场，产品价值可以尽快的得到市场的验证并修正。

   避免工作转换时的效率降低（20%~40%），团队成员技能要求尽量具备全栈技能，俗称的T型人才。

每个项目都有属于各自的生命周期类型，传统的生命周期是预测型生命周期，又称瀑布流生命周期。每次开发时，都假定了目标是明确的，需求是明确的，需求是不会改变的。

增量型生命周期：在前期定义了一个电商产品，在规划中是划分成直通车模块、购物车模块、活动会场模块。第一次发布时，就发布了直通车模块。本来在下一个版本中，是要发布购物车模块的，但是基于市场反馈，马上就要过节了，有一个活动会场可以更好的吸引用户。于是在下一次版本中，发布的是活动会场模块。整体顺序就变成了直通车模块、活动会场模块、购物车模块。

迭代生命周期：可以帮助团队交付和反馈创建一个节奏，并且团队会为交付和反馈创建增量。

   小结：每一种生命周期都有各自的特点，在很多时候大多数实际情况中，是根据实施环境的不同，来组合生命周期的使用。如在前期的设计中使用瀑布流生周期，在项目开发过程中，使用敏捷型生命周期。而且在大多数企业从传统项目管理过渡到敏捷时，普遍都会经过增量型生命周期。

1、个体互动高于流程工具：项目执行者始终是人，人是项目的核心，有优秀的成员，但是没有好的流程来去控制的话，就会让优秀的成员在做事时就像无头苍蝇最后感到心灰意冷。现在竞争越来越激烈，企业是依然需要规则、流程，并不是说不需要流程，在走流程的这个过程中没有良好的沟通就无法更好的促进项目成功，甚至会失败。

2、可用软件高于完备文档：无论对于谁来说看得见、摸的着的高质量软件（工作成果）才是有价值的，如果看不见、摸不着停留在口头上的东西谁会信。在产出工作成果的过程中，如果没有文档的话，将会是一场灾难，这个工作成果只有这个完成的人知道，敏捷一样也是需要文档，强调的是轻量级、高价值的文档，比如把日报改为周报。

3、客户合作高于合同谈判：大多数公司与客户谈好软件的价格，客户扔下一笔钱在这之后，等全部工作完成了才与客户进行沟通与交付，结果做出来的东西是不符合客户预期的。经常的与客户保持沟通，每个里程碑做好后都与客户进行交流确认，及时发现问题、改进问题，而不是等客户发现了才来改。如果是客户发现问题，客户会出现不信任的心理，甚至会出现随意修改的过程。

4、响应变化高于遵循计划：敏捷并不是不需要计划了，而是有更多的计划和规划，尽量的把不确定性控制在可控的一个时间范围内。毕竟减少不确定性的唯一办法是通过做一些事情或模拟来获得反馈，不断的根据反馈来调整计划，即规划-执行-调整，有点类似戴明环的PDCA。

1、目的：尽早持续交付有价值的软件来满足客户需求，进而使客户满意。

2、态度：敏捷变更是提倡价值变更，所以是欢迎需求变更。

3、关注：尽早、经常的交付可用的软件。

4、合作：业务与开发合力推到信息孤岛的那堵墙。

5、核心：人是项目的核心，激励项目人员，基于所需要的环境与支持。

6、沟通：尽量面对面沟通。

7、标准：可用的软件是衡量的首要标准。

8、倡导：敏捷不提倡加班，提倡始终保持步调稳定前进，急功近利会使得团队容易处于崩溃的状态。

9、追求：对卓越技术和设计的持续关注与完善，以提高项目敏捷性。

10、根本：尽量减少不必要的工作，如果可以使用最简单的方式实现需求是最好的。重构是在实现新需求的过程中，清楚冗余的代码，随时重构是为了防止系统混乱的重要途径。

11、团队：最佳的架构、需求和设计出自于自组织的团队，整个团队共同承担责任，并且任务是以团队为单位来分配的。

12、调整：团队定期的反思、回顾、总结经验。项目结束时，才进行总结的话，在于总结经验不能立刻对组织或项目带来实际上的帮助。相反随时进行总结，团队成员们会认识到问题，并推动自己的行为来解决问题。

项目章程：就能了解项目之所以重要的原因、团队的前进方向以及项目的目标。帮助团队学习如何一起工作，怎样围绕项目协作。团队至少还需要项目愿景和目标。为什么要做这个项目？谁会从中受益？如何受益？达到哪些条件才意味着项目完成？我们将怎样合作？

团队章程：团队价值观，可持续的开发速度和核心工作时间；工作协议，时间盒、完整性和工作过程限制；基本规则，会议发言规定；团队规范，对待会议时间。

项目就是干已确定的工作和不确定的工作。传统的软件开发模型，瀑布模型是将所有工作都认为是不变的，识别变化延迟到最后的测试或用户使用阶段才发现，反馈周期很长，极大的增加了返工或变更成本。从而可以看到传统软件开发的官僚化，速度慢，庞大的问题。

敏捷通过短周期迭代，尽可能早的交付可用的迭代来快速响应和适应变更。

极限编程是肯特贝克1996年提出的。

   简单：从最简单的入手，在通过不断重构来达到最好的效果。

   沟通：鼓励经常性的口头交流与反馈。

   反馈：系统的反馈（测试单元）、客户的反馈、小组的反馈。同时在编程中的乐观主义是危险的，而及时反馈则是解决它的问题。

   勇气：只为今天的需求而编码，不要考虑明天。这是为了避免陷入设计泥潭而在其他问题上花费太多不必须要的精力，进而知道什么时候该丢弃现有的代码。

   尊重：团队成员之间体现在每个人保证提交的如何改变不会导致编译无法通过，或者导致现有测试用例失败。坚持追求高质量，坚持通过重构的手段来为手头上的工作找到最好的解决涉及方案。

   在XP中，轻量级的需求被叫做用户故事，通常用于发布和冲刺计划中。

典型冲刺有2周的时间：

1、在这冲刺期间开发人员会以结对编程的方式编写代码；

2、所有开发好的软件都会进行严格的而频繁的测试；

3、在获得客户认可之后，才会小规模的发布；

   备注：探针是一种技术方法，是为了减少风险，并且探针会在整个发布中使用到。例如在学习新技术、评估、验收标准定义以及通过产品了解用户行为的流程中应用。

   完整的团队：客户、开发人员、测试等都在一个场所下工作。

   规划游戏：需求分析都是通过规划游戏完成的。这个过程分为三个阶段：探测，分解需求；计划，制定和发布计划；调整，根据实际情况调整计划。

   小型发布：非常短的周期内以递增的方式发布新版本。体现了敏捷的特性。统一软件开发过程强调冲刺开发。

   共同所有权：全部代码强调所有人都要负责，某个人的代码出现BUG，另一个人可以修复。并且执行严格的代码控制。

   编码标准：如果没有统一的编码标准，代码共同所有权就无从谈起了。

   可持续的速度：强调以恒定的速率进行工作，不强调加班。

隐喻：在沟通中常用比喻的方式，加速理解。

持续集成：及早的爆率并消除隐患，由于重构、集体代码所有权的引入，从而减少问题的痛苦。

测试驱动开发：越没有空写测试程序，代码的效率和质量就越差，花在找BUG，解决BUG的时间就越长。

重构：是一种对代码进行改进，而不影响功能实现的技术。

简单设计：认为设计部应该在编码之前一次性完成，那样只能建立在需求不会改变的或者可以预见所有的变化的基础上。并且要能够通过所有测试程序，没有包括任何重复的代码，清晰的表达带来所有意图，尽可能少的类和方法。

结对编程：一个人写程序，另一个人坐在一边看，大大的降低了沟通成本，提高了工作之类，代码至少有2个人熟悉，并且代码总是能评审过，还能够消除无谓分歧、更好的沟通。

XP核心价值观：简单；沟通；反馈；勇气；尊重；

XP生命周期：用户故事、2周冲刺、结对编程、严格测试、小规模发布。

XP核心实践：完整的团队；规划游戏；小型发布；共同所有权；编码标准；可持续的速度；隐喻；持续集成；测试驱动开发；重构；

   Scrum来源于美式橄榄球，每个团队成员都具备很强的进攻和防范能力。团队成员具有高度自主权，在比赛中进行紧密的沟通合作，以高度弹性解决各种问题。

   备注：接下来的所有讲解将按照Scrum的方法论进行讲解。

   透明性（Transparency）：软件开发过程中各个环境保持高度的可见性。

   适应（Adaptation）：如果检查发现过程中有一个或多个方面不满足验收标准，并且最终产品是不合格的，那么就要进行调整，调整工作必须加快实施，以减少进一步的偏差。

   职责：从市场获得信息，确定该产品对于企业的回报，并且及时将市场需求反映在产品待开发项中。并且PO对产品待开发项具有决策权的人，重新排列产品待开发项优先级需要得到PO的统一，所有成员都要尊重PO的决定。

   对产品待开发项的内容进行优先级排序；

   确保开发团队所执行工作的价值；

   确保开发团队对产品待开发项内容达到一定程度的理解；

   清除团队成员的障碍，如频繁的开无意义的会议。

   自组织的团队：没有人会告诉开发团队如何把产品待开发项列表变成潜在的可发布的功能，自己决定做什么Scrum Master也不能干预。

   跨职能：团队拥有创造产品增量所需要是全部技能。无论承担什么工作都是开发者，不认可头衔，以及不包括测试、业务、分析等特定领域的团队，每个人统称都是成员。

1、PO从市场或客户方获取相关的产品信息。

2、PO一个人或与团队共同梳理收集回来的需求，并采用用户故事的方式对需求进行梳理。

3、根据使用用户故事梳理出来的需求，排列需求优先级，形成产品待开发列表（Product Backlog），并确定此次要发布计划要完成的工作内容。

4、PO、开发团队、SM等涉及的相关方，共同召开冲刺规划会议。这个会议会持续4~8小时。PO向开发团队介绍产品待开发项列表，确保与开发团队对这些工作取得共同的理解

5、开发团队在冲刺规划会议上挑选出一些用户故事并细化成任务作为本次冲刺的目标，并形成冲刺待办列表（Sprint Backlog）。

6、每一轮冲刺（Sprint）持续时间约2~4周。冲刺（Sprint）开始时，开发团队成员根据意愿领取自己想要做的任务。

7、每天早上会花15分钟召开每日站会（Daily Scrum Meeting），每个团队成员会回答三个问题，昨天完成了什么？今天准备做什么任务？遇到什么障碍？

8、在本轮冲刺完成后，会召开冲刺评审会议（Sprint Review Meeting），会持续2~4小时。主要是向相关方演示本次完成的产品功能，并获得反馈。同时，可以讨论并计划下一个迭代要做的事情。

9、召开冲刺回顾会议（Sprint Retrospective），持续时间2~4小时。总结哪些做的好的地方需要保持，需要改进的地方有哪些，以便在下一个冲刺中进行改进。

一个冲刺就是一个时间盒，时间大约是2~4周。

每个冲刺中包括了冲刺计划会议、每日站会、冲刺评审会议和冲刺回顾会议。

持续4~8小时，确定在这个冲刺中需要交付哪些产品功能，以及如何达成目标。

PO向团队介绍排好优先级的产品待开发项，确保开发团队对事项的理解，创建足够详细的计划来确保其能够完成。

本轮冲刺要完成的待开发项数量的多少由开发团队自行决定去评估和决定，SM或PO都不能干预。决定如何完成工作是开发团队的职责，决定做什么则是PO的职责。

开发团队按照完成的定义分解更小的单元，每个工作单元不超过一天。PO可以继续留下来回答问题以及澄清一些误解。

持续15分钟，可以带来透明性、信任和更好的绩效。

上一个每日立会到现在完成了什么？从现在到下一个每日立会，计划完成什么？遇到了什么障碍？

持续2~4小时，演示此次冲刺完成的产品功能，并获得客户的反馈与PO的验收。

PO和团队还可以根本此次完成的产品功能做对应的调整，并讨论剩余的产品待开发项（此次未完成或下一个阶段做的产品开发项），以及下一步计划完成的工作。

持续时间不超过3小时，总结哪些做的好的地方需要保持，需要改进的地方有哪些，以便在下一个冲刺中进行改进。

包括业务功能和非业务功能（技术、架构和工程实践相关等），提升点及缺陷修复等。

产品待开发项是需要持续改变的，以确保优先级是最合理、最具有竞争力、最有价值的。

Scrum不考虑已经花在产品待开发项内容上的工作时间，只关心剩余工作和日期这两个变量。

是从产品待开发项的用户故事分解而来的一系列任务项。

会伴随有一个计划以实现本轮冲刺的目标，并且产品待开发项的功能点被放到冲刺的固定周期中。

冲刺待开发项会因为两个方面而变化：一是对需求有更好的理解，可能需要增加一些新的任务到冲刺待开发项中。二是缺陷作为新的任务加进来，这个都作为承诺提交任务中未完成的工作。

通过冲刺中不断追踪剩余的工作，开发团队可以管理自己的进度。

在一个冲刺完成之后的所有产品待办事项的综合，以及之前所有冲刺产生的增量价值的总和。这些总量在每个冲刺即将结束的时候必须满足完成的定义，并且能够带来价值。

   Scrum活动或会议有冲刺规划会议、每次站会、冲刺评审会议、冲刺回顾会。

   Scrum工件：产品代办列表、冲刺代办列表、增量。