「アレグザンダー祭り」はおかげさまで大盛況のうちに終了しました。イベントにご参加いただいたみなさま、本当にありがとうございました!今回のイベントのソーシャルタグは以下の通りです。イベントのご感想など、ぜひお聞かせください。はじめに本連載のテーマは受入テストです。Teamと受入テストの関係について、説明します。本日のまとめチームが受入テストに早期着手することで、何を作るべきか、そのフィーチャ(機能)が実現したか否かの判断項目をチームで明確に共有できます。立つソフトウェアができることが期待できます。Writers、Users、そしてProgrammers[*1]が協力し合い、よい仕事をして、ビジネス価値の高い成果を出す集団を指します。ところが、単に人が集まっただけでは、各人はばらばらに考えて行動してしまい、システムに対する共通のイメージは作られず、役に立たないソフトウェアができてしまいます。Test)が一案として上げられます。イテレーション内の早期に、受入テストに着手するのです。[*2]早期にテストに着手する様子は、メタファーとして、ラグビー[*3]のチームメンバーが横一線に走りながら、ボールをまわしゴールに向かうようなイメージです。早期に受入テストに着手することで、要件定義とテストの工程が重なり合い、チームメンバーが密に協力し合う状況を作り出します。Design、ユーザマニュアルを早期に書く、CRCで演劇を取り入れる等も有効な手段と考えられますが、ここでは触れません。gap[*4]を参考に、受入テストの活動は、次のようなものを指しています。Teamにおける受入テストのポイントは?"ユーザ目線"エンドユーザ目線でシステムの期待する振る舞いを明確にする必要があります。プログラマ目線では、何を作るべきかをチームで共有できたとは言えません。"具体的に"テスト可能なほど考えてられていないのであれば、何を作ればよいのかチームで共有できていない問題を含んでいるかもしれません。受入に自動テスティングフレームワークを採用する場合は、プラックボックステストがコンピュータで実行な可能なレベルまで具体的に考えることになります。発の成功を導く重要なキー要です。Thenを使うアプローチ)については、後の連載でテーマに挙げたいと思います。"くりかえす"テストは、プロジェクトの終盤のみに行うのではなく、毎回イテレーションで行い、何を作るべきかを定期的に擦り合わせすることが好ましいです。Lean界隈で一部に広まっている一個流しのアイデアを採用する場合は、上記のサイクルは、イテレーションよりもさらに短いものになります。まとめチームが受入テストに早期着手し、何を作るべきか、そのフィーチャ(機能)が実現したか否かの判断項目を、チームで明確に共有することで、役立つソフトウェアができることが期待できます。次回は、アレグザンダーの思想と受入テストの関係について触れたいと思います。チームメンバーの分類はXP2ndを参考にしました。テストに着手するアイデアは、上記の本で言及されているそうです。gap』経由で知りました。Scrumに影響を与えています。集まっているチームと比べ、会話の発生が制限されてしまいます。うまく組み合わせるプロジェクト運営の工夫が必要かもしれませんね。〜昨年のふりかえりと今年の抱負〜明けましておめでとうございます、平田です。この連載の新年1回目ということで、昨年のふりかえりと今年の抱負を書きたいと思います。昨年から連載で書いてきた内容は主として、要求を引き出すシーンでステークホルダーとどのようにコミュニケーションしていくかについて、そしてそのようなシーンで使える(かもしれない)Tipsをあげてきました。これらは、筆者が日常の仕事で中心的に活動しているエリアで、日頃苦労しつつも多少なりともうまくいっていることを紹介することができたと思っています。今年のこれからの連載の中では、筆者自身も悩んでいる、迷っている要件定義に関することについて、テーマを選んで書いていきます。テーマの候補は以下のようなものです。何を書けばいいの?・アジャイル開発での要求の取り扱い方って?などなど、いろいろなことを考えながら進めていきます。それでは、今年もよろしくお願いします。┗編集後記こんにちは、編集人のナガタユウコです。12月の忘年会イベント、そして先週のアレグザンダー祭りと、2ヶ月連続でイベントを開催しました。「準備が間に合わないのでは」と心配していたのですが、参加者のみなさまや講演者の方々、そしてスタッフに支えられ、無事終了することができました。本当にありがとうございました!次回以降のイベントでもまたお目にかかれますことを楽しみにしております。お願いします!そして今週から、『オブラブスタッフ自己紹介』を連載開始します。)こんにちは、天野勝です。私はオブジェクト倶楽部の事務局長として、企画や予算の承認をしています。メールマガジンのレビューアとして、記事の質向上にはげんでいます。オブジェクト倶楽部は、私にとって「先生」のような存在です。私が「ちゃんとプログラムを書かないといけない」と考えるきっかけをくれました。その存在を知ったのは2000年の頃で、ブログラムなんて動けばそれでいいという考えで日々の作業をこなしていました。そのような時にXPという開発方法があると聞き、辿り着いたのがオブジェクト倶楽部でした。そこには、XPの12のプラクティスが紹介されており、そのプラクティスのひとつとしてコーディング標準がありました。Javaのコーディング標準が公開されていました。それを読んだ時の衝撃は今でも忘れられません。そのうちなんだかんだで、いつのまにか永和システムマネジメントに転職し、さらには事務局長を務めるようになりました。今ではメンバーも増え、いろいろな事にみんなが取り組んでいます。それを私に教えてくれます。今でもオブジェクト倶楽部は、私にとっての先生です。