Skip to content

Instantly share code, notes, and snippets.

@rpivo
Last active August 2, 2021 04:04
Show Gist options
  • Save rpivo/1469476d9c4cd3ea41f8709eaae94920 to your computer and use it in GitHub Desktop.
Save rpivo/1469476d9c4cd3ea41f8709eaae94920 to your computer and use it in GitHub Desktop.
The Key Process Patterns From *Specification by Example*

The Key Process Patterns From Specification by Example

In Specification by Example, Gojko Adzic describes a kind of behavior-driven development that makes documentation the central point from which everything else extends. In the book, he outlines key process patterns that organizations can follow to establish business goals, define scope, polish requirements, and write effective, evolving documentation along the way.

Gojko shares these process patterns as happening "just in time" and occurring cyclically rather than as a kind of waterfall pattern. This process workflow should happen when the team is "ready for more work". This allows these key process patterns to comfortably function within Agile sprints.

Gojko appears to mention these patterns not as a strict rubric, but more as process patterns that other successful teams have generally implemented in their own way.

Below is the key process pattern outline as specified by Gojko. This flowchart is an approximation of Gojko's original diagram in Specification by Example.



2021-08-01



The diagram is a series of landmarks and action items. Each landmark represents a point of arrival for an organization, indicating the completion of certain artifacts like goals or examples. The landmarks are:

  • Business goals
  • Scope
  • Key Examples
  • Specification with Examples
  • Executable Specification
  • Living Documentation

Each action item represents an action item that an organization needs to take in order to generate certain artifacts.

The action items are:

  • Deriving scope from goals
  • Illustrating using examples
  • Specifying collaboratively
  • Refining the specification
  • Automating validation without changing specifications
  • Validating frequently
  • Evolving a documentation system



2021-08-01-v2



Out of these landmarks and action items, there is a core set of artifacts that will be generated:

  • Business goals
  • Scope
  • Examples
  • Specification

Business goals are the specific results that represent a desired outcome for a business. This could be the result of personal enjoyment, or financial gain, or betterment of a community. If business goals are vague, then the scope, examples, and specification of the system is weaker. Clear business goals results in clear scope, examples, and specification.

It is hard to imagine how any one of these artifacts can exist if one of the four is not also generated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment