写在前面

换了新东家以来，由于研发模式的差异，对在上一个东家涉及的一些知识暂时无实践机会，其中觉得最遗憾的应该是敏捷相关的知识体系和实践经历。得益于上个东家的信任，有幸参与过公司敏捷团队的教练工作，同时也在公司的安排下参与了ACP培训，这个培训至今仍然是我觉得最有价值的一次培训，虽然涉及技术内容不多，但是却通过敏捷这一条线将自己所涉及的一些技术串联起来。在这一系列学习和实践中，也结合敏捷的思想有一些自己的感悟。在这记录下来，以便后面回过头来参考。其中会大量参考ACP培训的内容，也算是一个学习总结。

敏捷出现的背景

从软件作坊到软件危机，再到软件工程，传统的软件工程理论使得软件系统的开发流程变得越来越复杂，导致：

• 过长的开发周期

• 无法应对迅速变化的市场环境，需求很难修改

• 超预算开发

• 项目进度检查困难

• 最终交付的软件，不一定能满足用户需求

• 人员流动频繁，官僚制度严重

实际操作时可能遇到的问题：

• 一方面市场的需求瞬息万变，很难实现产品需求的明确且完整地收集

• 一方面技术的发展也日新月异，对于所定义的功能的可实现性也面临着多重不确定性的因素

传统的研发模式中，比较常见的就是长期性计划，例如一个项目可能持续半年，项目管理者需要提前将这半年可能发生的所有异常情况都考虑完全，从而制定细致周到的项目计划。不管用哪想这都是不可能的。

有道是人算不如天算，过一天算一天似乎更合适。当然这是个夸张的说法,本质上的意思是应该做短期计划，并且不断根据实际情况调整。

敏捷是什么

• 敏捷不是一个流程或方法

• 敏捷不是一套固定模板

• 敏捷不是一种可以直接重用的方法

敏捷是一种为了适应不断变化的需求，以人为核心，通过迭代增量等方式的开发方法。其本质是一种实践。

曾和同事交流说敏捷和Scrum，XP的关系，个人理解敏捷是一种思想，而Scrum，XP这些是在敏捷思想指导下总结出现的实践。

敏捷的三根支柱

敏捷是基于经验型的方法，并不依赖于预测，其成功依赖于三根支柱：

• 透明性：信息透明

• 经常性检查：获得反馈

• 适应：根据反馈快速调整并做出改变

三大支柱在敏捷实践的活动中都会有体现，所有活动的开展都应该围绕这三大原则。

瀑布VS敏捷

实际上大部分项目都会是传统型和敏捷型混合，比如研发人员吐槽最多的需求的不断变化，在传统型项目中出现也比较频繁。

敏捷与其他技术实践的关系

可能存在的乱象是将敏捷与其他技术实践完全隔离，例如一些企业会强调要做持续集成，持续交付，DevOps等等实践，但是却不把敏捷的实施作为第一步，同理还包括自动化测试。

当然并非是不做敏捷这些实践就无法实施，比如自动化测试，即使是在传统的研发模式中仍然有其用武之地。但是就如每个人都在寻找各自的真命天子(女)一样，敏捷就如这些实践的真命天子(女)，只有在敏捷的研发模式中，这些实践才能更好的发挥其威力。