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