“关键清单”，指的是一个切中要害的敏捷行动项参考列表，能为敏捷实践者在行动时提供参考，避免在错综复杂的真实场景中，遗漏重要的步骤。好比出门前常念的口诀：“身手钥钱”，让你不会因为匆忙，而忘记重要的东西。
对于敏捷教练、企业实践敏捷的团队成员和管理者来说，虽然学习了大量的敏捷实践的相关知识，但在具体落地敏捷实践时，会因为复杂场景突发情况的干扰，遗漏一些关键的行动项。
ThoughtWorks敏捷实践关键清单，可以为使用者列出具有ThoughtWorks特色的敏捷管理和技术实践的关键行动项，提醒使用者在进行敏捷实践时，不要遗漏切中要害的行动，并鼓励团队根据自身情况进行清单的定制化和改进。
不同于汗牛充栋的敏捷实践经典文献，或散落各处的敏捷实践博客，“ThoughtWorks敏捷实践关键清单”并不追求大而全，而只为敏捷实践者，提供切中要害且短小精悍的行动项清单，让敏捷实践者即使在复杂场景中，也不会遗漏关键的行动项。
“关键清单”的灵感，来自《清单革命》一书。该书提醒我们，对于敏捷转型这样一个复杂甚至是混沌的工作，光凭人的直觉和经验已然无法驾驭其复杂度。“求大求全”的各种材料，虽然能部分解决“无知之错”（即由于缺乏知识而导致失误），但无法解决“无能之错”（即已经具备相关的知识，但由于疏忽导致失误），而且往往最终会面临无人问津的境地。而我们真正需要的，是在掌握了相关知识后，能有一个极简、有效、切中要害的执行清单、核查清单和沟通清单，来帮助我们面对复杂和混沌，做出正确的行动，避免犯“无能之错”。
当然，“关键清单”并不能替代“大而全”的书籍材料。“关键清单”假设使用者已经具备了相关的基础知识，所以会有意省略一些显而易见的行动项。要想使用好“关键清单”，需要先学习相关的敏捷实践的价值观、原则和方法。
为便于查找，本文所列“关键清单”按照敏捷开发团队工作的时间先后排序，并包含清单名称和相应的价值。某个“关键清单”的详情页面，可以点击相应的超链接来访问。目前先提供其中几个“关键清单”的详情页面，其他详情页面会陆续推出。
下面的关键清单，基于我本人作为敏捷教练，从2014年至今这5年，在ThoughtWorks辅导10余家国内金融头部企业的实践经验而编写。其中汇聚了大量ThoughtWorks同事、社区中的敏捷实践者、所服务的客户的智慧，在此表示深深的谢意。其中必有疏漏不当之处，肯请给我反馈，我会及时修正。
时点1：当获得原始需求时
- “用户问题还是解决方案”关键清单：分辨原始需求是用户问题还是解决方案，以发现真正的用户问题
- “电梯演讲”关键清单：描述产品的价值假设
- “用户画像”关键清单：描述产品的用户特点
- “用户目标”关键清单：描述产品如何让用户成为Better Me，以吸引用户
- “用户问题定义“关键清单：描述所识别出的用户问题
- “快速启动（Inception）”关键清单：邀请业务人员、技术人员和用户，在几周内集体协作，快速启动一个产品的开发工作，包括创建产品愿景、描述目标用户、表达价值主张、识别用户旅程、构思解决方案、形成用户故事、确定范围与取舍、排定优先级、可视化解决方案、确定测试策略、形成技术方案、起草开发计划。
时点2：当形成问题定义时
- “用户体验地图”关键清单：识别用户体验中的痛点
- “纸面原型”关键清单：快速验证用户交互界面的可用性
- “领域驱动设计工作坊”关键清单：让开发人员和领域专家就业务领域知识和通用语言达成共识，并识别核心域，以便让软件代码与业务概念对齐
时点3：当产生用户故事时
- “用户故事地图”关键清单：识别用户故事，并排定优先级，以便进行软件开发
- “用户故事拆分”关键清单：将大故事拆小，以便提升价值流动效率
- “用户故事验收条件”关键清单：编写用户故事验收条件，以便减少返工
- “Spike限时预研”关键清单：针对要使用的新技术，进行短期的尝试和评估，以便作出技术决策
- “故事梳理工作坊”关键清单：为下一个迭代的用户故事编写验收条件，以便提升迭代计划会的效率
- “迭代计划会”关键清单：本迭代的目标？团队承诺在本迭代完成哪些用户故事？如何才算完成？
- “每日站会”关键清单：同步用户故事的进展和风险
- “价值流式开发管理”关键清单：不设置迭代周期，而使用看板更灵活地管理价值流动
- “分支策略”关键清单：尽早、频繁、小批地解决代码冲突
- “持续集成”关键清单：尽早、频繁、小批地解决软件集成问题
- “暗部署”关键清单：将“部署”与“发布”分离，尽早、频繁、小批地解决部署中出现的问题
- “敏捷度量”关键清单：制定全局度量指标，以评估过程改进的成效
- “用户故事开卡”关键清单：在代码编写前消除对需求的误解，大幅降低变更的成本，之后将故事分解成子任务，逐一完成
- “产品共识”关键清单：沉淀团队在开发产品的整个过程中所逐渐形成的共识及演化历史，以便新人在后续加入产品的开发和维护时参考
时点4：当为用户故事编写首行代码时
- “结对编程”关键清单：两人使用一台电脑为同一个用户故事编写代码，以便能在写代码时随时纠偏，降低返工成本，促进知识传递
- “测试驱动开发”关键清单：在编写代码前，先编写测试，以便能及时发现并修复代码缺陷
- “重构”关键清单：在编写新代码前对有坏味道的代码进行重构，能加快后续新代码的开发速度
- “用户故事验卡“关键清单：在代码编写完成后立即检验，能大幅降低返工的成本
- “自动化单元测试”关键清单：自动化单元测试的运行无须依赖测试环境，成本最低，速度最快
- “集体代码回顾”关键清单：多双眼睛，多道检查；及时纠偏，又快又好；知识分享，消除瓶颈，对齐约定
时点5：当用户故事通过测试而待部署时
- “迭代展示会”关键清单：为用户展示已完成的用户故事，获取其反馈，以便持续改进
- “迭代回顾会”关键清单：发现改进点，形成行动项，进行持续过程改进
- “最大痛点改进工作坊”关键清单：尽早、频繁、小批地识别“价值最大、质量最差”的最大痛点，并将其拆解，迭代地解决
- “改进形”关键清单：教练一对一地帮助学员制定频繁和小批的改进计划，并及时回顾，循环往复，以改进创造价值和提升质量的过程，并提升学员能力
时点6：当用户故事部署上线时
- “验尸报告工作坊”关键清单：尽早、频繁、小批地针对线上事故，回顾没有限制住的“小裂纹”，以便改进过程与系统，提升系统的稳定性
- “混沌工程”关键清单：一般发生在测试环境与生产环境，主要由Dev和Ops一起协作，来定义系统稳态行为的假设，设计一系列灾难恢复测试，来考验系统在未知动荡下的韧性，并在灾难恢复测试进行时，搜集系统稳态相关的数据，以便发现并修复未知的漏洞。
