极限编程XP︱一文搞懂极限编程XP的关键实践
2022-11-10
来源：ZyBlog 码农老张
，在敏捷中，需求都会定义为 用户故事 ，关于它的内容我们后面还会学到。然后就是根据 用户故事 定义的 发布计划 。我们会在 发布计划 中包含 总体估算 和 隐喻 。在这里，需要记住的是敏捷中的估算都是相对估算，都是不精准的。
接下来，我们会根据 发布计划 和 用户故事 来确定每个 迭代中需要做的事情，也就是 迭代计划 。在这个计划中，通过客户对功能的解释会将 用户故事 进行更加深入的拆分，变成任务。之后就是通过 结对编程 来实现我们的产品。
当 迭代 结束时，或者到了 发布计划 制定的发布结点时，我们就需要通过 小规模发布 来实现产品的迭代、增量开发，从而达到敏捷的能力。
上述几个步骤，就是一个 XP 项目开发的整个生命周期过程，完整的产品最后就是通过这样不停地迭代实现的。在图中，我们还看到了 架构探针 和 探针 这两个东西。其实，它们是为了些特殊情况而使用的，比如说采用了新的技术、或者使用了新的架构、或者我们第一次尝试 XP 开发。这个时候，一个探针就像是一次测试的微型迭代。探针 是为了减少风险的，并且可能在整个项目开发中经常会使用到。
极限编程XP的关键实践(一)
提到 XP 的关键实践，就不得不拿出下面这张图。
看着眼熟不？是不是很多内容我们在上面其实都已经讲过了。没错，可能有些概念你很清楚，但有些概念你就完全没听说过了。今天，我们就来一次性地好好学习一下。
看到图中的每一环了吗？最里面的是编程方法相关的，中间的是小组实践相关的，最外面的是交付和管理相关的，我们就从内到外逐一学习。
编程方法（一）：结对编程
一提到结对编程，估计写代码的人都会很感兴趣。但是转念一想：俩人一台电脑，一个写一个看，这个画风是不是有点儿暧昧...咳，这个如果是写代码还好，要是看一些别的什么不好的东西就真的很容易出事了，毕竟我们码农的口味是不好拿捏的。好吧，说正事，两个人一起写一份代码，感觉是很大的浪费呀！确实，也有很多人质疑，而且你在国内不管大小公司，很少能见到真正地实现结对编程的公司。为什么呢？主要就是因为这种做法不太适合我们现在越来越卷的国内的互联网行业，毕竟我们是需要通过不停地加班 996 来实现一个人当两个人用的，怎么可能让两个人去干一件事，这明显违背老板的价值观呀。
不过，敏捷实践者们既然提出了这个做法，那么也一定是有它的可取之处的。比如：
所有的决定都不是一个人做出的
至少有两个人熟悉系统的每一部分
几乎不可能有 2 个人都忽视的测试或其它任务
改变组合对象（也就是换不同的人结对）可以让知识在组织内更好地传播
代码总在被审查
结对编程的效率比单独编程更高
其它还有一些优点就不一一列举了。咋眼一看，貌似还不错呀，不过就像前面所说的，在国内，或许有一些极限编程爱好者开的公司会用到，但大部分公司，或者说 99% 的公司中你都见不到。
编程方法（二）：测试驱动开发（TDD）
想必这个对各位码农来说也不陌生吧，从我们写代码的角度来说，就是先写测试再写代码，然后让我们的代码通过测试之后才算是完成开发。典型的框架就是各种单元测试框架，什么 JUnit、PHPUnit 之类的。这个吧，说实话，我这些年的开发之路上，也没用到过。为什么呢？还是一点，效率略低。不过，这种开发方式最
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
