Date:  Wed, 10 Nov 2010 18:20:48 +0900
Subject:  【オブジェクト倶楽部: 2010-42号】
X-Mail-Count: 00360

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          No.350 2010/11/10

■ I N D E X
┃
┣【Topics】アジャイルプロセス協議会四国支部立ち上げイベント(11/21)
┣【プログラミング】Let's Try 受入テスト [10]
┣【要件定義】要求とか要件についての四方山話 [7]
┃           〜否定から入らずに確認する〜
┗ 編集後記

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
 〇 アジャイルプロセス協議会四国支部立ち上げイベント(11/21)
  〇 〇━━━━━━━━━━━━━ ━━・ 

来る2010年11月21日(日)、愛媛大学において、アジャイルプロセス協議会 四国
支部 立ち上げのイベントを開催することとなりました。

2003年より発足したアジャイルプロセス協議会ですが、これまで四国において
は独立した支部という形がとれていませんでした。

この度、四国においてもアジャイル開発についての話題、情報共有ができるよ
う、四国支部という形で立ち上げる運びとなりました。近県の方には、この機
会に是非ご来場頂けますよう、よろしくお願い申しあげます。

日 時:2010年11月21日(日) 13時30分〜17時30分(開場 13時00分)
場 所:愛媛大学 工学部 4号館 1階 18番教室(愛媛県 松山)
詳 細:http://www.agileprocess.jp/modules/eguide/event.php?eid=37

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

● Cucumberの電子書籍の紹介
達人出版会からCucumberの電子書籍が出ました。
『はじめる! Cucumber』
 http://tatsu-zine.com/books/cuke
Cucumberの解説が日本語で読める数少ない電子書籍になっています。
おすすめです。

● はじめに
本連載は、ツール編に入り、Cucumberについて解説しています。
前回は、Scenario Outline: & Examples: を使った記述を解説しました。
詳細は、下記をご覧ください。
/ml-arch/magazine/355.html

今回は前回とは異なる表を使った記述方法について解説します。
前回は、ステップの連なりをアウトライン化し、Examples: でステップの連な
りを具体化するのに表を利用していましたが、今回は、あるステップ内(例えば
Then)の記述を簡潔わかりやすくするために、表の記述を利用します。

● サンプル
https://github.com/haru01/rails3-sample/
にサンプルをつくってみました。抜粋します。

https://github.com/haru01/rails3-sample/blob/master/features/manage_posts.feature
-----------------------------------------------------------
Feature: ....
....

 Scenario: Delete post
  #1
  Given the following posts:
    |title|body|published|
    |title 1|body 1|false|
    |title 2|body 2|true|
    |title 3|body 3|false|
    |title 4|body 4|true|
  #2
  When I delete the 3rd post
  #3
  Then I should see the following posts:
    |Title|Body|Published|
    |title 1|body 1|false|
    |title 2|body 2|true|
    |title 4|body 4|true|
-----------------------------------------------------------

ブログサービスの一覧画面のようなものをイメージしてください。
title、body、published属性を持ったPostが、モデル要素です。

#1のGivenで4つのpostオブジェクトを準備しています。
(重複してGivenを呼ぶ代わりに)簡潔に事前条件を表で記述しています。
#2のWhenで3番目のpostの削除の操作をしています。
#3のThenで三番目のpostを除いた3つのposts一覧が表示していること確認して
います。
表で期待値を記述しています。
(重複して3回Thenを呼ぶ代わりに)簡潔に表で期待結果を記述しています。

● ステップ定義は?
https://github.com/haru01/rails3-sample/blob/master/features/step_definitions/post_steps.rb
を参考にしてください。

Thenステップ定義のみ、解説します。

-----------------------------------------------------------
....
Then /^I should see the following posts:$/ do |expected_posts_table|
 expected_posts_table.diff!(tableish('table tr', 'td,th'))
end
-----------------------------------------------------------

expected_posts_tableは、featureファイル内に表形式で記述した期待値に相当
します。
tableish('table tr', 'td,th')は、HTMLの表示結果から表の実績値の部分を抜
き出しています。diff!は、期待値と実績値の比較を行っています。

● まとめ
ステップ(Given、Then)中に表を記述する例を紹介しました。前提条件のデータ
を表で用意したり、期待結果と実績値の比較を表で行いたい時などに便利な機
能です。

表を使わず、Given、When、Thenのステップが煩雑に記述された箇所を見つけた
場合、表で記述することで、システムの期待する振る舞いが簡潔にわかりやす
くに記述できないか検討すると良いでしょう。(IENAGA)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【要件定義】要求とか要件についての四方山話 [7]
┗           〜否定から入らずに確認する〜

こんにちは、平田です。

今回も身近な出来事で少し気になったことがあったので紹介します。
私の所属する部署では、部内でwikiを共有していて、日付ごとのページを作っ
て運用していくということをやっています。その日付ごとのwikiページがいつ
の間にかその日になるとできているので、誰かが手で作ってくれているんだろ
うなと思っていたのですが、ある打ち合わせの中で上司がやっていることがわ
かりました。

それに対して、普段の仕事の中で「自動化」などの努力をしてチームの活性化
や効率化を担っているメンバーの人たちは、「そんなのは手で作るんじゃなく
て、cronでまわして日次で作っていけば・・・」などの意見をいきなりぶつけ
はじめました。私には「なぜそんな非効率なことを手で続けているんだ?」と
詰問しているように聞こえて、いたたまれなくなりました。

チームのふりかえりを進めるにあたっての重要な考え方のひとつに、ふりかえ
り最優先条項[*1]というものがあります。これは、ふりかえりを進める際に、
チームのメンバーがそのときの状況の中で最善を尽くしたということを信じて
進めていくという話です。
これはチーム運営、その中のふりかえりで有用なものとしてあげられているの
ですが、実は、システムを作っていこうとする際の、お客様との関係の中でも
重視しないといけないものだと気づきました。

どんなに非効率に見えるやり方でも、そのやり方を採用するには何らかの理由
や経緯が存在するわけだし、誰かがやっていることの否定から入るのは絶対に
やってはいけないと思います。特にプログラミングやシステム開発のことをあ
まり知らないお客様が相手の場合はなおさらです。

とはいえ、非効率なやり方というのはなんとかしたいですよね。なんらかの方
法で解決に結び付けたいです。強力なのは、今の方法を採用している理由を尋
ねるというものです。理由を聞く質問と言えば「なぜ?」という言葉が思い浮
かびますが、これは要注意です。聞かれたほうはどうしても詰問されている印
象を受けてしまいます。これは言葉を変えて「今、〜〜というやり方をされて
いますが、この理由を教えてください」のようにするだけでも相手が受ける印
象を柔らかくすることができるでしょう。

理由を直接的に聞いても、「なんとなく」「前任者からそう教えられたので」
という答えが出てくることもあるでしょう。それでも理由を知りたいと感じて
しまう場合、実は聞き手側が答えを持っていることが多いです。お客様として
は特に不満は感じていないけれど、開発者から見ると非効率に見えてしまう場
合などです。お客様は、ソフトウェアに任せる方法を知らないか、頼むとコス
トがかかるのではないか、などの心配をしているのでしょう。
上述の例だと「ページを作る作業をプログラムに任せることができますが、そ
れと手動だとどちらがよいですか?」と提案してみましょう。おそらくこの例
では、手動でやることもそれほど苦ではないので、タダだったら作ってよとい
う話になるでしょう。もしかすると毎朝仕事に集中する儀式としてやっていて
外せないのかもしれません。
どういう答えが返ってくるにせよ、今の方法を選択している理由を明確にする
ことができ、他の要求とのトレードオフができる状態にすることができます。
(もしくは、要求ではないことが明確になるでしょう)

現状行っている業務への疑問を感じるということは必要なことですが、詰問調
にならないよう、相手の立場にたった発言を心がけたいですね。まず相手のこ
れまでを受け入れるということを最初に考えていきたいです。今回の出来事を
通じて、自戒をこめて思いました。

ところで、最初に書いた日付単位のwikiページの作成ですが、いろいろと発言
はあったもののいまだ手動で作られています・・・。(平田)

[*1]ふりかえり最優先条項
    http://www.infoq.com/jp/news/2008/03/retrospective-prime-directive

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

こんにちは、編集人のナガタユウコです。先日お声かけいただき、「LT祭り」
にてドラ娘業をしてきました!
『LT祭り』 http://kokucheese.com/event/index/5240/
LT祭りはその名の通り、LTの作り方、LTでより想いを伝えるための工夫、そし
てLT本番、懇親会でも飛び入りLTを開催など、まさにLTのためのイベントでし
た。私はLTで発表したことはないのですが、一度発表してみたい、と思える、
そんな素晴しいイベントでした。参加者の方の感想もたくさんWeb上にアップさ
れているようですので、読んでみてくださいね。そしてぜひ、オブラブイベン
トのLTで発表してください☆(ナガタユウコ)

*** オブラブスタッフ自己紹介 ***
No.29 えむ。
こんにちは。たまにオブジェクト倶楽部のMLに登場するえむ。です。
私とオブラブの関係ですが、イベントでの発表では、若人トラックというコー
ナーで、LinuxカーネルについてやSTMについて話したりと、オブジェクト指向
とはまったく関係の無い話をする担当です。
さて、ここで私的な告知をさせていただきます。以前、オブラブに『Ruby逆引
きレシピ』をプレゼントとして提供してくださったRuby札幌のみなさんが開催
する、札幌Ruby会議03にてLTでお話してきます。
http://regional.rubykaigi.org/sapporo03
私以外にも、オブラブのメンバーからは、柴田メンバーと角谷メンバーが本編
で発表します。ご都合があう方は、是非ご参加ください。(えむ。)

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