001-敏捷方法与大型互联网系统开发-前沿

【导读】这是阿里技术嘉年华发表于segmentfault的第一篇文章，感谢高阳给了测试资格。接下来阿里技术嘉年华将在segmentfault围绕项目管理、敏捷实践、淘宝搜索算法、个性化推荐、导航、反做弊等方面发表若干原创技术干活。本帐号由阿里巴巴集团-技术发展部-新媒体相关的同窗在负责维护，有任何问题请经过campus#alibaba-inc.com(请将#替换成@)与咱们取得联系，谢谢：）

文/一玄

目前，我国的互联网商业发展十分迅速，许多公司将其商业模型和业务系统基于互联网进行构建，掀起了互联网系统开发的又一波热潮。

稳定、可用性高、质量好的互联网应用，对于在商业上取得成功具有极其重要的意义。同时，可以以最快的速度、最高的效率和最低的成本响应用户需求、根据商业运营状况进行快速的适应调整，对于在竞争激烈的互联网行业中立于不败之地，具备极其关键的做用。而兴起于20世纪末、流行于本世纪的敏捷软件开发方法，被认为是应对复杂软件系统开发的有效途径。

基于此，本文将把敏捷软件方法学中的核心原则和实践，与面向公众的大型互联网系统的开发结合起来，研究如何在大型互联网系统的开发中吸取采纳敏捷软件开发方法的精髓，以更快速度、更好质量和更低成本，进行互联网软件的开发。

互联网开发的一些现状

随着互联网的普及、计算机相关技术书籍和期刊的广为发行，以及大量相关的专题网站和技术社区的推广，敏捷思想和敏捷软件开发方法已经为国内的IT界所了解。敏捷软件开发的内容也已经逐渐走入正统的软件工程教材，走入大专院校的课堂。许多软件开发组织也正在接触和实践敏捷软件开发方法。

但从总体宏观上看，敏捷软件方法在中国还处于刚刚开始被了解、逐步被采纳的阶段。

中国已经有一些软件开发组织在近几年开始使用敏捷方法，虽然目前数量还较少，并且大部分使用敏捷方法的公司都集中在外资的跨国企业如IBM、SUN等在中国的研发团队，以及一些外资软件外包和专业的敏捷开发咨询服务公司如ThoughtWorks公司等。同时有一些比较前沿的国内公司也在率先学习、采纳和实践、推广敏捷软件开发方法。从宏观总体而言，能够说当前中国国内的敏捷软件开发方法，仍然处于技术采纳生命周期的初期试用阶段。

互联网是一个“快鱼吃慢鱼”的行业，也是竞争最为激烈、变化最为迅猛的行业。如何在竞争激烈、变化迅猛的互联网行业中脱颖而出，并长期立于不败之地？敏捷软件开发方法的理念和实践，让互联网行业中的许多公司看到了新的方向。敏捷软件开发开始在国际国内的许多互联网公司中掀起了革命。

一些著名的国际互联网公司如Google,Microsoft和Yahoo!以及众多的新兴Web 2.0互联网公司已经开始转向全面采用敏捷开发，其中Scrum和XP被使用的最多。并且其中很多已经有了较长时间的实践经验。

好比，Yahoo！公司在2002年时，最初使用的是公司内部定义的一个相似瀑布模型的PDP方法。但是，到2005年时，它发现须要新的方法来应对互联网产品的复杂性和多变性，而PDP在应对快速的市场变化方面根本没法与敏捷方法相提并论。所以，在2005年Yahoo！在美国、欧洲和亚太地区开始选择实施敏捷方法学中的Scrum方法，进行互联网软件产品的开发。最初仅选择了四个团队进行尝试。到2008为止，已有近200个团队在不一样程度上使用了Scrum。虽然在实施过程当中，也出现过很多问题，但平均而言，全部参与敏捷实施的这些团队，其生产效率提升了30~40%。对于一个企业来讲，这并非一个小数目。

在Google公司中，敏捷软件开发的理念和应用则更为明显。Google的许多产品都打上Beta的标签，也就是在告诉用户，Google的产品一直在根据用户的反馈进行不断的演化发展中，Google的开发团队会根据用户反馈来及时调整产品的方法，是一种典型的敏捷开发方法。另外，Google的软件开发团队具有使人瞩目的创新能力，而其由软件开发精英人才组成的敏捷产品开发小组做战模式，是Google可以持续创新的关键因素之一。这些都具备敏捷软件开发理念的深入痕迹。

中国许多互联网公司的开发团队，在这几年中也在逐渐接受并应用相似的敏捷软件开发模式。许多公司正在不断学习、引入和实践敏捷软件开发模式，并逐步造成各自的实践框架。其余国内很多新兴的Web 2.0互联网公司，在吸纳敏捷方法上，也有活跃的表现。

但因为传统的瀑布式软件开发模型在中国具备较长时期的影响，许多软件公司都先入为主的采用瀑布式方法，互联网公司中也有不少人员是从传统的软件开发组织转入互联网系统开发，对瀑布方法已经有了根深蒂固的思惟定势。加之，敏捷软件方法在中国互联网公司内的采纳和实施也不多是垂手可得的，目前整体上看，即便那些在采用敏捷方法上起步较早的互联网公司，也仍是处于“起步”阶段向“探索”阶段过渡的时期。在这些公司中，也还须要对敏捷软件开发进行大量的学习、研究、实践、适配和整合。

在阐述敏捷软件开发方法以前，有必要首先来分析总结广为流传和使用的瀑布式开发模型的简陋和严重弊端。

瀑布式开发模型的弊端

重量型的软件开发方法学，其基础模型是所谓的“瀑布式开发模型(Waterfall Model)”。软件开发的瀑布模型，将整个软件过程分解为按照固定顺序完成的一系列单独阶段：整个过程，从需求、设计、实现、测试、部署到维护，按顺序进行。整个开发过程看起来就像是瀑布同样，逐次通过这些阶段。开发过程当中的每一个阶段，都有明确的起始点和结束点。若是上一个阶段的结束点没有完成，则不能进入到下一阶段的活动中；而一旦已经进入到下一阶段中，就没法再回到上一个阶段的活动。

这种模型的概念看起来很是简单，易于理解和掌握；加之，在软件开发组织中的许多管理者，通常而言，他们也都很喜欢可以有一系列固定的里程碑，以可以很方便地对开发过程的进度进行跟踪。瀑布式模型乍看之下很是符合这种须要。可是，因为瀑布模型是一个僵硬固化、不容许在过程当中发生变化的模型，忽略了软件开发活动复杂现实，是一个过于简陋的模型，因此事实上很难得到理想中的可管理性。

事实上，软件开发活动是一个高度动态、须要很是强的适应性、须要不断根据反馈进行调整的过程。在这个过程当中，十分容易发生各类各样的变化和调整，好比需求的变动、投资计划的变动、进度计划的变动等，这些变化通常而言是不可避免的；即便到了实现阶段，也可能会发现最初的设计存有问题，必须进行调整修正等；并且，因为软件开发通常而言都有一个比较长的周期，使用瀑布模型时，因为客户没法提早确切知道他们所想要的一切东西，需求变动的问题尤为没法避免。并且，客户只有在最终阶段，才可以看到和使用真实的项目成果，这时若是发现实际产物和本身所需差异很大，则可能带来巨大的商业损失。

对许多软件项目的跟踪研究结果代表，开发组织的生产力降低、软件缺陷率攀升和项目的失败，都和采用瀑布方法呈正相关性。

1970年，Winston Royce在《Proceedings of the IEEEWestcon》上发表了一篇题为《管理大型软件系统的开发》的论文。在这篇论文中，Royce首次描述了瀑布方法，但他其实是要推荐一种与流行的瀑布模型不一样的方法，罗伊斯提到瀑布方法是“风险重重和易于招致失败”的，瀑布模型是最简单一种过程描述，毫不是放之四海皆准的法宝，事实上它只适用于最简单的项目。这篇论文倾向提倡使用迭代式开发模型来改进和替代瀑布方法。

美国国防部在20世纪八十年代，针对软件开发颁布了标准DOD-STD-2167，这是一个基于瀑布模型与文档驱动的方法。以后，美国国防部发现遵循瀑布方法和2167标准给他们在软件开发上带来了许多失败的项目，栽了不少跟斗。以后，美国国防部通过研究，决定废弃DOD-STD-2167和它的改良标准DOD-STD-2167A，在1994年以MIL-STD-498取代。

可是，因为长期的传播，瀑布式开发模型在许多软件开发组织和软件工程教科书中先入为主的危害已经造成。纵观科学史，简单的思想每每在一开始会占据主要的位置。软件开发是一个全新的领域，所以，在开始阶段遵循“需求、设计、编码、测试”的简单公式来试图建立技能化的开发过程也就不足为奇。不少软件采购组织、软件开发从业人员对此已经造成根深蒂固的强烈思惟定式。

好比，DOD-STD-2167影响了美国外的许多国家的标准定义。这些国家尚未了解到美国国防部后来摒弃了2167标准和瀑布方法；这些国家的标准体系中有至关一部分仍然强调瀑布式的文档驱动的开发过程。

再好比，20世纪80年代后期和90年代期间，软件工程学院(SEI)的软件成熟度模型(CMM)在业界颇具影响，它也仍是倡导文档驱动、计划驱动、面向阶段和预见性计划，其指导思想仍是基于瀑布模型的实践和指令型过程。早期的项目管理学会(PMI)和项目管理知识体系(PMBOK)，也是鼓吹“计划工做，而后按计划工做”、分阶段的预见性计划，在本质上其思惟范式也是瀑布模型。

萌芽于20世纪80年代、兴起于20世纪90年代的轻量型方法和本世纪初的敏捷软件开发方法(Agile Software Development, ASD)，开始试图改变和扭转这种局面。

下期我们来聊聊互联网学习型敏捷研发组织的构建及策略，请继续关注。