立ち上げのイベントを開催することとなりました。2003年より発足したアジャイルプロセス協議会ですが、これまで四国においては独立した支部という形がとれていませんでした。この度、四国においてもアジャイル開発についての話題、情報共有ができるよう、四国支部という形で立ち上げる運びとなりました。会に是非ご来場頂けますよう、よろしくお願い申しあげます。達人出版会からCucumberの電子書籍が出ました。http://tatsu-zine.com/books/cukeCucumberの解説が日本語で読める数少ない電子書籍になっています。はじめに本連載は、ツール編に入り、Cucumberについて解説しています。使った記述を解説しました。詳細は、下記をご覧ください。http://ObjectClub.jp/ml-arch/magazine/355.html今回は前回とは異なる表を使った記述方法について解説します。ステップの連なりを具体化するのに表を利用していましたが、今回は、あるステップ内(例えばThen)の記述を簡潔わかりやすくするために、表の記述を利用します。サンプルhttps://github.com/haru01/rails3-sample/にサンプルをつくってみました。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ステップ定義のみ、解説します。'td,th'))end-----------------------------------------------------------expected_posts_tableは、featureファイル内に表形式で記述した期待値に相当します。'td,th')は、HTMLの表示結果から表の実績値の部分を抜き出しています。diff!は、期待値と実績値の比較を行っています。まとめステップ(Given、Then)中に表を記述する例を紹介しました。表を使わず、Given、When、Thenのステップが煩雑に記述された箇所を見つけた場合、表で記述することで、システムの期待する振る舞いが簡潔にわかりやすくに記述できないか検討すると良いでしょう。〜否定から入らずに確認する〜こんにちは、平田です。今回も身近な出来事で少し気になったことがあったので紹介します。私の所属する部署では、部内でwikiを共有していて、日付ごとのページを作って運用していくということをやっています。その日付ごとのwikiページがいつの間にかその日になるとできているので、誰かが手で作ってくれているんだろうなと思っていたのですが、ある打ち合わせの中で上司がやっていることがわかりました。それに対して、普段の仕事の中で「自動化」などの努力をしてチームの活性化や効率化を担っているメンバーの人たちは、「そんなのは手で作るんじゃなくて、cronでまわして日次で作っていけば・・・」などの意見をいきなりぶつけはじめました。私には「なぜそんな非効率なことを手で続けているんだ?」と詰問しているように聞こえて、いたたまれなくなりました。チームのふりかえりを進めるにあたっての重要な考え方のひとつに、ふりかえり最優先条項[*1]というものがあります。これは、ふりかえりを進める際に、チームのメンバーがそのときの状況の中で最善を尽くしたということを信じて進めていくという話です。これはチーム運営、その中のふりかえりで有用なものとしてあげられているのですが、実は、システムを作っていこうとする際の、お客様との関係の中でも重視しないといけないものだと気づきました。どんなに非効率に見えるやり方でも、そのやり方を採用するには何らかの理由や経緯が存在するわけだし、誰かがやっていることの否定から入るのは絶対にやってはいけないと思います。プログラミングやシステム開発のことをあまり知らないお客様が相手の場合はなおさらです。いえ、非効率なやり方というのはなんとかしたいですよね。法で解決に結び付けたいです。強力なのは、今の方法を採用している理由を尋ねるというものです。理由を聞く質問と言えば「なぜ?」という言葉が思い浮かびますが、これは要注意です。象を受けてしまいます。象を柔らかくすることができるでしょう。理由を直接的に聞いても、「なんとなく」「前任者からそう教えられたので」という答えが出てくることもあるでしょう。それでも理由を知りたいと感じてしまう場合、実は聞き手側が答えを持っていることが多いです。お客様は、ソフトウェアに任せる方法を知らないか、頼むとコストがかかるのではないか、などの心配をしているのでしょう。上述の例だと「ページを作る作業をプログラムに任せることができますが、それと手動だとどちらがよいですか?」と提案してみましょう。この例では、手動でやることもそれほど苦ではないので、タダだったら作ってよという話になるでしょう。すると毎朝仕事に集中する儀式としてやっていて外せないのかもしれません。いう答えが返ってくるにせよ、今の方法を選択している理由を明確にすることができ、他の要求とのトレードオフができる状態にすることができます。(もしくは、要求ではないことが明確になるでしょう)現状行っている業務への疑問を感じるということは必要なことですが、詰問調にならないよう、相手の立場にたった発言を心がけたいですね。相手のこれまでを受け入れるということを最初に考えていきたいです。今回の出来事を通じて、自戒をこめて思いました。ところで、最初に書いた日付単位のwikiページの作成ですが、いろいろと発言はあったもののいまだ手動で作られています・・・。┗編集後記こんにちは、編集人のナガタユウコです。http://kokucheese.com/event/index/5240/LT祭りはその名の通り、LTの作り方、LTでより想いを伝えるための工夫、そしてLT本番、懇親会でも飛び入りLTを開催など、まさにLTのためのイベントでした。私はLTで発表したことはないのですが、一度発表してみたい、と思える、そんな素晴しいイベントでした。参加者の方の感想もたくさんWeb上にアップされているようですので、読んでみてくださいね。