笔记 C：敏捷开发与人本思维
Agile Coach's Note (敏捷教练按)： 敏捷（Agile）从来不是一种教条的流程，而是一种应对不确定性的“生存哲学”。在代码产出成本被无限拉低的今天，敏捷的核心不再是“如何更快地写代码”，而是“如何确保我们在做正确的事”。
模块一：敏捷哲学 (Agile Philosophy) 与核心原则
传统的软件工程试图通过完美的计划来消除变化，而敏捷哲学则认为变化是无处不在的，必须通过系统性地拥抱变化来创造价值。
- [Core Concept]：敏捷处理不可预见性的核心逻辑是增量式的适应 (Incremental Adaptation)——通过在极短的周期内频繁交付可运行的软件小增量，从而让适应步伐跟上变化的速度。
- [Engineering Mindset]：
- “个体互动”优于“流程工具”的权衡：软件工程师不是按部就班的机器，人的工作风格和沟通能力差异巨大。通过面对面的高频个体互动，可以最大程度降低信息传递中的噪音和沟通成本，这比依赖僵化的审批流程和工具更高效。
- “开发速度”与“文档化程度”的平衡：敏捷价值观强调“可运行的软件胜过面面俱到的文档”。它的权衡逻辑是剥离所有非必要的中间产物，保持文档的轻量级。过度的前期文档在面对需求变更时会产生极高的沉没成本。
- [AI-Era Mapping]：
- 在大模型时代，AI 的强项是“处理信息”，弱项是“理解意图”。过去的“轻文档”在今天正在演变为 “富上下文 (Rich Context)” 。你不需要写长篇的 Word 需求规格说明书，但你必须为 AI 维护高度结构化的 Markdown Prompt（提示词）和架构约束，这些本质上就是敏捷时代“活的文档”。
- [Memory Trigger]：
- 比喻：瀑布模型是“发射洲际导弹”，发射前需要极其精密的弹道计算（重计划），一旦点火很难中途大幅变轨；敏捷模型是“开越野车”，你只需要知道大概的方向（愿景），然后根据路况（反馈）随时狂打方向盘（拥抱变化）。
模块二：Scrum 框架 —— 团队协作的节拍器
Scrum 是一种为应对复杂性和不确定性而生的敏捷框架，它赋予了团队极大的自主权，以“时间盒 (Time-box)”的形式强制推进工作。
- [Core Concept]：Scrum 通过建立清晰的角色边界和极短的反馈循环（Sprint），打造一个自组织 (Self-organizing) 的特种作战小队。
- [Engineering Mindset]：
- 权衡逻辑：这是“管理干预”与“团队自治”之间的权衡。
- 三个核心角色：
- 产品负责人 (Product Owner, PO)：决定“做正确的事”，全权负责梳理和排序产品待办事项 (Product Backlog)。
- Scrum Master：团队的“清道夫”和教练，负责扫除团队在每日开发中遇到的障碍，确保 Scrum 机制顺畅运行。
- 开发团队 (Team)：决定“如何正确地做事”，有权在冲刺 (Sprint) 期间拒绝外界的任何需求变更。
- 关键仪式：每日站会 (Daily Stand-up) 限制在 15 分钟内，仅回答“昨天做了什么”、“遇到什么障碍”、“今天计划做什么”，极大地降低了团队的信息不对称。
- [AI-Era Mapping]：
- AI Agent 正在成为隐形的“Scrum 团队成员”。你可以将大模型视作开发团队中的“高产打字员”，而你作为人类，必须承担起 Product Owner 的职责（定义价值、验收增量）和 Scrum Master 的职责（为 AI 扫除 Context 缺失的障碍、审查 AI 的幻觉问题）。
- [Memory Trigger]：
- 比喻：Scrum 这个词来源于橄榄球运动 (Rugby) 中的“司克栏 (并球)”。它代表着一群人紧密抱团、步调一致，每一次冲刺 (Sprint) 都是为了把球向前推进几码，而不是一个人抱着球漫无目的地狂奔。
模块三：极限编程 (XP) —— 捍卫代码质量的护城河
Scrum 解决的是管理和协作问题，而极限编程 (Extreme Programming, XP) 解决的是硬核的工程技术问题。如果没有 XP 的工程实践托底，Scrum 极易沦为交付劣质代码的灾难。
- [Core Concept]：将最有效的工程实践（测试、重构、集成）“推向极致”，以此来“彻底拉平变更成本曲线 (Flatten the cost of change curve)”。
- [Engineering Mindset]：
- 测试驱动开发 (Test-Driven Development, TDD)：在写业务代码之前先写测试用例，用测试来证伪代码。这是一种“以终为始”的防御性编程逻辑，隐形成本是初期开发极慢，但收益是后期的重构和变更成本趋近于零。
- 成对编程 (Pair Programming)：两人共用一台电脑，一人编码，一人实时审查和思考架构。看似浪费了一半的人力，但实际上这是一种“连续的桌面检查 (Continuous desk check)”，通过实时质量保证避免了后期灾难性的 Bug 修复成本。
- 持续集成 (Continuous Integration, CI)：每天多次将代码合并到主干并自动运行测试。如果不这么做，传统的“大爆炸式集成 (Big bang approach)”会让人陷入“排错地狱”。
- [AI-Era Mapping]：
- 从成对编程到“人机结对 (Human-AI Pair Programming)”：Cursor 等工具彻底颠覆了 XP。现在，AI 是那个负责疯狂敲击键盘的“领航员 (Driver)”，而人类开发者是那个坐在旁边负责把握方向、审查逻辑、控制全局架构的“观察员 (Navigator)”。
- TDD 的重生：AI 时代代码生成极快，如果缺乏测试，系统会瞬间腐烂。但好消息是，AI 自动生成测试用例的成本极低。人类现在需要做的是“Prompt 驱动开发” + “AI 辅助生成 TDD 框架”。
- [Memory Trigger]：
- 比喻：拉力赛赛车。成对编程就是“驾驶员与领航员”的完美配合；TDD 是发车前的底盘强度测试；持续集成 (CI) 则是赛道上的进站快修，绝不能等到车散架了才保养。
特别模块：AI 时代敏捷宣言 2.0 构想
结合软件工程底层逻辑与当今的 AI Agent 范式，敏捷不仅没有过时，反而需要进一步演进：
- “人机结对 (Human-AI Pairing)” 优于传统的独立开发： 在个体与互动的基础上，接纳 AI 作为结对编程的常驻伙伴，人类负责价值定义与架构裁决，AI 负责繁重的逻辑实现与重构。
- “动态且严密的上下文 (Dynamic Context & Prompts)” 优于僵化的文档或纯口头沟通： 文档依然需要保持轻量，但必须进化为对大模型高度友好的 System Prompts、UML 类图或 Markdown 规范。代码的灵魂不再仅仅存在于人类的大脑中，还要存在于 AI 的 Context Window 里。
- “持续的 AI 重构 (Continuous AI Refactoring)” 应对暴涨的技术债务： AI 一键生成代码的速度让技术债务 (Technical Debt) 的积累速度呈指数级增长。必须比以往任何时候都更加坚持 XP 中的持续测试与持续集成，利用 AI 定期扫描和清理“代码异味 (Code Smells)”，否则系统将极速退化。