|
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（测试驱动开发）和可执行性需求进入到
？？ 这段按照下面进行组织：
Active Stakeholder Participation 涉众积极参与（需求方积极参与）
Functional Requirements Management 功能需求管理
Initial Requirements Envisioning 初始需求展望
Iteration Modeling 迭代模型
Just in Time (JIT) Model Storming 及时模型风暴
Non-Functional Requirements Management 非功能需求管理
Who is Doing This? 谁来做这些工作
The Implications for Testing 测试启示
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:
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.
JIT model storming. just in time (JIT)
model storming through the construction lifecycle to
explore the details
Independent parallel testing. This is performed throughout
the lifecycle to ensure that the system addresses the
non-functional requirements appropriately.More on this
later.
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:
敏捷需求策略对敏捷测试有几个重要影响：
Agile testing must be iterative. Agile requirements
activities, and design activities, and construction
activities, are iterative in nature. So must testing
activities.
敏捷测试必须是迭代：敏捷需求活动和设计活动以及构造活动，本质是迭代的，所有测试活动也是迭代的。
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.
敏捷测不能依赖完整的说明书：当你看Figure 2 和 7中的需求被识别，研究和实现贯穿申明周期，没有简单的需求阶段去产出完整的需求说明书，因此，测试策略不能依赖完整的需求说明书。
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.
敏捷测试人员必须是灵活的。 测试人员必须有最好的工作能力，根据被提供的信息进行工作。 能够全面的理解提供他们的工作的信息，而且这些信息可能经常变化。
也就是说敏捷测试人员要适应变化，快速的全面的理解工作信息。
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. | 
