极限编程[关闭]

Question

作为开发人员和专业工程师，您是否接触过 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 的主要工程原理远远优于我参与过的任何其他工作。您的意见是什么？

Answer 1

我认为自己很幸运，除了“结对编程”之外，我们都可以做到，但只是为了解决大问题，而不是在日常基础上。 “集体代码所有权”也很难实现，如果不进行结对编程，我们倾向于在迭代中保持逻辑下一个用户故事。

Answer 2

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

• 计划游戏
• 测试驱动开发
• 整个团队（被授权 交付）
• 持续集成
• 重构或设计改进
• 小版本
• 编码标准
• 集体代码所有权
• 简单的设计

我必须说，一年后我无法想象有不同的工作方式。

至于结对编程，我必须说它在某些领域是有意义的，那里有一个非常困难的领域，或者最初的良好设计是必不可少的（例如设计界面）。但是，我认为这不是很有效。在我看来，最好对较小的部分执行代码和设计审查，这对结对编程是有意义的。

至于“整个团队”的做法，我必须承认，随着我们团队的成长，它受到了影响。它只是让计划会议时间过长，每个人都可以提供他的个人意见。目前，一个核心团队正在通过一些初步的粗略规划来准备规划游戏。

Answer 3

• 整个团队（有权交付）
• 小版本
• 编码标准
• 集体代码所有权

但是，我确实在一个相当保守的关键任务开发团队工作。我不一定认为 XP 是一种很好的开发方式，您必须找到适合您的方式并忽略教条。

Answer 4

除了小版本之外，我们已经完成了所有工作，这非常棒。我无法想象以其他方式工作。根据我的经验，我最看重的原则是：

• 持续集成（使用可靠的测试套件）。
• 集体代码所有权。
• TDD
• 团队授权和决策制定。
• 编码标准。
• 重构。
• 可持续的步伐。

其余的也很不错，但我发现只要我们有 TDD、集体所有权和重构，我就可以在没有配对的情况下生活。

Answer 5

• 结对编程[5]

这方面很难说服管理层。但我发现当工程师遇到困难或我们有一位对技术或工作不熟悉的工程师时，这是可行的。

• 计划游戏

是的。

• 测试驱动开发

易于向管理层销售。然而，一些管理的困难部分是增加更多的时间。许多经理认为极限和敏捷编程将节省他们的时间。他们不会节省时间给你送东西。事实上，测试不断的需求收集增加了工作量。它的作用是让客户更快地得到他们想要的东西。

• 整个团队（有权交付）

毫无疑问，这对 Xtreme 来说是一个了不起的方面。

• 持续集成

在每次迭代（冲刺）结束时，会发生完全集成。不会发生每日完全集成。

• 重构或设计改进

你的第一次努力很少是最好的。所以是的，我发现 Xtreme 不断产生越来越好的解决方案。

• 小版本

我发现，考虑到可以将建议的迭代时间延长 1 或 2 周的基础设施和资源。这在很大程度上取决于您要部署到的位置。如果您的系统被部署到生产环境中，正式系统和压力测试会增加很多开销。因此，在这种环境下，我们会进行持续一个月甚至 2 个月的迭代。如果系统正在部署到开发区域并且尚未部署到生产环境，那么即使是持续 1 天的迭代这样紧凑的操作也是可行的。

• 编码标准

新团队成员的结对编程可以促进这一点。代码审查在这里也可以提供帮助。这在很大程度上取决于你们彼此合作了多长时间。

• 集体代码所有权

我还没有发现 Xtreme 在这方面真的有帮助。每个人都自然而然地落入代码库的某些领域。因此，人们获得了他们花费大量时间的事物的所有权。这实际上可以成为一个很好的驱动程序，因为优秀的软件工程师会为他们以这种方式编写的内容感到自豪。

• 简单的设计

短的迭代周期实际上促进了简单的设计。它需要在短期版本中保持可维护性。

• 系统隐喻

不知道这里是什么意思？

• 可持续的步伐

团队的速度是一项只能通过适当的指标进行敏锐估计的任务。需要保留有关任务估计和任务完成持续时间的指标。