Part2 基础理论

01 | 到底应该怎样理解软件工程？

什么是软件工程?

什么是工程，有人参与、有计划、有步骤地造一件产品，我们通常称为“工程”。

人月神话，60年代 OS/360操作系统，1000名程序员，5000人年。
两个事例：OS/360，Therac-25带出软件危机
软件危机：软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。

软件工程，它是为研究和克服软件危机而生。
为应对软件危机，1968 年秋季，北大西洋公约组织的科技委员会召集了近 50 名一流的编程人员、计算机科学家和工业界巨头，讨论和制定对策。在那次会议上第一次提出了“软件工程”（software engineering）这个概念。

为了经济地获得在真实机器上可靠工作的软件而制定和使用的合理工程原则。（Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.）

1993 年，电气电子工程师学会（IEEE）定义

将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中。（Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).）

本质：就是要用工程化方法去规范软件开发，让项目可以按时完成、成本可控、质量有保证。

软件工程的演化史

软件项目生命周期：需求定义与分析、设计、实现、测试、交付和维护

阶段一
依据项目管理衍生出一套最基础的过程模型：瀑布模型

瀑布模型简.png

• 瀑布模型的诞生，让软件开发从无序到有序，每个阶段又衍生出各自的方法学和工具，例如需求分析、软件测试等等
• 缺点：周期长，需求变更成本极高
• 瀑布模型，又衍生出 V 模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷

阶段二

• 90 年代，各种轻量级开发方法例如 Scrum、极限编程等不断被提出。

• 2001 年，轻量级开发方法组成敏捷联盟，精益、敏捷，星火燎原。

  
  敏捷迭代.png

软件工程公式

基于软件过程产生

• 角色分工
• 过程的管理和工具
• 过程每个阶段细分的方法学和工具

软件工程 = 过程 + 方法 + 工具

02 | 工程思维：把每件事都当作一个项目来推进

Everything is a project

工程方法：有目的、有计划、有步骤地解决问题的方法

工程方法通常会分成六个阶段：想法、概念、计划、设计、开发和发布

工程方法.png

站在整体而非局部去看问题

• 有一个被有效论证过的方法论指导你，可以帮助你提高成功概率，也可以提高效率。
• 当你用工程方法去思考的时候，你会更多的站在整体而非局部去思考，更有大局观。

改变，最有效的是方式是改变思想，这往往也是最难的部分。

03 | 瀑布模型：像工厂流水线一样把软件开发分层化

瀑布模型算是现代软件工程的起源，软件工程的发展，很大部分都是构建于瀑布模型的基础之上的。

最简单的模型Code And Fix 模型

存在问题

• 开发过程不可控，难以进行项目计划；
• 团队无法有效分工协作；
• 没有有效的需求分析，需求的理解容易出现偏差，后期导致返工；
• 项目编码完成后，没有有效测试，运行时 Bug 非常多。

瀑布模型

1970 年，Winston Royce 博士借鉴了其他工程领域的思想提出了瀑布模型。

瀑布模型.jpg

六个阶段

1. 问题的定义及规划
2. 需求分析
3. 软件设计
4. 程序编码
5. 软件测试
6. 运行维护

“软件生命周期”(Software Life Cycle,SLC) 的概念
软件生命周期是软件的产生直到报废或停止使用的生命周期。而像瀑布模型这样，通过把整个软件生命周期划分为若干阶段来管理软件开发过程的方法，叫软件生命周期模型。

瀑布模型的优缺点

瀑布模型优缺点.jpg

瀑布模型解决的问题

• 让软件开发过程有序可控
• 让分工协作变成可能
• 质量有保障

04 | 瀑布模型之外，还有哪些开发模型？

• 快速原型模型
  解决客户的需求不明确和需求多变的问题。对原型采取抛弃策略或附加策略。

• 增量模型
  按模块分批次交付。需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付。

  
  增量模型.jpg

• 迭代模型
  每次迭代都有一个可用的版本。迭代结束时要完成一个可以运行的交付版本。

  
  迭代模型.jpg

V模型

V模型.jpg

05 | 敏捷开发到底是想解决什么问题？

敏捷起源

2001 初，17 位代表上述各种轻量级软件开发过程流派的领军人物聚集在一起，讨论替代瀑布模型这种重量级软件开发过程的新方法。但是没能达成一致，所以退而求其次，把大家都认同的理念整理出来，也就是后来的敏捷宣言。这些人还一起成立了敏捷联盟

敏捷宣言.png

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

06 | 大厂都在用哪些敏捷方法？（上）

07 | 大厂都在用哪些敏捷方法？（下）

一切工作任务围绕 Ticket 开展，三栏式，Todo，In Progress，Done

看板.jpg

基于 Git 和 CI 的开发流程

代码管理.jpg

部署上线流程
容器化、微服务、DevOps

每日站立会议

• 重点是要高效沟通反馈；
• 成员轮流发言，三个问题；
• 检查最新的 Ticket；
• 停车场问题

成员分工
产品、开发、测试、PM

需求/Bug都是ticket

一周事件

• 每周一部署生产环境
• 每周二开迭代回顾会议，总结上个 Sprint，
• 每周四迭代规划会，计划下周工作；
• 每周五分支切割

评估每条 Ticket 工作量

每周轮值

08 | 怎样平衡软件质量与时间成本范围的关系？

万变不离其中，软件金三角。

课后感

• 瀑布模型其实更多的是V模型。在实际工作中更多的是使用V模型。当然拉直了就是瀑布。但V模型的阶段体现了对质量的控制。
• 解决复杂问题的道，问题分解，阶段分解。
• 敏捷开发想解决什么问题？我认为敏捷依然是解决软件开发项目失败率过高的问题。瀑布模型提高了成功率，但CHAOS Report显示成功率仍然很低。由于信息系统的复杂程度已经几何级的上升，单单的分阶段显然无法足够的降低复杂度。所以需要将问题切分到更细粒度去处理，这就是敏捷的迭代或Sprint。换句话说，今天我们仍然没有摆脱软件危机。敏捷算是一剂新药。敏捷不是银弹。
• 软件开发中多快好省存在吗？我认为是可以是存在的。组织形式的创新是可以提高效率和质量的。知识的传播和共享可以提高生产率。效率质量的提升，沟通成本的降低，减少人员的负输出，多快好省是有机会出现的。

如果你也感兴趣，欢迎一起学习。