《软件工程之美》总结一：基础理论

总览

软件工程核心图：时间（多久可以完成）、范围（需要实现多少功能）、成本（花多少钱）决定了质量（产品的质量、客户的满意度）

质量焦点：软件工程目标是聚焦于质量，构建和维护高质量的软件

过程：在软件项目的生命周期内开发与构建系统时要遵循的步骤（瀑布模型、敏捷开发）

方法：在整个过程中，如何构建系统的方法学（如何分析用户需求、如何对产品进行测试验收、如何进行系统架构设计等）

工具：知道了过程，掌握了方法，具体落到操作层面，就会涉及到工具的使用

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

瀑布模型缺点：瀑布的特性决定了它只能从上往下流，而且从上到下走完整个周期很长，所以一旦出现了需求的变更，很多事情需要重头再来

改善：
基于瀑布模型，衍生出 V 模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷；
这些改进模型的发展趋势上就是缩短项目周期，快速迭代

过程模型2敏捷开发：各种轻量级开发方法例如 Scrum、极限编程等不断被提出，这些轻量级开发方法一起组成了敏捷联盟

想法：想要解决的问题；
最开始问题通常是模糊的，所以需要清晰地定义好问题，研究其可行性，检查是否有可行的解决方案

概念：用图纸、草图、模型等方式，提出一些概念性的解决方案；
这些方案可能有多个，最终会确定一个解决方案

计划：关于如何实施的计划；
通常会包含人员、任务、任务持续时间、任务的依赖关系，以及完成项目所需要的预算

设计：针对产品需求，将解决方案进一步细化，设计整体架构和划分功能模块，作为分工合作和开发实施的一个依据和参考

开发：开发阶段就是根据设计方案，将解决方案构建实施；
开发阶段通常是一个迭代的过程，这个阶段通常会有构建、测试、调试和重新设计的迭代

发布：将最终结果包括文档发布

工程思维：本质上是一种思考问题的方式，在解决日常遇到的问题时，尝试从一个项目的角度去看待问题、用工程方法去解决问题、站在一个整体而不是局部的角度去看问题

瀑布模型

起源：一开始大家都是边写边改，产生了软件危机

瀑布模型：

增量模型按照功能模块来拆分、迭代模型则按照时间来拆分，看单位时间内能完成多少功能

如果项目风险高，可能做一半就不做了，那么可以基于增量模型或者迭代模型进行开发，记得在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损，此为螺旋模型：强调风险，以风险驱动的方式完善项目的开发模型

根据这个价值观，产生了诸如站立会议、Scrum等工具

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

最佳实践：Scrum + 极限编程 + 看板
Scrum 用来管理项目过程，极限编程用来工程实践，看板用来将工作流可视化

敏捷开发条件：

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

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

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

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

平衡质量、时间、成本

压缩时间：要求调整功能数量（调整范围）、增加开发成员（增加成本）

临时加需求：要求进度延期

MVP（minimum viable product，最小化的可行性产品）模式：是一种快速推出 产品的模式，一开始只推出最核心的功能，满足用户最核心的需求，然后在用户的使用过程中收集反馈，进一步升级迭代

来源：木棉上的光