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