|
1. Agile Software Development
1、敏捷软件开发
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
1.1 敏捷定义
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
is:
很多刚接触敏捷的人有个挫折，那是就是没有官方的敏捷软件开发的定义 ，尽管很多人指出了敏捷的价值和方针，话虽如此，我给出的敏捷软件开发的定义是：
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
描绘了一个敏捷开发生命周期的高级视图，展示了敏捷项目被划分到一系列的迭代时间盒（在SCRUM方法中他们比较作“Sprints”
，有些人把他们叫做循环）。 尽管很多人告诉你敏捷生命周期就是迭代，这是不完全正确的。正如你看到的他们针对是连续的小的迭代。
这连续的迭代来自至少三个不同的迭代类型（风味），初始迭代（亮绿），构造迭代（亮蓝），和发版迭代（蓝）-这是迭代工作的不同。
很显然你的测试和验证方法根据所在的生命周期位置的不同而不同，作为一个结果，去理解生命周期中的每一个高级活动是非常很总要的。
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
goals document.
迭代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) 并且实现他们。 敏捷团队要执行测试人员嵌入到开发团队中的整体团队方法，并肩工作构建系统。
测试努力的焦点是经常通过开发回归测试来确认测试或者最好执行测试驱动开发（TDD）
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
lifecycle. 敏捷开发生命周期概览
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
Lifecycle
1.3 传统系统开发生命周期
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.
提供错误的功能。V模型提倡的是需求在项目早起进行详细的定义方法，尽管这可能是好的理论，在时间中被证明是非常贫穷的方法。。这些大需求预先定义的方法结果导致大量的浪费，因为最好的项目团队将构建一些规范，而不是涉众的实际需求。
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
asnon-solo development.
交接注入缺陷。每次在两个组人进行交接时因为错误的理解导致新的缺陷注入到产品中，尽管这类问题通过审查可以减轻，但是也被证明这样做比敏捷方式是昂贵的。
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
cycles.
修改缺陷成本昂贵。 反馈周期越长，平均修复缺陷的成本就越高。 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.
增长的时间价值。 V模型通过增加官僚和等待时间，增加了交付总时间，这也降低了机会利益和发布提供的净现值（NPV)
Figure 3. Serial SDLC/V Model.
1.4 How Agile is Different
1.4 敏捷方法的不同
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
documentation.
较短的工作周期。 确定需求和验证需求的时间现在是按照分钟，而不是月或年，由于测试驱动开发方法的采用，更加协作和介绍对临时文件的依赖。
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
(NOT generalists!).
需要更广的技术面。 仅仅做一个测试人员，一个分析人员 等是不够的，敏捷者不再是传统开发方法中激励人们成为的专才，而是适应高度迭代和协作方法的通才（不是多面手）-大概意思是样样精通的人才。
1.5 Comparing Agile and Traditional
Approaches
1.5 敏捷与传统方法对比
The agile approach offers many benefits over the traditional
V model:
敏捷方法比传统的V模型提供了很多有益的地方：
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.
交付需求功能的能力:敏捷团队与涉众紧密合作，理想情况下满足涉众的实践活动。这个实践，结合进化方法，敏捷团队更好的理解需求的能力并且实现了涉众们的实际需求。Figure
4 总结了这个结果。展示敏捷团队在交付被需要的功能的能力上比传统团队更有效果。
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
the lifecycle.
很好的质量。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年敏捷调查，也发现了人们普遍详细敏捷比传统团队生产出更高质量的产品，提供的产品涉众（需求放）更满意，提供更高的生产率。
| 
