** 如有错误，感谢指正**

如有错误，感谢指正，请私信博主，有辛苦红包，拜“一字之师”。

请根据目录寻找自己需要的段落

导语：本博客为个人整理Java学习记录帖，如有错误，感谢指正。系统学习，欢迎持续关注，后续陆陆续续更新~
Java 交流qq群 383245788。群内有一些资源和大佬，欢迎进来交流。

本文旨在学习交流，个人敏捷开发学习心得-自用

内容来源：

1. 黑皮书-软件开发
2. 拉钩教育
3. 相关博客和学习视频

正文

敏捷理论

敏捷既可以说成是一种思维，也可以说是一-种方法，它旨在项目推进的过程中，帮助团队提高效率但除了敏捷，精益思想和看板方法也能够提高效率。

• 精益方法多用于企业管理，是面向全局性的战略级方法
• 敏捷和看板方法多用于产研团队，是面向组织级的

敏捷的三把利剑：价值观、原则和实践

• 敏捷思维是由是价值观和原则构成，并在敏捷实践中体现出来的。其中，价值观来定义敏捷思维模式，原则作为行动指导，实践也就是具体应用的过程。实践的部分是非常重要的，学习敏捷，最终都要落实到实际工作场景中，在这个过程中，要注意根据自身需求去选择最适合的实践方案。

敏捷宣言

• 个体和互动高于流程和工具；
• 工作的软件高于详细的文档；
• 客户合作高于合同谈判；
• 响应变化高于遵循计划。

敏捷宣言定义了敏捷是一种方法，但依据多年的敏捷实战经验，我们可以这样来理解敏捷，它就是用来应对 VUCA 时代不确定性商业环境的方法和实践。敏捷宣言是敏捷的价值观，它告诉我们两点：

1. 敏捷方法并不是凭空而谈，它源自实践积累，我们需要把握敏捷的核心，在实践中不断去探索更好的方法。
2. 敏捷方法来源于实践，它也应归于实践，帮助我们解决实际问题，而不是一个框住我们思维的框架，沦为思想牢笼。

敏捷的十二大原则

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

解释：十二原则是用来指导我们如何进行敏捷实践的，它明确地列出了我们在推进项目中会遇到的一些情况，并且说明了应该怎样去做，或者怎样做更好。比如第二条，它告诉我们要欣然地面对需求变化，这是因为在工作中，需求很容易频繁地变更，如果团队没有做好随时面对变更的心理准备，就很容易陷入沮丧之中影响了项目推进。比如第六条，它告诉我们面对面交谈是最好的沟通方式，这是因为有很多团队在工作中习惯用文字沟通，但是这样容易表述不清产生歧义，需要反复确认，增加了沟通的成本。

敏捷实践：

敏捷方法

Scrum 方法：Scrum 是现在最流行的敏捷方法 ，它主要是面向开发和维护复杂产品的。这个结构框架很好理
解，可以用“3355”来全盘概括，意思是 3 种角色、3 种工件、 5 种仪式和 5 种价值观。

DSDM 方法：DSDM 就是动态系统开发方法。它具体的实施思路是这样的：在时间进度和可用资源预先固定的情况下，力争最大化地满足业务需求（传统方法一般是需求固定，时间和资源可变），然后交付所需要的系统。对于交付的系统，必须达到足够的稳定程度，确保可以在实际环境中运行；对于业务方面的某些紧急需求，必须做到在能够在短时间内满足，并在后续迭代阶段中对这些功能进行完善。
水晶方法：一种提倡机动性的方法，包含具有共性的核心元素，每个原色都含有独特的角色、过程模式、工作产品和实践。发明人将水晶方法细化为透明水晶方法论（Crystal Clear）、黄色水晶方法论（Crystal Yellow）、橙色水晶方法论（Crystal Orange）以及红色水晶方法论（CrystalRed）。这几种水晶方法论按照项目重要程度以及参加人员规模来进行划分。
水晶方法更强调组织，它会教你如何进行组织转型，同时也是一套可以根据不同的组织进行“因地制宜”裁剪的方法。
特性驱动方法：特性驱动方法简称 FDD，它是一个模型驱动（model-driven）、短期迭代（short-iteration）的过程，也就是说 FDD 是一个开发过程，过程就有起点和终点，FDD 的起点是创建一个全局的模型轮廓，通过两周一次的"特性设计-特性实现"的迭代，逐渐丰富模型功能内容。
特性驱动方法在平常地工作中使用较多。它最大的特点是需要一个全面的架构，这意味着设计和建模已经非常清晰了，所以它比较适合不需要试错的产品，也就是说需求范围很确定的项目。
自适应软件开发方法 ：

1. 基于复杂自适应系统理论，改善软件推测、协作和学习过程，建立新的价值观：自适应比优化重要；
2. 关注人（技能）和交流，将开发过程放在第二位，关注工作的软件而不是文档，它强调和客户协作及对变更的适应；
3. 定义以人为本的、领导-协作管理模型。领导的重点不是指令，而是创造一个文化氛围，使自适应和协作能够有效运行，除此之外，还要创造一个协作结构，使多个团队能够进行有效沟通。

它是更加适合需求多变、开发期短的软件项目。可以说它就是敏捷的雏形，但是更适用于开发内部，这是因为它不强调交付的价值，也没有过多关注到市场和用户的变化。

持续集成方法：持续集成方法是一种工程实践方法，具体来说就是每当开发人员提交一行代码，就能通过机器自动编译、自动测试，然后自动发布。开发团队通常每天集成一次，就能产生一个新版本供团队和用户体验，其目标是通过快速产生的版本可以尽快把问题暴露出来，进一步提高开发生产的效率。

最佳实践

我们是通过这些具体的内容来评判是否是最佳实践的：

1. 稳定的团队：我们需要稳定、有默契的团队，即在很长一段时间内团队成员是固定不变的。
2. 可预见的速率：我们需要在一个迭代当中形成团队的速率，方便知道下一个迭代我们可以做完哪些工作。
3. 单件流：我们需要集中精力一次做好一件事情，所以不欢迎并行任务。
4. 质量内建：我们需要在每一个环节保证好自己的质量，不让质量问题留到下游。
5. 日事日毕：我们需要把任务粒度拆分成至多1天，以方便每天知道我们的工作进展。
6. 设有紧急停车带：我们需要给紧急任务加上紧急停车带，以便分析紧急任务的插入情况。
7. 滚动迭代：我们需要通过迭代交付来完善我们的产品。
8. 持续改进：我们需要通过回顾和总结，不断强化我们的团队能力。
9. 尽早交付：我们希望尽早交付版本，更快得到用户反馈，以便于更快满足用户所需。

需要注意的是，我们要认清自己与最佳实践的差距，不可一蹴而就。要针对自己的实际情况，按照需求进行裁剪，避免形式主义，不要为了敏捷而做敏捷。

敏捷转型-项目的生命周期

项目的生命周期是来描述项目从概念到完成的整个过程。整个项目生命周期包括五个过程组。

1. 启动过程组：是一个包含了获得授权，并定义一个新项目或现有项目的一个新阶段，然后正式开始该项目或阶段的过程。 比如，我们在开始做斗地主第一个手游版本之前，会先论证市场、竞品和用户商业模式，然后形成结论之后输出项目章程。在这个过程中，我们投入的资源会比较少，只有制作人、产品负责人和项目经理，以及几位研发领导；
2. 规划过程组：是通过明确项目范围和优化目标，为实现目标而制定行动方案的一组过程，使团队工作能够有序发展。比如通常我们的项目会分成四个阶段计划：Demo 阶段、基本功能实现、灰度发布和正式发布，每个阶段都有其范围、资源投入情况等；
3. 执行过程组：是通过完成项目管理计划中确定的工作以实现项目目标的一组过程。在这个过程里，我们主要需要关注的是信息沟通和项目进展；
4. 监控过程组：是指通过跟踪、审查和调整项目进展与绩效，以识别必要的计划变更并启动相应变更的一组过程，使得项目朝目标方向进展。这个过程我们主要控制四个方面：范围变更、质量控制、状态报告及风险应对；
5. 收尾过程组：是指为完结所有过程组的所有活动以正式结束项目或阶段而实施的一组过程。这个过程组的主要价值是可以总结项目过程中得到的教训，并对此持续改进，帮助我们在今后的项目中完成得更好。

在实际的工作中，我们遇到的项目多样，需求情况是不同的，所以人们根据不同项目的特点对它们进行了归纳，总结出了四种项目生命周期：预测型、迭代型、增量型、敏捷型。我们可以根据自身项目的特点来选择合适的类型，帮助我们更好地推进，也就是说我们可以以此来判断项目是否适合敏捷方法。

预测型生命周期

首先是预测型生命周期，通常我们所说的项目生命周期其实就是指预测型生命周期。预测型生命周期是以分析、设计、构建、测试和交付为顺序的方式执行的，这要求我们制定详细的计划，什么时候启动项目，什么时候结束项目。在此过程中，我们尽量限制变更，以至于我们需要成立变更委员会这样复杂的机构来处理每一次变更的审批。因为这样项目尽可能地减少了处理变更带来的成本，有利于最小成本地交付产品。
在项目刚开始制定计划时，团队必须考虑到各种项目制约因素，并将这些制约因素加入风险和成本计划当中。这样当我们在执行计划时，可以严格控制对这些计划的影响，尽量少让项目产生变更。
因为预测型项目强调顺序执行，所以通常不会在项目过程中交付产品或服务，这样会产生一个较大的风险，就是一旦对客户需求理解不够，或对需求产生了分歧，那么前面做的很多工作将付之一炬。

迭代型的生命周期

早期的互联网项目大多属于迭代型生命周期。它在项目过程当中就会产生交付，我们可以在过程中获得反馈，然后收集这些反馈进行归纳、提炼，随后形成新的需求，再把这些需求放在下一个迭代版本中完成。这样我们就可以通过原型验证或概念验证的方式来帮助我们改进工作成果。这样做的好处是可以减少项目的不确定性。
迭代型的生命周期整个过程包括需求分析、分析设计、构建测试和价值交付，它的特点集中在中间的分析设计和构建测试的过程中，此时我们需要不断快速打磨以完善我们的产品。这样就能通过快速迭代来尽早修复问题，而且修复成本就会变得更小。如果项目中需求频繁发生变化，或者我们认为