illegalCreed

中文

English

中文

English

Appearance

指南 ​

基于《敏捷宣言》原文（agilemanifesto.org，2001）与 12 条原则（agilemanifesto.org/principles.html）编写

速查 ​

  • 4 价值观的试金石：「左>右」非「左弃右」，宣言明文「尽管右项有其价值，我们更重视左项」
  • 价值观一（以人为本）：流程与工具是手段，个体判断与跨职能互动是源头
  • 价值观二（可用软件）：可运行的软件比纸面文档更能验证方向，文档服务于沟通而非替代品
  • 价值观三（客户协作）：用持续协作替代对立式合同谈判，把客户拉进开发回路
  • 价值观四（响应变化）：计划是滚动的、可自适应的，而非一次性冻结
  • 原则主线：早交付（1/3）、欢迎变化（2）、每日协作（4）、自组织（5/11）、面对面（6）、可用软件度量（7）、可持续节奏（8）、技术卓越（9）、简洁（10）、反思改进（12）
  • 工程实践：TDD、持续集成、重构、结对——这些是「敏捷能持续」的工程底座（源自 XP）
  • 计划方法：滚动式计划（近期细、远期粗）+ 估算用于容量规划而非承诺
  • 敏捷工程纪律：没有自动化测试的「拥抱变化」= 持续制造技术债
  • 反敏捷信号：站会变汇报、回顾变甩锅、估算变承诺、迭代无 Definition of Done
  • 规模化困境：单团队敏捷顺，多团队需 SAFe/LeSS/Nexus；扩展框架引入复杂度，慎用
  • 核心共识：敏捷是价值观不是流程，落地要贴合团队上下文，工程能力是地基

4 价值观深度解读 ​

价值观一：个体与互动 高于 流程与工具 ​

这条针对的是「把人当资源、把流程当万能药」的倾向。工具（Jira、Confluence、CI）和流程（变更审批、门禁）能提升一致性，但软件最终由有判断力的人做出。当流程压制了人的判断（如一个明显错误的变更要等 3 天审批），或工具定义了工作方式（如「Jira 里没建的任务不许做」导致紧急修复被阻塞），就违背了这条价值观。

落地含义：跨职能小团队（开发 + 测试 + 设计坐一起）、面对面或实时沟通优先、决策权下放给离信息最近的人。

价值观二：工作的软件 高于 详尽的文档 ​

这是最常被误读的一条。宣言没有否定文档，它说的是「优先级」——能跑的软件比 200 页设计稿更能验证需求是否正确。文档的正当性在于「促进理解与协作」，而非「作为交付物的形式合规」。

落地含义：每个迭代产出可演示的增量（Increment），而非「设计文档 100% 完成」；文档写「够用」的（架构决策记录 ADR、API 契约、上手指南），而非事无巨细。

价值观三：客户协作 高于 合同谈判 ​

传统外包模式靠「需求规格说明书 + 验收条款」把甲乙双方置于对立面——甲方想多要、乙方想少做。敏捷主张把客户（或产品负责人）拉进开发回路，每个迭代共同 Review、共同调整优先级。这要求合同模式从「固定范围」转向「固定预算 + 时间，范围可变」。

落地含义：Product Owner 代表客户声音、迭代 Review 邀请真实用户、用「工作软件」替代「需求确认单」做决策依据。

价值观四：响应变化 高于 遵循计划 ​

软件开发的本质不确定性使「详尽的前期计划」注定失准。敏捷不反对计划，而是让计划滚动（rolling）：近期（下个迭代）计划细，远期（3 个月后）计划粗，并随反馈调整。关键前提是有工程安全网（自动化测试、持续集成），否则频繁变化会迅速积累技术债。

落地含义：需求以 Product Backlog 形式按价值排序，每个迭代只承诺近期；估算用于「容量规划」而非「对客户的硬承诺」。

12 原则逐条要点 ​

#原则（要点）实践落点
1最高优先级是通过早并持续交付有价值软件满足客户短迭代 + 每个 Sprint 产出可用增量
2即使开发后期也欢迎需求变更Backlog 持续优先级排序，不冻结需求
3频繁交付可用软件（数周到数月，倾向更短）Sprint 长度 1-4 周，越短反馈越快
4业务人员与开发者每日协作PO 与团队同处一室 / 每日同步
5围绕有动力的个体建项目，给环境与支持，信任他们自组织团队、去掉微观管理
6面对面沟通是最有效的信息传递白板、结对、立会优先于长文档
7可用软件是进度的首要度量用「能演示的功能」而非「完成的任务数」度量
8敏捷过程倡导可持续开发，恒定节奏不靠加班堆迭代，长期可持续
9持续关注技术卓越与良好设计增强敏捷重构、TDD、干净架构
10简洁——最大化未完成工作的艺术砍掉不增价值的功能与流程
11最好的架构/需求/设计由自组织团队涌现团队自主决定技术方案
12团队定期反思并调整行为Sprint Retrospective

敏捷工程实践 ​

敏捷宣言本身不谈工程，但「能拥抱变化」必须有工程底座，否则就是裸奔。这套实践主要来自 XP（极限编程）：

text
自动化测试  → 没有它，每次变更都是赌博
持续集成    → 没有它，集成债越积越大
重构        → 没有它，代码腐烂，变更成本指数上升
结对/评审   → 没有它，知识锁在个人脑中
实践作用失去后的风险
TDD（测试驱动开发）变更有安全网，回归可自动捕获「拥抱变化」沦为制造技术债
持续集成（CI）频繁集成，问题早暴露集成阶段爆炸，迭代末期通宵
重构持续改善设计，控制复杂度代码腐烂，新功能越来越慢
结对编程 / 代码评审知识共享，质量内建巴士因子低，单点故障
简单设计只做当下需要的，YAGNI过度设计，维护负担重

计划与估算 ​

敏捷的计划是滚动的，估算服务于容量规划，不服务于对客户的硬承诺。

text
Product Backlog（远期，粗估，按价值排序）
        │ 每个 Sprint Planning 拉一批
        ▼
Sprint Backlog（本期，细估，承诺完成）
        │ 每日立会跟踪
        ▼
Increment（可用的增量，满足 Definition of Done）

估算方法：故事点（Story Point，相对复杂度）或理想日（Ideal Day）。要点：估算用于「这个迭代能装多少」，而非「这个功能 3 月 1 日上线」。

反模式清单 ​

反模式表现纠正
假敏捷拿「敏捷」当不写文档/不做设计的借口补 Definition of Done、补架构 ADR
站会变汇报Daily Scrum 变成给经理的进度汇报聚焦「计划是否需调整」，经理不发言
估算变承诺故事点被当成对客户的交付承诺估算仅用于容量规划
回顾变甩锅Retro 沦为互相指责聚焦流程改进，对事不对人
无 DoD 的迭代「完成」没有客观标准定义 Definition of Done
只做不回顾迭代结束直接进下一个强制 Retro，哪怕 15 分钟

规模化敏捷的取舍 ​

单团队敏捷（5-9 人）通常顺畅。当团队规模放大到几十上百人，纯 Scrum 不够，需扩展框架：

框架思路取舍
Scrum of Scrums多个 Scrum 团队的代表定期同步轻量，但协调弱
Nexus多团队共用一个 Product Backlog，一个集成 SprintScrum 官方扩展，较轻
LeSS（Large-Scale Scrum）保持 Scrum 简洁，多团队一 PO简洁但要求高
SAFe层级化（团队/项目群/组合），强流程重，适合超大型强合规组织

共识：先让单团队敏捷跑顺，再谈规模扩展。用 SAFe 救不了根本不会敏捷的团队。

敏捷与 DevOps 的关系 ​

维度敏捷DevOps
关注开发阶段的需求与协作开发与运维的协同与自动化
核心实践短迭代、回顾、自组织CI/CD、基础设施即代码、监控
关系敏捷「写」软件，DevOps「交付并运行」软件；二者互补

敏捷持续交付的理念（每个迭代产出可用增量）需要 DevOps 的 CI/CD 管线才能真正「频繁上线」。无 DevOps 的敏捷，迭代产物常堆在「待发布」队列里。