本文是在阅读《软件交付通识》一书的基础上，结合自己的工作实践整理出的读书工作笔记。可能对于初入行的读者并不友好，欢迎提出各种改进意见。

《软件交付通识》/ 董越著电子工业出版社，2021.10

软件项目开发的全过程是一个很大的范畴，从确定需求，到编码设计，到集成发布，到运维、运营、设计方方面面，而本文所要讨论的内容仅仅限于软件交付部分。

首先，此处所讨论的软件交付过程（Software Delievery Process）指得是站在交付的角度和思维方式下去看待整个软件项目开发的全过程。也就是说主要指编码、集成、测试、发布四个过程中的后三个过程，但本文所指软件交付并不完全按照项目开发阶段时间划分，如果因为交付遇到问题而产生的编码工作也可以看做是本文所讨论的问题。

软件项目追求

软件开发生命周期所有相关活动大致分为两部分内容，需求分析和需求实现，核心目标是追求业务成功。

需求分析对应着软件定义侧，主要目的在于制定正确的战略方向，抓住市场机会，最后落实到软件产品设计中。

需求实现对应着软件的实现侧，目的在于软件需求的落地交付。主要包括架构设计、编程实现、软件交付、运维甚至运营等。

MVP(Minimum Viable Product 最小可行性产品)：满足定义侧和实现侧需求的小步快跑要实现的最小单位项目。

小步快跑的重要性：从定义侧和实现侧协作的角度看，定义侧应该不断的定义小的需求，交给实现侧，然后实现侧尽快实现和交付这些小的需求。这就是小步快跑

软件实现侧的追求

多：更高的产能

快：更快的响应速度

好：适当的质量。这里所说的质量，是指用户能够感受到的软件服务质量，所以也包括稳定性、可靠性、安全性等。

省：合理的成本

软件交付过程追求的目标

关键是快，快点达到业务所需质量实现交付。

软件工程管理与实践探索

软件危机与软件工程

软件危机诞生于1970年左右，危机主要表现为面对越来越复杂的软件项目，开发进度难以预测，开发成本难以控制，质量无法保证等。

软件工程是指软件的工程化，即把其他领域和行业的工程化经验借鉴过来，以系统性的、规范化的、可定量的工程化方法来维护和开发软件。

软件工程思想

软件工程思想有以下7条基本原则：

用分阶段的生命周期计划严格管理
坚持进行阶段评审
对产品需求变更实行严格的控制
采用现代程序设计技术
对中间成果应能清楚的进行审查
开发人员应该少而精
承认不断改进软件实践的必要性

敏捷理念与实践

今天，我们处在VUCA（vuca是volatility(易变性)，uncertainty(不确定性)，complexity(复杂性)，ambiguity(模糊性)的缩写）时代。与传统工程追求资源效率的思维方式不同，VUCA时代往往更重要的是流动效率。因此软件工程的思想已经不能完全满足今天的时代需求，由此诞生了敏捷开发的思想。

敏捷开发的价值观

个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

敏捷开发的核心思路

敏捷开发的核心思路就是“敏捷软件开发宣言”中遵循的12条原则

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常的交付可工作的软件，相隔几星期或者一个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体斗志，以他们为核心大家项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好、效率最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何提高成效，并依次调整自身的举止表现。

总体来说，敏捷是在纠正软件工程过于强调工程化的倾向。当然，如果把敏捷片面的理解为不要流程、不写文档、不做计划，那就矫枉过正了。

敏捷开发的最佳实践

在管理实践中，接受度最高的是Scrum。

工程实践中，接受度最高的是单元测试、持续集成。

对于XP极限编程、测试驱动开发等并未被广泛采用。

精益开发

精益开发起源于丰田的精益制造思想，精益软件开发的核心逻辑是，要想尽办法尽快把产品方向选对，功能要真正能满足用户需求，防止跑偏造成浪费。为此，要把大的需求拆分成小的特性来试探，并且把小的特性在设计--开发--集成--发布这个过程中产生的各种浪费尽力消除，让这个过程尽可能快，让用户尽快看到这个特性，尽快用起来这个特性，加快用户反馈。“小步快跑”其实就在大体反映这个思想。

持续集成/交付/部署

做到持续集成的常见方法有版本控制、质量内建、自动化、过程可视化等。

持续部署是持续交付的极端情况，试将持续交付做到了极致。

DevOps

概念：

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

目前DevOps还加入了QA和Security。

DevOps的三大原则：

基础设施即代码（Infrastructure as Code）
持续交付（Continuous Delivery）
协同工作（Culture of Collaboration）

DevOps三步工作法：

实现开发到运维的工作快速的从左向右流动。
在从右向左的每个阶段中，应用持续、快速的工作反馈机制。
建立具有创意和高可信度的企业文化。

做好软件交付的10个策略

做好软件交付的10个策略可以分为以下几部分来总结：

首先是组织结构、系统架构、和交付流程的总体策略，包括
- 细粒度、低耦合、可复用的架构
- 小批量持续流动的流程
- 运行综合手段保证质量和安全
然后是针对具体事情如何做到方便、快捷，包括
- 自动化与自助化
- 加速各项活动
- 及时修复
接下来是一些保障补充性的内容，包括
- 完备记录，充分展现
- 标准化
- 协调完成完整功能
最后是如何改进
- 基于量度的持续改进

了解几个概念：

测试左移：尽量写完代码就测试

测试右移：跑到线上做测试

康威定律：你把组织结构做成什么样，那么开发的软件系统架构就会长成什么样子。

软件交付过程的思考与总结相关推荐

如何科学地利用MTTR优化软件交付流程？
谷歌提出的衡量 DevOps 质量的 DORA 指标让 MTTR(平均恢复时间) 名声大振.在本文中,你将了解到 MTTR 的作用.为什么它对行业研究很有用.你可能被它误导的原因以及如何避免 MTTR ...
DevOps笔记-01：软件交付面临的问题、软件工程的三个发展阶段、什么是DevOps？
目录 1.软件交付面临的问题 2.软件工程的三个发展阶段 3.什么是DevOps? 4.总结 1.目前软件交付面临的问题 (1)跨部门沟通成本高:团队间沟通和协作的重要性一点也不亚于写代码.写文档.做 ...
《企业软件交付：敏捷与高效管理精要》——3.4　企业软件交付的软件工厂方法...
3.4 企业软件交付的软件工厂方法正如我们前面讨论的,今天的机构面对的商业环境正以前所未有的速度发生变化.与此同时,这些机构还要管理和降低整个机构的运营成本.这就直接意味着,他们不仅要最大限度地减少 ...
《企业软件交付：敏捷与高效管理精要》——2.2　MyCo公司和MyProj企业软件交付项目...
2.2 MyCo公司和MyProj企业软件交付项目这个案例取材自真实的项目,可以说明很多实际情况.有一个跨国公用事业公司,依赖一家企业软件交付机构来为业务提供IT服务,而后者承受着很大的成本和效率压 ...
衡量软件交付性能的4个指标
目录软件交付性能指标部署频率变更准备时间变更失败率平均恢复时间(MTTR) 总结当你的团队需要通过持续集成和持续交付(CI/CD)流水线将代码部署到生产环境时,衡量这些应用程序交付的速度和 ...
全公司层级化、分层扁平化_扁平化软件发布过程
在向用户交付软件方面,敏捷开发尚未在许多组织中兑现其诺言. 造成这种情况的原因有很多,但是核心问题是组织结构的错位. 通常,公司的开发和运营团队位于单独的公司部门中,只有一位高管(CEO)是共同的,首 ...
关于测试软件设计过程管理的思考
关于测试软件设计过程管理的思考关于测试产品软件建设过程说明平台测试环节管理关于平台建设初期报表统计维度的经验关于测试产品软件建设过程说明业务方和软件实现团队方怎么能有效的沟通,这个话题一直应 ...
什么是软件维护？在软件已经交付使用后，为了改正错误或满足新需求而修改软件的过程。它有哪几种类型？
软件维护是软件生命周期的最后一个阶段,说来也许难以相信,软件的维护可以占到软件全部工作量的一半以上.在软件运行过程中,由于种种原因,计算机程序经常需要改变.除了要纠正程序中的错误外,还要增 ...
SAP成都研究院郑晓霞：Shift Left Testing和软件质量保证的一些思考
2019独角兽企业重金招聘Python工程师标准>>> 今天的文章来自Jerry的同事,曾经的搭档郑晓霞(Zheng Kate).郑晓霞是在Jerry心中是一位很有实力的程序媛,20 ...

软件交付过程的思考与总结