49 务实的团队
维持小而稳定的全功能团队，为学习、改进和端到端交付安排真实时间。
学习目标
- 能画出小而稳定团队完成一条用户功能所需的能力和责任边界
- 能把学习、改进和交付安排进真实日程，而不是等“有空”再做
- 能在团队能力或信任失效时定位首个差异，恢复端到端交付并减少知识孤岛
49 务实的团队
本页依据 David Thomas、Andrew Hunt《程序员修炼之道：通向务实的最高境界（第2版）》，云风译，电子工业出版社，2020 年 4 月，ISBN 9787121384356 的公开中文目录，独立重构 49 务实的团队。正文、代码、图示、实验和练习都是本课程重新设计的教学材料，不复制原书正文、插图或答案。
务实团队不是把更多职位塞进同一个群聊，而是让一组稳定的人共同承担从用户目标到验证、发布和恢复的完整切片。稳定减少交接成本，小规模让反馈快速到达，全功能让团队能在边界内完成工作；学习和改进还必须被安排，否则交付压力会持续吃掉团队能力。
三个会让团队看起来稳定的陷阱
五个词定义务实团队
<Term def="在一段时间内共同承担同一用户目标、反馈循环和恢复路径的核心协作边界。">团队稳定性</Term>不是组织图上的静态框，而是成员、目标、责任和知识可以被持续重建。稳定边界变化时，要记录原因和影响。
<Term def="团队拥有完成目标所需的设计、实现、验证、运行和沟通能力，或有明确的补足路径。">全功能</Term>不要求每个人单独全能。它要求用户价值链不被无人负责的外部移交切断。
<Term def="成员能够提出风险、承认不知道、请求帮助并相信反馈不会被惩罚的工作条件。">信任</Term>需要和具体行为连接：可以暂停发布，可以挑战决定，也可以让别人接管失败恢复。
<Term def="为交付、学习、维护和改进预留并公开承诺的时间位置。">日程</Term>把长期能力从“有空再做”变成可检查的工作。没有日期、负责人和输出，改进仍然会被挤掉。
<Term def="从用户请求到实现、验证、发布和恢复的责任与能力连续体。">端到端能力</Term>用来检查团队是否真的能交付，而不是只拥有某个局部阶段的专家。
小而稳定的团队通过共同目标减少等待，全功能边界减少移交，信任让风险提前出现，日程保护学习，端到端能力则验证这些选择有没有产生用户结果。
提示84：维持小而稳定的团队
小团队的价值在于更短的沟通路径和更清晰的责任，不是盲目压缩人数。先确定用户切片和必要能力，再决定最小协作边界；当边界无法承载验证、运行或恢复时，应补足能力或缩小范围，而不是继续靠英雄加班。
提示85：排上日程以待其成
学习和改进要像交付一样拥有时间、负责人和可观察输出。可以安排每周的故障复盘、自动化补强、结对学习或技术债切片，但必须说明它解决的风险以及何时判断已足够。未安排的改进不会因为团队认同它重要就自动发生。
提示86：组织全功能的团队
全功能团队应当能把用户目标转成可运行结果，并接住反馈与故障。能力缺口可以通过合作、平台支持或短期专家补足，但不能让外部队列成为隐形的永久依赖；每次移交都要有输入、输出、反馈和责任人。
用能力地图检查一个团队
Interactive lab
选择团队样本，定位端到端能力的首个变化
输入证据
团队可以开发功能，却依赖外部队列测试和发布，用户反馈长期延迟。
实际首差
边界节点：全功能不成立，范围需要缩小或补足明确能力。
恢复动作
为移交写契约和期限，安排结对学习；在缺口关闭前拒绝扩大切片。
先画能力和责任，再选择团队样本；稳定边界的价值在于多人都能接住用户结果。
type TeamSlice = {
goal: string;
capabilities: string[];
feedbackOwner: string;
recoveryOwner: string;
improvementSlot: string;
};
function canAcceptSlice(slice: TeamSlice) {
return (
slice.goal.length > 0 &&
slice.capabilities.length > 0 &&
slice.feedbackOwner.length > 0 &&
slice.recoveryOwner.length > 0 &&
slice.improvementSlot.length > 0
);
}这个检查提醒团队把能力、反馈、恢复和改进放到同一张地图上。它不会掩盖缺口：如果恢复责任仍为空，团队应拒绝扩大范围，先补足能力或安排明确的接管路径。
1. 画用户切片和能力边界
选择一条小用户功能，列出设计、编码、数据、测试、运行、沟通和恢复所需能力。标出每个输入、输出、责任人和外部依赖，找出无法由团队解释的空白。
正常、边界与单一故障证据
| 样本 | 只改变的变量 | 预期判定 | 必存证据 |
|---|---|---|---|
| 正常 | 稳定成员、完整能力和日程 | 用户切片闭合，责任可接管 | 能力地图、目标、反馈和恢复 |
| 边界 | 人数、期限或能力缺口 | 缩小范围或补能力，不假装完成 | 阈值来源、缺口、负责人和决定 |
| 单一故障 | 一个成员、信任或依赖失效 | 在首个团队异常点暴露并恢复 | 首差、影响、回退和改进安排 |
团队健康不靠“大家都很忙”证明。复核者应当看谁能解释目标、谁能运行验证、谁能接住故障，以及改进是否有真实时间；这些证据比组织图更接近端到端能力。
术语表
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 团队稳定性
在一段时间内共同承担同一用户目标、反馈循环和恢复路径的核心协作边界。
- 全功能
团队拥有完成目标所需的设计、实现、验证、运行和沟通能力，或有明确补足路径。
- 信任
成员能够提出风险、承认不知道、请求帮助并相信反馈不会被惩罚的工作条件。
- 日程
为交付、学习、维护和改进预留并公开承诺的时间位置。
- 端到端能力
从用户请求到实现、验证、发布和恢复的责任与能力连续体。
练习
练习
问题 1： 一个四人团队能开发功能，却每次发布都要等待另一个团队测试。你会如何判断它是否全功能？
问题 2： 团队总把自动化和重构放到“下个迭代”，如何把提示 85 变成实际行动？
问题 3： 核心成员离开后，剩余团队不敢发布也无法处理报警。你会先恢复什么？
本单元回顾
务实团队不是稳定名单或忙碌氛围，而是小而清晰的协作边界、足够的端到端能力、可提出风险的信任，以及被写进日程的学习改进。能在成员、期限或依赖发生变化时缩小范围、接住反馈并由多人恢复，才证明团队真正具备持续交付能力。