敏捷测试与最佳实践(二) 敏捷需求

翻译 2013年12月05日 16:50:46

2. Agile Requirements Strategies

This section provides an overview to agile approaches to requirement elicitation and management.  This is important because your approach to requirements goes hand-in-hand with your approach to validating those requirements, therefore to understand how disciplined agile teams approach testing and quality you first need to understand how agile teams approach requirements. Figure5 depicts a process map of thebest practices of Agile Modeling (AM) which address agile strategies for modeling and documentation, and in the case of TDD and executable specifications arguably strays into testing.  This section is organized into the following topics:

这段提供一个需求调研和管理的敏捷方法,这是是非常重要的,因为你的需求方法和验证需求的方法是相辅相成的。因此,去理解严格的测试和质量方法前,你需要去理解敏捷团队的需求方法。Figure 5描绘了一个敏捷模型的最佳实践 ,他提出了对模型和文档的敏捷策略和 TDD(测试驱动开发)和可执行性需求进入到 ??  这段按照下面进行组织:


Figure 5. The best practices of Agile Modeling.

 

 

2.1 Active Stakeholder Participation

Agile Modeling’s practice of Active Stakeholder Participation says that stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques. When stakeholders work closely with development it increases the chance of project success by increasing the:

敏捷模型中的涉众积极参与 是说涉众应该提供及时信息和及时做出结论。 并且通过使用工具和技术积极参与开发过程,当涉众积极参与开发活动,大大增加项目的成功几率:


  • Chance that the developers will understand the actual needs of the stakeholders

    开发人员快速的理解涉众(用户-不是客户)的实际需求的机会

  • Stakeholder's ability to steer the project by evolving their requirements based on seeing working software being developed by the team

    涉众(用户-不是客户)基于看到的开发团队开发出来的软件不断完善需求来控制项目。

  • Quality of what is being built by being actively involved with acceptance testing throughout the lifecycle

    涉众(用户-不是客户)在整个生命周期里参与验收测试。保证产品质量。


The traditional approach of having stakeholders participate in a requirements elicitation phase early in the project and then go away until the end of the project for an acceptance testing effort at the end of the lifecycle proves to be very risky in practice.  People are not very good at defining their requirements up front and as a result with a serial approach to development a significant effort is invested in building and testing software which is never even used once the system is in production.  To avoid these problems agilists prefer an evolutionary approach where stakeholders are actively involved, an approach which proves more effective at delivering software that people actually want.

传统的方法是涉众在项目的早期参与需求分析和调研,在项目结束阶段在参与项目的验收,这种方法是有很大风险。  人们不善于在开始非常好的定义需求 并且经历一系列的开发活动构造和测试的那个重来没有使用的生产系统。 去避免这些问题敏捷专家喜欢通过涉众积极参与的进化的方法 ,这保证了交付客户实际想要的软件的交付效率

 

2.2 Functional Requirements Management

A fundamental agile practice is Prioritized Requirements Stack, called Product Backlog in Scrum.  The basic ideas, shown inFigure 6, are that you should implement requirements in prioritized order and let your stakeholders evolve their requirements throughout the project as they learn.  The diagram also indicates several advanced agile concepts.  First, it's really a stack of work items and not just functional requirements (defect reports also appear on the stack as you can see inFigure 2,more on this later, and you also need to plan for work such as reviewing artifacts from other teams and taking vacations).  Second, to reduce the risks associated with complex work items, not all work items are created equal after all, you will want to consider modeling a bit ahead whenever a complex work item is an iteration or two away.

敏捷实践的基本原理是优先需求堆栈,在SCRUM中叫做产品Backlog 。 Figure 6中展示了基本的想法, 你应该实现需求的优先级顺序 并且让你的涉众在产品过程中演变需求。

这个图也表明了几个敏捷高级概念,首先,它真是一个工作项目的堆栈,而不仅仅是功能需求(缺陷报告也背显示在这个堆栈中),第二 去减少那些有复杂工作项目带来的风险,毕竟不是所有工作项目是平等的。 你应该对处于一个或两个迭代的任何复杂的工作项目提前考虑建模


Figure 6. Agile requirements change management process.

 

 

2.3 Initial Requirements Envisioning

Figure 7 depicts the project lifecycle of Agile Model Driven Development (AMDD)As you see in Figure 7, during Iteration 0 agilists will do some initial requirements modeling with their stakeholders to identify the initial, albeit high-level, requirements for the system.  The goal of initial requirements envisioning is to do just enough modeling to identify the scope of the system and to produce the initial stack of requirements which form the basis of yourprioritized work item list (it just doesn't magically appear one day, after all).  The goal is not to create adetailed requirements specificationas that strategy actually increases your project risk in practice.

Figure 7 指出了基于敏捷模型驱动开发的项目生命周期,在Figure7 中,你会看到在迭代0  敏捷者会合涉众一起做一些需求模型出示工作,去识别系统的初始的、高级的、需求。 初始需求设想的目的是有足够的模型去识别系统范围,并且生产出机遇你的工作项目优先级立标的初始需求堆栈。 初始需求设想的目的不是编写详细的需求说明书 ,那将增加项目实践风险。



Figure 7: The Agile Model Driven Development (AMDD) Lifecycle.

Fig:敏捷模型驱动开发生命周期

 

Depending on logistics issues (it can be difficult to get all the right people together at roughly the same time) and your organization's ability to make decisions within a reasonable timeframe, Iteration 0 may last for a period of several days to several months of calendar time.  However, your initial requirements modeling effort should only take up several days of effort during that period.  Also, note that there is a bit more to Iteration 0 than initial modeling -- the AMDD lifecycle of Figure 7 only depicts modeling activities.  An important activity during Iteration 0 is garnering initial support and funding for the project, something which requires an understanding of the initial scope.  You may have already garnered initial support via your pre-project planning efforts (part ofportfolio management), but realistically at some point somebody is going to ask what are we going to get, how much is it going to cost, and how long is it going to take. You need to be able to provide reasonable, although potentially evolving, answers to these questions if you're going to get permission to work on the project.  In many organizations you may need to take it one step further and justify your project via a feasibility study.

 根据逻辑问题和你的组织能力在合理的时间内作出决定 0迭代是持续几天或者几个月。 然而初始化需求建模工作在这个周期内应该几天时间。Figure 7 中仅描述了建模活动。

在0迭代中一个重要活动是获得项目的初始支持和资金,这些事情需要对初始范围的理解。 可能在项目前期的计划时已经获得了初始的支持,但实际上还会有些人问项目会收获什么,要花多少钱,要用多长时间。 你需要能够提供足够的理由。

2.4 Iteration Modeling

As you see in Figure 6 agile team will implement requirements in priority order by pulling an iteration's worth of work off the top of the stack. To do this successfully you must be able to accurately estimate the work required for each requirement, then based on your previous iteration's velocity (a measure of how much work you accomplished) you pick that much work off the stack.  For example, if last iteration you accomplished 15 points worth of work then the assumption is that all things being equal you'll be able to accomplish that much work this iteration.  The implication is that at the beginning of eachConstruction iteration an agile team team must estimate and schedule the work that they will do that iteration.  To estimate each requirement accurately you must understand the work required to implement it, and this is where modeling comes in. You discuss how you're going to implement each requirement, modeling where appropriate to explore or communicate ideas. This modeling in effect is the analysis and design of the requirements being implemented that iteration. My experience is that a two-week iteration will have roughly half a day of iteration planning, including modeling, whereas for a four-week iteration this effort will typically take a day.  The goal is to accurately plan the work for the iteration, identify the highest-priority work items to be addressed and how you will do so.  In other words, to think things through in the short term.  The goal isn't to produce a comprehensive Gantt chart, or detailed specifications for the work to be done.  The bottom line is that an often neglected aspect of Mike Cohn’s planning poker is the required modeling activities implied by the technique.

正如你所看到的在图6中敏捷团队将按照工作需求优先级顺序从迭代工作堆栈的顶部开始实现需求。要想成功的执行你必须能够准确的估算每个需求要用的工作量,然后基于前面迭代速度(一个完成多少工作的度量指标),在决定你再堆栈上拿走多少工作。 例如,你最后一次迭代完成了15个工作,那么在同等条件下,你在这次迭代中完成这么多的工作。也就是说在一个敏捷团队的每一个构造迭代开始时必须评估和安排计划这个迭代要做的工作。 准确的估算每一个工作,你必须理解实现工作的要求,这就是建模。

你们讨论怎么去实现每一个需求,在建模式中进行探讨和沟通想法。 这个建模实际上就反复的需求实现的分析和设计。我的经验是一个两周的迭代应该有半天的迭代计划时间,包括建模。如果是4周的迭代周期,这个工作大概花费1天时间。 目标就是准确的计划迭代工作,识别最高优先级工作项目和怎么做。 换句话说,就是在短时间内进行思考。 这个工作目标不是产生一个完整的甘比特度或者详细的工作规范。


 

2.5 Just in Time (JIT) Model Storming

The details of these requirements are modeled on a just in time (JIT) basis in model storming sessions during the development iterations. Model storming is just in time (JIT) modeling: you identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group explores the issue, and then everyone continues on as before. One of the reasons why youmodel storm is to analyze the details of a requirement.  For example, you may be implementing auser story which indicates that the system you’re building must be able to edit student information. The challenge is that the user story doesn't include any details as to what the screen should look like -- in the agile world we like to say that user stories are "reminders to have a conversation with your stakeholders", which in other words says to do some detailed requirements modeling. So, to gather the details you call yourproduct owner over and together you create a sketch of what the screen will look like drawing several examples until you come to a common understanding of what needs to be built.  In other words, you model storm the details.

在开发迭代中通过模型风暴会议或讨论及时把这些详细需求模型化。 模型风暴是及时模型:当你你识别出一个需要解决的问题,马上就要找出几个能帮助解决问题的其他人员,一起研究这个问题,然后每个人继续想前面讲的一样。 通过模型风暴去分析详细需求的原因之一。 例如,你可能实现一个用户场景-他指出系统必须能够编辑学生信息。

 

2.6 Non-Functional Requirements

Non-functional requirements, also known as "technical requirements" or "quality of service" (QoS) requirements, focus on aspects that typically cross-cut functional requirements. Common non-functionals include accuracy, availability, concurrency, consumability/usability, environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, and supportability.  Constraints, which for the sake of simplicity I will lump in with non-functionals, define restrictions on your solution, such as being required to store all corporate data in DB2 per your enterprise architecture, or only being allowed to use open source software (OSS), which conforms to a certain level of OSS license. Constraints can often impact your technical choices by restricting specific aspects of your architecture, defining suggested opportunities for reuse, and even architectural customization points. Although many developers will bridle at this, the reality is that constraints often make things much easier for your team because some technical decisions have already been made for you. I like to think of it like this—agilists will have the courage to make tomorrow's decisions tomorrow, disciplined agilists have the humility to respect yesterday's decisions as well.

Although agile teams have pretty much figured out how to effectively address functional requirements, most are still struggling with non-functionals. Some teams create technical stories to capture non-functionals in a simple manner as they capture functional requirements via user stories. This is great for documentation purposes but quickly falls apart from a management and implementation point of view. The agile requirements management strategy described earlier assumes that requirements are self-contained and can be addressed in a finite period of time, an assumption that doesn't always hold true for non-functionals.

There are four fundamental strategies, all of which should be applied, for addressing non-functional requirements on an agile project:

  1. Initial envisioning.  It is during your initial requirements envisioning that you will identify high-level functional requirements and non-functionals.  All forms of requirements will drive yourarchitecture envisioning efforts, which occur iteratively in parallel with requirements envisioning. The goal of your requirements envisioning efforts is to identify the high-level requirements and the goal of your architecture envisioning efforts is to ensure that your architecture vision effectively addresses those requirements.  You don't need to write detailed specifications at this point in time, but you do want to ensure that you're going in the right direction.
  2. JIT model storming.  just in time (JIT) model storming through the construction lifecycle to explore the details
  3. Independent parallel testing.  This is performed throughout the lifecycle to ensure that the system addresses the non-functional requirements appropriately.More on this later.
  4. Education.  Developer education so that they understand the fundamentals of the full range ofarchitectural concerns described in the requirements.

 

2.7 Who is Doing This?

Figure 8 summarizes some results fromAmbysoft’s 2008 Agile Practice and Principles Survey.  As you can see, it is quite common for agile teams to do some up-frontrequirements envisioning and that requirements details will emerge over time (via iteration modeling and model storming). A tools-based view is shown in Figure 9, which summarizes some results fromAmbysoft’s 2008 Test Driven Development (TDD) Survey.  Although there is a lot of rhetoric aroundacceptance test-driven development (TDD) the fact is that not only hasn't it replaced agile requirements modeling techniques it doesn't even appear to be as popular.  The implication is that requirements are explored via several techniques on agile teams, and rightfully so because one single strategy is rarely sufficient for real-world situations.

Figure 8. Requirements practices on agile projects.

 

Figure 9. Requirements capture practices on agile teams.

 

2.8 The Implications for Testing

There are several important implications that agile requirements strategies have for agile testing:

敏捷需求策略对敏捷测试有几个重要影响:

  1. Agile testing must be iterative.  Agile requirements activities, and design activities, and construction activities, are iterative in nature.  So must testing activities.

  2. 敏捷测试必须是迭代:敏捷需求活动和设计活动以及构造活动,本质是迭代的,所有测试活动也是迭代的。
  3. Agile testers cannot rely on having complete specifications.  As you saw in Figures2 and7 requirements are identified, explored, and implemented throughout the lifecycle.  There isn't a single requirements phase which produces a comprehensive requirements specification, therefore your test strategies cannot rely on having a complete specification available.

  4. 敏捷测不能依赖完整的说明书:当你看Figure 2 和 7中的需求被识别,研究和实现贯穿申明周期,没有简单的需求阶段去产出完整的需求说明书,因此,测试策略不能依赖完整的需求说明书。
  5. Agile testers must be flexible.  Testers must be prepared to work to the best of their ability, with the information provided to them at the time, with the full understanding that the information they are basing their work on today could change tomorrow.

  6. 敏捷测试人员必须是灵活的。 测试人员必须有最好的工作能力,根据被提供的信息进行工作。 能够全面的理解提供他们的工作的信息,而且这些信息可能经常变化。 也就是说敏捷测试人员要适应变化,快速的全面的理解工作信息。
Perfect Software

The good news is that agile testing techniques exist which reflect these implications.  The challenge is that you need to be willing to adopt them.

敏捷测试的方法和实践 (上)

什么是敏捷测试呢?敏捷测试当然不能简单地理解测得更快,绝对不是比以前用更少时间进行测试,也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说,只有敏捷开发,没有敏捷测试。下面我们就要讨论一下:...
  • KerryZhu
  • KerryZhu
  • 2010年12月15日 21:32
  • 23418

浅谈敏捷:基础、需求管理

通过本篇,大家能了解到 1. 敏捷发展历程、宣言、原则. Scrum价值观. 2. Scrum整体框架. Scrum角色(PO、Scrum Master、团队)及职责. 3. S...
  • itCatface
  • itCatface
  • 2016年01月15日 20:33
  • 1108

8个敏捷开发的最佳实践

总结的国外的敏捷开发资料且翻译成中文:The CIO’s Guide to Becoming a Trailblazer 资料下载:http://download.csdn.net/detail/...
  • u011774517
  • u011774517
  • 2017年02月06日 09:34
  • 1190

敏捷 - 需求估算工具 - 故事点

软件项目的几个常见挑战及应对:挑战1 -  在项目还没有开始前,老板总会问:项目什么时候可以做完。应对 1 - 不确定。。。额 对,是不确定。但是,请继续看在任何需求没有细化分解成可用于时间估算的任务...
  • jameszhou
  • jameszhou
  • 2013年09月10日 23:17
  • 1598

敏捷软件测试常见的七个误区

转自 ThoughtWorks 敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法,是能够应对快速变化的需求的一种软件开发能力,它作为一种新型的开发模式,被越来越多地应用到...
  • kaka1121
  • kaka1121
  • 2016年06月21日 09:57
  • 2135

规模化敏捷开发的10个最佳实践(上)

【编者按】软件开发和采购人员经常会对现有软件开发方法、技巧和工具产生一些疑问。针对这些疑问,Kevin Fall 整理了五个软件方面的话题:Agile at Scale,Safety-Critical...
  • wangpeng198688
  • wangpeng198688
  • 2015年08月19日 18:41
  • 759

敏捷开发之需求澄清

SE整理完一个迭代的需求以后,进入下一个流程需求澄清,需求澄清的主要目的是给开发人员澄清需求,确认开发点。   需求澄清的一般流程为:         1.  SE给开发人员讲解需求点     ...
  • chenleixing
  • chenleixing
  • 2015年04月19日 15:27
  • 2000

深入敏捷测试之测试象限

什么是测试象限?敏捷测试象限是什么呢?我们先来上个图: 划分维度通过上图我们可以看出主要是通过业务、技术、检查预期输出及分析未定义的、未知的和意料之外的四个维度,将测试进行切割,分为四个象限。 业务...
  • swordgirl2011
  • swordgirl2011
  • 2017年07月09日 21:23
  • 208

深入敏捷测试之计划不要忘了全局

关于计划的不同观点 因为敏捷宣言说响应高于遵循计划,所以经常有人误以为敏捷开发不需要做计划。而实际上,优秀的敏捷团队的计划性往往比传统瀑布式项目团队更强。它会根据需要把任务分解为足够小的任务块来完成,...
  • swordgirl2011
  • swordgirl2011
  • 2017年07月16日 21:22
  • 525

看看你对敏捷迭代方法的理解:敏捷迭代考试试题附带答案

在学习和实践了一段敏捷方法后,可以检验一下对敏捷知识和思想的领会程度。本试题是一个面向实践的参考,不涉及敏捷的理论条款。 下面试题按照题目(题干)和选项(备选项)的方式排列,注意题目是多选题。“参考...
  • hu_shaoping
  • hu_shaoping
  • 2011年09月14日 23:36
  • 2680
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:敏捷测试与最佳实践(二) 敏捷需求
举报原因:
原因补充:

(最多只允许输入30个字)