Dan Bergh Johnsonn氏による、スクラム、BDD、DDDの関係を解説したブログ記事について、要約とコメント。
要約
スクラム・BDD・DDD - アジャイル開発スタック
Dear Junior - Letters to a Junior Programmer: Scrum on BDD on DDD - an Agile Development Stack
アジャイルのプラクティスがどのような関係にあるのかについて、長いこと考えてきた。日常使っている３つのプラクティスについては、特にそうである。それが、ドメイン駆動デザイン（"Domain-Driven Design"）、ふるまい駆動開発（"Behaviour-Driven Development"）、スクラム（"Scrum"）の３つである。これらについては、スタック（"stack"）としてとらえるのが適切だと考えるに至っている。
スクラム
良質で軽量なプロジェクトフレームワーク。要件定義からソフトウェアの完成までをどのように進めるべきかについて示しているが、要件／要求であるストーリーの形式については何も規定されていない。スクラムは、ストーリーがチーム、PO、ステークホルダ間における対話のスタート地点であるとするが、この対話が効率的にできるかどうかはストーリーの形式にかかっている。
ふるまい駆動開発
ストーリーの形式について、優れたものを提供してくれるのが、ふるまい駆動開発である。"As I want so that "に始まり、"Given , when , then "形式で明確な具体例を示す。しかし、この形式はきわめて簡略化されているので、使用している単語が理解されている必要がある。少なくとも、最も中心的な概念に関する理解が共有されていることは不可欠である。
ドメイン駆動デザイン
最も中心的な概念に関する理解の共有に注力させてくれるのがドメイン駆動デザインである。このうち、「共有 （"shared"）」、「理解 （"understanding"）」、「最も中心的 （"most central"）」が重要なキーワードとなる。「共有」が意味しているのは、関係者全員が同じ概念で考えるということであり、これが「ユビキタス・ランゲージ（"ubiquitous language"）」の本質的な意味である。「理解」とは、システムについて議論する際の文脈において、単語の用法を正確に定義すること。「最も中心的」とは差別化を行う場所であり、DDDで言う「コア・ドメイン」のことである。
So, to turn it all around, and walk the stack bottom-up: Domain-Driven Design provides the stringency and preciseness that Behaviour-Driven Development needs to make the story-conversations productive that lets Scrum smoothly process visions to software.
ふりかえって、ボトムアップにスタックを見ると次のようになります。ドメイン駆動デザインがもたらす厳密さと正確さによって、ふるまい駆動開発のストーリー的対話が生産的なものとなり、そのことでスクラムは円滑にビジョンをソフトウェアへと具体化することができるのです。
コメント
ざっくりと整理すると、次のように言えるでしょう：
BDDとDDDの関係という意味では、Dan North氏による「BDDとDDD」とは逆の方向から考えられていると言えるでしょう。つまり、こちらはまずストーリーから始めて、ストーリーで用いられる言語を共有するためにDDDのテクニックを使うという流れですが、North氏の解説では「コア・ドメイン」がまずあって、それを境界の外側から捉えるためのテンプレートとしてストーリーがあるという流れです。
どちらの説明であっても重要なのは、BDDが要件を明確にとらえるための方法と考えられている点と、DDDの本質を「ユビキタス・ランゲージ（"Ubiquitous Language"）」「境界付けられたコンテキスト（"Bounded Context"）」「コア・ドメイン（"Core Domain"）」といった点に見ていることだと言えるでしょう。
