BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 振る舞い駆動開発(BDD) - コラボレーションによる価値創造

振る舞い駆動開発(BDD) - コラボレーションによる価値創造

原文(投稿日:2013/12/30)へのリンク

ソフトウェアプロジェクトの目的は,ステークホルダに価値を提供することだ。プロジェクトを通じたステークホルダへの価値提供を中心とするBDD(Behavior-Driven Development,振る舞い駆動開発)は,そのためにデザインされた – Viktor Farcic氏は,自身のBDDに対する見方をこのように説明する。
ソフトウェア開発者としてウォーターフォールからアジャイルプロセスへの移行に取り組む同氏は,さらに次のように言う – BDDの原則のひとつに,要件は誰でも理解できる方法で記述されなければならない,というものがある。それと対照的に従来のウォーターフォールプロジェクトでは,ステークホルダに対すしての価値が不明であったり,忘れられていたりすることが多い。このようなプロジェクトに関わる人たちの多くは “自分の仕事” だけを気に掛けて,それを “壁越しに” 次の人に投げ渡しているのだ。

BDDにおいて要件を語る上で重要なのはストーリである。氏はストーリをナラティブ(Narrative,物語)と,それをフォローする1つ以上のシナリオ(Scenario)という,2つの要素で構成されるもだと説明している。ナラティブとは,人あるいは役割の面で語られた,短くてシンプルな機能説明である。すべての関係者(ビジネスアナリスト,開発者,テスタ他)の間で行うコミュニケーションのベースを提供する程度の内容で,文章による説明よりも会話での使用を前提とするものだ。その目標は,3つの質問 - 価値は何か,誰にとっての価値か,実際の機能は何か - に答えることにある。これらの質問に答えることでチームは,ステークホルダとの強力の下で,最善のソリューション定義に着手することができるのだ。
完了状態を定義し,開発したナラティブが期待を満たすことを確認する受け入れ基準となるシナリオを作成することで,ナラティブはさらに確固としたものになる。

しかしながら氏にとってのナラティブは,氏にとっては重要な違いのある,従来型の要件の特徴もいくつか持っている。時として極めて不正確になる書き言葉とは対照的なものとして,話し言葉による継続的なコミュニケーションに注目している点がそのひとつである。そしてもうひとつは,“本システムは ... します” というような形式の文章の羅列に終始しない機能記述が可能な点だ。機能の羅列は読み手に対して,システムの全体像やプロジェクトの目標の理解を難しくする。

最後に氏は,BDDから自動化への移行について説明する。BDDシナリオの実行は,JBehaveCucumberSpecFlowJasmineなど,さまざまなフレームワークを使用して達成することができる。氏の提案によれば,BDDの実践は3つの段階で自動化することが可能だ。

  • 各ステップを正規化してライブラリを作成し,実際のコードからシナリオを分離する。これにより,非プログラマにも容易にストーリが記述できるようになる。
  • 各ステップをより高度なビジネスレベルで結合して,アナリストや同様の立場からも理解しやすいものにする。
  • 実施例の表を利用して,同一のシナリオをパラメータセットを変えながら何度も実行できるようにする。

氏がまず最初のフェーズを実行するように奨める。そして最初のシナリオをサポートするに十分なステップが作られたならば,以降の2つのステップを続けていけばよい。

BDDは2006年頃,導入部ストーリをBDDの視点から記述したDan North氏によって開発された。
例示による仕様記述は,BDDと密接に関連した要件定義方法のひとつだ。

この記事に星をつける

おすすめ度
スタイル

BT