┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.355 2010/12/15
■ I N D E X
┃
┣【Topics】ジェフ・サザーランドのスクラムプロダクトオーナー研修
┣【要件定義】要求とか要件についての四方山話 [8]
┃ 〜何かを仮定していないかを疑う〜
┣【プログラミング】Let's Try 受入テスト [11]
┗ 編集後記
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 ジェフ・サザーランドのスクラムプロダクトオーナー研修
〇 〇━━━━━━━━━━━━━ ━━・
こんにちは！かわぐちと申します。
オブラブ夏イベントでは「はじめてのスクラム」のセッションのツッコミを担
当させていただきました。
みなさま、スクラムってご存知でしょうか？北米・欧州でとっても普及してい
るチームでの製品開発の「フレームワーク」です。ジェフ・サザーランドとケ
ン・シュウェイバーの2人が、日本のリーン文化やソフトウェアのエンジニアリ
ングプラクティスを取り入れて作ったものです。
最近は「認定スクラムマスター持ってると就職に有利」なんて、想像を超える
世界が、新大陸にはあるらしいです。どどーん。
先週来日したジム・コプリエンさん[*1]によると、当初、Smalltalkで実装した
フレームワークだったのを、Smalltalk部分を取り去って「なんでも入る箱」に
したのが、現在のスクラムなんだそうです。原型で型取りして、型を抜いてフ
レームワークにするというのは、面白いアプローチだな、と思いました。そう
いえば、奈良の大仏さんもそういう風に作ったと、中学校で習った気がします。
ごーーーん。(鐘の音)
そうそう、スクラムというのは竹内先生・野中先生の論文「The New New Product
Development Game」にでてくる、新製品開発チームの協業の形態をラグビーの
スクラムに似ていると表現したところからきています。昨年、ジェフ・サザー
ランドさんにビデオメッセージ[*2]をもらったんですが、「日本人はアジャイ
ルできるはず」といわれて、なんかとても悔しかったですよ。ゴゴゴゴゴゴ。
私がスクラムのやり方を学ぶにしたがって、一番、つかみどころがないな、と
感じるのは「プロダクトオーナーってどうすればいいの？」ということです。
プロダクトバックログ項目(PBI)を書いて優先度をつける、というのが定義なの
ですが、ではそのバックログ項目はどこからくるのか、どうやって洗い出すの
か、優先度を変えるべきかどうかはどうやって知るのか、どの程度の粒度でPBI
を書くのか。チームにとってプロダクトオーナーはやりたくないことを丸投げ
してるんじゃないか。プロダクトオーナーからみて、チームに丸投げにならな
いようにするにはどうしたらいいか。日本の受託契約の文脈でプロダクトオー
ナーはだれが、どうやればうまくいくのか。
というわけで、そんな私の疑問点に答えるべく(違う)、年始にジェフ・サザー
ランドさんが初来日します。日本初上陸の認定スクラムプロダクトオーナーセ
ミナーがあります。野中郁次郎先生との初顔合わせもあります。初・初・初と
年始から景気のいいことですね。すばらしい業績を持っている人は、みんなで
質問攻めにすべき、と考えます。ぜひぜひ多くの方のご参加をお待ちしており
ます。
もしかすると、普段はアジャイルに拒否反応を示しちゃうような方とか、コー
ディングのプラクティスそのものには興味が薄い方でも「製品開発の話です」
「要件定義と優先度付けの話です」「組織とイノベーションの話です」「野中
先生の講演です」というような文脈でご紹介頂けるとよいかもしれません。実
は興味がある方がスルーしてしまっていないか、ご確認いただければ幸いです。
決して勧誘ではありません。必要なのは確認です。(かわぐち)
▼ジェフサザーランドさんのCSPO認定スクラムプロダクトオーナーセミナー
(2011年1月11日〜12日)
http://d.hatena.ne.jp/wayaguchi/20101203/1291319690
▼Innovation Sprint 2011 −競創時代の新製品／新サービス開発とは−
(1月13日)
http://innovationsprint.com/
[*1] ジム・コプリエンさんのセミナーの報告はこちらです
http://d.hatena.ne.jp/wayaguchi/20101212/1292118782
[*2] ジェフサザーランドさんのビデオメッセージはこちらです
http://www.youtube.com/watch?v=UemyLH3pv0U
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【要件定義】要求とか要件についての四方山話 [8]
┗ 〜何かを仮定していないかを疑う〜
こんにちは、平田です。
今日は「何かを仮定していないかを疑う」ということについてお話をしたいと
思います。
要件定義というアクティビティに限らず、何かを行うときには必ずその事前の
知識というものが存在していると思います。その知識がなければ、自分に入っ
てくるインプットに対する反応ができないでしょう。
こういう前提知識や共通認識はうまく使うと、理解を早めるのでとても良いの
ですが、共有できていない人同士の場合、注意深く進める必要があります。
たとえば、業務に精通しているユーザの方と、システムを作ることを専門にし
ている開発者の間では、共通認識を持てていることはそう多くないでしょう。
そんなときには当然、一緒に会話した結果や体験したことでさえ、別の受け取
り方をしていることがあります。「この書類には収入印紙を貼る必要があるけ
れど、取引金額が低い場合貼らないこともある」など、業務をやっている人に
とっては常識でも、ふだん収入印紙などに関わらない人たちにとっては、思っ
てもないようなことかもしれません。
そんなときに自問自答するとよいのが、「自分たちは何かを仮定して進めてい
ないか」ということです。「この書類を受領したときには、収入印紙を貼って
いるかどうかチェックすること」という要求を受け取って、「収入印紙の貼っ
ていない書類はバリデーションエラーにする」などという仕様、実装にしてし
まうことはありがちではないでしょうか？そんなとき、、「収入印紙は無条件
で貼られているのが正常である」ということを、自分たちで勝手に仮定してし
まっていないか、というのを疑ってかかるべきだと思います。
これは逆の場合でも同じことが言えます。開発者にとって常識の技術的制約な
ので、特にそれをお客様に伝えることなく済ませてしまってはいないか、常に
確認を怠ってはいけないと思います。
今回は、「何かを仮定していないかを疑う」ということについて書きました。
もし、仮定している部分を見つけたら、それはお客様に確認することが必要で
すね。(平田)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】Let's Try 受入テスト [11]
● はじめに
本テーマは、受入テストです。現在はツール編に入りCucumberの記述法ついて
解説しています。今日は、簡単なイディオム[*]の紹介です。
● [*]を使ったステップの省略
通常、Cucumberは、Given(前提)、When(もし)、Then(ならば)のステップを使っ
てシステムの期待する振る舞いを記述します。
ただ、記述する際に3ステップの明確な区分が重要でない場合、[*]で省略する
ことも可能です。例を見てみましょう。
● [*]の例
下記は、cucumberのインストール先の
examples/i18n/en/features/division.feature
のサンプル抜粋です。
======
Scenario: Regular numbers
* I have entered 3 into the calculator
* I have entered 2 into the calculator
* I press divide
* the result should be 1.5 on the screen
=======
もしGiven、When、Then、(And)を[*]省略しなければ、下記のように記述するで
しょう。
======
Scenario: Regular numbers
Given I have entered 3 into the calculator
And I have entered 2 into the calculator
When I press divide
Then the result should be 1.5 on the screen
=======
[And]の文字が、文全体のGiven、When、Thenの構造を読みにくくしていると感
じる場合は、Andのかわりに[*]を使うのも一つの手でしょう。
======
Given _____________
* __________________
* __________________
When _____________
Then _____________
* __________________
* __________________
=======
● まとめ
ステップのキーワードの省略[*]を紹介しました。通常は、BDDのステップの考
えに乗っ取って、Given、When、Thenを明記することがおすすめです。が、どう
してもGiven、When、Thenの記述がしっくりこないと感じる場合は、[*]で省略
すると良いでしょう。
次回以降ですが、ちょっと寄り道して、Fitの紹介、その後、もう一度Cucumber
に戻ってStep記述詳細について解説していこうと予定しています。(IENAGA)
● 過去の連載
1) /ml-arch/magazine/316.html
2) /ml-arch/magazine/321.html
3) /ml-arch/magazine/325.html
4) /ml-arch/magazine/330.html
5) /ml-arch/magazine/334.html
6) /ml-arch/magazine/338.html
7) /ml-arch/magazine/345.html
8) /ml-arch/magazine/349.html
9) /ml-arch/magazine/355.html
10) /ml-arch/magazine/360.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人のナガタユウコです。オブラブ特製カレンダー2011のプレ
ゼントはまだまだご応募受付中です。ご希望の方は下記のフォームからご応募
くださいね☆このチャンスを逃すと二度と手に入らない(かもしれない)特製カ
レンダーですので、お急ぎ下さい！みなさまのご応募をお待ちしております！
(ナガタユウコ)
▼オブラブカレンダー2011 プレゼント応募はコチラから↓
http://bit.ly/oblove-calendar-2011
*** オブラブスタッフ自己紹介(最終回) ***
No.33 ナガタユウコ
( @ngtyk , http://d.hatena.ne.jp/ngtyk/ )
事務局長の天野さんから始まりました、この「オブラブスタッフ自己紹介」の
コーナーも、めでたく今回で最終回を迎えることができました。ということで
最終回はオマケとして・・・こんにちは、編集人のナガタユウコです！2007年
よりオブジェクト倶楽部事務局の一員として、イベント運営やメルマガ発行、
ドラ娘などを担当してきました。オブラブスタッフになってからもう3年も経つ
のかと改めて驚いてしまうぐらい、オブラブではたくさんの出会いと気づきが
あり、あっというまの3年間でした。事務局として至らない点も本当に多く申し
訳ない限りですが、メルマガ読者のみなさま・イベント参加者のみなさま・そ
してスタッフに支えられて、オブラブを動かす力の一部を担当することができ
ました。ありがとうございました。
・・・なんだかオブラブスタッフを辞めるような文章になってしまいましたが
そんなことはなく、これからも事務局として頑張りますので、末永くよろしく
お願いします！(ナガタユウコ)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は ⇒/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.