通过实例规范：成功团队如何交付正确的软件

5星 · 超过95%的资源需积分: 21 2 浏览量更新于2024-07-31 3 收藏 12.78MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"Specification by Example - 如何成功的团队交付正确的软件" 《Specification by Example》是Gojko Adzic撰写的一本关于如何通过实例规范来成功交付正确软件的书籍。这本书详细介绍了如何通过实际示例来创建软件，以弥合业务利益相关者与构建软件的开发团队之间的沟通鸿沟。在书中，作者Gojko Adzic基于对全球成功团队的访谈，分享了他们在短迭代周期内无缺陷地指定、开发和交付软件的方法。本书涉及的技术，即实例规范，是一种协作性的需求规格和测试方法。书中深入探讨了七个关键模式，这些模式对于使这种方法有效至关重要。实例规范有四个主要优点：它生成活的、可靠的文档；清晰定义期望并使验证高效；减少返工；最重要的是，它确保交付团队和业务利益相关者确信构建的软件符合其目的。书中的内容涵盖了常见的过程模式，如何避免不良实践，如何将实例规范融入你的流程，以及超过50个案例研究，涵盖了从小型网络初创公司到大型金融机构的各种项目，它们在XP、Scrum和Kanban等不同过程中工作。这本书面向共同构建优秀软件的开发者、测试人员、分析师和业务人员。无论是希望改进现有流程的项目经理，还是寻求更高效协作方式的团队成员，都可以从书中获得有价值的洞察和实践指导。书中详细讨论了以下主题： 1. 实例规范的基本原理和实施步骤。 2. 如何通过实际示例来明确需求和预期，减少误解。 3. 实施实例规范时的常见陷阱和如何避免它们。 4. 在敏捷开发框架（如XP、Scrum、Kanban）中整合实例规范的方法。 5. 案例研究展示了不同规模和行业的项目如何成功应用实例规范。 6. 如何利用实例规范创建持续更新的文档，以保持与软件开发同步。 7. 整合业务需求和开发活动的最佳实践。 8. 通过实例规范提高软件验证效率和质量。《Specification by Example》提供了实用的工具和策略，帮助团队更好地理解业务需求，改进沟通，确保软件开发与业务目标保持一致，从而实现高质量、低风险的交付。

资源详情

资源推荐

There are no best practices in software, but there are deﬁnitely good ideas that we

can try to apply in different contexts. You will ﬁnd thumbs-up and thumbs-down icons

next to the sections in part 2, indicating practices that several teams from the survey

found useful or issues they commonly faced. Treat these as suggestions to try out or

avoid, not as prescriptions for something that you must follow. Arrow icons point to

particularly important ideas for each practice.

Software development isn’t static—teams and environments change and the process

must follow. I present case studies showing the journeys of a few selected teams in part

3. I write about their processes, constraints, and contexts, analyzing how the processes

evolved. These stories will help you get started with your journey or take the next step,

ﬁnd ideas, and discover new ways of doing things.

In the ﬁnal chapter of the book, I summarize the key things I’ve learned from the

case studies leading to this book.

Beyond the basics

On the traditional

Shu-ha-ri

learning model, this book is at the

level.

is about

breaking the old rules and showing that there are many successful models. In my book

Bridging the Communication Gap

, I presented my model and my experience. In this

book, I try hard not to be inﬂuenced by my background. I present things from the proj-

ects I worked on only when there’s an important point to make and I don’t think any

of the teams featured in the book had a similar situation. In that sense,

Speciﬁcation by

Example

continues where

Bridging the Communication Gap

stopped.

I introduce the basic principles brieﬂy in chapter 2. Even if you’ve never heard of

any of these ideas before, this should give you enough information to understand the

rest of the book, but I won’t go into the basics too much. I wrote about the basics of

Speciﬁcation by Example at length in

Bridging the Communication Gap

and have no

wish to repeat myself.

If you want to go over the basics in more detail, visit

http://speciﬁcationbyexample.

com

, register a copy of this book, and you’ll get the PDF of

Bridging the Communication

Gap

free.

I don’t think that I’ll write a follow-up on this subject on the

level—because that

level is beyond books. On the other hand, I believe that this book will help you move

to that level. Once you start thinking that the choice of a particular tool is irrelevant,

you are there.

Shu-ha-ri is a learning model associated with Aikido. It roughly translates to “obey-detach-

leave.” At the ﬁrst level (Shu - “obey”), a student learns by closely following one model. At

the second level (Ha - “detach”), the student learns that there are multiple models and solu-

tions. At the third level (Ri - “leave”), the student goes beyond following models.

xvi

xvii

This book has no source code and doesn’t explain any tools

This book has no source code or instructions on how

to work with a particular tool. I feel compelled to men-

tion this upfront, because I had to explain it already

several times during the publishing process (typically as

an answer to the question, “What do you mean? A soft-

ware development book without source code? How’s

that possible?”).

The principles and practices of Speciﬁcation by Example primarily

affect how people communicate in software delivery teams and how they

collaborate with business users and stakeholders. I’m sure that many

tool vendors will try to sell you a technical solution for that. There are also many

managers who would be happy to pay for their problem to go away instantly. Unfortu-

nately for them, this is mostly a people problem, not a technical one.

Bill Gates said, “The ﬁrst rule of any technology used in a business is that automa-

tion applied to an efﬁcient operation will magnify the efﬁciency. The second is that au-

tomation applied to an inefﬁcient operation will magnify the inefﬁciency.” Many teams

who failed with Speciﬁcation by Example have magniﬁed their process inefﬁciency by

automating it. Instead of focusing on a particular tool, I want to address the real reasons

why teams struggle to implement these ideas. Once you get the communication and

collaboration right, you’ll be able to choose the right tool to ﬁt it. If you want to know

more about tools that support speciﬁcation by example after reading this book, go to

http://speciﬁcationbyexample.com and check out the resources section.

A few words on the terminology

If this is your ﬁrst contact with Speciﬁcation by Example, Acceptance Test-Driven De-

velopment, agile acceptance testing, Behavior-Driven Development, or any of the other

names people use for this set of practices, you’ve avoided years of confusion caused by

misleading names. You should feel good about that, and you may skip this part of the

introduction. If you have already come into contact with any of those ideas, the names I

use in this book might surprise you. Read on to understand why I use those names and

why you should start using them as well.

While writing this book, I had the same problem practitioners often have when writ-

ing our automated speciﬁcations. The terminology has to be consistent to make sense,

but we don’t necessarily see that until we write things down. Because this book is the

result of a series of interviews, and many people I spoke to used different names for the

same thing, it was quite hard to make the story consistent with all the different names.

I realized that the practitioners of Speciﬁcation by Example, myself included, have

traditionally been guilty of using technical terms to confuse both ourselves and everyone

else who tries to implement these practices. Then I decided that one of my goals with

this book would be to change the terminology in the community. If we want to get busi-

ness users more involved, which is one of the key goals of these practices, we have to use

the right names for the right things and stop confusing people.

This lesson is obvious when we write our speciﬁcations, and we know that we need

to keep the naming consistent and avoid misleading terms. But we don’t do this when

we talk about the process. For example, when we say

continuous integration

in the con-

text of Speciﬁcation by Example, we don’t really mean running integration tests. So why

use that term and then have to explain how acceptance tests are different from integra-

tion tests? Until I started using

speciﬁcation workshop

as the name for a collaborative

meeting about acceptance tests, it was difﬁcult to convince business users to participate.

But a simple change in naming made the problem go away. By using better names, we

can avoid many completely meaningless discussions and get people started on the right

path straightaway.

Why Speciﬁcation by Example?

I ﬁrst want to explain why I chose Speciﬁcation by Example as the overall name for the

whole set of practices, as opposed to agile acceptance testing, Behavior-Driven Develop-

ment, or Acceptance Test-Driven Development.

During the Domain Driven Design eXchange 2010 conference

in London, Eric

Evans argued that

agile

as a term has lost all meaning because anything can be called

agile now. Unfortunately, he’s right. I’ve seen too many teams who tried to implement

a process that was obviously broken but slapped the name

agile

on it as if that would

magically make it better. This is in spite of a huge body of available literature on how to

properly implement XP, Scrum, and other less-popular agile processes.

To get around this meaningless ambiguity and arguing whether agile works or not

(and what it is), I avoid using the term

agile

in this book as much as I can. I use it only

when referring to teams that started implementing well-deﬁned processes built on the

principles outlined in the Agile Manifesto. So without being able to mention agile in

every second sentence, agile acceptance testing as a name is out of the question.

The practices described here don’t form a fully ﬂedged software development meth-

odology. They supplement other methodologies—both iteration and ﬂow based—to

provide rigor in speciﬁcations and testing, enhance communication between various

stakeholders and members of software development teams, reduce unnecessary rework,

and facilitate change. So I don’t want to use any of the “Driven Development” names.

Especially not Behavior-Driven Development (BDD). Don’t take this as a sign that I

http://skillsmatter.com/event/design-architecture/ddd-exchange-2010

xviii

have anything against BDD. Quite the contrary, I love BDD and consider most of what

this book is about actually a central part of BDD. But BDD suffers from the naming

problem as well.

What BDD actually means changes all the time. Dan North, the central authority

on what BDD is and what it is not, said that BDD is a

methodology

at the Agile Speciﬁ-

cations, BDD, and Testing Exchange 2009.

(Actually he called it “a second-generation,

outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile

methodology.”) To avoid any confusion and ambiguity between what North calls BDD

and what I consider BDD, I don’t want to use that name. This book is about a precise

set of practices, which you can use within a range of methodologies, BDD included (if

you accept that BDD is a methodology).

I also want to avoid using the word

test

too much. Many managers and business us-

ers unfortunately consider testing as a technical supplementary activity, not something

that they want to get involved in. After all, they have dedicated testers to handle that.

Speciﬁcation by Example requires an active participation of stakeholders and delivery

team members, including developers, testers, and analysts. Without putting

tests

in the

title, story testing, agile acceptance testing, and similar names are out.

This leaves Speciﬁcation by Example as the most meaningful name with the least

amount of negative baggage.

Process patterns

Speciﬁcation by Example consists of several process patterns, elements of the wider soft-

ware development life cycle. The names I use for process patterns in this book are a

result of several discussions at the UK Agile Testing user group meetings, Agile Alliance

Functional Testing Tools mailing list, and workshops. Some of them have been in use

for a while; some of them will be new to most readers.

A popular approach in the community is to use the name of a practice or tool to

describe a part of the process. Feature Injection is a good example—it’s a popular name

for extracting the scope of a project from the business goals. But Feature Injection is

just one technique to do that, and there are alternative ways to achieve the same goal. In

order to talk about what different teams do in different contexts, we need a higher-level

concept that includes all those practices. A good name describes the expected outcome

and clearly points to the key differentiating element of this set of practices.

In the case of Feature Injection and similar practices, the outcome is a scope for a

project or a milestone. The key differentiator from the other ways of deﬁning the scope

is that we focus on the business goals. So I propose that we talk about

deriving scope

from goals

http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

xix

One of the biggest issues teams have with Speciﬁcation by Example is who should

write what and when. So we need a good name that clearly says that everyone should be

involved (and that this needs to happen before the team starts programming or testing),

because we want to use acceptance tests as a target for development.

Test ﬁrst

is a good

technical name for it, but business users don’t get it, and it doesn’t imply collaboration.

I propose we talk about

specifying collaboratively

instead of test ﬁrst or writing accep-

tancIt sounds quite normal to put every single numerical possibility into an automated

functional test. Why wouldn’t we do it if it’s automated? But such complex tests are

unusable as a communication tool, and in Speciﬁcation by Example we need to use tests

for communication. So instead of writing functional tests, let’s talk about

illustrating

using examples

and expect the output of that to be

key examples

to point out that we want

only enough to explain the context properly.

Key examples are raw material, but if we just talk about acceptance testing then

why not just dump complicated 50-column, 100-row tables with examples into an

acceptance test without any explanation? It’s going to be tested by a machine anyway.

With Speciﬁcation by Example, the tests are for humans as well as for machines. We

need to make it clear that there’s a step after illustrating using examples, where we ex-

tract the minimal set of attributes and examples to specify a business rule, add a title and

description, and so on. I propose we call this step

reﬁning the speciﬁcation

The result of this reﬁnement is at the same time a speciﬁcation, a target for develop-

ment, an objective way to check acceptance, and a functional regression test for later.

I don’t want to call this an acceptance test because it makes it difﬁcult to justify why

this document needs to stay in domain language, be readable, and be easily accessible.

I propose we call the result of reﬁning a

speciﬁcation with examples

, which immediately

points to the fact that it needs to be based on examples but also contain more than just

raw data. Calling this artifact a speciﬁcation makes it obvious that everyone should care

about it and that it needs to be easy to understand. Apart from that, there’s a completely

different argument as to whether these checks are there to automatically accept software

or to automatically reject the code that doesn’t satisfy what we need.

I just don’t want to spend any more time arguing with people who’ve already paid

a license for QTP that it’s completely unusable for acceptance tests. As long as we talk

about test automation, there’s always going to be a push to use whatever horrible con-

traption testers already use for automation, because it’s logical to managers that their

teams use a single tool for test automation. Agile acceptance testing and BDD tools

don’t compete with QTP or tools like that; they address a completely different problem.

Thanks to David Evans who suggested this.

Thanks to Elisabeth Hendrickson who suggested this name.

http://www.developsense.com/blog/2010/08/acceptance-tests-lets-change-the-title-too

剩余294页未读，继续阅读

curfeu

粉丝: 4
资源: 21

通过实例规范：成功团队如何交付正确的软件

Specification by Example.pdf

specification by example: how successful teams deliver the right software

write test case creation conclusion

app designer

confluence json

group linux

server: port: 9999 servlet: context-path: /teams spring: http: encoding: force: true charset: UTF-8 enabled: true mvc: static-path-pattern: /** devtools: restart: enabled: true #设置开启热部署 a

系统测试参考文献有哪些

Please write a cover letter for me to Abb Company

python系统需求规格说明书参考文献

netcore ddd

entity model designer

2018.04-2019.09 比亚迪股份有限公司 规划院 HC车型EMS主管英文翻译

给出分别利用16支球队的分数在淘汰赛中取得冠军次数matlab代码

已知16支球队的100场数据，请使用BP神经网络分别给出16支球队在淘汰赛中预测取得冠军的概率matlab代码

ubuntu安装teams

最新资源

2018.04-2019.09 比亚迪股份有限公司规划院 HC车型EMS主管英文翻译