6、极限编程与敏捷团队建设解析

极限编程与敏捷团队建设解析

1. 极限编程（XP）是否等同于草率编码

在极限编程开始流行时，有人认为它会鼓励草率编码。这里的“草率编码”指的是软件开发中可能引发问题的方式，具体表现如下：
- 忽视业务和测试需求 ：开发时不考虑业务需求或测试要求，在不清楚代码对业务的价值以及如何验证的情况下就开始编写。而且规格文档往往冗长、表述模糊且过时，没人愿意阅读，也就无法明确软件必须实现的功能。
- 架构或设计缺陷 ：所采用的架构不适合正在开发的产品，或者设计存在某种缺陷。开发者坐在键盘前盲目编写代码，期望写得足够多就能创造出可交付给客户的东西。
- 缺乏测试验证 ：代码没有用于验证其正常工作或正确实现目标的测试。开发者需要花费数天、数周甚至数月使用调试器来确保软件不会神秘崩溃或产生更多缺陷。

当草率编码被官僚作风掩盖时，情况尤为棘手，团队和组织可能会继续否认问题存在，还会说“我们投入了数百万在软件流程上，不可能是草率编码”。

2. 为何极限编程不鼓励草率编码

极限编程团队通过故事来确保开发者理解软件必须实现的功能。故事卡片只是提醒，真正的规格细节包含在可执行的客户测试（以及相关的敏捷模型）中。这些测试类似于规格语言，但与正式方法不同，客户可以亲自编写。团队在充分考虑业务需求和测试要求后才会开始开发。

敏捷团队不会在人们只能对需求进行假设时，花费时间构建丰富复杂的架构。相反，他们会尽量推迟应用这些约束，直到绝对必要时，此时团队可能对实际需求有更清晰的认识。例如，项目开始时不必急于决定使用 SQL Serve