The HIRO Says

If you smell what The HIRO is cooking!!!

「ホンモノ」の ATDD by Example


まず最初に、タイトルに特に悪意はないですw
Agile2014初日の7/28(月)に、Adam Yuret さん『How to use ATDD to help deliver quality software in Kanban or Scrum process.』 というワークショップに参加してきました。


セッションの概要を確認すると、「ユーザストーリーの Acceptance Criteria をクリアにするワークショップを通して、ATDD の考え方を体感できる」(超意訳)とのこと。
ちょうど今、BDD(Behavior-Driven Development) の可能性に興味を持ち始め、『Specification By Example』を読んでいる最中なので、自身の理解を確認する意味でもプラスになると思い参加してきました。


ワークショップの内容

まず、このようなお題を出されました。


写真がブレて見づらいので、文字に起こしてみました。

Transportation is needed to and from the bank
in order to deliver the heist team to from the bank.
・Identify Acceptance Criteria
・Identify Concrete Positive and Negative examples

いきなり銀行強盗になって、無事銀行強盗の仕事を成し遂げるにはどのような Story と Acceptance Criteria が必要か考えよう!というものでしたw
さすがに強盗なんかやったことないから、想像で考えるしかないw

ワークショップの進め方
  • まず、5〜6人程度のチームを作ります。
  • チーム内で一人、プロダクトオーナー(PO)を決めます。
    • PO は、上記のお題&要求の曖昧な箇所を明確にすることに責任を持ちます。
  • PO を含めた全メンバーで、ユーザストーリーとその Acceptance Criteria を明確にしていきます。
  • 特にユーザストーリー&Acceptance Criteria を明確にする際は、効果のプラスとマイナスの例を明確にします。
実際にやってみました。


まず必要なユーザストーリーは何かについて、チームメンバー同士お互い思いつくアイデアを列挙してみて、それらを KJ 法でクラスタリングしてみることにしました。その後、各ユーザストーリーで具体的に何を検証すべきか、Acceptance Criteria を考えてみることにしました。
以下が、私たちのチームで考えた例です。

・移動手段は車にしよう。
・車ならば、どのような車が良いか?
 ・Fedex のトラックやスクールバスだと、大きくて耐久性があるため、警察との交戦に有効だよね。
  → あくまで警察との交戦はせず、迅速に移動して逃げることを優先しよう。
    あわせて、武器の携行はしないこととしよう。
 ・どのくらいの早さで動けると良いか?
  → 10分程度で移動できるのが好ましい。
  → ミニバンにしよう。
・おとり用と実業務用の2台が必要だね。

特にアイデア出しで意識したのは、次の3点でした。

  1. 具体例で考える
  2. 具体的な数値で考える
    1. プラスになる点とマイナスになる点を、合わせて明確にする。
  3. User Story Mapping の要領で、全チームメンバーが協力してアイデアを出し合う。
トレードショーによる改善

終わった後、「トレードショー」(自分たちのワークショップの成果をチーム同士お互いに説明しあうイベント)を実施。そこで得たものを自チームに持ち帰り、更に改善を実施しました。
以下が、我々が追加した情報です。

車2台の費用回収を初期投資として考えると、銀行からは800万ドル持っていく必要がある。
・気付かれずに動くようにするため、音のうるさくないメーカーの車を選ぶ。
 ・プリウス

一連のワークショップのポイント

  • 具体的な数値を使用した具体例(Example)に基づいて考えることで、仕様の曖昧さを減らし、rework を減らすことが出来る。
  • このようにして明確にした Acceptance Criteria の検証を自動化しておくことで、「動く仕様」に基づいて開発・テストをやっていくことができる。
    • 「Automated pipeline を作る」という言い方をしていました。
    • ツール例として、Cucumber があげられていました。
  • 仕様の明確化は、PO や Tester も含めた全員で行うこと。
    • PO は、ユーザや Business Analyst を説得するのに必要な知識を持っている可能性がある。また仕様の曖昧な箇所を明確化する責務を持つ。
    • Developer は、仕様が実装可能か、またより実装しやすい方法は何かについて語ることができる。
      • そもそも PO らの言いなりになっていては、責任あるものを作れない。
    • Tester は、仕様がテストをしやすいものであるかを判断できる。
      • テストをしやすい仕様・要求に洗練することで、プロダクト開発を主導することが出来る。
  • どれだけテストをすれば良いのかを、チームで決定することが出来る。
    • 結果として、テストの重複を減らし、テストの総量を減らすことも可能。

所感


基本的に、人間同士の理解にはズレが生じうるもの。PO に決めてくれ!と言って仕様を出してもらっても、妥当な仕様を PO だけで作れることはまれ。
それならば、Example(具体例)、特に数値を含むそれでユーザストーリーと Acceptance Criteria を明確化すれば、このズレを減らすことが出来、結果 rework を減らし sustainable なプロダクト開発が出来るのではないか?
セッションのテーマは ATDD でしたが、実質『Specification By Example』のワークショップだったなという印象です。


補足

ちなみに、特に Flow ベースの Kanban のお話は出ませんでした。