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 比较敏捷和传统的方法

　　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?

　　我找到的识别一个团队是否按照严格的方法去做敏捷开发的标准，首先团队是不是做到了开发者回归测试或者执行了更好的测试驱动开发方法？第二，利益相关者是不是参与到开发活动中（也就是用户是不是参与了需求），第三，团队生产高质量和可工作的软件是不是常态化（大概意思是常态发布），第四，团队是不是在有效的管理框架下高度协作和自我组织的工作？ 第五，他们是不是在项目中改进他们的方法？

　　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

　　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

　　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

　　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年敏捷调查，也发现了人们普遍详细敏捷比传统团队生产出更高质量的产品，提供的产品涉众（需求放）更满意，提供更高的生产率。