Date:  Wed, 24 Mar 2010 18:52:11 +0900
Subject:  【オブジェクト倶楽部: 2010-12号】
X-Mail-Count: 00330

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          No.320 2010/03/24

■ I N D E X
┃
┣【プログラミング】Let's Try 受入テスト [4]
┣【PF】現場リーダーの心得 [24]
┗ 編集後記

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】Let's Try 受入テスト [4]

● はじめに
本連載のテーマは受入テストです。
今日は、ユーザーストーリーの紹介です。ユーザーストーリーは、XPの文脈に
おいて、受入テストと深い関係があります。

●今日のポイント
「ユーザーストーリー単位を軸に、受入テストを実施すれば、
  ユーザー目線の価値単位で、
  システムの期待する振る舞いが実現できたかを確認できる」です。

● ユーザーストーリーとは?
ユーザーストーリーを使った活動の特徴を表すのに、次の3C(Card、
Conversation、Confirmation)が知られています。
- ユーザーのシステムに対する期待する振る舞いやそれが必要な理由を小さな
【Card】に収まるほど簡潔に記述する
- 顧客と開発者(テスターを含む)が対話【Conversation】[*1]を通じて、Good
 なユーザーストーリーに洗練させる
- 後で、ユーザーストーリーが実現できたかを確認【Confirmation】する。

1つのユーザーストーリーが、受入テストの1つの大まかな確認項目となります。

10日を1イテレーションにした反復開発の場合、例えば、次のようにユーザー
ストーリーが利用できます。

------
適宜:顧客が中心となってユーザーストーリーをカード等に記述し、集めておく。
1日目:
  開始のミーティング。優先度の高いものから顧客と開発者の対話を通じて、
  Goodなユーザーストーリーに洗練さる。また、イテレーション期間中にどの
  ユーザーストーリーを実現するかを決める。
2日目〜9日目:
  開発中。チーム一丸となってユーザーストーリーを実現する。
10日目:
  終了のミーティング。どのユーザーストーリーが実現できたかをデモで確認
  する。デモを通じて、新しいユーザーストーリーを発見する。
----

● ユーザーストーリーのテンプレート
英語のテンプレートは次になります。
「As a <type of user>
  I want <some functionality>
  so that <some benefit>.」
あるいは
「In order to <achieve some value>,
  as a <type of user>,
  I want <some functionality>.」

参考:「新たなユーザーストーリーフォーマットがビジネス価値を強調」[*2]

● ユーザーストーリーの記述例
例えば、英語学習のWebサービスを考えた場合、次のようなユーザーストーリー
が挙がるでしょうか。
(筆者が、夜中2時に思いつきで書き出しました。魅力的なWebサービスかどう
かは、保留してください :-) )

「学習コンンツのアップローダーとして(As a ...)
  コンテンツ(英語動画/テキスト/テスト)を登録したい (I want ...)
  魅力的なコンテンツを学習者に提供し、人を集めたいから。(so that ...)」

「学習者として、
  学習コンテンツを見たい。
  コンテンツを見て、英語を学習したいから。」

「学習者として、
  フォローワーが欲しい。
  仲間からアドバイスがもらえたり、楽しく学習が続けられるから。」

「学習者として、
  ライバルと比較できる、テストのスコアランキングがほしい。
  競争しながら学習すると、勉強がはかどるから。」

「サイト管理者として
 アクセス統計を細かく見たい。
 サイトのアクセス行動分析をし、魅力的なWebサイト作りに活かしたい。」

上の記述だけでは、システムの具体的な期待する振る舞いや、その機能が必要
な理由は見えてきません。
顧客と開発の間で【対話】を通じて、誰向けに(Who)、何をつくるのか
(What)、何故それが必要なのか(Why)を深堀し、Goodなユーザーストーリーに
洗練させていきます。Good なユーザーストーリーの目安の基準として INVEST
が知られています。

● INVEST
-Independent(独立)
-Negotiable(交渉/相談可能)
-Valuable(ユー ザ価値)
-Estimable(見積り可能)
-Size appropriately(イテレーション期間に収まる手頃なサイズ)
-Testable(テスト可能)

INVESTを満たすようにユーザーストーリーを洗練させ、後で、そのユーザース
トーリーが実現できたかを確認することになります。

● まとめ
ユーザーストーリーを紹介しました。ユーザーストーリーの特徴は、3C(Card、
Conversation、Confirmation)です。
記述フォーマットは、
「As a <type of user>,
  I want <some functionality>,
  so that <some benefit>.」で、
Who、What、Whyを簡潔に記述します。
Goodなストーリーには INVEST(Independent、Negotiable、Valuable、
Estimable、Size appropriately、Testable)が備わっています。
ユーザーストーリー単位を受入テストのチェック単位とすれば、ユーザー目線
の価値単位でシステムの期待する振る舞いが実現できたかを確認できます。

ユーザーストーリーの一番参考になる文献は、 『User Stories Applied』[*3]
です。日本語で読めると文献としては、『アジャイルな見積りと計画づくり』
[*4]や、『実践アジャイルテスティング』[*5]が参考になります。

先日すくすくスクラムの勉強会で、角さんのユーザーストーリーに関する講義
を聞きました[*6]。こちらも参考になります。

次回は、BDDと受入テストの関係について紹介する予定です。(IENAGA)

●参考
[*1] 「対話的ストーリー」
ユーザーストーリーの対話重視については、下記が参考になります。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ConversationalStories

[*2] 「新たなユーザストーリーフォーマットがビジネス価値を強調」
http://www.infoq.com/jp/news/2008/06/new-user-story-format

[*3] 「User Stories Applied」
http://wwww.amazon.co.jp/dp/0321205685/xpjp-22
この本は、ユーザーストーリーに関するバイブル本です。今回の記事の一番の
情報源です。

[*4] 「アジャイルな見積りと計画づくり」
http://www.amazon.co.jp/dp/4839924023/xpjp-22


[*5] 「実践アジャイルテスト」
http://wwww.amazon.co.jp/dp/4798119970/xpjp-22

[*6] 「ユーザーストーリービギンズナイト」
http://www.slideshare.net/SukusukuScrum/no01101suc3rum20100225

● 過去の連載記事
 - /ml-arch/magazine/316.html
 - /ml-arch/magazine/321.html
 - /ml-arch/magazine/325.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
 ■
 ┗【PF】現場リーダーの心得 [24]
オブジェクト倶楽部メルマガ読者のみなさん、こんにちは。
岡島です。

今回はお勧めイベントの紹介をさせてください。来る4月9日と10日の二日にわ
たり、「日本の現場をアジャイルを軸に改革する人達のためのイベント」
AgileJapan 2010が開催されます。

http://www.agilejapan.org/index.html

昨年行われたAgileJapan 2009で、私はクロージングセッションを担当させてい
ただいたのですが、今回は「やっとむ」ことオブジェクト倶楽部でもおなじみ
安井さんのセッションをお手伝いすることになりました。その名も「カンバン
ゲーム  〜かんばんによるプル型開発体験」。カンバンだけでなく、やっとむ
が開発したカードとダイスを使い、カンバン、特にプル方式カンバンのメリッ
トを体感していただけるセッションです。
プル方式カンバンは、リードタイムを減らし、提供する価値を最大化するとさ
れています。どうしたらそれを実現できるのか、理屈だけでなく実感できるの
がカンバンゲームです。

ゲームのルールは簡単です。カンバン(ToDo/Doing/Done)と二種類のカード
(タスクカードとチャンスカード)、サイコロを二つ使います。タスクカード
をカンバンの上に置き、それをDoneレーンまで次々の動かします。タスクカー
ドには「コスト」があって、サイコロの出た目だけ減らしていくことができ、
コストが0になったら次のレーンに移動させることができるのです。さらに、
プレイヤーはターン毎にチャンスカードを一枚引き、そのカードの内容によっ
てゲームにはいろいろな「問題」が発生します。これら「問題」の「解決」も
このゲームの楽しさの一つなのです。

ゲームでつかうカンバンは三種類です。先ほど紹介した通常のものに加え、
Doingをデザイン・実装・テストの三つの役割に分けたもの、さらに「待ち領域
(キュー)」を設けたものです。最後の待ち領域付きカンバンを使ったゲームに
より、プル型カンバンの利点を体験しながら学ぶことができるようにデザイン
されたセッションです。

なお、これらのゲームは協力ゲームであり、誰が一番かを競うものではありま
せん。ゲームの参加者同士でいろいろ会話や議論を楽しめるようにも工夫され
ています。私もこのゲームで実際に遊んで(?勉強して)みましたが、いろい
ろなカンバンのバリエーションを体験しながら、徐々にプル方式のカンバンに
移行していくことで、プル方式のメリットの一部を楽しく味わうことができま
した。

カンバンゲーム以外にも興味深い事例セッションや講演が二日間にわたり目白
押しのAgileJapan 2010。ありがたいことに、すでに満員御礼にて募集は締め
切られたそうです。「もっと早く知らせてくれれば!」という方、本当にもう
しわけありません。すでに申し込みを頂いた方、当日お会いできること楽しみ
にしています。(岡島)

■ 永和システムマネジメントの組込みソフトウェア開発
 ICTとETのクロスーオーバーを目指します。
http://et.esm.co.jp/site/index.html

■「ソフトウェア開発を成功させるチームビルディング」
 現場リーダーの仕事術をチームビルディングの観点から説明しています。
http://www.amazon.co.jp/dp/4797352434/xpjp-22

■ okajima_yukioのtwitter
http://twitter.com/okajima_yukio/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人の天野勝です。
あたたかかったり、寒かったりでみなさま体調を崩していないませんか。私の
まわりで、体調を崩してしまう人が出ています。わたしの妻や、このオブラブ
の編集人をいつもつとめているナガタユウコもダウンしています。このメール
マガジンは、久々に私がピンチヒッターで編集いたしました。
さて、皆様においては体調に気を付けて過ごして、きたる花見では盛り上がれ
る様に備えてくださいね。

*** オブラブスタッフ自己紹介 ***
 No.07 森田秀幸
 ( @emeitch、http://emeitch.com/ )
こんにちは、森田秀幸(@emeitch)です。オブジェクト倶楽部では、ライバル団
体であるファンクション倶楽部系記事の寄稿や発表をしたりしてます。ここで
は自己紹介がてら、最近私が凝っていることを紹介させて下さい。

最近、私が凝っているは「ビジョンを中心とした開発」というテーマの研究で
す。

具体的に言うと「どうやって作るのか?」と「何を作るのか?」と「何故作る
のか?」という疑問は絶対的なものではなく、互いに相対的なもので、その先
に何を置くべきかという話です。

「○○機能が欲しいです。」
「何故ですか?」
「△△を実現したいからです。」
「何故ですか?」
「□□したいからです。」
「何故ですか?」
  ...

この連鎖に置いて「△△」は、「何を作るのか?」の疑問の答えであり、○○
に対する「何故作るのか?」疑問の答え(の一部)であり、□□に対する「どう
やって作るのか?」という疑問の答え(の一部)にもなっています。この関係は
相対的で、階層のどのレベルでも起こりえます。

そうなったとき、「何故作るのか?」の最終的な答えはどこにあるんでしょう?
その終着点は「ビジョン」にあると、私は考えています。

「そのビジョンって何よ?」と思った、そこのあなた。次回のオブラブイベン
トで私と議論でもしましょうか?(森田秀幸)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は   ⇒/community/object_ml/
■ 発行:オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.