Cotton Bolls: March 2004 Archives
Document Actions
« February 2004 | トップページ | April 2004 »
2004.03.28
ストーリーポイント
僕が作る見積書にはいつも「ポイント」が出てくる．XPをよく知らない人には，このポイントが何なのかよくわからないらしい．先日も営業に見積もりを出したら「出たー，ポイント！」といわれショックだった（いつも説明しているはずなのに(x_x)）．もちろん見積書であるExcelシートには人月や金額も算出されるようにしているが，以前からポイントはわけのわからないもの，というふうに思われているらしかった．そこで，今日は僕のプロジェクトで採用しているストーリーポイントを紹介する．
ストーリーポイントの計算はすごく簡単だ．すなわち，
1pt = 「ペアプロで一日かかる作業量」
という式で表される．だから，見積もりをする場合はペアでやるとどれぐらいかかるか？ということを考えながらメンバーと相談して決める．
このペアプロはいつも時間割を決めて行う．1日3コマ制だ．
- 10:15 - 12:30
- 13:30 - 15:45
- 16:00 - 18:15
1コマ2時間15分が0.3ptで，少し残業すると1日1ptという計算になる．ソロの場合はこの半分．でも正確さは全然求めない．かなりアバウトで，難しいことは考えないようにしている．まあ，半日ぐらいなら0.5ptだし，午前中にできるんだったら0.3ptでいいって感じだ．
実際に消費したポイントは，ストーリー集というXMLファイルに書き出す．使っているストーリー集のテンプレートはこんな感じだ：
<?xml version="1.0" encoding="UTF-8"?>
<stories name="イテレーション1 (3/29-4/9)">
<story name="ストーリーA">
<desc>ストーリーAの説明</desc>
<task name="タスク1" expected="2" actual="0.5">
<desc>タスク1の説明</desc>
</task>
<task name="タスク2" expected="1" actual="1.5" done="yes">
<desc>タスク2の説明</desc>
</task>
</story>
</stories>
この例では，最初のタスクは未完了で，0.5pt消費したことがわかる．一方，二番目のタスクは完了しているが，0.5pt分足が出た，ということになる．
このファイルをrubyで読み込み，ポイントの小計および合計を加えてHTMLに変換し，開発用Webサーバーにアップする．もちろんこのアップロード作業はMakeで自動化されている．
上の例はイテレーション単位のストーリー集だったが，他に
- 見積もり用ストーリー集(estimate.xml)
- 未実装ストーリー集(todo.xml)
- 実装済みストーリー集（rubyによる自動生成）
などのストーリー集を作る（フォーマットは同じだ）．これらをまとめてプロジェクトのWebサイトから簡単に参照できるようにしている．
プロジェクトが始まる前，最初に行う見積もりでは，見積もり用ストーリー集を起こし，これを元に見積書を作成する．無事契約が成立すれば，まず未実装ストーリー集とイテレーション0のストーリー集を作ることになる．その後イテレーションが終わるたびに次のイテレーションのストーリー集を作り，未実装ストーリー集から実装済みストーリーを削除する．開発はこの繰り返しだ．
以上が僕が何年も前から使っているストーリー管理の方法だが，XMLファイルを編集するのが不恰好なのでWikiに移行できればいいなと思っている．会社ではPukiWikiが使われてるので，こんな感じのストーリー集作成プラグインがあればいいのだが．
09:16 PM in XP | 固定リンク | コメント (0) | トラックバック
2004.03.21
種の設計
ソフトウェア開発について考えるとき，僕が一番好きなのは次の言葉だ．
If you want to design a new flower, you will design the seed and let it grow.
この言葉は，パターンで有名なChristopher Alexanderの著書「時を越えた建築の道」の翻訳本にある「訳者あとがき」に登場する．訳者である平田翰那（かんな）氏がバークレー校での学業を終えるときにAlexanderから送られた言葉だそうだ．
「時を越えた建築の道」を買った当時，ソフトウェア界隈でパターンはほとんど知られていなかった．GoFもなかった頃だ．僕がパターンを知ったのは，DDJJのKent Beckによる記事だったと思う．実は，その記事を読んでもパターンが何かよくわからなかったのだが，ソフトウェア設計に役立つと聞き，「パタン・ランゲージ」「時を越えた建築の道」「形の合成についてのノート」などAlexanderの一連の書籍を買ってしまった．「時を越えた建築の道」は建築や都市設計のコーナーにあるのだが，手に取ったとき，隣にいた人から「本当に買うんですか？」と驚いたように聞かれたのが印象に残っている．建築の世界でもパターンに興味を持つ人は珍しかったらしい．
これらの本を読み，Alexanderは建築家というより思想家で．スケールの大きいことを考えるなあと感動したのを覚えている．でも，これがどうしてソフトウェアに役立つのかわからなかった．わかったのは数年後にGoF本を手に取ったときだ．そのときはパターンをソフトウェアに応用するとこんな風になるのか，という印象だった．でもこの本は単なるパターンカタログで，Alexanderの本来の思想からはちょっと外れている．今Alexanderの考えに一番近いのは，きっとXPなんだろう．
少し脱線したが，最初のAlexanderの言葉に戻ろう．この言葉が好きなのは，これが一番理想的なソフトウェアの開発プロセスだと思うからだ．
ソフトウェアを開発するとき，まず種の設計から始める．ここでいう種とは，そのソフトウェアのToy Modelというべきものだ．ミニチュアのおもちゃのようなクラスと考えてもらえばいい．この段階では，画面UIやデータベースは一切関係ない．あくまでテストメソッド内で簡単にシュミレーションでき，ソフトウェアの要件を満たすよういろいろ遊べるクラスなわけだ．
そういう種ができれば，今度はそれを育てていく．培養していくのはテストコードで，育てるのは少しずつの機能追加とリファクタリングだ．ここで肝心なのは，育てるときにコードをよく観察するということだ．「不吉な匂い」を感じたら，すぐ原因を突き止めて病気にならないようにしなければならない．また，いきなり目的の機能を入れようとしてもいけない．無理に入れようとしても，そこまで育っていなければいびつな設計になってしまう．あくまでコードを誘導して目的のところまで育てていくことが必要だ．
こうして出来上がったプログラムは，設計も実装もすばらしくいいものになる．最初からこのパターンを使おうとか，クラス図で詳細をつめてからコードを書こうとか，最初からそういうことを決めてしまうといびつで汚いコードになってしまう．そこには「育てる」という過程がないからだ（注：この「種を設計し，育てる」というプロセスは，あくまでストーリー単位のものと考えてほしい．ソフトウェア全体の種を設計し，一度にみんな育てる，ということではない）．
この仕事をしていると，よく画面べったりの汚いコードに出くわすことがある．そのコードの開発者は納期に追われていたか，新しい技術の習得に精一杯で種について考えることがなかったのだろう．どうもこの抽象化を忘れたまま開発している人が多いように思う．種の設計には，画面やDB，新しい技術をいったん捨てさるという抽象化の能力が必要だ（16パズルの抽象化が参考になると思う）．でも，自分ができる範囲で行うだけでもいいと思うのだ．
僕自身も最近新しい技術や言語の習得に時間をとられ，こういった基本がおろそかになりつつある．そういうとき，改めてこのAlexanderの言葉を思い返す必要があると思うのだ．
05:45 PM | 固定リンク | コメント (2) | トラックバック
2004.03.19
引越し
ホームページを以下のURLに引越ししました．
http://homepage3.nifty.com/masarl
今まで使っていたNiftyのメンバーズホームページが8月に廃止されるためです．お手数ですが，リンクをされている方は更新等よろしくお願いします．
このHPも公開してからかれこれ5年以上経つでしょうか．相変わらず更新が滞ってますが，また時間を見つけて書いていこうと思います．どうもRubyのWin32OLEやMakeの記事の要望が多そうな感じですね．
12:12 AM | 固定リンク | コメント (2) | トラックバック
2004.03.14
ココログのカスタマイズ
ココログは便利だが，融通が効かなくて困ることがある．文章だけならいいが，記事の中にプログラミング言語を書くようなプログラマ向けには作られていないようだ．プログラムを書くには幅が狭すぎるし，preタグ内の文字は小さすぎる．前の記事もJavaのコードが入らなくて何度も調整した．こういうどうでもいいことに時間がとられるとやる気が失せてしまう．
これじゃダメだと思って，今回がんばってカスタマイズの方法を調べてみた．いつもの内容を期待していた人はごめんなさい．でも，ココログでソフトウェアの技術情報を書いている人は参考になるのではないかと思う．もちろんHTMLとスタイルシートの知識が少しだけ必要だ（といっても僕自身こっち方面はかなりいい加減だ）．
僕が使っているのは，ウェブログのサブタイトルにスタイルシートを埋め込む方法だ．こうすることで，ココログが用意したスタイルシートをオーバーライドできる．
まず，ココログの「設定 > ウェブログの基本情報」にある「ウェブログのサブタイトル（キャッチフレーズ）：」欄にstyleタグを埋め込む．例えば，今Cotton Bollsで設定しているのは次のスタイルシートだ：
<style type="text/css">
#banner {
height: 10%;
font-style: italic;
}
#container{
width: 97%
}
#left {
width: 20%
}
#center {
width: 80%
}
.content p,
.content pre,
.content h2,
.content h3,
.content li,
.content blockquote,
.content {
font-size: 0.9em;
}
.content {
font-size: 0.9em;
margin-right: 0px;
border-right: none;
}
.content h2 {
font-style: italic;
}
.content h3 {
border-bottom-style: double;
}
.content pre {
border:1px solid #6464e4;
padding:1em;
line-height: 140%;
}
</style>
これをそっくりそのままサブタイトルにし，サイトに反映させる．これでできあがりだ．以上バッドノウハウ終わり．
でも，上のことをそのままやるとスタイルシートを調整しにくい．何度もサブタイトルを変更し，本番サイトで確認する羽目になる．そこで，ココログが表示しているHTMLファイルをローカルに保存し，自分のパソコンで試してみることをお勧めする．具体的には，次のような手順でやればいい．
1. ブラウザで自分のサイトを表示させ，単一のHTMLファイルとして保存する．
2. 保存したファイルがシフトJISなら，head内のmetaタグを次のように修正する．
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
3. サブタイトルのh2タグを探し，先に埋め込んだスタイルシートを修正してその都度ブラウザで確認する．
4. スタイルシートができれば，h2タグの中身をコピーし，改めてサブタイトルに設定する．
以上だ．この方法だと簡単にスタイルシートの調整ができると思う．
さらにバッドノウハウをもう一つ．preタグにプログラムを埋め込むとき，空行があれば勝手にbrタグが補完されて表示がおかしくなってしまう．それを防ぐには，空行の部分にわざとコメントを埋め込めばよい．例えばこんな感じだ．
<pre>
package jjunit;
<!-- line -->
public interface TestSaver {
public void tearDown() throws Exception;
}
</pre>
これでプログラムも普通に書けるようになると思う．というわけで，今回やっと望み通りのスタイルで表示できるようになった．
ところで，ブログや日記を毎日のように書き続けている人はすごいと思う．2/29の記事なんかは書くのに6時間もかかってしまった．本当に遅いので，文章を書くには全然向いてないなと思う．先日も，ある出版社の編集者さんを怒らせてしまったようで，迷惑をかけてしまった．すみません．こういうので気まずくなり音信不通の人が過去何人か．なので，あまり僕のところに執筆依頼はしないでください＞出版関係の方々．僕は，そんなたいした人間じゃないです．本や雑誌の記事を書く前にもっと勉強しろって感じで（といいつつしないんですが…）．