敏捷开发 最佳实践_jira 敏捷开发 最佳实践 - CSDN
  • 极限编程(eXtreme Programming,简称XP)是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法,其特性包含在12个最佳实践中。 1. 计划游戏 ( Planning Game )  (1)快速制定计划、随着细节的...

    极限编程(eXtreme Programming,简称XP)是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法,其特性包含在12个最佳实践中。


    1.  计划游戏 ( Planning Game )

        (1)快速制定计划、随着细节的不断变化而完善;

        (2)详解:要求结合项目进展和技术情况,确定下一阶段要开发与发布的系统范围。当计划赶不上实际变化时就应更新计划。

    2.  小型发布 ( Small Release )

        (1)系统的设计要能够尽可能早地交付;

        (2)详解:强调在非常短的周期内以递增的方式发布新版本,从而可以很容易地估计每个迭代周期的进度,便于控制工作量和风险;同时,也可以及时处理用户的反馈。

    3.  系统隐喻( System Metaphor )

        (1)找到合适的比喻传达信息;

        (2)详解:通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。

    4.  简单设计( Simple Design )

        (1)只处理当前的需求使设计保持简单;

        (2)详解:任何时候都应当将系统设计的尽可能简单。不必要的复杂性一旦被发现就马上去掉。

    5.  测试驱动( Test-driven )

        (1)先写测试代码再编写程序;

        (2)详解:程序员不断地编写单元测试,在这些测试能够准确无误地运行的情况下开发才可以继续。

    6.  重构( Refactoring )

         (1)重新审视需求和设计,重新明确地描述它们,以符合新的和现有的需求;

         (2)详解:代码重构是指在不改变系统行为的前提下,重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。

    7.  结对编程( Pair Programming )

         (1)由两个程序员在同一台电脑上共同编写解决同一问题的代码。

         (2)详解:通常一个人负责写编码,而另一个负责保证代码的正确性与可读性。 

    8.  集体所有权(Collective Ownership)

        (1)任何人在任何时候都可以在系统中的任何位置更改任何代码。

        (2)详解:每个成员都有更改代码的权利,所有的人对于全部代码负责。

    9.  持续集成( Continuous Integration )

        (1)可以按日甚至按小时为客户提供可运行的版本;

        (2)提倡在一天中集成系统多次,而且随着需求的改变,要不断的进行回归测试,避免了一次系统集成的恶梦。

    10.  每周工作40小时 ( 40-hour Week )

        (1)要求项目团队人员每周工作时间不能超过40小时,加班不得连续超过两周,否则反而会影响生产率。

    11.  现场客户( On-site Customer )

         (1)在团队中加入一位真正的、起作用的用户,他将全职负责回答问题。

         (2)详解:要求至少有一名实际的客户代表在整个项目开发周期在现场负责确定需求、回答团队问题以及编写功能验收测试。

    12.  编码标准( Code Standards )

          (1)强调通过指定严格的代码规范来进行沟通,尽可能减少不必要的文档。

    展开全文
  • 不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。本文将结合一个软件项目实例,基于项目开发的...

    敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式。不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。本文将结合一个软件项目实例,基于项目开发的不同阶段,详细介绍每个阶段的主要测试活动。文中将分析每个主要测试活动的前提条件和目标任务,并根据实例推荐最佳的解决方案。


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

    敏捷软件开发(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)

    基于这四点原则,敏捷软件开发有着自己独特的流程(参见图 1)。

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

    整个过程中夹杂了很多在敏捷开发前己经出现的软件开发方法,包括极限编程(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 服务器上,在一些问题区域上标注鲜明的色彩,用来警示团队中的每个人。

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


    展开全文
  • 讲到结对编程,我想大家首先想到的是XP极限编程中描述的,两位程序员并排...这种编程方式为众多敏捷爱好者所向往,但实际工作中尝试采用的却寥寥无几,究其原因:喜的是它可以提高代码质量,增进沟通,并起到传帮带的作
             讲到结对编程,我想大家首先想到的是XP极限编程中描述的,两位程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起完成编码工作这种编程方式为众多敏捷爱好者所向往,但实际工作中尝试采用的却寥寥无几,究其原因:喜的是它可以提高代码质量,增进沟通,并起到传帮带的作用;忧的是它需要投入更多的资源,灵活性不强。结对编程和传统编程模式有着很大不同,对程序员的能力也有着更高的要求,要求结对双方高度集中注意力,保持步调、思维一致。

    如何做才能既享受结对编程带来的好处,而又能有效的避免相应的影响呢?本文阐述了实际项目过程中的一些结对编程的实践活动,希望可以给读者一定的启示。

     

    1、结对认领任务

             项目启动后,开发人员两两结对,共同认领开发任务,作为owner,他们相互协作,一起对所承担的开发任务负责。在需求理解、设计阶段双方一起设计和讨论,编码阶段独立实现。对过程中发现的问题,随时进行沟通和讨论,通过这种小范围、高效的沟通,解决项目中的绝大部份问题。从而,实现更高的开发效率和代码质量。

             结对成员一般由一位能力强、经验相对丰富和一位相对欠缺的工程师配对,能在一定程度上形成互助、互补;结对小组认领的任务模块在不同迭代中进行交替轮换,让项目组成员对项目的所有模块功能、代码都比较的熟悉,提升开发团队的战斗力。

    通过结对认领任务的活动,结对成员在需求理解、设计思路上充分的沟通和讨论,尽早的发现和解决问题,避免因需求理解偏差、设计问题造成返工。对于新员工或经验稍微不足的开发人员,通过经常性的沟通和讨论,能迅速的进入角色并积累经验,发挥了传帮带的作用。此外,结对成员之间互为backup,当有一方因故资源不能保证时,另一方就能非常顺利地接手遗留下来的任务,减少项目风险。

     

    2、交叉单元测试

             我们知道单元测试是众多敏捷实践的基石,无论是重构还是持续集成都离不开单元测试。因此,如何做好单元测试就显得尤为重要。在实际项目过程中,我们会更多关注功能实现的进度和质量,而忽略了对单元测试完成情况及质量跟进。

             交叉单元测试活动指的是结对双方对共同认领的开发任务进行更进一步的分工,一方负责某些任务业务功能的实现,另一方就负责完成对应功能的单元测试。每个人在项目中既会承担功能实现部分,也会承担单元测试部分,通过任务墙上的小卡片分别对这两部分任务进行进度跟踪。

    相比传统的一个人同时负责功能实现和单元测试,交叉单元测试可以加强大家对单元测试的重视程度,提高单元测试的覆盖率,同时在编写单元测试过程中,必然会去了解对方的实现代码,这样也能尽早发现业务逻辑、代码设计上存在的问题。

    图1:交叉单元测试

     

    3、交叉代码审查

            通过代码审查(code review),可以帮助我们提高代码质量和编码规范。交叉代码审查活动,是代码审查的一种组织形式,结对双方在完成或部分完成编码和单元测试后,相互交叉审查对方在本次迭代中所实现的所有代码,以发现代码中的编码规范及业务逻辑问题或潜在隐患,并且确保提出的问题得到妥善解决。

    其他常见代码审查形式有很多种:比如集体review,组织项目成员一起到会议室,一人通过投影仪展示并讲解自己写的代码,其他成员一起寻找代码中可能存在的问题,并由专人记录所发现的问题,会后发出代码审查报告并安排修复解决。我们早期也曾多次采用这种方式来做代码审查,但总体效果不太理想,所发现的问题多数是编码规范上的,而很难发现深层次的业务逻辑问题。究其原因,大家认为review过程中思路跟不上讲解代码的人,且容易走神,所耗时间长而效果不佳;再有一种,项目组成员分头review,审查本迭代中除自己提交以外的代码,这种review形式工作量较大且没有重点,容易遗漏。

    相比上述的代码审查形式,交叉代码审查由于结对双方在需求理解、设计编码阶段就有充分的沟通和讨论,对所需审查代码的业务逻辑较为熟悉,并且审查的代码和文件相对明确且数量适当。因而,交叉审查可以使review更加充分和细致,更重要是可以根据自己的时间安排随时开展,表现出更灵活、高效的特点。

             在做代码审查时,可以结合一些工具,比如Jupiter,ReviewClipse等eclipse插件,简单方便的提交、跟踪和解决审查的问题,提高代码审查效率。目前,我们结合团队的需要,采用自己开发的review工具Tala(现已release了第一个版本,正在技术团队中试用,后续也会考虑开源)。我们用此工具记录review中发现的问题,不仅可以方便跟踪,还可以按项目、问题类型等维度进行统计,通过定期的问题回顾,避免一些典型问题重复出现。工具主要视图如下:

     

    图2:需要review的文件列表视图

     

    图3:code review问题列表视图

     

    图4:记录code review问题视图

     

             上述活动为我们正在尝试的结对编程实践中的三个重要活动,我们认为通过这些活动,可以有效的避免了XP中结对编程投入成本高、约束性大(需双方同时集中精力)等问题,同时,又获得了结对编程带来的好处,主要有如下几点:

             1)、提升代码质量;

             2)、通过充分的沟通和交流,成员间起到传帮带的作用;

             3)、互为backup,减少产品(项目)风险;

             读到这里,可能很多读者会有一个疑惑,那什么样的开发人员适合结对呢?并非所有的人都适合做结对,至少参与结对的开发人员应具备独立思考和解决问题的能力,并且具备较好的团队协作意识。否则,不仅不能带来结对的好处,反而引起一些新的问题。

             敏捷的实践不尽相同,没有什么实践活动可适用于所有团队,我们需要根据实际情况和客观条件,选择适合的实践活动,并在实践中不断的改善和调整,形成自己团队的最佳实践。本文所阐述的结对编程最佳实践亦是如此,我们认可的最佳实践也许未必适合你的团队,但我们希望通过本文可以给大家带来一些新的思考和尝试,相信通过你的努力,同样可以找到你的最佳实践。最后,欢迎广大敏捷爱好者联系我们,共同探讨敏捷项目管理实践。

     

            ps:最后非常感谢建法对此文的审阅和修订。

    展开全文
  • 敏捷开发——SCRUM

    2018-10-22 21:38:02
    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。
  • 资料下载:http://download.csdn.net/detail/u011774517/9747734下面谈谈我对翻译的内容“8个敏捷开发最佳实践”的理解,我会逐条写下自己的理解敏捷应用开发的最佳实践 1、专注于客户--注重客户或者说是重视...

    总结的国外的敏捷开发资料且翻译成中文:The CIO’s Guide to Becoming a Trailblazer
    资料下载:http://download.csdn.net/detail/u011774517/9747734

    下面谈谈我对翻译的内容“8个敏捷开发的最佳实践”的理解,我会逐条写下自己的理解

    敏捷应用开发的最佳实践
    1、专注于客户--注重客户或者说是重视应用的最终用户体验
    开发团队需要深入了解客户需求并进行相应调整。领导者可以通过授权开发团队去掌握并衡量端到端客户体验,公司才可能创新。

    2、为开发人员提供思考的安全边界--培养团队的创新能力,应该给每个成员一个安全的环境提出自己的想法,成员无需担心报复和尴尬;并且避免群体思考。
    CIO可以采取的措施:给职员一定的安全空间,使职员之间不会产生摩擦;CIO应在数据整合上投资,让员工可以自由访问正确的数据,然后让职员根据自己的需求策划。

    3、基于IT资源的适当的创新
    根据已有的IT开发人员、以及使用各种语言的开发团队等IT资源来适当的创新

    4、利用阴影IT
    Shadow IT(shadow information technology)是企业中的硬件或软件,但是它不受组织的中央IT部门支持。尽管标签本身是中性的,但该术语通常带有负面含义,因为它意味着IT部门尚未批准该技术或甚至不知道员工正在使用它。(维基:影子IT通常用于描述在没有明确组织批准的情况下在组织内部构建和使用的信息技术系统和解决方案)
    利用阴影IT为这些非IT用户提供可视化应用开发工具,使他们能够以“低代码”和“无代码”视觉编程环境来开发apps。 在这种方法中,用户可以构建而IT人员维护监督,以确保安全性和法规遵从性,并且还保留其他内部数据。 这样,更多的员工可以开发有用的产品性质的应用程序,并且熟练的开发人员可以迅速创建应用程序

    有篇介绍影子IT(影子信息技术)的文章不错:http://searchcloudcomputing.techtarget.com/definition/shadow-IT-shadow-information-technology

    5、DevOps的好处
    DevOps: Development和Operations的组合DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。可以把DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集。
    使用敏捷开发时要引入DevOps , 培养DevOps精神,需将共享角色和责任的精神逐步灌输给企业中的每个人。 为了保持速度和敏捷性,业务团队和IT团队需要尽可能快地移动,这意味着业务团队和IT团队要作为一个单元移动。
    Elasticbox 整理了 60+ 开源工具与分类,其中包括版本控制&协作开发工具、自动化构建和测试工具、持续集成&交付工具、部署工具、维护工具、监控,警告&分析工具等等, 
补充了一些国内的服务,可以让你更好的执行实施 DevOps 工作流。
    * 版本控制&协作开发:GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar

    * 自动化构建和测试:Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit

    * 持续集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go

    * 容器平台: Docker、Rocket、Ubuntu(LXC)、第三方厂商如(AWS/阿里云)

    * 配置管理:Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible

    * 微服务平台:OpenShift、Cloud Foundry、Kubernetes、Mesosphere

    * 服务开通:Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat

    * 日志管理:Logstash、CollectD、StatsD

    * 监控,警告&分析:Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana

    DevOps BookMarks里面涉及了DevOps方方面面的工具和内容,有兴趣的同学可以前去学习。

    6、使用微服务方法开发
    微服务架构模式(Microservices Architecture Pattern)的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务,每个服务都可以很容易得局部改良。
    
然而,在微服务架构带来可独立部署、高扩展与伸缩、自由选择开发语言、高效利用资源、故障隔离等优点,同时也因为服务多带来分布式事务、服务之间通信、监控、部署等新的问题。

    提到微服务架构与单体架构进行比较,单体架构存在如下缺点:代码维护难度大,臃肿的部署,局限的弹性与扩展能力,阻碍团队与技术革新等等;微服务架构存在如下优点:代码维护简化,可独立部署,高扩展与伸缩,自由选择开发语言等优点。
    翻译的敏捷开发的最佳实践中提到“微服务驱动方法通过将功能分离为可被其他团队重用或使用的组件和服务,来实现松散耦合的应用程序体系结构。这样,当新入职的员工或有人需要构建一个包含新功能的应用程序时,他或她可以将这些预先构建的服务集成进新的功能中”。

    7、持续交付
    持续交付包含几个方面:集成、持续、部署、交付。
    持续交付(Continuous Delivery)是一系列的开发实践方法,用来确保让代码能够快速、安全的部署到产品环境中,它通过将每一次改动都提交到一个模拟产品环境中,使用严格 的自动化测试,确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中,所以当业务开发完成时,你有信心只需要按一 次按钮就能将应用安全的部署到产品环境中。

    张程荣在演讲中主要为大家介绍了阿里云持续交付的经验。
    https://yq.aliyun.com/product/713?utm_medium=text&utm_source=baidu&utm_campaign=YQDZ&utm_content=se_302289
    8、捕获部落知识
    部落知识是在一个组织内已知的信息或知识,但在其外部常常是未知的。从企业的角度来看,“部落知识或技能是组织的集体智慧,是所有人的所有知识和能力的总和,部落知识可能对产品的生产或服务的表现至关重要。
    企业要建立好自己企业的部落知识,不仅使每个开发人员可以获取正确的数据或资源,还可以更容易更快的分享我们的工作。

    展开全文
  • 首先强调一些Scrum的基本概念本文只想为那些不断实验敏捷开发方法、追寻快速交付产品的IT管理者提供全套经过验证的实践经验,供之参考。我首先假设你已经理解了Scrum这种敏捷开发方法的基本概念并认同之,但是仍然,...
  • Ruby on Rails敏捷开发最佳实践书的全部源代码
  • 《Ruby_on_Rails敏捷开发最佳实践》英文版,文字影印版
  • 虽然最早来源无从考察,但将最佳实践(Best Practices)一词发扬光大的无疑是CMM/CMMI。以本人接触的先后顺序,CMM是在2001年同方听到的,而极限编程(那时候基本上还没有Scrum)也是同时听到的,所以算是同一时期的...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 英文原文:http://www.agilemodeling.com/essays/modelStorming.htm Model Storming是一种实时的建模方式: 你找到了一个需要...这对于敏捷项目来说是很普遍的事情。使用极限编程的人称这个为站立的设计会议(stand-
  • 英文原文:http://www.agilemodeling.com/essays/modelStorming.htm Model Storming是一种实时的建模方式: 你找到了一个需要解决...这对于敏捷项目来说是很普遍的事情。使用极限编程的人称这个为站立的设计会议(stand
  • 寻找jira的最佳实践

    2019-02-27 12:03:27
    task是给研发组长用的,可以给每个story去建议一个或多个task,包括开发、联调、测试的task,研发人员再用sub-task来分解具体的task; test和bug是给测试用的,测试人员从story开始建立test用于测试计划,再...
  • 【编者按】软件开发和采购人员经常会对现有软件开发方法、技巧和工具产生一些疑问。针对这些疑问,Kevin Fall 整理了五个软件方面的话题:Agile at Scale,Safety-Critical Systems,Monitoring Software-Intensive ...
  • 站立会议是敏捷软件开发方法论Scrum的相关技术之一,亦可称之为Scrum的最佳实践。具体形式为每天的同一时间,一个敏捷开发团队的所有成员面对面站在一起,进行一个为期15~20分钟的短会。在会议上,每个人要依次回答...
  • 敏捷开发来自欧美,欧美从事敏捷开发的企业尤其是较大的企业中,其开发人员一般都有十年甚至二十年的开发经验,所以敏捷对他们来说可以不需要写文档,因为关于产品和开发的知识都已经烙印在他们脑子里,某些文档对...
  • 在本课程结束时,您将准备好提高敏捷开发过程的效率,避免常见的看板陷阱,并为您的团队带来最佳工作。 以下是本 Chat 的内容目录: 介绍 精益和看板 精益思维 看板原则 核心练习 看板实践 ...
  • 敏捷团队的最佳实践

    2019-11-07 22:23:34
    不能完全照搬敏捷的框架与方法,也并不是所有敏捷实践都要采用,要根据企业和项目的具体特点裁剪出适用于自己的框架与方法 二、敏捷迭代周期的选择 一般初期转型时建议一个迭代周期为4周,团队稳定后可根据...
  • 《可伸缩敏捷开发:企业级最佳实践》/(美)兰芬维奥(Leffingwell,D.)著;李冬冬,冯雁,娄嘉鹏译.—北京:电子工业出版社,2009.5(软件工程研究院)书名原文:Scaling Software Agility: Best Practices for ...
1 2 3 4 5 ... 20
收藏数 19,991
精华内容 7,996
关键字:

敏捷开发 最佳实践