一、敏捷开发
有人认为:
- 敏捷开发就是 Scrum、极限编程;
- 敏捷开发就是每天站立会议、每两周一个 Sprint(字面意思是冲刺,可以理解为迭代);
- 敏捷开发就是把需求变成故事,把故事写在便签上贴到白板,然后根据状态移动到不同的列;
- 敏捷开发就是用看板软件来管理项目。
然而,这些是敏捷开发的真正含义吗?
1、敏捷开发的背景
要理解敏捷开发,我们先要了解其诞生背景。在 2001 年那会,“重型”的瀑布模型还是主流,整个流程走完通常周期很长。长周期导致风险增加、难以响应变化。
由瀑布模型衍生出很多模型,除上篇介绍的,还有当时不怎么有名,现在却如雷贯耳的轻量级开发方法,例如极限编程(Extreme Programming,XP)、Scrum 等。
2001 初,17 位代表上述各种轻量级软件开发过程流派的领军人物聚集在一起,讨论替代瀑布模型这种重量级软件开发过程的新方法。
但是没能达成一致,所以退而求其次,把大家都认同的理念整理出来,也就是后来的敏捷宣言。这些人还一起成立了敏捷联盟。
敏捷宣言指出:敏捷不是一种方法论,也不是一种软件开发的具体方法,更不是一个框架或过程,而是一套价值观和原则。
当你开发做决策的时候,遵守了敏捷开发的价值观和原则,不管你是不是用 Scrum 或者极限编程,那么都可以算是敏捷开发。
敏捷开发就是想解决瀑布模型这样的重型软件开发方法存在的问题,用一种轻量的、敏捷的方法来改善甚至是替代它。
- 瀑布模型的典型问题就是周期长、发布烦、变更难。
- 敏捷开发就是快速迭代、持续集成、拥抱变化。
2、什么是敏捷开发
- 敏捷开发是一种以人为核心,迭代,循序渐进的开发方式。
- 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。
- 简单的说,敏捷开发并不是追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。
敏捷是项目管理和软件开发的一种迭代方法,可帮助团队更快地向客户,交付价值,减少麻烦,敏捷团队不是把所有事情都押在“大爆炸”的发布上,而是以小的但可消耗的增量交付工作,需求、计划和结果会得到持续评估,因此团队拥有快速响应变化的机制。
3、敏捷开发和瀑布模型的差异
这些年敏捷开发,已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践,Scrum 主要用来管理项目过程,极限编程重点在工程实践,而看板将工作流可视化。
基于 Scrum 和极限编程的实践,来对比一下敏捷开发模型和瀑布模型的差异。
(1) 敏捷开发是怎么做需求分析的?
- 瀑布模型:详尽的需求文档。
- 敏捷开发:用户故事。在 Sprint 的开发中,再去确认需求的细节。
用户故事例如:作为用户,我想登录网站。
好处是减少了大量需求文档的撰写,可以早些进入开发。但这个对开发人员在需求理解和沟通的能力上要求更高了。
(2)敏捷开发是怎么做架构设计的?
在敏捷开发中,每个 Sprint 只做一部分需求,所以是一种渐进式的架构设计,当前 Sprint 只做适合当前需求的架构设计。
缺点:这种渐进式的架构设计,迭代次数一多,就会出现架构满足不了需求的现象,产生不少冗余代码,通常我们叫它技术债务,需要定期对系统架构进行重构。
(3)敏捷开发怎么保证项目质量的?
- 瀑布模型在编码完成后,会有专门的阶段进行测试,以保证质量。
- 在敏捷开发的 Sprint中,并没有专门的测试阶段,这就依赖于开发功能的同时,要编写单元测试和集成测试代码,用自动化的方式辅助完成测试。
缺点:相对来说,这种以自动化测试为主的方式,质量确实是要有些影响的。
(4)敏捷开发是怎么发布部署的?
-
瀑布模型通常在编码结束后,开始部署测试环境,然后在测试阶段定期部署测试环境。测试验收通过后,发布部署到生产环境。
-
在敏捷开发中,这种持续构建、持续发布的概念叫持续集成,因为整个过程都是全自动化的,每次完成一个任务,提交代码后都可以触发一次构建部署操作,脚本会拿最新的代码做一次全新的构建,然后运行所有的单元测试和集成测试代码,测试通过后部署到测试环境。
4、该不该选择敏捷开发?
这些年,软件工程中一些好的实践,像持续集成、测试驱动开发、结对编程、看板等都来自于敏捷开发。可以肯定,敏捷开发是一种非常好的软件开发模式。
但在应用上,也确实需要一些满足一些条件才能用好,例如:
- 团队要小,人数超过一定规模就要分拆;
- 团队成员之间要紧密协作,客户也要自始至终深度配合;
- 领导们得支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性;
- 写代码时要有一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。