在《软件过程模型的管道理论 》中我们介绍了软件过程的模型以及管道理论。从本文开始，我们将开始一个新的系列，讨论目前主流的敏捷方法。结合软件开发过程，我们把敏捷的理念分成四大块内容，即适应变化、团队协作、交付价值和过程改进。
1. 适应变化
敏捷最为人称道的一个理念就是“拥抱变化”。为什么“拥抱变化”这一理念会深入人心，程度上是受软件开发的本质特征所决定，即任何软件的需求并不是在一开始就能完全确定。期望我们的用户、客户在开发之前想清楚真正想要的软件是不现实的，软件开发的过程就是不断向用户交付软件产品并不断激发用户或客户发现需求的过程。
逐步提炼需求的现实意味着软件开发应该以小批量、频繁交付的节奏进行，这是敏捷开发的一条基本原则，也是软件开发的客观规律。在需求响应周期相同的情况下，一次开发的需求量越小，开发资源利用率就越高；在资源利用率相同的情况下，批量越小，其交付周期就越短（见下图）。
敏捷开发的另一条重要原则是即使在开发后期，我们也欢迎需求变化。因为变化势必会发生，一开始就制作一个大而全的机会并付诸于开发实施容易造成返工。对于软件开发的演进应该采用迭代思想，根据迭代累积的经验和需求变化的情况对计划作出调整。
如何适应变化的另一个思路是建立强大的反馈机制，反馈意味着提供快速响应变化的信息来源。利用多层次的反馈手段，在不大变化的环境中能够使信息透明，了解变化所带来的影响以及与变化后目标的差距，从而不断调整开发过程。
2. 团队协作
敏捷方法认为，在产品开发团队中，面对面交流是最有效的沟通方式。而沟通的最大障碍是不同职能部门的人员所具有的不同视图和视角。产品由产品的思维模式，技术也有技术的工作方法，在两者之间如果无法建立一种统一语言（Ubiquitous Language），对需求的理解就会参数偏差。所以，在整个产品开发过程中，拥有专业领域知识的业务人员和开发人员应该每天都坐在一起工作，这是敏捷方法的一条重要原则。
另一方面，敏捷团队的协作方式需求从传统型转变成敏捷型，即从垂直管理转变到水平管理。在传统方式下，管理者努力控制团队，通过制定详细的开发计划和安排，通过复杂的管理手段和规则监控开发过程。但在敏捷团队中，更多的是激励机制。以受激励的开发人员为核心构建团队，帮助团队提供资源、排除障碍，并营造自我管理的工作方式，相信他们可以把工作做好。
3. 交付价值
敏捷思想认为最优先要做的是尽早、持续地交付有价值的软件从而让客户满意，这是最重要的一条原则。一方面，敏捷方法所提倡的适应变化的思维能够为客户维持竞争优势，因为面对需求变化的第一步是尝试从客户的角度看问题。
对于软件开发而言，项目管理三角形中的时间和成本往往无法改变，在时间、成本存在冲突情况下，能够改变的就是范围。敏捷关注频繁的交付系统，且指交付刚刚好的系统，从项目管理的角度讲就是不要对开发范围进行镀金，对客户需求进行深入理解并简化。
4. 过程改进
开发过程中普遍存在浪费，其表现形式有很多，如部分未完成的工作、完成之后未应用的特性，由于人员更替所需要的工作交接和再次学习成本等。敏捷原则提倡尽最大可能减少不必要工作，通过识别和消除浪费来提高开发效率。
任何软件开发工作都是有时效性和阶段性的，即不存在一成不变的开发过程，也不存在完美到不需要做任何调整的过程。敏捷开发强调过程改进，通过团队定期反思来探寻如何提升效率的方法，并依此调整。
敏捷的理念为我们提供了指导思想和原则，业界围绕这些思想和原则诞生了一批具体的实现方案和框架。本系列文章后续内容将结合敏捷理念与管道理论对目前主流的Scrum、精益、看板等方法做进一步阐述。
如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型，或扫描下面的二维码。
我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流
