实例化需求：打造正确软件的成功团队实践

需积分: 10 148 浏览量更新于2024-07-17 1 收藏 17.58MB PDF 举报

"实例化需求团队如何交付正确的软件_英文版" 实例化需求（Specification by Example）是一种高效的需求定义和管理方法，旨在帮助软件团队更准确地理解并传达用户需求，从而确保开发出的产品能够满足预期。这种方法的核心理念是通过具体的例子来说明需求，而不是仅仅依赖于抽象的文字描述。这样可以减少误解，提高沟通效率，并降低软件的缺陷率。 Gojko Adzic 的《Specification by Example》一书深入探讨了这一主题，书中介绍了一系列团队在短时间内定义需求、开发软件并成功交付高质量产品的实践案例。这些团队使用实例化需求说明作为共同语言，确保所有参与者——包括业务人员、分析师、开发者和测试者——对需求有共同的理解。书中提到的关键实践包括： 1. 共同创建示例：业务专家与技术团队一起构建示例，确保需求的准确性和完整性。这有助于发现潜在的漏洞和边界情况。 2. 故事地图：通过绘制故事地图，团队可以将需求分解成可管理的小块，便于优先级排序和计划。 3. 测试驱动开发(TDD)：开发者依据实例化的例子编写自动化测试，确保代码实现符合需求。 4. 持续集成(CI)：频繁集成代码，配合自动化测试，确保在早期就能发现并修复问题。 5. 验收测试：通过实例化的例子编写验收测试，作为交付物的一部分，确保产品功能符合预期。 6. 反馈循环：快速迭代，通过定期回顾和调整示例，根据反馈进行需求的更新和改进。 7. 协作文化：建立一个鼓励开放沟通、共同学习和持续改进的文化，促进团队成员之间的理解和协作。通过案例分析，读者可以看到不同团队在实施实例化需求说明过程中的挑战、成功因素以及经验教训。这些案例不仅展示了实例化需求如何提高团队的生产力，还揭示了如何在实际项目中应用这些原则。实例化需求方法论强调的是通过具体的示例来驱动软件开发，以降低沟通成本，提升产品质量，同时增强团队的敏捷性和适应性。它是一种实用且强大的工具，适用于各种规模和类型的项目，尤其在复杂需求和快速变化的环境中效果显著。

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

Download from Wow! eBook <www.wowebook.com>

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.

Download from Wow! eBook <www.wowebook.com>

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

Download from Wow! eBook <www.wowebook.com>

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

Download from Wow! eBook <www.wowebook.com>

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

Download from Wow! eBook <www.wowebook.com>

剩余294页未读，继续阅读

fate3008

粉丝: 0
资源: 28

实例化需求：打造正确软件的成功团队实践

软件需求Software Requirements(PDF)经典哦

实例化需求 团队如何交付正确的软件

实例化需求 -如何交付正确的软件+培训PPT

软件开发实例1001软件开发实例csdn

specification by example: how successful teams deliver the right software

实用软件工程 吕云翔 pdf

csdn需求文档模板

软件架构设计 温昱 epub

软件工程师的面试题及答案

基于模型设计mbd实例

最新资源

实例化需求团队如何交付正确的软件

实用软件工程吕云翔 pdf

软件架构设计温昱 epub