XP试点要回答三个问题：先做哪几项实践、按什么顺序推进、试点期间怎么协作。对已有基本开发流程的团队，建议从测试驱动开发、持续集成、结对编程、小步发布和计划游戏切入，先建立可验证的质量反馈，再提高协作密度，最后调整发布与计划节奏。试点范围控制在1—2个小组、一个真实迭代周期，用构建通过率、缺陷回流、结对覆盖等信号判断是否扩大。
要点总览（TL;DR）
- 起步优先选测试驱动开发与持续集成，这两项构成可验证的质量反馈闭环；结对编程、小步发布、计划游戏在质量基线稳定后依次引入。
- 实施按三阶段推进：第1—2周固定测试先行与提交触发构建，第2—3周引入结对与代码集体所有，第3—4周调整发布批次与计划协商节奏。
- 协作上设试点负责人、教练、开发、测试四类角色，每日同步并入既有站会，每周一次三十分钟复盘，一个决策只在一个会议上做出。
- 试点范围控制在1—2个小组、一个真实迭代周期，用构建通过率、缺陷回流、结对覆盖、评审响应时长等可观察信号判断是否扩大。
- 试点结论分扩大、调整、停止三种，以测试用例、构建记录、结对排班、发布记录和计划对比表等归档证据为依据。
起步实践怎么选：先做哪几项XP实践
XP的实践之间存在依赖关系，试点起步不宜平均用力。测试驱动开发与持续集成共同构成“写完即验证”的反馈闭环，是其他实践的地基；结对编程和代码集体所有要求团队具备较高的协作信任与代码规范；小步发布与计划游戏则牵动发布节奏和需求协商，适合在质量反馈稳定后引入。按这个依赖关系筛选，起步清单可以收得很窄。
优先起步的实践及理由
| 实践 | 试点期作用 | 选择理由 |
|---|---|---|
| 测试驱动开发 | 先写测试再写实现，让缺陷在编码阶段暴露 | 单点改动即可落地，不依赖组织调整，反馈最快 |
| 持续集成 | 每次提交触发构建与自动化测试，保持主干可运行 | 与测试驱动开发配套，把个人验证升级为团队验证 |
| 结对编程 | 两人共用一台工作站完成同一任务，边写边评审 | 在质量基线建立后引入，降低返工和知识孤岛 |
| 小步发布 | 缩短从完成到可交付的间隔，减少大版本风险 | 依赖前几项实践提供的质量信心 |
| 计划游戏 | 业务方与开发共同估算、协商本轮范围 | 需要团队对自身速度有初步数据后再谈承诺 |
暂缓的实践与重启条件
代码集体所有、重构制度化、隐喻、现场客户等实践在起步阶段可以暂缓。代码集体所有要求团队已形成统一的编码规范和评审习惯，否则容易变成“谁都能改、谁都不负责”；重构制度化需要测试网兜底，测试驱动开发尚未稳定时推行风险较高；现场客户依赖业务方投入程度，试点期可用固定时间的需求澄清会替代。当试点小组的构建通过率稳定、结对形成固定节奏后，再逐项评估是否引入。
已有基本流程时的取舍原则
团队已有基本开发流程，意味着需求流转、任务拆分、版本管理大体可用，试点不需要推倒重来。取舍时把握三条：一是优先选能直接改善当前质量痛点的实践，若缺陷主要集中在编码阶段，测试驱动开发优先；二是优先选改动局部、可回退的实践，避免一上来就调整发布审批或考核方式；三是每项实践只设一个可观察的完成标志，例如“新代码测试先行比例达到约定值”，避免用“团队意识提升”这类无法核对的表述。
实施顺序：分阶段推进XP实践
试点按三个阶段推进，每个阶段有明确的输入、动作、输出和完成标志。阶段之间允许重叠一周，但不建议跳阶段，否则后续实践缺少判断依据。
| 阶段 | 实践 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|---|
| 第一阶段（第1—2周） | 测试驱动开发、持续集成 | 现有代码库、构建脚本、缺陷记录 | 选定一个模块试点测试先行；配置提交触发构建与自动化测试；约定主干保持可运行 | 测试用例集、构建流水线、失败处理约定 | 新代码测试先行成为默认动作；构建失败当日内修复 |
| 第二阶段（第2—3周） | 结对编程、代码集体所有 | 第一阶段形成的测试与构建基线 | 按任务复杂度安排结对；约定轮换周期；评审以结对过程替代部分正式评审 | 结对排班表、轮换记录、评审规则 | 关键模块结对覆盖达到约定比例；评审等待时间下降 |
| 第三阶段（第3—4周） | 小步发布、计划游戏 | 前两阶段的质量数据与速度数据 | 缩短发布批次；业务方参与本轮范围协商；按实际速度调整承诺 | 发布记录、本轮计划与实际的对比 | 发布间隔缩短且回滚次数可控；计划偏差在约定范围内 |
第一阶段：把验证动作固定下来
这一阶段的重点是让“写完代码先跑测试”成为习惯，而不是额外负担。做法上先选一个改动频繁、缺陷较多的模块，由一名开发带一名测试共同梳理该模块的测试用例，开发在提交前补齐对应测试；同时把构建脚本接入提交触发，明确构建失败后的处理责任人和时限。输出物包括可执行的测试用例集、构建流水线配置和一份简短的失败处理约定。完成标志是：新代码默认带测试、主干在约定时间内保持可构建。
第二阶段：提高协作密度
结对编程的引入要控制范围，先从复杂逻辑、核心模块和新成员上手三类任务开始，简单重复任务不必强制结对。结对双方按半天到一天轮换，轮换记录用于观察知识扩散情况。代码集体所有同步推进：统一编码规范、明确谁都可以修改他人代码但必须走测试与评审。此阶段的输出是结对排班表、轮换记录和评审规则，完成标志是关键模块的结对覆盖达到团队事先约定的比例，且代码评审的平均等待时间下降。
第三阶段：调整发布与计划节奏
前两阶段积累的构建数据和缺陷数据，是这一阶段谈发布节奏的基础。团队把发布批次从大版本拆小，明确每个批次的准入条件；计划游戏由业务方提出需求优先级，开发按实际速度给出范围建议，双方共同确认本轮承诺。输出物是发布记录和计划与实际的对比表，完成标志是发布间隔缩短、回滚次数在可接受范围内、计划偏差落在约定区间。
协作方式：角色分工与日常协作机制
试点期的协作安排要解决两件事：谁对什么负责，以及哪些会议可以合并。角色不宜设多，职责要能对应到具体动作和产物。
| 角色 | 主要职责 | 关键产物 |
|---|---|---|
| 试点负责人 | 确定试点范围与节奏，协调资源，对外汇报进展 | 试点计划、阶段结论 |
| 教练 | 辅导测试驱动开发与结对的具体做法，观察并纠正偏差 | 实践观察记录、辅导纪要 |
| 开发 | 执行测试先行、参与结对、维护构建可运行 | 测试用例、提交记录、结对记录 |
| 测试 | 参与用例设计、验证发布批次、跟踪缺陷回流 | 用例集、缺陷分析 |
结对轮换与评审规则
结对以任务为单位组队，复杂任务由熟悉该模块的成员带一名不熟悉的成员，轮换周期建议半天到一天，避免长期固定配对形成新的知识孤岛。结对过程本身承担部分评审职能，正式评审聚焦跨模块接口和发布前检查，减少重复走查。评审意见需在约定时限内响应，超时视为阻塞并升级给试点负责人。
每日同步与迭代内反馈的衔接
每日同步与团队既有站会合并，控制在十五分钟内，内容聚焦三件事：昨日完成的测试与构建状态、今日结对安排、当前阻塞。迭代内反馈通过构建结果和缺陷回流两条线传递，构建失败即时通知责任人，缺陷按严重程度决定是否打断当前任务。每周安排一次三十分钟的试点复盘，只讨论实践执行中的具体问题，不重复站会内容。
与既有流程会议的合并与去重
团队已有的需求评审、版本评审会议保留，但把XP试点相关的检查项并入其中，例如版本评审时同步确认发布批次的准入条件是否满足。取消或合并与站会内容重叠的进度汇报会，避免同一信息在多个会议重复确认。会议合并的原则是：一个决策只在一个会议上做出，其余会议只做信息同步。
试点中的任务拆分、结对记录、构建结果和检查项需要在同一处承载，避免散落在多个表格里。ONES的敏捷研发管理方案把需求、研发、测试放在一条流程上，迭代中的任务可通过敏捷看板管理状态，每日站会时用于对齐进度和风险；构建与部署可通过流水线管理工具与项目、迭代关联，形成可视化交付记录；试点结束后的复盘数据与经验可用ONES Wiki沉淀，文档支持关联任务并插入工作项列表，便于下一批小组直接复用。
示例：一个小组四周XP试点安排
以下为演示情景，用于说明实践、顺序与协作如何组合，实际排期需按团队情况调整。
试点范围：一个六人小组，包含四名开发、一名测试、一名兼任试点负责人的技术负责人，教练由组内一名有结对经验的成员兼任。试点对象是一个真实迭代周期内的两个模块。
| 周次 | 实践重点 | 协作动作 | 可观察输出 |
|---|---|---|---|
| 第1周 | 测试驱动开发起步 | 开发与测试共同梳理用例；每日站会同步测试先行情况 | 模块测试用例集、首轮构建流水线 |
| 第2周 | 持续集成稳定、结对启动 | 构建失败当日修复；复杂任务开始结对并记录轮换 | 构建通过率记录、结对排班表 |
| 第3周 | 结对扩展、评审规则落地 | 关键模块结对覆盖提升；正式评审聚焦接口与发布检查 | 轮换记录、评审响应时长 |
| 第4周 | 小步发布与计划游戏 | 业务方参与范围协商；按实际速度调整承诺；周度复盘 | 发布记录、计划与实际对比、复盘纪要 |
示例中的调整点
若第2周构建失败频繁，应暂停结对扩展，先把失败原因归类并修复流水线稳定性，否则结对会把不稳定的构建问题放大。若第3周结对覆盖未达约定比例，检查是任务类型不匹配还是排班冲突，必要时缩小结对范围到核心模块。第4周的计划游戏若业务方无法全程参与，可改为提前提交优先级清单、开发给出范围建议后书面确认，保留协商动作即可。
完成检查：试点是否达到预期
试点结束前，用一份清单逐项核对，结论分为扩大、调整、停止三种。检查以证据为准，不以主观感受替代。
实践执行情况检查项
- 新代码是否默认先写测试，抽查近期提交可核对；
- 构建是否由提交触发，失败是否有责任人和修复时限记录；
- 结对是否有排班和轮换记录，关键模块覆盖是否达到约定比例；
- 发布批次是否按计划拆小，准入条件是否在发布前确认；
- 计划游戏是否形成本轮范围协商记录，计划与实际是否有对比。
质量与协作的可观察信号
质量侧看三项：构建通过率是否稳定在约定水平、缺陷回流是否下降、发布回滚次数是否可控。协作侧看三项：结对轮换是否按计划发生、评审响应时长是否缩短、站会与复盘是否按合并后的规则运行。这些信号应在试点开始前就确定口径，避免结束时各说各话。
扩大、调整或停止的判断条件
| 结论 | 判断条件 | 后续动作 |
|---|---|---|
| 扩大 | 各项实践完成标志基本达成，质量信号改善且协作规则稳定运行 | 增加试点小组，补充教练，复用已有检查清单 |
| 调整 | 部分实践未落地，或质量信号无改善但团队执行意愿明确 | 延长一个迭代，聚焦未达标的单项实践，缩小范围重试 |
| 停止 | 关键实践长期无法执行，或质量信号恶化且原因无法在试点内解决 | 记录原因与证据，回到原有流程，评估其他改进方向 |
证据留存与复盘方式
试点期间产生的测试用例、构建记录、结对排班、发布记录和计划对比表，按周归档，作为复盘的事实依据。复盘会由试点负责人主持，教练提供实践观察记录，开发与测试分别说明执行中的阻碍，结论写入试点报告并明确下一批小组的改进项。经验沉淀到团队知识库，文档与相关任务关联，便于后续小组直接查阅而不是重新摸索。
常见问题
团队已有基本开发流程，引入XP时哪些既有会议需要取消或合并？
需求评审和版本评审这类做决策的会议保留，把XP试点相关的检查项并入其中，例如版本评审时同步确认发布批次的准入条件。与站会内容重叠的进度汇报会可以取消或合并，避免同一信息在多个会议上重复确认。合并的原则是：一个决策只在一个会议上做出，其余会议只做信息同步。每日同步并入既有站会，控制在十五分钟内，聚焦测试与构建状态、今日结对安排和当前阻塞三件事。
结对编程在试点期是否所有任务都要执行？
不需要全量执行。试点期先从复杂逻辑、核心模块和新成员上手三类任务开始结对，简单重复任务不必强制。结对双方按半天到一天轮换，避免长期固定配对形成新的知识孤岛。如果第3周结对覆盖未达约定比例，先检查是任务类型不匹配还是排班冲突，必要时把结对范围缩小到核心模块，而不是直接放弃这项实践。
试点中途构建频繁失败，应该先停下来修流水线还是继续推进结对？
先处理构建稳定性。构建失败频繁时继续扩展结对，会把不稳定的构建问题放大，结对双方的时间也会耗在排查环境问题上。建议暂停结对扩展，把失败原因归类，修复流水线后再恢复。第一阶段设定的完成标志本身就是构建失败当日内修复、主干在约定时间内保持可构建，这个标志未达成时不具备进入下一阶段的条件。
业务方无法全程参与计划游戏，试点还能推进吗？
可以推进，但要保留协商动作。替代做法是业务方提前提交优先级清单，开发按实际速度给出范围建议，双方书面确认本轮承诺。计划游戏的核心是业务方与开发共同协商范围，形式可以调整，协商记录要留存，否则第三阶段的完成标志“计划偏差在约定范围内”就缺少对比依据。
试点期间的任务拆分、结对记录和构建结果用什么承载比较合适？
关键是集中在一处，避免散落在多个表格里。ONES的敏捷研发管理方案把需求、研发、测试放在一条流程上，迭代中的任务可通过敏捷看板管理状态，每日站会时用于对齐进度和风险；构建与部署可通过流水线管理工具与项目、迭代关联，形成可视化交付记录；试点结束后的复盘数据与经验可用ONES Wiki沉淀，文档支持关联任务并插入工作项列表，便于下一批小组直接复用。
