极限编程规则概述
本文约 576 字，包含 0 张图片，0 个代码段，阅读时间约 2 分钟
在手机上查看此页面
注：极限编程有两大版本，第一个是 Don Wells 于 1999 年在 XP 网站上发布的，第二个是 Ken Auer 在 XP/Agile Universe 2003 中提出的。本文的规则采用的是 Don Wells 版本，来源于 XP 网站，一共给出了 29 个规则，这其中包括了其他版本提到的“实践（Practices）”。而 Ken Auer 版本的不同主要是条目的变动和模糊。详细信息请戳 Wiki：Extreme Programming。
原文：The Rules of Extreme Programming
计划（Planning）
- 编写用户故事（User Story）
- 创建发布计划（Release Planning）和发布时间表（Release Schedule）
- 频繁地以小版本发布软件（Make Frequent Small Releases）
- 将项目划分，以迭代（Iterative Development）方式开发
- 迭代计划（Iteration Planning）从每次迭代时开始
管理（Managing）
- 给团队一个专用的工作空间（Dedicated Open Work Space）
- 设置一个可持续的工作步伐（Sustainable Pace）
- 召开每日的站立会议（Stand Up Meeting）
- 测量项目进度（Project Velocity）
- 保持人员移动（Move People Around）
- 当极限编程被破坏时要进行修复（Fix XP When It Breaks）
设计（Designing）
- 简单是关键（Simplicity is the Key）
- 决定系统隐喻（System Metaphor）
- 在设计阶段使用CRC卡（Class-Responsibilities-Collaboration Card）
- 创建尖峰解决方案（Spike Solution）以降低风险
- 不要过早的添加功能（Never Add Functionality Early）
- 尽可能地进行重构（Refactor）
编码（Coding）
- 随处体现用户需求（The Customer is Always Available）
- 严格的遵守代码编写标准（Coding Standard）
- 首先编写单元测试（Code the Unit Test First）
- 所有的代码应使用结对编程（Pair Programming）
- 按序集成代码（Sequential Integration）
- 频繁提交（Integrate Often）
- 配置专门的代码集成计算机（Dedicated Integration Computer）
- 使用集体所有制（Collective Ownership）
测试（Testing）
- 代码必须要单元测试（Unit Test）
- 代码发布前必须要通过单元测试
- 发现Bug时（When a Bug is Found）要创建测试
- 验收测试（Acceptance Test）要经常进行，并且要公布结果