敏捷开发怎么控制成本_敏捷开发中如何控制成本 - CSDN
  • 需求的不可预见性 每一个我项目都会听到这样的小插曲,开发人员“项目最大的问题就是需求总是变化”,让人感到惊异的是任何人对此都表示不适应;在开发商业软件的过程中,变更是正常的,问题是我们如何面对它。 一...
          
    
    需求的不可预见性
          每一个我项目都会听到这样的小插曲,开发人员“项目最大的问题就是需求总是变化”,让人感到惊异的是任何人对此都表示不适应;在开发商业软件的过程中,变更是正常的,问题是我们如何面对它。
          一种方式是把需求变更的原因归结为糟糕的需求分析。这种观点的隐含意思是需求分析要在编码开始之前对需求有一个全面的理解,然后用户签字,签字之后启动开发过程并尽量不做变更。这里有一个问题那就是充分理解需求是很难的一件事情,而无法对需求的成本进行评估是这件事情更加难上加难。比如你要给你的车添加一个遮阳篷,而销售人员无法告诉你要添加10美元还是100美元。不知道花多少钱你怎么判断是不是要买?
           众多因素导致估计很难做到,因素之一是软件开发是一个设计活动难以计划和估计;因素之二:基本资源一直变化难以估计;因素之三:估计取决于过程中的人,人是很难进行预计和量化分析的。
    软件是没有物质实体的,在它没有做出来之前你很难看到它的位置。直到你用的时候你才知道那些功能点是有价值的哪些是没有价值的。这就要求人们应该认为软件需求是可以变化的,软件就是应该是“软”的。需求不仅仅是可变,而且是应该变;花费大量精力来跟客户确定需求,特别是客户也曾经涉足软件开发那就更糟了,因为他们知道软件变一下很容易;
          即使能得到一个精确的稳定的需求,你依然难逃厄运。今天的经济形势就决定了软件的内容快速变化。今天的好需求,六个月之后就可能一文不值;即使需求不断的改进也是跟不上经济发展的步伐;经济是无法预言的,否定这个观点的人要么是撒谎要么是有足够的实力可以左右市场;软件开发中的其他事情都取决于需求,你得不到一个稳定的需求,你也得不到一个可预见的计划。
    发包方如何节省开发费用,实现敏捷开发?
         一个用户说,太感谢csdn项目交易频道了,通过这个平台,他的项目虽然没有做成,但是学到了很多知识,大长见识。项目没有完成的原因很多,其中之一是会做的人太多了,他不知道该选哪个,另外他的需求更开发者谈判期间就变化了很多,我们的会员都很热情,每个竞标人都会提出自己的方案与建议,从而让这位客户更加冷静的思考过之后觉得这个功能开发的价值对整个项目的意义不大,从而放弃了开发。
          确实csdn交易平台比起其他频道虽严肃了很多,他再帮某些人赚钱的同时,也在给提供大家学习的机会,这是一个真枪实战的软件战场。每个项目都有平均10多个会员在竞夺,每个人都在进行博弈。发包方选定一位合适的承接人,最多因素主要是在价格方面的优惠,其次才会考虑技术问题。此时的发包方已经经历了几轮的谈判培训,他理所应当承接人应该为他开发更多的功能。他不会为开发人员节省时间,策划的功能很是齐全,不管那些功能是否有价值。其实不然,这些多余的无意义的功能并没有让您占便宜,不仅损失了您的开发费用,也增加了您的系统累赘,同时由于您已经占了那么多便宜,开发人员便不愿意理会您的需求变更。如果您以那些预算费用先开发一个简单的版本,当可实际操作系统的时候,在增加一些小的功能,不仅时间成本低,开发人员的免费合作度也会提升。
         下班了,要回家了,有空再修改此文。
    展开全文
  • 人们对敏捷开发和精益开发的关注兴趣越来越强。仅仅在IBM一家,过去的两年中,敏捷项目的数量从5个增加到了200多个。本文向您介绍使用敏捷开发成本和效益方面的优势。

    敏捷开发的种种优点时常被项目经理提及,但真正在项目中采用敏捷开发的却很少。这里分析敏捷开发的优点,将告诉您采用敏捷的项目如何从成本到收益得到好处。

    高效地开发出有品质的软件对各个行业的企业都是至关重要的,对最终用户尤为重要。软件企业不再能忍受18个月的产品周期,它们正在寻求各种方式变得更加灵活和多变以适应不断变化的市场需求。

    尽管我们需要一个高效的软件开发计划,但目前多数的开发项目仍然在进行中并且按传统的模式要求事先定义下所有的需求,同时这些需求在日后几乎不允许改变。问题是按这种方式多数客户都不能准确定义出它们的需求。夹杂着技术进步带来的变化,结果是令人气馁的。美国的一家研究公司Standish Group发现百分之九十的软件项目延期,百分之六十六的可以认为失败,以及百分之三十的完全报废。

    敏捷开发是一个使公司能够更快速地提交软件产品的开发过程方法。 它一个渐进的,协作的方法,其目标是有效及时地生产出高质量的软件。

    在敏捷开发的初期,它适用于较小的范围和相对简单的商业应用项目。 如今,局面已发生了显著变化。 当公司想要把敏捷开发应用在更广泛的项目上, 那么敏捷开发就需要处理当前软件开发组织所面临的大量业务、结构、和技术的复杂问题。

    正确的分析出转向敏捷的代价,你必须权衡利弊,同时开了开发风险的减少。例如,实施敏捷方法需要改变工程师花费时间的方式和他们如何完成所有的软件开发活动。这里强调一些进行转换应该关注的要点。

    ◆个人和交互(针对流程和工具)

    ◆工作软件(针对全面文档)

    ◆客户的合作(针对合同谈判)

    ◆响应变化(针对遵循计划)

    经理们必须考虑他们扮演的角色。多数敏捷精益开发经理使用更加放手的方式。他们让队员在特定的方向作先锋从而培育出成功转向敏捷精益开发的环境所需要的。

    敏捷增加了团结的软件交付效率,从而转化为客户满意度和收益。效率可以消除在特定活动上的浪费,它可能也许不能对大的目标产生影响。但是,效率不会告诉你正在做的事情是否正确,或者告诉你正确的做事顺序。效率更重要的是它帮助你实现目标。

    和其它重要的敏捷开发原则一样的一条是开发阶段的客户介入,如同前面提到过的,持续的团队协作。相关人员关于可工作代码的反馈和测试驱动开发对成功推出一个项目至关重要。相关人员包括业务相关者、软件使用人、客户支持、和其它企业IT部门人员,需要他们尽早的多多介入到敏捷项目整个开发周期中,积极参与建模和测试,有时甚至是参与开发。这一层次的介入使得他们能够看到软件开发的内部工作。这样促使开发人员关注于客户的优先级上而不是个人的优先级,这样可以提高产品的可用性。

    这些敏捷开发指导方针为企业提供了一个基础,一个使企业知道如何快速响应并准备好应对需求变化的基础。例如使用Scrum(混战:一个敏捷开发借用橄榄球运动中的术语),一个每天举行的“混战”(也就是会议)邀请所有项目相关人员。 每天开发人员回答三个问题:

    ◆从昨天到今天你完成了什么?

    ◆从今天到明天你打算做什么?

    ◆你遇到什么问题使你无法完成计划的目标?

    这个每日例会要求每个人清楚说明他所做的事情,这样其它队员可以在转为灾难之前指出错误和不兼容。它也可以确保在紧急情况出现时有人可以作出及时补救。

    敏捷开发常常被人批评为是过于随意的,这是不符合事实的。沟通交流和规则是敏捷开发的两个基本组成部分。敏捷最大的驱动原则是定期提交可工作的软件。提交周期越短,对规则的要求越高 - 例如,每次迭代都必须以可工作软件形式提供具体的可以度量的商业价值。

    展开全文
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...

    敏捷开发与迭代式开发是整体与局部的关系

     

    敏捷开发:敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。敏捷开发过程中,只有开发团队,没有各个开发环节工种(分析师、设计师、架构师等)的划分,所有的工作都是团队会议明确、按照时间节点和任务节点交付。敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。

    迭代开发:每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代。在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。迭代是敏捷开发中被划分出来的一个周期实现方式。可理解如下: 迭代一般指某版本的生产过程,包括从需求分析到测试完成; 版本一般指某阶段软件开发的结果,一个可交付使用的产品。迭代开发和敏捷开发都是弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。

     

    1、在项目初期先挑选系统核心架构的需求来实现,待系统核心架构完成后,再在系统核心架构的基础上不断的添加其他功能模块,通过累加开发的方式,来不断的完善系统,并在完善系统时,对系统的瑕疵或不足,不断的进行重构和改进设计工作。通过多个迭代的敏捷开发,并且每个迭代都会产生一个可使用的产品。这样一来,我们就会达到降低产品开发风险的目的。

     

    敏捷建模不可缺少,UML规范就是给我们提供建模标准的,建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通,通过画一两张图来代替几十甚至几百行的代码,建模成为简化软件和软件(开发)过程的关键,而且比代码更容易控制和改变。这一点对开发人员而言非常重要-它简单,容易发现出新的想法,随着你(对软件)的理解的加深,也能够很容易的改进。

    3、有目的的建模,开发软件需要使用多种模型,因为每种模型只能描述软件的单个方面,但是要特别强调,我们没有必要每次应用所有的模型,而应该针对系统的具体情况,挑选能够解决问题的模型,不应该毫无意义的建模。首先,你要确定建模的目的以及模型的受众,在此基础上,再保证模型足够正确和足够详细。只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单和完整。

    4、并行创建模型,和团队他人一同开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时候由于每种模型都有其长处和短处,没有一个模型能够完全满足建模的需要。例如你在收集需求时,你需要开发一些基本用例或用户素材,一个基本业务流程等。敏捷建模者会发现在任何时候,同时进行多个模型的开发工作,要比单纯集中于一个模型要有效率的多。

    5、持续测试和集成,每个迭代,我们都在做增加新功能和变更需求,产生新的版本,因此不断进行测试和集成,已达到可交付的产品,但是无论如何变更,模型都可以是最轻量级的持续改进,以保证最终的完整性和准确性。

     

    针对中大型的软件开发来说,用例驱动、架构为中心的,无论是从需求用例还是测试用例,都可以统一对应,保证过程的完整统一。敏捷开发是一个轻装前进的过程,每一个过程都只关注当前的任务,但是在开始之前,我们必须要高瞻远瞩,综合评定,无论是在一开始的架构模型还是开发过程中的每一个系统模型,都要有合适的取舍,但是也要有考虑可扩展,可变更,可迭代的过程。

     

     

    传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好。
    特别是前期阶段,设计的越完美,提交后的成本损失就越少。

    迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目的,以最短的时间,
    最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善。

    螺旋开发,很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。

     

    敏捷开发优点:

     1、降低风险
      2、得到早期用户反馈
      3、持续的测试和集成
      4、使用变更
      5、提高复用性
    --------------------- 
    作者:ouyanghaitao 
    来源:CSDN 
    原文:https://blog.csdn.net/ouyanghaitao/article/details/84923309 

    展开全文
  • 敏捷开发实战经验

    2018-05-30 18:22:35
    敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。...
         敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。以下分享产品项目里的九个敏捷开发实战经验。
      敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。
      在《Scrum:兼顾计划与灵活的敏捷开发》一文中,作者最后也提到过,借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。
      其实敏捷对产品经理的要求是很高的,需要安排至少两个迭代的任务,两个迭代的规划。
      对程序员的要求也很高,当所有的任务都拆散了之后,最终做出来的东西要形成一个产品,技术人员的整体意识要比较强,且一开始就得熟知产品的整个规划,否则到最后就会出现所有任务都已完结,合并出来的最终产物却是什么都不是。
      并且敏捷开发不仅仅是IT部门的事情,还需要各个业务部门对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。
      运行一段时间的敏捷之后,发现最容易接受敏捷这种方式的是开发团队,不管是瀑布式还是敏捷,只是做工作的形式不一样了,进度更容易把握了,更能适应需求的变化了,实质其实并没有变化。
      对测试团队来讲,测试资源调配会更加的紧张,敏捷要求做完一条侧一条,与原先的整体项目排期完全不一样;对产品经理来说,敏捷能让自身更好的掌握整个产品的进度。
      但需求分析与产品设计阶段的敏捷拆分还是较为头疼的,究竟要不要写文档了,是不是有什么做什么,还是说要规划完整体设计之后才进行拆分?疑问很多,搜集了部分资料,结合敏捷实践的经验,分享如下:
      一、敏捷开发最少需要维护哪些文档?
      软件或者系统产品终归是人来维护的,业务知识和技能的传递就成为产品可持续发展的一个重要因素,这就需要有知识性的沉淀,需要有文档的产出。
      实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;敏捷开发照样重视文档的作用,也重视文档的维护。
      但文档宜少且精炼,一般情况下建议维护三份文档:
      《产品需求规格说明书》
      也即PRD:定义产品应该具有的功能、边界描述等,它作为产品团队之间共同的讨论基础,并在设计和开发过程中不断的更新维护,并记录所有的需求变更;
      《系统设计说明书》
      开发人员编写的技术设计,包含数据库E-R图,架构设计等:说明产品如何实现,内部之间是什么关系;
      《测试用例和测试报告》
      由测试人员编写:记录所有功能点的测试计划、过程和测试结果;
      二、敏捷开发是否需要系统设计?
      前面也提到过,敏捷开发对开发人员来讲实质差异不大,只是以小周期代替大周期。
      小周期包括:需求、设计、开发、测试、发布,这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的。
      因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化。
      传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。
      三、敏捷开发是否需要项目计划?
      敏捷开发只是把整体拆分成许多个体,产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。
      它是一种有组织有目标的行为,往往我们都将其作为一个项目来管理,这就是讨论为什么有产品经理的同时还要有项目经理,为什么要求产品经理要有项目管理的能力,因此它需要项目计划。
      但这个计划是一个短程计划,根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的需求变更;
      四、敏捷开发的迭代周期大概多长?
      敏捷开发的迭代周期没有硬性的规定,结合项目里程碑、目标、功能实现情况、产品稳定性综合决定,如果产品用户活跃、功能实现难度小、维护复杂度低,建议以周为周期。
    产品项目里的九个敏捷开发实战经验
      对于规模比较大、维护复杂度高的产品,考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;
      五、敏捷开发为何提倡小版本?小版本有哪些优势?
      小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:
      1、总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;
      2、需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;
      3、测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;
      六、敏捷开发与重构的关系如何?
      敏捷开发以重构为基础,时时刻刻处于重构过程中;
      七、敏捷开发为何强调团队人员的参与、用户的参与?
      敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果。
      由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息有效传达。
    产品项目里的九个敏捷开发实战经验
      用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中,我们常常可以听到这样的话:
      “是的,就是这样的”
      “这正是我想要的……”
      “这里需要修改一下……”
      “我的想法是这样的……”
      这个过程中,用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?一句话总结就是:用户参与帮助我们做正确的事情!
      八、怎么才能评估团队是否已经敏捷了?
      由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,常见评估项目团队是否已经敏捷的方法如下:
      • 团队有共同的愿景,并且对这个愿景充满信心;
      • 团队有明确的阶段目标并且为每个成员所知晓;
      • 团队知晓当前计划:做什么、何时完成、预期效果等;
      • 团队任务是低耦合的,并且紧密协作;
      发布过程是轻松愉快的,构建版本并不断测试是常态行为之一。
      九、敏捷开发能缩短项目时间并提高质量吗?
      从我的实践经验来看是可以的,但目前无法提供量化的数据做参考,只能从几个方面评估和推断:
      • 用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;
      • 不断的重构和测试发布能把问题发现在早期,整体质量显著提高;
      • 过程目标导向,使团队高度集中于项目目标,提高了生产力;
      • 不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;
      以上是一些敏捷开发过程当中的疑问,其实还有很多,目前我这边还只是主推让开发和测试团队敏捷,PD团队还在摸索当中。下次我会分享一下如何在需求这个层面用敏捷的方式来设计,去产出PRD文档。敏捷设计、敏捷开发、敏捷测试连在一起,这样才能最大限度的发挥敏捷的效用
    展开全文
  • CMMI与敏捷开发

    2019-03-29 10:50:09
    最近看了很多关于敏捷开发和CMMI比较的讨论,结合我实施CMMI的经验和对敏捷开发的研究,提出点薄见,还希望大家多多讨论! 首先我现在很多公司盲目跟随潮流使用敏捷开发过程,或CMMI标准过程,未完全确定自己公司的...
  • 敏捷开发中QA如何做质量管理? 经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型中遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的,曾经在中兴通讯做过...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • ThoughtWorks的敏捷开发

    2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...
  • 敏捷软件开发最近几年越来越火。跟传统软件开发相比有什么优点呢。今天我们就来聊一聊。 首先我们来看下什么叫做敏捷敏捷软件开发过程 软件开发过程是指设计软件开发过程中涉及的一系列活动,指导开发组一步...
  • 敏捷开发实践总结

    2017-12-03 20:21:15
    敏捷开发实践总结 前言 敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和...
  • 前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • 本文以作者黄文海的实际敏捷开发与管理的经验为基础,分享了具体实施 Story 演示的注意要点以及如何控制 Story 演示的成本。本文分享的不仅是一个具体的敏捷开发实践,更是一种敏捷开发的思想和思维方法。 此文发表...
  • 敏捷开发中的PO即Product Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品...
  • 敏捷开发之道

    2012-07-22 19:15:41
    敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目...
  • 敏捷开发知识体系

    2017-03-28 08:27:22
    敏捷开发知识体系整体框架 敏捷开发工程实践 项目管理 迭代开发风险价值生命周期多级项目规划完整团队每日站立会议任务板燃尽图 需求管理 需求订单业务流程草图用例驱动开发用户故事 架构 演进...
  • 敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也...
  • 瀑布模型开发与敏捷开发的对比     瀑布模型开发: 严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义...
  • JSAAS敏捷开发平台

    2017-11-29 15:55:42
    红迅JSAAS敏捷开发平台是广州红迅软件有限公司面向合作伙伴以及有IT运维团队中大型企业提供新一代的企业级的数据IT一体化的业务管理平台工具,它基于流行的JAVA开源技术上构建,扩展容易,学习成本低,可快速构建...
  • 通过前面几篇关于敏捷开发总体的相关介绍,相信大家对敏捷开发模式已经有了一个比较清晰的了解,后续会介绍一些比较细分的方面,结合我在敏捷开发实施过程当中的一些体会,来阐述自身对敏捷开发的认识。 敏捷开发中...
1 2 3 4 5 ... 20
收藏数 21,507
精华内容 8,602
关键字:

敏捷开发怎么控制成本