敏捷开发 订阅
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 [1] 展开全文
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 [1]
信息
外文名
Agile Development
方    法
迭代、循序渐进
中文名
敏捷开发
核    心
用户的需求进化
敏捷开发原则
敏捷建模(AM)定义了一系列的核心原则和辅助原则,它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来,在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见!基本上,本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作;这样,对于这些借鉴于XP的原则,我们可以从另一个角度来看待。◆主张简单当从事开发工作时,你应当主张最简单的解决方案就是最好的解决方案。不要过分构建 (overbuild)你的软件。用AM的说法就是,如果你现在并不需要这项额外功能,那就不要在模型中增加它。要有这样的勇气:你现在不必要对这个系统进行过分的建模(over-model),只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单。◆拥抱变化需求时刻在变,人们对于需求的理解也时刻在变。项目进行中,Project stakeholder可能变化,会有新人加入,也会有旧人离开。Project stakeholder的观点也可能变化,你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行,项目环境也在不停的变化,因此你的开发方法必须要能够反映这种现实。◆你的第二个目标是可持续性即便你的团队已经把一个能够运转的系统交付给用户,你的项目也还可能是失败的--实现项目投资者的需求,其中就包括你的系统应该要有足够的鲁棒性(robust ),能够适应日后的扩展。就像Alistair Cockburn常说的,当你在进行软件开发的竞赛时,你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版,或是你正在构建的系统的运转和支持。要做到这一点,你不仅仅要构建高质量的软件,还要创建足够的文档和支持材料,保证下一场比赛能有效的进行。你要考虑很多的因素,包括你现有的团队是不是还能够参加下一场的比赛,下一场比赛的环境,下一场比赛对你的组织的重要程度。简单的说,你在开发的时候,你要能想象到未来。◆递增的变化和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上,你就算想这么做也不太可能。而且,你不用在模型中包容所有的细节,你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型,你只要开发一个小的模型,或是概要模型,打下一个基础,然后慢慢的改进模型,或是在不再需要的时候丢弃这个模型。这就是递增的思想。◆令投资最大化你的项目投资者为了开发出满足自己需要的软件,需要投入时间、金钱、设备等各种资源。投资者应该可以选取最好的方式投资,也可以要求你的团队不浪费资源。并且,他们还有最后的发言权,决定要投入多少的资源。如果是这些资源是你自己的,你希望你的资源被误用吗。◆有目的的建模对于自己的产出,例如模型、源代码、文档,很多开发人员不是担心它们是否够详细,就是担心它们是否太过详细,或担心它们是否足够正确。你不应该毫无意义的建模,应该先问问,为什么要建立这个产出,为谁建立它。和建模有关,也许你应该更多的了解软件的某个方面,也许为了保证项目的顺利进行,你需要和高级经理交流你的方法,也许你需要创建描述系统的文档,使其他人能够操作、维护、改进系统。如果你连为什么建模,为谁建模都不清楚,你又何必继续烦恼下去呢?首先,你要确定建模的目的以及模型的受众,在此基础上,再保证模型足够正确和足够详细。一旦一个模型实现了目标,你就可以结束工作,把精力转移到其它的工作上去,例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型:如果你要做一些改变,也许是一个熟知的模式,你应该有做出变化的正确理由(可能是为了支持一项新的需求,或是为了重构以保证简洁)。关于该项原则的一个重要暗示是你应该要了解你的受众,即便受众是你自己也一样。例如,如果你是为维护人员建立模型,他们到底需要些什么?是厚达500页的详细文档才够呢,还是10页的工作总览就够了?你不清楚?去和他们谈谈,找出你想要的。◆多种模型开发软件需要使用多种模型,因为每种模型只能描述软件的单个方面,“要开发现今的商业应 用,我们该需要什么样的模型?”考虑到现今的软件的复杂性,你的建模工具箱应该要包容大量有用的技术(关于产出的清单,可以参阅AM的建模工件)。有一点很重要,你没有必要为一个系统开发所有的模型,而应该针对系统的具体情况,挑选一部分的模型。不同的系统使用不同部分的模型。比如,和家里的修理工作一样,每种工作不是要求你用遍工具箱里的每一个工具,而是一次使用某一件工具。又比如,你可能会比较喜欢某些工具,同样,你可会偏爱某一种模型。有多少的建模工件可供使用呢,如果你想要了解这方面的更多细节,我在Be Realistic About the UML中列出了UML的相关部分,如果你希望做进一步的了解,可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。◆高质量的工作没有人喜欢烂糟糟的工作。做这项工作的人不喜欢,是因为没有成就感;日后负责重构这项工作(因为某些原因)的人不喜欢,是因为它难以理解,难以更新;最终用户不喜欢,是因为它太脆弱,容易出错,也不符合他们的期望。◆快速反馈从开始采取行动,到获得行动的反馈,二者之间的时间至关紧要。和其他人一共开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时候,例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作,去了解他们的的需求,去分析这些需求,或是去开发满足他们需求的用户界面,这样,你就提供了快速反馈的机会。◆软件是你的主要目标软件开发的主要目标是以有效的方式,制造出满足投资者需要的软件,而不是制造无关的文档,无关的用于管理的工件,甚至无关的模型。任何一项活动(activity ),如果不符合这项原则,不能有助于目标实现的,都应该受到审核,甚至取消。◆轻装前进你建立一个工件,然后决定要保留它,随着时间的流逝,这些工件都需要维护。如果你决定保留7个模型,不论何时,一旦有变化发生(新需求的提出,原需求的更新,团队接受了一种新方法,采纳了一项新技术...),你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型,很明显,你实现同样的改变要花费的功夫就少多了,你的灵活性就增强了,因为你是在轻装前进。类似的,你的模型越复杂,越详细,发生的改变极可能就越难实现(每个模型都更“沉重”了些,因此维护的负担也就大了)。每次你要决定保留一个模型时,你就要权衡模型载有的信息对团队有多大的好处(所以才需要加强团队之间,团队和项目投资者之间的沟通)。千万不要小看权衡的严重性。一个人要想过沙漠,他一定会携带地图,帽子,质地优良的鞋子,水壶。如果他带了几百加仑的水,能够想象的到的所有求生工具,一大堆有关沙漠的书籍,他还能过得去沙漠吗?同样的道理,一个开发团队决定要开发并维护一份详细的需求文档,一组详细的分析模型,再加上一组详细的架构模型,以及一组详细的设计模型,那他们很快就会发现,他们大部分的时间不是花在写源代码上,而是花在了更新文档上。最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。经常交付可以工作的软件,从几星期到几个月,时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准。敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。简单——尽可能减少工作量的艺术至关重要。最好的架构、需求和设计都源自自我组织的团队。每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。 [2] 
收起全文
精华内容
下载资源
问答
  • 敏捷开发

    千次阅读 2017-09-18 13:41:55
    敏捷开发
    
    

    一个团队,每位成员为团队目标负责。

    一.核心方法
    0.每位团队成员会团队目标负责
    团队成员可以提出改进的想法,只要该想法符合团队目标,然后推动完成。
    每位成员即是管理者也是执行者。

    1.需求评审演讲项目成员轮流

    2.两名成员交叉设计,交叉开发,互相codeReview

    3.项目经理codeReview核心功能
    其他成员完成较快则可帮助其他人codeReview

    4.晨会,问题及时提出
    若某个功能开发进度有延迟,及时提出,可寻求团队其他成员帮助完成,一个团队。

    5.快速设计
    初始设计时,可用草稿纸等快速设计方法完成设计,同另一个同学讨论。用visio较慢。

    6.交叉设计
    目的是让每个成员对每个模块都有相应了解,每个项目中每个成员可能会负责不同模块。

    7.项目总结
    总结出项目中做的好的方面,不好的可以改进的方面,然后可采用的新的实践是什么。
    新的实践指定相应负责人,并指定一个完成时间。

    8.设计简单
    只做必要设计,一些开发成本较大的扩展设计可以先简单设计,当然具体看对需求的变化把握。

    9.评审时间短
    评审时间40分钟内结束。

    10.评审后,不足改进,只需找到相应成员确认即可,不需要再开会议

    11.分阶段设计
    按功能优化级设计,必要的设计先做,有产出与相应同事交流设计。


    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,461
精华内容 12,184
关键字:

敏捷开发