敏捷开发中制作用户故事

2018-09-07 11:21:02 zz1180 阅读数 6006

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

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

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

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

 

 

 

·



 

2017-11-21 11:24:06 ETIpiero 阅读数 6639

敏捷开发的看板不仅仅只是看板?在敏捷开发中为什么要采用看板?如何设计好的看板?任务条是改进的关键?

 

在我的理解中,敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三个如果实施好了,不管你是否在实施真正敏捷还是对当前项目管理方式的一种改进,都能在研发管理过程中取得很大的进展。

 

前面两篇文章讲了用户故事和站会,这章就重点讲述项目进度看板化,本人会结合实际项目操作过程及对看板演进的过程进行讲解。

 

 

什么是看板?看板不仅仅是看板?

 

看板一词来自日本(kanban),源于精益生产实践(丰田生产),敏捷开发将其背后的可视化管理理念借鉴过来。看板使得项目管理最大的可视化,但是看板更可以将研发的过程进行管理,记录下用户故事研发过程中的细节和历程。

 

敏捷开发为什么要采用看板?

看板可以让研发过程最大限度的可视化,同时解决团队沟通障碍(实践中发现也可以作为和上级沟通项目进展的重要信息)的主要方法之一。通过看板,项目团队可以清楚了解已经完成的情况,正在做的以及后续将有可能需要做的用户故事。

看板可以作为敏捷团队每天站会的讨论的核心,及时变更看板各个用户故事的状态,通过看板,敏捷团队可以清楚的了解其它成员的工作状况及和自己相关工作的进展。

在状态墙上,除了用户故事、 bug之外,还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务,这三类任务用不同颜色的卡片,放到状态墙上统一管理。

敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                                        1.实际项目看板

         看板状态呈现可以很简单,也可以很复杂,这都基于实际项目的需要,我结合我们在实践敏捷研发过程中,对看板的几次改进进行分享。在介绍之前需要对用户故事的“完成”状态下个定义, 用户故事的“完成”是指经过测试并可潜在发布给用户使用的状态

 

 

第一阶段:简单的反映用户故事目前处于的研发状态

        

敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                               2 简单的讲用户故事的任务上墙

         刚开始实施敏捷的时候才用最简单的看板,如上图2所示,只是简单的将用户故事的研发上看板,基于此看板我们能清楚的指导目前用户故事处于的状态。但是这种简单的看板存在一些明显的问题,如研发人员和测试人员的沟通状态无法在看板上进行体现。

         所以在第一阶段我们又进行修改,增加研发和测试的衔接,如下图3所示

         敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?


3 细化“正在做”的状态

         在改进后,我们“正在做”阶段进行细分为开发中,待测试机测试验证,

         这样的看板流程可以有以下一些好处

1.       通过这个改进流程就可以通过看板呈现研发完成到测试阶段,从测试阶段到完成阶段的展示。

2.       通过看板上用户故事数量的状况,可以预测目前研发资源和测试资源配比是否合理?根据状况可以及时调整人员。

 

第二阶段,通过泳道方式,让实现用户故事团队成员间的协作得到反映

         我们开展的项目由于是端到端的系统,所以往往一个用户故事的实现会涉及多个成员的共同参与,所以一个用户故事的完成依赖于多个人员负责的Task完成。所以针对这种情况我们进化了图4的方式,

 

敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                     3 采用泳道方式进行管理

         具有泳道特性的看板,在移动状态时需要参照以下流程

1.       当一个用户从“将要做”移到“用户故事”列时,需要将用户故事涉及的多方成员的工作进行任务拆分,拆分成一个个的任务。

2.       成员针对任务进行工作,当所有成员的任务完成后,将完成的用户移到测试验证列中。

3.       如果测试发现问题,则将相关的bug报给对应任务的人。

 

泳道方式的看板具有以下一些优点

1.       在多个人协助的情况下,每个人可以独立完成分配的Task,相互的影响和制约可以降低到最小。

2.       每个人完成的Task可以作为用户故事的阶段成果,可以尽早的引入测试进行功能测试。

3.       可以非常清楚的了解整个用户故事的进展情况,了解用户故事处于的障碍。

但泳道方式也存在以下不足之处

1.       由于用户故事被拆分成分工明确的Task了,所以这个用户故事内部进入了阶段提交的过程。

2.       由于大家被拆分到了Task,所以需要指定特定的人来负责整个用户故事,并需要在内部协调项目之间的工作

3.       用户故事的工时预计又被模块拆分,在长期实践中,导致工时的预计又进入负责任务的人进行预估的模式。

 

第三阶段,通合理设计任务条,实现故事,进度,工时和各类衔接工作

         在实践了一段泳道模式之后,我们重新思考了,如何让各类工作更好的衔接。最终在任务条上进行改动是最合适的。所以我们根据实践过程中发现的问题,形成了如下的任务条。

         敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?


                                                        图四 全面体现工作的任务条

此看板的任务条主要体现几大方面

1.       用户故事的描述,这个作为任务条核心部分,通过模块和ID和需求系统进行对应

2.       研发团队先对用户故事进行整体工时预估,得出这个用户故事团队的工作时间。

3.       涉及这个用户故事的所有人员都列在用户故事的下方,并且通过每天对当前用户故事的总工作量的预估,以及填写昨天的实际开发所耗工时

4.       用户故事指定相关责任人及依赖关系,可以明确的找到相关人员进行协调和解决

5.       通过bug list列出发现的问题,开发人员可以及时修改

 

采用了这种任务条后,就取消了泳道的模式,而是采用需求,UI设计,开发,单元测试,待测试,测试中,完成几个状态来完成。在我们项目中UI设计进行独立管理,是因为在整个UI设计是我们的瓶颈所在,需要及时查看UI任务堆积状况,及时调整UI的工作优先级状态,所以针对UI我们会独立出任务。

 

敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                              5完整看板状况

 

在做好看板工作时需要注意以下几点

1.       找到一种好的材料来制作任务条,以确保任务条容易被移动,不易掉落并且容易被收藏。一旦这个环节没有做好,很可能会导致看板维护成本加大,甚至后期不维护看板。

我们在这个过程中尝试了很多,如中便签条+小便签条, 大便签条, 纸板+橡皮泥等等,最终结合我们的看板是基于玻璃的,最后选择了打印纸+透明胶的方式,移动很方便,而且不容易掉。

 

2.       及时更新任务条中的各类状态,任务条不仅仅只在看板上移动,更重要的是要记录下研发的过程,这样很容易制作燃尽图,工时消耗图等供全局使用的报表。我们的做法是在站会钱5分钟,大家先更新状态,PO及时统计各类数据。

2016-07-08 14:07:25 langzai2012 阅读数 4982

敏捷开发模式下需求分析岗 BA

传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,没有项目经理,做什么东西完全是程序员自己的行为。他们认为这样的过程无法满足真正大型项目和复杂项目的需要,因此在经过考虑后,放弃了敏捷方法

思考:敏捷开发过程是否存在完整需求分析? 敏捷过程到底是如何做需求分析?   用户故事和用例有什么区别?  敏捷过程如何去管理需求的?

这些是一些想要实践敏捷的人一直在困惑的事情。 我们常常看到书中讲,程序员拿到一个用户故事后,怎么计划,怎么分解,怎么写单元测试,怎么小步前进,怎么持续集成。这是典型的程序员视角。事实上,敏捷方法分为三部分,敏捷项目管理,敏捷需求分析,敏捷软件开发。上述书中提到的完全是敏捷开发中的实践,很多人了解到的敏捷,只是敏捷的三分之一。

敏捷项目中谁来做需求分析?

在敏捷的团队中,作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看,只需要选择一张他感兴趣的故事卡片,了解清楚该卡片的需求,开始从功能测试写代码,等通过了所有测试就完工。基本上不需要考虑太多的事情,非常轻松愉快。但程序员向谁去问清楚需求?故事卡片是怎样写出来的呢?让我们来关注开发前发生的事情。 了解敏捷过程的人都知道,Kent Beck在XP过程中提到了现场客户,如果一个敏捷团队能够有现场客户,这当然是最棒的事情。但多数情况下,客户都是很忙碌的,很难全力投入到软件开发过程中。这时候,我们就需要商务分析师这个角色,来充当客户的角色。商务分析师最重要的职责就是与客户交谈,了解和分析需求,将其制作成用户故事并将需求转述给程序员。同时,商务分析师也要代替客户负责功能验收测试

敏捷项目中如何进行需求分析?

       敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流,搞清楚客户到底需要什么,到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向,就可以不迷失方向。和客户进行交流,最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验,客户说,我要这个功能,我想要怎么怎么样。这时候要特别注意,他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么,挖掘出他真正的目标。

       在这个目标下,商务分析师开始进行需求的分析:我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更? 搞清楚这些事情后,就可以写出用户故事。用户故事的书写遵循一定的原则,一般包括三部分:"作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)"。在书写的时候格式比较随意,可以在故事卡背面写上注释或疑问,甚至画上界面原形图。 举一个最常见的用户故事例子,“作为一个普通用户,我希望能够用用户名和密码登录,以便我能享受到个性化的服务”。其中,用户是系统涉众,登录是他想要做的事情,而他的目标是获得个性化的服务。 从这个例子我们可以想象到,这个页面可能存在两个文本框,用于输入用户名和密码,有一个按钮来登录,并且不登录就不能看到个人资料,另外,如果用户输入错误需要提示“登录失败请重试”。这就是可见性,也可以称为可测试性。我们可以根据这样的可见性写出功能测试,从而驱动这个用户故事的开发,这被称为 Acceptance Driven Development。

 

用户故事和用例有什么区别?

        用户故事的作用有两个,一个是作为进度跟踪的依据,一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求,因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成,这是敏捷需求分析的精华所在。 不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能,而不是文档。而用例需要详细的描述其操作步骤,以及每个异常路径,因而起到了文档的作用。用户故事是可见的商业价值,而不是功能描述。每个用户故事的粒度和工作量都相差不多,这和用例有很大的区别。用户故事是小粒度的,可测试的,可见的,并且是有价值的。 如下

 

【敏捷项目需求分析案例】 公司有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目,在开工的时候客户对功能需求还不明确,但需要快速推出抢占市场,正是最适合敏捷过程的项目。 在项目伊始,商务分析师和客户做了深入的谈话,了解他的商业构想,他的盈利模式,搞清楚宏观的结构,然后思考并整理获得的结果,花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善,不足以做好整个系统。但对于我们开始项目的前一阵,已经足够了。我们可以从这里开始项目。敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前,由一组有经验的开发人员大致评估一下用户故事,标记出不同的难度和风险,并提出问题供商务分析师来获得更详细的信息,商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选,客户可以选择这些用户故事,或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。 项目经理圈子客户看到每个迭代交付的可运行的软件后或者得到用户反馈后,常常会有新的想法冒出来。有些想法是好的,有些想法就属于看到别家网站有这个功能,不假思索的提出的功能。这些不同的需求都需要经过认真的分析,找出哪些是值得我们立即考虑的,哪些是不用急迫的去实现的。 有一次和客户谈话时,他说到希望增加拍卖功能。那么,我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑,我们发现网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求,因此,用户最终放弃了这个特性。 另一次,客服人员提出增加一个查询用户交易的功能,而此时我们有其他更加重要的功能需要先去考虑,查询用户交易功能可以由技术人员临时通过数据库直接代为查询,因为项目运营初期交易不是很多,暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上,始终没有排到最高的优先级。 客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合,客户也逐渐适应了许多敏捷思想,甚至我在和客户讨论时,偶然提起了后期的某种可能的情况,他们还能够帮我纠正应当考虑目前的情况,为近期的情况作计划。

 

敏捷过程如何去管理需求的?

        用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展,是否已经开始实现?是否已经完成代码开发?是否已经开始功能测试?不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后,团队的开发速度基本保持恒定,我们就可以很容易的知道每个迭代能做多少个用户故事,这样就可以安排下一迭代的开发。

          每个迭代内分析好恰好足够下一个迭代开发的需求,就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成,包括需求的了解,分析,评估和排列优先级。 在每个迭代开始的时候,由商务分析师主持召开迭代计划会议,在会议上向所有的程序员解释这个迭代要完成的用户故事,然后由程序员自由提问,知道他们能够获得足够开始实现该功能的信息。 在程序员完成一个用户故事后,商务分析师还要来代表客户做功能验收测试,查看是否完成了预计的功能,是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然,更多的测试还需要QA来完成。

          项目实践中实践充分表明了,敏捷过程并不是没有需求分析,而是把需求分析过程分散到整个开发的过程中,让开发和需求分析并行进行。这就是公司敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中,起到了纽带和桥梁的作用,是一个团队不可缺少的角色 。

2014-11-06 10:38:05 wushxian 阅读数 8591

一次敏捷workshop上,有同学问:“敏捷软件开发中,团队成员自己主动认领的,是用户故事还是被分解成的任务?”同学们一时讨论热烈。

 

稍具敏捷开发实践经验的同学都应该知道,答案是——任务(Task)

 

但我们不想就此打住。让我们从以下几个方面来探讨一下这背后的原因。


用户故事和任务

敏捷团队

敏捷需求估算

敏捷迭代的跟踪与管理


用户故事和任务


用户故事(User Story)和任务(Task)[1]是敏捷开发中管理和跟踪用户需求的主要工具。用户故事是首创于极限编程(XP)的管理用户需求的基本方法,目前已广为各个敏捷实践方法和技术所借鉴和使用。Scrum将用户故事作为最基本的需求管理工具,组成了称之为产品待办事项列表(Product Backlog)的用户需求列表。


用户故事从用户的角度描述用户渴望得到的功能和实现的价值。一个好的用户故事包括三个基本要素:
  角色:谁要使用这个功能。
  活动:需要完成什么样的功能。
  商业价值:为什么需要这个功能以及这个功能带来什么样的价值。


用户故事关注的是交付给客户的最终价值,也就是能给客户带来什么样的最终效益。换句话说,用户故事面向的是具体客户的需求,而不太关心开发团队要怎样才能实现这个需求。用户故事不关心具体实现,使得它不关注具体的细节,因而有时候一个用户故事的粒度很大,甚至会有史诗故事(epic);有时候一个用户故事的粒度有很小,可能一个小的软件缺陷(defect)也能作为一个用户故事。


而软件团队最终需要把承诺的用户故事,转变为可工作的软件,即使用具体的开发语言和工具,实现用户故事。可工作的软件才是敏捷开发真正关注的核心。软件团队需要和产品负责人(Product Owner)及Scrum Master一起,分析、评估具体的用户故事,详细、深入地了解用户故事所传达的用户价值,讨论该用户故事的故事点数(Story Point)以及具体的工作量,实现该用户故事所要做的事情,把这些事情分解为具体的任务,比如逻辑设计、数据库设计、界面设计、编码、测试(或自动化测试)、集成、验收测试、部署等工作


由用户故事分解而来的具体任务,关注于该如何实现该用户故事而必须完成的工作,关注的是具体的技术细节和实现方法。不同的任务具有不同的技术要求,比如开发任务要求的是更加专业和高效的代码实现能力,而测试工作则专注于如何测试该实现以确保最终交付的可工作软件真正实现用户故事所体现的客户价值。因而每个任务的具体技术要求可能都不一样。


由此可见,团队成员更倾向于专注于具体的工作任务和自己专长的领域,而任务则正好适合团队成员专注于某个具体领域并培养自己在该领域的专长。团队成员主动认领自己擅长的任务并高效、高质量地完成之,也是符合敏捷开发原则的最佳做法。


敏捷团队


通常意义上,敏捷软件团队是指遵循敏捷宣言的精神和敏捷实践的具体原则,运用敏捷软件开发相关的技术、方法、工具和流程,从事软件开发和交付的自组织、跨功能团队《Scrum Guide》[1]指出,Scrum团队包含产品负责人、开发团队和Scrum Master。Scrum团队是自组织且跨功能的。自组织团队选择如何最好地完成他们的工作,而不是由团队外的其他人来指使他们。而跨功能团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人员即可完成开发和交付软件所需要的全部工作。Scrum团队模式的目的是最大限度地优化适应性、创造性和生产力。


由此我们知道,跨功能团队包括了完成软件开发和交付工作所需要的全部技能类别,开发、测试、QA、需求、设计、用户体验、数据库等。虽然当前“全栈工程师”的概念颇为流行,但随着现代软件工程向着更加精细的专业化、分工化发展,每一个细分的专业方向都差别巨大。后台数据库的设计和开发与前端界面的美丑、布局是否合理等,不仅仅体现在用户能接触到的多少。一个工程师不可能了解和掌握开发和交付软件所需要的全部技能。因而团队必然是各种技能工程师的组合,大家每人专注于开发和交付高客户价值软件所需要的各个方面,需求、编码、测试、设计、界面优化、用户体验等人员的工作紧密配合、相互协作才能交付高质量的软件。


纯理论上的跨功能团队有时也要求团队成员彼此在技能上尽量缩小差距,不同角色的成员了解和掌握其他角色成员所具备的技能,以便在需要的时候能够担负相应的职责。但从具体实践来讲,团队成员可以了解别的角色的技能,比如开发了解测试,测试工程师学习开发技术等,但精通掌握另一个角色的技能还是有比较大难度的。要想交付高质量软件,每个团队成员必须在自己最擅长的领域做出最可靠和最高效的贡献。专注于某一个具体技术领域,专注才能达到专业,专业才能高质量和高效。所以,敏捷团队必须能够让每个成员都能够在自己专长的工作上发挥最大功效,才能真正成为高效的自组织团队。因此,编码的Task不太可能由测试人员负责,而前端设计类任务也最好由擅长前端设计的人员来负责。


用户故事专注于交付给客户的具体价值,也就是该用户故事能够帮助客户实现什么样的功能和成就。而为实现用户故事,通常会把用户故事分解为一系列要完成的任务,比如最常见的设计、编码、测试、集成、部署等。所以不同角色的团队成员主动认领自己最擅长的任务并高效完成之,是最合理和高效的做法

 

敏捷需求估算

 

产品负责人(Product Owner)根据来自各渠道收集到的信息,整理并创建出称之为产品待办事项的用户故事列表。而开发团队则负责将经过产品负责人整理和按照优先级排序了的用户故事转变为最终的可工作软件。在这个过程中,软件团队需要和产品负责人一道,分析具体的用户故事,评估实现该用户故事所需要完成的工作,估算具体的工作量。而后软件团队需要在每个迭代开始时,将承诺的用户故事分解为具体的任务。因而该过程需要完成2件事情:1)估算用户故事的故事点;2)将用户故事分解为任务。


敏捷参与者分为“鸡”和“猪”两种角色。“鸡”的角色者,参与项目工作,但不承诺任何结果。就Scrum而言,“鸡”并不是实际Scrum过程的一部分,但是必须考虑他们。“猪”是在Scrum过程中全身投入项目的各种角色,他们在项目中承担实际工作。就像关于“鸡”和“猪”的那个经典笑话里所说的,“猪”要把自己身上的肉贡献出来。敏捷开发中需要的角色包括Product Owner、Scrum Master、Developer、需求、UI/UX、测试、部署等。一般的Scrum开发团队中,通常将Scrum Owner(产品经理)、Scrum Master(项目经理)、Developer、需求分析师作为猪类角色,而测试工程师、UI/UX工程师、QA、客户等作为鸡类角色。

 


而敏捷估算的参与者,必须是“猪”类角色。也就是说,“鸡”类角色并不参与用户故事的故事点估算工作。因而,“鸡”类角色对用户故事的理解远没有“猪”类角色深刻和详细。“鸡”类角色不可能独自认领并承诺用户故事的开发和交付。

 

“猪”类角色将用户故事估算完毕,所有的用户故事在经过Product Owner的排序之后,组成了产品待办事项列表。在每个Sprint的Sprint计划中,包括“鸡”类角色在内的团队针对优先级最高的用户故事,进行讨论、分析,并将之分解为一个个的任务,这些任务细化到实现和交付用户故事所需要采取的每一个步骤。不同的团队角色都要对用户故事的实现和交付做出必要的贡献。这个时候,每个角色根据自己的能力和优势,认领相应的任务,并估计自己所认领任务的工作时间。这就是“谁承诺任务,谁负责任务,谁估算任务”,因为“做这个事情的那个人是最了解那个任务的人,也是最适合对之做出估计的人”。


敏捷迭代的跟踪与管理


敏捷开发中,通常使用任务板来可视化地展示各个用户故事和相应任务的进展情况,并据此画出相应的Sprint 燃尽图(Burndown chart)[3]。作为敏捷开发中任务完成情况的可视化展示,任务板和燃尽图直观而生动地展示出了项目团队在目前工作上的进展情况和预期进展。


有些团队的任务板包括用户故事、任务列表、未开始的任务、已开始的任务(WIP)、完成的任务等。有些团队为了突出彰显任务的承诺者,还会在每个任务上写上认领者的名字,甚至贴上认领者的照片。


从迭代计划的跟踪和管理的角度看,敏捷团队需要跟踪和度量每个任务的完成情况。只有在按照团队“完成”(DoD, Definition of Done)要求,完成了DoD中所要求的全部任务时,一个用户故事才算完成。在IBM RTC里面,度量每个任务的完成时间。而每个任务是跟踪到团队角色的。所以,每个团队角色所认领的,也只是由用户故事分解而来的任务,而不是用户故事。


总结


用户故事专注于团队需要交付给客户的用户价值,而任务则关注于实现和交付由用户故事所体现出的客户价值的技术和底层细节。为实现和交付用户价值,敏捷团队角色需要主动认领属于自己职责和专业领域的工作,完成相应的任务


当然,在某些情况下,为了更加明确项目产品待办事项的职责,会指定某个人负责跟踪和协调某个用户故事的所有任务,以确保在Sprint里面所承诺的所有用户故事需要的任务都能如期完成。但这种用户故事的负责人,不过是项目管理和项目工作跟踪与原理的一种方式,与敏捷开发中自组织、跨功能团队成员主动认领的需要承诺完成的工作是不同的范畴


参考文献: 

[1] 用户故事与敏捷方法,[美] 科恩 著; 石永超,张博超 译; 李国彪,滕振宇 校,清华大学出版社2010年4月出版。

[2] Scrum Guide, http://www.scrumguides.org/。 (中文版 http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CN.pdf#zoom=100 )

[3]  敏捷估计与规划,[美] 柯恩 著; 宋锐 译,清华大学出版社2007年7月出版。


2017-09-27 21:38:14 poppy3163 阅读数 1844

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

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

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

敏捷软件开发(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 服务器上,在一些问题区域上标注鲜明的色彩,用来警示团队中的每个人。

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



http://www.cnblogs.com/lcw/p/4059291.html

0
0

用户故事详解

阅读数 5625

JSAAS敏捷开发平台

阅读数 4428