105.敏捷开发模型

文章目录

• • 1.什么是敏捷开发/li>
  • 2.敏捷开发宣言
  • 3.站立会议的意义
  • 4.敏捷开发想解决什么问题/li>
  • 5.如果用敏捷的方式盖房子
  • 6.敏捷开发和瀑布模型的差异
  • • （1）敏捷开发是怎么做需求分析的/li>
    • （2）敏捷开发是怎么做架构设计的/li>
    • （3）敏捷开发怎么保证项目质量的/li>
    • （4）敏捷开发是怎么发布部署的/li>
    • （5）敏捷开发的 Sprint 和迭代模型的迭代有什么区别/li>
  • 7.该不该选择敏捷开发/li>
  • 8.总结

1.什么是敏捷开发/h2>

• 敏捷开发，基于迭代的开发模型，它也强调快速交付，每次交付系统的部分功能，来保证客户满意度。在敏捷开发中，称之为·。
• • 敏捷开发，在每个迭代后，都应该向客户收集反馈，然后在后面的迭代中，酌情加入客户反馈修改的内容。
• 严格来说，敏捷开发并不算是一种开发模型，更像是框架或指南。有各种开发模型来实现敏捷开发，比如说·，和 。

有人是这样理解敏捷开发模型的：

• 敏捷开发就是 Scrum、极限编程；
• 敏捷开发就是每天站立会议、每两周一个 Sprint（字面意思是冲刺，可以理解为迭代）；
• 敏捷开发就是把需求变成故事，把故事写在便签上贴到白板，然后根据状态移动到不同的列；
• 敏捷开发就是用看板软件来管理项目。

然而，这些是敏捷开发的真正含义吗/p>

2.敏捷开发宣言

• 2001 初，17 位代表上述各种轻量级软件开发过程流派的领军人物聚集在一起，讨论替代瀑布模型这种重量级软件开发过程的新方法。
• 但是没能达成一致，所以退而求其次，把大家都认同的理念整理出来，也就是后来的敏捷宣言。这些人还一起成立了敏捷联盟。
  
  我们再回头来看前面大家对敏捷的定义，其实都是在从方法论、工具等方面解释敏捷开发。
• 敏捷宣言指出：

敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。
各种敏捷框架、方法论和工具，就像是“术”，告诉你敏捷开发的方式，而敏捷则是“道”，是一套价值观和原则，指导你在软件项目开发中做决策。

3.站立会议的意义

• 敏捷开发中流行的站立会议，主要目的是为了保证团队成员充分的沟通，遇到困难可以及时寻求帮助。但是如果每天的站立会议流于形式，并不能起到有效的目的，则应该减少频度，甚至取消换成其他方式。

• 要不要在你的项目开发中使用站立会议，判断的依据就在于这样做是不是符合敏捷的价值观和原则。

• 也就是说，当你开发做决策的时候，，不管你是不是用 Scrum 或者极限编程，那么都可以算是敏捷开发。

4.敏捷开发想解决什么问题/h2>

5.如果用敏捷的方式盖房子

• 客户想要盖一栋房子（·）。

• 产品经理和客户进行了初步的沟通，把用户的需求写成了一个个用户故事（），例如：

作为一个上班族，我想要一个卧室，以便于休息；
作为一个家庭主妇，我想要一个厨房，以便于做饭。

• 施工人员根据用户故事和客户进一步沟通（），然后对用户故事进行设计和实现；
• 每个用户故事开发时，还要给一个测试机器人编写测试脚本，让机器人可以自动测试（），并且做好的用户故事可以随时被测试验收（）；
• 每个 Sprint 四个星期时间（）；
• 第一个 Sprint 搭了个草棚，一张床就是卧室，厕所就挖了一个坑，厨房还来不及搭建（），屋顶还在漏水（）；
• 第二个 Sprint 有了简易厨房，同时修复了屋顶漏水的毛病（）；
• 第三个 Sprint 升级成了小木屋，但是忘记加上窗户（）；
• 第四个 Sprint 升级成了砖瓦房，窗户也开好了，客户可以入住。但是这时候客户发现一家三口的话，完全不够用，需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室（）；
• 第五个 Sprint，升级成了 3 个卧室，升级过程中把厨房下水道弄坏了（）；
• 第六个 Sprint，修复了下水道的问题，房子也装修好了（）；
• 客户验收使用（）。

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

当然，采用敏捷开发的模式也存在一些问题，例如全程需要客户参与，由于测试相对少一些 ，问题也会相应多一些。

6.敏捷开发和瀑布模型的差异

• 这些年敏捷开发，已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践，
• Scrum 主要用来管理·，
• 极限编程重点在，
• 而看板将。

基于 ·的实践，来对比一下敏捷开发模型和瀑布模型的差异

（1）敏捷开发是怎么做需求分析的/h3>

瀑布模型的一个重要阶段就是需求分析，要有严谨的需求分析，产生详尽的需求分析文档。而敏捷开发的需求，主要是来源于一个个小的用户故事，用户故事通常是写在卡片上的一句话，在 Sprint 的开发中，再去确认需求的细节。

比如一个用户登录网站的需求，在用户故事里面就是一句话：
作为用户，我想登录网站，这样可以方便浏览。

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

（2）敏捷开发是怎么做架构设计的/h3>

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

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

（3）敏捷开发怎么保证项目质量的/h3>

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

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

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

（4）敏捷开发是怎么发布部署的/h3>

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

在敏捷开发中，这种，因为

持续集成是一个非常好的实践，极大的缩短和简化了部署的流程，而且自动化测试的加入也很好的保证了部署产品的质量。。

（5）敏捷开发的 Sprint 和迭代模型的迭代有什么区别/h3>

我们假设有两个团队，都要实现一个简单的用户系统，

• 一个团队用迭代模型，
• 一个团队用敏捷开发（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 周期里面会完成多个用户故事。在用户故事的开发时，会针对用户故事有编码、自动化测试编码。当一个用户故事开发完成，即可通过持续集成自动发布到测试环境。

• 相对来收，

• 因此，。

7.该不该选择敏捷开发/h2>

这些年，软件工程中一些好的实践，等都来自于。可以肯定，敏捷开发是一种非常好的软件开发模式。

但在应用上，也确实需要一些满足一些条件才能用好，例如：

• 团队要小，人数超过一定规模就要分拆；
• 团队成员之间要紧密协作，客户也要自始至终深度配合；
• 领导们得支持。敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性；
• 写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。

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

因为·，做计划要相对难一些。如果团队大、客户不配合、领导不支持，再好的敏捷方法也很难有效实践起来。

如果你要实践敏捷开发，建议先找个。有条件的话，可以和一些顾问公司合作，请人做专门的培训和指导。

如果不具备条件，应该，比如说

8.总结

瀑布模型面向的是过程，而敏捷开发面向的是人。敏捷开发要解决的，恰恰是瀑布模型中存在的一些问题。

最后，在要不要用敏捷开发这个问题上，不用过于纠结，看好敏捷开发，那就放心去用，。

，以前没有敏捷开发只有瀑布模型的时候，也一样诞生了大量伟大的软件，像 Windows、Office。现在有敏捷开发，更多的是让我们多了一些选择。

附上一个链接补充：https://mp.weixin.qq.com/s/puMNz91hiQgio4wSCIrTgQ

参考：极客时间—软件工程之美

来源：BitHachi