作为开发人员和专业工程师，您是否接触过 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 的主要工程原理远远优于我所参与的任何其他工作。您的意见是什么？
我们正在遵循您提到的这些做法：
我必须说，一年后我无法想象以不同的方式工作。
至于结对编程，我必须说它在某些领域是有意义的，那里有一个非常困难的领域，或者最初的良好设计是必不可少的（例如设计界面）。但是我不认为这是非常有效的。在我看来，最好对较小的部分进行代码和设计审查，而结对编程在这方面是有意义的。
至于“整体团队”的做法，我必须承认，随着我们团队的成长，它受到了影响。它只是让计划会议时间过长，每个人都可以提供他的个人意见。目前，一个核心团队正在通过一些初步的、粗略的规划来准备规划游戏。
我认为自己很幸运，除了“结对编程”之外，我们都可以做到，但只是为了解决大问题，而不是在日常基础上。“集体代码所有权”也很难实现，如果不进行结对编程，我们倾向于在迭代中保持逻辑下一个用户故事。
除了小版本之外，我们已经完成了所有工作，这很棒。我无法想象以其他方式工作。根据我的经验，我最看重的原则是：
其余的也很好，但我发现只要我们有 TDD、集体所有权和重构，我就可以在没有配对的情况下生活。
但是，我确实在一个相当保守的关键任务开发团队工作。我不一定认为 XP 是一种很好的开发方式，您必须找到适合您的方式并忽略教条。
在这方面很难说服管理层。但是我发现当工程师遇到困难或者我们有一个对技术或工作不熟悉的工程师时，这是可行的。
是的。
易于销售给管理层。然而，一些管理的困难部分是增加更多的时间。许多经理认为极限和敏捷编程将节省他们的时间。他们不会节省时间给你送东西。事实上，测试不断的需求收集增加了工作量。它的作用是让客户更快地得到他们想要的东西。
毫无疑问，这对 Xtreme 来说是一个了不起的方面。
在每次迭代（冲刺）结束时，会发生完全集成。不会发生每日完全集成。
你的第一次努力很少是最好的。所以是的，我发现 Xtreme 不断产生越来越好的解决方案。
我发现考虑到基础设施和资源可以延长建议的 1 或 2 周迭代长度。这在很大程度上取决于您要部署到的位置。如果您的系统被部署到生产环境中，正式系统和压力测试会增加很多开销。因此，在这种环境下，我们会进行持续一个月甚至 2 个月的迭代。如果系统正在部署到开发区域并且尚未部署到生产环境，那么即使像持续 1 天的迭代一样紧凑也是可行的。
新团队成员的结对编程可以促进这一点。代码审查在这里也可以提供帮助。这在很大程度上取决于你们彼此合作了多长时间。
我还没有发现 Xtreme 在这里真的有帮助。每个人都自然而然地落入代码库的某些领域。因此，人们获得了他们花费大量时间的事物的所有权。这实际上可以是一个很好的驱动程序，因为优秀的软件工程师会为他们以这种方式编写的内容感到自豪。
事实上，较短的迭代周期确实促进了简单的设计。它需要在短期版本中保持可维护性。
不知道这里是什么意思？
团队的速度是一项只能通过适当的指标进行敏锐估计的任务。需要保留有关任务估计和任务完成持续时间的指标。