日报写作规范_写作验收标准的验收标准

最新推荐文章于 2022-01-11 15:23:41 发布

cumian9828

最新推荐文章于 2022-01-11 15:23:41 发布

阅读量513

点赞数

文章标签： java 人工智能大数据 python 编程语言

原文链接：https://www.freecodecamp.org/news/the-acceptance-criteria-for-writing-acceptance-criteria-6eae9d497814/

版权

日报写作规范

by Elijah Valenciano

通过伊莱贾·瓦伦西亚诺

写作验收标准的验收标准 (The Acceptance Criteria for Writing Acceptance Criteria)

Many development teams are too familiar with the frustrations of unsatisfactory acceptance criteria or even the lack of criteria itself. Defining no requirements is like preparing for battle without a plan of action — the team has taken more steps toward failure than success. I offer specific suggestions in crafting acceptance criteria that can improve any agile process.

许多开发团队对不满意的接受标准甚至缺乏标准本身的挫败感太熟悉了。定义任何要求就像在没有行动计划的情况下为战斗做准备—团队为失败而不是成功采取了更多步骤。我在制定可以改善任何敏捷过程的接受标准时提供了具体建议。

First, let’s quickly define acceptance criteria.

首先，让我们快速定义验收标准。

Acceptance criteria are the “conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.” (Microsoft Press)

接受标准是“软件产品必须满足的条件才能被用户，客户或其他利益相关者接受。” (微软出版社)

Easy enough, right? Not quite. At this point, I would ask myself if this is where my definition of acceptance criteria stops. In addition to the definition above, any product owner should have answers ready for the following questions:

很容易，对吧？不完全的。在这一点上，我想问自己，这是否是我接受标准定义的终点。除了上面的定义外，任何产品所有者都应该为以下问题准备好答案：

What do these conditions look like? Who creates these conditions? How many conditions should there be? How are outcomes measured?

这些条件是什么样的？谁创造这些条件？应该有多少条件？如何衡量结果？

Generally, acceptance criteria are initiated by the product owner or stakeholder. They are written prior to any development of the feature. Their role is to provide guidelines for a business or user-centered perspective.

通常，验收标准是由产品所有者或利益相关者发起的。它们是在对该功能进行任何开发之前编写的。他们的作用是为业务或以用户为中心的观点提供指导。

However, writing the criteria is not solely the responsibility of the product owner. Acceptance criteria should be developed as a joint effort between the development team and the product owner.

但是，编写标准并不仅仅是产品所有者的责任。 开发团队和产品所有者之间应共同制定验收标准。

Crafting these criteria together helps the development team understand the desire featured. It also helps the product owner catch missing details. Additionally, the owner gains a better understanding of feasibility, complexity, and scope.

一起制定这些标准可帮助开发团队了解其需求。它还可以帮助产品所有者捕获丢失的详细信息。此外，所有者还可以更好地了解可行性，复杂性和范围。

格式化验收标准 (Formatting acceptance criteria)

Criteria can be written in a variety of formats. Most teams lean towards two specific types: rule-oriented or scenario-oriented.

标准可以以多种格式编写。大多数团队倾向于两种特定类型： 面向规则或面向场景。

Rule-oriented requirements are straight-forward. They list out observable outcomes. “Display statement balance upon successful authentication.”

面向规则的要求很简单。他们列出了可观察到的结果。 “成功通过身份验证后，显示语句将保持平衡。”

On the other hand, scenario-oriented criteria tend to follow the “Given…When…Then…” template. This was derived from behavior-driven-development (BDD). This requirement outlines the expected observable result. This occurs when a particular action is executed given some context.

另一方面，面向场景的标准倾向于遵循“给出……何时……然后……”模板。这源自行为驱动开发(BDD)。该要求概述了预期的可观察结果。在给定上下文的情况下执行特定操作时，会发生这种情况。

有效验收标准的3个特征 (3 characteristics of effective acceptance criteria)

1.可通过明确定义的通过/失败结果进行测试 (1. Testable with clearly defined pass/fail results)

Have testable criteria. This allows testers to properly confirm that all of the desired conditions have been fulfilled. If criteria were not testable, then there would be no way for verification. These criteria should either be met or not met. A developer should know the point in which the criterion has been achieved. Any ambiguity may prolong effort on the story.

有可测试的标准。这使测试人员可以正确确认是否已满足所有所需条件。如果标准不可测试，则将无法进行验证。这些条件应该满足或不满足。开发人员应该知道达到标准的地方。任何歧义可能会延长故事的工作量。

For example, an acceptance criterion states “increase the number of entries available in a drop-down menu”. The developer would have no idea how many new entries to add and may take the liberty to assume a number based on his experience with the product. Likewise, a manual tester may take the same liberty and assume a different definition of increase. This results in a confusion that will circle back to the product owner.

例如，接受标准指出“增加下拉菜单中可用条目的数量”。开发人员将不知道要添加多少个新条目，并且可能会根据他在产品上的经验而随意采用一个数字。同样，手动测试人员可以享有相同的自由，并假定增加的定义不同。这导致混乱，并会转回产品所有者。

2.简洁明了 (2. Unambiguous and concise)

This is where writing acceptance criteria become an art. Academic essays stress the importance of clarity and succinctness. Similarly, writing acceptance criteria mandates the same level of organization and care.

这就是写作接受标准成为一门艺术的地方。学术论文强调清晰和简洁的重要性。同样，编写接受标准要求组织和护理具有相同水平。

Similar to writing a literary piece, the audience must be kept in mind. Those reading the acceptance criteria must understand what is written. Otherwise, those words are completely useless. If they are long-winded and filled with jargon, then the main points of the outlined conditions may not come across. Many people can overlook essential details in a sea of words when pressed for time. Even when not pressed for time, many people can easily gloss over long blurbs.

与撰写文学作品相似，必须牢记观众。那些阅读接受标准的人必须理解所写内容。否则，这些话是完全没有用的。如果他们long不休，充满术语，那么可能不会遇到概述条件的要点。时间紧迫，许多人可能会无话可说。即使没有紧迫的时间，许多人也可以轻松遮盖长时间的模糊效果。

Instead of putting the blame on others’ lack of careful reading, one can proactively present acceptance criteria that are easy to read, straight to the point, and devoid of superfluous details.

与其将责任归咎于他人缺乏仔细的阅读，不如说可以主动提出易于阅读，直截了当且没有多余细节的验收标准。

3.建立共识 (3. Establish shared understanding)

This is probably the most important characteristic and the one most taken for granted. If all the members of the team are not on the same page, then process and productivity become jeopardized. Having the development team review acceptance criteria before moving forward with the story minimizes confusion. Clarifications should be made about the criteria, and the criteria should be updated accordingly.

这可能是最重要的特征，也是最理所当然的特征。如果团队的所有成员不在同一页面上，则过程和生产率将受到损害。让开发团队先审查验收标准，然后再继续讲故事，以最大程度地减少混乱。应澄清标准，并相应地更新标准。

I’ve had experiences where all team members have been part of writing acceptance criteria. It allowed everyone to understand all parts of the story. It also provided opportunities for team members to chime in with questions and ideas. However, such a process might not always be ideal, especially for larger teams.

我曾经有过所有团队成员都参与编写验收标准的经历。它使每个人都可以理解故事的各个部分。它还为团队成员提供了提出问题和想法的机会。但是，这样的过程可能并不总是理想的，特别是对于较大的团队。

Nevertheless, it is important that each member can read the acceptance criteria. From there each member should gain an understanding of how to bring the story into completion. Regardless of whether it be in development or testing.

但是，重要的是每个成员都必须阅读接受标准。从那里，每个成员都应该了解如何使故事完成。无论是在开发还是测试中。

当太多的问题 (When too much is an issue)

We’ve already explored the danger of unclear acceptance criteria. This results in the risk of introducing extraneous features into a story. However, the surprising opposite case can also exist: acceptance criteria may become too detailed.

我们已经探讨了接受标准不明确的危险。这导致在故事中引入无关功能的风险。但是，也可能存在令人惊讶的相反情况：接受标准可能变得过于详细。

“Acceptance Criteria should state intent, not a solution” (Segue Technologies)

“接受标准应说明意图，而不是解决方案”( Segue Technologies )

Provide a blueprint of “what” (intention) instead of “how” (implementation). Otherwise, the development team may be robbed of the opportunity to explore different ways to solve the problem. On those lines, better implementations may be thought up after the initial thoughts on a solution.

提供“什么”(意图)而不是“如何”(实现)的蓝图。否则，开发团队可能会失去探索各种解决问题方法的机会。按照这些思路，在对解决方案进行初步思考之后，可能会考虑更好的实现。

Once you’ve written your acceptance criteria, you may ask yourself, “How many is too many?”I’ve seen stories that range from zero acceptance criteria to more than fifteen (or at least it felt like that).

写下接受标准后，您可能会问自己：“多少是太多？” 我见过的故事范围从零接受标准到超过15个(或至少感觉像这样)。

As a rule of thumb, I personally like to see three to eight acceptance criteria per story. However, towards the upper end of that limit, around five or more acceptance criteria, I would check manageability. I would carefully check to see that the story couldn’t be broken up into smaller, more manageable stories.

根据经验，我个人希望每个故事看到三到八个接受标准。但是，在达到该上限的上限附近，我将检查五个或多个接受标准。我会仔细检查，以确保无法将故事分解成更小，更易于管理的故事。

Others would disagree and argue that eight would already be too many. However, I like to lean towards providing as much “what” detail as I can without sacrificing conciseness.

其他人则不同意并认为八个已经太多了。但是，我倾向于在不牺牲简洁性的前提下，尽可能多地提供“什么”细节。

怎么办？ (Now what?)

Ok, I lied. I did not provide an exhaustive list of acceptance criteria for writing acceptance criteria. The desired characteristics such as conciseness, clarity, and comprehension are subjective. I intended them to be.

好的，我撒谎了。 我没有提供详尽的验收标准清单来编写验收标准。诸如简洁，清晰和理解之类的期望特性是主观的。我希望他们成为。

I believe that there is no “correct” format to writing acceptance criteria. Their correctness is measured by the effectiveness in one’s team.

我相信没有任何“正确”的格式来编写接受标准。 他们的正确性由团队的有效性来衡量。

I highly recommend on initially using a template. They have provided many teams with a solid and safe structure that promotes good acceptance criteria writing. However, do not let that structure stop you from advancing into ideas that may promote efficiency and efficacy.

我强烈建议您最初使用模板。他们为许多团队提供了牢固而安全的结构，从而促进了良好的验收标准编写。但是，不要让这种结构阻止您前进可能会提高效率和功效的想法。

If you are a product owner or client writing acceptance criteria, I challenge you to ask your development team for feedback on the current acceptance criteria. With a bit of care, practice, and organization, crafting effective acceptance criteria becomes a powerful tool in improving the workflow of any team.

如果您是产品所有者或客户，编写接受标准，我会挑战您要求开发团队提供有关当前接受标准的反馈。通过一点点的关心，实践和组织，制定有效的接受标准成为改善任何团队工作流程的有力工具。