这是鼎叔的第六十五篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。

继续聊聊著名的敏捷研发框架：极限编程。

极限编程（Extreme Programming，XP）是由 Kent Beck 在 1996 年提出的一种软工工程方法学。XP 作为最富有成效的方法学之一，相对于传统工程方法，更强调可适应性而不是可预测性。软件需求的不断变化是难以避免的，主动适应变化才是更加现实，更加具有竞争力的态度。

对极限编程理论的理解

XP 是一种软件开发风格，专注于编程技术，清晰沟通还有团队协作的实践。XP 是始终让客户驱动系统的内容，由团队驱动开发的过程，其工作范式是保持清醒，适应变化。

XP 致力于解决敏捷软件开发中的所有风险，包括延迟、取消、系统恶化，高缺陷率，业务误解，需求变更，人员流动等。

XP 要求你抛弃旧的低效技术和习惯，按照你对团队共同目标做出的贡献来评价自己。

极限编程的价值观和核心实践

XP 的基础价值观是加强交流、从简单做起、寻求反馈和勇于实事求是。它采用近似螺旋式的轻量级开发方法，把复杂开发过程分解为一个个相对比较简单的小周期，帮助客户清楚地了解开发进度和待解决的问题，并及时调整。

XP 要求遵循的 13 条核心实践是：团队协作（Whole Team）、规划游戏（the Planning Game）、结对编程（Pair Programming）、测试驱动开发（Testing-Driven Development），重构（Refactoring）、简单设计（Simple Design）、代码集体所有权（Collective Code Ownership）、持续集成（Continuous Integration）、客户测试（Customer Test）、小型发布（Small Release）、40 小时工作制（40-hour Week）、编码规范（Code Standard）和系统隐喻（System Metaphor）。如图 2-2 所示。

XP 推崇开放式的工作环境，把客户卷入开发队伍之中，强调频繁测试不断整合的价值，希望尽早交付简单产品给用户以获得反馈。XP 方法比较适合小团队的开发实践。

价值观是普适的，实践是基于场景的，那连接两者的桥梁则是原则。

XP 的原则

一 人性化，在开发中应满足一些人性的需求。软件是由人来开发的，非人性化的管理过程会付出高昂的代价，比如导致人员更替的成本，失去创新的机会。优秀的开发者需要基本的安全感，成就感，归属感，亲切感和成长。

XP 中的限制工作时间就是为了给非工作场合的人性化需求挪出时间，从而提高工作时间内的个人贡献。总是牺牲个人需求来满足团队需求也是不可取的，伟大的团队在建立互相信任的关系时，让每个成员可以更加自我。

二 经济学。经济学上影响开发的两个方面是金钱的时间价值（今天的一块钱比明天的一块钱更加值钱），团队和系统的可选择价值（能适应未来变化的系统更有价值），必须有人为所以这些买单，不在没有把握的地方投资。

XP 实践应让所有成员和客户都获益，才算是成功的，比如代码重构，优化命名和自动化测试。

三 改进工作，而不是等待完美。“最好” 是 “足够好” 的敌人，软件开发的卓越是通过改进达到的。

四 多样性。想法越多，机会越多。关键的困难问题能用几种不同的方法解决。

五 反省。不要试图掩盖错误，反省后紧跟行动。

六 流。通过参与软件开发的所有活动来交付有价值软件的稳定流，这个流是连续的，通过频繁部署较小的增量来实现。

七 机遇。有意识地学会把问题变成机遇。

八 失败。当你不知道怎么做的时候，冒一点风险失败可能是通向成功的最短道路。

九 质量。项目不会因为接受低质量而加快速度，要求高质量通常导致更快的交付，并且让工程师感到自豪。

十 责任。责任不能被指派，只能被心甘情愿的接受，同时还要接受相应的实践，责任和权力需要同时承担。

读者可以参阅 Kent Beck 和 Cynthia Andres 的《解析极限编程——拥抱变化》

下面我们从测试角度谈谈有哪些主要的启发。

测试启发

一、将业务代表或用户代表卷入到各类测试活动中，越早越好。

充分利用有代表性的客户，帮助我们明确需求的质量要求及优先级，参与早期版本验收测试（尤其是 MVP 版本，即最小可行产品的版本），尽快反馈能代表用户声音的质量问题。

通过积极的交流，让客户代表非常清楚开发的进度、风险、待解决的质量问题以及背后的困难；同时开发团队也能及时响应商业变化，避免投资浪费。

二、共享代码所有权。

有些团队是比较抵触测试人员获得代码权限，甚至以安全为理由拒绝权限申请。我倾向于支持专职测试人员获得和开发同等的代码权限，至少是阅读和本地编译权限，便于测试人员进行代码理解，精准测试，尝试定位问题等技能。测试人员有机会和开发在同等的信息源上进行技术对话，甚至直接针对代码质量进行规范检查。

测试人员可以推动团队使用单一代码库，对临时分支生命周期进行度量，推动尽快关闭。

三、可持续的工作投入。

即不要长时间加班（工作时间超过 40 小时/周）。据我观察，一些加班严重的团队效率并不高，加班必要性不强，而每天真正高效的工作时间远远低于 8 小时，很多时间都被浪费或者拖延掉了。管理者也常陷入只看工时不看效率的低水平管理模式。

可持续的稳定工作时间，才能形成稳定的迭代会议节奏，和准确的工作量估算。团队处于比较松弛的迭代状态是持久健康的，这远比高承诺低交付要好。

在国家明令打击 996 的今天，企业管理者只能寄希望于法定工作时间内的稳定效率。

因此，如果出现大量加班现象，管理者和客户可以一起确定加班的原因，及时采取缓解措施，进行项目进度和资源的调整。

四、开放的工作空间。

最好 15 秒内能识别团队的信息工作空间。所有人在一个开放的空间办公（可以有一些小隔间做私人沟通用途），墙上有大白板贴有各种重要的提醒卡片，列出团队共同的目标和愿景，随时可以在白板上进行涂写讨论，甚至可以一起在休息间吃茶点交流。

成员需要团队感，而不是碎片人的感觉。

五、测试驱动开发 TDD。

详细解读文章参考本公众号上一篇：聊聊测试驱动开发 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484254&idx=1&sn=f48dd00832d9fb7da108f4ceeb63942b&chksm=c24fb63cf5383f2a817fcb8ec3b971e82fc21ce29e3c8260e487b340ab3274c522d9e423f3f4&scene=21#wechat_redirect

XP 将单元测试结合到它独特的螺旋式增量型开发过程中，鼓励开发人员先写验收测试通过的代码，再不断补充和重构代码内容，降低冗余代码，并努力保证测试代码的通过。这些测试代码就形成保障质量内建的安全网，同时确保了开发设计从简单开始演进，尽可能避免冗余设计。

对于测试人员，学习 TDD 的代码可以更好的理解开发人员的设计过程，以及单元测试的完成质量，同时可以把相关测试代码高频率地用于回归测试。多用单元测试替代目前的系统测试，在降低冗余的同时，还能提升根源分析的能力。

对于架构师，应习惯利用测试代替规格说明和解释，并对系统治而分之。

六、结对编程对质量有什么好处。

结对编程是 XP 实践中争议最大的一点，实施效果参差不齐。由于个人隐私空间被打破，第一次尝试结对编程的开发者通常不太适应，需要管理者加以推动。而且长时间结对很难保障，每天的结对时间通常建议控制在 4 小时以内。

从个人产出效率来说，结对编程并没有明显的优势，开始时甚至是下降的（因为同时要占用两个开发人员），随着配合越来越默契，结对编程的效率会提升。

但是从设计质量和代码质量角度来评估，结对编程效益明显，因为一个人员在主导编码时，另一个人会对他的设计思路、代码规范、测试质量做评估，及时指出了大部分的初级问题。同理，我们也鼓励测试人员和开发人员一起实践结对编程。

七、泰勒科学管理主义和 TPS(丰田产品生产方法)

泰勒主义，把质量从工程中分离出来使得质量部门更像惩罚而不是建设性的。而 TPS 是把质量融入到工程每个角色和每个环节，强调控制在制品的最大数量，中间零件承载了上游是否稳定工作的信息。

为什么项目中本应该亲密合作的两个角色团队会产生对立？

我认为是，部分团队采用了敏捷原则中对自己有利的部分，而忽视了敏捷的其他重要价值观，沟通，one team，角色互补

部分团队没有学习敏捷，而是泰勒主义的中间人，没有定期停下来审视和集体改进，建设上下游的尊重融合。

八、迭代计划和估算

​用户故事的计划就像购买货物，价格就是估值，预算就是时间，尽量晚做出基于最佳信息的决定，降低质量并不会减少工作量。

大团队要缩小，就要学会把大问题转化为小问题，从而可维护，可追溯。为了提高团队的瓶颈吞吐率，尝试把约束转移到团队以外 (这需要主管的认可)，把推模式变为拉模式。

软件设计质量则依赖核心人员的本能，思考，经验。

九 合同。和客户签订可协商范围的合同，甚至尝试按次付费（有利于与客户的快速反馈），关注初次产生收益的周期，尽快对外呈现出产品优点。客户只为系统现在或将来功能制品付费，其他都是浪费。

有价值的项目文档应在开发完成后尽快完成，不能为了文档增加基本的开发周期。

十 最佳的面试方法：先让候选人和团队工作一天吧。