数字化转型旨在找到一种新的工作方式，使组织能够更高效和轻松地应对快速的变化，重新调整组织，以更快地向客户交付更多价值。

持续发布软件特性

持续交付让业务部门在任何时候都能将新开发的特性发布到生产环境中，只需按下一个按钮，无须等待漫长的测试和发布周期。这里有持续发布的管理实践。

将需求分解为用户故事（user story）

用户故事是对特性简单、非正式的描述，不是针对系统需求的精确文档，格式通常是“作为（一种类型的用户），我想（做某事），以便（实现某种价值）”。用户故事的诞生，是为了实现需求的敏捷化，一次变更一点点。

组建小规模跨职能团队

敏捷团队通常由6-10人组成，对用户故事进行分析、开发、测试和部署。这样的团队规模能够在沟通和能力之间获得最佳平衡。

制定迭代周期

用户故事的大小最多只有几天的工作量，它比大型、复杂的用例更容易估算。团队以1-4周的迭代周期工作，包括：制定迭代计划（挑选优先要开发的故事）、日常开发、每日站会、故事完成后的演示、迭代结束后的回顾会议、下一次迭代的准备。这个节奏让团队一次只关注一小块特性，实时讨论出详细的需求，编写代码，快速展示。

痛苦的事情早点做

拖延的时间越长，解决难题就变得越痛苦。随着时间的推移，解决问题和错误所需的工作量就越大，系统集成就要花费更大的成本。频繁地集成能够发现潜在的问题，让团队改进脚本和自动化流程，使得集成过程更快、更平滑、低风险。用自动化来解放技术人员，把精力投入到更困难和更有价值的事情中。

扩展跨职能团队

在传统行业中，开发是开发，运维是运维，两种角色基本上没啥交集。应用程序的问题，由开发解决。平台和基础环境的问题，由运维解决。2009年提出了DevOps的概念，它是开发和运维的结合，表达的是像开发人员一样思考的运维人员和像运维人员一样思考的开发人员。它强调软件的系统管理和运维不应该是独立的工作——应该包含在软件开发团队的工作中。需要注意的是，即便拥有DevOps工程师，他也不能真正承担与系统运维相关的一切问题。

2016年又提出了AIOps，它让机器自动运维，减少对人工的依赖，让机器发现错误后自动恢复处理，解放人类的生产力。

四个关键指标

评价软件交付水平有四个关键指标：

• 代码更改从开发到上线所花费的时间
• 部署一次代码需要多久
• 从故障中恢复需要多长时间
• 生产代码多久导致一次故障