（本文基于一线实践经验，不试图覆盖全部理论分支，重点讨论可执行部分）

敏捷 和 精益

敏捷（开发）始于 “敏捷宣言”，对迭代、增量式的软件开发模式进行了总结，目的是应对快速变化的需求，并提升软件的质量。

精益（生产）则是从日本制造业 —— 丰田生产系统（TPS）总结和演进而来，用最少的工作，创造更多的价值。

两者起源不同，但在价值观和实践目标上高度重叠。我长期关注的是以下问题：

• 软件开发到底是 “创造” 活动，还是 “制造” 活动
• 软件交付 和 （工业）产品交付有什么区别
• 软件的流水线 和 工厂流水线 的相似性
• ...

在追溯 Scrum、Kanban 等 “敏捷项目管理方法” 的过程中，我发现很多工具和方法论都是来源于制造业。现在大多数软件都更像是一种工业产品，有明确的设计图（架构图）、有明确的工艺（框架/语言）、有明确的工人（程序员）和明确的步骤（开发、部署、维护）。但，软件也具备 “研究型” 产品的特质，适用性广（各行各业）、材料易获取（只是代码而已）、个人共享可占比高（一个高手顶十个）。

所以软件开发既要借鉴制造业的流程方法，也要保留软件产品自身的探索属性。

技术/管理 x 理论/实践

• 广义的敏捷，是包含如极限编程、整洁代码、DevOps 等方法学和工具的一个集合体。
• Scrum 和 Kanban 的原型其实都是始于丰田（早于敏捷概念的提出），但后来被引入到软件开发管理上，逐渐变成了敏捷管理方法。（Ken Schwaber 即是敏捷宣言的发起人，又是现代 Scrum 的创立者）
• 将精益价值流的分析迁移到软件开发过程中，推动了软件交付的自动化，以减少各个流程交替的时间和上下文切换的消耗
• 精益价值树也可以被用来聚焦产品的核心愿景和投入，以便确立 MVP

个人 团队 部门 企业

• 从组织层面看，敏捷更关注个人（毕竟一开始程序员比较少），如 TDD、结对 等工程实践
• 随着团队体量的增加、软件复杂性的提升、知识负载的增加
  • 一方面需要引入项目管理管理大型团队，如 Scrum、Kanban
  • 一方面需要降低认知负载，如 DDD、平台化、组件化/模块化
  • 一方面需要革新技术提升效率，如 DevOps、自动化、云原生
• 而以 IT 技术为核心的公司，因为 “产品” 的特殊性，其组织结构也会发生转变（或是本就如此）
  • 层级较为扁平
  • 教练 coach over 导师 mentor，崇尚自我提升自我学习
  • 自管理团队，以产品、项目团队为单元，而非横向部门