敏捷开发能解决什么问题？

一. 什么是敏捷开发

敏捷开发宣言

敏捷宣言指出：

敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。

就是说，当你开发决策的时候，遵守了敏捷开发的价值观和原则，不管你是不是用Scrum或者极限编程，那么都算敏捷开发。

二.敏捷开发解决了什么。

敏捷开发就是想解决破布模型这样的重型软件开发存在的问题，用一种轻量的、敏捷的开发方式来概算甚至是替代它。

瀑布模型的典型问题就是周期长，发布烦，变更难。

敏捷开发就是快速迭代，持续集成，拥抱变化。

三.怎么使用敏捷开发项目。

使用敏捷开发的具体步骤模拟：

1.客户想要盖一栋房子（初步的想法）。

2.产品经理和客户进行了初步的沟通，把用户的需求写成了一个个用户故事（用简单的用户故事代替繁重的需求文档），例如：

        作为一个上班族，我想要一个卧室，以便于休息；

        作为一个家庭主妇，我想要一个厨房，以便于做饭。

3.施工人员根据用户故事和客户进一步沟通（客户合作高于合同谈判），然后对用户故事进行设计和实现；

4.每个用户故事开发时，还要给一个测试机器人编写测试脚本，让机器人可以自动测试（大量采用自动化测试），并且做好的用户故事可以随时被测试验收（随时发布，持续集成）；

5,每个 Sprint 四个星期时间（时间盒子，迭代时间固定）；

6.第一个 Sprint 搭了个草棚，一张床就是卧室，厕所就挖了一个坑，厨房还来不及搭建（每个 Sprint 会选择高优先级的用户故事），屋顶还在漏水（每个 Sprint 会定期发布，客户可以随时看到可用版本，即使还不完整）；

7. 第二个 Sprint 有了简易厨房，同时修复了屋顶漏水的毛病（每个 Sprint 不仅完成用户故事，还会修复 Bug）；

8.第三个 Sprint 升级成了小木屋，但是忘记加上窗户（敏捷推崇自动化测试，但可能会测试不完备）；

9.第四个 Sprint 升级成了砖瓦房，窗户也开好了，客户可以入住。但是这时候客户发现一家三口的话，完全不够用，需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室（响应变化高于遵循计划）；

10.第五个 Sprint，升级成了 3 个卧室，升级过程中把厨房下水道弄坏了（迭代过程中可能会导致质量不稳定）；

11.第六个 Sprint，修复了下水道的问题，房子也装修好了（迭代中不断完善）；

12.客户验收使用（上线）。

用敏捷开发的方式，不再像瀑布模型那样有严格的阶段划分，火灾迭代中不断完善；不在写很多文档，而是和客户一起紧密合作；不再地址需求变更，而是即使响应变更；不在乎等到测试阶段才发布，而是随时发布，何不随时可以看到东西。

敏捷开发的问题很会让你明显：全程需要客户参与，由于测试相对少一些，问题也会多一些。

四.敏捷开发和瀑布开发的差异。

1.敏捷开发需求分析。

瀑布模型的一个重要阶段就是需求分析，要有严谨的需求分析，产生详尽的需求分析文档。

敏捷开发的需求，主要是来源于一个个小的用户故事，用户故事通常是写在卡片上的一句话，在 Sprint 的开发中，再去确认需求的细节。

比如一个用户登录网站的需求，在用户故事里面就是一句话：

作为用户，我想登录网站，这样可以方便浏览。

好处是减少了大量需求文档的撰写，可以早些进入开发。但这个对开发人员在需求理解和沟通的能力上要求更高了。

2. 敏捷开发是怎么做架构设计的？

瀑布模型在需求分析完了以后，就需要根据需求做架构设计。而在敏捷开发中，并不是基于完整的用户需求开发，每个 Sprint 只做一部分需求，所以是一种渐进式的架构设计，当前 Sprint 只做适合当前需求的架构设计。

这种渐进式的架构设计，迭代次数一多，就会出现架构满足不了需求的现象，产生不少冗余代码，通常我们叫它技术债务，需要定期对系统架构进行重构。

3. 敏捷开发怎么保证项目质量的？

瀑布模型在编码完成后，会有专门的阶段进行测试，以保证质量。

敏捷开发的 Sprint 中，并没有专门的测试阶段，这就依赖于开发功能的同时，要编写单元测试和集成测试代码，用自动化的方式辅助完成测试。

相对来说，这种以自动化测试为主的方式，质量确实是要有些影响的。

微软的 Windows 就是个很好的例子，在 Windows 10 之前，Windows 的开发模式是传统的类瀑布模型，有很长一段测试的时间，质量有很好的保障，Windows 10 开始，采用的是敏捷开发的模式，每月发布更新，稳定性要稍微差一些。

4. 敏捷开发是怎么发布部署的？

瀑布模型通常在编码结束后，开始部署测试环境，然后在测试阶段定期部署测试环境。测试验收通过后，发布部署到生产环境。

敏捷开发中，这种持续构建、持续发布的概念叫持续集成，因为整个过程都是全自动化的，每次完成一个任务，提交代码后都可以触发一次构建部署操作，脚本会拿最新的代码做一次全新的构建，然后运行所有的单元测试和集成测试代码，测试通过后部署到测试环境。

持续集成是一个非常好的实践，极大的缩短和简化了部署的流程，而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求。

5. 敏捷开发的 Sprint 和迭代模型的迭代有什么区别？

增量模型和迭代模型，这两种也是一种快速迭代的方式，那么敏捷开发和迭代模型的区别是什么呢？

我们假设有两个团队，都要实现一个简单的用户系统，一个团队用迭代模型，一个团队用敏捷开发（Scrum），一个迭代 /Sprint 的时间周期都是 2 周（10 个工作日）。

迭代模型所在的团队，产品经理会先花 2 天时间去分析需求，写成需求分析文档，架构师会花 3 天时间来做设计，程序员会花 3 天时间编码，测试再花 2 天时间去测试，最后上线用户系统。

敏捷开发的团队，Product Owner（类似于产品经理）会把需求拆分成了几个简单的用户故事：用户登录、用户注册、找回密码、修改资料，然后放到当前 Sprint 的 Backlog（任务清单），Team（开发团队）成员开始从 Backlog 选择用户故事。

程序员 A 选了“用户登录”这个用户故事，他会去找 Product Owner 确认需求细节，之后动手实现这个用户故事。

功能完成后，同时程序员 A 还写了单元测试代码和集成测试代码，对登录的功能写了自动化测试。完成后，通过持续集成工具测试和部署到测试环境。部署完成后，用户登录功能就可以进行使用了。

这个过程，程序员 A 可能花了 4 天时间，做完“用户登录”这个用户故事之后，他又开始继续选取“找回密码”的用户故事来做，4 天时间也完成了。

其他程序员也和程序员 A 一样，他们也会从 Backlog 选择一些用户故事来做。

当团队中第 1 个用户故事部署完之后，测试人员就开始帮助测试，发现的 Bug 都提交到了 Backlog，程序员们在完成用户故事后，开始着手修复这些 Bug，正好在最后 2 天都修复完成。

从上面的例子，你可以看出，迭代模型本质上是一个小瀑布模型，所以在一个迭代里面，需要完整的经历从需求分析，到设计、编码、测试这几个完整的阶段。

所以像瀑布模型一样，刚开始测试的时候是不稳定的，到测试后期才逐步稳定下来，一般迭代前期也会相对轻松一点，而后期测试阶段可能会时间很紧张。

敏捷开发的 Sprint 中，没有严格的阶段划分，每个 Sprint 周期里面会完成多个用户故事。在用户故事的开发时，会针对用户故事有编码、自动化测试编码。当一个用户故事开发完成，即可通过持续集成自动发布到测试环境。

相对来收，敏捷开发中，整个 Sprint 的节奏是比较恒定，产品也是相对稳定的，即使用户故事没有完成，也不影响版本的发布。

因此，敏捷开发更注重软件开发中人的作用，需要团队成员以及客户之间的紧密协作。

五.怎么选择开发模型。

在实际工作中选择敏捷开发,还是有些条件的：

1.团队要小，人数超过一定规模就要分拆；

2.团队成员之间要紧密协作，客户也要自始至终深度配合；

3.领导们得支持。敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性；

4.写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。

所以在选择敏捷开发这个问题上，你先要参考上面这些条件。

敏捷开发，其实对项目组成员的综合素质的要求更高，做计划要相对难一些。如果团队大、客户不配合、领导不支持，再好的敏捷方法实施也有困难。

如果现在不具备这些条件，就可以考虑NBA其中一些好的东西先用起来。比如说：每日例会，持续集成、自动化测试等。