什么是敏捷开发？

Posted 2021-04-25 红猴子

 「敏捷开发」一词，想必大家都不陌生，不过对于大多数人来说，可能这只是一个书上见过、听说过、然而并没有真实接触过的虚无概念。因为看不见摸不着，同时也没有衡量标准。

想想这也是有道理的。

不同于 Java，Spring 这些编程语言和框架，也不同于版本管理、持续集成、Bug 追踪这些实实在在的工具，「敏捷开发」其实并不是一门技术或者工具，它只是一个软件开发方法，也可以说是思想。

首先，澄清一个误区。

这里的敏捷，并不意味着快速，越快越好，加班加点写代码、赶进度，虽然字面上看貌似是这样的。

据说这个概念最一开始被提出的时候，是被命名为 「lightweight processes」，也就是轻量级软件开发过程，只不过后来这个名称由于种种原因没有被采纳，而是用了「agile」- 敏捷。

所以，敏捷我们应该看作是轻量级、高效，而不应是快速。

软件开发向来是一门学问，有很多人提出过不同的观点，各种软件开发、项目管理方法层出不穷，有的时候应用这些方法也是一件头疼的事情，太笨重、冗余、繁杂的方法只会弄巧成拙、拖慢开发进度。

敏捷开发中的轻量级由此得名。

敏捷开发的定义这种很官方的内容我就不说了，只会让人看起来更懵，你只要知道它是一种软件开发方法就行了。

具体是什么样的一种方法呢？

我来说下我的理解，尽量说的通俗易懂。

敏捷开发中，最核心的就是人。

不是说每个人坐在自己的格子间里，各自独立开发，定期向领导汇报工作就完事了，敏捷开发需要做到几个关键点：

定期会面。通过定期高效会议让开发人员保持紧张有序的工作状态。

及时告知项目进展。鼓励遇到问题一定要及时告知，让所有利益相关者都能够及时了解项目的最新进展。

知识共享。把知识分享出来，可以提升整个团队的开发能力，是对团队的一种投资。

代码共享。把代码集中在版本管理工具之中，团队任何人都有访问权限。

代码审查。针对代码的每个改动，都需要相关人员做代码审查。

敏捷开发与传统瀑布式开发一个最大的不同就是，并非一次定终身。

软件开发不是线性过程，它存在很多的不确定性，有一定的动态波动，所以需要不断的反馈、调整，快速响应变化。

需求调整。在产品落地前，你是不可能制定出完美需求方案的，客户也并不一定能够清晰的知道他想要的软件产品到底是什么样子。所以，要做好需求不断变化的心理准备，也要有快速响应需求变化的能力。

功能调整。收集客户反馈、用户反响，来不断调整和优化软件功能。

代码重构。在开发的过程中，需要不断的重构代码，保持代码清晰、内聚、整洁。

传统软件开发的方式是，等代码编写完毕，所有功能都完成之后，再集中测试和上线，在这之前，软件都是用户不可用的。

在信息快速发展的今天，这显然太落伍了，可能等你软件开发个一年半载，外面都变天了。

敏捷开发，另一大特色，就是保持软件一直可用，在最小可用版本基础之上，不断做功能迭代，不断发布新的版本。

通俗点讲就是，先做一个简化版本出来，让用户一直有软件可用，而后再逐步添加更多的功能，「小步快跑」式的做开发，而非一步到位。

这样做的好处，也是为了能够不断收集用户反馈与需求，及时调整开发方向。

这一条是上一条的延伸。

所谓「迭代」就是，重复下一个开发周期，此刻你可以想象一下 while loop。

用迭代的方法在前一版本之上逐步开发新的功能，发布新的版本，即：增量发布。

迭代周期不宜过长，一年半年显然就太久了，尽量要缩短迭代周期，保持开发过程稳步前进。

但短迭代并不意味着太过频繁，每天或者每周迭代一次的话，很可能会过犹不及，半个月到一个月应该是一个不错的时间节点。当然这只是参考建议，具体的迭代周期还应根据真实情况量力而行。

还记得前几天有同学留言说，自己的课程设计各个模块都没问题，但是合在一起就不工作了，马上就要交差了，头疼。

这就是不提早集成的结果。

「集成」的含义就是，把软件的各个模块，新旧代码统一整合在一起，能够正确编译、运行，并且能够通过一系列的单元测试。

敏捷开发要求开发人员，不要临到软件发布或者交付的当天才开始集成，也不要很久才集成一次，尽可能的做到提早继承、频繁集成。理论上讲，每添加进一些新的代码，最好都要做一次集成。

通过提早集成、不断集成，能够尽早发现代码中的问题，保持软件的状态一直是可用的。

敏捷的另一个关键点是，通过技术手段把集成、测试与部署这些非常耗时的操作自动化。

至于为什么要自动化，如果你是一个人开发一个几千行的程序，那确实没必要自动化，确切的说，也没必要应用什么敏捷开发。

针对开发大型软件的团队而言，编译、测试过程有可能都非常的耗时，编译有时会花上半天的时间，测试可能会持续好几天。而且是多人协作共同开发，如果纯手动的话，你想象一下如果两个人想前后脚提交代码，岂不是要等上好几天的时间，等前面那个人集成结束之后，后面那个人才可以开始集成？

把集成、测试与部署自动化的好处就是，把这些耗时的纯体力劳动扔给机器去做，它做完了，只要返回你一个最终结果就好了，而且两个人同时 Check In 时也不会受到影响。

说起来可能比较抽象，我找来了一幅图帮助理解。

这副图涵盖了自动化集成、测试以及部署的流程。

开发者 Check In 之后的所有工作将都交给机器去做，它们都有专门的工具 ，包括集成工具、测试工具，当然这些工具可以使用第三方的，也可以自己开发。

一般情况下，这一系列的工作都跟版本管理工具绑定在一起，你只要 Check In 就会触发集成、测试，甚至还有部署。而你，只要专心的等待结果就好。

最后，总结一下。

在流程上，敏捷最大的特色是迭代式开发。

但迭代式开发并非敏捷思想的全部，团队协作与自动化开发也是敏捷思想的精髓所在。

现在想想，我所经历过的公司就是采用的敏捷开发，尽管「敏捷」一词从未被任何人提起过。