码农的自我修养之 软件危机和软件过程

软件危机和软件过程

没有银弹

  10年后到1986年，Brooks发表了一篇著名的论文“没有银弹（No Silver Bullet: Essence and Accidents of Software Engineering）”，断言“在10年内无法找到解决软件危机的杀手锏（银弹）。这文章激起许多软件工程专家的辩论﹐而没有银弹（No Silver Bullet）也成为脍炙人口的名词。Brooks认为软件工程专家们所找到的各种方法都是舍本逐末，它们解决不了软件中的根本困难，即软件概念结构(conceptual structure)的复杂性，无法达成软件概念的完整性和一致性，自然无法从根本上解决软件危机带来的困境。

基于组件的软件工程方法

  到了1990年﹐面向对象分析与设计领域的大师Brad Cox，针对Brooks的观点，发表了一篇重要文章“有一个银弹（There Is a Silver Bullet）”，以说明他找到了应对软件危机的杀手锏，即经济上的利益诱导会促使人类社会中的文化改变(culture change)，使得人们会乐于去制造类似硬件芯片(IC)般的软件组件(software component)，将软件组件内的复杂结构包装起来，使得软件组件简单易用，由这些组件整合而成的大型软件，自然也简单易用，从而软件危机得以化解。由此提出了"Software IC"一词，也就是基于组件的软件工程方法的来源。

再论没有银弹

  到1995年初，Brooks的名著《人月神话》第二版出版，书中含有一篇关于杀手锏（银弹）的文章“再论没有银弹（No Silver Bullet Refired）”。文章里Brooks赞扬Brad Cox的文章，但他认为Brad Cox误解了他的本意。Brooks认为从论文“没有银弹”发表，尽管历经了十年，软件开发方法也有所进展，但Brooks仍然认为杀手锏（银弹）仍未出现。大型软件系统的开发工作仍然困难重重，只能渐进地加以改善，不要奢望短期内会出现杀手锏（银弹）能一举解决软件危机所面临的困境。

基于组件的软件供应链

• 1995年底，作为对“再论没有银弹（No Silver Bullet Refired）”回应Brad Cox发表了文章“No Silver Bullet Reconsidered”。文章里Brad Cox深刻探讨了文化和思维范式的变迁(paradigm shift)，从人类文化的观点阐释软件危机的原因，最终得到乐观的结论：解决软件危机的杀手锏（银弹）是可能的。

• 简单来说，Brad Cox认为可以利用软件供应链来鼓励组织和个人生产、买卖软件组件(component)以及更小的子子孙孙组件(subcomponent)。如果买卖各层组件者皆有利可图，形成产业链，人们自然会想尽办法将组件封装得简单易用。Brad Cox觉得Brooks的观点是以技术为中心的，而他的观点则是以人为核心。由于观点的差异，对软件危机的阐释自然会得到不同的结论。

软件危机的根本问题

  理性主义：软件概念结构(conceptual structure)的复杂性，无法达成软件概念的完整性和一致性，自然无法从根本上解决软件危机带来的困境。

软件危机的展望

  如今来看，Brooks的预测是千真万确的，软件危机的困境依然没有从根本上找到解决方法。从复杂系统研究的结果看，人类过去的科学理性范式没有能力处理应对多个独立变量相互作用的复杂系统，而大型软件系统就是高维度复杂系统，人类的理性力量无法有效跟踪分析高维度复杂系统的概念完整性和一致性。换句话说，基于规则的编程模型，找不到解决软件危机的杀手锏（银弹）。

软件过程模型

  每一个软件的生命周期都是独一无二的，但是从众多独一无二的软件个体中却呈现出来一些固有的模式，类似于软件设计模式、建筑设计模式，乃至人生模式，软件生命周期的模式我们称之为软件过程模型。

软件的生命周期概述

一般来讲，我们将软件的生命周期划分为：分析、设计、实现、交付和维护这么五个阶段。

• 分析阶段的任务是需求分析和定义，比如在敏捷统一过程中用例建模和业务领域建模就属于分析阶段。分析阶段一般会在深入理解业务的情况下，形成业务概念原型，业务概念原型是业务功能和业务数据模型的有机统一体，比如用例的集合和业务数据模型，每一个用例在逻辑上都可以通过操作业务数据模型完成关键的业务过程。
• 设计阶段分为软件架构设计和软件详细设计，前者一般和分析阶段联系紧密，一般合称为“分析与设计”；后者一般和实现阶段联系紧密，一般合称为“设计与实现”。
• 实现阶段分为编码和测试，其中测试又涉及到单元测试、集成测试、系统测试等。
• 交付阶段主要是部署、交付测试和用户培训等。
• 维护阶段一般是软件生命周期中持续时间最长的一个阶段，而且在维护阶段很可能会形成单独的项目，从而经历分析、设计、实现、交付几个阶段，最终又合并进维护阶段。

描述性的过程和说明性的过程

  描述性的过程试图客观陈述在软件开发过程中实际发生什么。我们想象一下软件开发过程中实际会发生什么？比如测试时发现了一个bug是对需求的错误理解造成的，那必须返回到分析阶段重新调整软件概念模型，比如用户使用过程中出现闪退现象，我们需要返回到系统测试试图重现闪退，乃至回到设计阶段调整设计方案从根本上解决闪退的根源问题。
  说明性的过程试图主观陈述在软件开发过程中应该会发生什么。显然说明性的过程是抽象的过程模型，有利于整个软件项目团队对软件开发过程形成一致的理解，能够在与实际软件开发过程比较时找出项目过程中的问题。
  采用不同的过程模型时应该能反映出要达到的过程目标，比如构建高质量软件、早发现缺陷、满足预算和日程约束等。不同的模型适用于不同的情况，我们常见的过程模型，比如瀑布模型、V模型、原型化模型等都有它们所能达到的过程目标和适用的情况。

瀑布模型

  瀑布模型（Waterfall Model）是第一个软件过程开发模型，对于能够完全透彻理解的需求且几乎不会发生需求变更的项目瀑布模型是适用的。但是由于瀑布模型能够将软件开发过程按顺序组织过程活动，非常简单和易于理解，因此瀑布模型被广泛应用于解释项目进展情况及所处的阶段。瀑布模型中的主要阶段通过里程碑（milestones）和交付产出来划分的。

  瀑布模型是一个过程活动的顺序结构，没有任何迭代，而大多数软件开发过程都会包含大量迭代过程。瀑布模型不能为处理开发过程中的变更提供任何指导意义，因为瀑布模型假定需求不会发生任何变化。由此看来，瀑布模型将软件开发过程看作类似于工业生产制造的过程，而不是一个创造性的开发过程。工业生产制造的过程就是没有任何迭代活动，直接产出最终产品。瀑布模型视角下的软件开发过程也一样，只有等待整个软件开发过程完成后，才能看到最终软件产品。

带原型的瀑布模型

  显然瀑布模型会将整个软件开发过程中的众多风险积累到最后才能暴露出来，为了尽早暴露风险和控制风险，在瀑布模型的基础上增加一个原型化（prototyping）阶段，可以有效将风险前移，改善整个项目的技术和管理上的可控性。

V模型

  V模型也是在瀑布模型基础上发展出来的，我们发现单元测试、集成测试和系统测试是为了在不同层面验证设计，而交付测试则是确认需求是否得到满足。也就是瀑布模型中前后两端的过程活动具有内在的紧密联系，如果将模块化设计的思想拿到软件开发过程活动的组织中来，可以发现通过将瀑布模型前后两端的过程活动结合起来，可以提高过程活动的内聚度，从而改善软件开发效率。这就是V模型。

  生死相依原则：通过V模型给我们提供一个工作思路，就是在开始一项工作之前，先去思考验证该工作完成的方法。这大概就是中国传统文化中所谓的“未定生，先定死”，我们可以称之为生死相依原则，在软件开发过程中被广泛使用，比如创建一个对象和销毁一个对象的代码成对出现便于代码的组织和管理，V模型是开始一个特定过程活动和评估该特定过程的过程活动成对出现，从而便于软件开发过程的组织和管理。

分阶段增量和迭代

  分阶段开发可以让客户在没有开发完成之前就可以使用部分功能，也就是每次可以交付系统的一小部分，从而缩短开发迭代的周期。如图所示，分阶段开发还可以让产品系统和开发系统并行进行。

分阶段开发的交付策略分为两种，一是增量开发（Incremental development），二是迭代开发（Iterative development）。
增量开发就是从一个功能子系统开始交付，每次交付会增加一些功能，这样逐步扩展功能最终完成整个系统功能的开发。
迭代开发是首先完成一个完整的系统或者完整系统的框架，然后每次交付会升级其中的某个功能子系统，这样反复迭代逐步细化最终完成系
统开发。

分阶段开发有着显著的优点：

• 能够在系统没有开发完成之前，开始进行交付和用户培训；
• 频繁的软件发布可以让开发者敏捷地应对始料未及的问题；
• 开发团队可以在不同的版本聚焦于不同的功能领域，从而提升开发效率；
• 还有助于提前布局抢占市场。
  任何一颗苍天大树最初都是由一粒小小的种子所规定的。分阶段增量和迭代开发就相当于软件开发过程模型的一颗种子，从这颗种子里我们可以看到敏捷方法的意味、能看到持续集成持续交付的感觉、能看到反复迭代中过程改进和重构的可能性。

螺旋模型

  螺旋模型是在1988年由Boehm提出，是一种演化软件开发过程模型，兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险管理，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的基本策略。
螺旋模型将每一次迭代过程分为四个主要阶段：

• Plan
• Determine goals, alternatives and constraints
• Evaluate alternatives and risks
• Develop and test

PSP和TSP

PSP

个体度量过程PSP0：一般来说，做任何事情最基本的思路就是计划、执行和总结。PSP0就是这个最基本的思路，但是在PSP0阶段必须理解和学会采集软件过程中的数据。

• 计划阶段
• 开发阶段
  • 设计
  • 编码
  • 测试
• 开发完成后进行总结分析
  个体度量过程PSP0.1：PSP0.1 增加了编码标准规范、程序规模度量、以及过程改进计划。显然PSP0.1融入了标准规范，而且将最后的总结分析更加明确充实。过程改进计划用于随时记录过程中存在的问题、解决问题的措施以及改进过程的方法，以提高软件开发人员的质量意识和过程意识。
• 计划阶段
• 开发阶段
  • 编码标准规范
  • 设计
  • 编码
  • 测试
• 程序规模度量
• 开发完成后进行总结分析
• 过程改进计划
  PSP0和PSP0.1重点是个体度量过程，也就是通过采集过程数据、度量程序的规模等，通过量化的度量数据为软件过程改进提供基准。
  个体计划过程PSP1：PSP1在计划阶段增加了项目评估，引入了基于估计的计划方法，用自己的历史数据来预测新程序的大小和需要的开发时间，开发阶段之后首先完成项目测试报告。
• 计划阶段
  • 项目评估
• 开发阶段
  • 编码标准规范
  • 设计
  • 编码
  • 测试
• 项目测试报告
• 程序规模度量
• 开发完成后进行总结分析
• 过程改进计划
  在PSP1阶段应该学会编制项目开发计划，这不仅对承担大型软件的开发十分重要，即使是开发小型软件也必不可少。因为，只有对自己的能力有客观的评价，才能作出更加准确的计划，才能实事求是地接受和完成客户委托的任务。
  个体计划过程PSP1.1：PSP1.1在PSP1增加项目评估的基础上，开发阶段之后首统计记录各项工作用了多少时间，前后呼应进行量化管理，为过程改进提供数据支撑。
• 计划阶段
  • 项目评估
• 开发阶段
  • 编码标准规范
  • 设计
  • 编码
  • 测试
• 统计记录各项工作用了多少时间
• 项目测试报告
• 程序规模度量
• 开发完成后进行总结分析
• 过程改进计划
  PSP1和PSP1.1的重点是个体计划过程，基于历史数据来评估项目，进而提高项目计划的准确性。
  个体质量管理PSP2：PSP2的重点是个体质量管理，引入了设计评审（Design Review）和代码评审（Code Review），以便及早发现缺陷，使修复缺陷的代价最小。
• 计划阶段
  • 项目评估
• 开发阶段
  • 编码标准规范
  • 设计
  • 设计评审
  • 编码
  • 代码评审
  • 测试
• 统计记录各项工作用了多少时间
• 项目测试报告
• 程序规模度量
• 开发完成后进行总结分析
• 过程改进计划
  个体质量管理PSP2.1：PSP2.1引入了分析和设计规格，介绍了分析方法，并提供了设计规格。
• 计划阶段
  • 项目评估
• 开发阶段
  • 分析
  • 设计规格
  • 编码标准规范
  • 设计
  • 设计评审
  • 编码
  • 代码评审
  • 测试
• 统计记录各项工作用了多少时间
• 项目测试报告
• 程序规模度量
• 开发完成后进行总结分析
• 过程改进计划
  个体循环过程PSP3：PSP3的重点是个体循环过程，目标是把个体开发小规模程序所能达到的生产效率和生产质量，扩展到大型程序中。主要是采用螺旋式上升的方法，即增量和迭代开发方法，首先把大型程序分解成小的模块，然后对每个模块按照PSP2.1所描述的过程进行开发，最后把这些模块逐步集成为完整的软件产品。
  应用PSP3开发大型软件系统，必须采用增量式开发方法，并要求每一个增量都是高质量的。在这样的前提下，在新一轮个体循环过程中，可以采用回归测试的方法，重点考察新的增量是否符合要求。因此，要求在PSP2中进行严格的设计评审和代码评审，并在PSP2.1中努力遵循设计规格。
  个体软件过程PSP总结：
• 从个软件过程PSP框架的概要描述中，可以清楚地看到，如何作好项目规划和如何保证产品质量，是任何软件开发过程中最基本的问题。
• PSP可以帮助软件工程师在运用软件过程的方法和原则，借助于一些度量和分析工具，了解自己的技能水平，控制和管理自己的工作方式，使自己日常工作中的评估、计划和预测更加准确、更加有效，进而改进个人的工作表现，提高个人的工作质量和产量，积极而有效地参与高级管理人员和过程人员推动的团队范围的软件工程过程改进。
• 个体软件过程PSP为软件工程师提供了发展个人技能的结构化框架和必须掌握的方法。在软件行业，开发人员如果不经过PSP训练，就只能靠在开发中通过实践逐步摸索掌握这些技能和方法，这不仅周期很长，而且要付出很大的代价。

TSP

团队概述

如果几个人随机组成一个小组共同完成一项工作，比如把1000瓶纯净水从A地搬到B地，如果分工负责各干各的彼此之间没有依赖关系，那么这几个人就是临时组成了一个松散的工作组（Work Group），而不是一个团队。
一个团队应该是相互依赖相互协作中完成共同目标的一个组织。比如下图中接力搬运的方式就是团队合作。
团队有一些共同的特点：

• 团队有一致的团队目标，要一起完成这个目标。一个团队的成员不一定要同时工作，比如接力赛跑。
• 团队成员有各自的分工，互相依赖合作，共同完成任务。比如团队赛艇。
  软件团队的组织结构：软件团队的组织分为高度结构化的组织和松散结构化的组织。
  

TSP概述

• 大多数商业软件都是由团队开发的，因此，要想成为一个优秀的软件工程师，你就必须具有在团队中工作的能力。如果你有与人合作的意识并且愿意付诸实践，你就具备了成为一个优秀的团队成员的基本素质。但是，团队协作的涵义远比融洽相处要丰富。
• 团队必须计划项目、跟踪进展、协调工作，还必须有一致的工作目标，共同的工作过程，并且经常自由沟通。
• TSP是一个为多达20人的团队开发或升级大型软件系统而设计的工业化软件过程，而且通常是需要几年时间才能完成的大型项目。我们学习TSP无法完整地模拟实际大型项目的情况，但是可以学习到最基本的概念和方法，以便将来在实际大型项目中能够快速上手TSP。
• 单纯把一项工作任务交给一群工程师并不能自动产生一个团队。建设团队的步骤并不显而易见，新的团队经常要花费大量时间去建立团队的运行机制。他们必须明确如何作为一个团队一起工作，如何定义要做的工作，以及如何设计工作方案。他们必须在团队成员间分配任务、协调任务，并且跟踪和汇报工作进展。虽然这些团队建设工作很重要，但是并不难，而且已有很多完成这些工作的方法，你和你的团队成员并不需要自己去重新发明这些方法。

TSP的基本原理

项目失败最根本的原因是团队问题。

哪些常见的团队问题容易导致项目失败？

缺乏有效的领导和管理；

• 不能做出妥协、安排或不善于合作；
• 缺少参与；
• 拖拉与缺乏信心；
• 质量低劣；
• 功能多余；
• 无效的组员互评；

团队的基本要素

• 团队规模
• 团队的凝聚力
• 团队协作的基本条件

如何建设高效团队

• 建设具有凝聚力的团队
• 设定有挑战性的目标
• 反馈
• 共同遵守的工作流程和框架

TSP的基本工作方法

如何开始一个团队项目？

• 设定团队目标
• 设定团队成员目标，包括各个角色的目标
  • 团队领导角色
  • 开发经理角色
  • 计划经理角色
  • 质量和过程经理角色
  • 支持经理角色
• 项目筹备及第一次项目会议
  团队项目的基本策略
• 计划先行，也就是做出承诺之前先计划
• 完成概念设计
• 选择开发策略
• 完成初步规模估算
• 完成初步时间估算
• 评估风险
• 建立策略文档
• 制定配置管理计划
  开发计划
• 制定计划
• 实现计划
• 对照计划跟踪进展
• 质量管理
  定义需求
• 软件需求规格说明书
• 需求任务分配
• 系统测试计划
• 需求变更和追溯管理
  与团队一起设计
• 利用所有团队成员的才智
• 产生精确的设计
• 复用性设计
• 易用性设计
• 可测试性设计
• 设计规格说明书
  -设计评审和审查
  产品实现
• 编码标准
• 缺陷预防
• 详细设计与设计评审
• 编码及代码评审
• 单元测试
  集成与系统测试
• 构建和集成策略
• 测试计划
• 跟踪缺陷
• 系统测试
• 回归测试
  结项总结
• 过程改进建议

CMM/CMMI

CMM/CMMI简介

  CMM/CMMI用于评价软件生产能力并帮助其改善软件质量的方法，成为了评估软件能力与成熟度的一套标准，它侧重于软件开发过程的管理及工程能力的提高与评估，是国际软件业的质量管理标准。
  CMMI共有5个级别，代表软件团队能力成熟度的5个等级，数字越大，成熟度越高，高成熟度等级表示有比较强的软件综合开发能力。

• CMMI一级，初始级。在初始级水平上，软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。但是由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务。项目实施能否成功主要取决于实施人员。
• CMMI二级，管理级。在管理级水平上，所有第一级的要求都已经达到，另外，软件组织在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对项目相关的实施人员进行了相应的培训，对整个流程进行监测与控制，并联合上级单位对项目与流程进行审查。二级水平的软件组织对项目有一系列管理程序，避免了软件组织完成任务的偶然性，保证了软件组织实施项目的成功率。
• CMMl三级，已定义级。在已定义级水平上，所有第二级的要求都已经达到，另外，软件组织能够根据自身的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。这样，软件组织不仅能够在同类项目上成功，也可以在其他项目上成功。科学管理成为软件组织的一种文化，成为软件组织的财富。
• CMMI四级，量化管理级。在量化管理级水平上，所有第三级的要求都已经达到，另外，软件组织的项目管理实现了数字化。通过数字化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
• CMMI五级，持续优化级。在持续优化级水平上，所有第四级的要求都已经达到，另外，软件组织能够充分利用信息资料，对软件组织在项目实施的过程中可能出现的问题予以预防。能够主动地改善流程，运用新技术，实现流程的优化。
  CMM模型基于众多软件专家的实践经验，是组织进行软件过程改善和软件过程评估的一个有效的指导框架。CMMI更是为工业界和政府部门提供了一个集成的产品集，其主要目的是消除不同模型之间的不一致和重复，降低基于模型改善的成本。CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。CMM/CMMI不仅是一个模型，一个工具，它更代表了一种管理哲学在软件工业中的应用。
  CMM/CMMI所依据的想法是只要不断地对企业的软件工程过程的基础结构和实践进行管理和改进，就可以克服软件生产中的困难，增强开发能力，从而能按时地、不超预算地开发出高质量的软件。

CMM/CMMI的作用

  CMM/CMMI是基于政府评估软件承包商的软件能力发展而来的，有两种通用的评估方法用以评估组织软件过程的成熟度：软件过程评估和软件能力评价。

• 软件过程评估：用于确定一个组织当前的软件工程过程状态及组织所面临的软件过程的优先改善问题，为组织领导层提供报告以获得组织对软件过程改善的支持。软件过程评估集中关注组织自身的软件过程，在一种合作的、开放的环境中进行。评估的成功取决于管理者和专业人员对组织软件过程改善的支持。
• 软件能力评价：用于识别合格的软件承包商或者监控软件承包商开发软件的过程状态。软件能力评价集中关注识别在预算和进度要求范围内完成开发出高质量的软件产品的软件合同及相关风险。评价在一种审核的环境中进行，重点在于揭示组织实际执行软件过程的文档化的审核记录。

CMM/CMMI的主要内容

  CMM/CMMI把软件开发组织的能力成熟度分为5个等级。除了第1级外，其他每一级都由几个过程域组成。每一个过程域都由公共特性予以表征。CMM/CMMI给每个过程规定了一些具体目标。按每个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例，这个关键过程的各项目标就能达到，这就表明该关键过程实现了。这种分级的思路在于把一个组织执行软件过程的成熟程度分成循序渐进的几个阶段，这与软件组织提高自身能力的实际推进过程相吻合。这种成熟度分级的优点在于级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。这一点很重要，因为大多数软件组织只能在某一段时间里集中开展少数几项过程改进活动。

CMMI评估

  CMMI评估组由几方人员共同组成，由主任评估师领导。其中评估小组是由经验丰富的软件专业人员组成，还要经过培训，使他们了解组织的同时，也懂得如何将CMM/CMMI模型及关键实践与组织的要求建立关联。参与评估的人员包括：公司的管理人员、项目经理，开发人员，培训人员，采购人员等。
评估过程主要分成三个阶段：准备阶段、评估阶段和报告阶段。

• 准备阶段包括小组人员培训、计划以及其它必要的评估准备工作。在评估的最初几十天，小组成员的主要任务是采集数据，回答SEI的CMM/CMMI提问单，文档审阅以及进行交谈，对整个组织中的应用有一个全面的了解。
• 然后进行数据分析。评估员要对记录进行整理，并检验所观察到的一切信息，然后把这些数据与CMM/CMMI模型进行比较，最后给出一个评估报告。在每个评估报告中，必须针对CMM/CMMI 的每个过程方面，指出这个软件过程在什么地方已经有效地执行了，什么地方还没有有效地执行。只有所有评估人员一致通过的情况下，这个评估报告才有效。
• 在评估报告的基础上，评估小组产生一个评估结果。评估和评级的结果应与有关的关键过程域和目标相对应。评估报告和结果将送交所有有关的人员并上报CMU/SEI。

敏捷方法

敏捷方法产生的背景

敏捷宣言及所遵循的原则

敏捷宣言：

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划
• 也就是说，尽管右项有其价值，我们更重视左项的价值。
  敏捷方法所遵循的原则
• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

Scrum敏捷开发方法

Scrum是一种迭代的增量软件项目管理方法，是敏捷方法中最为常见的软件开发模型之一。
Scrum中的团队角色：

• 项目经理（Scrum Master），一般也称为project manager，负责项目的开发过程。
• 产品经理（Product Owner），代表业务需求方及利益相关方，比如定义产品功能和特性。
• 团队（Team），是一个跨职能小组进行实际分析、设计、实现、测试等工作。

DevOps

什么是DevOps？

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

6.2.DevOps和敏捷方法

6.3.DevOps和精益原则

6.4.DevOps和全栈自动化