自分の発表が終わったので，今日は7時半に起きて朝風呂入ってから朝食に向かいました。そこで知ったのは，米Manning社の電子書籍が44％値引きで購入できることです。

ATDD，BDD，そしてHDD

今日，朝一番に参加したセッションは，David Bulkin氏による「Beyond Stories, an Intro to ATDD, BDD & HDD」です。部屋は丸テーブルがある狭い部屋でしたが，ほぼ満員でした。

David Bulkin氏は専門コンサルタントなので話はとても上手です。まず簡単な紹介から。ATDD（Acceptance Test Driven Development：受け入れテスト駆動開発）とは，プログラマがビジネスニーズを想定して開発を進めるもので，BDD（Behavior Driven Development：振る舞い駆動開発）は，開発者がビジネスに要求を聞いてから開発を進める方法です。

またHDD（Hypothesis Driven Development：仮説駆動開発）とは，ビジネスでも完全に要求を理解を理解していないことを前提にしています。ビジネスを成功させることができるソフトウェアを開発することが目的であって，仕様通りに正しく動作するプログラムを作成することではないということです。

次に，ワークショップスタイルでTDD，BDD，HDDを体験しました。TDDの例では，簡単な電卓のテストケースを作成しました。BDDではDan Northのブログで紹介されたATMからお金を引き出す例を利用しました。HDDでは入場券販売を例にして，売り上げをどのようにしたら上げることができるか皆で議論しました。予定していた人数が来なかった場合や，思ったよりも原価が高かった場合などにどのように対応するかの話で盛り上がりました。

良い成果物より良い結果を ─アジャイルの使い方

10:45～12:00は，Jeff Patton氏の「Agile Requirements & Product Management」を聞きに行きました。講演用の大部屋でしたが，ほぼ満員でした。やはり有名人だけあって集客力がすごいです。

セッションは，まず自己紹介から始まりました。芸術学校を中退してソフトウェア会社に就職したPatton氏はプログラマになりたかったのですが，技術力が足りないのと，ドメイン知識を活かせると言われてプロダクトマネージャにされたそうです。

そして前日のマイク・コーン氏の講演で間違っていた点を訂正しました。ソフトウェアは世の中を変えるために作成するものです。またソフトウェアは人を幸せにするために作成します。やりたいことができなかったり，混乱している人たちの考えをまとめて，ソフトウェアを開発してその人たちに提供することによって幸せにするものです。

ソフトウェア開発者の役目は，できる限りソフトウェア開発の労力を最小にし，ユーザへ提供するメリットを最大にすることです。

製品とプロジェクトとは異なります。プロジェクトは成果物を出荷したら成功となりますが，製品は出荷した後から価値が出ます。スケジュール通りかつ予算内にプロジェクトを完了させても，できた製品のメリットがユーザにとって低い場合もあります。それを避けるために，ユーザと開発者が共通した認識を持つ必要があります。

ドキュメントを共有しても共通認識をもつとは限りません。そのため，ドキュメントではなくストーリーを共有します。ストーリーとは書かれた文章というよりも，利用者と開発者が共通認識をもつためのツールです。そのために文字に限らずお互いの理解が共通に得られるような道具を使います。また，よく会話をしてすれ違いが無いように確認をします。重要なのは書かれた仕様書ではなく，共通した認識です。

成果物（output）と結果（outcome）も異なります。たとえば，スキーを習い始めた人にはパワープラウ（いわゆる“⁠ボーゲン⁠”⁠）の仕方を教えます。しかしパワープラウが上手になることが目的ではありません。どれだけパワープラウが上手になったしてもスキーが上手になったとは言えません。オリンピックにパワープラウと言う種目はありません。

アジャイル開発は，良い成果物よりも良い結果を出すために使います。その時のユーザの考えていることを完璧に把握するよりも，実際に動くソフトウェアを提供して使ってもらえるようにすることを優先します。使っていただくことにより，ビジネスでどのように使えるかを確認して，全員で学びながらよいビジネス結果へ向かいます。

ストーリーとは岩のようです。以前「アステロイド」というゲームがありましたが，このゲームのコツは，大きい岩を1つずつ砕くことです。砕いて小さくなった岩はばら撒かれるだけではなく，スピードも速くなります。ストーリーも同じように1つずつ細かく砕いていった方が良いと言います。また，ストーリーの「正しい粒度」というものはありません。会話をしながら，お互い共通した認識が持てる粒度が最適です。その人とのその時の関係で粒度が変わります。また，ソフトウェアの要求は供給より多いので，要求は絞る必要があります。

反復型開発にはインクリメンタル型開発とイテレーティブ型開発法があります。インクリメンタル型開発とは，機能を分けてその機能ごとに完成させていくことです。イテレーティブ型開発法とは，すべての機能を同時に開発しますが，最初からは完成させないことです。芸術家が絵の下書きをして，それを徐々に完成させていくのと似ています。

話の最後に次のようなスライドを見せて，話の内容をまとめました。