本文主要内容来自 SpriCoder 的博客，更换了更清晰的图片并根据新的课程设计做了补充和修正。
课程动机
- 核心课程：唯一一门系统讲解软件开发管理的课程
- 梳理如下的概念
- 软件项目管理
- 软件生命过程
- 软件过程
- 软件过程管理
- 敏捷软件开发
- CMM/CMMI
- 瀑布模型
- 未来可能需要的部分
- DevOps
- SRE
软件工程究竟是什么？
什么是软件开发？
本质上是智力劳动
软件开发的本质困难：
- 复杂性
- 不可见性
- 可变性
- 一致性
本课程目标（重要，要全部理解）
- 理解项目管理的基本概念，掌握项目管理的常用方法。例如估算和计划跟踪，配置管理，风险管理等。
- 掌握产品质量和过程质量的基本概念，理解通过过程质量管理来保障最终产品质量或服务质量的手段。
- 掌握软件过程的基本概念，了解常用软件过程方法。理解进行个人级、小组级和组织级软件过程的评价与改进方法。
- 面临复杂项目的时候，能够选择适用的软件过程，对其进行合理组合和裁剪，并在此基础上合理组织和管理项目开发，达到预先设定的质量要求。
本课程要回答的十大问题（重要）
| 问题 | 回答 |
|---|---|
| 软件过程管理和软件项目管理是不是一回事？如果不是，两者差异是什么？ | 完全是两件不同的事情，没有隶属关系。 前者类似于流水线升级改造，关注过程本身，如开发工具是否适合。CMMI 主要指导软件过程管理 后者针对特定的项目目标实现，成本质量（主要是指产品质量）工期等。 管理视角的软件工程是要复制别人的成功。 |
| 软件估算过程中，项目经验/历史数据的作用是什么？您的答案经得起细问吗？比如，能具体解释如何把项目经验/历史数据转变成估算结果？估算结果经得起时间考验吗？比如，隔了 3 个月，能保证估算结果一致？ | 估算要尽可能细地划分，提升对结果的信心； 用相对大小、抽象的描述；历史数据应该为估算所用，通过适当的加工，提升对结果的信心。 |
| 所以，估算究竟追求的目标是什么？ | 追求的是所有参与者对估算结果的认同，而不是简单追求估算结果客观的正确性，因为客观的正确性是达不到的。 估算本质上是相互讨论、妥协、达成一致的过程。 估算规模与实际规模相近，可以认为估算准确；估算时间与实际时间相近，不一定是估算准确，可能是因为只给了这么多时间。 |
| 什么叫做 XX 管理？管理的要素有哪些？如何区分有管理（或者好的管理）还是没有管理（或者不好的管理）？这种判断如果只能事后从结果判断，有意义吗？ | 三要素：目标、状态跟踪、纠偏措施； 质量管理最难的是状态跟踪。 |
| 接上一问题，什么叫做软件质量？当您宣称做了质量管理，实际上真的对质量有管理吗？ | 绝大多数企业只有质量实践，没有质量管理。 质量路线图告诉我们如何追求高质量 |
| 说说敏捷吧。 - 客户合作胜于合同谈判，您会不先签订合同或类似文件就正式开始项目吗？ - 可以工作的代码胜过面面俱到的文档，试试二次开发？现如今，从头开始的软件项目还多吗？ - 个体和互动胜过流程和工具，您试试跟 DevOps 全栈工程师谈谈？当需要服务数亿或者数千万用户的时候，敢脱离过程，甚至简化过程吗？ - 响应变化胜过遵循计划，这究竟是甲方的想法还是您的想法？请仔细想一下！ 当然，我们大可说敏捷宣言并不否认右项价值，那么问题来了，您如何判断右项已经做的足够了所以您可以开始重视左项的价值？ |
孙子曰：以正合，以奇胜。 好的敏捷是在充分理解了右项之后，在思考计算之后选择了左项。 |
| 从没有度量就没有管理/改进，到软件项目度量毫无意义，到包含 2200 多指标项的研发效能度量，到研发效能引发血案，这是想闹哪样？究竟要不要度量？ | 度量是没有争议的，一定要度量！ 错误的做法：直接把别的项目的数据拿过来用。 |
| 从极度反对 CMM 到自己搞开发运维一体化成熟度模型，所以，这是成熟度模型的问题？还是其他问题？ | 只要可以用过程描述的事情，从不成熟到成熟的路线图都是一样的。 |
| 定量管理的本质是什么？用数据就是定量管理了？DevOps 模式下，还需要定量管理吗？ | 一是构造预测模型，二是用预测模型指导项目实践 DevOps 也需要定量管理，而且可以做得更好 |
| 关于工程实践。需求分析究竟要解决什么问题？设计究竟要设计什么？测试的目的是什么？为实现这个目的，测试实践的重点应该是什么？ | 严格区分客户需求和产品需求，前者是问题，后者是解决方案 设计就是要把内部-外部、动态-静态四个象限内容填满。 测试不是提升质量水平的手段，而是帮助掌握质量状态的手段 掌握 Ver & Val：前者关注的是产品需求是否得到体现、从这个产品需求（即解决方案）设计出来，一直到解决方案的开发完成，整个过程当中有没有偏、解决方案有没有被正确地实现出来；后者更多关注的是你的这个客户需求有没有得到满足，简单来说就是客户期望解决的问题，有没有被解决。 |
关于本课程的一些假设前提
- 软件开发本质上是智力劳动，开发者心理方面的因素不可忽视；
- 大部分情况下，管理仅仅是试图复制其他地方（场景）的成功，但是这种复制一般并不容易；
- 软件开发四大本质难题永远存在，不可能彻底解决，在不同时期凸显程度有差异；
- 项目管理是为了降低/减少各种无谓损耗来实现本该有的效能；
- 软件过程改进为了达到更好的效能，这其中质量（缺陷）是首要目标或限制。
内容安排
- 第一讲 概述
- 第二讲软件过程的历史演变和经典工作（1）
- 软件开发和应用特征驱动
- 当前挑战和未来
- 不同阶段的经典（瀑布、CMM、敏捷、等等）
- 第三讲软件过程的历史演变和经典工作（2）
- 技术热点 ABC 和 DevOps（https://www.icourse163.org/）自学
- 第四、五讲估算、计划和跟踪
- 估算方法、计划框架、挣值管理方法
- 第六、七讲质量管理
- 质量是什么？质量管理手段和路线图
- 第八讲风险管理
- 第九讲工程技术管理
- 需求开发管理、技术方案管理、方案决策、V & V 管理
- 第十、十一和十二讲统计与定量管理
- 常用用统计方法、软件过程建模与仿真技术、软件项目的定理管理
- 第十三讲 GQM 度量体系
- 第十四讲配置管理
- 第十五讲缺陷预防与根因分析
- 第十六、十七讲过程管理
- 基本概念和方法
- 参考模型
- 基础设施
- 过程裁剪和融合
课程组织
- 上课，单双周安排
- 平时作业组织
- 个人完成的部分课堂练习
- 小组完成的学期课题（为一个待开发的软件项目定义一个可以工作的软件过程）
- 期中考试
- 期末考试
课本
- Devops
- 软件过程与管理
