本文笔者将从软件工程的角度来聊一聊敏捷开发模式，会涉及瀑布，V字、RUP、迭代、螺旋等开发模型，同时重点分享下敏捷模式的核心思想。 敏捷开发是互联网界比较流行的软件开发模式，产品、技术、项目管理、运营、美术和测试等各岗位对其理解后都大有益处，运用得当可以事半功倍。现在信息爆炸、良莠不齐，网上很多讲敏捷的文章，Scrum词意没理解到位。去年看了敏捷的原版《Scrum:The Art of Doing Twice the Work in Half the Time》，结合大学所学的软件工程聊一聊这个话题，here we go~ 先上定义：瀑布模型是将软件周期的各项活动，为按固定顺序而连接的若干阶段工作软件概念，主要分为：需求分析、架构设计、详细设计、实现、单元测试、集成部署、系统测试、运营。 如果一个人接项目，他也许不需要这么麻烦，但规模稍微大一些，就需要多人协作，这时候就需要有标准有规范。 最开始的时候，大家用了建筑工程领域的模型来对标软件工程。是盖住宅还是盖工厂，或是商厦或是办公楼或是博物馆，都需要有严谨的建筑设计图，水电管道布线甚至装修方案，才可以开始施工。 瀑布模型就是这个思维，所以瀑布模型对软件架构师的要求很高。在瀑布模型下，如果把开发软件作为盖栋建筑的话，coder只需要“搬砖”就可以了（在敏捷开发过程中，对研发团队人员的要求会较高。瀑布重视流程、文档，敏捷强调团队内人员能力，特别是cross-functional，要有跨领域的能力）。 也有人把瀑布模型折叠起来，变成了V字型，目的是每个阶段都有要去验证的东西，看起来是有迹可循的，前后阶段是对应的。 盖大楼毕竟跟开发软件不一样，软件的需求往往是不断变化的，瀑布模型往往会导致牵一发而动，这就导致绝大多数瀑布模型是延期的，而且出来的东西也不是用户最初想要的——客户想要一把军刀，最终只出来一把螺丝刀，甚至只是一根小儿。 于是，人们逐渐想办法克服了这个问题——这就是统一软件开发过程（RUP：Rational Unified Process） RUP是瀑布模型的改进，可以这样理解，这个模型把软件开发过程的类比从建筑行业改到了汽车行业。 一个车型可以是系列的，舒适版、技术版、豪华版，不同年份还不一样，是不断迭代更新的。要想造一辆车，团队可以分头行动。 简化一下，比如：要做一个四只脚的木凳，甲可以先去做凳子面，乙去做凳子腿。前提是两个人定义好怎样连接（接口），用什么样的螺丝，多大的孔，在什么连接，凳子腿多高等等，也可以有个专门的丙（项目经理）去协调这些事情。这样凳子腿可以在这个基础上地涂些花纹，加个皮套，做些镂空等等。 这个模型已经具备了高内聚低耦合的思想。但还是有个问题，客户或领导通常想看到一些进展，也许一辆车从设计到出厂需要两年，但每几个月大家可以看到一些实实在在的东西。 以做凳子为例：我们是可以看到凳子腿和凳子面的，也可以想象它们连接起来的样子。而软件不一样，只要各个模块还没有效的连接起来，那基本上啥都没有，特别是对于大多数没有计算机知识的人，基本上是一个“黑盒”过程。这个模型同样面临着延期超预算的风险，同时做出来的也不一定是客户想要的。 随着互联网的发展，对软件的变化需求越来越高，就产生了大家最熟悉的迭代模型——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”思维方式来解释。 球队里最吃香的是哪种人，当然是那种什么都能打且都打得好的，俗称万金油。勒布朗·詹姆斯号称可以从1号位打到5号位，这种人可以体会到在各个的人的“不容易”，从而更有利于团队发展。奥尼尔给人篮下巨无霸的印象，但其实他有灵活的运球技巧和出色的娱乐表演天赋，这些综合到一起才成为球迷心中大鲨鱼的人设。 NBA里那些最受人的后卫，基本都会多种绝学，乔丹科比韦德等人，控球、得分、突破、抢板、分球等各项技能均能登堂入室，有些方面甚至前无古人。有一项技能特别突出基本就可以独步武林，但想成为选手，一定是cross-functional的。 而作为球队老板，希望在有限的资源下，尽可能多地把这种选手招致麾下，才有可能对拉里·奥布莱恩杯发起冲击。勇士的“死亡五小”更是将这种发挥到了极致，场上队员几乎都能快攻、投篮和抢板。 回头来看，软件开发也是，cross-functional是对团队人员素质要求的提高，正所谓不会写代码的产品不是好美术。软件开发也是个跨兵种共同协作的同时不断面临变化的事情，从这个角度来看，跟打篮球和橄榄球是相同的，还记得NBA赛场上暂停时大家是怎么解决问题的么？ 结合说的场景“球在队伍中间穿梭，队伍整体快速向目标移动”，这是Scrum中非常重要的。 “Planning is useful.Blindly following Plans is stupid.”——计划是有用的，但盲目的按计划走是愚蠢的。这跟作者的从军经历有关，其执行任务的时候都是随机应变，也应了中国的那句老话“计划没有变化快”。 InspectandAdapt cycle：说的OODA行动模型的抽象，“观察—适应”，这两个过程不断循环。 敏捷可以应用在各行各业，作者已经在汽车制造、开洗衣店、学生培训、制造飞创、婚礼策划等领域展开实践。所以说，Scrum模型不只是一套软件开发工具集，是具有普世性的价值观： 这就是敏捷宣言的所有原文，后来被各种放大和解读，其实它非常简洁——敏捷宣言，它强调了以下价值观： Scrum原著以案例来表达了他对图表、文档、对计划、对团队、对过程管理的一些观点，而Scrum正是这一系列价值观的合集，这才是Scrum的精髓所在。 为了快速实践和方便理解这些价值观，作者提供了一些方法，比如：每日立会、sprint、backlog等。 具体方法不赘述了，网上有很多介绍。这些方法都是为了落实的观点：我们处在什么状态，我们有什么，如何做下个状态会比现在的好…… 作者：齐齐兽，号：齐齐兽，从技术转型到产品经理，北邮MBA，千万DAU平台型产品负责人，擅长社交和棋牌。 对于软件开发，敏捷开发是个梦见找不到回家的路花巧的技术，华而不实。适用于技术研发要求不高的项目，对于技术研发很密集的项目，比如：操作系统，不适用，很容易陷入不断迭代的过程里。敏捷开发如同武功里的招式，招式学得再好，遇到真正的高手必败无疑。 我是针对现在的浮夸之风说的，其实你说的跟我说的一样，方法都有个适用范围。不过，我说的更进一步，阿里的yunos搞了有10年了吧，到最后还不是山寨android。那些开发人员还不是个个自诩高手。我也见过有个自诩专家的，论文发表了好多篇，又到腾讯，我看他研究什么，无非就是敏捷开发、结对编程和团队建设与管理，这些都是招式。当你要搞想操作系统这类技术非常密集的项目时，就不得不要软件工程的原理，原理理解不深不透彻不能融会贯通是不行的；因为成本是第一制约因素，稍有不慎它会大到连阿里都承受不起。所谓假传万卷书，真传一句话，你以功夫这么容易就能学到，绝大多数开发人员都没有。 yunos的研发过程必定曾发生某个版本开发不下去了必须推倒重来的状况。开发浏览器内核、操作系统这类难度很高的项目，你就会发现，什么瀑布、敏捷开发、结对编程都行不通。靠谱的方式只有两种：要么靠开源和社区，依托互联网进行群策群力，要么由1、2个真正的高手带领团队。 人人都是产品经理（是以产品经理、运营为核心的学习、交流、分享平台，集、培训、社群为一体，全方位服务产品人和运营人，成立8年举办在线+期，线+场，产品经理大会、运营大会20+场，覆盖北上广深杭成都等15个城市，在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监，他们在这里与你一起成长。
|