敏捷开发 订阅
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 [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] 
收起全文
精华内容
参与话题
问答
  • 敏捷开发

    千次阅读 多人点赞 2019-08-12 20:39:23
    敏捷开发前言迭代开发增量开发敏捷开发的好处早期交付降低风险如何进行每一次迭代敏捷开发的价值观十二条原则 前言    迭代开发   敏捷开发的核心是迭代开发(iterative development)。敏捷一定是采用迭代开发...

    前言

      

    迭代开发

      敏捷开发的核心是迭代开发(iterative development)。敏捷一定是采用迭代开发的方式。那么什么是"迭代开发"呢?迭代的英文是 iterative,直译为"重复",迭代开发其实就是"重复开发"。
      对于大型软件项目,传统的开发方式是采用一个大周期(比如半年)进行开发,整个过程就是一次"大开发";迭代开发的方式则不一样,它将开发过程拆分成多个小周期,即一次"大开发"变成多次"小开发",每次小开发都是同样的流程,所以看上去就好像重复在做同样的步骤。
      举例来说,SpaceX 公司想造一个大推力火箭,将人类送到火星。但是,它不是一开始就造大火箭,而是先造一个最简陋的小火箭 Falcon 1。结果,第一次发射就爆炸了,直到第四次发射,才成功进入轨道。然后,开发了中型火箭 Falcon 9,九年中发射了70次。最后,才开发 Falcon 重型火箭。如果 SpaceX 不采用迭代开发,它可能直到现在还无法上天。
      迭代开发将一个大任务,分解成多次连续的开发,本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本,然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤,不断改进产品,添加新功能。通过频繁的发布,以及跟踪对前一次迭代的反馈,最终接近较完善的产品形态。

    增量开发

      迭代开发只是要求将开发分成多个迭代,并没有回答一个重要的问题:怎么划分迭代,哪个任务在这个迭代,哪个任务在下个迭代?这时,一般采用"增量开发"(incremental development)划分迭代。
      所谓的"增量开发",指的是软件的每个版本,都会新增一个用户可以感知的完整功能。也就是说,按照新增功能来划分迭代。
      举例来说,房地产公司开发一个10栋楼的小区。如果采用增量开发的模式,该公司第一个迭代就是交付一号楼,第二个迭代交付二号楼…每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基,第二个迭代建好每栋楼的骨架,第三个迭代架设屋顶…
    增量开发加上迭代开发,才算是真正的敏捷开发。

    敏捷开发的好处

    早期交付

      敏捷开发的第一个好处,就是早期交付,从而大大降低成本。
      还是房地产公司为例,如果按照传统的"瀑布开发模式",先挖10栋楼的地基、再盖骨架、然后架设屋顶,每个阶段都等到前一个阶段完成后开始,可能需要两年才能一次性交付10栋楼。也就是说,如果不考虑预售,该项目必须等到两年后才能回款。
      敏捷开发是六个月后交付一号楼,后面每两个月交付一栋楼。因此,半年就能回款10%,后面每个月都会有现金流,资金压力就大大减轻了。

    降低风险

      敏捷开发的第二个好处是,及时了解市场需求,降低产品不适用的风险。
      请想一想,哪一种情况损失比较小:10栋楼都造好以后,才发现卖不出去,还是造好第一栋楼,就发现卖不出去,从而改进或停建后面9栋楼?
      对于软件项目来说,先有一个原型产品,了解市场的接受程度,往往是项目成功的关键。有一本书叫做《梦断代码》,副标题就是"20+个程序员,三年时间,4732个bug,100+万美元,最后失败的故事",这就是没有采用敏捷开发的结果。相反的,Instagram 最初是一个地理位置打卡 App,后来发现用户不怎么在乎地理位置,更喜欢上传照片,就改做照片上传软件,结果成了独角兽。
      由于敏捷开发可以不断试错,找出对业务最重要的功能,然后通过迭代,调整软件方向。相比传统方式,大大增加了产品成功的可能性。如果市场需求不确定,或者你对该领域不熟悉,那么敏捷开发几乎是唯一可行的应对方式。

    如何进行每一次迭代

      虽然敏捷开发将软件开发分成多个迭代,但是也要求,每次迭代都是一个完整的软件开发周期,必须按照软件工程的方法论,进行正规的流程管理。

     &emssp;具体来说,每次迭代都必须依次完成以下五个步骤。

    • 需求分析(requirements analysis)
    • 设计(design)
    • 编码(coding)
    • 测试(testing)
    • 部署和评估(deployment / evaluation)
      每个迭代大约持续2~6周。

    敏捷开发的价值观

    《敏捷软件开发宣言》里面提到四个价值观。

    • 程序员的主观能动性,以及程序员之间的互动,优于既定流程和工具。
    • 软件能够运行,优于详尽的文档。
    • 跟客户的密切协作,优于合同和谈判。
    • 能够响应变化,优于遵循计划。

    十二条原则

    该宣言还提出十二条敏捷开发的原则。

    • 通过早期和持续交付有价值的软件,实现客户满意度。
    • 欢迎不断变化的需求,即使是在项目开发的后期。要善于利用需求变更,帮助客户获得竞争优势。
    • 不断交付可用的软件,周期通常是几周,越短越好。
    • 项目过程中,业务人员与开发人员必须在一起工作。
    • 项目必须围绕那些有内在动力的个人而建立,他们应该受到信任。
    • 面对面交谈是最好的沟通方式。
    • 可用性是衡量进度的主要指标。
    • 提倡可持续的开发,保持稳定的进展速度。
    • 不断关注技术是否优秀,设计是否良好。
    • 简单性至关重要,尽最大可能减少不必要的工作。
    • 最好的架构、要求和设计,来自团队内部自发的认识。
    • 团队要定期反思如何更有效,并相应地进行调整。
    展开全文
  • 一、敏捷开发 “敏捷”是一种思想,与”瀑布“式(即传统开发模式)相比,敏捷开发有如下宣言 个体和互动高于流程和工具:意思是敏捷开发中每个人都可以提出自己的见解,而不必按照”流程“逐个向上级反应。目的是...

    一、敏捷开发

    “敏捷”是一种思想,与”瀑布“式(即传统开发模式)相比,敏捷开发有如下宣言

    • 个体和互动高于流程和工具:意思是敏捷开发中每个人都可以提出自己的见解,而不必按照”流程“逐个向上级反应。目的是为了降低”沟通的成本
    • 工作的软件高于详尽的文档:指你正在开发的软件,即使没有文档,你也可以开发(传统式开发中文档是高于开发的,没有”需求文档”,是不可以随便进行开发的)。不能停滞不前。
    • 客户合作高于合同谈判:指和客户之间的即使沟通,对于客户临时提出的要求来说,即使和合同文件上描述的不一致,我们也是要按照客户的要求做下去的

    • 响应变化高于遵循计划:在”敏捷“中,变化是无处不在的。所以我们不能按部就班,要积极的响应变化,最终实现“可交付的增量”这一目标。

    敏捷十二原则

    1. 工作的软件是首要进度度量标准

    2. 敏捷过程提倡持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度

    3. 不断地关注优秀的技能和好的设计会增强敏捷能力

    4. 简单----尽最大可能减少不必要的工作----是根本的

    5. 最好的构架、需求和设计出自与自组织的团队

    6. 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整

    二、Scrum

    定义:Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。

    Scrum三个角色

    • 产品负责人(Product Owner

    • Scrum Master

    • 开发团队

    Scrum三个工件

    • 产品BacklogProduct Backlog):迭代计划

    • SprintBacklog

    • 产品增量(Increment

    Scrum的5个活动

    • 产品Backlog梳理会议( Product Backlog Refinement
    • Sprint计划会议(Sprint Planning Meeting
    • 每日站会(Daily Scrum Meeting
    • Sprint评审会议(Sprint Review Meeting
    • Sprint回顾会议(Sprint Retrospective Meeting

    Scrum5个价值

    • 承诺 愿意对目标做出承诺
    • 专注把你的心思和能力都用到你承诺的工作上去
    • 开放– Scrum 把项目中的一切开放给每个人看
    • 尊重每个人都有他独特的背景和经验
    • 勇气有勇气做出承诺,履行承诺,接受别人的尊重

     

    展开全文
  • 文章目录0. 软件的生命周期1. 瀑布模型2. 螺旋模型3. 迭代模型4. 增量模型5....  瀑布模型是最早出现的软件开发模型,是所有其他软件开发模型的基础框架。与软件的生命周期不同的是,它缺少了软...

    0. 软件的生命周期

      软件的生命周期是指从软件产品的设想开始到软件不在使用而结束的时间。
      软件的生命周期分为6个阶段,即需求分析、计划、设计、编码、测试、运行维护

    1. 瀑布模型

    在这里插入图片描述
      瀑布模型是最早出现的软件开发模型,是所有其他软件开发模型的基础框架。与软件的生命周期不同的是,它缺少了软件运行维护阶段。
    描述: 每个阶段都只执行一次,因此是线性顺序的软件开发模型。
      正是由于每个阶段只执行一次,所以前面的需求分析和设计尤为重要。
    优点:

    1. 为项目提供了按阶段划分的检查点,强调开发的阶段性。
    2. 强调早期的计划及需求调查。
    3. 强调产品测试。

    缺点:

    1. 在各个阶段之间极少有反馈。
    2. 只有在项目周期的后期才能看到结果,所以风险往往至后期的测试阶段才显露,因此失去了及早的纠正过程。
    3. 单一流程,开发中的经验教训不能反馈应用于本产品的过程。

    适用项目: 需求比较明确且变更很少的项目。

    2. 螺旋模型

    一般在软件开发初期阶段需求不是很明确时,采用渐进式的开发模型。螺旋模型是渐进式开发模型的代表之一。
    在这里插入图片描述
    描述: 以原型为基础沿螺线旋转、每转一圈都经过计划/风险分析/实施/评估等过程且得到相应新版本、经过若干次螺旋上升得到最终版本。
    螺旋模型沿着螺旋线进行若干次迭代,图中的四个象限代表了一下活动:
    (1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
    (2)风险分析:分析评估所选方案,考虑如何识别和清楚风险;
    (3)实施工程:实施软件开发和验证;
    (4)客户评估:评价开发工作,提出修正建议,制定下一步计划。
      迭代开发的模式给软件测试带来了新的要求,它不允许有一段独立的测试时间和阶段,测试必须跟着开发的迭代而迭代,所以回归测试的很重要。
    优点:

    1. 强调严格的风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适用于规模庞大,风险大的项目
    2. 强调各个开发阶段的质量
    3. 这种的开发模式会提供机会探讨项目是否有价值继续下去。

    缺点:

    1. 由于引入了非常严格的风险识别、风险分析和风险控制,将会大大消耗人力、资源,如果严重的影响了项目的利润,风险分析将毫无意义。
    2. 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险。
    3. 软件建设周期长,但软件技术发展比较快,所以可能会和当前的技术水平有较大的的差距,无法满足当前用户需求。

    适用项目: 对新近开发,需求不明确的情况下,适合用螺旋模型进行开发,便于风险控制和需求变更。

    3. 迭代模型

    在这里插入图片描述
      开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上,迭代模型是类似小型的瀑布式项目。
    每一个迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
    描述:
    4. 一次迭代过程包括了所有软件开发流程。
    5. 每一次迭代均产生一个可发布的产品。
    6. 该产品为最终产品的一个子集。
    适用项目: 适合于事先不能完整定义产品的所有需求,计划多期开发的项目。

    4. 增量模型

    在这里插入图片描述
    描述:

    1. 采用随时间进展而交错的线性序列。
    2. 每个序列产生一个可发布的增量。
    3. 每一个增量产生一个可操作的产品。
    4. 第一个增量是核心产品。

    优点: 开始时不用投入大量人力资源,可以事先推出核心产品以稳定用户,可以有计划的管理技术风险。
    缺点: 需要开放式体系结构,可能会产生设计效果差、开发效率低的情况。
    适合项目: 需求经常发生改变的软件开发过程。

    增量和迭代模型的区别:
      增量是逐块建造的概念,例如:画一幅人物画,我们可以先画人的头部,再画身体,再画手脚……。
      迭代是反复求精的概念,例如:同样是画人物画,我们可以先画整体轮廓,在勾勒出基本雏形,再细化、着色……。

    5. 敏捷模型

    描述: 敏捷模型是一种轻量、高效、低风险、更强调团队协作和沟通的开发方式,适合于中小型开发团队,客户需求模糊或多变。
    特点:

    • 强调人与人之间的沟通。
    • 轻文档(弱化文档,但不是不需要文档)
    • 客户需要全程参与
    • 需求可以的变化
    展开全文
  • 敏捷软件开发之何为敏捷开发

    千次阅读 2010-08-23 09:26:00
    敏捷开发,Agile Development,就是指能够在需求迅速变化的情况下快速开发软件。我们接触最多敏捷实践方式有:极限编程(XP)、结对编程、测试驱动开发(TDD)等。 追究敏捷的历史,就必须要提到著名的...

    敏捷开发,Agile Development,就是指能够在需求迅速变化的情况下快速开发软件。我们接触最多敏捷实践方式有:极限编程(XP)、结对编程、测试驱动开发(TDD)等。

    追究敏捷的历史,就必须要提到著名的敏捷开发宣言,2001年,17位业界专家(其中包括我们非常熟悉的Martin, Martin Fowler)组成了一个敏捷联盟,并且创建了一份敏捷联盟宣言,宣扬了4条核心价值观:

     

     

     

    1, Individuals and interactions over processes and tools(人和交互重于过程和工具)

    2,Working software over comprehensive documentation(可以工作的软件重于易于理解的文档)

    3,Customer collaboration over contract negotiation(客户合作重于合同谈判)

    4,Responding to change over following a plan(响应变化重于遵照计划)

    此外,还有公开了12条敏捷软件开发的规则。

    1,Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    尽早地、持续地交付有价值的软件来满足客户的需求

    2,Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

    欢迎需求的变化,即使是项目后期的变更。敏捷过程能够驾驭变化,为客户带来竞争优势

    3,Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    经常交付可以工作的软件,时间间隔越短越好

    4,Business people and developers must work together daily throughout the project.

    整个项目开发期间,业务人员与开发人员应该工作在一起

    5,Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    围绕斗志高昂的人构建项目,给他们提供所需的环境,满足他们的需要,并信任他们

    6,The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    最有效的信息传达方式和与团队相处的方法是面对面交流

    7,Working software is the primary measure of progress.

    可以工作的软件是进度主要的度量标准

    8,Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    敏捷过程提倡可持续开发。投资方、开发者和用户应该总是保持一致的步伐

    9,Continuous attention to technical excellence and good design enhances agility.

    不断追求卓越技术和良好设计有助于加强敏捷性

    10,Simplicity--the art of maximizing the amount of work not done--is essential.

    简单--尽量减少工作量是非常重要的

    11,The best architectures, requirements, and designs emerge from self-organizing teams.

    最好的架构、需求和设计都出自于自我组织的团队

    12,At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    每隔一段时间,团队都要反思如何更有效率,并相应地调整自己的行为

    更详细可参照敏捷联盟的官方网站(http://www.agilealliance.org/)和敏捷开发宣言网站(http://www.agilemanifesto.org/)。

     

     

    从以上的4条价值观和12条敏捷开发的规则中,我们可以得出敏捷开发更强调的是,人与人之间的交互,包括程序员之间,程序员和客户之间的沟通,程序员不再是我们经常形容的代码工人等机械式的个体,受控于大量的规则文档和各种强大的工具。敏捷开发注重的是程序员的个人能力和沟通协作能力,一个具有良好沟通能力的程序员组成的团队更有可能获得成功,结对编程的方式就是利用两个人的紧密协作达到1+1>2的效果。敏捷开发不在受制于庞大笨重的工具,合适的工具对成功来说是很重要的,但是过于庞大笨重的工具就和缺少工具一样,都是不好的。项目中最常用的就是源代码管理工具,实际使用过程中发现昂贵的工具未必能体现其价值,有些免费开源的工具已经足够适用于项目的需求了。

    传统的软件开发,非常注重文档的作用,文档有助于软件的后续维护,有助于客户对产品的理解。但是过多的文档比过少的文档更糟,文档太多就需要花费大量的时间去编写和维护。对于需求经常变更的项目,维护庞大的文档本身就是一场噩梦。在敏捷开发中,编写和维护一份简短的系统和结构方面的文档已经足够了。对于后续维护,更细致的说明,应该体现在代码中,设计简单良好、可读性强的代码对程序员来说是比设计文档更直观更容易理解的文档,软件技术专家Jack Reeves曾经说过:“实际上满足工程设计标准的唯一软件文档,就是源代码清单”。所以在项目中,直到迫切需要时才编制文档,按照需求开发可运行的软件才是敏捷开发的重点。

    一般的软件项目合同中规定的都是整体的要求,但是我们知道软件开发中有太多的不确定性,这就会带来大量的需求变更,大的变更在项目开发过程总也是很正常的。经常有这样的案例:客户给我们需求,开发团队埋头苦干数月后完成交付客户,但是客户非常不满意,更有甚者,和客户的理解相差太大而导致项目失败。所以敏捷开发强调在开发过程中,保持和客户的沟通,面对面的沟通,完成模块时,应该马上请客户进行验收,这样项目结束的时候,验收的工作也基本完成了,极大地降低了项目失败的风险。敏捷中,强调随时应对变化的能力也会让开发团队有意识地设计和开发可扩展性好、可维护性好的软件。

    敏捷开发强调了程序员的能力,极大地发掘程序员个体的潜力和整体的协作来保证项目的成功,而不是靠文档、制度、工具等。

    我非常推崇敏捷软件开发模式,这样的方式可以极大地调动程序员的积极性、极大地加强团队的凝聚力。

    如果你对敏捷软件开发有兴趣,请关注敏捷开发相关的各种实践,给大家推荐一本敏捷开发的图书,由Robert C. Marting(敏捷宣言发起者之一)编写的经典著作:

     

     

     

    如果想深入关注敏捷的动态,也请关注发起敏捷宣言的各位大师们的著作,他们是:

    Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas。

    展开全文
  • 敏捷开发智慧敏捷系列

    千次阅读 2012-02-07 16:29:59
    敏捷开发智慧敏捷系列之一:序言 这是智慧敏捷系列的第一篇。(之一,之二,之三,之四,之五) 本文将解决各种敏捷中需要辩证思考的问题,包括:写文档还是不写文档?拥抱变更还是迭代期内无变更?持续交付的产品...
  • SCRUM敏捷开发视频教程

    万人学习 2015-08-20 14:22:02
    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • 敏捷开发实践

    2019-01-29 15:30:37
    本课程将讲解几种最基础也是最实用的敏捷开发实践,这些实践都在多个项目实践过,可快速借鉴。每个章节配有相应案例练习题,供学员快速掌握要领。内容包括: 如何编写准确切中客户价值的用户故事 如何输出完备的...
  • 敏捷开发解惑

    千次阅读 热门讨论 2014-03-06 12:08:03
    在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。敏捷开发的流行...
  • 敏捷开发简介

    千次阅读 2012-08-14 14:16:44
    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐,在全球一百强的企业中,敏捷也已大行其道,受到许多资深项目管理者和开发人员的推崇。欧美软件企业中,有近半企业已采用敏捷...
  • 如何理解敏捷开发? 没有参与过敏捷开发项目的人可能觉得敏捷开发抽象难懂。举个例子,敏捷开发像是在冲浪,一直处于动态、不断变化的环境中。在项目研发过程中出现的需求变化和挑战就是你在冲浪时要应对的海浪。...
  • 敏捷开发说起 “敏捷”概念最先是从软件开发领域引入的。传统的软件开发采用的是瀑布式开发的流程,把整个开发过程分成了需求、设计、编码、测试、发布等阶段,前面阶段达成后再进入下一个阶段,整个过程按照事先...
  • 敏捷开发学习分享

    千次阅读 多人点赞 2014-05-22 11:03:41
    程序员都很懒,你懂的! 敏捷不是快,而是拥抱变化(不断反馈...在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,
  • 敏捷开发

    千次阅读 2008-02-08 10:17:00
    敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目...

空空如也

1 2 3 4 5 ... 20
收藏数 47,239
精华内容 18,895
关键字:

敏捷开发