极限编程规则概述
本文约 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)要经常进行,并且要公布结果