极限编程XP︱一文搞懂极限编程XP的关键实践
2022-11-10
来源：ZyBlog 码农老张
团队
XP 所期望的完整的团队是什么样的呢？不是你想的什么美工、前后端、运维这些人到齐就行了。而是包括上述人员之外，还有客户、测试、产品、项目等各种角色的人一起。当然，这些人最好还是之前讲过的 T 型人才，一门精通，还顺便能了解其它的高级人才。
在 XP 中，没有强调团队的人数，不过依据敏捷的原则来说，团队人数也不宜过多。要想凑齐这样的一个包含全部人员的团队其实还是有难度的。如果有条件的话，可以让客户、测试、产品这些尽量多参与，并且尽量坐得离我们的团队更近一些。只要能够达成有效、快捷的沟通，那么我们的团队就是一个完整的团队。这里的完整不限于任何形式。
交付和管理（二）：计划游戏
计划就计划，怎么扯到了游戏上？传统项目管理最擅长做的是什么？计划！传统项目管理最让人受不了的是什么？计划！做计划，本身就是一件说起来容易做起来难的事情。想想你在每年的年初立过多少 Flag ，又有多少能够做到。
在 XP 中，我们将计划称为计划游戏。用游戏这两个字其实是想让计划 这个东西变得轻松一些。因为传统的项目管理中，特别是在 PMP 中，你会发现大部分的东西都是在规划过程组 中做的，最后形成的那个项目管理计划 更是一幅鸿篇巨制。但结果呢？大部分的项目最后的结果都不一定甚至很大程度上会偏离那个写了很久的项目管理计划。
而 XP 中的计划，是通过不同的阶段进行的，并且是贯穿整个项目开发过程始终的。
在探测阶段，客户和开发人员会产生评估和用户故事。
在计划阶段，客户和开发人员一起制订、发布计划（包含每一次的发布计划、每一次的迭代计划）。
在调整阶段，客户和开发人员一起针对开发过程中的实际情况，对计划不停的调整甚至制订新的计划。
这就是 XP 中的计划游戏，千万别被 游戏 这两个字误导，它和游戏还真没什么关系，只是一种制定计划的方式。我们在 Scrum 中也会看到 Scrum 是如何来制定计划的，跟 XP 的还真不太一样。
交付和管理（三）：现场团队
在现场团队这个概念中，客户是非常重要的。通常来说，客户是很难跟我们天天在一起工作的。这时候，可以选择一个 用户代表 来代替客户的职责。如果有不清楚的地方，他能随时和客户方进行快速地沟通。通常来说，让团队中的产品负责人来担任这个角色会比较好。
交付和管理（四）：小规模发布
小规模发布的另一层含义就是能够频繁地发布。有多频繁呢？最佳选择就是每一次的持续构建之后，马上就进行发布。当然，这也要视我们开发的情况而定，大部分情况下，我们的一次迭代所能交付的，应该就是可以上线正式运行的功能。但是，一些大型的功能可能需要受制于其它功能的迭代开发完成才能一起上线，这时，就需要再等一两个迭代。当然，也可以制定对应的发布计划，比如几个迭代之后会有一次全量发布，而每次迭代都是一次增量发布等。
对于小规模的发布来说，可以降低项目开发过程中的风险，也能够快速获得用户的反馈并且及时响应，这同时也促进了开发团队与客户之间的交流。不过要实现小规模发布，也需要在有测试驱动开发、持续集成、代码重构以及优良的编码规范的前提条件下，才能让小规模发布能够有条不紊地执行。
总结
怎么样，XP 的实践是不是让你怦然心动。不过还是那句话，这些实践有的很容易实
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
