敏捷开发模式的概述_传统开发模式和敏捷开发模式的区别 - CSDN
  • 名词一:backlog 一、什么是迭代backlog 1、迭代Backlog是团队在一轮迭代中需要完成的 任务清单,是迭代计划会议确定的内容; ...2、迭代Backlog是团队在召开迭代计划会议的时 候从产品Backlog挑选出高优先级的...

    名词一:backlog

    一、什么是迭代backlog

    1、迭代Backlog是团队在一轮迭代中需要完成的 任务清单,是迭代计划会议确定的内容;

    2、迭代Backlog是团队在召开迭代计划会议的时 候从产品Backlog挑选出高优先级的需求清单;

    3、每项任务信息包含当前剩余工作量和负责人


    二、迭代Backlog关键要点

    1、任务清单是由完整团队成员 自己定义和分解的,而不是上级指派;

    2、与需求相关的所有工作都可以作 为一个任务,每个任务要落实到具体的责任人;

    3、任务的颗粒度要足够小, 工作量大于2天的任务要进一步分解;

    4、用小时作为任务剩余工作量 的估计单位,并且每日估计和刷新


    名词二:完成标准(DoD  )

    1、基于"随时可向用户发布"的目标 制定衡量团队工作是否已完成的标准



    名词三:迭代计划会议

    一、什么是迭代计划会议

    1、每轮迭代启动前,团队共同讨论本轮迭代详细开发计划的过程, 输入时产品backlog,输出是团队迭代Backlog

    二、迭代计划会议内容

    1、澄清需求、对“完成标准”达成一致

    2、工作量估计、根据团队能力确定本轮迭代交付内容

    3、细化、分配迭代任务和初始工作计划


    三、迭代会议好处

    1、通过充分讨论,使团队成员对任务和完成标准理解一致

    2、团队共同参与,促进团队成员更认真对待自己的承诺


    四、迭代会议关键要点

    1、充分参与:Scrum Master确保PO和Team 充分参与讨论,达成理解一致

    2、互相承诺:Team承诺完成迭代 Backlog中的需求并达到‘’完成标准“, PO承诺在短迭代周期不增加需求(2-4周)

    3、确定内部任务:Team和PO协商把一些 内部任务放入迭代中(例如重构、持续集成、 集成环境搭建),由PO考虑并与其它外部需求一期排序


    名词四、每日站立会议

    一、什么是每日站立会议

    1、由Scrum Master组织,Team成员全体站立参与

    2、聚焦在下面四个主题

     2.1、我昨天为本项目做了什么?

     2.2、我今天计划为本项目做了什么

     2.3、我需要什么帮助以更高效的工作

     2.4、SM关系运到哪些难的问题或阻碍

    二、每日站立会议的关键要点

    1、准时开始:按计划会议制定的时间地点开会  形成团队成员带 自然习惯

    2、搞笑会议:会议限时15分钟, 每个人都保持站立,依次发言, 不讨论与会议四个主题无关的 事情(如技术解决方案)

    3、问题跟踪:SM应该记录下问题并跟踪解决


    名词五:迭代回顾会议

    一、目的

    1、分享好的经验和发现改进点, 促进团队不断进步

    二、围绕三个问题

    1、本次迭代有哪些做得好

    2、本次迭代我们在哪些方面还能做得更好

    3、我们在下个迭代准备在哪些方面改进

    三、迭代回顾会议的关键要点

    1、会议气氛:Team全员参加,气氛宽松自由, 畅所欲言,头脑风暴发现问题,共同分析原因

    2、关注重点:Team共同讨论优先级, 将精力放在最需要的地方(关注几个改进就够了,如TOP3)

    3、会议结论要跟踪闭环:可以放入迭代backlog中


    名词六:持续集成

    一、概念

    1、持续集成(CI)是一项软件开发实践, 其中团队的成员经常集成他们的工作, 通常每日每人至少集成一次,每次集成通过自动化构建完成
    二、好处
    1、大幅度缩短反馈周期,实时反映产品真实质量状态

    2、缺陷在引入当天就被发现并解决,降低缺陷修改成本

    3、将集成工作分散在平时, 通过每天生成可部署的软件, 避免产品最终集成时爆发大量问题

    展开全文
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...

     敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式。

       不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。
       其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。

    第一部分:敏捷软件开发简介

    敏捷软件开发(Agile Software Development)初起于九十年代中期。最早是为了与传统的瀑布软件开发模式(waterfall model)相比较,所以当时的方法叫做轻量级方法(Lightweight methods)。二十世纪初,17 位该方法的倡导者建立了敏捷联盟(Agile Alliance),并将该软件开发方法命名为敏捷软件开发过程。

    敏捷联盟在成立之初总结了四条基本的价值原则:

    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)

    基于这四点原则,敏捷软件开发有着自己独特的流程

    图  敏捷软件开发流程
    图 . 敏捷软件开发流程

     

    整个过程中夹杂了很多在敏捷开发前己经出现的软件开发方法,包括极限编程(Extreme Programming,1996)、Scrum(1986)、特征驱动开发(Feature Driven Development),测试驱动开发(Test Driven Development)等。这些方法在敏捷软件开发流程的各个阶段都有充分的体现和应用。

    例如,Scrum 主要着重于项目管理,团队中的项目经理(Scrum master)需要在每个客户需求到来的时候制定 Sprint 的周期,定义每个 Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的 Sprint。

    相反,特征驱动开发和测试驱动开发主要被应用于 Sprint 周期中。如果项目进行于开发新功能时期,这个阶段主要推行特征驱动开发。所有测试和开发人员都将自己的工作重心放在新的功能上面,从开发和测试两个方面来完成各自的任务。如果项目进行于测试新功能时期,这个阶段需要将工作的重点挪到测试上来。所有的测试和开发人员都密切关注着目前版本的缺陷状况。测试人员需要在每天的站立会议(Daily Standup Meeting)上报告前一个工作日发现的新缺陷情况,项目经理根据项目进度和缺陷严重性来决定是否修复这些问题。需要及时修复的缺陷是目前 Sprint 中的一个新任务,将由项目经理添加到 Sprint Backlog 上并通知开发人员去修复漏洞。

    对于敏捷开发和测试中的审查过程,极限编程中的同行评审(peer review)思想得到了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对,互相评审;有时候,一个开发和一个测试人员也可以组成一对,互相协作。这样能够有助于缺陷和问题在第一时间被抹杀在萌芽中。

    敏捷开发还有以下几个关键概念 (Key Issues):

    1. 迭代过程(Iterative process)
    2. 用户故事(User stories)
    3. 任务(Tasks)
    4. 站立会议(Stand-up meeting)
    5. 持续集成(Continuous integration)
    6. 最简方案(Simplest solutions)
    7. 重构(Re-factoring)

    这些概念是敏捷开发中经常使用到的观点和方法。下面我们将详细论述测试人员在敏捷软件开发中扮演的角色和职能。

     

     

    第二部分:敏捷开发中的测试人员

    本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

    2.1 敏捷开发团队介绍

    我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

    图 2. 敏捷开发团队成员

    图 2. 敏捷开发团队成员

    由于敏捷开发要求参与人能够快速而高效得应对变化,所以无形中对测试人员提出很高的要求。

    2.2 测试人员需要具备的素质

    测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

    每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

    1. 具有质量检测和编写代码的能力–> 测试开发
    2. 具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员
    3. 具有开发和执行测试程序的能力 -> 软件质量工程师

    总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

    在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

    2.3 测试人员的主要职责

    在敏捷软件开发中,测试人员的职责有三个主要方面:

    1. 定义质量 (Define Quality):这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。
    2. 交流缺陷(Communication):敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。
    3. 及时反馈 (Feedback): 敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

    以上总结了测试人员在敏捷开发中的需要展现的能力和担负的任务,下面请跟随一个项目实例来详细了解敏捷测试的最佳实践。

     

     

    第三部分:敏捷开发中的测试流程

    本部分结合一个软件项目,详细介绍项目流程中的主要测试活动,每个活动的前提条件和目标任务等。

    3.1 介绍项目实例

    项目介绍:根据一家在线 B2B 公司的要求,我们将为其开发一款类似于谷歌的搜索服务。作为 Web Service,该服务可以内嵌于网页中。当用户输入关键词并选择商户的类型和位置后,系统会返回具体商户的列表(参见图 3)。

    图 3. 项目实例图

    图 3. 项目实例图

    典型的敏捷开发和测试活动参见下表。它主要由三部分构成,从最初的用户故事设计和发布计划,到几次 Sprint 周期的迭代开发和测试,以及最后的产品发布阶段。每个时间段都有相应的测试活动。通常 Sprint 周期被分成两类:特征周期(Feature Sprint)和发布周期(Release Sprint)。特征周期主要涉及新功能的开发和各类测试。发布周期则会结合计划,确定新版本功能,然后对最新的功能进行测试。

    敏捷开发的主要活动 测试活动
    用户故事设计 寻找隐藏的假设
    发布计划 设计概要的验收测试用例
    迭代 Sprint 估算验收测试时间
    编码和单元测试 估算测试框架的搭建
    重构 详细设计验收测试用例
    集成 编写验收测试用例
    执行验收测试 重构验收测试
    Sprint 结束 执行验收测试
    下一个 Sprint 开始 执行回归测试
    发布 发布

    在迭代的 Sprint 周期中,开发部分可以根据传统步骤分成编码和单元测试、重构和集成。需要指出的是,重构和集成是敏捷开发的 Sprint 迭代中不可忽视的任务。如果在新的 Sprint 周期中要对上次的功能加以优化和改进,必然离不开重构和集成。

    在每个 Sprint 周期结束前,测试团队将提交针对该 Sprint 周期或者上个 Sprint 周期中已完成的功能的验收测试(在实际项目中,测试团队的进度通常会晚于开发团队)。这样一来,开发团队可以运行验收测试来验证所开发的功能目前是否符合预期。当然,这个预期也是在迭代中不断变化和完善的。

    当产品的所有功能得以实现,测试工作基本结束后,就进入了发布周期。此时,测试团队的任务相对较多。

    以上,我们概述了敏捷开发的主要活动。下面我们将对各阶段相应的测试活动作详细的介绍和分析。首先是用户故事设计和发布阶段。

    3.2 用户故事设计和发布计划阶段

    在用户故事和发布计划阶段,项目经理和产品经理会根据客户的需求,制定概要的产品发布日程计划。此时,测试人员可以和开发人员一起学习新的功能,了解客户的需求。其中,有两个主要活动:寻找隐藏的假设和设计概要的验收测试用例。

    3.2.1 寻找隐藏的假设

    正如前文所述,开发人员通常关注一些重要的系统功能而忽视细节。此外,敏捷开发倡导简单的实现方案,每个开发 Sprint 周期不可能将功能完美得实现;相反,每个 Sprint 都会增量得开发一些功能。所以,测试人员在最初就需要从各种角度来寻找系统需求,探索隐藏的假设。

    项目实例:

    1. 从在线 B2B 公司角度思考
    Q:这个搜索框对公司的业务有什么价值?

    A:搜索框可以为用户方便得提供商户的目录信息。如果越来越多用户使用这个搜索框,可以增加我们网站的访问量。
    1. 从用户角度思考
    Q:作为查询信息、寻找商业合作伙伴的网站用户,搜索框对我有什么好处?

    A:坏处:找到一家商户的地址,过去才发现已经关门歇业
    好处:查找商户很简单,只要轻点鼠标

    不快:有时候在寻找一类商户,却记不清楚具体名字
    1. 从程序员角度思考
    Q:一个搜索框的最简单实现方法是什么?

    A:一个有 text input 和 search button 组成的 form;后台通过 server 程序将符合类型和地址的商户名从数据库中取出,返回给用户;每个返回项包括商户的名称、地址和评价意见。
    1. 寻找这些观点中的问题
    Q:搜索框如何在用户忘记具体名字的时候提醒用户?

    A:在第一版本中实现比较困难。可以让用户输入至少一个类型来提高模糊查找的效果。
    1. 最后寻找到隐藏的假设

    以上的思考让测试人员对系统的隐含假设更加清晰:

    首先,系统应该能够在高峰时候处理 200 条搜索请求和 1000 个鼠标点击事件。

    其次,用户可以在已经查找到的内容中继续查找

    最后,系统提供一个商户类别清单;如果用户选择商户类别而忘记具体名字,系统提供模糊查询。

    在敏捷开发中,这些假设可以作为用户故事记录下来,从而指导未来系统的开发和测试。

    3.2.2 设计概要的验收测试用例

    定义完一系列用户故事后,测试人员就可以着手设计概要的验收测试用例。正如我们在前文论述,不同于单元测试,验收测试检查系统是否满足客户的预期,也就是用户故事是否能够实现。于是,测试人员可以根据每条用户故事来扩展,寻找其中的“动作”,然后为每条“动作”制定正例和反例。

    项目实例:

    动作 数据 期待的结果
    搜索 一组能成功搜索到的(类别,位置)数据 在该类别和位置条件下的一组商户信息
    搜索 一组不能成功搜索到的(类别,位置)数据 空列表

    3.3 迭代 Sprint 阶段

    当一个 Sprint 周期正式开始时,项目经理将制定该周期的具体开发和测试任务。在定期的 Sprint 计划会议(Planning Meeting)上,每位团队成员都要提供自己在未来一个 Sprint 周期中的休假和培训计划。另外,每个团队可以根据各自团队成员的能力和工作经验,适当设定一个工作负载值(Load Factor)。比如,我们团队的工作负载值为 75%,也就是说每个人平均每天工作 6 小时(以 8 小时计算)。接着,大家就可以开始分配任务。

    当开发团队开始编码和单元测试时,测试人员的工作重点包括:估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码。第两个主要活动一般在项目初期的 Sprint 周期中完成。其他的三个主要活动将在接下来的多个 Sprint 周期中视情况迭代进行。下面我们将具体介绍每个主要活动。

    3.3.1 估算验收测试时间

    在软件开发初期,需要估算时间以制定计划。这一点在敏捷开发中应用更加广泛。如果以前的开发模式需要测试人员估算一个软件版本发行的计划(这样的计划通常会延续几个月),那么现在则要在每个 Sprint 机会会议上估算两周到一个月的任务。此外,在每天的站立会议上,测试人员需要不断得更新自己的估算时间,以应对变化的需求。所以,每个测试人员都应该具备一定的估算任务能力。下面我们将介绍两个通用的估算测试计划的方法:

    1. 快速而粗糙的方法

    从经验而言,测试通常占项目开发的三分之一时间。如果一个项目开发估计要 30 天 1 人,那么测试时间为 10 天 1 人。

    项目实例:

    搜索框的开发估计需要 78 天 1 人完成。但是,考虑到系统有模糊搜索的功能,所以测试任务可能会占 40%左右,大概 31 天 1 人。下面列出了具体的任务:

    任务 估计时间
    设计测试用例,准备测试数据(搜索数据集) 8
    加载数据集 2
    编写自动测试代码 18
    执行测试和汇报结果 3
    总结 31
    1. 细致而周全的方法

    这个方法从测试任务的基本步骤出发,进行详细分类。其中包括 :

    1. 测试的准备(设计测试用例、准备测试数据、编写自动测试代码并完善代码)
    2. 测试的运行(建立环境、执行测试、分析和汇报结果)
    3. 特殊的考虑

    项目实例:

    估算单个测试任务的事例参见下表:

    测试 准备 运行 特殊考虑 估算
    1 设计测试用例 0.5 建立环境 0.1    
      准备测试数据 0.5 执行测试 0.1    
      编写自动测试代码 0.5 分析结果 0.1    
      完善自动测试代码 2.5 汇报结果 0.1    
    总共   4   0.4 0 4.4

    估算多个测试任务的汇总参见下表:

    测试任务编号 准备 运行 特殊考虑 估算
    1 4 0.4 0 4.4
    2 4 0.4 0 4.4
    3 12 4.5 8.5 25
    4 4 0.4 0 4.4
    5 4 0.4 0 4.4
    6 4 0.4 0 4.4
    7 4 0.4 0 4.4
    总共   51.4

    3.3.2 估算测试框架的搭建

    测试框架是自动测试必不可少的一部分工作。由于敏捷开发流程倡导快速而高效得完成任务,这就要求一定的自动测试率。一个完善的测试框架可以大大提高测试效率,及时反馈产品的质量。

    在敏捷开发流程中,在第一个 Sprint 周期里,需要增加一项建立测试框架的任务。在随后的迭代过程中,只有当测试框架需要大幅度调整时,测试团队才需要考虑将其单独作为任务,否则可以不用作为主要任务罗列出来。

    项目实例:

    考虑该项目刚刚进入测试,需要为此建立一个测试框架。于是,在原先的估算中多增加一些任务。

    任务 估算(小时)
    选择测试工具 3
    建立测试系统 3
    编写下载、存放和恢复测试数据的脚本 2
    寻找或建立测试结果汇报工具 8
       
    设计具体的搜索测试用例 4
    准备搜索测试数据 4
    编写和测试“搜索”模块 3
    编写和测试“验证返回列表”的模块 1
    学习“在结果中搜索”的模块设计 4
    编写和测试“在结果中搜索”模块 4
       
    第一次执行测试 4
    分析第一轮测试结果 4
    第二次执行测试 4
    分析第二轮测试结果 4
       
    总共 52

    3.3.3 详细设计验收测试用例

    完成对测试任务的估算,接着就可以着手详细设计验收测试用例。我们可以对概要设计中的测试用例进行细化,根据不同的测试环境、测试数据以及测试结果,编写更详细的测试用例。另外,可以结合几个用例,完成一个复杂的测试操作。

    由于敏捷开发的流程是不断迭代的过程,所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。对测试人员而言,一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例(Basic Verification Test Case)在第一时间实现自动化;而对一些复杂的功能测试用例,可以先采用手工的方法测试,直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外,对测试中出现的缺陷可以设计回归测试用例(Regression Test Case),为其编写自动测试代码,使得此类问题在发布周期(Release Sprint)时可以顺利而高效得进行验证。

    项目实例:

    基本验证测试用例:

    动作 数据 期待的结果
    登录 用户名:(空)
    密码:(空)
    “用户名和密码无效”

    功能测试用例:

    动作 数据 期待的结果
    登录 正确的用户名和密码 进入系统:请输入搜索条件并点击“搜索”按钮
    搜索 错误的类型 提示正确的类型
    搜索 使用正确的类型 商户列表

    3.3.4 编写验收测试用例

    敏捷开发不提倡撰写太多的文档,提倡直接编写测试用例。此外,测试人员和客户应取得良好的沟通,将这些需求总结下来,转化成验收测试用例。如果资源充足,最好对验收测试用例建立版本控制机制。

    考虑到需求在每一轮 Sprint 周期中会不断得变化,测试团队要控制测试的自动化率,正确估计未来功能的增减。自动化率过高会导致后期大量测试代码需要重构,反而增加很多工作量。

    3.4 Sprint 结束和下一个 Sprint 开始

    在一个 Sprint 周期结束时,团队要举行一个回顾会议(Retrospective Meeting)。团队成员可以在会议上畅所欲言,指出在过去一个 Sprint 周期中可行的,不可行的和有待改进的地方。待改进之处将在项目经理监督下于未来的 Sprint 周期中实现。

    由于敏捷开发倡导增量开发,当新的 Sprint 开始时,测试团队需要根据新 Sprint 周期的开发进度及时重构验收测试。如果新 Sprint 周期没有具体的新功能开发,测试团队可以将精力集中在执行验收测试和寻找缺陷上。

    如果下一个 Sprint 周期是发布周期,那么测试人员需要准备执行回归测试。下面我们来详细了解每个测试活动。

    3.4.1 重构验收测试

    正如上文所提及,敏捷开发是以迭代方式进行的,功能在每次迭代中推陈出新。于是,验收测试用例经常需要修改或者添加,相应的验收测试代码也需要删减。这部分工作如果时间花销很大,最好在估算的时候一并提出。

    项目实例:

    在下一个 Sprint 周期中,我们需要实现之前没有实现的“模糊查找”功能。测试人员要在新的 Sprint 周期中更新原来的验收测试用例,在测试“搜索”模块中添加模糊查找测试。重新估算的测试任务参加下表:

    任务 估计时间
    设计测试用例,准备测试数据(模糊搜索数据集) 2
    加载数据集 1
    编写自动测试代码 3
    执行测试和汇报结果 2
    总结 8

    3.4.2 执行验收测试

    验收测试可以分为两大类,基本验证测试和功能测试。如果是基本验证测试,推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。如果是功能测试,可以在每个 Sprint 后期,新功能代码提交后,由测试人员单独执行。

    敏捷开发的开发和测试是相辅相成的。一旦基本验证测试出现问题,那就说明开发人员的实现违反了最初客户定义的需求,所以不能够提交。如果功能测试出现问题,那么测试人员要及时与开发人员沟通。如果是缺陷,需及时上报给项目经理,并在每天站立会议中提出;如果不是,那么继续下一项任务。这个过程充分体现了敏捷开发所提倡的团队交流机制。

    3.4.3 执行回归测试

    在发布周期中,测试人员所肩负的任务非常重要,因为这是产品发布前的最后质量检验。

    首先,要建立一套自动生成 build、运行自动测试代码、手工执行测试用例并汇总测试结果的框架。估算方法参加上文。

    其次,定期执行各类测试,包括功能和系统测试。

    最后,要整理之前在每个特征测试周期中出现的问题。如果已经整理并归类为回归测试用例,那么只要定时执行就可以了;否则,需一一添加。如果用例已经被自动化,可以直接运行;如果是手工测试,测试人员需要按照测试用例进行操作,最后汇总测试结果。这部分测试就是所谓的回归测试。

     

     

    总结

    以上我们回顾了敏捷测试在整个项目开发中的基本流程。详细介绍了各阶段存在的主要测试活动,结合实际项目,叙述每个测试活动的最佳实践。

    最后,我们来探讨一下测试中的两个问题:手工测试和测试报告。

    手工测试和自动测试是两个主要的测试类型。考虑到敏捷开发的高效性,自动测试会优于手工测试。手工测试有两个主要的缺点:不可靠和容易被遗忘。比如,在文中的搜索实例中,一旦我们重新建立索引,那么先前在搜索文本中出现的文字错误就无法重现。另外,当测试人员按部就班得手工完成一个一个测试用例时,他们很容易遗忘一些特殊的测试用例,很多缺陷因此而被埋没。敏捷测试主张一些基本的验收测试可以被自动化;对一些涉及系统方面的测试,手工测试比较适合。

    测试报告是反映一个测试团队工作的最好成果。为适应敏捷开发的节奏,测试报告可以以网页的形式发布在内部的 web 服务器上,在一些问题区域上标注鲜明的色彩,用来警示团队中的每个人。

    综上所述,本文详细谈论了敏捷开发中测试的各项任务。希望本文有助于正在使用敏捷模式或者打算使用敏捷模式的团队更好得理解敏捷测试。

     

     

    附录:敏捷开发管理工具

    很早以前,就有这么一个想法:开发一套高效的、用于软件开发行业进行项目管理的管理型软件。之所以有这个想法,与我本人的经历有关。早年,在做**系统的时候,部门的总监就让我去做那么一套东西,基于Visual Basic和adodb,当时确实是经验、眼界、思路都不足,确实带着尝试和研究的心态去做了,只是限于以上的局限性,做出来的东西怎么说呢?显得很小家子气,因为没有做专门的界面设计,UI设计也不大气,在部门内部只能实现基于局域网的任务分发、周报编写和文档的上传。

    1、Leangoo,这个工具是我通过网络搜索了解到的,通过网站,我注册了一个账号,新建了一个product backlog并查看了网站现有的部分实例,总体来说,综合了敏捷开发管理的思路,视图清晰,感觉不错。

    2、Teambition,这个是之前就了解到过的一个软件,有网络版也有app版本。有任务管理、FAQ管理什么的,也还不错,但敏捷性管理的任务卡片、看板、燃尽图什么的概念在软件内好像没展现。给我印象最深的是FAQ,也许是和我本人的工作性质有关系,个人觉得这个模块比较实用。这些是之前的状况,不知道现在是否有改版,好久没有去看了,也许有更新吧。

    3、Worktile , 在Worktile中,我们进入的默认页面是“消息”这个IM,这个即时通讯功能正是沟通的体现。而在企业协作场景中,任务又是沟通后的最初成果,也是即将展开的各项工作的核心,而Worktile的核心就是任务这件事。

     

     

     

    ·



     

    展开全文
  • 广义而言,精益与敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说,它们是精益和敏捷软件开发里轻度重叠的三种不同...

    广义而言,精益与敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说,它们是精益和敏捷软件开发里轻度重叠的三种不同风格。

    精益与敏捷软件开发概述

     

    Scrum、XP和看板都有很具体的技术,如Sprint规划会议(Scrum)、结对编程(XP)和限定在制品(看板)。这些技术都可视作流程工具。这三种工具的功能都有相当程度的重叠,例如,三种工具都建议使用真实的任务板将当前工作以可视化方式展现出来。

    1、敏捷软件开发(Agile Software Development)

    出现于2001年。当时,来自软件开发界的十七位思想领袖聚集在美国犹他州的一个滑雪度假胜地,探讨软件开发如何取得成功。研讨会期间,他们总结出一些强大的共同观点,形成了软件开发如何成功的共有愿景,即后来人们熟知的《敏捷宣言》 。

    精益与敏捷软件开发概述

     

    《敏捷宣言》内容如下:

    我们正在通过亲身实践以及帮助他人实践,探寻更好的软件开发方法。通过这项工作,我们建立了如下价值观:

    • 个体和互动胜过流程和工具。
    • 可以工作的软件胜过详尽的文档。
    • 客户合作胜过合同谈判。
    • 响应变化胜过遵循计划。

    也就是说,虽然右项也具有其价值,但我们认为左项具有更大的价值。

    研讨会结束后,他们就支撑这些价值观的以下十二条原则达成共识:

    1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
    2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,要通过敏捷过程掌控变化。
    3. 经常地交付可工作的软件,比如相隔几星期或一两个月就交付,倾向于采取较短的周期。
    4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    6. 不论团队内外,传递信息效果最好、效率也最高的方式是面对面的交谈。
    7. 可工作的软件是进度的首要度量标准。
    8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    10. 以简洁为本,它是极力减少不必要工作量的艺术。
    11. 最好的架构、需求和设计出自自组织团队。
    12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

    虽然敏捷一词正式出现于2001年,但多数敏捷方法都是在20世纪80年代到90年代形成的。敏捷只是一个描述了共同特征的统称。凡遵循上述价值观和原则的方法或方式都可视为敏捷方法。

    2、精益概述

    精益起源于日本丰田公司的“TPS”(丰田生产方式),即助力丰田成为全球最成功汽车制造商的生产方式。实践证明,TPS的基本原则“丰田之道”几乎适用于所有行业,包括软件开发。

    敏捷与精益可以看作是一对拥有共同价值观但起源不同的兄弟。精益起源于制造业,敏捷起源于软件开发。两组原则都能与对方完美契合,而且适用范围都非常广泛。越来越多的软件开发组织在探索如何将两组原则完美结合,从而应用于从产品创意到交付的完整开发链。

    1)全局优化

    局部的优化长期来说,会对系统整体优化不利。

    • 专注于整体价值流:从概念到现金。从客户需求到软件部署。
    • 交付完整产品:客户不要软件产品,他们要解决问题。完整的解决方案是由完整的团队构建的。
    • 着眼长期:警惕导致短期思维和优化局部业绩的治理和激励体系。

    2)消灭浪费

    浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下:

    • 构建错误的功能:“没有什么比高效完成根本不应做的工作更无用。”
    • 拒绝学习:我们有很多策略都干扰了我们学习,例如,只按计划行事、频繁移交、决策与工作分离等,而学习则是开发的精髓。
    • 辗转现象:那些干扰价值顺利流动的做法,例如,任务切换、请求清单冗长、大堆未完成的工作等等,都只能达到事倍功半的效果。

    3)品质为先

    如果在验证过程中总是能发现缺陷,那流程就有问题。

    • 最终验证不应发现缺陷:所有软件开发流程的根本目的都是尽早在开发阶段发现并修复缺陷。
    • 采用测试先行的开发模式让流程具有防误机制:测试(包括单元测试、端对端测试和集成测试)必不可少,以此建立信心,保证系统在任何层次、在开发阶段任何时间点都始终正确无误。
    • 打破依赖:系统架构应当支持随时添加功能。

    4)不断学习

    规划工作非常有用。学习则必不可少。

    • 可预测的性能来自于反馈:可预测的组织不会猜测未来并称之为计划;反之,他们会培养能力对未来做出响应。
    • 保持选择方案:视代码为实验——使其具有容变性。
    • 最后可靠时刻:在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策,也不要事后才做出决定!

    5)尽快交付

    从一开始就深入了解所有干系人看重的价值。然后基于这样深入了解的价值观,创建稳定、连贯的工作流。

    • 快速交付、高质量和低成本是完全相互兼容的:以速度竞争见长的公司拥有很高的成本优势,他们可以交付优质的产品,而且对客户需求更为敏感。
    • 排队理论同样适用于开发,而不仅仅是服务行业:专注于使用性会造成交通堵塞,反而降低了使用性。以较小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。
    • 管理工作流比管理进度表要容易得多:建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。

    6)人人参与

    聪明、有创造力的人员的时间与精力,是当代经济的稀有资源和竞争优势的基础。

    获得公正薪资的人员在自主性、成长性和使命感等方面受到激励。

    • 自主性:最有效的工作小组是半自治团队,有一个内部主管从头到尾负责完整、有意义的任务。
    • 成长性:对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。
    • 使命感:将工作与价值挂钩。只有相信自己工作的意义,团队成员才会全心投入工作,实现这种使命。

    7)不断提高

    结果不是重点——重点是培养人、发展体制,使之能够交付结果。

    • 失败是个学习机会:即使是非常小的失败都会被深入调查并纠正的,做到一丝不苟的时候,才可能获得最可靠的性能。
    • 标准存在的目的就是要被质疑和提高的:将现行的、最知名的做法纳入人人都遵循的标准,与此同时鼓励所有人质疑并改变标准。
    • 使用科学方法:教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。

    3、Scrum概述

    Scrum是由杰夫•萨瑟兰(Jeff Sutherland)和肯•施瓦伯(Ken Schwaber)于20世纪90年代早期共同创建的一种软件开发过程。Scrum核心内容如下:

    1)按优先顺序排列的产品需求清单

    将产品分割成一组小而具体的可交付物,即产品需求清单。产品负责人对产品愿景进行定义,并按商业价值以及风险和依赖关系等其他因素对需求清单进行排序。

    精益与敏捷软件开发概述

     

    2)跨职能团队

    将产品所有人员划分为多个小规模、跨职能、自组织的开发团队。每个团队都有一位产品负责人负责定义愿景和总体的业务优先顺序,以及一位Scrum大师专注于改进团队、消除障碍。

    精益与敏捷软件开发概述

     

    3)Sprint

    将整个开发时间划分成多个短小的、固定的迭代周期或Sprint(通常为两周或三周)。开发团队自行决定每个迭代周期要完成多少个产品需求清单项。每个迭代周期最后都要演示已通过测试、能够发布的版本。

    精益与敏捷软件开发概述

     

    4)持续调整版本发布计划

    产品负责人与客户一起合作,在每个迭代周期之后仔细检查发布版本,根据所得的结果,不断优化版本发布计划,并更新优先排序。

    5)持续调整流程

    开发团队通过每个迭代周期之后的回顾会议不断优化开发流程。所以,Scrum开发模式意味着:不是由一个大团队用很长的时间来开发一个大产品……而是由一个小团队用很短的时间来开发一个小功能。但定期集成,以构成整体。Scrum模式不会硬性规定任何具体的工程实践——这些都由团队自行决定。不过,在实践中,不纳入XP的核心工程实践而通过Scrum模式取得成功是非常困难的。

    4、XP概述

    极限编程(XP)是肯特•贝克(Kent Beck)于20世纪90年代中期创立的软件开发方法。该方法以简洁、沟通、反馈、勇气和尊重等价值观为基础。XP方法是与Scrum并行发展的,实际上包含了大多数相同要素。例如,XP中的现场客户(on-site customer)就大致等同于Scrum中的产品负责人(product owner)。

    精益与敏捷软件开发概述

     

    从这个意义上而言,Scrum可被视作XP的“包装纸”,专注于结构问题和外部沟通。而XP除多数理念都与Scrum相同以外,还增加了一些团队内部的工程实践,包括以下内容:

    • 持续集成:拥有一个随着团队的开发可自动编译、集成并测试代码的系统。这样就能尽早为开发团队提供有关产品质量方面的反馈。
    • 结对编程:在一台工作站上进行结对编程,从而使学习效果最大化、设计质量最大化、缺陷最小化。
    • 测试驱动开发:采用测试代码驱动系统的设计。编写自动化测试脚本,然后编写刚刚足够的代码以使其通过测试,然后从根本上重构代码,提高其可读性,移除重复代码。清理并重复这一过程。
    • 集体代码所有权:允许(实际上是鼓励)开发团队的任何人编辑代码库的任何部分。这样可营造出团队所有权的意识,确保整个系统的设计都一致、易于理解。
    • 增量式设计改进:从最简单的设计开始,然后运用重构等技术持续不断地改进设计,而不是从一开始就做好完整的设计。

    上述许多实践都互为基础。例如,如果系统的自动化测试覆盖范围不足,那增量式设计改进就很难实现、令人生畏且风险很高,而若要测试覆盖范围足够,则需要通过测试驱动开发和结对编程才可实现。不过,如果所有的测试都必须手动触发,而且只能在开发人员的本地工作站上运行,问题就会让人更头痛,所以,我们就需要一个持续集成系统在后台自动完成上述工作,等等。

    5、看板概述

    看板是敏捷软件开发的精益方法。实际上,看板有着多方面的意义。从字面上看,看板是日语单词,是“可视卡片”(或标志)的意思。在丰田,看板专指将整个精益生产系统连接在一起的可视化物理信号系统。看板的规则很简单。不过,跟象棋一样,规则简单并不意味着游戏简单。

    可视化工作流:把产品切分成小块,将每一块写在一张卡片上,然后将卡片贴到墙上。墙上的每一栏都有名称,以此显示每张卡片在工作流中所处的位置。

    精益与敏捷软件开发概述

     

    这就基本上直接实施了精益拉式生产调度系统。Scrum专注于结构和沟通,XP增加了工程实践,看板则专注于将工作流可视化,并对瓶颈进行管理。

    展开全文
  • 精益开发 我先把精益开发的概念和七条基本原则列一下,然后再逐条原则表述一下我的理解。 概述 精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于...

    精益开发

    我先把精益开发的概念和七条基本原则列一下,然后再逐条原则表述一下我的理解。

    概述

    精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于生产制造管理,对于IT系统建设,精益开发的常用工具模型是价值流模型。

    精益开发的基本原则

    • 杜绝浪费:将所有的时间花在能够增加客户价值的事情上。
    • 推迟决策:根据实际情况保持可选方案的开放性,但时间不能过长。
    • 加强学习:使用科学的学习方法。
    • 快速交付:当客户索取价值时应立即交付价值。
    • 打造精品:使用恰当的方法确保质量。
    • 授权团队:让创造增值的员工充分发挥自己的潜力。
    • 优化整体:防止以损害整体为代价而优化部分的倾向。

    对原则的理解

    杜绝浪费,浪费是可耻的,这个很好理解,但是在这条的描述中,精益提出“把所有的时间都放在能够增加用户价值的事情上”,这样太容易被曲解了,最值得考究的就是什么才算能够增加用户价值的事?及时交付对用户有价值的产品算是增加用户价值,那么我们要做的事就仅此一件了吗?显然太片面,我们需要做的远不止这一件事。健康的团队才能产出优秀的产品,“毕其功于一役”的大决战当然是一场拼尽全力的冲锋,但是“路漫漫其修远兮”,“上下求索”显然又是个长跑的过程,不健康的团队谈不到长远的发展,所以“所有时间”中必然要包括培养出一只有战斗力的团队。再有,概述中就提到的,我们需要通过什么手段消除浪费呢?通过不断地改良流程,敏捷宣言中说“个体的主观能动性以及个体之间的互动优于既定流程和工具”,这只是强调个体的主观能动性和互动更加重要,但是并没有抹消掉流程的重要性,而且敏捷非但没有忽视流程的重要,恰恰相反,在敏捷开发的原则中说“简洁是减少重复劳动的艺术”,而流程就是保持简洁有力手段,这一点在精益中被尤为强调,所以在制定更加简洁高效的流程上花时间绝不是浪费。
    推迟决策,就是提出尽可能多的可行方案,有利于针对实际情况做出选择。我们应该把重点放在后半句的“时间不能过长”上。假设我们把相当宽裕的时间留给了提出尽可能多的方案上,我们得到了相当多的可行方案,但是方案再多总要根据实际情况选择最行之有效的那一个,那么怎么评判是不是最行之有效的方案呢?简单点讲就是找到这些方案中最能满足“时间”、“范围”、“资源”三者之间平衡的方案,耗时太长显然就压缩了项目的可用时间,对“范围”和“资源”也必将产生影响。推迟决策是为了找到平衡“时间”、“范围”、“资源”的最佳方案,那么掌握不好“推迟”的时间就是在舍本逐末。
    加强学习,这和上面讲到的培养有战斗力的团队相呼应,学习是强化团队、保持团队活力的最佳方式,至于什么是“科学的方法”,我觉得应该是最适合自己团队的方法,是组建读书会、学习小组这类组织,还是搞黑客马拉松、分享讲座这种活动看你对团队的了解,哪种方法最有效,最能持续发展就选那种。
    快速交付,精益开发是敏捷开发的一种形式,既然是敏捷开发那就不能不提快速交付,在我们软件开发中的实践就是尽可能缩短迭代周期,并且在每次迭代中给用户提供稳定可运行的并且有价值的软件,这是敏捷开发的核心手段,精益中如此,其他的敏捷方式比如“极限编程(XP)”、“水晶方法”、“动态系统开发法(DSDM)”、“SCRUM”也是如此,只是各种方法都有自己具体实践,几种的方式对迭代的实践我会放到后续的文章中讨论。
    打造精品,“XX出品必属精品”,当一个公司被冠以这样的评价,如果这个评价是正面的而非带有讽刺意味,那么说明这家公司得到了用户极高的认可,“赢在用户”一语双关,既是说精品的受益者是用户,也是说只有精品才能在竞争中赢得用户。
    授权团队,团队,还是团队,好产品离不开好团队,好团队要培养也要被信任,授权团队可以最大化地激发团队中成员对产品的主人翁意识。用人不疑,疑人不用,需要的是睿智和胸襟,不能放任不管任由其自生自灭,也不能大权独揽,手里攥着大印把角都磨圆了,还怎么激发团队的主观能动性。
    整体优化,整体优化不应该被简单理解为全面优化,我认为对整体有利的优化就可以称之为整体优化,当局部优化的程度达到足以提升整体的成效时就是一次整体的优化,这条原则强调的是局部优化的投入不应该大到拖延整体的进度。当你跟上级说我要优化一下项目架构(不要以为架构层面的就是整体,说到底研发团队也只是整个项目的一部分),大概要花两三个月的时间时,可以让软件的执行效率提升20 ~ 30%,否则将来软件的执行效率会很差,一般情况下你会得到什么答复?糟糕一点儿当然是被一口回绝,好一点儿的可能会被问问“现在的架构有什么局限?”、“新架构能带来什么好处?”,多数人在多数情况下是争取不到这么长的时间去做这种拖慢产品进度的优化的,无关于这次优化是关乎局部还是整体。或许经过几个版本的迭代后你所担心的问题终于发生了,软件运行的效率大大降低,这个时候我们应该暗暗冷笑上级只顾眼前利益吗?我觉得我们应该考虑一下自己给出的方案是不是真的考虑了整体,方案够不够敏捷。其实张口就要几个月的时间本身就是没有考虑到整体,技术停下来优化各两三个月那让产品、设计、运营放三个月长假吗,或者你独立出来搞几个月,你确定几个月后你还追的上产品这几个月来的迭代?一个优化需要两三个月的时间这显然是不够敏捷的,甚至无法保证最终优化的框架是不是真能达到预期的效果,“不能达到预期效果”正是困扰瀑布流模式的问题,也是敏捷开发提出短周期提交可用软件所要解决的问题,当你坐在上级的位置上肯定也要考虑局部优化对整体利益的影响,既然我们是在敏捷开发这个大的项目开发流程下,那么局部的优化也应该遵循敏捷的原则,化整为零,逐步迭代。我想针对上面说的花两三个月的时间优化框架这个请求,如果我们提出的方案是三到五个迭代每个迭代两到三周,每个版本都可以让项目开发的效率提升5~10%,再跟上级讲讲不优化可能带来的软件运行效率问题,我想上级点头的可能性会大大增加吧。

    展开全文
  • 什么是敏捷开发

    2017-09-27 21:38:16
     不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。   第一部分:敏捷软件开发...
  • 下载地址:网盘下载内容简介······在本书中,享誉全球的软件...这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。目录······第Ⅰ部分 敏捷开发第一章 敏捷实践1.1...
  • 第Ⅰ部分 敏捷开发 第一章 敏捷实践 1.1 敏捷联盟 1.2 原则 1.3 结论 参考文献 第二章 极限编程概述 2.1 极限编程实践 2.2 结论 参考文献 第三章 计划 3.1 初始探索 3.2 发布计划 3.3 迭代计划 3.4 任务计划 3.5 ...
  • 什么叫敏捷开发

    2015-04-19 15:18:07
     软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元,这与冰冷的机器是不可比的,所以在中国的历史上,管理人是最难的工作;“学而优则仕”的...
  • 敏捷软件开发概述

    2019-07-22 20:27:59
    背景 由于软件开发过程中需求不断变动,致使开发周期不断延迟,经费预算一再上涨...事实上,外部环境变化往往引起软件开发过程中的重大变动,这在飞速发展的当今社会是难以避免的,从而敏捷型软件开发方法应运而生...
  • 敏捷开发方法概述

    2019-07-12 02:35:49
    敏捷开发方法的核心思想:适应变化和以人为中心 敏捷型与滞重型方法显著的区别: 反映在文档: 敏捷型不是很面向文档,对于一项任务,它们通常只要求尽可能少的文档。 敏捷型方法是“适配性”而非“预设性”。 ...
  • 敏捷开发的流程

    2015-08-31 20:27:22
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。   第一部分:敏捷软件开发...
  • --Pete McBreen,软件技术专家在第1章中,我们概述了有关敏捷软件开发方法方面的内容,但它没有确切地告诉我们去做些什么;其中给出了一些泛泛的陈述和目标,却没有给出实际的指导方法。本章要改变这种状况。2.1 ...
  • 敏捷开发、持续集成/交付(CI/CD)、DevOps学习笔记 版权声明:原创内容,如需转载请联系作者。 https://blog.csdn.net/CrankZ/article/details/81545439 概述 敏捷开发和DevOps都是一种理念。他们的理念相似,...
  • 极限编程是一组简单、具体的实践,这些实践结合在一起形成了一个敏捷开发过程。项目团队可以直接拿来使用,也可以增加一些实践,或者对其中一些实践进行修改后再采用。1. 客户作为团队成员2. 用户素材 对于做计划而...
  • 敏捷开发之道

    2012-07-22 19:15:41
    敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目...
  • 敏捷开发概述  简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大...
  • 极限编程与敏捷开发 徐景周 在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。 -- Jack Reeves 简介 2001年,为了解决...
  • 正式开发之前咱们先学习一下什么是 敏捷开发 和 XP 极限编程,在实际工作中我们都会采用一些 编程方法论 给我们指引方向,让我们少走弯路。 了解敏捷开发 三分钟了解敏捷开发 小灰经过千辛万苦,终于拿到了心仪的 ...
1 2 3 4 5 ... 20
收藏数 4,554
精华内容 1,821
关键字:

敏捷开发模式的概述