Part I - Thinking About Acceptance
A key part of understanding any system, whether we are designing it, building it, testing it, accepting or using it is to build mental models about how we expect it to work. Systems that are easy to use make it easy for users to develop simple mental models
or at least familiar mental models that allow them to reuse knowledge about how other systems work. This part of the guide describes six simple models that help us reason about the process of accepting software.
The ultimate goal of any development process is to build the right product of high quality and to build it with minimum waste. The primary decisions we must make are the workflow and the amount of work that will be moved through the workflow at a time. The
workflow consists of the set of activities the team must pursue and the ordering of those activities, that is, whether the activities will be carried sequentially or as needed. Our organizations choices on these two critical dimensions affect how we will go
about making the acceptance decisions. In addition, how a project chooses to measure the rightness and the quality of the product will make a difference in deciding how the product development team and the product owner will know if it’s done and ready to
deploy. The models help address the impact of the choices that the stakeholders make on these dimensions.
Chapter 1 – The Acceptance Process introduces the overall acceptance process. It describes the decisions that must be made and how acceptance relates to the overall software development life cycle, the processes with stages and gates, and the classic
V-model of software development.
Chapter 2 – The Decision-Making Model describes the process for making the decisions introduced in the previous chapter. It also provides guidance on who (which roles) should make the decisions and who should collect the information on which the decisions
Chapter 3 – The Project Context Model describes the various project factors that might influence the acceptance process.
Chapter 4 – The System Requirements Model describes various ways requirements can be partitioned and described and how that relates to the acceptance process.
Chapter 5 – The Risk Model describes a simple way of thinking about potentially undesirable events and how they might influence the acceptance process.
Chapter 6 – The Doneness Model describes ways to describe to what degree the product is finished. It gives us ways to ask the question “what does
done mean?” as a way to define our acceptance criteria for individual features and for entire releases of products. It also introduces the concept of incremental acceptance.