极限编程规则概述

本文约 576 字,包含 0 张图片,阅读时间约 2 分钟

QR Code

在手机上查看此页面

注:极限编程有两大版本,第一个是 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)

  1. 编写用户故事(User Story)
  2. 创建发布计划(Release Planning)发布时间表(Release Schedule)
  3. 频繁地以小版本发布软件(Make Frequent Small Releases)
  4. 将项目划分,以迭代(Iterative Development)方式开发
  5. 迭代计划(Iteration Planning)从每次迭代时开始

管理(Managing)

  1. 给团队一个专用的工作空间(Dedicated Open Work Space)
  2. 设置一个可持续的工作步伐(Sustainable Pace)
  3. 召开每日的站立会议(Stand Up Meeting)
  4. 测量项目进度(Project Velocity)
  5. 保持人员移动(Move People Around)
  6. 当极限编程被破坏时要进行修复(Fix XP When It Breaks)

设计(Designing)

  1. 简单是关键(Simplicity is the Key)
  2. 决定系统隐喻(System Metaphor)
  3. 在设计阶段使用CRC卡(Class-Responsibilities-Collaboration Card)
  4. 创建尖峰解决方案(Spike Solution)以降低风险
  5. 不要过早的添加功能(Never Add Functionality Early)
  6. 尽可能地进行重构(Refactor)

编码(Coding)

  1. 随处体现用户需求(The Customer is Always Available)
  2. 严格的遵守代码编写标准(Coding Standard)
  3. 首先编写单元测试(Code the Unit Test First)
  4. 所有的代码应使用结对编程(Pair Programming)
  5. 按序集成代码(Sequential Integration)
  6. 频繁提交(Integrate Often)
  7. 配置专门的代码集成计算机(Dedicated Integration Computer)
  8. 使用集体所有制(Collective Ownership)

测试(Testing)

  1. 代码必须要单元测试(Unit Test)
  2. 代码发布前必须要通过单元测试
  3. 发现Bug时(When a Bug is Found)要创建测试
  4. 验收测试(Acceptance Test)要经常进行,并且要公布结果