敏捷开发模式(敏捷开发瀑布开发)

本文将从软件工程的角度谈敏捷开发模型,涉及瀑布、V字、RUP、迭代、螺旋等开发模型,同时重点分享敏捷模型的核心思想。文章分为两部分:通过举例和对标其他行业,聊聊

本文将从软件工程的角度谈敏捷开发模型,涉及瀑布、V字、RUP、迭代、螺旋等开发模型,同时重点分享敏捷模型的核心思想。

敏捷开发模式(敏捷开发瀑布开发)插图文章分为两部分:

通过举例和对标其他行业,聊聊软件开发模型的发展演进。聊聊敏捷的核心思想。

敏捷开发是互联网领域流行的软件开发模式。产品、技术、项目管理、运营、美工、测试等所有岗位都有利于其理解,如果运用得当,可以事半功倍。现在信息爆炸,良莠不齐,网上也有很多关于敏捷的文章,但是对Scrum的含义理解的并不恰当。去年看了Scrum的原版:事半功倍的艺术,结合大学学的软件工程,谈了这个话题。来了~

第一部分瀑布模型

上面的定义:瀑布模型是一个工作软件的概念,它将软件生命周期的活动定义为按固定顺序连接的几个阶段,主要分为:需求分析、架构设计、详细设计、实现、单元测试、集成部署、系统测试、运维。

瀑布模型要求每个阶段都有清晰的文档输出。对于严格的瀑布模型,每个阶段不应该重叠。

敏捷开发模式(敏捷开发瀑布开发)插图(1)为什么会有瀑布模型?

如果一个人承担一个项目,可能不需要那么多麻烦,但是如果规模稍微大一点,就需要很多人的配合。这个时候就需要标准和规范了。

一开始,我们使用建筑工程领域的模型来测试软件工程。无论是盖房子还是建工厂,或者是商业建筑还是写字楼或者是博物馆,都需要有严谨的建筑设计图纸,水电管线布线,甚至装修方案才能开始施工。

瀑布模型就是这种思维,所以瀑布模型对软件架构师的要求很高。在瀑布模型下,如果把开发软件当做一座大楼,编码员只需要“搬砖”(在敏捷开发的过程中,对R&D团队成员的要求会更高。瀑布重视流程和文档,敏捷强调团队中人的能力,尤其是跨职能的,具有跨领域的能力)。

也有人把瀑布模型折成V字形,目的是每个阶段都有东西验证。似乎有迹可循,前后阶段对应。

我认为个人瀑布模型最重要的是建立软件工程的基本概念:

前期做足功课很重要;编码只是软件工程中的一部分。敏捷开发模式(敏捷开发瀑布开发)插图(2)v字模型

瀑布模型有什么问题?

逐渐发现瀑布模型有很多局限性和问题,其中最重要的是它不能拥抱变化。

毕竟建筑不同于开发软件,软件的需求总是在变化的。瀑布模型往往牵一发而动全身,导致大部分瀑布模型的延迟,出来的不是用户原本想要的——客户想要一把瑞士军刀,最后出来的只是一把螺丝刀,甚至是一根小棍子。

因此,人们逐渐试图克服这个问题——这就是RUP:理性统一的过程)。

统一软件开发流程:

它是RUP瀑布模型的改进。可以理解为,该模型将软件开发过程的类比从建筑行业改变为汽车行业。

主要有两点:

软件是不断迭代的;软件应该是面向对象的。

当然还有很多其他的改进细节,我就不展开了。

一款车型可以是一个系列,舒适版,技术版,豪华版,不同年份不同,不断迭代更新。要造一辆车,团队可以分开。

简化一下,比如:做一个四条腿的木凳,A可以先做凳面,B可以做凳腿。前提是两个人定义好如何连接(接口),用什么样的螺丝,孔有多大,在哪里连接,凳子腿有多高等等。也可以有专门的C(项目经理)来协调这些事情。这样凳子腿就可以自由的画一些图案,加个皮套,刻空等等。

敏捷开发模式(敏捷开发瀑布开发)插图(3)改进的瀑布模型

这个模型已经有了高内聚低耦合的思想。但是还有一个问题。客户或领导通常希望看到一些进步。也许一辆车从设计到交付需要两年时间,但每个人每隔几个月就能看到实实在在的东西。

以上面做的凳子为例:我们可以看到凳子的腿和表面,也可以想象它们是如何连接的。但是软件不一样。只要模块没有有效连接,基本就没有什么,尤其是对于大多数没有计算机知识的人来说,基本就是一个“黑箱”过程。这种模式也面临着延迟预算的风险,同时也不一定是客户想要的。

随着互联网的发展,对软件变更的需求越来越高,出现了大家最熟悉的迭代模型——先启、精化、构建、产品化。四个阶段形成一个闭环,核心思想是软件增量开发,每次迭代都能看到一些进展。敏捷开发就是在这种生命周期模型下发展起来的。

敏捷开发模式(敏捷开发瀑布开发)插图(4)迭代模型

螺旋模型

然后,有螺旋模型,这是一个改进,而不是推翻瀑布和RUP。从某种角度来说,螺旋也遵循瀑布模型——每一次螺旋迭代都要有明确的目标、明确的需求、计划的实现、交付条件等。这个循环也是迭代模型的迭代循环演化。

比如做汽车,我们可以先做自行车,然后逐步给自行车加铃铛,加发动机,变成四个轮子,加顶篷,把车把变成方向盘...继续螺旋,各方面迭代,最终会出一个类似汽车的东西。

这个例子有一些原型方法的味道。为了降低风险,更大更复杂的系统经常使用螺旋模型。每次投资都能看到一个东西的产出,希望能“白盒”整个过程。

敏捷开发模式(敏捷开发瀑布开发)插图(5)螺旋模型

总结

这是软件工程的三个主要生命周期模型,逐渐出现了极限编程、原型开发、敏捷开发等模型。

严格来说,瀑布模型和迭代模型是生命周期模型(当然,它们通常包含一系列开发工具),敏捷开发是一套基于迭代模型的软件开发指导原则。我个人的看法是,在实践中要重视指导性原则,弱化方法论。

迭代模型在学术上早已提出。《敏捷开发》的作者之所以能从不同的角度看待软件开发,有独特的思维和管理方法,和他的个人经历有很大关系,因为他不是计算机出身。为了了解他的想法,我特意购买了敏捷革命的英文原版《Scrum,事半功倍的艺术》来阅读。以下部分分享其核心观点。

第二部分

我们可以看看《Scrum》的作者杰夫·萨瑟兰的经历。他之所以能从新的角度认识和理解软件工程,是因为他不是这个行业出身。

作者的经历

杰夫·萨瑟兰毕业于著名的西点军校。他作为战斗机飞行员参加了越南战争。在他的团队里,50%的飞行员会被击落,有的会获救,有的永远回不来了。在这种环境下,他构建了自己的行动模型——也就是OODA(观察、定向、决定、行动)在执行任务时一直重复这个循环,犹豫不决就会死。这种行为模式在他的作品中可以感受到已经深入骨髓。

参加越战后,他去斯坦福读统计学硕士。后来在空军事学院当数学教授的同时,读了生物统计学的博士,研究了一些细胞和癌症相关的东西,学习了一些系统论的东西。

在研究细胞的时候,他会不断地考虑一个问题:新状态比旧状态好在哪里——这个状态是不是比上一个状态好?《敏捷革命》原著中多次提到状态这个词,这也是作者非常重要的一种思维方式。

他大学毕业后的第一份工作是在美国做自动取款机。此时,他将自己在《战争与研究细胞》中的方法应用到IT领域,然后通过大量实践(包括为FBI建立犯罪嫌疑人数据库和著作中的重要案例)逐步总结和发展了敏捷模型理论。

另外,Scrum并不是作者的首创,而是作者基于两位日本教授的理论发展。在学术界,日本两位教授质疑瀑布。他们认为最好的团队应该像打橄榄球一样。球在团队间穿梭,团队整体快速向目标移动(这是Scrum想要表达的)。日本大企业最早使用这种指导思想(当时是日本IT大发展的时代)。

理论早就有了,但很少有美国人这样实践。为了理解日本人的Scrum思想,笔者练习了多年的合气道,将其与Scrum进行了对比,并用“状态”的思维方式再次解释。

说到Scrum,我们来谈谈跨职能。

你可能不熟悉橄榄球,我们来谈谈篮球:

团队里什么样的人最受欢迎?当然是那些哪里都能玩,玩的好的,俗称万金油。勒布朗·詹姆斯号称能打1号位到5号位。这种人能体会到各个岗位人的“难处”,更有利于团队发展。奥尼尔给人的印象是篮下巨无霸,但实际上他拥有灵活的运球技术和出色的娱乐天赋,这两者结合在一起成为了球迷心中的大鲨鱼。

在NBA最受推崇的顶级后卫,大多都会有各种绝学技能,比如乔丹科比韦德等人,能控球、得分、突破、抢板、分球等技能,有些方面甚至是前所未有的。如果你有一项技能特别出众,基本上可以在武林中独树一帜,但要想成为顶尖高手,就必须跨职能。

作为球队的主人,我希望在有限的资源下,能吸引尽可能多的球员,这样才能对拉里奥布莱恩杯产生影响。勇士的“死亡五小”将这一理念发挥到了极致,场上几乎所有球员都能快攻、投篮、抢板。

回想起来,软件开发也是如此。跨职能是对团队成员素质要求的提高。俗话说,不会写代码的产品不是好的艺术,软件开发在不断面对变化的同时,也是一种跨兵种协作。从这个角度来说,和打篮球、橄榄球是一样的。还记得NBA停赛的时候大家是怎么解决问题的吗?

结合上述场景“球在团队间穿梭,整个团队快速向目标移动”,这是Scrum中非常重要的概念。

敏捷作者的一些核心观点(为保留原汁原味,摘录部分原文):

传统的瀑布模型实际上是由很多图表组成的,作者对图表发表一些看法:

“规划是有用的。盲目遵循计划是愚蠢的。”-计划是有用的,但盲目遵循计划是愚蠢的。这和作者在部队的经历有关。他执行任务时总是见机行事,正符合中国的古话“计划没有变化快”。

"每个项目都包含问题的发现和灵感的迸发,Scrum的尴尬,不可预测性和创造性."-任何项目都包含未发现的问题,随着项目的进展,图表会限制这些问题,scrum“拥抱”这些不确定性和创造性。

“停止你正在做的事情,回顾你所做的事情。”-放下你在做的事,想想我们在做什么。

作者对“敏捷”的一些看法:

MVP:“从消费者那里获得即时反馈的最少可行产品,而不是等到项目完成。”-最小化可行产品,简称MVP(会有很多方法论去搜索这个短语)。用最小可行的产品快速得到用户的反馈,而不是等待项目完成,就是我们通常所说的“小步快跑”。

InspectandAdapt循环:前面提到的OODA行动模型的抽象,“观察-适应”,这两个过程是不断循环的。

这里笔者提到一个常用的方法5W2H,在每个阶段(状态)问自己:

什么:我们要做什么,有什么意义,目前的状态是什么;

为什么:我们为什么要这样做?我们一定要做吗?有替代方案吗?

什么时候:什么时候做,最后期限是什么;

哪里:哪里做,哪里用;

谁:谁来做,谁来负责;

How:怎么做,怎么合作;

多少:多少,多少,花多少钱,花到什么程度;

敏捷革命可以应用于各行各业。作者已经在汽车制造、洗衣店、学生培训、制造宇宙、婚礼策划等领域实践过。因此,Scrum模型不仅是一套软件开发工具,也是一种普世价值:

《敏捷宣言》宣称了以下价值观:人高于过程;产品实际上记录了该产品的预期用途;与客户合作,与他们谈判;响应变化而不是遵循计划,Scrum是我构建的将这些价值观付诸实践的框架。没有方法论。”

这是敏捷宣言的全部原文,后来被各种媒体放大解读。事实上,它非常简洁——敏捷宣言,它强调以下价值观:

人重于过程;产品真正好用重于文档里的设计;跟用户合作重于跟他们谈判;对变化做回应重于按计划去做;我建立Scrum模型就是为了把以上价值观揉进一套工具集以方便更好地实践,敏捷模型没有方法论(没有方法论,没有方法论,没有方法论,这是作者的原话啊,啪啪啪打脸有木有)。总结

Scrum的原著用案例表达了他对图表、文档、计划、团队和流程管理的看法,而Scrum就是这些价值观的集合,这就是Scrum的精髓。

为了快速实践和轻松理解这些价值观,作者提供了一些方法,如:每日例会、冲刺、积压等。

不赘述,网上有很多介绍。这些方法都是为了贯彻上述观点:我们处于什么状态,我们拥有什么,如何让下一个状态比现在更好...

与直接使用方法相比,了解上述观点,然后根据实际情况选择方法更有效。

作者:奇奇兽,微信官方账号:奇奇兽,从技术转型到产品经理,北邮MBA,百万DAU平台产品总监,擅长社交和棋牌。

本文由@奇奇兽原创,人人都是产品经理。未经许可,禁止复制。

来自Unsplash的图像,基于CC0协议。

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。

作者:美站资讯,如若转载,请注明出处:https://www.meizw.com/n/62412.html

发表回复

登录后才能评论