06 | 敏捷开发

发布于 2021-11-25  644 次阅读


一、什么是敏捷开发?

敏捷不是一种方法论,也不是一种软件开发的具体方法,更不是一个框架或过程,而是一套价值观和原则。

也就是说,当你开发做决策的时候,遵守了敏捷开发的价值观和原则,不管你是不是用 Scrum 或者极限编程,那么都可以算是敏捷开发。

敏捷开发就是快速迭代、持续集成、拥抱变化。

 

二、敏捷开发想解决什么问题?

如果你仔细读了敏捷宣言,你会发现,宣言中右边的内容其实都是瀑布模型核心的内容:流程和工具、详尽的文档、合同谈判、遵循计划。

虽然敏捷开发并未对瀑布模型的价值进行否定,但也表明了瀑布模型做的还不够好,同时提出了一套自己的价值观。

比如说,我们开始做一个新项目,需要从客户那里收集整理需求,如果按照传统的软件开发模式,我们需要在开发前获得所有需求然后和客户签订合同,在发布前都不会轻易修改需求。

但是如果我们采用敏捷开发模式来开发项目,那这样做显然违背敏捷的价值观:“客户合作高于合同谈判”。所以如果是敏捷开发,在每个迭代后,都应该向客户收集反馈,然后在后面的迭代中,酌情加入客户反馈修改的内容。

结合敏捷开发提出的背景,你其实不难发现,敏捷开发就是想解决瀑布模型这样的重型软件开发方法存在的问题,用一种轻量的、敏捷的方法来改善甚至是替代它。这些年敏捷开发也是一直这么做的。

瀑布模型的典型问题就是周期长、发布烦、变更难,敏捷开发就是快速迭代、持续集成、拥抱变化。

 

三、如果用敏捷的方式盖房子

在讲瀑布模型的时候,我拿盖房子举了个例子,

如果改成用敏捷开发的模式盖房子,则会是这样子的:

  • 客户想要盖一栋房子(初步的想法)
  • 产品经理和客户进行了初步的沟通,把用户的需求写成了一个个用户故事(用简单的用户故事代替繁重的需求文档)
  • 例如:作为一个上班族,我想要一个卧室,以便于休息;作为一个家庭主妇,我想要一个厨房,以便于做饭。
  • 施工人员根据用户故事和客户进一步沟通(客户合作高于合同谈判),然后对用户故事进行设计和实现;
  • 每个用户故事开发时,还要给一个测试机器人编写测试脚本,让机器人可以自动测试(大量采用自动化测试),并且做好的用户故事可以随时被测试验收(随时发布,持续集成)
  • 每个 Sprint 四个星期时间(时间盒子,迭代时间固定)
  • 第一个 Sprint 搭了个草棚,一张床就是卧室,厕所就挖了一个坑,厨房还来不及搭建(每个 Sprint 会选择高优先级的用户故事),屋顶还在漏水(每个 Sprint 会定期发布,客户可以随时看到可用版本,即使还不完整)
  • 第二个 Sprint 有了简易厨房,同时修复了屋顶漏水的毛病(每个 Sprint 不仅完成用户故事,还会修复 Bug)
  • 第三个 Sprint 升级成了小木屋,但是忘记加上窗户(敏捷推崇自动化测试,但可能会测试不完备)
  • 第四个 Sprint 升级成了砖瓦房,窗户也开好了,客户可以入住。但是这时候客户发现一家三口的话,完全不够用,需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室(响应变化高于遵循计划)
  • 第五个 Sprint,升级成了 3 个卧室,升级过程中把厨房下水道弄坏了(迭代过程中可能会导致质量不稳定)
  • 第六个 Sprint,修复了下水道的问题,房子也装修好了(迭代中不断完善);
  • 客户验收使用(上线)。

用敏捷开发的方式,不再像瀑布模型那样有严格的阶段划分,会在迭代中不断完善;不再写很多文档,而是和客户一起紧密合作;不再抵制需求变更,而是即时响应变更;不再等到测试阶段才发布,而是随时发布,客户随时可以看到东西。

当然,采用敏捷开发的模式也存在一些问题,例如全程需要客户参与,由于测试相对少一些 ,问题也会相应多一些。

 

四、敏捷开发和瀑布模型的差异

这些年敏捷开发,已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践,Scrum 主要用来管理项目过程,极限编程重点在工程实践,而看板将工作流可视化。

我将基于 Scrum 和极限编程的实践,来对比一下敏捷开发模型和瀑布模型的差异。

1. 敏捷开发是怎么做需求分析的?(用户故事)

瀑布模型要求产生详尽的需求分析文档,敏捷开发的需求来源于一个个的用户故事:

  • 作为用户,我想登录网站
  • 作为客人,我想有个卧室休息

在Sprint的开发中再去确认具体需求的细节。

好处:减少了大量需求文档的编写,可以早些进入开发;

但对开发人员在需求理解和沟通的能力上要求更高了。

2. 敏捷开发是怎么做架构设计的?(一部分需求,渐进式架构,会产生技术债务)

瀑布模型在需求分析完了以后,就需要根据需求做架构设计。

而在敏捷开发中,并不是基于完整的用户需求开发,每个 Sprint 只做一部分需求,所以是一种渐进式的架构设计,当前 Sprint 只做适合当前需求的架构设计。

这种渐进式的架构设计,迭代次数一多,就会出现架构满足不了需求的现象,产生不少冗余代码,通常我们叫它技术债务,需要定期对系统架构进行重构。

3. 敏捷开发怎么保证项目质量?(编写开发功能时编写单元测试和集成测试,自动化测试)

瀑布模型在编码完成后,会有专门的阶段进行测试,以保证质量。

在敏捷开发的 Sprint 中,并没有专门的测试阶段,这就依赖于开发功能的同时,要编写单元测试和集成测试代码,用自动化的方式辅助完成测试。

相对来说,这种以自动化测试为主的方式,质量确实是要有些影响的。

4. 敏捷开发是怎么发布部署的?(持续集成,每完成一个任务构建部署,测试)

瀑布:编码-->测试环境-->生产环境

瀑布模型通常在编码结束后,开始部署测试环境,然后在测试阶段定期部署测试环境。测试验收通过后,发布部署到生产环境。

敏捷开发:持续集成

在敏捷开发中,这种持续构建、持续发布的概念叫持续集成,因为整个过程都是全自动化的,每次完成一个任务,提交代码后都可以触发一次构建部署操作,脚本会拿最新的代码做一次全新的构建,然后运行所有的单元测试和集成测试代码,测试通过后部署到测试环境。

持续集成是一个非常好的实践,极大的缩短和简化了部署的流程,而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求。

5. 敏捷开发的 Sprint 和迭代模型的迭代有什么区别?

增量模型和迭代模型,这两种也是一种快速迭代的方式,那么敏捷开发和 迭代模型的区别是什么?

迭代模型本质上是一个小瀑布模型,所以在一个迭代里面,需要完整的经历从需求分析,到设计、编码、测试这几个完整的阶段。

所以像瀑布模型一样,刚开始测试的时候是不稳定的,到测试后期才逐步稳定下来,一般迭代前期也会相对轻松一点,而后期测试阶段可能会时间很紧张。

敏捷开发的 Sprint 中,没有像瀑布模型那样严格的开发阶段划分,而是一个个循环迭代的 Sprint

举例来说,一个瀑布模型的项目,可能会按照阶段分成:2 周需求分析,2 周设计,4 周编码,2 周测试,然后上线发布,一共 10 周。如果用敏捷开发的方式来进行,那么可能会是每 2 周一个 Sprint,每个 Sprint 结束后,都会发布上线,每次发布的可能只是完整功能的一部分,但是每次发布的都是一个可用的版本,通过多个 Sprint 的迭代,最终完成项目开发。具体到每一个 Sprint 的开发周期中,在一个 Sprint 中会有多个小的开发任务,这些开发任务主要是新功能的开发和 Bug 的修复。

由于每个 Sprint 周期很短,所以不能像瀑布模型那样有充足的时间去做需求分析、设计和测试,那么敏捷开发中怎么保证质量呢?在敏捷开发中,通常用“用户故事”这样的方式来代替传统的需求分析,也就是以用户故事的形式,对一个需求进行简单的描述,配合关键的测试用例,并且和需求方的紧密沟通,让开发人员可以理清楚需求;通过“只做刚刚好的设计”来节约设计上的时间;通过“自动化测试”、“持续集成”来提升测试效率。

相对来说,敏捷开发中,整个 Sprint 的节奏是比较恒定,产品也是相对稳定的,即使用户故事没有完成,也不影响版本的发布。因此,敏捷开发更注重软件开发中人的作用,需要团队成员以及客户之间的紧密协作。

五、什么时候选择敏捷开发?

条件:

  • 团队要小,人数超过一定规模就要分拆;
  • 团队成员之间要紧密协作,客户也要自始至终深度配合;
  • 领导们的支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性;
  • 写代码时要有一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。

因为敏捷开发对项目成员综合素质要求更高,做计划要相对难一些。如果团队大、客户不配合、领导不支持,再好的敏捷方法也很难有效实践起来。

如果你要实践敏捷开发,建议先找个小项目进行试点,能证明可行了,再进一步推广。

有条件的话,可以和一些顾问公司合作,请人做专门的培训和指导。如果不具备条件,应该考虑先把其中一些好的实践用起来,比如说持续集成、每日站会、自动化测试等。

 

六、总结

流程、工具、文档、合同、计划都是工业化的标志。它们带来了稳定的质量、惊人的效率、超大规模的协作,对于软件工业也是如此。

然而软件工业具备轻资产、知识密集型、从业人员素质高等特点,充分发挥人的创造力和价值,是其相较传统工业更高阶的要求。加之软件工程面对的不确定性与复杂度更显著。于是“个体和互动高于流程和工具,工作的软件高于详尽的文档,客户合作高于合同谈判,响应变化高于遵循计划”的敏捷思想应运而生。

通过用户故事,理解用户需求。在迭代中采用渐进的架构设计。定期重构解决技术债务。功能开发的同时编写自动测试代码。自动化持续构建。

由于淡化了部分工业思维中兼顾稳定、质量、效率、成本的传统手段,敏捷思想的最终落地,需要素质极高的从业人员参与其中,且数量不宜过多,以此来弥补流程上的缺失。同时要团队与客户紧密协作,上级的充分信任,才能够有效发挥其灵活应变,又万变不离其宗的优势。这是大胆的返璞归真,好似回到了瀑布模型前的蛮荒时代,实则是更高级的打法,就像独孤九剑一般。所以,敏捷开发“道”的属性更浓。

敏捷开发具有快速迭代、持续集成、拥抱变化等诱人的特点,但也有苛刻的条件要求。不过,即使无法推行完整的敏捷开发,依旧可以在传统模式下,有针对性的应用敏捷开发的实践方法。


她喜欢所以就做咯