大家好，又见面了，我是你们的朋友全栈君。
文章目录
- 主要内容
- 项目范围6个过程
- 范围管理的重要性
- 总表
- 5.1范围管理概述
- 5.2规划范围管理
- 5.3收集需求
- 5.4定义范围
- 5.5创建工作分解结构（WBS）
- 5.6确认范围
- 5.7控制范围
主要内容
项目范围6个过程
（1）规划范围管理：对如何定义、确认和控制项目范围的过程进行描述。 （2）收集需求：为实现项目目标，明确并记录项目干系人的相关需求的过程。 （3）定义范围：详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础。 （4）创建工作分解结构（WBS）：把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上而下的分解结构。 （5）确认范围：正式验收已完成的可交付成果。 （6）范围控制：监督项目和产品的范围状态、管理范围基准变更。
范围管理的重要性
（1）项目范围来自于项目目标完成项目工作范围是为了实现项目目标。 （2）项目范围管理及控制的有效性，是衡量项目是否达到成功的一个必要标准。 （3）在项目中不断重申项目工作范围，是项目中实施控制管理的一个主要手段。 （4）项目范围管理可以详细、清楚地界定分工界面和责任。 （5）项目范围管理能确定项目边界，明确主要可交付成果，范围管理能提高对项目成本、进度和资源估算的准确性。 （6）项目范围管理影响到项目的成功，在实践中，范围蔓延是项目失败最常见的原因之一。
项目管理四个核心：成本、进度、质量和范围。范围是基础性和全局性的工作。
总表
规划范围管理 | 收集需求 | 定义范围 | 创建WBS | 确认范围 | 监控范围 | |
|---|---|---|---|---|---|---|
What | 创建范围管理计划和需求管理计划，书面将如何定义、确认和控制范围。作用：在整个项目中如何管理范围提供南 | 定义干系人的需求作用：为定义和管理项目范围（包括产品范围）奠定基础 | 制定一份范围说明书，详细描述项目和产品、具体定义、描述项目范围作用：明确收集的需求哪些包含在项目范围内，哪些将排除在项目范围外，明确项目、服务或成果边界 | 创建一份WBS把项目可交付成果和项目工作分解为较小的，更易于管理的组成部分。作用：对所要交付的内容提供一个结构化视图 | 正式验收已经完成的可交付成果，与客户或发起人一起审查可交付成果，确保可交付成果已经圆满完成。作用：使验收过程具有客观性，通过每个可交付成果验收，提高最终产品、服务或成果活动验收的可能性 | 监督项目和产品范围，管理范围基准变更。作用：在整个项目期间保持对范围基准的维护 |
Why | 指导范围管理知识领域其他过程如何开展 | 收集需求旨在定义和管理客户期望，掌握项目需求和产品需求对促进项目成功有重要作用需求是WS基础 | 编制详细的项目范围说明书，对项目成功至关重要 | WBS代表着项目范围说明书所规定的工作，可以针对WBS的工作包安排进度，估算成本和实施监控 | 获得客户或发起人正式验收 | 防止范围失控。变更实际发生时，管理变更。如果变更不可避免，必须强制实施项目整体变更控制。杜绝范围延和范围镀金 |
Who | 项目管理团队/项目团队（如果项目规模比较小），组织过程资产往往是可以剪裁来使用的 | 项目管理团队/项目团队（如果项目规模比较小） | 项目经理带领项目管理团队/项目团队（如果项目规模比较小）制定，应该获得发起人/客户和关键干系人批准 | 项目管理团队/项目团队（如果项目规模比较小） | 项目经理与客户或发起人一起 | 项目管理团队或项目团队（如果项目规模比较小） |
When | 在制定项目章程后，范围管理其他过程之前 | 项目章程制定和后，干系人初步识别后，规划范围管理后 | 收到需求以后 | 制定项目范围说明书后 | 已经产出可交付成果，并且可交付成果已经通过实施质量控制过程进行了检验，得到了组织中质检部门的确认之后，实施质量控制和核实范围也可同时进行 | 项目或阶段末，项目结束前进行。 |
How | 召开会议和专家判断 | 采用访谈/小组会议/引导式研讨会/群体创新技术/群体决策技术/问卷调查/观察/原型法/系统交互图文件分析来收集需求 | 采用产品分析、备选方案生成和引导式研讨会，采用专家判断 | 用分解和专家判断的方法 | 检查/群体决策技术 | 釆用挣值计算，进行偏差分析 |
5.1范围管理概述
1、项目范围管理需要做以下三个方面的工作： ①明确项目边界。 ②对项目执行工作进行监控。 ③防止项目范围发生蔓延。
三不做：不需要做的、无法做的、不能做的。
范围蔓延：客户提出新需求，超出了范围基准【客户不断提出要求，不断去改，最终交付物不满足要求】 范围镀金：客户没有提新需求，乙方自己做了额外客户不需要的工作【项目实施人员往往愿意尝试新的技术或者为信息系统项目加上更牛X的功能】 范围潜变：客户不断提岀小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败
2、产品范围（强调结果）与项目范围（强调过程）： ①产品范围是指产品或者服务所应该包含的功能，项目范围是指为了能够交付产品，项目所必须做的工作。 ②产品范围是项目范围的基础，产品范围的定义是产品要求的描述，而项目范围的定义是产生项目管理计划的基础，两种范围在应用上有区别。 ③项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。判断项目范围是否完成，要以范围基准来衡量。产品范围是否完成，则根据产品是否满足了产品描述来判断。 ④产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。 3、范围管理的各个过程（图来自蓝皮书）
5.2规划范围管理
1、编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，在整个项目中对如何管理范围提供指南和方向。范围管理计划需要项目管理团队全员参与。 2、范围管理计划的内容： ①如何制订项目范围说眀书 ②如何根据范围说明书创建WBS ③如何维护和批准WBS ④如何确认和正式验收已完成的项目可交付成果。 ⑤如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。 3、范围管理计划描述如何管理项目范围，项目范围怎样变化才能与项目要求相一致等问题，所以它也应该对怎样变化、变化频率如何，以及变化了多少等项目范围预期的稳定性进行评估。 范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类等问题的清楚描述。项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概活的，可以是正式的或者非正式的。 4、需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。 5、需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。 6、需求管理计划的内容： ①如何规划、跟踪和汇报各种需求活动 ②需求管理需要使用的资源 ③培训计划 ④项目干系人参与需求管理的策略 ⑤判断项目范围与需求不一致的准则和纠正规程 ⑥需求跟踪结构 ⑦配置管理活动
5.3收集需求
1、需求包括业务需求、干系人需求、解决方案需求、过渡需求、项目需求和质量需求等。
需求类型 | 含义 |
|---|---|
业务需求 | 整个组织的高层级需要。例如：实施项目的原因。 |
干系人需求 | 干系人群体的需要 |
解决方案需求 | 为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征 |
过渡需求 | 从“当前状态”过渡到“将来状态”所需的临时能力；例如：数据转换和培训需求 |
项目需求 | 项目需满足的行动、过程或条件 |
质量需求 | 用于确认可交付成果完成的标准 |
2、收集需求的工具与技术有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。
工具与技术 | 含义 |
|---|---|
访谈 | 正式或非正式，一对一会谈或一对多访谈匚 |
焦点小组 | 一对一访谈的扩展形式，加入了专家，专门的主持人 |
引导式研讨会 | 集中主要干系人，集中讨论定义产品需求，强调跨职能和协调干系人差异 |
群体创新技术 | 组织一些群体活动来识别项目和产品需求 |
群体决策技术 | 为达成某种期望结果，对多个未来行动方案进行评估 |
原型法 | 制造模型，征求反馈，支持渐进明细 |
标杆对照 | 用实际和计划与其他组织的进行比较 |
群体创新技术： ①头脑风暴：各抒己见。 ②名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。 ③德尔菲技术：可以防止个人的观点被不正确的放大。 ④概念/思维导图：是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。 ⑤亲和图又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。 ⑥多标准决策分析是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
3、需求文件的内容包括： ①业务需求 ②干系人需求 ③解决方案需求 ④项目需求 ⑤过渡需求 ⑥与需求有关的假设条件、依赖关系和制约因素。
4、需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。 5、可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。可验证性是需求的最基本特性。 6、每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。双向跟踪，包括正向和反向跟踪： 正向跟踪：检查需求文件中的每个需求是否都能在后继工作产品（成果） 中找到对应点；（以免需求被做漏、做偏） 反向跟踪：逆向跟踪，检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。（是查需求源头，了解为什么要做这个需求来源背景和原因是什么）
①从用户原始需求可向前追溯到需求文件可区分受变更影响的需求，确保需求文件包括所有用户需求； ②从需求文件回溯到相应的用户原始需求，确认每个需求的出处； ③从需求文件追溯到产品元素，可知每个需求对应的产品元素，从而确保产品元素满足需求； ④产品元素回溯到需求文件，使项目团队成员知道产品元素存在的原因； （如果设计元素或测试案例无法回溯到需求文件，则可能是镀金；如果孤立的产品元素是一个正当功能，则可能是需求遗漏） ⑤需求文件之间的跟踪便于更好地处理各种需求之间的逻辑相关性检査需求分解中可能出现的错误或遗漏。 7、需求跟踪矩阵表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。
需求 | 用例1 | 用例2 | … |
|---|---|---|---|
需求1 | |||
需求2 | |||
… |
8、需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、己完成等）和状态日期。
5.4定义范围
1、定义范围是制定项目和产品详细描述的过程，是明确所收集的需求哪些包含在项目范围内，哪些在项目范围外，从而明确产品、服务或成果的边界。 2、定义范围工具与技术：专家判断、产品分析、备选方案生成和引导式研讨会。 ①产品分析：对于那些以产品为可交付成果的项目，是一种有效的工具 ②备选方案生成：用来指定尽可能多的澘在可选方案的技术，用于识别执行项目工作的不同方法 注：产品分析与范围定义紧密相关如软件产品分为几个子系统？是不是有基础平台？等等。 3、项目范围说明书的内容： ①产品范围描述 ②验收标准 ③可交付成果 ④项目的除外责任 ⑤制约因素 ⑥假设条件
4、项目范围说明书的主要作用： ①确定范围 ②沟通基础 ③规划和控制依据 ④变更基础 ⑤规划基础
5.5创建工作分解结构（WBS）
1、创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程 2、里程碑标志着某个可交付成果或者阶段的正式完成。 注意：重要的检査点是里程碑、重要的里程碑是基线 3、工作包应便于完整地分派给不同的人或组织单元，所以要求明确各工作单元直接的界面。工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。作为一种经验法则，8/80规则（80小时原则）建议工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时。 几个相关概念： 范围基准：经过批准的项目范围说明书、WBS、WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。 项目范围说明书：是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围，包括项目和产品范围。 WBS：全部工作范围的层级分解（有助于防止范围蔓延）。 WBS词典：针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件（有助于评价变更的影响）。
4、控制账户是一种管理控制点。在该控制点上，将范围、预算（资源计划）、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效。控制账户是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于个控制账户。项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。 5、规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。规划包是在控制账户之下、工作包之上的WB要素。规划包是暂时用来做计划的，随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。 6、WBS词典也称为WBS词汇表，它是描述WBS各组成部分的文件。对于WBS的每一组成部分WBS词典可能包括账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑相关的进度活动、所需资源、成本估算、质量要求验收标准、技术参考文献、协议信息等。 （WBS字典实际是相当于新华字典，是对WBS中每个元素的描述） 7、分解是一种将项目可交付成果和项目工作分解成较小的、更易于管理的组件的技术。 8、要将整个项目工作分解为工作包，需要开展以下活动： ①识别和分析可交付成果及相关工作 ②确定WBS的结构和编排方法 ③自上而下逐层细化分解。 ④为WBS组件制定和分配标识编码。 ⑤核实可交付成果分解的程度是恰当的 9、创建WBS时对工作的划分原则包括： ①功能或者技术原则。在创建WBS时，需要考虑将不同人员的工作分开。 ②组织结构 ③系统或者子系统。总的系统划分为几个主要的子系统，然后对每个子系统再进行分解。
10、WBS分解的方法： ①项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。（如按项目周期的需求、设计、开发、测试、实施等阶段做为第二层；把每个阶段产出的可交付成果作为第三层，如：需求分析结果、调研结果等） ②主要可交付成果作为分解的第二层（ERP分解为OA、客户关系管理等） ③整合可能由项目团队以外的组织来实施的各种组件（例如，外包工作），然后作为外包工作的一部分，卖方需编制相应的合同WBS。 例子看这里：https://m.sohu.com/a/150900112_208218
11、WBS不是某个项目团队成员的责任，应该由全体项目团队成员用户和项目干系人共同完成和致确认。 12、WBS表示形式有分级的树型结构（组织结构图式）和表格形式（列表式） 树型结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示岀项目的全貌（常用于小项目）。 表格形式的直观性比较差，但能够反映出项目所有的工作要素（常用于大项目）。 13、虽然有些参考文献也使用鱼骨图形式的WBS，但这种形式并不常用。 14、WBS分解注意8个方面： ①WBS必须是面向可交付成果的。 ②WBS必须符合项目的范围。 ③WBS的底层应该支持计划和控制。 ④WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。 ⑤WBS的指导（不是原则），WBS应控制在4∽6层。 ⑥WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。 ⑦WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。 ⑧WBS并非是一成不变的。在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。 补充： （1）在层次上保持项目的完整性，避免遗漏必要的组成部分。 （2）一个工作单元只能从属于某个上层单元，避免交叉从属。 （3）相同层次的工作单元应用相同性质。 （4）工作单元应能分开不同的责任者和不同的工作内容。 （5）便于项目管理计划和项目控制的需要。 （6）最底层工作应该具有可比性，是可管理的，可定量检查的。 （7）应包括项目管理工作，包括分包出去的工作。
5.6确认范围
1、确认范围是正式验收项目己完成的可交付成果的过程。确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。 2、确认范围的主要工具与技术是检査和群体决策技术。检查也称为审查、评审、审计、走查、巡检、测试等，是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。 3、确认范围应该贯穿项目的始终。 4、确认范围的步骤： ①确定需要进行范围确认的时间。 ②识别范围确认需要哪些投入。 ③确定范围正式被接受的标准和要素。 ④确定范围确认会议的组织步骤。 ⑤组织范围确认会议。
5、范围确认时，一般需要检查以下问题： ①可交付成果是否是确定的、可确认的。 ②毎个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。 ③是否有明确的质量标准。 ④审核和承诺是否有清晰的表达。 ⑤项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。 ⑥项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。
6、管理层所关注的项目范围是指范围对项目的进度、资金和资源的影响，些因素是否超过了组织承受范围是否在投入产出上具有合理性。企业管理层不会关心太细节的东西。只需要关心投入产岀的合理性就好了。 7、核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整；确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。 8、确认范围与项目收尾的不同之处在于： ①虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。 ②确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。
9、范围确认完成时，同时应当对确认中调整的WBS及WBS字典进行更新。 10、范围确认和需求确认一定要分开。需求确认是在项目前期三方通过召开需求评审会的方式讨论从而形成—个需求说明书，确认需求；范围确认是阶段性的验收。 11、确认范围与质量控制的不同之处在于： ①确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。 ②质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行。 ③质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。 具体看下表：
区别 | 质量控制 | 确认范围 |
|---|---|---|
关注重点 | 正确性–可交付成果做得对不对，质量有没有问题（正确的未必可接受） | 可接受性–可交付成果是否满足需求，是否能通过验收 |
实施方 | 一般内部的QC部门进行 | 项目发起人、客户和其他主要干系人 |
先后顺序 | 通常先做，也可同时进行 | 通常后做，也可同时进行 |
通过标准 | 是否符合质量测量指标 | 是否满足需求文件中的描述，是否符合验收标准 |
交付物 | 核实的可交付成果 | 验收的可交付成果 |
实施动作 | 英文 Verification、verify-核实（质量） | Validation、 Validate-确认（成果） |
12、确认范围与项目收尾的不同之处在于： ①虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。 ②确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。
13、每个人对项目范围所关注的方面是不同的。 ①管理层所关注的项目范围，是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。 ②客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务。 ③项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。 ④项目团队成员主要关心项目范围中自己参与的元素和负责的元素，通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作又有冲突的地方。
5.7控制范围
1、控制范围是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时，也要采用范围控制过程来管理这些变更。
2、造成项目范围变更的原因是项目外部环境发生了变化，例如： ①政府政策的问题。 ②项目范围的计划编制不周密详细，有一定的错误或遗漏。 ③市场上出现了或是设计人员提出了新技术、新手段或新方案。 ④项目执行组织本身发生变化。 ⑤客户对项目、项目产品或服务的要求发生变化。 3、未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）称为范围蔓延。 变更是不可避免的，控制范围过程依赖于范围变更控制系统，范围变更控制是指对有关项目范围的变更实施控制，审批项目范围变更的一系列过程，包括书面文件、跟踪系统和授权变更所必须的批准级别。 4、范围变更控制的工作： ①影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。 ②判断范围变更是否已经发生。 ③范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。
5、项目管理中变更是极其普遍的现象，对变更要进行管理。项目范围的核心是产品围，因此，产品的需求发生变化其实就是一种范围变更。需求的核心是客户的需求，无论需求识别还是需求变更都要让客户参与。范围管理是整体管理的部分，变更流程可统一设计，统一管理，因此没必要必须把范围变更与整体变更区分开来。 6、项目范围变更控制，包括审批项目范围变更的一系列过程，包括书面文件、跟踪系统和授权变更所必须的批准级别。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/190702.html原文链接：https://javaforall.cn
