软件工程之美学习笔记六 05 | 敏捷开发到底是想解决什么问题？
《软件工作之美》材料地址：https://time.geekbang.org/column/article/84351
一 什么是敏捷开发？
1. 敏捷开发宣言
2. 敏捷开发是什么不是什么
敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。
各种敏捷框架、方法论和工具，就像是“术”，告诉你敏捷开发的方式，而敏捷则是“道”，是一套价值观和原则，指导你在软件项目开发中做决策。
二 敏捷开发想解决什么问题？
敏捷开发就是想解决瀑布模型这样的重型软件开发方法存在的问题，用一种轻量的、敏捷的方法来改善甚至是替代它。
瀑布模型的典型问题就是周期长、发布烦、变更难，敏捷开发就是快速迭代、持续集成、拥抱变化。
三 类比：如果用敏捷的方式盖房子
四 敏捷开发和瀑布开发的比较
（以下参考网站 https://www.guru99.com/agile-scrum-extreme-testing.html）
- 敏捷开发是怎么做需求分析的？
用户故事 - 敏捷开发是怎么做架构设计的？
渐进式的架构设计，当前 Sprint 只做适合当前需求的架构设计。所以多次迭代后会带来技术债务，需要重构。 - 敏捷开发怎么保证项目质量的？
并没有专门的测试阶段，这就依赖于开发功能的同时，要编写单元测试和集成测试代码，用自动化的方式辅助完成测试。 - 敏捷开发是怎么发布部署的？
自动化的持续集成持续部署环境（CICD）
下图是我们公司的CICD环境架构图
五 该不该选择敏捷开发？
- 团队要小，人数超过一定规模就要分拆；
- 团队成员之间要紧密协作，客户也要自始至终深度配合；
- 领导们得支持。敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性；
- 写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。
六 我的留言：
（一）我们的一个综合使用开发模式的实例
我们现在着手的一个项目，是一个软件框架建设项目，外包给供应商做的。在签合同时，基本需求已经梳理得差不多了。所以按理是可以采用瀑布式开发来进行的。但由于以下原因，所以我们结合了增量开发和Scrum项目管理的模式进行系统建设。
1，基本需求是可以分模块来实现的
2，我们这个项目所依赖的其他部门提供的基础平台也不是一次性可以交付我们使用的
3，我们的使用方(另外一个应用项目）对我们项目的时间要求很急，但可以接受我们分批次交付的模块。
基于以上原因，我们设立了几个大的增量阶段，每个增量阶段我们有分几个sprint来进行开发管理。到目前为止，进展还比较顺利。
但由于我们这个框架建设项目的外部干系人比较多，所以在协调上游平台和下游应用系统的时候，确实遇到了许多沟通方面的问题。由于其他项目没有进行看板管理，所以需要进行例会形式的沟通来确保关键节点的功能实现。
所以，我认为，开发模式和项目管理模式不可以拘泥于一种形式，关键还是要看是否真正达到了整体的敏捷和精益。对于文中老师提及的scrum管理和极限编程，确实是小团队内部协同作战的比较好的实践。但对于多团队协同作战，就要考虑综合运用各种方法了。
另外，对于文中提及的站会形式，从“道”的角度来说，当然是可以视实际需求来确定是否要开，但往往一种文化的培养，需要有仪式感，需要不断锻炼。所以对于我们来说，我们还是坚持开Scrum中要求的四个重要会议的。
老师回复: 你这对软件工程中各个模型的应用可以说是非常经典的案例了，充分结合了各种模型的优缺点和适用场景，值得大家学习借鉴????
软件工程知识点其实不算复杂，难的恰恰是如何灵活运用这些知识！
还有你说的“仪式感”也是个很好的点，这些会议看起来形式化，但确实能起到仪式感的效果。
（二）对于传统开发模式中的迭代开发、增量开发和敏捷开发中的迭代的概念的理解
对于传统开发模式中的迭代开发、增量开发和敏捷开发中的迭代的概念的理解，确实会经常搞，当然这个问题挺学术化的，是要结合历史发展来谈的。
我们可以通过需求场景来谈开发模式
一类是需求不变的，工作量是可估算的、系统开发过程是可排期的、开发合同是闭口的合同。
不变的意思是，需求最终是确定的，不会再变了。只是在开发过程中有个发掘和确认过程，可以一下子全部确认（这就是瀑布模式适合的场景），也可以一个模块一个模块确认（增量开发模型），也可以先确认有把握的部分，然后再补充丰富（迭代开发模式），这类场景的开发模式称为传统开发模式。
另一类是需求是注定要变化的，而且系统需要快速发布的。
举个例子，这次我希望交付的产品页面是红底的，下次我希望是蓝底的，再下次我要求的又成了红底的了。每次需求是确认的，但下次需求和这次需求的变化很大，不只是增加（create），还有大量的（update），这类场景相对应的开发模式就是敏捷开发模式了。
所以，总结来说，传统模式和现在的敏捷模式最大的不同是需求是否可变。
大家比较混淆的是敏捷开发和迭代这两个概念。
先来说一下迭代，我们现在经常讲的迭代实际上有两种语境，一是特指软件工程中的传统开发模式中的迭代开发模式，也是更多用于传统应用的开发的。二是只敏捷开发模式下的迭代，实际就是其字面的本来意思：一件事通过几个回合来达成。
现在再来分析一下敏捷开发和敏捷开发中的迭代之间的关系。
实际上可以这么理解，在敏捷开发里，敏捷是目标，迭代是手段。通过以下场景，可以理解敏捷和迭代的关系：
有一天，老板要我带队开发一个互联网产品，老板只有一个初步的想法，最终要做成什么样，需要互联网用户的反馈，而且，互联网用户的喜好变化很快，或许今天想这样，明天又会想那样，后天又会变回来，所以老板要求我们持续跟踪用户反馈。
我认真地想了想，为了敏捷地适应用户快速变化的需求**（目标），决定采用敏捷开发的模式来开发这个产品，采用scrum的方式开展工作，每两周一个sprint冲刺，完成一次从需求确认到上线的迭代（手段）**，通过两次迭代，发布一个最小可用产品，同时收集老板的反馈，以及最终用户的反馈，把需求逐渐加到product backlog 里，然后在product backlog里挑选合适的需求，加到下一次sprint冲刺里，这样一次一次地进行迭代开发，借助持续集成持续发布部署的流水线，不断发布新的产品版本供用户使用，直到产品下线。
老师回复: 你这对软件工程中各个模型的应用可以说是非常经典的案例了，充分结合了各种模型的优缺点和适用场景，值得大家学习借鉴????
软件工程知识点其实不算复杂，难的恰恰是如何灵活运用这些知识！
还有你说的“仪式感”也是个很好的点，这些会议看起来形式化，但确实能起到仪式感的效果。