敏捷开发工具的重要性 - CSDN
  • 记录几种敏捷开发应用的工具

    千次阅读 2017-04-12 09:52:41
    很早以前,就有这么一个想法:开发一套高效的、用于软件开发行业进行项目管理的管理型软件。之所以有这个想法,与我本人的经历有关。早年,在做**系统的时候,部门的总监就让我去做那么一套东西,基于Visual Basic和...

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


    以上内容,和敏捷开发管理流程没有任何的关联,纯属胡乱联想而已。

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


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


    附上知乎上看到的一段话,加深理解,无论什么开发管理方法,以人为本是核心,以实现目标为宗旨:

    首先,敏捷开发是一种过程控制论,通俗的说,就是一种做事情的方法。

    1. 它适用于软件,因为软件是软的,可以改。要是硬件,改起来就没那么方便了
    2. 它适用于客户不知道自己要啥的情况,其实,这样的客户占绝大多数。因为客户不知道要啥,所以你需要不断帮客户弄明白他到底想要啥。。。换句话说,你需要和客户沟通,合作,倾听反馈,持续改进。。。
    3. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。
    4. 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步的把汽车改成飞机,还能按时交付。
    5. 它适用于在一个地方办公的小团队,一般10个人以内。这样能使敏捷中主要的沟通方式“Face to Face” 是可行的。

    其次,敏捷开发是一套工具集,里面有形形色色的工具,你可以不搞敏捷,但可以用那么一两个来提高工作效率。

    比如:
    1. 站会:三个问题,简洁有效的小团队沟通方式
    2. 看板:直观反映工作进度,反映流程遵守情况,反映流程缺陷
    3. 演示,计划,反思会:适合于小团队的协作和优化反馈方式
    4. 用户故事:站在用户的角度讲需求



    作者:付聪
    链接:https://www.zhihu.com/question/19645396/answer/16635773
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    展开全文
  • 实际上,既然是软件开发,在所难免得面临工具的选择,而且很多优秀软件实践离开强有力的工具支持都玩不转。在如今的软件开发世界中,工具(这里谈的是软件工具)层出

    敏捷软件开发绝不再是一个新名词了,但理解还是时时有偏差。敏捷宣言中的第一条“个体和互动高于流程和工具”,有人就误读为“有了沟通,一切都迎刃而解” ,因此花费大量精力整顿团队合作,却轻视了工具(技术)。其实宣言中的意思只是想强调个人和沟通更重要而已。

    实际上,既然是软件开发,在所难免得面临工具的选择,而且很多优秀软件实践离开强有力的工具支持都玩不转。在如今的软件开发世界中,工具(这里谈的是软件工具)层出不穷,数不胜数,那么到底该怎么去选择适合的工具呢?

    本文将根据我十几年的企业级软件开发经验给出一点建议,和大家一起来探讨敏捷和工具(特别是在企业实施中的工具)这个话题。

    为了避免不必要的麻烦,文中尽量用开源软件作为介绍,但这并不是说我排斥商业软件,恰恰相反,在很多时候,只有商业软件才提供了你需要的功能(当然大部分情况下开源软件会很快迎头赶上)。

    背景知识:应用程序生命周期管理

    聊到软件开发中的工具,一般都会提到这个术语“应用程序生命周期管理(Application Lifecycle Management ,ALM)” ,说句老实话,有点烂,谁都想把自己往上靠,谁都有自己的一套说法,图1为我心中贯穿企业开发项目全程的ALM全局观。

    图1中列出了ALM中的各个子系统,以及我略有研究的相对应工具的名称,让我们一起先来简单地过一遍整个过程。

    leangoo团队协作工具

    图1 开发项目中应用程序生命周期管理及其工具

    产品开发始于一定的需求,需求有好几个层次,从产品需求到项目需求,进而产生出用户故事(User Story), 然后团队会分解出任务(Task)。团队开发者利用IDE(如Eclipse)去完成相应的代码,单元测试完成后,再推送到代码库(git),这些和软件配置管理(Software Configuration Management,SCM)相关。

    构建系统会从代码库中获取最新的代码,进行编译、打包、功能测试和系统测试,可以设置在质量系统中显示一些相关信息,如果一切顺利,甚至能直接上传到在线系统更新上线。此外不管是开发中还是运行中一般还都会有一个缺陷管理系统。

    BugZilla大家应该很熟悉了,用Redmine的人少一些,国内也有越来越多的公司在使用leangoo,很好用的一个敏捷协作软件,在线的高效看板协作。Nexus是一个Java软件包的管理工具,需要和Maven结合使用,Sonar是一个Java项目的质量控制工具,它集成了如单元测试、覆盖率、静态质量检查等内容。为什么任务管理下的Redmine有红叉呢?我们稍后会解释。

    leangoo敏捷团队协作工具

    限于篇幅,本文只会谈到其中的一部分工具。作为参考,可以阅读Manning出版社的新书《Agile ALM》,它对SCM、单元测试、功能测试等话题进行了更深入的探讨。

    敏捷中有些工具是必需的

    如果你说敏捷实施大半年了,但持续集成 (Continuous Integration,CI)服务器却还没有架起来,那我实在是不晓得你都在敏捷些啥东西了。无论你究竟“信仰”哪种敏捷,产品开发各个方面的自动化(Automation)和持续集成都必不可少。要了解持续集成,可以看看Martin Fowler的文章,可谓白皮书级别的经典,有中文翻译版。

    使用CI就一定会用到CI服务器,可选的有很多,其中Jenkins是现在最流行的一个,而且架设起来也很方便。它是从Hudson继承而来(自从2011年5月Oracle决定把Hudson捐献给Eclipse组织,两者的关系和将来的发展方向也可能带来更多变数)。

    在Jenkins构建服务器中,可以定义任务(在Jenkins中叫job),以完成一些构建步骤(如签出代码、编译、各种类型的测试、打包等),它有极丰富的插件(plugin)资源作为支撑,可以来集成产品软件开发的各个要素,它把你所需要的一切都自动化起来。

    leangoo团队协作工具

    图2 Jenkins项目自己的Jenkins构建服务器

    在Jenkins构建服务器的首页,每个任务还都有一个天气图标表示其状态,非常直观,例如“太阳”就代表着一切正常(至少从构建结果来看)。它是产品项目开发的晴雨表,项目状态是否正常一目了然。不管是对Jenkins不了解还是想提高,我强烈推荐阅读John Ferguson Smart的Jenkins开源书:Jenkins: The Definitive Guide。

    对敏捷来说,并没有“CI服务器要还是不要”一说,它就是必须的,一定要好好地实施。基于持续集成再往前走,就是持续交付(Continuous Delivery)了,这也是敏捷的一个新热点,其中加入了很多新元素(如自动化验收测试、持续部署等)。

    别让工具牵着鼻子走

    工具很重要,但会不会有些误区呢?当然有,我们一起来看个我经常碰到的一个例子。

    讲到敏捷实施一直都会提到白板(Whiteboard)的使用,先得提醒大家,它也是一个“工具” (现在可以用leangoo,在线看板),白板的其中一种用法叫任务白板,主要是提供给团队使用的。

    leangoo团队协作工具

    图3 每日例会用的任务白板(图来自《硝烟中的Scrum和XP 》一书)

    图3就是常见的任务白板,团队的需求,一般是用户故事(User Story),被放在最左边一栏“NOT CHECKED OUT”,作为团队一个迭代的输入,然后分解成任务(Task)用报事贴(俗称黄贴)贴在白板上“CHECKED OUT”那一栏,并签上自己的名字,就算是领任务啦。当做完了一个任务就把它(黄贴)挪到下一栏“DONE!:o)”,代表做完了,最右边一般还会留出部分空间,用来记录进度条和注意事项来提醒团队一些重要的事情。

    如果说Jenkins构建服务器是产品开发的晴雨表,那么任务白板就是团队开发的晴雨表。

    一般一大早在每日的站立会议(Daily Standup Meeting)上,整个团队所有人都会围在白板前,分享所负责任务的进度,顺便挪动一下任务到相应的状态栏,用这种方式能够减少很多不必要的汇报型会议,而且团队成员也能很快地了解开发的整体状况。相信如果某个黄贴在白板上连着三天都没动,团队里一定会有人站出来帮忙的。(没有?!那还是先组织他们参加团队合作的培训吧。)

    有时候团队坐得比较分散,或者有人喜欢流行的在家办公方式,这时可能会开始使用一些图形化的电子白板来管理团队任务,大家对着屏幕介绍进度,效果似乎还不错,其他人(包括经理们)也非常高兴,因为他们可以随时从网上了解到团队的进度了。慢慢地,面对面的时间看起来也可以节省下来,只要窝在座位上点点鼠标,挪挪电子黄贴(如果支持漂亮的拖拉就更好了)就已经足够了。

    这是敏捷的好实践吗?

    是否嗅到了一点怪味道?它就是我想谈的工具带来的误区,电子白板会削减团队之间的沟通,降低团队的透明度,违背了敏捷重视人和团队的原则。如果你的团队成员不经常去更新电子白板上的任务时间,慢慢地你看到的都是不太准确的信息了。有人可能说我们还是面对着电子白板开每日站立会议呀,那我希望你有个很大的屏幕吧,这样效果更好。

    那为什么没说它不对呢,因为在一些场合下,它还是有作用的。关键是团队要能充分认识到它的局限性,因此我极力反对在团队组建初期用电子白板,可以等团队充分领会到敏捷中人与人沟通的重要性后再引入。

    这也是在图1中特意用红叉提醒不要用Redmine来管理任务(Redmine这个白板功能的插件很差,不如用leangoo)。

    所以要了解你的需求,不要让一些工具牵着鼻子走,要了解敏捷实施的目的,否则出了问题还以为工具不到位,拼命要更强的功能,结果陷入大误区。

    有些工具会带来意想不到的好处

    传统的敏捷著述中通常会提到CI的部分,然而工具的运用并不限于此,例如我在实际项目中用到的Gerrit,它非常契合敏捷的宗旨,也给我们带来了意想不到的好处。

    代码审阅是一个不错的敏捷开发实践,让人非常头疼的是实施。大企业中通常是制定出一大堆相关的规范和流程来指导代码审阅。我听说好多公司都会把代码打印出来,进行走读,这可真是累啊。这种方式会给人不信任的感觉,而且应该是挺浪费时间的。

    结对编程(Pair Programming)也是非常好的一种代码审阅的方式,值得好好地学一学,只是我对它并不太感冒,体会是在大企业实行结对编程的难度很大,当然如果能找到合适的推动者,那还是可以尝试尝试的。

    那看看开源社区是怎么解决这个问题的呢,使用的又是什么工具呢?Google的Android系统是现在非常热门的开源项目,它的代码审阅(包括贡献者的代码)使用的是Gerrit,非常棒的东西,在自己的企业中架设起来也非常方便,我一用就爱上它了。

    Gerrit是一个基于Web的代码评审和项目管理的工具,面向基于Git版本控制系统的项目,所以如果你没用git(干嘛不用呢),就没法用Gerrit了,接下来来看看在Gerrit中怎么实施代码评审的。

    ● 首先开发者(贡献者)的代码变更通过 git 命令被推送(push)到Gerrit管理下的Git 版本库,推送的提交转化为一个一个的代码审核任务(见图4)。

    ● 代码审核者可以通过Web界面查看审核任务、代码变更,通过Web界面做出通过代码审核(Review)或者拒绝(Reject)等决定。

    ● 测试者(一般可以设定为CI服务器执行)可以通过访问来获取(fetch)代码变更进行相应测试,如果测试通过,就可以把这个评审任务设置为校验通过(Verified)。

    ● 最后经过了审核(Review)和校验(Verified)的代码变更可以通过Gerrit界面中提交动作合并到版本库的对应分支。

    相比代码走读,它的好处在于,审阅动作发生在向主干提交代码前,可以只看变更的部分显得很贴心,网上随时随地审阅起来也很方便,这也是有别于结对编程的一个好处。

    任何人都可以审阅提交的代码,整个团队的代码都一目了然,审阅起来更方便,非常符合开放、透明的敏捷精神。使用之后能够显著提高代码质量,甚至于等到习惯了以后,代码不被审阅一下,都觉得实在是不好意思提交代码到主干上去。

    Gerrit中,通过特定分支,任何审核任务的代码变更都能访问,所以如果需要细看或是合并到本地都异常方便。

    Gerrit刚开始实施可能会有点不习惯,毕竟整个工作流有所变化,因此实施时需要通盘考虑。

    如上只是近期我特别喜欢的一个工具,其实类似的工具还有许许多多,这不过是沧海一粟而已。

    总结

    水能载舟,也能覆舟,工具和敏捷的关系亦如此,下面我给出几点建议:

    ● 积极尝试新工具,如今的软件开发世界中,工具层出不穷,要不断与时俱进,了解最新动向和如何用有效的工具去辅助敏捷的实施,在自己的软件开发环境中去尝试和了解这些工具,尝试这一点很重要,不要只看说明或戴有色眼睛去看待这些工具,应该通过实践摸索找到最适合你的选择。

    ● 人总是第一位的,要了解你的团队,了解他们的需求,有些时候甚至可以为了团队,冒险一下采用新技术、新工具,这样可以提高团队的凝聚力(敏捷要素之一)。我待过的一些部门推动Git时,就是这么来的,很多时候过多的讨论其优缺点反而是浪费时间,不如多花点时间多试试。

    ● 实施敏捷也离不开组织的支持,特别大型企业涉及到的人很多(可能水平不一),这时候推动者就必须用专业的手段建立一个持续渐进的工具引入过程,这样会使得实施更容易些。

    ● 唠叨这么多,实际上也只是讲到一些皮毛,还有很多东西需要我们继续研究下去。

    来源:程序员

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

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

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

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

    敏捷软件开发(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的核心就是任务这件事。

     

     

     

    ·



     

    展开全文
  • 但是,最近几年出现了多种工具,它们对顺利完成敏捷开发起到了很好的促进作用。Migan和Gaia近期做了一个调查,以试图得出敏捷开发团队对工具的使用情况。据两位所言,他们做这个调查的原因之一是要评估敏捷团队...

    实施敏捷不需要一定或者建议使用工具。理想的情况是,看着索引卡上的需求,通过命令行就可以完成开发。但是,最近几年出现了多种工具,它们对顺利完成敏捷开发起到了很好的促进作用。Migan和Gaia近期做了一个调查,以试图得出敏捷开发团队对工具的使用情况。

    据两位所言,他们做这个调查的原因之一是要评估敏捷团队是不是愿意使用简单的工具。

    很多公司现在依然使用传统的项目管理工具来进行敏捷开发,比如MS Project、电子表格(MS Excel)。在采访了多家公司后,我们发现这一现象的背后原因是,许多敏捷工具都提供了许多不同的定制选项,但比起电子表格、笔和纸等却更难使用,更不直观。

    很多公司现在依然使用传统的项目管理工具来进行敏捷开发,比如MS Project、电子表格(MS Excel)。在采访了多家公司后,我们发现这一现象的背后原因是,许多敏捷工具都提供了许多不同的定制选项,但比起电子表格、笔和纸等却更难使用,更不直观。
    这一调查共涵盖了100名代表,分别来自35个国家,包括英国、瑞典、埃及、美国、法国、加拿大、印度、西班牙、波兰、乌克兰、马来西亚、巴西、新西兰、罗马尼亚、意大利、澳大利亚和德国等。

    调查结果显示了一个非常有趣的现象,那就是简单工具和敏捷项目管理工具软件常常混合使用:

    在使用其他敏捷工具的同时,25%的用户使用传统的墙和纸,23%的使用电子表格;
    尽管敏捷工具软件里有故事卡片功能,62%的团队依然在使用传统的工具,如墙和纸等;
    对敏捷工具最渴望的特性是易于使用,随后是可定制化和价格;
    对某个工具最不喜欢看到的地方就是缺少和其他系统的集成,然后是不能输出定制的报表等。
    Migan和Gaia会在以后发布一个详细的调查分析,但据两位讲,初步分析显示简单和实际的工具最常被使用。

    敏捷工具使用调查给出了这么一个事实,那就是大多数公司坚持使用简单的、实用的工具,比如Leangoo,很简单,很易用,对它们而言,可用性是一个工具最有价值的地方。

    这一结果,和此前TargetProcess的Michael Dubakov和Peter Stevens所做的一个研究很类似。

    这个研究的结果揭示了像白板、卡片、大的实际图表等简单工具得分为57,而基于Web的敏捷工具得分为52,电子表格是43。基于敏捷的哲学思想,大多数团队不希望让事情变得那么复杂。

    Michael和Peter整合了他们的研究结果,向其他团队做了推荐。他们总结说,基于不同的团队构成和所需的状态报告,实际的、基于Web的,或者二者兼而有之的工具都有可能被用到。

    | 不需要状态报告 | 状态报告很重要
    | 小的集中团队 | 实际的工具 | 实际的工具和基于Web的敏捷工具混合使用
    | 大的集中团队 | 实际工具和基于Web的敏捷工具混合使用 | 基于Web的敏捷工具
    | 分布式团队 | 基于Web的敏捷工具 基于Web的敏捷工具

    英文原文:Simple Tools Preferred in the Agile Tools Space

    展开全文
  • 敏捷开发工具Pivotal Tracker实施小结

    千次阅读 2019-01-19 18:03:17
    Pivotal Tracker是一款敏捷开发和项目管理的软件。最近在使用了一段时间后,认为这个工具还是不错的,所以在这里总结一下自己的体会。   敏捷开发介绍 简单介绍一下什么是敏捷开发(Agile Development)。敏捷...
  • 什么是敏捷开发

    万次阅读 多人点赞 2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
     敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值,但是我们认为左项...
  • 敏捷开发工具

    千次阅读 2007-05-22 13:13:00
    将团队开发的工作与交流限制在可以控制的范围内,就是我们选择和使用敏捷开发工具集的原则.并且,使用工具来改善团队开发的工作和交流的重要性已经超越敏捷开发的概念,它是一项在任何开发模式下都具适用性的开发...
  • 敏捷开发的意义和作用

    千次阅读 2013-06-28 20:48:24
     今天听了一天敏捷开发的课,觉得很有意思,我早先就曾经关注过敏捷这个东西,我觉得结对编程挺好的。但是有个问题,就是即便是没有所谓敏捷开发这个概念的时代,也会有小版本迭代这种做法。    早几年,我们的...
  • 2009-09-08 作者:Jack Vaughan 来源:ITPUB敏捷开发的潮流并不是由敏捷工具来推动的。因为你可以仅使用命令行接口、单元测试工具和需求卡片来展开敏捷开发。但近年来,为了更好地支持敏捷开 发,敏捷工具也有了很...
  • 敏捷开发有什么好处?

    万次阅读 2013-08-19 18:17:04
    原文地址:敏捷开发有什么好处?作者:苗得雨 软件开发方法一直处在不断发展过程中。在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升...
  • 敏捷开发 模型讲解

    千次阅读 2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 敏捷开发项目管理软件

    千次阅读 2018-09-10 14:25:19
    工欲善其事,必先利其器,那我给大家介绍一款敏捷开发项目管理工具-Leangoo。 它是由国内最早推广敏捷 也是最权威的 Scrum中文网 研发打造,完美支持Scrum敏捷开发中的所有元素,我们一起来具体看看吧! ...
  • 敏捷开发-快速迭代

    万次阅读 多人点赞 2013-05-08 19:57:45
    今天跟大家分享的是“敏捷开发、快速迭代”。我们大都采用的是“瀑布开发模式”,有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理。经过YH系统的开发,也...
  • 敏捷开发的优缺点

    万次阅读 2017-06-20 14:39:52
    近期试用了一下华为最新推出的项目管理工具-华为软件开发云,接触了敏捷开发,产生一些想法。以下是使用体验,仅供同行们参考。 一、敏捷开发技术的几个特点和优势: 1.个体和交互胜过过程和工具 2....
  • 八分钟敏捷开发(scrum)扫盲

    千次阅读 2018-08-20 16:54:42
    敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...
  • 敏捷开发初步了解

    千次阅读 2019-09-02 10:34:44
    敏捷开发  敏捷开发,现在大多数团队都在推崇敏捷开发模式  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些...
  • 敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。 首先,笔者认为敏捷开发是一种软件过程方法和工具敏捷...
  • 敏捷开发优点和缺点

    千次阅读 2019-07-04 16:04:18
    一、敏捷开发技术的几个特点和优势: 1.个体和交互胜过过程和工具 2.可以工作的软件胜过面面俱到的文档 3.客户合作胜过合同谈判 4.响应变化胜过遵循计划 二、敏捷开发技术的12个原则: 1.我们最优先要做...
1 2 3 4 5 ... 20
收藏数 44,323
精华内容 17,729
热门标签
关键字:

敏捷开发工具的重要性