« アジャイル開発はツールに依存している~SW構成管理を再考しよう | トップページ | 【告知】Shibuya.trac第4.5回勉強会で発表します »

2009/08/16

チケット駆動開発のFAQ

チケット駆動開発についてのFAQをまとめてみた。

他に聞きたい質問があれば、コメントして下さい。
チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

TiDD:チケット駆動開発: ソフトウェアさかば

RedmineとTracの機能比較: プログラマの思索

脱Excel! Redmineでアジャイル開発を楽々管理 - @IT自分戦略研究所

Tracのワークフロー: プログラマの思索

ワークフロー機能のカスタマイズ方法 - かおるんダイアリー

そろそろTracのワークフローについて語っておくか - almost nearly dead

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

TracからRedmineへ移行しない、たった一つの理由 - almost nearly dead

[TiDD]チケット駆動開発と見える化: ソフトウェアさかば

【プロジェクト】
【Q1】Redmineにある複数プロジェクト機能はどのように使えばいいですか?

【回答】
複数プロジェクトを使う目的は、タスク管理を分割統治する点にあります。
チケット駆動開発では、メンバーが5人以上のチームの場合、チケットが多すぎて管理が大変になります。
だから、チケットを管理しやすい範囲になるように、プロジェクトでタスク管理のスコープを分割します。

例えば、「大規模プロジェクトにおけるサブチーム単位」や「ブランチやtrunkのようなコードライン単位」、「warやjarなどのコンポーネント単位」でプロジェクトを作ればいいでしょう。

【Q2】大規模プロジェクトでもチケット駆動開発を運用できますか? 運用上の注意点はありますか?

【回答】はい、大規模プロジェクトでも運用できるはずです。(私も経験ないですが)

今考えられる注意点は、最低限、下記があげられるでしょう。

一つ目は、サブチーム単位でプロジェクトを作り、プロジェクト内部でタスク管理することです。
Q1のように、5人以下でタスク管理することを勧めます。

二つ目は、チケット管理専門の担当者を置くことです。彼の役割は、全てのプロジェクトのチケット管理の最終責任者です。
複数のプロジェクトをまたがったチケット管理は、彼が課題管理会議(CCB)の議長になって、チーム間の調整をすべきでしょう。
そして、課題管理会議(CCB)は最低、週1回は開催して、チケットの棚卸しをすべきでしょう。

【ワークフロー】
【Q3】RedmineやTracでは、課題管理や顧客の問合せ管理がやりにくいです。いい方法はありませんか?

【回答】RedmineやTracは本来は障害管理ツール(BTS)なので、バグ修正が基本フローです。
そのフローだけでSW開発の全ての作業を管理することは元々おかしいです。
課題や問合せ用のワークフローを作るべきでしょう。

Redmineなら、トラッカー(チケットの種類)ごとに新しいワークフローを簡単に作れます。
例えば課題ならば「新規→設計中→問合せ中→回答済み→解決→終了」のようなワークフローが考えられるでしょう。

Tracのワークフロー: プログラマの思索

Tracなら、trac.iniを修正してみて下さい。

ワークフロー機能のカスタマイズ方法 - かおるんダイアリー

そろそろTracのワークフローについて語っておくか - almost nearly dead

【チケット】
【Q4】チケットは仕様書ですか? チケットには何を書くのですか?

【回答】チケットは仕様書ではありません。チケットにはタスク(作業又は課題)を記入します。
チケットにタスクとその履歴を記録することで、タスクのステータスや進捗率、実績工数を管理することができます。

つまり、チケットをXPのタスクカードをデジタル化したものと見なせば分かりやすいでしょう。

※従来のBTSを拡張した上記のような管理手法をIssue Trackingと呼ぶ場合もあります。

【Q5】チケットはどれくらい詳細に書くべきですか? チケットの粒度はどのように決めたらいいでしょうか?

【回答】チケット駆動開発にある「チケットファースト」の原則に従うと、チケットは「一つの成果物を一人の担当者が1~5人日以内で完成させる作業」まで細分化します。

但し、バグ修正はテスターと開発者が相互にチケットをやり取りし合うように、複数人が一つのチケットを連携する場合もあります。
ワークフローによってチケットを変えましょう。

【Q6】チケットを乱発したり放置してしまいがちです。どのようにすればいいですか?

【回答】まず、チケット駆動開発では、チケットがいつも最新化されている状態が大事です。
チケットの内容が古いと、リアルタイムに保守されないExcelの進捗報告と何ら変わりありません。
現場リーダーがチケットを最新に保守する最終責任者です。

チケット駆動開発 - Live a meaningful Life

チケットが乱発されやすい理由は、チケット登録のルールが決められていないからでしょう。
最初は、現場リーダーがWBSに落としたタスクをチケットに登録することから始めればいいでしょう。
チケット登録できる権限をサブリーダーまでに制限したり、開発者がチケット登録できる種類はリファクタリングやバグのみに限る、などのルールを作ってもいいでしょう。

また、リリース時期が不明なチケットを登録したい時があります。
例えば、リスクや将来の課題という優先順位の低いチケットがあるでしょう。
このチケットは、「内部課題」という特別なイテレーションで管理するなど、優先順位の低いチケット群として別管理したらいいでしょう。

Redmineを使って気付いたことpart7~イテレーションで追跡する: プログラマの思索

また、チケットが放置されやすい理由は、チケットの粒度が大きい場合があります。
成果物が最初は不明なチケットの場合、あるいは、最初に登録したチケットが予定工数よりも大きくかかる場合、一人の担当者だけでは解決できないと後で分かる時はよくあります。
遅延したチケットは、更に分割して、複数人の開発者で担当するように運用すればいいでしょう。

Redmineを使って気づいたことpart3~チケット分割のタイミング: プログラマの思索

【イテレーション】
【Q7】Redmineではマイルストーンはどれですか? マイルストーンとバージョンの違いは何ですか?

【回答】Redmineでは、マイルストーンとバージョンは同一の概念になります。
Tracの場合、マイルストーンとバージョンは異なる概念として存在します。

マイルストーンは進捗報告のタイミング、バージョンはリリースするタイミングと区別されます。
普通は、一つのバージョンに複数のマイルストーンが含まれる運用になるでしょう。

Redmineでは、リリースのタイミング(バージョン)とマイルストーン(開発の一つの区切り)を故意に同一視することで、XPのイテレーションのように扱えます。
これによって、Redmineの方がアジャイル開発を自然に運用できるようになります。


【Q8】チケット駆動開発をアジャイル開発のように使うには、どの点に気をつければいいですか?

【回答】「イテレーションをどの単位で扱うか?」が一番のポイントです。
Redmineならバージョン、TracならマイルストーンをXPのイテレーション、Scrumのスプリントのように扱えばよいでしょう。
普通は、イテレーションを2~4週間の単位で区切り、そのイテレーションでリリースできる機能にシステムを分割し、その機能を実装するチケットをイテレーション(バージョン又はマイルストーン)に登録します。

2番目のポイントは「小規模リリースを実現する」ことです。
つまり、一つのイテレーションに含まれるチケットが全て終了ステータスになったら、そのイテレーションをリリースし、終了チケットはリリース履歴として残す運用になります。

アジャイル開発の最大のポイントは、スコープ・工数・納期の三角形でプロジェクト管理を行うことです。
チケット駆動開発では、一つのイテレーションで実装できないチケットは、次のイテレーションへ延期するか、却下することで、スコープと工数・納期のバランスを取る戦略になります。

つまり、プロジェクト管理をチケットの取捨選択に置き換えることで、マネジメントを見える化しているのです。

【ソース管理】
【Q9】チケットとソースをリンクさせるにはどうすればいいですか?

【回答】Redmineでは、SVNコミットログに「refs」や「fixes」を付けると、チケットにソースのリビジョンが相互リンクされます。
この方法を徹底できると、運用保守で過去のチケットからパッチの理由を推測することができるので、リバースエンジニアリングしやすくなる利点があります。

この手法をチケット駆動開発は重視しており、提唱者のまちゅさんも「チケット無しの成果物のコミットは不可」というルールで呼んでいます。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

【Q10】RedmineではSVNコミットログにタグ(「refs」「fixes」)を付けると、チケットとソースが連携できると聞きました。「refs」と「fixes」の違いは何ですか?

【回答】Redmineでは「refs」を付けると、チケットとソースのリビジョンが単純に相互リンクされるだけです。
「fixes」を付けると、チケットとソースが相互リンクさせるだけでなく、リンク先のチケットのステータスを「解決」、進捗率を「100%」へ自動更新します。
つまり、「fixes」を使えば、SVNコミット後にチケットを更新する手間が省けます。

また、SVNコミットのタイミングで、バグを確実に修正できた場合は「fixes」、全機能は実装できていないが一部機能は実装できた場合は「refs」のように使い分けると、SVNコミットログからコミット履歴を検索しやすくなるでしょう。

【レポート】
【Q11】MSProjectの進捗管理とチケット駆動開発のタスク管理が連携しにくいです。何故でしょうか?

【回答】MSProjectとチケット駆動開発で進捗管理の視点が異なるからです。

つまり、MSProjectは顧客向けの進捗報告であり、管理者の視点で機能別、工程別に進捗を管理しますが、チケット駆動開発は開発チーム内部の進捗管理であり、開発者の視点で作業別、成果物ベースで管理しているからです。

すなわち、MSProjectはXPのストーリーカード、チケット駆動開発はXPのタスクカードの観点で進捗管理していると考えれば分かりやすいでしょう。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

【Q12】毎月の工数を集計した顧客向けの月次報告をチケット駆動開発のツールから生成できますか?

【回答】Redmineは運用+カスタマイズするしかありませんが、Tracならクエリを上手に使えば生成できるでしょう。

TracからRedmineへ移行しない、たった一つの理由 - almost nearly dead

基本的アイデアは、一つのストリーカードを複数のタスクカードに分割し、そのステータスと工数、開始・終了日をストーリーカードの単位で集計すればいいでしょう。

つまり、顧客価値に相当する要件(ストーリーカード)と成果物ベースの作業(タスクカード)を相互リンクさせる構造をチケット管理に取り込むのがポイントです。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

|

« アジャイル開発はツールに依存している~SW構成管理を再考しよう | トップページ | 【告知】Shibuya.trac第4.5回勉強会で発表します »

Redmine」カテゴリの記事

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

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

コメント

コメントを書く



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


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



トラックバック

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

この記事へのトラックバック一覧です: チケット駆動開発のFAQ:

« アジャイル開発はツールに依存している~SW構成管理を再考しよう | トップページ | 【告知】Shibuya.trac第4.5回勉強会で発表します »