« 【告知】第 24 回 Ruby/Rails 勉強会@関西 | トップページ | REST思想とHTTPメソッドの関係 »

2008/03/10

XPの計画ゲームとは?

OOエンジニアの輪! 第 40 回 関 将俊 さんの巻」で、関さんが興味深い発言をしている。

(引用始まり)
--- XP やアジャイルを試みてからずっと継続的にやってるんですか?

7 年くらい。でも、多分やってる人は XP でやってると思ってないと思います。そういう話はしてないです。はじめに入った時からそれしか知らないから、他と違うことを知らない人が多いのかもしれないです。

--- エリートですね(笑) 。どのようなプラクティスを重視してますか?

うちが一番注意しているのは計画ゲームとか、ストーリーカード・・・他のやつは、普通のプログラミングテクニックですよね? 計画ゲームが無いと XP としての意味がないというか・・・

(snip)

--- XP、アジャイルとの出会いはいつくらいですか? Kent Beck の白い本が出始めた頃ですか?

多分 2001 年ぐらいだと思う。出る前くらいかなんかだと思います。なんか当時、流行ってましたよね? ほかでも。なんか絵が描いてあるヤツ。絵を指している絵を使って。平鍋さんの所かな*25。プラクティス同士がこうつながるような絵のやつ。計画ゲームとかは共感できて。

--- 計画ゲームに関さんのツボがある感じがしますね。

計画ゲームは、何かある山を越えないとできない何かが結構あるんですよ。他のプラクティスに限って言えば、導入しても普通のプログラミングテクニックとかわらない。うまくやっている所はやってた事で、みんな知ってたよねっていう気がするんです。例えばうまい人はみんなテスト入ってからやってるのが普通。

--- 計画ゲームをやっていないと XP をやってるとは言えないですか。

うん。XP は名前に反しててプログラミングのための仕掛けじゃなくて、どうやって製品作ればいいんだろうっていう仕掛けなんですよね。その中でも、計画ゲームは作る製品を企画するような作業に一番向いていて。
(引用終わり)


XPのプラクティスの殆どは、今やかなり流通している。
Webシステム開発のように、ビジネスの速さにシステム開発を付いていくようにしたら、自然にXPらしくなってくる。

ソース共有、コーディング規約、常時ビルドは、今や当たり前の開発環境。
テスト駆動、リファクタリングも、今や当たり前のプログラミング技術。
スタンドアップミーティングで朝会をやり、全員同席でお互いのタスクと、チームのゴールを確認する。

ペアプロも、初めてのフレームワークや技術検証では、結局2人で作業していることが多い。
特に、本番リリース作業やデータセンターで本番DBをメンテナンスする時、ペアで作業している。
そうでないと、逆に怖い。

顧客を巻き込むことも自然にやっている。
本番リリースする前に、顧客に必ずデザインやUIを確認してもらうのが当たり前。
だから、リリース前には、WebデザインやUIの細かい部分の修正とテストを頻繁に繰り返すのが普通。
特に小売系は見た目にうるさい。
FireFoxで動作しても、IEでほんの少しレイアウトが崩れただけでも、やり直しになる。

だが、計画ゲームだけは、よく分からなかった。
関さんによると、計画ゲームとは、企画なのだと。
システムのデザイン、製品のデザインを顧客を巻き込んで行うこと。
技術志向ではなく、製品を一から作り上げていくためのボトムアップ的な手法。


オブジェクト倶楽部にある下記の話が秀逸。
「ドライブ」こそがXPの真髄。

(引用始まり)
Kent は,はじめて自動車を運転する練習をした日のことを例にしています.

母を横に乗せ,ハンドルを握り... 最初はうまく行きました.でも,ちょっと油断した瞬間,車は車道を外れて砂利に突っ込んでしまいました.母は車を道に戻すと,初めて運転とは何かを教えてくれました.
「運転で大切なのは,車を正しい方向に進めることじゃないのよ.大切なのは,常に注意を払って細かく左右に方向修正していくことなの.」

(引用終わり)

|

« 【告知】第 24 回 Ruby/Rails 勉強会@関西 | トップページ | REST思想とHTTPメソッドの関係 »

プロジェクトマネジメント」カテゴリの記事

コメント

以前、「計画ゲームが分からない」とおっしゃられていたので、簡単に解説を。

一般的に、ソフトウェアの管理変数は、
 ・Q:品質
 ・C:コスト
 ・D:納期

の3つですが、XPでは、
 ・T:時間
 ・S:スコープ(いわゆるストーリの数)
 ・R:リソース(開発者数/コストに相当)
 ・Q:品質

の4つでして、QCDにない「S」があるのが特徴です。

↓こんな関連になります。

   R
   |
   T
  / \
 Q   S

制限時間内(Time)に、与えられた工数(Resource)で、要求される品質(Quality)を満たした能機(Scope)の開発可能数の数は、決まってしまいます。

スコープがリソースを上回ってしまうと、品質が低下する。品質を上げると消化可能なスコープが減ってしまう。リソースを増やすと、無駄な工数が増える。

TSQRの中で、「TQR」は、お客様の要求が強く、開発側が増減する事は難しい。そこで、「S」を調整し、「TSQR」を上手くバランスさせる。

開発側が「S」に対し1件づつ見積もりを行い、お客様にサイフと相談頂き、実施要否/優先順位を決定して頂く。

どうしても「S」が減らせないのであれば、「R」を増やしてもらわないと、「Q」が確保できない旨申し入れ、「R」を増やして頂くか、お客様にご了承頂いた上で、「Q」を減らさざる終えない。

-----
この様に、お客様と「S」を調整し、「TSQR」をバランスさせる事こそが、計画ゲームであるといえます。

-----
>システムのデザイン、製品のデザインを顧客を
>巻き込んで行うこと。

これも、お客様の要求(S)を、1つづつ値札を付けて、お客様にサイフと相談していきながら、実装する機能を決めて頂くことと言えると思います。

投稿: たけぷ~ | 2008/04/05 03:56

◆たけぷ~さん

この図で「トリアージ」の意味が分かりました。
そういうことだったのか~。
Thanks!

   R
   |
   T
  / \
 Q   S

投稿: あきぴー | 2008/04/05 10:52

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/40468814

この記事へのトラックバック一覧です: XPの計画ゲームとは?:

« 【告知】第 24 回 Ruby/Rails 勉強会@関西 | トップページ | REST思想とHTTPメソッドの関係 »