ITの地殻変動はどこで起きているのか？: プログラマの思索を読んで思い出したことをまとめておこう。 TracなどのBTS(バグ管理システム)を用いたチケット駆動の開発というスタイルで、アジャイル開発を実践されている方も多いことだろう。 私がTracを使っていて感じた不足をここに挙げておく。 インシデント管理 顧客からの要望などのインシデント票と呼ばれるものと、開発の為のタスク（チケット）は別のものだ。私も当初はこれらを混在してつかっていたのだけど、顧客からの問い合わせや要望といったものと、実際の開発作業の間には大きな溝がある。 例えば「Tracにインシデント管理機能をつけてよ」と言われた段階で「インシデント管理機能を作成」というチケットをあげてはいけない。 XPで言うところの計画ゲームをする際のタスクカードと、TODOであるところのTrac上のチケットは分けた方がいい。アイデアとしては出た
チケット駆動開発でアジャイルに開発しながら、「チケットではなくイテレーションで進捗やリスクを追跡する」意味が何となく分かってきた。 それについてメモ。 【1】チケット駆動開発の基本は、チケットファースト。 チケットがXPのタスクカードに相当する。 担当者は、チケットへ作業内容を記入してから、作業を開始する。 開発者は実際、チケットをToDoカードのように用いている。 SW開発のタスクは単にプログラミングだけではない。 お客様へ納品する設計書を作ることも必要だし、テスト仕様書を作ることも必要。 更には、ビルド環境を作ることも必要だし、テストデータを準備することも必要。 すると、チケットは終了するペースよりも登録する方がどんどん増える。 何もしなければ、チケットは乱発されて、放置状態になり、収拾が付かなくなる。 僕が初めてTracを運用した時、マイルストーンやバージョンが曖昧なままチケットを登
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
