一. 什么是敏捷开发
敏捷宣言指出:
敏捷不是一种方法论,也不是一种软件开发的具体方法,更不是一个框架或过程,而是一套价值观和原则。
就是说,当你开发决策的时候,遵守了敏捷开发的价值观和原则,不管你是不是用Scrum或者极限编程,那么都算敏捷开发。
二.敏捷开发解决了什么。
敏捷开发就是想解决破布模型这样的重型软件开发存在的问题,用一种轻量的、敏捷的开发方式来概算甚至是替代它。
瀑布模型的典型问题就是周期长,发布烦,变更难。
敏捷开发就是快速迭代,持续集成,拥抱变化。
三.怎么使用敏捷开发项目。
使用敏捷开发的具体步骤模拟:
1.客户想要盖一栋房子(初步的想法)。
2.产品经理和客户进行了初步的沟通,把用户的需求写成了一个个用户故事(用简单的用户故事代替繁重的需求文档),例如:
作为一个上班族,我想要一个卧室,以便于休息;
作为一个家庭主妇,我想要一个厨房,以便于做饭。
3.施工人员根据用户故事和客户进一步沟通(客户合作高于合同谈判),然后对用户故事进行设计和实现;
4.每个用户故事开发时,还要给一个测试机器人编写测试脚本,让机器人可以自动测试(大量采用自动化测试),并且做好的用户故事可以随时被测试验收(随时发布,持续集成);
5,每个 Sprint 四个星期时间(时间盒子,迭代时间固定);
6.第一个 Sprint 搭了个草棚,一张床就是卧室,厕所就挖了一个坑,厨房还来不及搭建(每个 Sprint 会选择高优先级的用户故事),屋顶还在漏水(每个 Sprint 会定期发布,客户可以随时看到可用版本,即使还不完整);
7. 第二个 Sprint 有了简易厨房,同时修复了屋顶漏水的毛病(每个 Sprint 不仅完成用户故事,还会修复 Bug);
8.第三个 Sprint 升级成了小木屋,但是忘记加上窗户(敏捷推崇自动化测试,但可能会测试不完备);
9.第四个 Sprint 升级成了砖瓦房,窗户也开好了,客户可以入住。但是这时候客户发现一家三口的话,完全不够用,需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室(响应变化高于遵循计划);
10.第五个 Sprint,升级成了 3 个卧室,升级过程中把厨房下水道弄坏了(迭代过程中可能会导致质量不稳定);
11.第六个 Sprint,修复了下水道的问题,房子也装修好了(迭代中不断完善);
12.客户验收使用(上线)。
用敏捷开发的方式,不再像瀑布模型那样有严格的阶段划分,火灾迭代中不断完善;不在写很多文档,而是和客户一起紧密合作;不再地址需求变更,而是即使响应变更;不在乎等到测试阶段才发布,而是随时发布,何不随时可以看到东西。
敏捷开发的问题很会让你明显:全程需要客户参与,由于测试相对少一些,问题也会多一些。
四.敏捷开发和瀑布开发的差异。
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 的节奏是比较恒定,产品也是相对稳定的,即使用户故事没有完成,也不影响版本的发布。
因此,敏捷开发更注重软件开发中人的作用,需要团队成员以及客户之间的紧密协作。
五.怎么选择开发模型。
在实际工作中选择敏捷开发,还是有些条件的:
1.团队要小,人数超过一定规模就要分拆;
2.团队成员之间要紧密协作,客户也要自始至终深度配合;
3.领导们得支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性;
4.写代码时要有一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。
所以在选择敏捷开发这个问题上,你先要参考上面这些条件。
敏捷开发,其实对项目组成员的综合素质的要求更高,做计划要相对难一些。如果团队大、客户不配合、领导不支持,再好的敏捷方法实施也有困难。
如果现在不具备这些条件,就可以考虑NBA其中一些好的东西先用起来。比如说:每日例会,持续集成、自动化测试等。
此内容极客时间版权所有,本人只是学习之后做一个笔记记录如有用做任何商业用途,极客时间可能追究法律责任,本人一概不负责,分享和转载请注明:https://time.geekbang.org/column/article/543f03f9b434f06485ab631f6984d21b/share?code=mybUYSWKKskrdOz0DM6%2FKO%2F9RDfR5YCw65TVohaq%2FrE%3D