作为开发人员和专业工程师，我们已经接触过Kent Beck在"版本1"中定义的极限编程的租户。
我们认为这12项核心原则中的哪项是被允许执业或者至少是当前工作或者其他工作的一部分？

* Pair programming[5]
* Planning game
* Test driven development
* Whole team (being empowered to deliver)
* Continuous integration
* Refactoring or design improvement
* Small releases
* Coding standards
* Collective code ownership
* Simple design
* System metaphor
* Sustainable pace

从工程师的角度来看，我认为XP的主要工程原理远胜于我所参与的其他任何事情。我们对此有何看法？

解决方案

回答

我认为自己很幸运，除了"配对编程"以外，我们都可以做到，但只能解决日常问题。 "集体代码所有权"也很难实现，如果不进行结对编程，我们往往会在每次迭代之间保持逻辑上的下一个用户故事。

回答

我们正在遵循我们提到的这些做法：

• 规划游戏
• 测试驱动开发
• 整个团队(有权交付)
• 持续集成
• 重构或者设计改进
• 小发行
• 编码标准
• 集体代码所有权
• 设计简单

我必须说，一年后我无法想象工作会有所不同。

对于结对编程，我必须说这在某些区域是有意义的，这些区域有很高的难度区域或者必须进行初始良好的设计(例如设计接口)。但是我认为这不是很有效。在我看来，最好在较小的零件上执行代码和设计审查，而在这种情况下，Pair编程将是有意义的。

至于"整个团队"的实践，我必须承认，随着我们团队的成长，它已经遭受了打击。当每个人都可以提供自己的个人意见时，这只会使计划会议时间过长。当前，一个核心团队正在通过进行一些初步的粗略计划来准备计划游戏。

回答

• 整个团队(有权交付)
• 小发行
• 编码标准
• 集体代码所有权

但是后来，我确实在一个非常关键的任务关键型开发团队中工作。我不一定认为XP是开发的好方法，我们必须找到适合自己的方法，而忽略教条。

回答

除了小版本，我们已经完成了所有工作，一切都很棒。我无法想象以其他方式工作。根据我的经验，我最重视的宗旨是：

• 持续集成(具有可靠的测试套件)。
• 集体代码所有权。
• 时分双工
• 团队授权和决策制定。
• 编码标准。
• 重构。
• 可持续的步伐。

其余的也很高兴，但是我发现只要拥有TDD，集体所有权和重构，我就可以不结对生活。