敏捷开发 谁制作用户故事_敏捷开发中的用户故事和故事墙 - CSDN
  • 用户故事(user story)是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素: 1. 角色:要使用这个功能。 2. 活动:需要完成什么样的功能。 3. 商业价值:为什么需要这个功能,这个功能带来...
    用户故事(user story)是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:
    1. 角色:谁要使用这个功能。
    2. 活动:需要完成什么样的功能。
    3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。


    用户故事通常按照如下的格式来表达:

    英文:
    As a <Role>, I want to <Activity>, so that <Business Value>.
    中文:

    作为一个<角色>, 我想要<活动>, 以便于<商业价值>

    举例:

    作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”

    需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。


    用户故事来描述产品需求是敏捷开发实践必须学习和转变的第一项工作,最经典的三段论,“作为一个…(角色),可以<能够>…(功能),以便…(客户价值),这个语法很好地表明了需求的三个最重要的要素:角色,功能,客户价值。

      为什么需要角色,

      1. 有利于特定的用户核实,有一个“角色“字段,都令沟通工作可以与适当的角色进行,完成的产品自然也就令这些角色的人员满意。

      2. 有利于开发人员理解场景,角色与“普通用户/管理员/执行人“这些区别,可以使开发人员更容易理解产品的用户,风格、操作人员的熟练程度、操作习惯。

      功能描述最好遵从以下两条规则

      1. 主语-谓语原则

      比如,作为一个会议系统管理员,可以显示所有用户的提问,以便。。。。

      是不是别扭,对可以转换成“可以查看所有用户的提问“,这样是通过角色+谓语的方式来描述

      2. 动宾词组原则

      在功能动作描述的时候,尽量采用动词+宾语的描述,如新建用户,查看所有评论等。

      所以对于功能的描述应该是: 把角色作为主语,功能主题的描述采用动宾结构。

      用户价值

      用户价值看似很简单,但是其实是很难写,而且很重要。

      如:作为会议管理员,可以查看所有用户的提问,以便了解哪些用户发表的评论。看上去这种价值描述不错。但是如果系统只是为了查看的话,会议管理员为什么要查看?如果评论很多,他如何查看?

      所以用户故事的价值描述,给需求分析做了一些价值挖掘的要求,团队要去挖掘角色做这一动作的价值,要为角色挖掘出必要且合理的理由。

      用户故事作为需求分析和研发的依据,是在敏捷开发实践过程中首先需要去实践的一个重要环节,看似简单的用户故事,在实际操作中是相对困难的,如何从传统的功能描述转变成客户和研发团队都能理解的用户,这里有很多技巧。包括如何确定角色,用户故事颗粒度,用户故事的评估等问题。

    推荐大家一本书科恩(美)的《用户故事与敏捷方法》。


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

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

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

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

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

     

     

     

    ·



     

    展开全文
  • 敏捷软件开发中,史诗&故事都是常用的术语。对于管理敏捷软件开发来说,...任务:是完成用户需求的过程性的工作,表示用户故事开发任务的完成; 子任务:子任务通常是故事或任务的具体拆分,由单人承接,而且通常.

    在这里插入图片描述
    在敏捷软件开发中,史诗&故事都是常用的术语。对于管理敏捷软件开发来说,Choerodon猪齿鱼是一个很好的工具,为敏捷术语和功能提供了非常广泛的实践方法,例如:史诗,故事、任务、子任务和缺陷,这些都是Choerodon中的问题类型。

    • 史诗:是一个功能集或是一个大的用户故事,但因为颗粒度太大而无法适应冲刺,它可以分解为许多较小的故事;
    • 故事:是简短的用户需求,足够小以适合冲刺;
    • 任务:是完成用户需求的过程性的工作,表示用户故事开发任务的完成;
    • 子任务:子任务通常是故事或任务的具体拆分,由单人承接,而且通常能在短时间内完成;
    • 缺陷:主要针对测试中的缺陷或者已发布版本的缺陷;

    image

    本文将详细为大家介绍敏捷中史诗和故事以及它们在敏捷中的具体使用规范。

    什么是史诗?

    史诗是一个大的故事,当一个功能具有多个场景时,该功能则需要在史诗层面进行多种实现。史诗代表的通常是与特定结果密切相关的原始想法,与该史诗相关联的用户故事则代表需要交付的解决方案的各个方面。总的来说,通过史诗可以跟踪待办事项中比较大的用户需求,史诗中包含多个小的产品功能的用户故事,这让用户需求更加具有层次结构。

    如何编写史诗?

    对于史诗的编写,目前还没有标准格式,一些团队会使用熟悉的用户故事格式,也有一些团队则用简短的短语表示史诗。

    在命名史诗时,请牢记以下两点:

    1.它是开发或需求的核心内容;
    2.编写时使用组织中的每个人都可以理解的语音文字,以免产生歧义;

    因为史诗是编写用户故事时要参考的内容,并且在编写用户故事时还要参考所有团队成员的意见,所以正确的编写史诗并将详细信息在史诗中体现非常重要,这有助于避免团队中的许多冲突和对产品功能的误解。

    用史诗介绍开发的新功能时,需要包括开发此功能的原因、需要解决的用户需求以及新功能的度验收量标准。此外,该功能的任何文档或早期的思路,可以向团队简单介绍,或者提供清晰的图片和信息。注意:团队对功能达成共识和目标是成功交付的关键。

    Choerodon中的史诗示例:

    • 史诗01:向用户提供排序和优先级选项,以轻松管理需求
      • 用户故事01:作为发布经理,我希望将发布映射到不同的sprint,并看到每个故事的优先级。
      • 用户故事02:作为系统管理员,我拥有优先处理产品需求的权限。
      • 用户故事03:作为用户,我可以标注需求的优先级,并实现简单的拖放操作重新排序需求。

    编写史诗时需要注意的是:

    1. 谨慎思考
      在编写史诗时,可以先撰写项目构想的草稿,并需要思考最有必要的内容以及在以后的开发中包含的内容。这些都需要仔细考虑。

    2. 逻辑清晰
      在编写后续的史诗时,应该根据先前的主题来创建史诗,前后的史诗需要合乎逻辑且一致。

    3. 结合测试
      史诗不只是从大的故事进行思考,它分解的每个功能还需要在测试中可用。

    4. 参考专家人士的意见
      在编写过程中不应仅依靠个人或团队成员的眼光和思路,还需要参考专家人士的意见,阅读专业人士的的博客或他们推荐的书籍。他们的工作经验和意见能使史诗更加客观,也能让团队成员获得专业的经验和技能。

    史诗是项目计划过程中重要的组成部分,有了史诗,团队成员和利益相关者可以看到产品真正的目的和用户需求。正确的史诗是进一步项目开发甚至产品研发的好帮手。

    什么是用户故事?

    用户故事是基于史诗进行分解的,反映的是用户需求和用户可以得到的价值。它们从用户的角度描述功能的各个部分。在敏捷开发过程中,当我们开始站在用户的角度上思考时,即使这个功能不是当前解决方案的范畴,我们仍需要建立用户可以操作的行为场景。例如,我们正在针对共享照片和视频的特定问题制定解决方案,根据经验我们按照预期的方式执行所有操作,但是用户第一次使用并且不了解产品,可能查找不到特定角色对应的照片。为了避免这种情况,在用户故事中从用户角度清楚地说明所需的功能非常关键。

    如何编写用户故事

    在敏捷方法论中,团队构建的所有内容都应围绕用户,这里的团队指的是产品经理、客户、利益相关者还有产品的最终用户。为了深度了解用户的需求和痛点,在开始编写用户故事之前,需要确定好产品的角色。以下是编写用户故事时广泛使用的模板:

    “ 作为一名 <角色或角色>,我可以 <目标/需要> 这样说 <为什么>”
    或者,在另一种情况下:
    “作为 <特定的用户类别>,我希望 <能够执行/执行某项操作>, 以便 <获得某种形式的价值或收益>”

    上面的描述为产品用户制定了业务价值。除此之外,用户故事的魅力在于,它不仅制定了业务价值,而且还制定了开发和测试的要求。通过简单的描述,添加产品功能的验收标准等描述,以总结需要完成的所有任务。

    以下Choerodon中某个项目的用户故事的简短形式:

    作为夜晚驾驶的驾驶员,我想迅速找到最近的优质加油站,以补充高品质的汽油。

    • 验收标准:
      • 作为开灯的司机,我可以看到所有即将到来的加油站。
      • 点击“Ctrl+T”,我可以选择适合我的加油站品牌的加油站。
      • 到达加油站,我可以看到即将到来的选定品牌的加油清单。
      • 点击“M”键,我可以看到最近在地图上选择的加油站。

    image

    用户故事的重点是从用户的角度清楚地说明所需的功能,需要正确的理解用户需求并详细的表达出来。编写用户故事时需要注意:

    1. 用户故事≠任务
      用户故事不是任务。在实际开发中,一个故事可能需要数百个任务才能成功交付,任务与执行有关,而用户故事是根据用户需求定义的。在编写故事时,应着重于提供有关产品功能的信息。

    2. 故事简明扼要
      故事必须简单而准确。只需使用简单准确的语言即可,有助于团队成员和利益相关者深入了解用户需求,避免花时间澄清用户故事中不清楚的地方,比如术语和首字母缩写词等。

    3. 了解用户
      在开始编写用户故事之前,都需要收集一组关键用户(理想情况下是产品的角色用户),了解他们的个人资料、观点、对产品的期望以及相关的“痛点”,以帮助更好地了解用户及其需求。

    4. 大胆思考
      当将产品描述为用户故事放到待办事项中时,“没有预算,时间周期不允许,可行性低或成本高等”会限制产品的思维。正确的做法是大胆思考 ,将用户故事维护到待办事项列表,从产品的清晰度、用户愿景方面获得的价值。

    用户故事提供了一种快速而准确地描述软件产品或系统功能的好方法,在产品规划会、产品迭代会中具有主导和输出作用。在这些会议过程中,用户故事需要以紧凑、结构化的方式阐明思想的提要。

    故事地图

    根据敏捷的定义,在Choerodon中我们使用故事地图的形式来体现史诗和用户故事的价值。

    image

    故事地图的优势:

    1. 将史诗用作业务价值的容器;
    2. 根据产品版本得到横向流程;
    3. 快速制定出产品的蓝图,得到mvp版本的制作周期;(关于MVP的介绍可以参考《MVP:平衡“可行性”和“最小化”》);
    4. 以故事为中心,使开发人员的精力全部集中到重点功能上;
    5. 使用增量来定期检查并调整项目进度;

    总结

    敏捷开发关注于快速且持续地交付给用户高价值、高质量、可用的产品功能。通过史诗和用户故事梳理用户需求、识别用户角色、梳理用户故事逐步完善更多细节,使执行的故事足够短小、简单,能在单个迭代期内完成,达到快速交付的目的。

    本篇文章出自Choerodon猪齿鱼社区付新圆&柴晓燕。

    展开全文
  • 如何理解敏捷开发

    2019-01-04 16:16:15
    敏捷开发,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 二、敏捷开发的特点 敏捷是以人为中心的软件开发方法,保持简洁的代码,经常性测试以及及时地交付应用的功能模块。正如敏捷宣言所提到...

    一、什么是敏捷开发?

    敏捷开发,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

    二、敏捷开发的特点

    敏捷是以人为中心的软件开发方法,保持简洁的代码,经常性测试以及及时地交付应用的功能模块。正如敏捷宣言所提到的那样。

    敏捷宣言强调的敏捷软件开发的四大宣言是: 
    1.个体与交互高于流程和工具 
    2·工作软件高于理解文档 
    3·客户协作高于合同协商 
    4·变化响应高于计划遵循 

    结合软件研发实际,四大宣言可以这样理解:

    个体与交互胜过过程与工具

           方法和工具是死的,人是活的,如何没有优秀个人和团队协作,再强大的方法和工具都是摆设。一个使用普通工具的优秀人员会比使用优秀工具的普通人员做得更好,一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷中每个成员都需要定时和团队的其他成员一起查看团队的整体进度,计划下一步工作,并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力,可以自发的通过各种途径解决开发过程中遇到的问题。

           虽然我们致力于个体和交互,但并不代表就不需要过程与工具了。Scrum、XP等方法本身也有一些方法和过程,每日构造等敏捷实践也需要工具的支持,需要哪些过程和工具由自组织团队制定,而不是由领导制定。

    工作软件高于理解文档 

           在合同中有时会看到分别在需求、设计、开发、测试阶段提供什么文档,支付多少金额等内容,而这些文档对用户来说是不是真的有价值呢?冗长文档对客户来说并不重要,其重要程度比不上一个可以工作的软件。冗长的文档对开发也不重要,没有人有时间去读,而且也不符合敏捷开发的特性,对研发团队来说最好的文档就是代码和团队,通过频繁的提供可以工作的软件,不断地搜集市场反馈,保证软件的市场时效性。

           虽然我们致力于提供可供做的软件,但并不是不要文档。我们在开发过程中仍然需要进行内部交流, 也需要和客户交流,我们仍旧可能需要制作原型,书写一些主要需求和算法,只要可以满足研发团队需求就行。

    客户协作高于合同协商 

           寻求客户合作的价值重于对合同的谈判。软件开发的最终目标是提供给客户满意的软件,而只有客户才更清楚怎么样才能满意,敏捷开发提倡客户和开发团队密切的在一起工作,经常性的根据市场需求对软件提供反馈。各种不同的敏捷方法都会利用短期迭代,通过尽早提供软件来达到与客户频繁沟通和反馈的,这也可以把问题及早暴露出来,以免隐藏的问题在后期造成更大的影响。

           虽然我们致力于客户协作,但为了双方利益和需要仍旧需要进行合同谈判。

    变化响应高于计划遵循  

           敏捷项目承认开发过程中的不确定性,所以不会在开发中制定长时间的复杂计划,它们的成功都是建立在现实反馈的基础上的。每次迭代都是基于上一迭代的完善基础之上进行的,通过不断的响应变化来消除开发中的不确定性。

           在敏捷开发时,我们不应该为了让自己的项目看起来像是按照计划好的样子循序渐进,而花费大量的时间让研发团队去附和计划。相反,敏捷需要的不是计划,而是规划。

           敏捷开发方法是“规划-执行-调整”、“规划-执行-调整”。一个项目的不确定性越高,敏捷开发方法对取得成功就越是至关重要,不断学习和调整是敏捷开发的核心。

           像3355中5会那样,计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。阶段性的召开会议,提出当前阶段的问题,根据昨天完成的情况来做出新的调整,根据上一个迭代对新的迭代功能等进行规划。在sprint评审会上,团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理,可以让团队有机会去回顾和识别版本发布的风险。

    敏捷开发的12条原则包括: 
    1.通过早期和连续型的高价值工作交付满足“客户”。 
    2.大工作分成可以迅速完成的较小组成部门。 
    3.识别最好的工作是从自我组织的团队中出现的, 
    4.为积极员工提供他们需要的环境和支持,并相信他们可以完成工作。 
    5.创建可以改善可持续工作的流程。 
    6.维持完整工作的不变的步调。 
    7.欢迎改变的需求,即时是在项目后期。 
    8.在项目期间每天与项目团队和业务所有者开会。 
    9.在定期修正期,让团队反映如何能高效,然后进行相应地行为调整。 
    10.通过完成的工作量计量工作进度。 
    11.不断地追求完善。 
    12.利用调整获得竞争优势。

    大致来讲,12宣言的核心内容就是将一个软件分成多个迭代去完成,在每个迭代开发时,坚持以人为本的原则,在研发过程中坚持人比工具更重要。在研发中坚持完善工作,拥抱市场拥抱变化,根据市场来调整软件的功能。快速变化,高效的做出响应。不断地调整软件,保持市场时效性。

           

           

     

    展开全文
  • 在我的理解中,敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三个如果实施好了,不管你是否在实施真正敏捷还是对当前项目管理方式的一种改进,都能在研发管理过程中取得很大的...
  • 敏捷开发中的测试人员敏捷开发团队介绍测试人员需要具备的素质测试人员的主要职责定义质量 (Define Quality)交流缺陷(Communication)及时反馈 (Feedback):敏捷开发中QA的职责之敏捷中的QA敏捷QA的日常活动敏捷QA与...
  • 敏捷开发

    2016-07-14 18:45:16
    敏捷开发用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把...
  • 用户故事(英语:User story)是指从用户的视角来表达软件需求的一种方式 用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。用户故事可以帮助研发团队理解真正的用户需求是什么,也可以促进...
  • 什么是敏捷开发

    2017-09-27 21:38:16
     不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。   第一部分:敏捷软件开发...
  • 敏捷开发模式下需求分析岗 BA 传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,...
  • 关于敏捷开发

    2018-01-18 09:11:59
    敏捷开发被越来越多的创业者奉为最适合初创公司的开发方法,可是在实际运用中,敏捷开发给我带来的是一个又一个的坑,如果没有对这种开发方法更深层的掌控,可能会打乱你的产品工作,得不偿失。 经过一段时间的沉淀...
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...
  • 什么是敏捷开发1.1 敏捷开发的定义1.2 敏捷开发的原则1.3 敏捷开发的特点1.4 传统的开发模式和敏捷开发模式的对比1.5 敏捷开发的分类1.5 Scrum 一. 什么是敏捷开发 1.1 敏捷开发的定义 2001年,由Martin Fowler,...
  • 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可...
  • 敏捷开发流程需求理解方案评审日常任务性能测试CodeReviewDemo 需求理解 理解需求背景 确认需求明确,无逻辑遗漏 确认所有需求方案都有实现方案 合理预估时间 需求不明确或者不清晰的点,可以当场提出来,或者稍后整理...
  • 敏捷开发之热门已达到任何一个开发人员都至少听过,并觉得敏捷方法很好,然而并不是所有的人都学习和实践过,以致于大家谈敏捷的时候其实理解的基准是不一样的,也导致“敏捷”泛滥成灾“,有些看似很敏捷的开发其实...
  • JSAAS敏捷开发平台

    2017-11-29 15:55:42
    1. 敏捷开发平台简介 红迅JSAAS敏捷开发平台是广州红迅软件有限公司面向合作伙伴以及有IT运维团队中大型企业提供新一代的企业级的数据IT一体化的业务管理平台工具,它基于流行的JAVA开源技术上构建,扩展容易,学习...
  • 敏捷开发与极限编程

    2014-02-11 23:35:03
    敏捷开发与极限编程作者: 陈沛 (系摘编) 软件设计方法可以区别为重量级的方法和轻量级的方法。重量级的方法中产生大量的正式文档。 著名的重量级开发方法包括ISO9000,CMM,和统一软体开发过程(RUP)。...
  • 敏捷开发 vs 传统开发

    2020-01-14 17:26:26
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 项目流程之敏捷开发

    2018-07-20 10:41:17
    大家好,我是IT修真院深圳分院第8期的学员,一枚正直纯洁善良的PM,今天给大家分享以下知识点是修真院pm任务十一中的项目流程之敏捷开发的小技巧 正常产品项目流程: 可以是产品经理创造需求;可以是“灵光一现”;...
1 2 3 4 5 ... 20
收藏数 7,086
精华内容 2,834
关键字:

敏捷开发 谁制作用户故事