┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.311 2010/01/20
■ I N D E X
┃
┣【Topics】「アレグザンダー祭り」終了しました！
┣【プログラミング】Let's Try 受入テスト [2]
┣【要件定義】プログラマにも役立つ要件定義の技術 [6]acc
┗ 〜昨年のふりかえりと今年の抱負〜
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 「アレグザンダー祭り」終了しました！
〇 〇━━━━━━━━━━━━━ ━━・
「アレグザンダー祭り」はおかげさまで大盛況のうちに終了しました。イベン
トにご参加いただいたみなさま、本当にありがとうございました！
今回のイベントのソーシャルタグは以下の通りです。イベントのご感想など、
ぜひお聞かせください。お待ちしております！
twitter: #oblove
ソーシャルブックマーク: #oblove2010alexander
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】Let's Try 受入テスト [2]
● はじめに
本連載のテーマは受入テストです。今日は、XP(エクストリームプログラミング)
でおなじみのWhole Teamと受入テストの関係について、説明します。
● 本日のまとめ
チームが受入テストに早期着手することで、何を作るべきか、そのフィーチャ
(機能)が実現したか否かの判断項目をチームで明確に共有できます。結果、役
立つソフトウェアができることが期待できます。
● Whole Team(チーム全体)とは？
Whole Teamは、プロジェクトによってメンバー構成は異なりますが、Testers、
Interaction Designers、Architects、Project Managers、Product Managers、
Exectives、Techincal Writers、Users、そしてProgrammers[*1]が協力し合い、
よい仕事をして、ビジネス価値の高い成果を出す集団を指します。Whole Team
を別の言葉で言い換えるなら、機能横断チーム(Cross functional Team)です。
ところが、単に人が集まっただけでは、各人はばらばらに考えて行動してしま
い、システムに対する共通のイメージは作られず、役に立たないソフトウェア
ができてしまいます。
● Whole Teamで システムの共通理解を得るには？
では、具体的にどのようにして、チーム全体で何を作るべきかの認識を擦り合
わせ、ソフトウェアというひとつの形にしていくのでしょうか？
そこで、受入テスト(Acceptance Test)が一案として上げられます。
イテレーション内の早期に、受入テストに着手するのです。[*2]
早期にテストに着手する様子は、メタファーとして、ラグビー[*3]のチームメ
ンバーが横一線に走りながら、ボールをまわしゴールに向かうようなイメージ
です。早期に受入テストに着手することで、要件定義とテストの工程が重なり
合い、チームメンバーが密に協力し合う状況を作り出します。
(何を作るべきかの認識を擦り合わせる別案として、プロダクトビジョンボック
ス、エレベータステートメント、メタファー、ペーパープロトタイプ、プロト
タイプ、ユーザストーリ、計画ゲーム、早期リリースとデモ、ユースケース、
ビジネスDSL、Domain Driven Design、ユーザマニュアルを早期に書く、CRCで
演劇を取り入れる等も有効な手段と考えられますが、ここでは触れません。)
● Whole Teamにおける受入テストの活動内容は？
本連載の中では、brigding the commnunication gap[*4]を参考に、受入テスト
の活動は、次のようなものを指しています。
- "ユーザ目線"でシステムの期待する振る舞いを
テスト可能なレベルで"具体的に"チームで"会話する"
- テストのチェック項目の作成する
- テストを実施し、要求を満たしているかを確認する
- 上記を"くりかえす"
● Whole Teamにおける受入テストのポイントは？
"ユーザ目線"
エンドユーザ目線でシステムの期待する振る舞いを明確にする必要があります。
プログラマ目線では、何を作るべきかをチームで共有できたとは言えません。
"具体的に"
テスト可能なほど考えてられていないのであれば、何を作ればよいのかチーム
で共有できていない問題を含んでいるかもしれません。
受入に自動テスティングフレームワークを採用する場合は、プラックボックス
テストがコンピュータで実行な可能なレベルまで具体的に考えることになりま
す。
"会話する"[*5]
会話の重要性はUser Stories Applied[*6]でも語られており、ソフトウェア開
発の成功を導く重要なキー要です。
会話のレシピ(ユーザストーリを使ったアプローチ、テーブルを使ってExample
を出すアプローチ、Given When Thenを使うアプローチ)については、後の連載
でテーマに挙げたいと思います。
"くりかえす"
テストは、プロジェクトの終盤のみに行うのではなく、毎回イテレーションで
行い、何を作るべきかを定期的に擦り合わせすることが好ましいです。また、
Lean界隈で一部に広まっている一個流しのアイデアを採用する場合は、上記の
サイクルは、イテレーションよりもさらに短いものになります。
● まとめ
チームが受入テストに早期着手し、何を作るべきか、そのフィーチャ(機能)が
実現したか否かの判断項目を、チームで明確に共有することで、役立つソフト
ウェアができることが期待できます。
次回は、アレグザンダーの思想と受入テストの関係について触れたいと思いま
す。(IENAGA)
● 備考
[*1] 『Extreme Programming Explained:Embrace Change(2nd Edition)』Kent Beck
http://www.amazon.co.jp/exec/obidos/ASIN/0321278658/xpjp-22
http://www.amazon.co.jp/exec/obidos/ASIN/4894716852/xpjp-22
チームメンバーの分類はXP2ndを参考にしました。
[*2] 『Exploring Requirements』Donald C. Gause、Gerald M. Weinberg
http://www.amazon.co.jp/exec/obidos/ASIN/0932633137/xpjp-22
要求に対する誤解を減らすために、要件定義の段階でブラックボックス
テストに着手するアイデアは、上記の本で言及されているそうです。
『bridging the communication gap』経由で知りました。
[*3] 『The New New Product Development Game』竹内弘高、野中郁次郎両氏の論文
http://apln-richmond.pbwiki.com/f/New+New+Prod+Devel+Game.pdf
ラグビーのメタファをつかったチーム活動の説明は、竹内弘高、野中郁
次郎両氏の論文「The New New Product Development Game」が有名で、
Scrumに影響を与えています。
[*4] brigding the commnunication gap Gojko Adzic
http://www.acceptancetesting.info/
本連載の中核となる参考文献はこれです
[*5] 会話
ただし、私の関わるプロジェクトでもよくあることですが、要件に詳し
い人、開発者、テスターが地理的に分散したチームの場合は、一ヶ所に
集まっているチームと比べ、会話の発生が制限されてしまいます。
ドキュメントと会話(ミーティング／電話／テレビ会議／チャット等)を
うまく組み合わせるプロジェクト運営の工夫が必要かもしれませんね。
[*6] 『User Stories Applied』Mike Cohn
http://www.amazon.co.jp/exec/obidos/ASIN/0321205685/xpjp-22
● 過去の連載一覧
1) /ml-arch/magazine/316.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【要件定義】プログラマにも役立つ要件定義の技術 [6]
┗ 〜昨年のふりかえりと今年の抱負〜
明けましておめでとうございます、平田です。
この連載の新年1回目ということで、昨年のふりかえりと今年の抱負を書きたい
と思います。
昨年から連載で書いてきた内容は主として、要求を引き出すシーンでステーク
ホルダーとどのようにコミュニケーションしていくかについて、そしてそのよ
うなシーンで使える(かもしれない)Tipsをあげてきました。
これらは、筆者が日常の仕事で中心的に活動しているエリアで、日頃苦労しつ
つも多少なりともうまくいっていることを紹介することができたと思っていま
す。
今年のこれからの連載の中では、筆者自身も悩んでいる、迷っている要件定義
に関することについて、テーマを選んで書いていきます。テーマの候補は以下
のようなものです。
・そもそも要求ってなんだろう？
・要求と要件って？
・要求仕様書、要件定義書って何を書けばいいの？
・アジャイル開発での要求の取り扱い方って？
などなど、いろいろなことを考えながら進めていきます。
それでは、今年もよろしくお願いします。(平田)
● 過去の連載一覧
1) /ml-arch/magazine/291.html
2) /ml-arch/magazine/297.html
3) /ml-arch/magazine/303.html
4) /ml-arch/magazine/308.html
5) /ml-arch/magazine/315.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人のナガタユウコです。12月の忘年会イベント、そして先週
のアレグザンダー祭りと、2ヶ月連続でイベントを開催しました。企画当初は、
「準備が間に合わないのでは」と心配していたのですが、参加者のみなさまや
講演者の方々、そしてスタッフに支えられ、無事終了することができました。
本当にありがとうございました！次回以降のイベントでもまたお目にかかれま
すことを楽しみにしております。どうぞ、よろしくお願いします！
そして今週から、『オブラブスタッフ自己紹介』を連載開始します。こちらも
よろしくお付きあいくださいませ☆(ナガタユウコ)
*** オブラブスタッフ自己紹介 ***
No.01 天野勝
( @amapyon, http://d.hatena.ne.jp/amapyon/ )
こんにちは、天野勝です。私はオブジェクト倶楽部の事務局長として、企画や
予算の承認をしています。また、メールマガジンのレビューアとして、記事の
質向上にはげんでいます。
オブジェクト倶楽部は、私にとって「先生」のような存在です。私が「ちゃん
とプログラムを書かないといけない」と考えるきっかけをくれました。初めて
その存在を知ったのは2000年の頃で、ブログラムなんて動けばそれでいいとい
う考えで日々の作業をこなしていました。そのような時にXPという開発方法が
あると聞き、辿り着いたのがオブジェクト倶楽部でした。そこには、XPの12の
プラクティスが紹介されており、そのプラクティスのひとつとしてコーディン
グ標準がありました。そして、Javaのコーディング標準が公開されていました。
それを読んだ時の衝撃は今でも忘れられません。
そのうちなんだかんだで、いつのまにか永和システムマネジメントに転職し、
さらには事務局長を務めるようになりました。今ではメンバーも増え、いろい
ろな事にみんなが取り組んでいます。そして、それを私に教えてくれます。今
でもオブジェクト倶楽部は、私にとっての先生です。(天野勝)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は ⇒/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2003-2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.