全球领先的IT技术网站 |首页 |Tags |网站地图

您现在正在浏览:首页 » 开发频道 » 其他 » 敏捷开发

RSS订阅

敏捷开发

暂无Tags标签
摘要:敏 捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的 特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏 捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的 特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷建模(Agile Modeling,AM)的价值观包括了XP的四个价值观:沟通简单反馈勇气,此外,还扩展了第五个价值观:谦逊。

沟通

建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。

简单

画一两张图表来代替几十甚至几百行的代码,通过这种方法,建模成为简化软件和软件(开发)过程的关键。这一点对开发人员而言非常重要-它简单,容易发现出新的想法,随着你(对软件)的理解的加深,也能够很容易的改进。

反馈

Kent Beck在Extreme Programming Explained中有句话讲得非常好:“过度自信是编程的职业病,反馈则是其处方。”通过图表来交流你的想法,你可以快速获得反馈,并能够按照建议行事。

勇气

勇气非常重要,当你的决策证明是不合适的时候,你就需要做出重大的决策,放弃或重构(refactor)你的工作,修正你的方向。

谦逊

最优秀的开发人员都拥有谦逊的美德,他们总能认识到自己并不是无所不知的。事实上,无论是开发人员还是客户,甚至所有的 project stakeholder,都有他们自己的专业领域,都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值,都应该被尊重。
 

核心原则

◆主张简单
当从事开发工作时,你应当主张最简单的解决方案就是最好的解决方案。不要过分构建
敏捷开发

  敏捷开发

(overbuild)你的软件。用AM的说法就是,如果你现在并不需要这项额外功能,那就不要在模型中增加它。要有这样的勇气:你现在不必要对这个系统进行过分的建模(over-model),只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单。
◆拥抱变化
需求时刻在变,人们对于需求的理解也时刻在变。项目进行中,Project stakeholder可能变化,会有新人加入,也会有旧人离开。Project stakeholder的观点也可能变化,你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行,项目环境也在不停的变化,因此你的开发方 法必须要能够反映这种现实。
◆你的第二个目标是可持续性
即便你的团队已经把一个能够运转的系统交付给用户,你的项目也还可能是失败的--实现Project stakeholder的需求,其中就包括你的系统应该要有足够的鲁棒性(robust ),能够适应日后的扩展。就像Alistair Cockburn常说的,当你在进行软件开发的竞赛时,你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版,或是你正在构建的 系统的运转和支持。要做到这一点,你不仅仅要构建高质量的软件,还要创建足够的文档和支持材料,保证下一场比赛能有效的进行。你要考虑很多的因素,包括你 现有的团队是不是还能够参加下一场的比赛,下一场比赛的环境,下一场比赛对你的组织的重要程度。简单的说,你在开发的时候,你要能想象到未来。
◆递增的变化
和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上,你就算想这么做也不太可能。而且,你不用在模型中包容所有的细节,你只要足够的细节就够 了。没有必要试图在一开始就建立一个囊括一切的模型,你只要开发一个小的模型,或是概要模型,打下一个基础,然后慢慢的改进模型,或是在不在需要的时候丢 弃这个模型。这就是递增的思想。
◆令Stakeholder投资最大化
你的project stakeholder为了开发出满足自己需要的软件,需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资,也可以 要求你的团队不浪费资源。并且,他们还有最后的发言权,决定要投入多少的资源。如果是这些资源是你自己的,你希望你的资源被误用吗。
◆有目的的建模
对于自己的artifact,例如模型、源代码、 文档,很多开发人员不是担心它们是否够详细,就是担心它们是否太过详细,或担心它们是否足够正确。你不应该毫无意义的建模,应该先问问,为什么要建立这个 artifact,为谁建立它。和建模有关,也许你应该更多的了解软件的某个方面,也许为了保证项目的顺利进行,你需要和高级经理交流你的方法,也许你需 要创建描述系统的文档,使其他人能够操作、维护、改进系统。如果你连为什么建模,为谁建模都不清楚,你又何必继续烦恼下去呢?首先,你要确定建模的目的以 及模型的受众,在此基础上,再保证模型足够正确和足够详细。一旦一个模型实现了目标,你就可以结束目前的工作,把精力转移到其它的工作上去,例如编写代码 以检验模型的运作。该项原则也可适用于改变现有模型:如果你要做一些改变,也许是一个熟知的模式,你应该有做出变化的正确理由(可能是为了支持一项新的需 求,或是为了重构以保证简洁)。关于该项原则的一个重要暗示是你应该要了解你的受众,即便受众是你自己也一样。例如,如果你是为维护人员建立模型,他们到 底需要些什么?是厚达500页的详细文档才够呢,还是10页的工作总览就够了?你不清楚?去和他们谈谈,找出你想要的。
◆多种模型
开发软件需要使用多种模型,因为每种模型只能描述软件的单个方面,“要开发现今的商业应
敏捷开发

  敏捷开发

用,我们该需要什么样的模型?”考虑到现今的软件的复杂性,你的建模工具箱应 该要包容大量有用的技术(关于artifact的清单,可以参阅AM的建模artifact)。有一点很重要,你没有必要为一个系统开发所有的模型,而应 该针对系统的具体情况,挑选一部分的模型。不同的系统使用不同部分的模型。比如,和家里的修理工作一样,每种工作不是要求你用遍工具箱里的每一个工具,而 是一次使用某一件工具。又比如,你可能会比较喜欢某些工具,同样,你可会偏爱某一种模型。有多少的建模 artifact可供使用呢,如果你想要了解这方面的更多细节,我在Be Realistic About the UML中列出了UML的相关部分,如果你希望做进一步的了解,可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。
◆高质量的工作
没有人喜欢烂糟糟的工作。做这项工作的人不喜欢,是因为没有成就感;日后负责重构这项工作(因为某些原因)的人不喜欢,是因为它难以理解,难以更新;最终用户不喜欢,是因为它太脆弱,容易出错,也不符合他们的期望。
◆快速反馈
从开始采取行动,到获得行动的反馈,二者之间的时间至关紧要。和其他人一共开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时 候,例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作,去了解他们的的需求,去分析这些需求,或是去开发满足他们需求的用户界面,这 样,你就提供了快速反馈的机会。
◆软件是你的主要目标
软件开发的主要目标是以有效的方式,制造出满足project stakeholder需要的软件,而不是制造无关的文档,无关的用于管理的artifact,甚至无关的模型。任何一项活动(activity ),如果不符合这项原则,不能有助于目标实现的,都应该受到审核,甚至取消。
◆轻装前进
你建立一个artifact,然后决定要保留它,随着时间的流逝,这些artifact都需要维护。如果你决定保留7个模型,不论何时,一旦有变化发生 (新需求的提出,原需求的更新,团队接受了一种新方法,采纳了一项新技术...),你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想 要保留的仅是3个模型,很明显,你实现同样的改变要花费的功夫就少多了,你的灵活性就增强了,因为你是在轻装前进。类似的,你的模型越复杂,越详细,发生 的改变极可能就越难实现(每个模型都更“沉重”了些,因此维护的负担也就大了)。每次你要决定保留一个模型时,你就要权衡模型载有的信息对团队有多大的好 处(所以才需要加强团队之间,团队和project stakeholder之间的沟通)。千万不要小看权衡的严重性。一个人要想过沙漠,他一定会携带地图,帽子,质地优良的鞋子,水壶。如果他带了几百加仑 的水,能够想象的到的所有求生工具,一大堆有关沙漠的书籍,他还能过得去沙漠吗?同样的道理,一个开发团队决定要开发并维护一份详细的需求文档,一组详细 的分析模型,再加上一组详细的架构模型,以及一组详细的设计模型,那他们很快就会发现,他们大部分的时间不是花在写源代码上,而是花在了更新文档上。

补充原则

◆内容比表示更重要
一个模型有很多种的表示方法。例如,可以通过在一张纸上放置即时贴的方法来建立一个用户界面规格(基本/低精度原型)。它的表现方式可以是纸上或白板上的 草图,可以是使用原型工具或编程工具建立和传统的原型,也可以是包括可视界面和文本描述的正式文档。有一点很有意思,一个模型并不一定就是文档。它们通常 作为其它artifact的输入,例如源代码,但不必把它们处理为正式的文档,即使是使用CASE工具建立的复杂的图表,也是一样。要认识到一点,要利用 建模的优点,而不要把精力花费在创建和维护文档上。
你不可能完全精通某项技术,你总是有机会学习新的知识,拓展知识领域。把握住这个机会,和他人一同工作,向他人学习,试试做事的新方式,思考什么该做,什么不该做。技术的变化非常的快,现有的技术(例如Java)以难以置信的速度在改进,新的技术(例如C#.NET) 也在有规律的产生。现存开发技术的改进相对会慢一些,但也在持续的改进中--计算机产业属于工业,我们已经掌握了其中的试验基本原理,但我们还在不断的研 究,不断的实践,不断的改进我们对它的了解。我们工作在一个变化是家常便饭的产业中,我们必须通过训练、教育、思考、阅读、以及和他人合作,抓住每一个机 会学习新的处事之道。
◆了解你的模型
因为你要使用多种模型,你需要了解它们的优缺点,这样才能够有效的使用它们。
◆了解你的工具
软件(例如作图工具、建模工具)有各种各样的特点。如果你打算使用一种建模工具,你就应当了解什么时候适合用它,什么时候不适合用它。
◆局部调整
你的软件开发方法要 能够反映你的环境,这个环境包括组织特征,project stakeholder的特征,项目自身的特征。有可能受其影响的问题包括:你使用的建模技术(也许你的用户坚持要看到一个细节的用户界面,而不是初始草 图或基本原型);你使用的工具(可能你没有数字照相机的预算,或是你已经拥有某个CASE工具的license);你遵循的软件过程(你的组织采用XP的开发过程,或是RUP,或是自己的过程)。因此你会调整你的方法,这种调整可能是针对项目的,也可能是针对个人的。例如,有些开发人员倾向于使用某一类工具,有些则不用。有些人在编码上花大力气,基本不做建模,有些则宁可在建模上多投入一些时间。
◆开放诚实的沟通
人们需要能够自由的提出建议,而且人们还应该能够感受到他们是自由的。建议可能是和模型有关的想法:也许是某些人提出某部分新的设计方法,或是某个需求的 新的理解;建议还可能是一些坏消息,例如进度延误;或仅仅是简单的工作状况报告。开放诚实的沟通是人们能够更好的决策,因为作为决策基础的信息会更加准 确。
◆相信直觉
有时你会感觉到有什么地方出问题了,或是感觉什么地方有不一致的情况,或是某些东西感觉不是很对。其实,这种感觉很有可能就是事实。随着你的软件开发的经 验的增加,你的直觉也会变得更敏锐,你的直觉下意识之间告诉你的,很可能就是你工作的关键之处。如果你的直觉告诉你一项需求是没有意义的,那你就不用投入 大量的精力和用户讨论这方面的问题了。如果你的直觉告诉你有部分的架构不能满足你的需要,那就需要建立一个快速技术原型来验证你的理论。如果你的直觉告诉 设计方法A要比设计方法B好,而且并没有强有力的理由支持你选择某一个方法,那就尽管选择方法A。勇气的价值就已经告诉你,如果未来证实你的直觉是错的, 你也有能力来挽救这种情况。你应该有这种自信,这很重要。

0 »

开发专题

JavaScript成为网络霸主的“绯闻”
JavaScript成为网络霸主的“绯闻”

JavaScript正凭借新型工具与功能提升以极度夸张的速度吞噬整个世界。我们是否应该接受这一无法逆转的趋势? 还记得那些旧日往事吗?很多用户因为担心安全问题而在浏览器中禁用JavaScript。如...

C++是垃圾语言?!
C++是垃圾语言?!

Linux之父对C++进行了炮轰,说它是糟糕程序员的垃圾语言,可谓是一石激起千层浪,引起众多程序员朋友的关注和讨论。本专题给出正反方的讨论观点,供大家评说!另外,给出了编程语言的发展状况...

MySQL数据库入门与精通
MySQL数据库入门与精通

MySQL是一个跨平台的开源关系型数据库管理系统,目前MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低,尤其是开放源码这一特点,许多中小型网站为了降低...

最新资讯

相关热门文章

  • 本文暂无Tags标签