If you or your team are involved in building software then this book is highly recommended. Be prepared to approach the book without holding on to your existing notion of how software is built because this thinking can make you change the way you approach and execute software development.
Who are the intended readers?
1. Managers who are accountable for delivering software. If you oversee delivery of software from conceptualization all the way to deployment to production, then this book is something worth every minute of reading time. In fact, the recommended practices here do benefit long term total cost of ownership of the software which your clients (internal or external) can benefit from (perhaps your career too).
2. Business Analysts, Testers and Programmers are also targeted readers because these are the key roles that contribute to the success of the software delivery team.
This is not just another book evangelizing a thesis, but the later chapters give you key takeaways on what the exact tools are recommended to implement it. Although you should not treat that list of tools as the final list because this book is already 'old' as far as that list is concerned today, instead go to Adzic's website to see a more up to date list of tools recommended. Even without the tools, the lessons advocated in this book are classic teachings on software quality -- that we should start addressing good quality software before we even start writing the first line of code.
Agile software development is a game changer some years back but it remains to be an approach that folks are uncomfortable with in traditional organizations with established "tried and tested" methodologies. This book will add further justification on why you should go agile. If you are doing agile now, then this book will improve on that practice further which can help you convince your stakeholders to side with you on the agile movement.
This is a review from somebody who actually wrote code for a living and managed software delivery for years.
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
by
Gojko Adzic
(Author)
|
Gojko Adzic
(Author)
Find all the books, read about the author, and more.
See search results for this author
|
ISBN-13:
978-0955683619
ISBN-10:
0955683610
Why is ISBN important?
ISBN
Scan an ISBN with your phone
Use the Amazon App to scan ISBNs and compare prices.
This bar-code number lets you verify that you're getting exactly the right version or edition of a book. The 13-digit and 10-digit formats both work.
Use the Amazon App to scan ISBNs and compare prices.
Add to book club
Loading your book clubs
There was a problem loading your book clubs. Please try again.
Not in a club?
Learn more
Join or create book clubs
Choose books together
Track your books
Bring your club to Amazon Book Clubs, start a new book club and invite your friends to join, or find a club that’s right for you for free.
Available to ship in 1-2 days.
Ships from and sold by Amazon.com.
More Buying Choices
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
-
Apple
-
Android
-
Windows Phone
-
Android
|
Download to your computer
|
Kindle Cloud Reader
|
Customers who bought this item also bought
Page 1 of 1 Start overPage 1 of 1
Start reading Bridging the Communication Gap on your Kindle in under a minute.
Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.
Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.
Product details
- Publisher : Neuri Limited (January 5, 2009)
- Language : English
- Paperback : 284 pages
- ISBN-10 : 0955683610
- ISBN-13 : 978-0955683619
- Item Weight : 14.9 ounces
- Dimensions : 6 x 0.6 x 9 inches
-
Best Sellers Rank:
#1,077,429 in Books (See Top 100 in Books)
- #463 in Software Testing
- #522 in Computer Systems Analysis & Design (Books)
- #2,950 in Computer Programming Languages
- Customer Reviews:
Customer reviews
4.3 out of 5 stars
4.3 out of 5
29 global ratings
How are ratings calculated?
To calculate the overall star rating and percentage breakdown by star, we don’t use a simple average. Instead, our system considers things like how recent a review is and if the reviewer bought the item on Amazon. It also analyzes reviews to verify trustworthiness.
Top reviews
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
5.0 out of 5 stars
... involved in building software then this book is highly recommended. Be prepared to approach the book without holding ...
Reviewed in the United States on December 19, 2016Verified Purchase
One person found this helpful
Report abuse
Reviewed in the United States on December 30, 2018
Verified Purchase
Message of the book is introduction to communication and discussion to discover missing (stories/hidden assumptions) + clearing between teams in organization (many teams).
It's very useful for anyone first step in Agile and need to know difference between tradition and new wave. This book does not mention tools for automation however it is enough to find automation that conformity and approciate to Agile team.
"Document is nothing, documenting is everything" - this quote book is impressed to the most value are communication and concensous/commitments.
It's very useful for anyone first step in Agile and need to know difference between tradition and new wave. This book does not mention tools for automation however it is enough to find automation that conformity and approciate to Agile team.
"Document is nothing, documenting is everything" - this quote book is impressed to the most value are communication and concensous/commitments.
Reviewed in the United States on July 18, 2009
Verified Purchase
"Bridging the communication gap" by Gojko Adzic is a much needed book on a very important topic that finally is deserving the attention it needs: Agile acceptance testing. This practice is also known as "automated acceptance testing" or as "acceptance-test-driven development." It has evolved over the last decade, but was known and used in a relative small group. Every year there would be a couple papers on the topic, Lasse Koskela covered it a bit in his "Test-Driven" but now finally Gojko takes the subject further and devotes a whole book on it.
What is it? Agile Acceptance Testing is a technique for closing the communication gap between business, developers and testers. A way to write specifications as examples which become executable. The specification are created together in a workshop and not handed over like traditional requirements.
The book is written in four parts. The first part is an introduction to the topic, describes an overview of the technique. An important part of this part (and the whole book) is the focus on communication instead of test. This is reflected in the excellent discussion about naming. Agile Acceptance Testing is perhaps one of the most poorly named practices, but... still... thats the name it became popular with (or with A-TDD). The second part is the most important parts of the book, which describes how to write specifications, why to work with examples, how to run specification workshops and what to do after these workshops. The part ends with a discussion about change in projects and how the automated acceptance test help with that.
The third part discusses implementation. It starts with how to fit this technique in an iteration and how to adopt the practice. Next is a chapter on user stories and its relationship with acceptance tests. Then the part dives in the tools by first covering the current tools and then discussing the requirements for the future tools. The last part of the book describes the impact of agile acceptance testing on the different functions: business analyst, developer and tester.
Bridging the Communication Gap is a small book (300 pages) and is easy to read. It could have been smaller, the writing is sometimes a little too wordy. It doesn't contain too much pictures, which is too bad when a book talks so much about workshops. Yet, despite these drawbacks, I think this is an excellent book and a much needed contribution to the modern software development/agile development literature. It was one of the few practices that did not have its own book yet and Gojko provided that.
I was doubting between 4 and 5 stars for this review. 4 because this book is certainly not perfect. 5 stars because it is good still. Because this is a first in a new area and because I consider this an important area, I decided to go for 5 stars. This will certainly be a book that I will be recommending to other people (and in fact, I already have). Great work Gojko!
What is it? Agile Acceptance Testing is a technique for closing the communication gap between business, developers and testers. A way to write specifications as examples which become executable. The specification are created together in a workshop and not handed over like traditional requirements.
The book is written in four parts. The first part is an introduction to the topic, describes an overview of the technique. An important part of this part (and the whole book) is the focus on communication instead of test. This is reflected in the excellent discussion about naming. Agile Acceptance Testing is perhaps one of the most poorly named practices, but... still... thats the name it became popular with (or with A-TDD). The second part is the most important parts of the book, which describes how to write specifications, why to work with examples, how to run specification workshops and what to do after these workshops. The part ends with a discussion about change in projects and how the automated acceptance test help with that.
The third part discusses implementation. It starts with how to fit this technique in an iteration and how to adopt the practice. Next is a chapter on user stories and its relationship with acceptance tests. Then the part dives in the tools by first covering the current tools and then discussing the requirements for the future tools. The last part of the book describes the impact of agile acceptance testing on the different functions: business analyst, developer and tester.
Bridging the Communication Gap is a small book (300 pages) and is easy to read. It could have been smaller, the writing is sometimes a little too wordy. It doesn't contain too much pictures, which is too bad when a book talks so much about workshops. Yet, despite these drawbacks, I think this is an excellent book and a much needed contribution to the modern software development/agile development literature. It was one of the few practices that did not have its own book yet and Gojko provided that.
I was doubting between 4 and 5 stars for this review. 4 because this book is certainly not perfect. 5 stars because it is good still. Because this is a first in a new area and because I consider this an important area, I decided to go for 5 stars. This will certainly be a book that I will be recommending to other people (and in fact, I already have). Great work Gojko!
14 people found this helpful
Report abuse
Reviewed in the United States on July 9, 2020
Verified Purchase
This book is an in depth read on why imperative specifications aren't very effective. It backs the information up with studies on IT, Army, and cognitive research. It then show a superior way to convey complex information using scenarios and examples.
Reviewed in the United States on January 4, 2014
Verified Purchase
The concept of using real world examples that explicitly validate expected business outcomes of a product feature is both practical and very powerful. Crystalizing out the process details to do this in an Agile development cycle is what this book does, and it does it well.
Personally I find the style of writing rather dry so pushing ahead through the material takes some commitment, but it is worth it. The lessons, techniques and value of the results provide an excellent payoff.
Personally I find the style of writing rather dry so pushing ahead through the material takes some commitment, but it is worth it. The lessons, techniques and value of the results provide an excellent payoff.
One person found this helpful
Report abuse
Reviewed in the United States on September 30, 2015
Verified Purchase
This method of agile acceptance testing for specifying requirements is specific and so thoroughly helps to communicate what is being talked about and agree on it - it really is useful to all parts of the project and implementation. Gojko gives good examples and summaries of techniques and makes the process clear.
One person found this helpful
Report abuse
Reviewed in the United States on April 9, 2015
Verified Purchase
I think this is a must read for anyone involved in a software development project. I love how it teaches you specification by example as a concept and philosophy to be learned by all parties involved before thinking of using any kind of software tool to automate it.
Top reviews from other countries
Alex
3.0 out of 5 stars
Lots of words
Reviewed in the United Kingdom on June 20, 2020Verified Purchase
Lots of words in this book. The first few chapters were fairly interesting but eventually it became rather a grind to get to the end.
Sum up the thesis with "don't make assumptions about what people want: ask"
And some software developers are full of their own self-importance.
Sum up the thesis with "don't make assumptions about what people want: ask"
And some software developers are full of their own self-importance.
Cathal King
4.0 out of 5 stars
Great insight mixed with lots of practical advice
Reviewed in the United Kingdom on February 18, 2014Verified Purchase
An enjoyable read that gives a satisfactory introduction into improving your software development process with the help of "specification by example" practices. The author spends plenty of time highlighting and addressing subtle and important issues that come up during typical software development life cycle for analysts, testers and developers. He explains in detail how "specification by example" (used interchangeably with "agile acceptance testing") can heighten effective levels of collaboration during a typical development iteration and lead to nipping common issues in the bud and improving the engagement of all involved.
Sohnee
5.0 out of 5 stars
Covers some all important missing pieces
Reviewed in the United Kingdom on September 12, 2014Verified Purchase
This book covers some all important missing pieces from many software development teams.
If the thought of developing software without the ambiguity of requirements appeals to you, this is the book to read.
If the thought of developing software without the ambiguity of requirements appeals to you, this is the book to read.
N. Murali Mohan
5.0 out of 5 stars
Clarifying Acceptance tests and more
Reviewed in India on July 5, 2020Verified Purchase
I am glad to have read this book at last and I regret that I did not read it before. It clarifies what acceptance tests mean.
This book clarifies what acceptance tests means and how it is used as a means of collaboration between business analysts, or customer, as the case maybe, testers and development teams to develop specifications for the system being developed. This book also clarifies how acceptance tests is a misnomer and suggests various other alternative names to use.
The author also discusses various tools in vogue and discusses the strengths and weaknesses of each. This book also discusses the impact on business analysts, testers and developers in the Agile world.
It is a must read for those interested in Agile ways of working in true spirit.
This book clarifies what acceptance tests means and how it is used as a means of collaboration between business analysts, or customer, as the case maybe, testers and development teams to develop specifications for the system being developed. This book also clarifies how acceptance tests is a misnomer and suggests various other alternative names to use.
The author also discusses various tools in vogue and discusses the strengths and weaknesses of each. This book also discusses the impact on business analysts, testers and developers in the Agile world.
It is a must read for those interested in Agile ways of working in true spirit.
Atanas Ianev
5.0 out of 5 stars
Sehr empfehlenswert
Reviewed in Germany on August 19, 2015Verified Purchase
Das Buch ist ein Muss für Alle, für die die Kommunikation zwischen den unterschidlichen Gruppen in einem Projekt ein wichtiges Thema ist und was dazu lernen möchten. Es ist einfach zu lesen und der Author hat es in einer sehr einfachen und direkten Weise geschaft, die Problematik erklären und anzugehen.
Pages with related products.
See and discover other items: agile development, software quality assurance, software quality assurance


