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