极限编程 - 规则
考虑一下您从事的任何运动。您需要遵守该运动或比赛的规则。类似地，在极限编程中，由于整个项目是由团队成员之间以及与业务（代表客户）之间的协作驱动的，因此需要在一开始就制定项目的某些规则。这些规则应该与极限编程实践相一致。
这些规则为团队中的每个人提供了共同的参考，以便提醒每个人在事情顺利和不顺利时需要做什么以及如何做。
我们在极限编程中所说的游戏就是规划游戏。
规划游戏规则
在极限编程中，规划游戏从首次发布规划会议开始，到最终发布结束。
您必须在第一次发布计划会议之前定义符合极限编程实践的计划游戏规则，并让业务和团队熟悉这些规则。您必须管理项目，确保遵守规则。
然而，在软件开发中，不可能将一组简单的规则应用于每个项目。它们可能必须根据业务和团队的不同而有所不同，但不能影响极限编程实践。因此，可以首先制定一套具有必要目标的规则，并且只有在需要时才可以随着开发的进展对其进行修改。
游戏的目标是最大化团队开发的软件的价值。从软件的价值中，您必须扣除其开发成本以及开发过程中产生的风险。
团队的策略是尽可能少地投入，尽快将最有价值的功能投入生产，并结合设计和编码策略来降低风险。
鉴于第一个工作系统的技术和业务经验教训，业务人员清楚什么是现在最有价值的功能，并且团队迅速将其投入生产。
这个过程不断迭代和发布，直到整个开发完成。
规划游戏的基本规则可以分为以下几个方面 -
规划
管理
设计
编码
测试
规划
规划是在发布规划和迭代规划期间完成的。两者的规则相同。
在发布计划中，
企业和团队都是参与者。
使用故事卡。
用户故事由客户写在故事卡上。
用户故事由客户写在故事卡上。
业务由实现功能的优先级决定。
团队根据故事卡给出估算。
将计划短期（经常是小规模）发布
发布时间表应在双方同意的情况下制定。
下一个版本将分为迭代。
迭代计划开始每次迭代。
在迭代计划中，
团队成员就是玩家。
使用任务卡。
对于为迭代选择的每个故事，都会生成任务卡。
团队成员必须根据任务卡估算任务。
每个团队成员都分配有任务卡。
每个团队成员必须根据他或她的任务重新估计，因为
接受工作。
承担完成工作的责任。
获取有关实际花费时间的反馈。
改进估计。
尊重这些估计。
因此，谁可以做出和改变估计的规则是明确的。
最终分配是在假设每周 40 小时和负载系数的情况下完成的。
管理
该团队拥有一个专门的开放工作空间。
每个工作站的布置应使两名开发人员可以并排坐着并轻松滑动键盘和鼠标。
应设定并管理可持续的节奏（每周 40 小时，加班时间不得超过一周）。
执行计划游戏规则。
修复任何出现问题的极端编程实践。
确保团队之间的沟通。
阻止沟通是 -
没有帮助
不在正确的时间
做得很详细
使人们四处走动。
测量实际时间并定期传达给团队，以便每个团队成员都知道与预测相对应的表现。这确保了团队成员的估算能力得到提高。
在需要时为团队提供食物。
设计
设计规则是 -
为系统选择一个隐喻，并随着开发的进展不断改进它。
保持设计简单。
早期没有添加任何功能。
现在就部署尽可能多的架构来满足您当前的需求，并相信您以后可以添加更多架构
随时随地进行重构。
编码
编码规则是 -
企业（代表客户）应该始终可用。
开发人员应该按照强调通过代码进行通信的规则来编写所有代码。
应确保结对编程。
应遵循编码标准。
所有代码都必须有单元测试。
在为系统的每个部分编写代码之前，先编写单元测试，以便更轻松、更快速地创建代码。创建单元测试并创建一些代码以使其通过所需的总时间与直接编码所需的时间大致相同。它简化了回归测试。
当你编码时，你应该只戴以下四顶帽子之一 -
添加新功能，但仅更改实现。
添加新功能，但仅更改界面。
重构代码，但仅更改实现。
重构代码，但只改变接口。
为整个团队提供专用的集成工作站。
一次只有一对集成代码并确保所有测试都通过。
应该经常进行整合。
应当采用集体所有制。
测试
测试规则是 -
所有代码在发布之前必须通过所有单元测试。
当发现缺陷时要编写测试。
验收测试要经常进行。