1. Agile Software Development
This section is a brief introduction
to agile software development. It is organized into
the following sections:
Defining agile 敏捷定义
The agile system development lifecycle 敏捷系统开发生命周期
The traditional system development lifecycle 传统系统开发生命周期
How agile approaches are different 敏捷方法的不同
Comparing agile and traditional approaches 比较敏捷和传统的方法
1.1 Defining Agile
One frustration that many people new to agile have
is that there is no official definition of agile software
development, although many people will point tothevalues
andprinciples of theAgile Manifesto. Having said that,
mydefinition of disciplined agile software development
An iterative and incremental (evolutionary) approach
to software development which is performed in a highly
collaborative manner by self-organizing teams within
an effective governance framework, with "just enough"
ceremony that produces high quality software in a cost
effective and timely manner which meets the changing
needs of its stakeholders.
The criteria that I look for to determine whether a
team is taking a disciplined approach to agile development.
First, is the team is doing developer regression testing,
or better yet taking a test-driven approach to development?
Second, are stakeholders active participants in development?
Third, is the team producing high-quality, working software
on a regular basis? Fourth, is the team is working in
a highly collaborative, self-organizing manner within
aneffective governance framework? Fifth, are they improving
their approach throughout the project?
1.2 The Agile System Development Lifecycle
To truly understand agile testing and quality strategies
you must understand how they fit into the overall agile
system development lifecycle (SDLC). Figure 1 depicts
a high-level view of theagile development lifecycle,
showing that agile projects are organized into a series
of time-boxes called iterations (in the Scrum methodology
they call them "Sprints" and some people refer
to them as cycles). Although many people with tell you
that the agile lifecycle is iterative this isn't completely
true, as you can see it is really serial in the large
and iterative in the small. The serial aspect comes
from the fact that there are at least three different
iteration flavors -- initiation iterations (light green),
construction iterations (light blue), and release iterations
(blue) -- where the nature of the work that you do varies.
The implication is that your approach to testing/validation
also varies depending on where you are in the lifecycle.
As a result it is important to understand each of the
high-level activities depicted by this lifecycle:
去真正的理解敏捷测试和质量策略，你必须理解他们如何融合到整个敏捷软件开发生命周期， Figure 1
1、Iteration 0. The goal of this iteration, or iterations
on complex projects, is to initiate the project. You
will performinitial requirements envisioning, initial
architecture envisioning, begin identifying and organizing
the development team, come to some sort of stakeholder
concurrence as to the goal(s) of the project, and gain
funding and support for the project. Testing/validation
activities include beginning to set up your testing
environment and tools as well as potentially reviewing
the initial models, plans, and vision or stakeholders
迭代0. 这个迭代或复制项目上的迭代的目的是做初始化项目。你将执行执行初始需求，初始架构， ，开始定义和组织开发团队,
。。。。 并且获得资金和支持项目。测试/验证活动活动包括 搭建你的测试环境和准备测试工具，以及可以审查初始模型，计划，和可视的涉众目标文档。
2、Construction iterations. During each construction
iteration (iterations 1 to N inFigure 1) the goal is
to produce more potentially shippable software. Agile
teams follow theprioritized requirements practice --
each iteration they take the most important requirements
remaining from the work item stack (what Scrum teams
call a product backlog) and implement them. Agile teams
will take a whole team approach where testers are embedded
in the development team, working side by side with them
to build the system. The focus of their testing efforts
are often on confirmatory testing via developer regression
testing or better yetTest-Driven Development (TDD).
构造迭代： 通过构造迭代，目标是去生成更潜在可交付的软件。敏捷团队根据需求度优先级 --每个迭代他们把最重要的需求放入工作堆栈中（SCRUM
团队中交一个产品backlog) 并且实现他们。 敏捷团队要执行测试人员嵌入到开发团队中的整体团队方法，并肩工作构建系统。
3、Parallel independent testing. Disciplined agile teams
perform continuous independent testing in parallel to
construction iterations throughout the lifecycle. The
goal of this effort is to find defects that got past
the development team, often performing higher forms
of testing such as exploratory testing, system integration
testing, security testing, usability testing, and so
on which require significant testing skills, complex
testing tools, and often complex pre-production testing
environments. There is often a 10:1 to 15:1 ratio between
people on the development team and independent testers
supporting them. In larger organizations this independent
test team typically supports several development teams
(thus enabling more sophisticated system integration
testing because they can more easily work with versions
of multiple systems under development).
并且经常预生成测试环境。 开发团队和支持他们的测试独立测试人员比例大概在10:1 到 15:1. 在大型的组织里独立的测试团队支持几个开发团队（因为他们能够更容易工作在多个系统版本，因此使得更富在的系统集成测试变得可能）
4、Release iteration(s). The goal of the release iteration(s),
the dark blue "R" iteration in Figure 1, is
to successfully deploy your system into production.
This can be quite complex in practice, including training
of end users, support people, and operations people;
communication/marketing of the product release; backup
and potential restoration (if things go bad); pilot/staged
deployment of the system; final translation of the UI
anddocumentation; finalization of system and user documentation;
and so on. During the release iteration there is still
sometesting at the end of the lifecycle to ensure that
the system is ready for production.
发布迭代：发布迭代，在Figure1中 蓝色R迭代， 的目标是成果的部署你的系统到生产环境，在实践中相当复杂，他包括终端用户，支持人员和操作人员的培训，沟通和市场的产品发布；备份和回复（如果发布失败）；试点/分期的系统部署，最后的UI和文档的翻译，最后交付的系统和用户的文档
，等等 。 在发版迭代仍然有些最后的测试要做，这些测试确认系统已经准备好上线。
Figure 1. High-level agile development
Figure 2 shows a detailed version of the SDLC, fleshing
out the details of Figure 1. Figure 2 also adds new
phases so as to depict the full end-to-end lifecycle,
including "iteration -1" where you identify
potential projects, the production phase where you operate
and support the system once it has been released, and
the retirement phase where you fully remove an unneeded
system from production.
Figure2 展示了一个软件开发生命周期的详细版，充实了figure 1， Figure 2 也加了新的阶段"iteration-1"
去描述完整的端到端的生命周期， “iteration-1" 中你识别潜在的项目，
”production phase“ 一旦产品被发布需的要操作和支持。
”retirement phase" 从生产环境中删除不需要的系统
Figure 2. A detailed agile SDLC.
1.3 The Traditional System Development
Figure 3 depicts the V Model for software development,
basically a sophisticated form of the traditional waterfall
model. With the V model the work on the left-hand side
of the diagram is validated later in the lifecycle through
corresponding activities later in the lifecycle (for
example requirements are validated through acceptance
testing, the architecture via integration testing, and
so on). Although this approach is better than not testing
at all, it proves to be very expensive in practice because
of several systemic problems:
Figure 3, 描述了软件开发的V模型，基于传统瀑布模式的复杂形势。 V模型的左边是后期验证活动，在活动的晚些时候执行验证活动（例如，需求在验收测试时被验证，架构被集成测试验证，等等），尽管这个方法比根本不测试要好，他提供了比较昂贵的实践。下面是几个系统的问题描述：
1、Deliver the wrong functionality. The V model promotes
an approach where the requirements are defined in detail
early in the project. Although this may be good theory
(note the use of the word "may") in practice
it proves to be a very poor way to work. These "big
requirements up front" BRUF approaches result in
significant wastage because at best the project team
will build something to specification instead of something
that the stakeholders actually need.
2、uild to a fragile design. Similarly, although in
theory it may be a good idea to think through the details
of the architecture/design up front the reality is that
you end up making, and then committing to, technical
decisions are too early when you have the least amount
of information available to you (during architecture/design
phases you're making decisions based on what you hope
will work, as opposed to what you know will work based
on actual working software).
3、Hand-offs inject defects. Every time you have a hand
off between two groups of people defects due to misunderstandings
will be injected into the product. Although this problem
can be partly mitigated via reviews, this proves to
be expensive compared to more agile approaches such
4、Fixing defects is expensive. The greater the feedback
cycle the greater the average cost of fixing a found
defect. The V model approach promotes very long feedback
修改缺陷成本昂贵。 反馈周期越长，平均修复缺陷的成本就越高。 V模型方法提供了一个非常长的反馈周期。
5、Increased time to value. The V model lengthens the
amount of time, through increased bureaucracy and waiting
time, it takes to deliver functionality into production.
This in turn lowers the opportunity benefits and net
present value (NPV) provided by the release.
Figure 3. Serial SDLC/V Model.
1.4 How Agile is Different
Traditional testing professionals who are making the
move to agile development may find the following aspects
of agile development to be very different than what
they are used to:
Greater collaboration. Agile developers work closely
together, favoring direct communication over passing
documentations back and forth to each other. They recognize
that documentation is the least effective manner of
communication between people.
Shorter work cycle. The time between specifying a requirement
in detail and validating that requirement is now on
the order of minutes, not months or years, due to the
adoption of test-driven development (TDD) approaches,
greater collaboration, and less of a reliance on temporary
Agilists embrace change. Agile developers choose to
treat requirements like a prioritized stack which is
allowed to change throughout the lifecycle. A changed
requirement is a competitive advantage if you're able
to implement it.
Greater flexibility is required of testers. Gone are
the days of the development team handing off a "complete
specification" which the testers can test again.
The requirements evolve throughout the project. Ideally,
acceptance-level "story tests" are written
before the production code which fulfills them, implying
that the tests become detailed requirement specifications.
Greater discipline is required of IT. It's very easy
to say that you're going to work closely with your stakeholders,
respect their decisions, produce potentially shippable
software on a regular basis, and write a single test
before writing just enough production code to fulfill
that test (and so on) but a lot harder to actually do
them. Agile development requires far greater discipline
than does traditional development.
Greater accountability is required of stakeholders.
One of the implications of adopting the practices active
stakeholder participation, prioritized requirements,
and producing working software on a regular basis is
that stakeholders are now accountable for the decisions
that they make.
Greater range of skills are required. It isn't enough
to be just a tester, or just a programmer, or just an
analyst, or just a ... anymore. Agilists are moving
away from the Tayloristic approaches of traditional
development which motivate people to become overly specialized
and instead are moving towards a highly iterative and
collaborative approach which requires generalizing specialists
需要更广的技术面。 仅仅做一个测试人员，一个分析人员 等是不够的，敏捷者不再是传统开发方法中激励人们成为的专才，而是适应高度迭代和协作方法的通才（不是多面手）-大概意思是样样精通的人才。
1.5 Comparing Agile and Traditional
The agile approach offers many benefits over the traditional
Greater ability to deliver required functionality.
Agile teams work closely with their stakeholders, ideally
following the practiceactive stakeholder participation.
This practice, in combination with an evolutionary approach,
results in greater ability of agile teams to understand
and then implement the actual needs of their stakeholders.
Figure 4 summarizes results from Dr. Dobb's Journal
(DDJ)'s 2008 Project Success Survey, showing that agile
teams are more effective at delivering required functionality
than traditional teams.
Greater quality. Figure 4 also shows that agile approaches
result in greater quality than traditional approaches,
most likely due to increased collaboration within the
team and earlier and very often more testing throughout
很好的质量。Figure 4 也展示了敏捷方法的结果比传统方法有更好的质量。这最可能因为增加团队内部的协作和较早的经常的测试在整个生命周期中。
Improved designs. Agile architecture and agile design
strategies are evolutionary in nature, and this, in
combination with the greater levels of collaboration
exhibited by agile teams, results in better designs
when compared to more traditional approaches. Architecture
and design are so important to agile teams that they
do these activities throughout the lifecycle, not just
during early lifecycle phases.
Improved economics. Figure 4 shows that agile teams
are providing greater return on investment (ROI) than
traditional teams. This is due in part to the shorter
feedback cycle of agile approaches which lowers the
average cost of addressing defects. Furthermore, because
agile teams are working smarter, not harder, they often
get the functionality delivered quicker (whichFigure
4 also depicts) thereby providing quicker time to value
and thus greater benefit.
改善经济. Figure 4 展示了敏捷团队提供了比传统团队更高的投资回报率，这是由于部分原因敏捷方法的比较短的反馈周期，这降低了定位bug的平局成本。另外，因为敏捷团队工作灵活，而不敬仰，他们经常成功快速的功能交付，因此提供了更快的获得价值和收益。
Figure 4. Success factors by paradigm
(Scale is from -10 to +10).
Finally, I just wanted to point out that the results
depicted inFigure 4 aren't an anomaly. DDJ's 2008 Agile
Adoption Survey also found that people believed that
agile teams were producing greater quality than traditional
teams, providing better stakeholder satisfaction, and
providing greater levels of productivity.
最后，我只想指出Figure 4 描述的结果是正常的， DDJ‘s 2008年敏捷调查，也发现了人们普遍详细敏捷比传统团队生产出更高质量的产品，提供的产品涉众（需求放）更满意，提供更高的生产率。