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