`
javababy1
  • 浏览: 1161844 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

敏捷开发

 
阅读更多

对于你,我初次谋面的读者,“敏捷开发”或许还是一个多少有些生疏的词汇。作为一个敏捷方法的实践者,作为一个软件工匠,我愿意把我所知道的“敏捷”介绍给你,作为一份小小的见面礼。希望这篇短文能引起你对敏捷方法的兴趣,我也就不虚此行了。
从软件工程说起
为了理解软件工程,我们首先需要了解在早期的软件工程文献中提到的那些项目。稍做研究,你就会发现一个令人惊讶的事实:这些文献中几乎没有对商用软件的报告。在所有的案例中,绝大多数都是大型国防项目。这些大型项目是真正的“系统工程”项目。这些项目通常同时包含硬件和软件的开发,其中的硬件是专为与软件协作而开发的。这一类项目有一个共通的特点:在项目的前期,软件开发者需要等待硬件的开发;而在项目的后期,则是硬件开发者在等待软件的开发。软件工程正是在这样一对矛盾中发展起来的。
在典型的软件工程项目的前期,软件开发者会有很多的时间。这时,硬件的发明或者设计尚未完成,所以软件开发者有大把的时间来做需求调研,并编写出详尽的软件设计规格书。设计团队则可以根据需求文档编写出极其详尽的设计规格书。他们甚至可以进行细致入微的设计复审——反正也没有别的事可以做。
一旦硬件能够投入使用,软件开发者就应该立刻动手将详细设计规格转换成代码。如何加快交付的速度?最简单的答案就是:“投入大量的人手。”于是,软件工程的理论就这样顺理成章地建立起来了:项目前期,用大量的时间进行需求分析和详尽的设计;进入编码阶段之后,投入大量“软件蓝领”进行简单而繁复的代码编写。不同职能的开发者泾渭分明,“分析师”、“设计师”、“程序员”这样的称谓标明了他们的细化分工,彼此之间用浩如烟海的文档交流。
软件工程另一个引人注目的方面就是那种确定的、可重复的开发方式。对于强调安全性的软件系统,这种有组织、有纪律、可计量的开发方式已经被证明是非常有效的。美国国防部的某些项目甚至达到了低于同等规模商用项目1%的错误率。但是,在这样的过程中,其他的约束条件则不得不被放松——就在那些错误率极低的项目中,平均每行代码的资金投入达到了1美元。
对于普通的商用软件,你或许要问:我们是否愿意投入那么大的成本,换取那么高的质量?然而,更加重要的是:我们是否有那么多的时间来进行详尽的分析和设计?面对用户本身对需求都不甚明了、业务规则又时常变化的软件项目,这种“有组织、有纪律、可计量的开发方式”真的合适吗?
敏捷宣言
2001年,一群强调实践、以自己的程序员身份为荣的软件大师们成立了一个松散的组织:敏捷联盟(Agile Alliance)。他们提出了自己对于软件开发的价值观:
? 个人和交流??胜过?过程和工具
? 可以工作的软件?胜过??? 面面俱到的文档
? 客户合作??胜过??? 合同谈判
? 响应变化??胜过??? 遵循计划
这就是所谓的“敏捷宣言”。不难看出,列在右边的恰好是传统软件工程一直关注的主题。敏捷方法的实践者们并非认为这些东西(例如过程、文档……)不重要,而是借由这个宣言提醒世人:在过去相当长的时间里,我们一直把注意力集中在这些“工程化”的东西上面,它们能带给我们的边际效益已经降到了非常低的水平——试问,哪位项目经理不会写文档、哪家软件公司不知道如何与客户谈判呢?当此时,如果将更多的精力投入到左边的东西,我们有机会获得更大的收益。
透过这份敏捷宣言,你不难读出一种人本主义的精神。早在1986年,Fred Brooks就在《没有银弹》 一文中指出,软件开发的任务分为两方面:根本任务——打造由抽象软件实体构成的复杂概念结构;次要任务——使用编程语言表达这些抽象实体,在空间和时间限制内将它们映射成机器语言。所有工程化的尝试(过程控制、文档管理、新技术和新方法……)无不是局限于解决“次要任务”,而软件开发的“根本任务”——理解真实世界的需求,并将其投射为软件模型——不是任何技术或过程可以解决的。借用Brooks的比喻,如果软件的复杂度是可怕的人狼,那么射杀这只怪物的银质子弹中必须有这样一个配方:软件开发者的技艺。归根结底,软件是由人来开发、给人使用的东西,我们无法、也不应当回避人的问题。
拥抱变化
如果你从事着商业软件(例如ERP系统、电子政务系统)的开发,我几乎可以肯定地说:你的项目面临着需求变化的挑战。商业规则总在发生着变化,甚至连用户本身在项目之初都不知道自己的需求是什么。软件业的人们常常自嘲地说:“在这个行业里,唯一不变的就是变化。”问题就摆在你面前:既然变化是生活的常态,你是要为自己准备一副盾牌来抵抗它呢,还是要积极地拥抱它?
就像汤普金斯先生在《最后期限》 里所说的,我们或许可以换一个角度来思考:作为软件开发者的我们,和用户本应该站在一条战壕里,我们有着共同的目标——为用户提供最大的价值。惟有拥抱变化,我们的目标才能达成。
如何确保随时为用户提供最大化的价值?我们可以把这个问题想得再极端一点:假如明天就要终止这个项目,如何确保今天能够提交给用户的是最有价值的东西?显然,如果提交给用户一堆需求文档和设计文档,它们对用户毫无价值。
答案是快速迭代。一个拥抱变化的团队应该尽快开始生产真正可用的软件系统,尽快为用户交付产品,尽快接收用户的反馈并做出反应。一次迭代的周期应该短至一周甚至几天,并且每天都必须保证可以集成一个可用的版本——这并非天方夜谭,在微软公司的开发实践中你就可以找到“每日构建”这一条目。
除了快速提供可用的产品之外,一个拥抱变化的团队还必须快速获得用户的反馈——不是通过电话或者通过商务部门的中转,也不是通过每周一次的项目例会,敏捷团队需要每天、每时每刻与用户交流,才能随时根据用户的反馈调整自己的作品。一种可行的策略就是现场客户:一位客户代表和开发团队在同一间办公室工作,随时解答开发团队的疑问。如果客户代表的本职工作可以通过网络进行,而且解答一个疑问只需要短短几句话,这种策略或许并不像它听起来那么难以实现。如果确实无法获得现场客户,在团队内部确定一名领域专家扮演现场客户的角色也是一种替代方案。
需求变更总是软件开发中的一个大问题,甚至由此衍生出了名为“变更控制”的学问。但是,如果把决定权交还给客户,由客户来决定每个迭代版本应该包含哪些特性、应该做出哪些修改,开发团队就无须面临艰难的抉择。毕竟,时间和预算都是有限的,只有客户能判断开发哪些东西能够提供最大化的价值。但这就要求开发团队能够提供精确的估算——只有当每次迭代周期都非常短时,你才有可能准确地估算出下一次迭代可以完成多少工作,估算未来三个月的工作量是毫无意义的。
最重要的(也是最根本的)是:一个拥抱变化的团队必须力求简单。在各种可行的方案中,他们应该始终选择最简单的一种;开发过程生成的产品也应该尽量精简——既然可以用单元测试来描述程序模块的功能,就不要再强求详细设计文档。俗话说“船小好调头”,越简洁的设计越容易接纳变化。
面向架构的软件开发
软件是一门抽象的艺术,软件的发展史就是人们不断提升抽象层次的历史。进入21世纪,面向对象编程语言等技术已经非常成熟,软件开发的最大问题已经不再是编写程序代码,而是如何建立概念模型使之体现业务需求、如何设计系统结构使之具有灵活性和可维护性。换句话说,软件系统中最重要的部分将是架构(architecture),而不是具体的实现技术和实现代码;描述软件系统最重要的语言将是模式语言(pattern language),而不是具体的编程语言。掌握架构能力和模式语言,将是一个称职的软件开发者必备的技能。
然而,架构和模式又不能脱离于具体的语言和实现技术存在——多年开发企业级应用的经验告诉我,如果一个系统号称“完全不依赖任何语言和实现技术”,那么这个系统也不会有任何用处。举一个最简单的例子:实现同样功能的一个软件产品,如果它主要作为类库(library)提供进程内服务,那么它的架构应该完全遵循面向对象原则,通过多个对象的多次协作完成业务操作;而如果需要提供远程调用服务,客户端与服务器端的每次交互就会造成巨大的网络开销,那么就需要按照面向服务的体系结构(Service-Oriented Architecture,SOA)来设计,尽量降低交互的频率。所以,一个称职的软件开发者不仅必须具备架构设计的能力,还必须清楚地知道用什么技术来实现自己的架构,否则他所设计的架构就会成为空中楼阁。
面向架构的软件开发,再加上各种各样极大提升编程效率的工具,不难想象,未来的大多数软件开发将由少数精英来完成——我更愿意把这些人叫做“软件工匠”,因为他们的工作将更多地体现出工艺性甚至是艺术性,更少地体现工程性。实际上,这已经是迫在眉睫的事实了。在过去的十年中,微软、Borland等世界领先的软件企业一直实行着小型团队、人性化管理、重视个人才华胜于制度的软件开发模式;最近一两年,真正在贯彻着CMM之类工程化方法的,在世界范围内也只剩下印度、爱尔兰等国以外包项目为主的软件企业了。
面向架构的软件开发要求高水平的小型开发团队,要求客户与开发团队之间直接而频繁的交流,要求在短迭代中不断验证和修改整个软件系统。因此,面向架构的软件开发必然是敏捷的。惟有敏捷的团队才能获得真正符合用户需要的软件架构和产品——而不是在汗牛充栋的文档中不断地浪费时间。
小结
在规则和需求瞬息万变的商业领域,传统的软件工程方法很难适应快速的变化,给软件企业带来了巨大的困扰。敏捷方法给我们一种新的思路:与其试图控制变化,不如努力拥抱变化。建立一种适应变化、拥抱变化的开发模式,软件企业将在充满变化的市场竞争中占得先机。为了拥抱变化,敏捷方法提倡采用先进的技术和高水平的小型团队,并辅以人性化的管理,充分发挥软件开发者的才华,建立畅通的交流机制,使软件开发团队与客户共同进步,在项目中实现双赢。
应该特别强调的是:尽管敏捷方法强调人性化管理,但在敏捷团队内部对于软件开发者有着极其严格的纪律约束——甚至比绝大多数传统软件工程方法更加严格。对于软件开发者的个人修养和工作方式,XP(eXtreme Programming,XP)等敏捷方法提出了一整套“军规”,其严格、精密的程度甚至能够以分钟计。拥有良好习惯的优秀开发者,才有可能充分发挥自己的才华。在以后的文章中,我将逐步介绍实施敏捷方法的过程和要求。我们后会有期。

<!-- 这篇资讯中是否有争论或者观点交锋呢?如果希望读者参与,请点击<a href="http://pkzone.csdn.net/AdminManage/Editor_Apply.aspx" target="_blank">这里</a>,创建一个观点PK -->
分享到:
评论

相关推荐

    敏捷开发的艺术

    本书为那些正在考虑应用敏捷开发来构建有价值软件的人们提供了实用的指导。现在已经有大量的书籍描述敏捷开发是什么或者为什么它能帮助软件项目成功,但很少有哪一本书能把针对开发者、管理者、测试者和客户的信息...

    敏捷开发知识体系

    《敏捷开发知识体系》面向敏捷实践者学习敏捷知识和敏捷软件开发企业进行敏捷转型的需要,旨在帮助个人更快地掌握敏捷开发知识,帮助企业更好地实施敏捷转型。主要内容包括:敏捷开发的哲学理念、价值观、敏捷开发...

    敏捷开发 敏捷开发 敏捷开发 敏捷开发

    敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发

    敏捷开发中编写高质量Java代码

    敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。 Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,以及缺乏统一的标准和...

    CSDN_敏捷开发相关文档全收集_5

    公司项目需要利用敏捷开发模式进行开发,故在CSDN上进行相关资料的查找搜集。27个资料,293 MB,花费了150多积分.现将所有查到的文档进行分包压缩,贡献给大家。因为实在花的积分过多,请原谅我不是无偿的。每个...

    敏捷开发-敏捷软件开发:原则、模式与实践

    在本书中,享誉全球的软件开发专家和软件工程大师Robert C.Martin将向您展示如何解决软件开发人员、项目经理及软件项目领导...这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。

    轻松Scrum之旅:敏捷开发故事

    敏捷开发

    敏捷开发管理试题及参考答案.pdf

    敏捷开发管理试题及参考答案.pdf敏捷开发管理试题及参考答案.pdf敏捷开发管理试题及参考答案.pdf敏捷开发管理试题及参考答案.pdf敏捷开发管理试题及参考答案.pdf敏捷开发管理试题及参考答案.pdf敏捷开发管理试题及...

    华为敏捷开发介绍(华为敏捷软件开发解读V1.01).ppt

    华为敏捷开发,devops,敏捷开发流程,需求分析,华为管理流程

    敏捷开发.doc

    敏捷开发

    CSDN_敏捷开发相关文档全收集_2

    公司项目需要利用敏捷开发模式进行开发,故在CSDN上进行相关资料的查找搜集。27个资料,293MB,花费了150多积分.现将所有查到的文档进行分包压缩,贡献给大家。因为实在花的积分过多,请原谅我不是无偿的。每个...

    敏捷开发知识总结

    极限编程的思想体现了适应客户需求的快速变化,激发开发者的热情,也是目前敏捷开发思维的重要支持者。 敏捷软件开发是一个开发软件的管理新模式,用来替代以文件驱动开发的瀑布开发模式。   敏捷开发集成了新型...

    CSDN_敏捷开发相关文档全收集_6

    公司项目需要利用敏捷开发模式进行开发,故在CSDN上进行相关资料的查找搜集。27个资料,293 MB,花费了150多积分.现将所有查到的文档进行分包压缩,贡献给大家。因为实在花的积分过多,请原谅我不是无偿的。每个...

    项目管理-敏捷开发模板.xlsx

    一般公司引进敏捷开发模式都需要一个大的Backlog(敏捷开发面板),但是如果公司没有这个条件,怎么实现类似敏捷的面板的管理方式呢。 在我的项目中,使用了EXCEL制作了一个电子敏捷开发面板。可以让你很方便的采用...

    **敏捷开发框架开发手册

    **敏捷开发框架开发手册 1.部署和管理 2.自定义表单开发 3.代码生成器开发 4.。。

    敏捷开发项目流程介绍,什么是敏捷开发

    敏捷开发

    论文研究 - 敏捷开发:探索从业者想知道的东西

    因此,在这项研究中,我们进入了实践者的世界,探索他们想了解的有关敏捷开发的知识。 我们使用一种多方法论方法,一项调查和一项解释性案例研究相结合的方式进行了研究。 我们了解到,在以下方面,敏捷开发尚未...

    敏捷开发pdf学习敏捷开发的资料

    敏捷开发pdf学习敏捷开发的资料,非常简洁的介绍了敏捷开发的流程

    敏捷开发|项目管理|#1-敏捷开发为什么会出现

    敏捷开发为什么会出现呢,那最简介的解释就是,传统的开发模式已经越来越不能适应,某些领域的飞速发展。瀑布模型可是说是典型的预见性为驱动的方法,将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、...

Global site tag (gtag.js) - Google Analytics