一、MVP

        MVP是Eric Ries所著《精益创业》这本书中提到的概念。MVP＝Minimum Viable Product，意思是最轻量级的可行性产品。 它的目的是验证两件事：一是产品满足了用户需求；二是产品能够创造商业价值。在我的理解里MVP有两个场景可以很好的应用，一是用户不知道想要什么的情况下的MVP，二是用户知道想要什么东西，但是认知不全面情况下的MVP，如下图

在第一种场景下，客户想要一个代步工具，我们可以先给做一个滑板车，如果这就满足了用户需求，则不需继续开发，节省资源快速满足需求；在第二种场景下，用户想要一辆汽车，我们就得先把架构搭建起来，满足汽车的基本构造，如四个轮子、发动机、驾驶舱，先交付用户使用，若用户满意，则不需继续开发，若不满意，还可以继续增加内饰、空调、收音机等等增强体验的功能，这也是节省资源快速满足需求；所以MVP实质上是指利用最少的资源来得到最大的回报，这里的回报指的是经验证的认知 。

二、XP(极限编程)

    XP是一种敏捷、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。从90年代初，软件需求量激增，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的制作过程正在失去控制，软件交付开始变得困难。XP就是在这样的情况下诞生的，它是灵巧的轻量级软件开发方法，它跳出复杂的流程和文档，而是以轻量的框架和极限的思想为核心进行开发。

· 价值观

· 沟通

    小组成员未达到协作的目的，必须保持持续无间断的沟通，以此来避免文档带来的巨大沟通障碍。通过口头的交流解决问题，提高工作效率。

· 简单

    XP方法中提倡工作中秉承“够用就好”的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会发现的新问题

·反馈

    反馈这件事是非常重要的，与客户，与开发人员之间，测试人员之间等，大家都应该及时反馈项目相关的事情，让所有人知道目前的进度和遇到的问题，知道下一步该做什么，知道朝着哪个方向一起努力，以便于更好的相互配合，更好的沟通。

· 勇气

    XP秉承敏捷的拥抱变化，有了变化就需要开发人员有足够的勇气去不断修改和重构自己的代码，然后去满足不断变化的需求，也可能会产生更多的bug，都需要有足够的勇气去承担这个后果。重新开发要敢于废弃之前的努力，重构则是要勇于改变现状，让代码脱胎换骨。

· 原则

· 快速反馈

    通过更短的反馈链条，迅速地了解现在的产品是否满足客户的需求，驱动我们去更好的进行产品迭代和调整，把系统价值最大化提现。同时也要求团队成员之间及时和有效的反馈，使得团队协作更加顺畅。

· 简单性假设

    这一原则要求开发人员将每个问题都看得十分容易解决，也就是说只为本次迭代考虑，不去想未来可能需要什么，相信具有将来必要时增加系统复杂性的能力，也就是号召大家出色地完成今天的任务。

· 逐步修改

    任何问题都应该通过一系列能够带来差异的微小改动来解决，每次修改及时得到反馈，决定是否满足客户的需求从而继续往下进行，避免一次改动过大，如不能一下满足客户需求会造成多次返工。

· 提倡更改

    开发不息，bug不断，我们提倡以不同的解决方案去满足不同的客户需求，每次更改都是在提现产品的价值，不能守着最初的方法不敢去做任何改变，时代在进步，我们也需要不断的通过更改系统去满足这些进步，要为随时可能到来的改动做好心里准备。

· 优质工作

    XP方法论中，贯彻的是“小步快走”的开发原则，因此工作质量决不可打折扣，通常采用测试先行的编码方式来提供支持，先明确验收标准和测试用例，开发人员可以按照这些进行开发，确保每次开发调整的产出都是可以上线可用的增量。

· 规则

    计划

    · 编写用户故事。

    · 根据发布计划制定发布时间表。

    · 进行频繁的小规模发布。

    · 将项目分解成迭代。

    · 用迭代计划驱动每个迭代。

    管理

    · 为团队提供专注开放型办公空间。

    · 可持续的节奏。

    · 以站会开始每一天。

    · 团队开发速度可度量。

    · 让团队坐在一起。

    · 调整有缺陷的规则。

    设计

    · 简单原则。

    · 设定一个系统隐喻。

    · 在设计交流中使用CRC卡。

    · 使用Spike方法降低风险。

    · 不要过度设计或过早添加不必要的功能。

    · 尽可能地重构代码。

    编程

  · 客户紧密参与团队协作。

  · 遵循编码规范。

    · 优先编写测试。

    · 通过结对编程构建生产代码。

    · 一次仅限一对程序员集成代码。

    · 持续集成。

    · 选一台机器专用于代码集成。

    · 代码集体所有。

    测试

    · 所有代码都必须有单元测试。

    · 发布前必须跑通所有单元测试。

    · 发现一个Bug要增加一个单元测试。

    · 经常性进行验收测试并公布测试结果。

XP 和 Scrum 的核心区别

    简单地说，XP 更关注技术和工程实践，而 Scrum 更关注团队协作和管理实践。这是我总结的二者核心区别，其实很好理解。

    极限编程是第一批敏捷开发方法中最具实效的一种。在各种敏捷方法中，极限编程最为重视工程实践。

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

    极限编程的规则非常简单，采用极限编程很像在玩拼图游戏，你会看到很多小片的拼图，每一个小片单独看起来没有意义，组合起来就会看见一幅完整的图景。这些规则乍一看可能显得幼稚笨拙，但在它们背后有着坚实的价值观和原则支撑。