105.敏捷开发模型 -ag凯发k8国际
文章目录
- 1.什么是敏捷开发?
- 2.敏捷开发宣言
- 3.站立会议的意义
- 4.敏捷开发想解决什么问题?
- 5.如果用敏捷的方式盖房子
- 6.敏捷开发和瀑布模型的差异
- (1)敏捷开发是怎么做需求分析的?
- (2)敏捷开发是怎么做架构设计的?
- (3)敏捷开发怎么保证项目质量的?
- (4)敏捷开发是怎么发布部署的?
- (5)敏捷开发的 sprint 和迭代模型的迭代有什么区别?
- 7.该不该选择敏捷开发?
- 8.总结
1.什么是敏捷开发?
- 敏捷开发,基于迭代的开发模型,它也强调快速交付,每次交付系统的部分功能,来保证客户满意度。在敏捷开发中,系统交付的周期称之为·冲刺(sprint)。
-
- 敏捷开发,在每个迭代后,都应该向客户收集反馈,然后在后面的迭代中,酌情加入客户反馈修改的内容。
- 严格来说,敏捷开发并不算是一种开发模型,更像是框架或指南。有各种开发模型来实现敏捷开发,比如说·极限编程(extreme programming),看板(kanban)和 scrum。
有人是这样理解敏捷开发模型的:
- 敏捷开发就是 scrum、极限编程;
- 敏捷开发就是每天站立会议、每两周一个 sprint(字面意思是冲刺,可以理解为迭代);
- 敏捷开发就是把需求变成故事,把故事写在便签上贴到白板,然后根据状态移动到不同的列;
- 敏捷开发就是用看板软件来管理项目。
然而,这些是敏捷开发的真正含义吗?
2.敏捷开发宣言
- 2001 初,17 位代表上述各种轻量级软件开发过程流派的领军人物聚集在一起,讨论替代瀑布模型这种重量级软件开发过程的新方法。
- 但是没能达成一致,所以退而求其次,把大家都认同的理念整理出来,也就是后来的敏捷宣言。这些人还一起成立了敏捷联盟。
我们再回头来看前面大家对敏捷的定义,其实都是在从方法论、工具等方面解释敏捷开发。 - 敏捷宣言指出:
敏捷不是一种方法论,也不是一种软件开发的具体方法,更不是一个框架或过程,而是一套价值观和原则。
各种敏捷框架、方法论和工具,就像是“术”,告诉你敏捷开发的方式,而敏捷则是“道”,是一套价值观和原则,指导你在软件项目开发中做决策。
3.站立会议的意义
-
敏捷开发中流行的站立会议,主要目的是为了保证团队成员充分的沟通,遇到困难可以及时寻求帮助。但是如果每天的站立会议流于形式,并不能起到有效的目的,则应该减少频度,甚至取消换成其他方式。
-
要不要在你的项目开发中使用站立会议,判断的依据就在于这样做是不是符合敏捷的价值观和原则。
-
也就是说,当你开发做决策的时候,遵守了敏捷开发的价值观和原则,不管你是不是用 scrum 或者极限编程,那么都可以算是敏捷开发。
4.敏捷开发想解决什么问题?
- 瀑布模型的典型问题就是周期长、发布烦、变更难,
- 敏捷开发就是快速迭代、持续集成、拥抱变化·
5.如果用敏捷的方式盖房子
-
客户想要盖一栋房子(·初步的想法·)。
-
产品经理和客户进行了初步的沟通,把用户的需求写成了一个个用户故事(用简单的用户故事代替繁重的需求文档),例如:
作为一个上班族,我想要一个卧室,以便于休息;
作为一个家庭主妇,我想要一个厨房,以便于做饭。
- 施工人员根据用户故事和客户进一步沟通(客户合作高于合同谈判),然后对用户故事进行设计和实现;
- 每个用户故事开发时,还要给一个测试机器人编写测试脚本,让机器人可以自动测试(大量采用自动化测试),并且做好的用户故事可以随时被测试验收(随时发布,持续集成);
- 每个 sprint 四个星期时间(时间盒子,迭代时间固定);
- 第一个 sprint 搭了个草棚,一张床就是卧室,厕所就挖了一个坑,厨房还来不及搭建(每个 sprint 会选择高优先级的用户故事),屋顶还在漏水(每个 sprint 会定期发布,客户可以随时看到可用版本,即使还不完整);
- 第二个 sprint 有了简易厨房,同时修复了屋顶漏水的毛病(每个 sprint 不仅完成用户故事,还会修复 bug);
- 第三个 sprint 升级成了小木屋,但是忘记加上窗户(敏捷推崇自动化测试,但可能会测试不完备);
- 第四个 sprint 升级成了砖瓦房,窗户也开好了,客户可以入住。但是这时候客户发现一家三口的话,完全不够用,需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室(响应变化高于遵循计划);
- 第五个 sprint,升级成了 3 个卧室,升级过程中把厨房下水道弄坏了(迭代过程中可能会导致质量不稳定);
- 第六个 sprint,修复了下水道的问题,房子也装修好了(迭代中不断完善);
- 客户验收使用(上线)。
用敏捷开发的方式,不再像瀑布模型那样有严格的阶段划分,会在迭代中不断完善;不再写很多文档,而是和客户一起紧密合作;不再抵制需求变更,而是即时响应变更;不再等到测试阶段才发布,而是随时发布,客户随时可以看到东西。
当然,采用敏捷开发的模式也存在一些问题,例如全程需要客户参与,由于测试相对少一些 ,问题也会相应多一些。
6.敏捷开发和瀑布模型的差异
- 这些年敏捷开发,已经逐步发展出一套 “scrum 极限编程 看板” 的最佳实践,
- scrum 主要用来管理·项目过程,
- 极限编程重点在工程实践,
- 而看板将工作流可视化。
基于 ·scrum 和极限编程的实践,来对比一下敏捷开发模型和瀑布模型的差异
(1)敏捷开发是怎么做需求分析的?
瀑布模型的一个重要阶段就是需求分析,要有严谨的需求分析,产生详尽的需求分析文档。而敏捷开发的需求,主要是来源于一个个小的用户故事,用户故事通常是写在卡片上的一句话,在 sprint 的开发中,再去确认需求的细节。
比如一个用户登录网站的需求,在用户故事里面就是一句话:
作为用户,我想登录网站,这样可以方便浏览。
好处是减少了大量需求文档的撰写,可以早些进入开发。但这个对开发人员在需求理解和沟通的能力上要求更高了。
(2)敏捷开发是怎么做架构设计的?
瀑布模型在需求分析完了以后,就需要根据需求做架构设计。而在敏捷开发中,并不是基于完整的用户需求开发,每个 sprint 只做一部分需求,所以是一种渐进式的架构设计,当前 sprint 只做适合当前需求的架构设计。
这种渐进式的架构设计,迭代次数一多,就会出现架构满足不了需求的现象,产生不少冗余代码,通常我们叫它技术债务,需要定期对系统架构进行重构。
(3)敏捷开发怎么保证项目质量的?
瀑布模型在编码完成后,会有专门的阶段进行测试,以保证质量。在敏捷开发的 sprint 中,并没有专门的测试阶段,这就依赖于开发功能的同时,要编写单元测试和集成测试代码,用自动化的方式辅助完成测试。
相对来说,这种以自动化测试为主的方式,质量确实是要有些影响的。
微软的 windows 就是个很好的例子,在 windows 10 之前,windows 的开发模式是传统的类瀑布模型,有很长一段测试的时间,质量有很好的保障,windows 10 开始,采用的是敏捷开发的模式,每月发布更新,稳定性要稍微差一些。
(4)敏捷开发是怎么发布部署的?
瀑布模型通常在编码结束后,开始部署测试环境,然后在测试阶段定期部署测试环境。测试验收通过后,发布部署到生产环境。
在敏捷开发中,这种持续构建、持续发布的概念叫持续集成,因为整个过程都是全自动化的,每次完成一个任务,提交代码后都可以触发一次构建部署操作,脚本会拿最新的代码做一次全新的构建,然后运行所有的单元测试和集成测试代码,测试通过后部署到测试环境。
持续集成是一个非常好的实践,极大的缩短和简化了部署的流程,而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求。
(5)敏捷开发的 sprint 和迭代模型的迭代有什么区别?
我们假设有两个团队,都要实现一个简单的用户系统,
- 一个团队用迭代模型,
- 一个团队用敏捷开发(scrum),
- 一个迭代 /sprint 的时间周期都是 2 周(10 个工作日)。
迭代模型所在的团队,产品经理会先花 2 天时间去分析需求,写成需求分析文档,架构师会花 3 天时间来做设计,程序员会花 3 天时间编码,测试再花 2 天时间去测试,最后上线用户系统。
再看敏捷开发的团队,product owner(类似于产品经理)会把需求拆分成了几个简单的用户故事:用户登录、用户注册、找回密码、修改资料,然后放到当前 sprint 的 backlog(任务清单),team(开发团队)成员开始从 backlog 选择用户故事。
-
程序员 a 选了“用户登录”这个用户故事,他会去找 product owner 确认需求细节,之后动手实现这个用户故事。
-
功能完成后,同时程序员 a 还写了单元测试代码和集成测试代码,对登录的功能写了自动化测试。完成后,通过持续集成工具测试和部署到测试环境。部署完成后,用户登录功能就可以进行使用了。
-
这个过程,程序员 a 可能花了 4 天时间,做完“用户登录”这个用户故事之后,他又开始继续选取“找回密码”的用户故事来做,4 天时间也完成了。
-
其他程序员也和程序员 a 一样,他们也会从 backlog 选择一些用户故事来做。
-
当团队中第 1 个用户故事部署完之后,测试人员就开始帮助测试,发现的 bug 都提交到了 backlog,程序员们在完成用户故事后,开始着手修复这些 bug,正好在最后 2 天都修复完成。
从上面的例子,你可以看出,迭代模型本质上是一个小瀑布模型,所以在一个迭代里面,需要完整的经历从需求分析,到设计、编码、测试这几个完整的阶段。
-
所以像瀑布模型一样,刚开始测试的时候是不稳定的,到测试后期才逐步稳定下来,一般迭代前期也会相对轻松一点,而后期测试阶段可能会时间很紧张。
-
敏捷开发的 sprint 中,没有严格的阶段划分,每个 sprint 周期里面会完成多个用户故事。在用户故事的开发时,会针对用户故事有编码、自动化测试编码。当一个用户故事开发完成,即可通过持续集成自动发布到测试环境。
-
相对来收,敏捷开发中,整个 sprint 的节奏是比较恒定,产品也是相对稳定的,即使用户故事没有完成,也不影响版本的发布。
-
因此,敏捷开发更注重软件开发中人的作用,需要团队成员以及客户之间的紧密协作。
7.该不该选择敏捷开发?
这些年,软件工程中一些好的实践,像持续集成、测试驱动开发、结对编程、看板等都来自于敏捷开发。可以肯定,敏捷开发是一种非常好的软件开发模式。
但在应用上,也确实需要一些满足一些条件才能用好,例如:
- 团队要小,人数超过一定规模就要分拆;
- 团队成员之间要紧密协作,客户也要自始至终深度配合;
- 领导们得支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性;
- 写代码时要有一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。
所以在选择敏捷开发这个问题上,你先要参考上面这些条件。
因为·敏捷开发对项目成员综合素质要求更高,做计划要相对难一些。如果团队大、客户不配合、领导不支持,再好的敏捷方法也很难有效实践起来。
如果你要实践敏捷开发,建议先找个小项目进行试点,能证明可行了,再进一步推广。有条件的话,可以和一些顾问公司合作,请人做专门的培训和指导。
如果不具备条件,应该考虑先把其中一些好的实践用起来,比如说持续集成、每日站会、自动化测试等。
8.总结
瀑布模型面向的是过程,而敏捷开发面向的是人。敏捷开发要解决的,恰恰是瀑布模型中存在的一些问题。
最后,在要不要用敏捷开发这个问题上,不用过于纠结,看好敏捷开发,那就放心去用,觉得时机还不成熟、还不够了解,就先试点或者只是先借鉴其好的实践。
·软件开发,最核心的是人,而不是用什么方法·,以前没有敏捷开发只有瀑布模型的时候,也一样诞生了大量伟大的软件,像 windows、office。现在有敏捷开发,更多的是让我们多了一些选择。
附上一个链接补充:https://mp.weixin.qq.com/s/pumnz91hiqgio4wscirtgq
参考:极客时间—软件工程之美
总结
以上是ag凯发k8国际为你收集整理的105.敏捷开发模型的全部内容,希望文章能够帮你解决所遇到的问题。
- 上一篇: 104. 软件工程的开发过程几种模型(瀑
- 下一篇: