during的用法
augest此文档由赛柏科技高级咨询顾问许娓翻译
(p.IV) Informative material was improved, including revising the engineering practices to reflect industry best practice and adding guidance for organizations that u Agile methods.
改进了提供信息的材料，这些改进包括参考行业的最佳实践修改了工程的实践，还为实施敏捷方法的组织提供了指南。
(p.58. Interpreting CMMI When Using Agile Approaches)
CMMI practices are designed to provide value across a range of different situations and thus are stated in general terms. Becau CMMI does not endor any particular approach to development, little information that is approach-specific is provided. Therefore, tho who don’t have prior experience implementing CMMI in situations similar to the one they are now in may find interpretation non-intuitive.
CMMI 实践的设计是为了提供跨越多种情况的价值，CMMI是用一些通用的术语来陈述的。CMMI并不支持任何特定的方法来开发，很少提供与特定方法有关的信息。因此，如果没有与当前情况类似的环境中实施过CMMI的经验，可能认为模型的解释并不直观。
university of virginiaTo help tho who u Agile methods to interpret CMMI practices in their environments, notes have be
en added to lected process areas. The notes are added, usually in the introductory notes, to the following process areas in CMMI-DEV: CM, PI, PMC, PP, PPQA, RD, REQM, RSKM, TS, and VER.
为了帮助使用敏捷方法的人们在他们的环境中解释CMMI的实践，在CMMI DEV v1.3 中，选择了CM，PI，PP，PPQA，RD，REQM，RSKM，TS & VER 等九个过程域增加了有关敏捷方法的注解，这些注解通常增加在过程域的引论性注解部分。
All of the notes begin with the words, “In Agile environments” and are in example boxes to help you to easily recognize them and remind you that the notes are examples of how to interpret practices and therefore are neither necessary nor sufficient for implementing the process area. Multiple Agile approaches exist. The phras “Agile environment” and “Agile method” are shorthand for any development or management approach that adheres to the Manifesto for Agile Development [Beck 2001].
王道是什么意思所有的注解都以“在敏捷环境中”开头，用示例框的形式出现，以便于帮助你快速的找到他们，并且提醒你这些注解只是如何解释实践的例子，因此它们既不是实施过程域所必需的也不是充分的。业内存在多种敏捷方法，短语“敏捷环境”和“敏捷方法”代表任何符合敏捷开发宣言的开发和管理方法[Beck 2001]
Such approaches are characterized by the following:
·Direct involvement of the customer in product development
·U of multiple development iterations to learn about and evolve the product ·Customer willingness to share in the responsibility for decisions and risk
敏捷方法有以下几点来刻画：
邀请客户直接参与产品开发
利用多次开发迭代，来理解产品和演化产品
客户愿意共同担当决策和风险的职责
Many development and management approaches can share one or more of the characteristics and yet not be called “Agile.” For example, some teams are arguably “Agile” even though the term Agile is not ud. Even if you are not using an Agile approach, you might still find value in the notes.
虽然很多开发和管理方法没有叫做敏捷方法，但他们也具有这些敏捷特征中的一个或多个特征。比如，尽管有些团队不使用敏捷术语，但可以说是“敏捷”。即便你没有使用敏捷方法，你仍然会发现这些注解的价值。
Be cautious when using the notes. Your ultimate interpretation of the process area should fit the specifics of your situation, including your organization’s business, project, work group, or team objectives, while fully meeting a CMMI process area’s goals and practices. As mentioned earlier, the notes should be taken as examples and are neither necessary nor sufficient to implementing the process area.
forgive的名词
当使用这些注解时，一定要谨慎。对过程域的最终解释应该符合你的特定情况，包括组织的商业目标以及项目、工作组或团队的目标和场景，同时充分满足CMMI过程域的目标和实践。之前已经提到过，注解应该只是例子，而不是实施过程域必需的也不是充分的。
Some general background and motivation for the guidance given on Agile development approaches are found in the SEI technical note CMMI or Agile: Why Not Embrace Both! [Glazer 2008].
关于提供敏捷开发方法指南的背景和动机，可以查阅SEI的技术报告“CMMI or Agile: Why Not Embrace Both”
1.(p.139, CM)
In Agile environments, configuration management (CM) is important becau of the need to support frequent change, frequent builds (typically daily), multiple balines, and multiple CM supported workspaces (e.g., for individuals, teams, and even for
pair-programming). Agile teams may get bogged down if the organization doesn’t: 1) automate CM (e.g., build scripts, status accounting, integrity checking) and 2) implement CM as a single t of standard rvices. At its start, an Agile team should identify the individual who will be responsible to ensure CM is implemented correctly. At the start of each iteration, CM support needs are re-confirmed. CM is carefully integrated into the rhythms of each team with a focus on minimizing team distraction to get the job done. (See “Interpreting CMMI When Using Agile Approaches” in Part I.)
在敏捷环境中，配置管理非常重要，因为需要支持频繁变更，频繁的构建（通常每天），多基线管理和多工作区管理（例如，个人工作区，团队工作区，甚至是结对编程工作区。一个敏捷的团队可能陷入困境，如果这个组织没有：1）自动的配置管理（例如，构建脚本、状态记录，完整性检查），2）将配置管理作为单
独的一套标准服务加以执行。一个敏捷团队一成立，就应该确定配置管理的负责人来确保配置管理活
甄嬛传英文
动的正确执行。在每个迭代开始，对配置管理应提供的支持重新确认。配置管理被小心的集成到各小组的工作节奏中，尽量避免分散各小组的注意力，以便使工作完成。（参见模型第一部分的“用敏捷方法解释CMMI 模型”）
2.(p.258, PI)
In Agile environments, product integration is a frequent, often daily, activity. For example, for software, working code is continuously added to the code ba in a process called ―continuous integration.In addition to addressing continuous integration, the product integration strategy can address how supplier supplied components will be incorporated, how functionality will be built (in layers vs. ―vertical slices), and when to ―refactor. The strategy should be established early in the project and be revid to reflect evolving and emerging component interfaces, external feeds, data exchange, and application program interfaces. (See ―Interpreting CMMI When Using Agile Approaches in Part I.)
在敏捷环境中，产品集成是频繁的活动，通常每天都要集成。例如，对于软件，使用持续集成的过程将工作的代码持续的添加到代码基准中。除了考虑持续集成，产品集成策略还需要考虑供应商提供的构件如何整合，功能如何构建（分层的或垂直的），以及什么时候重构。集成策略应该在项目的早期
稀罕的近义词是什么确定，并且不断修订，以反映不断演化的和出现的构件接口，外部输入，数据交换和应用程序界面等。（参见模型第一部分的“用敏捷方法解释CMMI模型”）
3.(p.278, PMC)
In Agile environments, the sustained involvement of customer and potential end urs in the project’s product development activities can be crucial to project success; thus, customer and end-ur involvement in project activities should be monitored. (See “Interpreting CMMI When Using Agile Approaches” in Part I.)
在敏捷的环境中，客户和潜在终端用户对项目产品开发活动的持续参与对项目的成功是至关重要的，因此，应当对客户和终端用户对项目活动的参与进行监测。（参见“用敏捷方法解释CMMI模型“的第一部分）
4.(p.282, PP)
For product lines, there are multiple ts of work activities that would benefit from the practices of this process area. The work activities include the creation and maintenance of the core asts, developing products to be built using the core asts, and orchestrating the overall product line effort
to support and coordinate the operations of the inter-related work groups and their activities. In Agile environments, performing incremental development involves planning, monitoring, controlling, and re-planning more frequently than in more traditional development environments. While a high-level plan for the overall project or work effort is typically established, teams will estimate, plan, and carry out the actual work an increment or iteration at a time. Teams typically do not forecast beyond what is known about the project or
punch line
iteration, except for anticipating risks, major events, and large-scale influences and constraints. Estimates reflect iteration and team specific factors that influence the time, effort, resources, and risks to accomplish the iteration. Teams plan, monitor, and adjust plans during each iteration as often as it takes (e.g., daily). Commitments to plans are demonstrated when tasks are assigned and accepted during iteration planning, ur stories are elaborated or estimated, and iterations are populated with tasks from a maintained backlog of work. (See “Interpreting CMMI When Using Agile Approaches” in Part I.)
对于产品线，有多系列工作活动将受益于这个过程域的实践。这些工作活动包括建立和维护核心资产，并用核心资产来构建要开发产品，以及编排整个生产线的工作量，支持并协调相互关联的工作组的作业及其活动。在敏捷的环境中，执行增量开发涉及到比传统的开发环境更加频繁的策划、监督、
控制和重策划。在建立一个典型的针对整个项目和工作的高层次计划的同时，团队还会在每个增量或者迭代时，估计、计划、并实施实际工作。除了预测风险、主要事件、大规模影响和制约因素以外，团队一般不对项目或迭代未知的部分做出预测。估计反映了影响迭代完成的时间，工作量，资源和风险的具体因素。在每个迭代中，只要需要时，团队都会计划、监控和调整计划（通常每天）。对计划的承诺表现为迭代计划期间，对任务进行了分配和接受，对用户故事进行阐述和估计，以及从一个被维护的工作列表中选择进入到迭代中的任务。（参见“用敏捷方法解释CMMI 模型“的第一部分）
5.(p.303, PPQA)
In Agile environments, teams tend to focus on immediate needs of the iteration rather than on longer term and broader organizational needs. To ensure that objective evaluations are perceived to have value and are efficient, discuss the following early: (1) how objective evaluations are to be done, (2) which process and work products will be evaluated, (3) how results of evaluations will be integrated into the team’s rhythms (e.g., as part of daily meetings, checklists, peer reviews, tools, continuous integration, retrospectives). (See “Interpreting CMMI When Using Agile Approaches” in Part I.)
在敏捷的环境中，团队往往倾向于把重点放在迭代的迫切需要，而不是长期和更广泛的组织需要。为
确保客观的评价具有价值和效率，应尽早的讨论以下几点：（1）客观的评价将如何进行，（2）哪些工作流程和产品将被评价，（3）评价结果将如何融入团队的节奏（例如，作为每天会议的一部分、检查单、同行评审、工具、持续集成、回顾展）。（参见“用敏捷方法解释CMMI模型“的第一部分）
6.(p.327, RD)longtimenoe
In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated. Requirements are documented in forms such as ur stories, scenarios, u cas, product backlogs, and the results of iterations (working code in
the ca of software). Which requirements will be addresd in a given iteration is driven by an asssment of risk and by the priorities associated with what is left on the product backlog. What details of requirements (and other artifacts) to document is driven by the need for coordination (among team members, teams, and later iterations) and the risk of losing what was learned. When the customer is on the team, there can still be a need for parate customer and product documentation to allow multiple solutions to be explored. As the solution emerges, responsibilities for derived requirements are allocated to the appropriate teams. (See “Interpreting CMMI When Using Agile Approaches” in Part I.)
在敏捷的环境，客户的需要和想法被迭代的导出、阐述、分析和确认。需求用以下的形式文档化：用户故事、场景、用例、特性列表和迭代的结果（软件体现为工作代码）。哪些需求将纳入一个既定的迭代是由风险评估和特性列表中未处理项的优先级所决定的。需求（和其它制品）文档化的详细程度取决于协调的需要（团队成员之间、小组之间及后来的迭代之间）和识别到的风险。当顾客参与敏捷团队时，需要区分顾客文档和产品文档，以允许探讨多个解决方案。随着解决方案出现，派生需求的职责分配给了合适的小组。（参见“用敏捷方法解释CMMI 模型“的第一部分）
7.(p.342, REQM)
In Agile environments, requirements are communicated and tracked through mechanisms such as product backlogs, story cards, and screen mock-ups. Commitments to requirements are either made collectively by the team or an empowered team leader. Work assignments are regularly (e.g., daily, weekly) adjusted bad on progress made and as an improved understanding of the requirements and solution emerge. Traceability and consistency across requirements and work products is addresd through the mechanisms already mentioned as well as during
start-of-iteration or end-of-iteration activities such as “retrospectives” and “demo days.” (See “Interpreting CMMI When Using Agile Approaches” in Part I.)
在敏捷的环境中，需求通过诸如特性列表、故事卡片、屏幕实物模型之类的机制被交流和跟踪。团队集体做出需求的承诺或由授权的小组组长做出需求的承诺。基于项目已取得的进展，以及对需求和解决方案的进一步理解，工作分配会定期进行调整（每天、每周）
。工作产品和需求之间的跟踪性和一致性通过已经提到的机制，以及迭代启动或迭代结束时的活动来解决的，如“回顾展“和“演示日”。（参见“用敏捷方法解释CMMI模型“的第一部分）
8.(p.350, RSKM)白萝卜的英文
In Agile environments, some risk management activities are inherently embedded in the Agile method ud. For example, some technical risks can be addresd by encouraging experimentation (early “failures”) or by executing a “spike” outside of the routine iteration. However, the Risk Management process area encourages a more systematic approach to managing risks, both technical and non-technical. Such an approach can be integrated into Agile’s typical iteration and meeting rhythms; more
