极限编程是第一批敏捷开发方法中的一种。在各种敏捷方法中，极限编程最为重视工程实践，将敏捷宣言中 软件能够运行优于详尽的文档 的价值观体现到了极致。

极限编程核心的测试驱动开发、持续集成、用户故事等具体落地的实践，给IT研发团队提供了明确有效的指导，使他们得以随时保持软件处于可工作、可交付的状态，使迭代交付高质量软件成为可能。

目录

敏捷开发

敏捷开发的核心是迭代开发（iterative development）。敏捷一定是采用迭代开发的方式。

敏捷软件开发宣言提出了主要的4个价值观与12个原则。敏捷开发更像是一个框架思想指导实践。

  • 敏捷开发
    • 4个价值观
      • 个体和交互 优于 流程和工具
      • 软件能够运行 优于 详尽的文档。
      • 与客户密切合作 优于 合同谈判。
      • 能够响应变化 优于 遵循计划。
    • 12条原则
        1. 通过早期和持续交付有价值的软件，实现客户满意度。
        1. 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
        1. 不断交付可用的软件，周期通常是几周，越短越好。
        1. 项目过程中，业务人员与开发人员必须在一起工作。
        1. 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
        1. 面对面交谈是最好的沟通方式。
        1. 可用性是衡量进度的主要指标。
        1. 提倡可持续的开发，保持稳定的进展速度。
        1. 不断关注技术是否优秀，设计是否良好。
        1. 简单性至关重要，尽最大可能减少不必要的工作。
        1. 最好的架构、要求和设计，来自团队内部自发的认识。
        1. 团队要定期反思如何更有效，并相应地进行调整。

参考：

极限编程XP

极限编程是第一批敏捷开发方法中的一种。在各种敏捷方法中，极限编程最为重视工程实践，将敏捷宣言中 软件能够运行优于详尽的文档 的价值观体现到了极致。

极限编程核心的测试驱动开发、持续集成、用户故事等具体落地的实践，给IT研发团队提供了明确有效的指导，使他们得以随时保持软件处于可工作、可交付的状态，使迭代交付高质量软件成为可能。

尽管有些中小团队引入了敏捷开发的概念，甚至过程、方法、工具，但仍然大面积出现传统开发方法的一些弊端，bug多、代码质量差、进度缓慢、加班严重等弊端问题，大部分团队是对敏捷开发有一定的误解，认为梳理过程，用上更高效的工具就可以叫敏捷开发了，敏捷开发很重要的一点在于：方法。过程大体是一样的，工具只是解决方法的辅助手段，不同团队对问题有不同的看法与解决方法，使用到的工具就会不一样，所以，重点在方法。敏捷宣言第一条：个体与交互优于流程与工具。

极限编程XP与其他方法的不同

XP是一种轻量敏捷、高效、低风险、柔性、可预测、科学且充满乐趣的软件开发方式，适用于小型或中型软件开发团队，并且客户的需求模糊或需求多遍。与其他方法相比，其最大的不同如下：

  • 1.在更短的周期内，更早地提供具体、持续的反馈信息。
  • 2.迭代地进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断地发展它。
  • 3.依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
  • 4.依赖于口头交流、测试和源程序进行沟通。
  • 5.倡导持续的演化式的设计。
  • 6.依赖于开发团队内部的紧密协作。
  • 7.尽可能达到程序员短期利益和项目长期利益的平衡。

极限编程4个价值观

更具体的4个价值观，他们是XP的基础和灵魂

  • 沟通

    每个人都是团队的一部分，保证大家都有发言权，面对面高效交流沟通尽量保证每个人信息对称。

  • 简单

    挖掘问题的本质，只做必须做的事，简单快速高效，过犹不及，最大化投资价值。

  • 反馈

    通过发布可运行的软件来兑现每一次迭代承诺。尽早、尽可能频繁地演示软件，倾听反馈及时响应，不固执遵从既定流程。

  • 勇气

    所有人真实反应项目进展和状态。培养不要为失败找借口的习惯。营造无需恐惧的氛围，勇于拥抱变化，一切从实际出发，只为成功这个目标。

  • 尊重

    除了以上4个价值观，我们觉得尊重是我们认为的第五个团队价值观。

    团队与个人相互依赖、密不可分；团队由个人构成，离开了个人，团队就不存在；个人是团队中的个人，离开了团队，个人就不再是团队成员，团队的状态与变化会影响成员个人；团队居主导地位，团队统帅个人，具备个人不具备的能力，个人在团队发展过程中是被支配的，需要服从和服务于团队。团队要尊重个人的付出，个人要尊重团队的成果。【马哲通俗之美 | 6 整体与部分】

极限编程5个原则

更具体的5个原则

  • 快速反馈
  • 简单性假设
  • 逐步修改
  • 提倡更改
  • 优质工作

极限编程术语

用户故事

  • 从用户角度出发

    用户故事是一个用来确认用户和用户的需求的简短的描述，把你的用户角色提炼出来。用户故事从用户的角度出发，描述他们希望系统提供的服务，使用业务语言编写，而不应带有太多专业技术术语。

  • 聚焦需求与价值

    用户故事与传统需求文档的另一个区别在于对用户诉求的重视程度。在用户故事中，应该尽量避免涉及具体的技术、数据库、算法等细节，应该尽量聚焦于用户需求和业务价值，而非详尽地描述用户界面细节。

  • 故事完成时间

    开发者需要估算完成用户故事大概需要的时间。在为期2~3周的迭代中，一个故事理想的完成时间应该在1~5天。超过5天的故事就太大了，需要进一步拆分成更小的故事。不到1天的故事可以与其他故事合并。

  • 故事验收

    用户故事还能驱动出相应的验收测试。一个用户故事是否完成，必须由一个或多个自动化的验收测试来验证。

更多参考：用户故事与敏捷方法心得 - 知乎

技术穿刺

  • 穿刺

    有些团队称为预研，预先研究的意思，通常初步了解需求后，都会出现棘手的技术或设计问题，可以做一个预研，也就是 穿刺，我们觉得这个词很适合(架构穿刺第一次在极限编程合作社听到)。通过穿刺试探寻找可行的解决方案。

  • 目的

    • 判断用户故事可行性
    • 提高用户故事可靠性
    • 降低技术难度，提高工作量评估准确性

  • 时间

    穿刺时间，不宜过长，且要求及时主动反馈进展，只要验证技术或设计问题，其他方面不考虑，最好在最近2~3天之内，超过太长时间，需要及时反馈并讨论是否有必要。

发布计划

  • 用户故事列表

    发布计划确定了每一次项目发布所需实现的用户故事范围，以及发布时间。

    发布计划提供一组用户故事列表，用于在迭代计划会议中进行选择，以便在下一个迭代中实现。

  • 目的

    这些被选定的故事，会被分解为独立的开发任务，并在迭代期间完成。

    发布计划是项目整体的用户故事管理，接受新故事，更新故事，提出故事进入迭代。

迭代计划

  • 选择用户故事

    每个迭代一般在1~3周。从发布计划（用户故事列表）里依次选择高优先级的用户故事加入到当前迭代。

    上一次迭代失败的待修复的验收测试（用户故事转化为验收测试）也会被加入到迭代计划中。参考团队上一次迭代的速度，为当前迭代选择合适数量的用户故事。当然根据实际时间、空间、资源情况灵活调整迭代时间、资源、用户故事数量等。

  • 任务分解结构

    开发团队将用户故事和上一次迭代验收失败的故事一同分解为开发任务。这里需要用倾向于开发者的语言来描述任务。将任务以索引卡片（看板）的形式记录下来，这些任务卡片构成了迭代计划细节。

  • 注意

    尽量不要在迭代进行中临时调整用户故事点估算。计划过程的基础是对现实有持续一致的估算，强行修正估算会造成更多的问题。

    不要太担心开发延期进度变慢问题。一旦执行几个迭代，就需要重新估算所有故事并且重新调整发布计划，这是很常见的情况。只要秉持最高价值故事优先开发的原则，就是在创造最大价值。

迭代开发

  • 周期

    每个迭代都是一个完整软件开发生命周期，迭代开发提升了软件开发过程的敏捷性。一般迭代开发周期在1~3周，太长反而不敏捷，太短压力太大，根据项目实际情况灵活制定迭代周期。

  • 跟踪反馈评估

    要严肃对待每个迭代的截止时间，并在迭代中跟踪任务执行情况，主动反馈任务进展，特别是可能会导致延期，及时进行迭代计划会议，重新评估部分任务甚至从本地迭代中移除部分任务。

团队效率

  • 团队效率

    团队需要清楚自身团队效率，也就是开发效率，团队效率可以用来衡量团队在一定时间内完成的工作量。

  • 故事单位与计算团队效率

    可以在上一次迭代中选择一个用户故事作为故事单位，比如消息推送、用户发帖、用户发视频等故事，就可以选择消息推送作为故事单位，用户发帖、发视频的故事参照消息推送故事计算出相当于多少故事单位，然后将所有故事的故事单位数相加，得到一个总和，就是开发效率。

  • 灵活的团队效率

    每个团队在估算故事和任务时，都是偏主观的，都有各自不同的偏好，会高估也会低估。

    一开始项目规模和团队效率是很难估算准确的，大多项目都是这个问题。通过几个迭代的探索，可以更好地衡量项目规模与团队效率。而要让主观估算更准确并可预期的节奏推进迭代的关键在于：跟踪记录每次迭代中完成的开发任务总量。

验收测试

  • 传统测试

    瀑布流或其他比较重的开发方法，测试都占比比较重大的环节。包含需求测试、测试用例设计、黑盒测试（功能/UI测试）、白盒测试、单元测试、集成测试、系统测试，发布前回归测试，及产品、运营、客户验收测试，上线发布跟踪测试等

  • 验收测试

    极限编辑中，验收测试和开发任务一样源于用户故事。

    在迭代过程中，测试团队通过迭代中的用户故事，设计用户故事相应的一个或多个验收测试，用于检查这个用户故事是否完整实现。

    验收测试，一般是黑盒测试，有一组输入，一组期待输出。

  • 自动化

    验收测试应该自动化。

缺陷管理

  • QA

    QA是极限编程很重要的一部分。在一些项目中，QA是由专门的团队来执行；另一些项目中，QA是开发团队的一部分。无论哪种情况，极限编程都要求开发和QA联系非常紧密。

  • bug管理

    bug管理，不仅有利于当前迭代中开发有序修复及了解当前迭代的质量，甚至预感可能问题，还有助于团队回顾复盘，避免之后迭代重复出现低级失误，提高团队技战术能力。

小步试错快速迭代

船小好调头。

把具有重要意义的功能拆分成小的用户故事，在发布计划会议上安排各个功能的交付计划，并尽早发布。小步发布有助于及时获取有价值的反馈，从而对系统开发产生有效的影响，不论是临时补充用户反馈更有价值的需求还是及时调整方向。重要的功能特性越晚让使用者看到，应对缺陷、用户不满和需求变化的时间就越少。

极简主义、小步试错、快速迭代、用户体验、及时调整

极限编程实践流程

发布计划会议

  • 发布计划会议

    发布计划会议的目的是对整个项目进行规划，制订项目的发布计划。发布计划之后会用于为每个迭代创建迭代计划。

  • 议程

    • 开发及各方人员估算用户故事理想实现时间（打分）
    • 讨论排定各个用户故事的优先顺序等级
    • 迭代数估算

  • 迭代数规划

    • 按时间估算

      用户故事总数 = 迭代数 * 团队效率（一个迭代可以完成多少单位的用户故事）

      如：1个月时间，团队一个迭代10天可完成10个单位的用户故事，则本次发布计划可以完成(30天/10天*10个单位故事 = 30个单位的用户故事)

    • 按范围估算

      迭代数 = 范围确定后的用户故事总数 / 团队效率（一个迭代可以完成多少单位的用户故事）

      如：50个单位的用户故事，团队一个迭代一周可完成10个单位的用户故事，则本次发布计划需要(50单位故事/10 = 5个迭代数)，即5周。

  • 影响计划的3个因素

    范围、时间、资源。范围即需要完成多少内容；时间即什么时候可以完成；资源就是有多少可用的人。

    降低质量并不能提高开发速度，反而会因为大量的错误和返工而降低速度，从而对3个项目变量（范围、资源、时间）都产生负面的影响。因此，开发团队应该尽力交付能力范围内最高质量的软件。

例会

  • 每日例会

    传统开发方法，最短例会是周例会。而敏捷开发强调人与交互、沟通、简单、快速反馈、能够响应，所以每日例会是一个最短例会。每日例会快速简短，主要快速信息对称、问题反馈、互相确认任务与目标，并强调当日的主要问题与任务。个人描述昨天完成什么，今天要做什么，以及存在的问题。

  • 周例会

    过去一周的评估，下一周的计划

    如果一次迭代的时间在1~2周之内，也可以灵活将周例会与迭代会议合并，减少会议次数。

  • 例会目的

    与上下级信息对称，了解过去，沟通当下，计划未来。促使团队与个人更聚焦明确的目标。

集体参与

目前大部分架构设计会由首席架构师主导，而项目系统的模块功能设计、编码都是分派给不同人负责，而后续人员流动或团队成员遇到困难时，导致其他人难以介入。

鼓励每个人为团队项目的所有模块贡献力量，让产品真正成为团队的结晶。

让团队大部分人都参与到系统设计来，让尽量多的人参与到模块设计中。

编码规范

代码必须遵循约定的编码规范。编码规范能够保持代码的一致且易于整个团队的理解和重构。

比如：

代码整洁之道

前端编码规范

结对编程

极限编程建议的结对编程，在目前国内的环境来看很难实现，2人结对编程，工资减半吗，目前有点难，但随着行业人员越来越多，行业越来越成熟，这是很可能的。

但目前可以借鉴结对编程的目的、好处和方式。结对编程可以提供更多解决问题的思路，可以提高编码质量，可以提高开发人员专注度，不容易分散。

借鉴参考，可以是两个水平相当的人结对，也可以是一老一少结对，但不是完全的结对编程，而是协作编程，不是常规编程方式，而是特殊时期或特殊问题处理期间的一种特殊协作编程方式，一主一辅的方式，两个人各自有各自的任务，两个人的任务具有较强相关性的，同一个模块的或是同一个大问题的，一个负责主要方面，一个负责次要方面，但两个人需要为这个模块或问题负责，也就是促使两个人都要联系、发展、全面的看待、分析、解决这个模块或问题。

两个人能力相当，轮流辅助；一老一少，可以以老带小，一起设计，少小编码，大佬检查完善；

结对编程就是强调了人与交互的重要性。

单元测试

极限编程推崇测试驱动开发，单元测试是极限编程的基石之一。

目前大部分中小团队都不愿意投入时间编写单元测试，最常见的理由是编写单元测试花太多时间、写单元测试的时间就已经可以写完业务代码了、快延期了就不写了。但是在项目的生命周期中，单元测试能有效地发现和防范错误，从而节省很多时间和成本。测试越难写，就越需要它，因为它节省的时间成本越多。单元测试所提供的回报远远大于创建它的成本。

我们也不唯上不唯书只唯实，每个团队还是根据自己项目实际情况，考虑是否要求单元测试编写，大部分还是需要的。

及时重构

软件代码也是联系变化发展着的，相关代码变化会引起架构的变化，方案设计也会从一开始的复杂到慢慢的简单明朗，而我们尽力遵从简单原则，保持设计简单，尽力避免混乱与复杂，及时纠正混乱与复杂，及时局部重构，优化局部，最终保持系统整体的优良、先进性。

持续集成

应该尽可能频繁地将代码集成并提交到代码库中，小步快速合并代码。首先可以有效及时的共享可重用代码资源，其次可以及时发现冲突与错误，再次可以避免资源丢失，最后保证项目临近尾声时顺利达成里程碑。

快速简单精确原则

团队及个人经常会陷入一个熟悉的困境：快速、简单、精确，三者永远只能满足其二，必须舍掉其中一个。

快速简单的方案，结果很难做到精确；简单精确的方案，没那么容易想得到；快速精确的方案，大多不简单。

还是从团队实际情况出发，有所取舍，最大化用户利益、团队利益。

客户紧密参与

  • 客户代表

    对于自由产品可以是C端客户，可以是B端客户；外包产品可以是乙方；对于开发可以是产品设计、商务运营、客服，他们本身就应该代表的是产品的终端客户的意愿（C端或B端）。

  • 每个阶段都需要客户代表

    客户代表不仅仅是为了帮助开发团队，而更应该成为开发团队重要的一份子。极限编程的所有阶段都需要与客户进行沟通，最好是在现场面对面沟通。

    一般团队很难有真正的客户，真实的客户不一定愿意，即使愿意还占用客户大量的时间。大部分团队还是会在内部寻找客户代表，可能是业务领域专家，可能是产品设计，可能是商务运营客服等，甚至有新手来充当客户 代表，但有个关键：我们需要来自真实的客户需求，不管客户代表如何接触客户获取需求信息，而不是坐着苦思冥想出来的需求。

    • 用户故事编写
    • 发布计划
    • 迭代计划
    • 验收测试
    • 发布跟踪反馈

极限编程XP关注点

从开发法者角度，主要关注点有：

  • 短平快会议 stand up
  • 小版本发布 frequent release
  • 较少文档 minimal documentation
  • 合作为重
  • 客户直接参与
  • 自动化测试
  • 适应性调整
  • 结对编程

从管理者的角度，主要的关注点有：

  • 测试驱动开发
  • 持续集成
  • 重构

参考