谁知道敏捷开发到底是什么鬼啊？

敏捷开发（Agile Development）是一种以快速响应变化为核心的软件开发方法论，强调通过迭代、协作和持续交付来高效完成项目。与传统“瀑布模型”（按阶段线性开发）不同，它更注重灵活应对需求变动，而非严格遵循初始计划。

---

核心思想

1. 敏捷宣言（Agile Manifesto）的四大价值观：

   • 个体与互动 > 流程与工具
   • 可工作的软件 > 详尽的文档
   • 客户合作 > 合同谈判
   • 响应变化 > 遵循计划

2. 十二原则（部分关键点）：

   • 频繁交付可用的软件（通常每2-4周）。
   • 拥抱需求变化，即使开发后期。
   • 开发团队与业务人员每日协作。
   • 以可持续的节奏推进工作（避免过度消耗）。

---

常见方法

一.极限编程（XP）

1. 极限编程（XP）的本质

极限编程是敏捷开发方法中工程实践最严格、技术规范最明确的框架，由Kent Beck于1996年提出。其核心目标是通过高频率的反馈与持续改进，在需求快速变化的环境中交付高质量软件，尤其强调代码质量与团队协作。

---

2. XP的五大核心价值观

1. 沟通（Communication）
   • 消除信息孤岛，开发团队、客户、管理者保持高频对话。
   • 典型实践：每日站会、结对编程、用户故事讨论。
2. 简单（Simplicity）
   • 以最简单方案实现当前需求，避免过度设计（YAGNI原则：You Ain’t Gonna Need It）。
   • 示例：仅实现已知业务逻辑，而非预测未来扩展。
3. 反馈（Feedback）
   • 快速验证代码正确性与业务匹配度。
   • 技术手段：单元测试、持续集成、短周期迭代。
4. 勇气（Courage）
   • 敢于重构不良代码、删除冗余功能、调整架构。
   • 技术支撑：自动化测试覆盖率保障重构安全性。
5. 尊重（Respect）
   • 团队成员互相认可技术贡献，客户尊重开发专业性。

---

3. XP的十二项核心实践（技术聚焦）

3.1 关键开发实践

1. 测试驱动开发（TDD）

   • 流程：红 → 绿 → 重构循环
     1. 编写失败的单元测试（红）；
     2. 编写最小代码使测试通过（绿）；
     3. 优化代码结构，保持测试通过（重构）。
   • Java工具链：JUnit 5 + Mockito + AssertJ + JaCoCo（覆盖率检测）。
   • 优势：强制明确需求边界，代码可测性高。

2. 持续集成（CI）

   • 流程：每日多次提交代码 → 自动构建 → 运行测试 → 部署到测试环境。
   • Java工具链：Jenkins/GitHub Actions + Maven/Gradle + SonarQube（代码质量分析）。
   • 关键指标：构建成功率、测试覆盖率、静态检查警告数。

3. 重构（Refactoring）

   • 原则：在不改变外部行为的前提下优化代码结构。
   • Java实践：
     • IDE支持：IntelliJ IDEA的重构工具（提取方法、内联变量等）。
     • 模式应用：用策略模式替代条件分支、用Stream API重构循环。
   • 安全保障：依赖TDD和自动化测试。

4. 简单设计（Simple Design）

   • 四原则：
     1. 通过所有测试；
     2. 无重复代码（DRY原则）；
     3. 清晰表达意图（命名规范）；
     4. 最小化类与方法数量。
   • 反例警示：避免过早引入抽象工厂、复杂设计模式。

3.2 协作与管理实践

5. 结对编程（Pair Programming）

   • 角色：驾驶员（写代码） + 领航员（审查与设计）。
   • 效率提升点：
     • 减少低级错误（如NPE、并发问题）。
     • 知识共享，避免技术债集中。
   • Java场景：复杂算法实现、并发代码调试、框架深度集成。

6. 用户功能（User Function）

   • 格式：As a [角色], I want [功能], so that [价值]。
   • 拆分原则：遵循INVEST（Independent, Negotiable, Valuable, Estimable, Small, Testable）。
   • Java示例：
     • 故事：“作为用户，我希望通过JWT令牌登录，以便安全访问API。”
     • 技术任务：集成Spring Security + JWT、编写过滤器、设计Token刷新机制。

7. 小型发布（Small Releases）

   • 周期：1-2周交付可运行版本，优先实现高价值功能。
   • Java微服务场景：通过Spring Boot Actuator暴露健康检查接口，分阶段发布API端点。

---

4. XP在Java项目中的典型应用场景

1. 高变化需求项目

   • 示例：快速试错的互联网产品，需求随市场反馈调整。
   • 技术适配：Spring Boot的模块化设计 + 动态配置中心（如Spring Cloud Config）。

2. 强质量要求的金融系统

   • 示例：交易引擎开发，需确保代码零缺陷。
   • 技术栈：TDD + JaCoCo（覆盖率>80%）+ SpotBugs静态分析。

3. 分布式团队协作

   • 工具支持：Git（分支策略） + JIRA（功能跟踪） + Zoom（远程结对编程）。

---

5. XP的优缺点分析

优势

• 代码质量卓越：TDD和重构保障可维护性。
• 快速响应变化：用户故事和迭代发布降低需求偏差风险。
• 团队技术成长：结对编程促进知识传递。

挑战

• 学习曲线陡峭：TDD和重构需要严格纪律。
• 初期效率损耗：编写测试和配对沟通增加时间成本。
• 客户参与依赖：需客户深度配合用户故事细化。

---

6. Java工程师的XP实施建议

1. 渐进式采用：从TDD和CI入手，逐步引入其他实践。
2. 工具链标准化：统一团队IDE、构建工具、测试框架。
3. 代码评审重点：
   • 检查测试覆盖率（如JaCoCo报告）。
   • 识别重复代码（使用SonarQube的CPD检测）。
4. 技术债管理：
   • 定期分配“重构Sprint”。
   • 使用ArchUnit验证架构约束。

---

7. XP与Scrum的差异（Java视角）

维度	XP	Scrum
核心目标	代码质量与工程实践	项目管理与迭代交付
技术规范	强制TDD、结对编程	无强制技术实践
迭代周期	1-2周（更短）	2-4周
适用场景	高复杂度、高质量要求的代码密集型项目	需求优先级频繁变更的业务型项目

---

总结

1. “极限”的真实含义：实践强度的极致化

• 技术实践的极限：
  • 测试驱动开发（TDD）：要求100%覆盖核心逻辑的测试代码，且测试编写先于生产代码。
  • 持续集成（CI）：每日多次集成代码并运行全量测试，缺陷存活时间不超过1小时。
  • 结对编程：关键代码必须双人协作，实时审查与知识共享强度拉满。
• 协作模式的极限：
  • 客户全程参与：需求方与开发团队每日同步，需求澄清零延迟。
  • 全功能团队：开发者、测试者、客户代表无壁垒协作，信息流转效率最大化。

---

2. “速度”的本质：减少浪费，而非压缩时间

• 速度 ≠ 加班：
  XP明确反对透支团队精力，强调可持续节奏（如每周40小时工作制）。其“快速”体现在：
  • 缺陷预防：通过TDD和结对编程，将Bug消灭在编码阶段，避免后期调试耗时。
  • 需求对齐：客户持续反馈，减少因误解导致的返工（据统计，传统开发中约30%时间用于修正需求偏差）。
• 案例对比：
  • 传统团队：2周编码 → 1周测试 → 发现重大缺陷 → 返工3天 → 总耗时3.3周。
  • XP团队：2周内完成编码+测试+小步发布 → 缺陷接近零 → 总耗时2周。
  • 关键差异：XP通过前期质量投入，规避了传统模式的“返工黑洞”。

一句话总结

极限编程可以理解为极限是测试开发客户协作的极限，即开发完最快甚至边开发边测试，避免因为缺陷导致返工，同时也是客户深度参与的极限，避免因为需求沟通不清楚导致的返工。是最大限度避免返工问题出现的极限。

或者说是开发、测试、需求、客户之间沟通协作的极限。用最大的可能避免返工问题。
以此来缩短开发时间。如果你是开发人员你可以想象一个场景，你左边是客户，右边是需求。
给你讲完需求之后，测试人员坐在你身后等你开发完进行测试，并且是一直等。
可能也不止一个测试人员，完全覆盖可能是几个测试人员反复交叉测试。
有bug随时改。反正想想就很极限了。

---

水晶法 （Crystal ）

1. Crystal的本质与核心思想

Crystal是由Alistair Cockburn提出的敏捷方法论家族，其核心理念是**“方法论必须适配团队特性，而非强制团队适应方法论”。它摒弃“一刀切”的流程，强调根据项目规模、关键性、团队分布等维度动态调整实践，属于轻量级敏捷框架**。

• 核心原则：
  1. 流动性（Fluidity）：方法论应像水一样适应项目容器。
  2. 增量式演进：从最小可行流程（Crystal Clear）起步，随项目复杂度升级（如→Crystal Orange→Crystal Red）。
  3. 以人为本：沟通效率 > 流程合规性，尤其适合高技能、自组织团队。

---

2. Crystal家族方法论（按项目规模分类）

方法论变种	团队规模	典型项目类型	Java项目示例
Crystal Clear	1-6人	低风险、需求变化快的创新项目	初创公司内部工具开发（如基于Spring Boot的CMS系统）
Crystal Yellow	7-20人	中等规模商业应用	电商平台后端服务（分布式微服务架构）
Crystal Orange	21-50人	跨部门协作的企业级系统	银行核心交易系统（高并发、强一致性要求）
Crystal Red	50-100人	多团队协作的复杂产品	航空订票系统（全球分布式团队协作）

---

3. Crystal Clear的核心实践（适用于小型Java团队）

3.1 核心机制

• 定期反思（Reflection Workshop）
  每1-2周召开会议，讨论流程改进点（如优化CI/CD流水线、调整代码评审规则）。

  • Java场景：发现Lombok滥用导致代码可读性下降 → 团队投票决定限制@Data注解使用。

• 渗透式沟通（Osmotic Communication）
  通过物理共处或虚拟开放频道（如Slack/钉钉群）实现信息自然流动。

  • 案例：团队成员在群内实时讨论Spring Cloud Config的热更新问题，快速达成解决方案。

• 增量交付（Incremental Delivery）
  每1-3个月交付可运行版本，优先实现核心业务流。

  • 技术实现：使用Spring Boot Actuator暴露API健康检查接口，逐步开放功能开关。

3.2 轻量级工件

• 项目地图（Project Map）
  可视化当前任务与目标的关系，通常用白板或JIRA看板实现。

  • Java示例：按模块划分看板列（认证服务→订单服务→支付服务），标注技术依赖（如Redis集成风险点）。

• 风险列表（Risk List）
  动态维护技术与非技术风险，按优先级处理。

  • 典型Java风险项：
    • 技术债：MyBatis动态SQL未防注入（需引入SQL过滤插件）。
    • 外部依赖：第三方支付接口SLA不达标（需设计降级策略）。

---

4. Crystal与其他敏捷方法的对比（Java视角）

维度	Crystal	Scrum	极限编程（XP）
流程刚性	高度灵活，可定制	固定角色/事件（如Sprint）	工程实践严格（如必须TDD）
技术规范	无强制技术实践	无强制技术实践	强制TDD、持续集成、结对编程
适用团队规模	明确分阶（Clear→Red）	适合中小团队（5-9人）	适合小团队（2-10人）
文档要求	轻量文档，强调口头沟通	需维护Product Backlog	测试代码即文档
Java适配性	适合架构探索期项目	适合需求明确的中长期项目	适合高质量要求的核心模块开发

---

5. Crystal在Java项目中的落地挑战与对策

5.1 常见挑战

• 过度自由导致无序：团队缺乏自律时易陷入“无流程”混乱。
  对策：从Clear的基础实践（如每日站会、迭代回顾）强制启动，逐步释放灵活性。

• 分布式团队沟通损耗：渗透式沟通依赖共处环境。
  对策：

  • 使用Miro虚拟白板同步项目地图。
  • 设立每日1小时“重叠工作时间”进行实时讨论。

• 技术债务积累：缺乏XP的严格工程规范。
  对策：

  • 在回顾会议中引入代码质量指标（SonarQube报告）。
  • 约定代码审查规则（如PR必须关联JIRA任务）。

5.2 成功案例：金融数据中台项目

• 背景：8人Java团队开发实时风控引擎，需求频繁变更。
• Crystal实践：
  1. Clear基础框架：每日站会 + 双周迭代交付。
  2. 定制化扩展：
     • 增加“技术尖兵”角色，负责Kafka性能调优（非固定角色，由资深工程师轮值）。
     • 使用ArchUnit约束包依赖，替代传统架构文档。
• 成果：需求响应速度提升40%，生产环境重大事故归零。

---

6. 何时选择Crystal？——Java团队决策指南

✅ 适合场景：

• 需求模糊且变化频繁的创新项目（如区块链中间件开发）。
• 团队成员技术能力强，厌恶流程束缚。
• 需要快速验证技术可行性（如评估Quarkus vs Spring Boot）。

❌ 不适合场景：

• 强合规性要求的领域（如医疗软件，需完整审计追踪）。
• 团队成员自律性差，需外部流程驱动。
• 超大规模系统（百人以上团队建议SAFe或LeSS）。

---

7. 总结

1. Crystal的“自由”本质：有限制的灵活性

(1) 自由的表现形式

• 流程可裁剪：
  不强制要求固定仪式（如Scrum的Sprint计划会），允许团队根据项目阶段动态调整。

  • Java示例：在开发Spring Boot微服务初期，团队可跳过每日站会，聚焦技术预研；进入稳定迭代后，再引入站会同步进度。

• 角色非固定：
  无严格定义的Scrum Master或PO，鼓励成员根据能力自然承担职责。

  • 场景：资深Java工程师可兼任技术协调员，主导代码规范制定，而产品经理负责需求优先级排序。

• 文档轻量化：
  强调面对面沟通而非长篇文档，但需保留核心决策记录。

  • 工具替代：用Swagger自动生成API文档，用ArchUnit代码测试替代架构设计文档。

(2) 自由的边界条件

• 必须遵守的“核心约束”：

  约束项	说明	Java场景示例
  增量交付	定期交付可运行软件（通常≤3个月）	每季度发布一个可独立部署的Spring Cloud微服务模块
  持续反思	定期回顾会优化流程	双周会议讨论如何优化Jenkins流水线构建速度
  渗透式沟通	确保信息透明流动	使用钉钉群同步生产环境事故处理进展
  风险可视化管理	动态维护风险清单	记录Elasticsearch集群扩容的技术风险及应对方案

---

2. “自觉性”的真实含义：自组织能力模型

Crystal假设团队具备成人学习者的成熟度，其自觉性体现在三个维度：

(1) 技术自觉性

• 代码规范自治：
  团队自主制定并遵守规则，如：
  • 禁止Java中的System.out日志输出，强制使用SLF4J。
  • MyBatis SQL文件必须存放在src/main/resources/mapper目录下。
• 技术债务管理：
  主动识别和偿还债务，而非等待外部指令。例如：
  • 发现Spring Bean循环依赖 → 立即重构为事件驱动模式。

(2) 流程自觉性

• 动态调整机制：
  根据项目状态主动优化流程。例如：
  • 当微服务数量超过10个时，从Crystal Clear升级到Crystal Yellow，引入跨团队协调会。
• 风险预警文化：
  成员自发标记风险而非隐瞒问题。如：
  • 提前预警Hystrix停更对现有熔断机制的影响，推动迁移至Resilience4j。

(3) 协作自觉性

• 无指令协同：
  开发者主动补位，如：
  • 前端阻塞在API调试 → 后端工程师主动提供Postman用例集。
  • 发现同事代码存在线程安全问题 → 提交PR修复而非等待他人处理。

---

3. 自由与自觉的共生关系

(1) 正向循环

高自觉性团队 → 享受更多流程自由 → 减少形式主义消耗 → 效率提升 → 正向激励自觉性

(2) 崩溃场景

低自觉性团队 → 滥用自由导致无序 → 质量/进度失控 → 加强管控 → 团队自主性进一步下降

(3) 典型案例对比

团队类型	流程选择	Java项目结果
高自觉性团队	Crystal Clear（最小约束）	6人3个月完成电商平台核心交易系统，代码整洁度SonarQube A级
低自觉性团队	强行套用Crystal	需求频繁变更导致模块接口混乱，Spring Bean依赖冲突频发，项目延期50%

---

4. 如何判断团队是否适合Crystal？

(1) 自检清单

• 团队成员是否具备以下特质：

  • 主动沟通问题而非掩盖（如提前暴露Spring事务管理缺陷）。
  • 在无监管情况下仍遵循代码规范（如Checkstyle规则）。
  • 能自主拆分复杂任务（如将“支付系统重构”分解为可并行子任务）。

• 项目是否具备以下条件：

  • 需求模糊但创新空间大（如探索AI模型与Java后端的集成）。
  • 技术栈成熟度高，无需频繁学习新框架（如已稳定使用Spring生态）。

(2) 过渡期训练建议

对自觉性不足的团队，可逐步实施：

1. 引入轻量Scrum：
   • 保留站会和回顾会，培养定期同步习惯。
   • 示例：每日15分钟站会同步Spring Boot服务开发进展。
2. 代码审查自动化：
   • 通过GitHub Actions强制执行Checkstyle、SpotBugs检查。
3. 风险可视化试点：
   • 使用JIRA看板公开技术债务，鼓励成员主动认领。

5.一句话总结

水晶法 Crystal是比较适合成熟的团队，尤其是团队中的人能承担多种角色可以主动的随时补位的那种，然后比较关注项目的关键交付节点，比如第一季度目标是否能如期达成这种较为长期的目标。（只要只有一个句号就是一句话，哈哈哈哈。）

---

并列争求法（Scrum）

---

1. Scrum的本质与核心思想

Scrum是一种迭代增量式敏捷框架，通过固定周期（Sprint）交付潜在可发布的软件增量，强调透明性、检视与适应。其名称源于橄榄球运动中的“争球”场景，寓意团队围绕目标紧密协作。对Java开发而言，Scrum提供了一套可落地的协作范式，尤其适合需求优先级频繁变化的项目（如互联网应用、企业级中间件开发）。

---

2. Scrum的核心组成

2.1 三大角色

角色	职责与Java场景示例
产品负责人（PO）	- 维护产品待办列表（Product Backlog），确定需求优先级。 - 示例：决定优先实现Spring Cloud微服务鉴权模块还是订单分布式事务。
Scrum Master	- 移除团队障碍，确保流程执行。 - 示例：协调运维团队为Java应用搭建Kubernetes测试环境。
开发团队	- 跨职能自组织团队（5-9人为宜）。 - 示例：Java后端 + 前端 + 测试工程师协作完成用户故事。

2.2 五大事件

事件	目标与Java实践
Sprint计划会	- 确定Sprint目标并拆解任务。 - 技术准备：评估技术可行性（如Elasticsearch集群搭建耗时）。
每日例会	- 15分钟同步进展/障碍。 - 示例：“昨日完成支付接口开发，今日联调时发现Spring事务传播问题需解决。”
Sprint评审会	- 演示可交付增量。 - 展示内容：Spring Boot Actuator监控指标、Swagger API文档。
Sprint回顾会	- 改进流程与工具链。 - 典型议题：优化Jenkins构建速度、引入SonarQube代码质量门禁。
Sprint（核心）	- 固定周期（2-4周）完成承诺任务。 - Java团队产出：可独立部署的JAR包 + 自动化测试报告。

2.3 三大工件

工件	内容与Java管理工具
产品待办列表	- 用户故事 + 技术任务。 - 工具示例：JIRA + Confluence（关联技术方案文档）。
Sprint待办列表	- 当前迭代的细化任务（含工作量估算）。 - 示例：使用故事点（Story Point）评估MyBatis迁移至JPA的复杂度。
增量（Increment）	- 达到“完成定义”（DoD）的可交付物。 - Java标准：通过所有测试 + 代码审查 + 生产就绪Docker镜像。

---

3. Scrum在Java项目中的落地实践

3.1 用户功能拆分技巧

• INVEST原则：

  • Independent：避免功能间技术耦合。
    • 反例：“重构用户服务与订单服务的数据库连接池” → 拆分至不同Sprint。
  • Testable：定义明确验收条件。
    • 示例：“用户登录成功”需满足：
      1. 返回JWT令牌（使用JJWT库生成）。
      2. 记录登录日志至MongoDB。

• 技术故事管理：
  将技术债务转化为可估算的故事。

  • 示例故事：“将日志框架从Log4j 1.x升级至Log4j2，解决线程阻塞问题”（估算：5故事点）。

3.2 Sprint执行关键点

• 每日构建（Daily Build）：

  • 流程：代码提交 → 触发Jenkins流水线 → 运行单元测试 → 部署至测试环境。
  • 质量门禁：单元测试覆盖率≥80%（JaCoCo报告）、无Checkstyle错误。

• 结对编程（可选）：

  • 适用场景：复杂算法实现（如分布式锁Redisson优化）、核心模块开发（支付对账逻辑）。

• 缺陷零容忍策略：

  • 发现Bug → 立即创建任务加入当前Sprint Backlog → 优先于新功能开发。

3.3 典型Java工具链

环节	推荐工具	集成示例
需求管理	JIRA + Confluence	用户故事关联Swagger API设计文档
代码质量	SonarQube + Checkstyle	Maven构建时自动执行代码规范检查
持续集成/交付	Jenkins + Ansible	自动部署Spring Boot应用到K8s集群
监控运维	Prometheus + Grafana	监控JVM堆内存、Tomcat线程池状态
文档生成	Swagger + MkDocs	自动化生成API文档并托管至内部Wiki

---

4. Scrum与极限编程（XP）的工程实践对比

维度	Scrum	极限编程（XP）
流程核心	项目管理框架	工程实践集合（TDD/持续集成等）
技术强制性	无强制技术规范	必须执行TDD、结对编程等
迭代长度	通常2-4周	通常1-2周
适用场景	需求优先级变化频繁的项目	高质量要求且需求相对稳定的核心模块
Java适配重点	团队协作与交付节奏管理	代码质量与架构可持续性

---

5. Scrum常见挑战与解决方案（Java视角）

5.1 需求蔓延（Scope Creep）

• 现象：PO在Sprint中频繁添加新需求，导致团队超载。
• 解决方案：
  • 严格遵循Sprint目标：变更需求仅限致命缺陷或合规要求。
  • 技术影响评估：例如新增需求需调用第三方OCR服务 → 评估HttpClient连接池配置调整。

5.2 技术债务累积

• 现象：为赶进度跳过代码审查，导致架构腐化。
• 解决方案：
  • 定义DoD（完成标准）：必须通过SonarQube质量门禁。
  • 技术债务看板：在JIRA中可视化技术任务，PO参与优先级排序。

5.3 分布式团队协作

• 现象：跨时区团队会不同步，代码集成冲突频发。
• 解决方案：
  • 异步站会：使用Slack每日提交进度报告（模板：昨日进展/今日计划/阻塞问题）。
  • 分支策略优化：采用GitFlow + 特性开关（Feature Toggle），减少主干冲突。

---

6. 成功案例：电商平台订单系统重构

• 背景：
  • 遗留系统：单体Spring MVC应用，订单处理延时高。
  • 团队：7人（Java后端4人 + 前端2人 + 测试1人）。
• Scrum实践：
  1. Sprint规划：2周迭代，首阶段聚焦订单服务拆分与性能压测。
  2. 技术决策：
     • 采用Spring Cloud Alibaba + RocketMQ实现异步削峰。
     • 使用JMeter制定基准性能测试（5000TPS）。
  3. 成果：
     • 6个Sprint后，核心服务响应时间从2s降至200ms。
     • 生产环境P0级故障下降90%。

---

7. 何时选择Scrum？——Java团队决策指南

✅ 适用场景：

• 需求变化频繁的互联网产品（如社交APP后端）。
• 中大型团队（5-20人）需明确分工协作。
• 客户期望定期可见进展（如融资路演前需MVP版本）。

❌ 不适用场景：

• 超短期项目（<2周）或需求完全固定的外包开发。
• 技术研究型项目（如AI算法预研，无法拆解为明确故事）。
• 团队成员缺乏自组织意识（需强指令管理）。

---

总结

1. Scrum应对需求变更的核心机制

(1) Sprint的“时间盒”保护

• 规则：每个Sprint（通常2-4周）锁定目标，期间PO不得变更当前Sprint Backlog。
• 价值：确保团队在当前迭代内专注交付，避免因频繁切换任务导致上下文丢失与效率损耗。

(2) 产品待办列表（Product Backlog）的动态排序

• 规则：PO在每个Sprint结束后，根据市场变化重新排序待办列表，决定下一迭代目标。
• 价值：优先级调整被控制在迭代边界，且变更基于最新业务洞察。

---

2. 场景模拟：功能A → 功能B的优先级切换

初始条件：

• 团队速率：每个Sprint可完成5个故事点（假设1故事点≈1人天）。
• 功能拆解：
  • 功能A = 用户身份验证（需5故事点，拆分为：手机登录 + 微信登录 + 令牌刷新）。
  • 功能B = 支付对接（需5故事点，拆分为：支付宝 + 微信支付 + 对账逻辑）。
• 原始计划：
  • Sprint 1：完成功能A（手机登录3点 + 微信登录2点）。
  • Sprint 2：完成功能A剩余部分（令牌刷新2点） + 功能B（支付宝3点）。

变更触发：

• Sprint 1结束后，PO因市场策略调整，要求下一迭代优先完成功能B（支付对接）。

Scrum处理流程：

1. Sprint 1评审会：

   • 交付成果：手机登录 + 微信登录（功能A核心部分已上线）。
   • PO确认：剩余令牌刷新（2点）优先级降低，移出下一迭代。

2. Sprint 2计划会：

   • 新目标：完成支付对接高优先级部分（支付宝3点 + 对账逻辑2点）。
   • 技术评估：对账逻辑依赖支付宝接口，故需前置开发。

3. Sprint 2交付：

   • 输出：支付宝支付 + 对账逻辑（功能B部分可用）。
   • 业务价值：即使功能A未100%完成，但核心登录能力已支持用户使用；同时支付功能部分上线，满足紧急业务需求。

---

3. 关键策略：如何避免“延期”错觉？

(1) 需求拆解为最小可交付单元（MVF）

• 原则：每个用户故事必须独立交付价值，避免“全有或全无”式开发。
  • 错误拆解：功能A作为一个不可分割的“大需求”（必须全部完成才能上线）。
  • 正确拆解：将功能A分解为多个可独立发布的子功能（如先支持手机登录，后续迭代增加微信登录）。

(2) 基于价值的优先级排序

• PO的决策逻辑：
  • 比较功能A的令牌刷新与功能B的支付宝对接，评估业务收益：
    • 令牌刷新：优化用户体验，但已有手机登录可满足基本需求。
    • 支付宝对接：直接带来收入增长。
  • 结论：优先开发支付宝对接，即使功能A未彻底完成。

(3) 持续交付可用增量

• 结果度量：
  • 传统模式：3个月后一次性交付功能A+B → 风险集中，延期则价值归零。
  • Scrum模式：每2周交付部分可用功能 → 即使最终未完成全部需求，已交付部分仍可产生价值。

---

一句话总结

Scrum 是把大功能拆分成一个个小功能点，然后把每个小功能点按照优先级排期，同时在一个任务周期内，即使优先级变化也尽可能在完成当前任务的情况下，把剩余的功能按照新的优先级排序进行开发，由于每个任务的开发周期都相对较短，所以把下一个任务按照新的优先级去处理不会对现有的功能开发有太大的影响。

---

1. Scrum：

   • 通过短周期（Sprint，通常2-4周）迭代开发。
   • 角色：产品负责人（PO）、Scrum Master、开发团队。
   • 关键会议：计划会、每日站会、评审会、回顾会。
   • 工具：产品待办列表（Product Backlog）、冲刺待办列表（Sprint Backlog）。

2. Kanban（看板）：

   • 可视化工作流（如“待办-进行中-完成”）。
   • 限制在制品（WIP）数量，优化流程效率。
   • 持续交付，无固定迭代周期。

3. 其他方法：极限编程（XP）、精益开发（Lean）、动态系统开发方法（DSDM）等。

---

---

自适应软件开发（ASD）

---

1. ASD的本质与核心思想

自适应软件开发（Adaptive Software Development, ASD）由Jim Highsmith提出，是敏捷方法论的早期代表，专为高不确定性、高复杂度项目设计。其核心哲学是**“拥抱变化而非抵抗变化”，强调通过持续学习与动态调整应对不可预测的需求和技术挑战。ASD特别适用于创新型产品开发**（如AI平台、区块链中间件）或遗留系统重构场景。

---

2. ASD三大核心阶段

阶段	目标	Java工程实践示例
推测（Speculate）	制定初步计划，接受其不确定性	使用领域驱动设计（DDD）划分限界上下文，定义Spring Boot微服务边界
协作（Collaborate）	跨职能团队紧密协作，共创解决方案	通过Event Storming工作坊对齐业务与技术人员，设计JPA实体关系
学习（Learn）	通过短周期迭代验证假设并调整方向	每2周演示可运行增量，利用JaCoCo测试覆盖率数据优化代码质量

---

3. ASD六大指导原则

1. 持续适应（Continuous Adaptation）

   • 实践：在Java项目中采用模块化架构（如Spring Boot Starter），便于快速替换组件。
   • 案例：发现MyBatis性能瓶颈后，一周内迁移至JPA + QueryDSL。

2. 基于使命的决策（Mission-Driven）

   • 实践：用OKR（目标与关键结果）替代详细需求文档。
   • 示例：目标“提升订单系统吞吐量至5000 TPS”，技术方案自主选择（Kafka异步处理 vs 数据库分片）。

3. 风险优先（Risk-Driven）

   • 实践：使用风险列表（Risk Backlog）管理技术债务。
   • 工具：SonarQube标记高严重性代码异味，优先处理阻塞持续集成的风险项。

4. 时间盒迭代（Timeboxed Iterations）

   • 节奏：固定1-3周迭代周期，强制产出可交付增量。
   • Java工具链：Jenkins流水线实现每日构建，确保每次提交生成可部署的Docker镜像。

5. 基于组件的架构（Component-Based）

   • 架构规范：通过Java模块系统（JPMS）或Spring Boot Starter实现高内聚低耦合。
   • 案例：将用户鉴权功能封装为独立JAR，供多个微服务引用。

6. 质量内建（Quality Focused）

   • 策略：测试左移 + 代码静态分析。
   • 工具链：JUnit 5（单元测试） + Testcontainers（集成测试） + ArchUnit（架构约束测试）。

---

4. ASD vs 其他敏捷方法（Java项目视角）

维度	ASD	Scrum	极限编程（XP）
核心焦点	应对不确定性，强调学习与适应	迭代交付与优先级管理	工程实践与代码质量
需求处理	动态任务列表（Feature List）	产品待办列表（Product Backlog）	用户故事（User Story）
技术强制	无强制技术规范，鼓励架构探索	无强制技术规范	强制TDD、结对编程
适用项目类型	高创新性、技术复杂度高的项目	需求频繁变更的业务型项目	代码质量要求极高的核心模块
Java适配重点	模块化架构 + 动态依赖管理	团队协作与持续交付流程	测试覆盖率与重构纪律

---

5. ASD在Java项目中的落地实践

5.1 推测阶段：轻量级架构决策

• 技术预研模板：

  ## 技术选型：分布式事务方案
  - **需求背景**：订单服务需调用库存服务与支付服务，保证数据一致性
  - **候选方案**：
    1. Seata AT模式（基于XA协议）
    2. 消息队列最终一致性（RocketMQ事务消息）
  - **验证计划**：
    - 搭建Spring Cloud + Seata测试环境（2人日）
    - 编写JMeter压测脚本（1人日）
  - **决策标准**：吞吐量 > 1000 TPS，端到端延迟 < 200ms
  

5.2 协作阶段：实时知识共享

• 协作工具链：
  • 代码协作：GitLab Merge Request + SonarQube门禁检查
  • 设计协作：PlantUML生成架构图，嵌入JavaDoc
  • 问题追踪：JIRA看板同步技术风险与解决方案

5.3 学习阶段：迭代回顾模板

## 迭代#3回顾报告（2023Q3）
- **交付成果**：
  - 订单服务吞吐量提升至4200 TPS（目标5000）
  - 集成RocketMQ事务消息实现最终一致性
- **关键学习**：
  - RocketMQ事务消息在Spring Cloud中需自定义事务监听器
  - HikariCP默认配置不适合高并发场景，需调整maxPoolSize
- **调整计划**：
  - 下迭代优先优化数据库连接池配置
  - 引入Redisson分布式锁解决库存超卖问题

---

6. ASD典型挑战与解决方案

挑战1：过度灵活导致方向迷失

• 现象：团队频繁调整技术方案，架构稳定性受损
• 解决方案：
  • 定义架构护城河：核心模块必须通过ArchUnit测试
  • 设立技术锚点：每季度评审一次基础架构（如Spring Cloud版本升级策略）

挑战2：分布式团队协作低效

• 现象：跨时区团队难以实时协作
• 解决方案：
  • 异步沟通规范：
    • 设计文档使用Confluence + 评论功能
    • 代码审查通过GitLab异步完成，24小时内响应
  • 重叠工作时间：每日设置2小时全球团队在线时段

挑战3：技术债务积累

• 现象：为快速交付牺牲代码质量
• 解决方案：
  • 质量门禁自动化：
    • Maven构建失败条件：单元测试覆盖率<80% || SonarQube阻断问题>0
  • 技术债务预算：每个迭代分配20%时间处理债务

---

7. 成功案例：供应链金融平台重构

• 背景：
  • 遗留系统：单体Struts应用，技术栈陈旧
  • 目标：转型为Spring Cloud微服务架构，支持千万级订单处理
• ASD实践：
  1. 推测阶段：通过DDD划分出“风控”、“交易”、“合规”等限界上下文
  2. 协作阶段：
     • 使用C4 Model绘制架构图
     • 采用TLA+形式化验证分布式事务算法
  3. 学习阶段：
     • 每两周演示可运行模块（如独立的风控服务）
     • 根据压力测试结果调整Kubernetes Pod资源配置
• 成果：
  • 9个月完成核心服务重构，TPS从200提升至3500
  • 生产环境P0级故障下降75%

---

8. 何时选择ASD？——Java团队决策指南

✅ 适用场景：

• 技术探索型项目（如评估Quarkus与Spring Boot的GraalVM支持）
• 需求高度不确定的创新产品（如元宇宙社交平台后端）
• 复杂遗留系统现代化改造（单体→微服务架构迁移）

❌ 不适用场景：

• 需求明确的外包交付项目
• 强合规性领域（如医疗设备控制软件）
• 团队成员缺乏自组织能力

---

总结

1. ASD的“不确定”本质：探索性创新，非无序混乱

(1) 不确定性的边界

• 允许不确定的领域：
  • 技术方案（如选择Kafka还是RabbitMQ实现消息队列）
  • 需求细节（如用户对AI推荐算法的偏好需通过MVP验证）
• 必须确定的锚点：
  • 核心业务目标：如“构建一个支持千万级并发的电商平台”
  • 架构原则：如“微服务间通信必须通过API Gateway”
  • 质量基线：如“单元测试覆盖率≥80%，生产事故恢复时间<5分钟”

(2) 技术栈多样性的风险控制

• 模块化隔离：
  不同技术栈仅限独立模块内使用，避免交叉影响。
  • 示例：
    • 使用Spring Boot开发核心订单服务（强类型保障）
    • 用Python + TensorFlow实现推荐算法（快速实验）
    • 通过gRPC协议隔离两者，技术栈差异不影响整体系统
• 技术雷达机制：
  定期评估新技术可行性，如每季度评审是否引入Quarkus替代部分Spring Boot服务。

---

2. 方案调整的纪律性流程

(1) 方案变更触发条件

变更类型	触发条件	Java项目示例
技术方案替换	原方案无法满足性能/扩展性要求	从EhCache切换至Redis Cluster应对缓存击穿问题
架构模式调整	业务需求发生根本性变化	从单体架构重构为Spring Cloud微服务
需求优先级重排	市场验证显示当前功能价值低于预期	暂停开发积分系统，转向优惠券秒杀功能

(2) 变更控制流程

1. 影响评估：
   • 技术影响：如替换ORM框架需重写DAO层，估算工作量（如从MyBatis迁移至JPA需3人周）
   • 业务影响：如延迟交付是否影响客户合同
2. 决策会议：
   • 参与者：架构师、PO、核心开发
   • 产出物：新方案原型代码（如用WebClient替换RestTemplate的Demo）
3. 迭代计划调整：
   • 将变更任务加入下一迭代Backlog，重新估算优先级

---

3. 交付节奏的“结构化灵活”

(1) 时间盒管理

• 强制节奏：
  每个迭代（通常2-3周）必须产出可演示的增量，但允许交付内容调整。
  • 示例：
    • 迭代1计划：完成用户注册功能（Spring Security集成）
    • 实际交付：基础注册+手机验证码登录（因短信服务对接延迟，放弃邮箱注册）
    • 仍符合要求：交付物可独立运行且产生业务价值

(2) 阶段汇报的深度要求

• 汇报内容标准：

  要素	示例（Java项目）
  可运行功能	提供Swagger文档及Postman测试集合
  质量指标	提交SonarQube报告（无阻断问题，覆盖率达标）
  技术决策依据	展示JMeter压测对比数据（如Redis vs Memcached）
  下一阶段目标	明确下迭代将优化JVM GC参数，提升吞吐量

• 反例警示：
  仅提交未集成的代码仓（无法启动）或未验证的算法设计（无性能数据）视为未完成迭代。

---

一句话总结

自适应软件开发（ASD）是要做一个目标明确的新产品，但是这个过程中不强制限制每个模块的技术，在尽可能保持技术栈统一的情况下，允许各个模块在一定的控制下探索新的技术实现方式，但是会对各个模块之间的通信和某些基础依赖比如Java版本等做出明确规定，这个过程当中，一旦某个模块的方案实现不了换新的方案或者重新讨论。同时这个过程中没有精确的交付的时间点，但是会有一个短周期的汇报，需要每次汇报都有新的进展。

---

优点

• 快速适应变化：需求变更时能灵活调整。
• 减少风险：通过持续交付验证方向，避免后期大范围返工。
• 客户参与度高：客户或用户可全程反馈，确保产品符合预期。
• 提升团队效率：短周期目标明确，团队专注度高。

---

适用场景

• 需求不明确或频繁变化的项目（如互联网产品）。
• 需要快速验证市场假设的初创项目。
• 强调跨职能协作的团队。

---

挑战

• 依赖团队自律和高效沟通。
• 对客户或产品负责人的参与度要求高。
• 不适合需求极其固定或监管严格的领域（如航天软件）。

---

总结

敏捷开发是“小步快跑，持续改进”的协作模式，目标是通过快速迭代和灵活调整，交付真正有价值的软件。