数字化转型应该如何去做？（敏捷思维篇）

　　业务需求无法承接，产品经理会被戴上不够敏捷的帽子；业务需求无法变更，研发团队会被戴上不够敏捷的帽子；系统没有按时上线，项目经理会被戴上不够敏捷的帽子。敏捷已经成为互联网公司提到最多的词，好像只要高举“敏捷”这面大旗就可以解决一切问题。

　　“敏捷”一般特指敏捷开发。敏捷开发是一种源自上世纪 90 年代的软件系统开发方法，此方法为团队构建快速响应需求变化的能力。 敏捷方法论的起源，可以追溯到 2001 年“敏捷宣言”的签署。

敏捷宣言的四个核心价值：

　　个体和互动 高于 流程和工具

　　交付的软件 高于 详尽的文档

　　客户合作 　高于 合同谈判

　　响应变化 　高于 遵循计划

　　虽然以上四个核心价值在强调“左侧部分”的重要性，但并没有否认“右侧部分”的价值。然而，在实践中，人们往往会按照自己的理解阐述“敏捷”。为了避免思想的曲解，敏捷宣言中还有 12 条原则，可以帮助我们正确理解含义。

敏捷宣言的 12 条原则：

1. 我们的首要任务是通过持续不断的快速交付高价值软件满足客户的需求。

2. 即使是在开发阶段的后期，我们也要欣然面对需求变化。敏捷流程响应变化的特性有助于客户获得竞争优势。

3. 数月到数周甚至更短的时间，频繁交付可运行的软件。

4. 在项目过程中，业务人员和开发人员必须每天在一起工作。

5. 积极的团队成员主导项目。为他们提供所需的环境和支持，并相信他们可以把工作做好。

6. 面对面交谈是最快速、最有效的沟通方式。

7. 可运行的软件是衡量进度的首要标准。

8. 敏捷流程提倡可持续合作。客户、开发人员和最终用户保持步伐一致，不断前行。

9. 不断追求先进的技术和优秀的设计保障，团队持续具备敏捷能力。

10. 简单，尽最大努力减少不必要的工作是敏捷流程的根本。

11. 自组织型的团队可以创造出最佳的架构、需求和设计。

12. 团队定期复盘，通过调节和调整工作模式不断提升效率。

　　基于敏捷思想和人们的不断实践，逐渐行成了多种敏捷方法。敏捷方法包括：Scrum、kanban、XP、DevOps。这此方法各有侧重点和适用场景。

敏捷方法对比表

　　Scrum 作为一种适用在多种行业的通用方法，已经成为了敏捷的代名词。XP 是最早用于软件系统开的敏捷方法。由于采用结对编程的方式导致开发成本提升，目前软件开发团队实践的方法多是 XP 和 Scrum 混合的方法。Kanban 源于工业化的生产车间，可以有效控制业务方的干扰，保持团队的工作节奏。Kanban 可视化的核心思想也被其它敏捷方法所采用。DevOps 是一种软件开发和运维领域的敏捷实践。通过自动化测试平台、自动化部署平台等技术，实现快速的系统开发、测试、上线部署的全流程。

　　敏捷和精益（Lean）作为两种流程改进的方法在实践 fp 过程中很容易混淆。两种方法都在通过各种方法和手段优化流程，缩短整个迭代周期。比如，软件系统开发过程中使用自动化测试平台对系统进行更快速、更全面的测试。但是，敏捷的目标是为了更好的适应环境改变而进行的自身调整；精益的目标是为了消除浪费而优化自身臃肿的过程。

　　敏捷思想的主旨是：充分发挥团队成员的主观能动性而不是循规蹈矩；工作内容分清主次而不是买椟还珠；重视客户体验而不是墨守成规；尊重客观事实进行实践而不是盲目奉行教条主义。敏捷虽然不是一颗“银弹”，但却是帮助我们面对未来挑战的利器。