本文笔者将从软件工程的角度来聊一聊敏捷开发模式,会涉及瀑布,V字、RUP、迭代、螺旋等开发模型,同时重点分享下敏捷模式的核心思想。
文章分两部分:
1、通过举例和对标其他行业,聊聊软件开发模型的发展演进。
2、聊聊敏捷的核心思想。
敏捷开发是互联网界比较流行的软件开发模式,产品、技术、项目管理、、美术和测试等各岗位对其理解后都大有益处,运用得当可以事半功倍。现在信息爆炸、良莠不齐,网上很多讲敏捷的文章,Scrum词意没理解到位。去年看了敏捷革命的原版《Scrum:The Art of Doing Twice the Work in Half the Time》,结合大学所学的软件工程聊一聊这个话题,here we go~
第一部分
瀑布模型
先上定义:瀑布模型是将软件生存周期的各项活动规定,为按固定顺序而连接的若干阶段工作软件概念,主要分为:需求分析、架构设计、详细设计、实现、单元测试、集成部署、系统测试、运营维护。
瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠。
图片发自简书App
为什么会有瀑布模型?
如果一个人接项目,他也许不需要这么麻烦,但规模稍微大一些,就需要多人协作,这时候就需要有标准有规范。
最开始的时候,大家用了建筑工程领域的模型来对标软件工程。是盖住宅还是盖工厂,或是商厦或是办公楼或是博物馆,都需要有严谨的建筑设计图,水电管道布线甚至装修方案,才可以开始施工。
瀑布模型就是这个思维,所以瀑布模型对软件架构师的要求很高。在瀑布模型下,如果把开发软件作为盖栋建筑的话,coder只需要“搬砖”就可以了(在敏捷开发过程中,对研发团队人员的要求会较高。瀑布重视流程、文档,敏捷强调团队内人员能力,特别是cross-functional,要有跨领域的能力)。
也有人把瀑布模型折叠起来,变成了V字型,目的是每个阶段都有要去验证的东西,看起来是有迹可循的,前后阶段是对应的。
个人觉得瀑布模型最重要的是给大家树立了软件工程的基本观念:
前期做足功课很重要;
编码只是软件工程中的一部分。
V字模型
瀑布模型有什么问题?
慢慢大家发现:瀑布模型有很多限制和问题,最主要的是不能拥抱变化。
盖大楼毕竟跟开发软件不一样,软件的需求往往是不断变化的,瀑布模型往往会导致牵一发而动全身,这就导致绝大多数瀑布模型是延期的,而且出来的东西也不是用户最初想要的——客户想要一把瑞士军刀,最终只出来一把螺丝刀,甚至只是一根小木棍儿。
于是,人们逐渐想办法克服了这个问题——这就是统一软件开发过程(RUP:Rational Unified Process)
统一软件开发过程:
RUP是瀑布模型的改进,可以这样理解,这个模型把软件开发过程的类比从建筑行业改到了汽车行业。
主要认清了两点:
1、软件是不断迭代的;
2、软件应该是面向对象的。
当然,还有很多其他方面的改进细节,就不展开了。
一个车型可以是系列的,舒适版、技术版、豪华版,不同年份还不一样,是不断迭代更新的。要想造一辆车,团队可以分头行动。
简化一下,比如:要做一个四只脚的木凳,甲可以先去做凳子面,乙去做凳子腿。前提是两个人定义好怎样连接(接口),用什么样的螺丝,多大的孔,在什么位置连接,凳子腿多高等等,也可以有个专门的丙(项目经理)去协调这些事情。这样凳子腿可以在这个基础上自由地涂些花纹,加个皮套,做些镂空等等。
改进后的瀑布模型
这个模型已经具备了高内聚低耦合的思想。但还是有个问题,客户或领导通常想看到一些进展,也许一辆车从设计到出厂需要两年,但每几个月大家可以看到一些实实在在的东西。
以上面做凳子为例:我们是可以看到凳子腿和凳子面的,也可以想象它们连接起来的样子。而软件不一样,只要各个模块还没有效的连接起来,那基本上啥都没有,特别是对于大多数没有计算机知识的人,基本上是一个“黑盒”过程。这个模型同样面临着延期超预算的风险,同时做出来的也不一定是客户想要的。
随着互联网的发展,对软件的变化需求越来越高,就产生了大家最熟悉的迭代模型——inception,elaboration,construction,transition,四个阶段形成闭环,不断循环往复,其核心理念是软件是增量开发的,每次迭代都能看到些进展。敏捷开发就是在这个生命周期模型下演变而来。
迭代模型
螺旋模型
接着,就有了螺旋模型,螺旋模型并不是推翻了瀑布和RUP,是一种改进。从某种角度来说,螺旋也是遵循瀑布模型的——每一次螺旋迭代都要有清晰的目标,明确的需求,规划实现,交付条件等,这个循环也是迭代模型的迭代周期演变。
比如说要做一辆汽车,我们可以先做一个自行车,再逐渐地在自行车上加个铃铛,加上发动机,变成4个轮子,加个篷,车把变成方向盘……在各方面持续地螺旋迭代下去,最终会出来一个跟汽车差不多的东西。
这个例子有一些原型法的味道,螺旋模型往往是较大较复杂的系统使用,目的是减小风险,每一次投入能看到一些东西的产出,希望把整个过程“白盒化”。
螺旋模型
总结
以上是关于软件工程的三个主要生命周期模型,逐渐地又出现了极限编程、原型开发、敏捷开发等模型。
严格来讲,瀑布模型、迭代模型是生命周期层面的模型(当然,通常也包含了一系列开发层面的工具集),敏捷开发是基于迭代模型发展起来的一整套软件开发指导原则。个人观点是在实际操作中应重视指导原则,弱化方法论。
迭代模型在学术上很早就有人提出,敏捷开发的作者之所以能从不同的视角去看待软件开发,并有独特的思维和管理方法,这跟他的个人经历有很大关系,因为他不是做计算机出身,为了理解他的思想,我特意购买了《敏捷革命》的英文原版《Scrum,The Art of Doing Twice the work in Half the Time》来阅读,下面部分分享其核心观点。
第二部分
我们可以看看《Scrum》的作者杰夫·萨瑟兰的经历,他之所以能以全新的视角来认识和理解软件工程这件事情,很重要的原因在于他不是做这个行业出身。
作者的经历
杰夫·萨瑟兰毕业于著名的西点军校,他以战斗机飞行员的身份去参加越南战争,在他的队伍里50%的飞行员会被击落,一些会被营救,一些再也回不来。在这个环境里他构建了自己的行动模型——即OODA(Observe,Orient,Decide,Act)执行任务的每时每刻都在重复着这个循环,犹豫就会死。这个行为模式在他的著作里能感受到已经深入骨髓。
参加完越南战争后,他去斯坦福进修了统计学硕士学位。后来边在空军学院做数学教授,边读了一个生物统计学博士,研究细胞、癌症相关的一些东西,学习了系统论方面的东西。
在研究细胞的时候,他会不断考虑一个问题:whether the new state is better than the old one——现在这个状态是不是比上一个好。《敏捷革命》原文中多次提到state这个词,这也是作者非常重要的一种思考方式。
其离开大学的第一份工作是做美国的ATM,这个时候他把自己在战争和研究细胞中的方法应用于IT领域,后通过大量实践(其中有为FBI构建犯罪嫌疑人数据库,著作中的重要案例)逐步总结发展出了敏捷模型理论。
另外,Scrum不是作者的首创,作者是根据日本两个教授的理论发展总结而来。在学术界,日本的两个教授质疑瀑布,他们认为:最好的团队应该像打橄榄球一样,球在队伍中间穿梭,队伍整体快速向目标移动(这才是Scrum想要表达的意思),日本的大企业最开始用这种指导思想(细算一下正是日本IT大发展的时代)。
理论早就有了,但很少有美国人这样去实践,作者为了理解日本人的Scrum思想,练习了多年合气道,并用合气道来类比Scrum,并再次用到了“state”思维方式来解释。
说到Scrum,我们来聊聊cross-functional。
橄榄球大家可能不熟,我们来聊聊篮球:
球队里最吃香的是哪种人,当然是那种什么位置都能打且都打得好的,俗称万金油。勒布朗·詹姆斯号称可以从1号位打到5号位,这种人可以体会到在各个位置的人的“不容易”,从而更有利于团队发展。奥尼尔给人篮下巨无霸的印象,但其实他有灵活的运球技巧和出色的娱乐表演天赋,这些综合到一起才成为球迷心中大鲨鱼的人设。
NBA里那些最受人崇拜的顶级后卫,基本都会多种绝学,乔丹科比韦德等人,控球、得分、突破、抢板、分球等各项技能均能登堂入室,有些方面甚至前无古人。有一项技能特别突出基本就可以独步武林,但想成为顶级选手,一定是cross-functional的。
而作为球队老板,希望在有限的资源下,尽可能多地把这种选手招致麾下,才有可能对拉里·奥布莱恩杯发起冲击。勇士的“死亡五小”更是将这种理念发挥到了极致,场上队员几乎都能快攻、投篮和抢板。
回头来看,软件开发也是,cross-functional是对团队人员素质要求的提高,正所谓不会写代码的产品不是好美术。软件开发也是个跨兵种共同协作的同时不断面临变化的事情,从这个角度来看,跟打篮球和橄榄球是相同的,还记得NBA赛场上暂停时大家是怎么解决问题的么?
结合上面说的场景“球在队伍中间穿梭,队伍整体快速向目标移动”,这是Scrum中非常重要的理念。
敏捷作者的一些核心观点(为保原汁原味,摘抄部分原文):
传统的瀑布模型其实是由一大堆图表构成,作者表达了对图表的一些观点:
“Planning is useful.Blindly following Plans is stupid.”——计划是有用的,但盲目的按计划走是愚蠢的。这跟作者的从军经历有关,其执行任务的时候都是随机应变,也应了中国的那句老话“计划没有变化快”。
“Every project involves discovery of problems and bursts of inspiration,scrum embraces uncertainty and creativity.”——任何一个项目都包含了未发现的问题以及随着项目进行的灵感爆发,图表会限制这些,Scrum“拥抱”这些不确定性和创造性。
“Stop doing what you’re doing,review what you’ve done.”——放下手中的事情,想一想我们在干啥。
作者对“敏捷”的一些观点:
MVP:“Minimum viable products to get immediate feed back from consumers,rather waiting until a project is finished.”——最小化可行产品Minimum viable products,也简称MVP(搜索这个短语会有大量方法论)。用最小化的可行产品来从用户那里快速获得回馈,而不是一直等项目完成,就是我们通常说的“小步快跑”。
InspectandAdapt cycle:上面说的OODA行动模型的抽象,“观察—适应”,这两个过程不断循环。
这里面作者提到了一个常用的方法5W2H,在每一个阶段(state)都问自己:
What:我们要做的是什么,有什么意义,现在是什么状态;
Why:我们为什么要做这个,可不可不做,有替代方案么;
When:什么时候做,deadline是什么;
Where:在哪做,哪里要用;
Who:谁来做,谁对此负责;
How:怎么来做,如何配合;
Howmuch:多少、程度,多大开销,做到什么程度;
敏捷革命可以应用在各行各业,作者已经在汽车制造、开洗衣店、学生培训、制造宇宙飞创、婚礼策划等领域展开实践。所以说,Scrum模型不只是一套软件开发工具集,是具有普世性的价值观:
“Agile Manifesto,It declared the following values:people over process;products that actually work over documenting what that product is suposed to do;collaborating with customers over negotiating with them;and responding to change over following a plan,Scrum is the framework I built to put those values into practice.There is no methodology.”
这就是敏捷宣言的所有原文,后来被各种媒体放大和解读,其实它非常简洁——敏捷宣言,它强调了以下价值观:
1、人重于过程;
2、产品真正好用重于文档里的设计;
3、跟用户合作重于跟他们谈判;
4、对变化做回应重于按计划去做;
我建立Scrum模型就是为了把以上价值观揉进一套工具集以方便更好地实践,敏捷模型没有方法论(没有方法论,没有方法论,没有方法论,这是作者的原话啊,啪啪啪打脸有木有)。
总结
Scrum原著以案例来表达了他对图表、文档、对计划、对团队、对过程管理的一些观点,而Scrum正是这一系列价值观的合集,这才是Scrum的精髓所在。
为了快速实践和方便理解这些价值观,作者提供了一些方法,比如:每日立会、sprint、backlog等。
具体方法不赘述了,网上有很多介绍。这些方法都是为了落实上面的观点:我们处在什么状态,我们有什么,如何做下个状态会比现在的好……
相比于拿过来方法直接使用,理解好上面的观点再根据实际情况选择方法是更有效的思路。