RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。
以下メモ書き。
【比較対象】
・Redmine0.8.0
・Trac0.11.1.ja
【元ネタ】
脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所
【1】複数プロジェクトの扱い
RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。
Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。
複数プロジェクトを作りたい状況は、二つある。
【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。
RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
理由は、チケットファーストの原則に従って、プロジェクト内部の作業をチケットに登録してしまうと、タスクの粒度が極めて小さくなり、チケットが増発されがちだから。
本来は管理者がチケット管理の最終責任者だが、メンバーが多ければそれだけタスクも増えるから、管理しにくくなる。
【1-2】コンポーネント単位(jar, dll)、ブランチ単位でチケット管理したい場合。
Redmineでは、SVNリポジトリとプロジェクトが1対1に対応する設計思想のため、リポジトリ全体だけでなく、trunkのみ、branchのみだけというプロジェクトも作れる。
この状況は、大規模プロジェクトで一つの製品やシステムを複数のライブラリで組み合わせて作る時に多い。
Redmineでは、プロジェクトの親子関係を入れることができるため、親プロジェクトの下に、サブチーム単位やコンポーネント単位、ブランチ単位に子プロジェクトを作ると良いと思う。
Redmineでは、チケット同士の関係(関連する、重複する、など)の属性があるので、各プロジェクトで関連するチケットを相互リンクすれば、更に見通しが良くなるだろう。
※但し、Tracも下記のプラグインなどで対応できるらしい。
TraM
SubProjectsPatch - Trac Hacks - Plugins Macros etc. - Trac
【2】ワークフロー管理
RedmineとTracのワークフロー管理については、下記の記事で言い尽くされている。
プログラマの思索: Tracのワークフロー
そろそろTracのワークフローについて語っておくか - almost nearly dead
チケット駆動開発を運用すると、チケットを問題管理(バグ修正)だけでなく、要件管理やインシデント管理、変更管理にも使いたくなる。
しかしながら、BTS本来のワークフローはバグ管理のため、そのままの設定では使いづらい。
Tracのワークフローは実は「new → assigned → closed」の1種類しかないため、非常に使い辛かった。
Trac0.11でも「new → accepted → assigned → closed」に少しだけ拡張されただけ。
trac.iniでワークフローを設定すれば、色々拡張できるが、その設定は素人ではとても修正できない難しさがある。
Redmineもデフォルトのワークフローはバグ修正の1種類だけだが、トラッカー(チケットの種類)やステータスのデシジョンマトリクスでチケットの状態遷移をWeb上で制御できる利点がある。
この利点を利用すれば、トラッカーの単位で、インシデント管理は「新規→担当→問合せ中→回答済→終了」、要件管理は「新規→作成中→レビュー中→承認済み→開発中→終了」のようなワークフローを作ればよい。
プロジェクト管理の基本は、SW開発で現れる全てのワークフローを洗い出して、管理者の制御下に置くことが重要だ。
それで初めて、プロジェクト内部の作業やリスクを把握することができる。
ワークフローが少なければ、本当にそれだけでプロジェクトを制御できているか、という疑問が生じる。
ワークフローが多ければ、チケット管理の運用が面倒で、逆に運用コストも高くなる。
複数プロジェクトの機能があれば、ワークフローが増えすぎたら、プロジェクト管理の視点が異なると考えて、別プロジェクトへワークフローを外出しにしたらいいと思う。
少なくとも、新規開発のチケットを扱うtrunkプロジェクトと、お客様から日常のクレームや調査に対応するチケットを扱うインシデント管理用のプロジェクトは、別々で管理した方が運用は楽だろう。
要件管理に対応するストーリーカードと、開発者の日々のタスク管理であるタスクカードも別々のプロジェクトで管理した方が良いと思う。
その理由は下記の記事で書いた。
プログラマの思索: チケット駆動開発は進捗報告作りをどのように解決しようとするか？
理由は、顧客向けのチケット(ストーリーカード)と開発者が扱うチケット(タスクカード)は、ワークフローもそのライフサイクルも大きく異なるからだ。
つまり、ワークフローをグループ化して、異なるグループは別プロジェクトで管理した方が楽に運用できるだろう。
※但し、Tracも下記プラグインで、チケットの種類に応じて複数のワークフローを使い分けることができるらしい。
AdvancedTicketWorkflowPlugin - Trac Hacks - Plugins Macros etc. - Trac
【3】チケット機能
Tracは障害報告票をチケットという概念へ昇華させた点に意義があったと思う。
RedmineがTracよりも優れている点は、進捗管理と工数管理がデフォルトで組み込まれていることだ。
【3-1】進捗管理は、開始日や終了日や進捗率を入力すると、ガントチャートやカレンダーにデフォルト表示できること。
チケット駆動開発を運用し始めると、チケットに慣れていないメンバーは、開始日や終了日を入力せずにチケットを発行してしまう。
すると、そのチケットは、ガントチャートやカレンダーに表示されないため、作業状態を追跡しにくくなり、作業漏れしやすい。
チケット入力の運用ルールを徹底することがチケット駆動開発の肝。
チケット管理が開発者のタスク管理、ToDo管理であるとメンバーに理解してもらう事が大事。
チケット管理が運用に乗れば、メンバーは毎日の作業日報を書く必要はなくなる。
Redmineでは、カレンダーから日付を登録できたり、チケット一覧でコンテキストメニューから一括変更できるなど、ユーザインターフェイスも使いやすい。
【3-2】工数管理は、予定工数と作業分類ごとの実績工数を入力すれば、バージョンと月別のクロス集計で実績工数を出力するなどの機能があること。
マネジメントの基本は、予定と実績の比較にある。
経営者や営業マンが毎月の売上の目標と実績を月末に評価されるように、開発の予定工数と実績工数は記録しておきたい。
Redmineでは、作業分類というチケットの属性がタイムトラッキングと呼ばれていて、この作業分類ごとに、実績工数が色づけされる。
故に、作業分類を、「管理」「設計」「実装」「テスト」「リリース」などのように分類しておけば、工程ごとに工数管理できる。
しかしながら、Redmineと比較すると、Tracのデフォルトのチケット機能は貧弱だと思う。
Tracのデフォルトでは、チケットの属性に開始日・終了日・予定工数・実績工数・進捗率の項目がないから、そのまま使うと、チケット管理の有り難味がなくなる。
但し、Tracは、tarc.iniへ[ticket-custom] セクションを追加して、開始日・終了日・予定工数・実績工数・進捗率の項目を追加すればよい。
また、ganttcalendarプラグインを入れれば、Redmineと同等な機能になる。
【4】イテレーションの概念
RedmineとTracのチケット管理で、その概念が最も異なるのは、イテレーションの概念だと思う。
Tracの運用では分からず、Redmineの運用で初めて腑に落ちた概念が、イテレーションだ。
Redmineの「バージョン」は、システム開発のマイルストーンと、リリースするバージョンが一致した概念である。
この機能によって、Redmineの「バージョン」はXPのイテレーション、Scrumのスプリントに相当するようにアジャイル開発を運用できる。
しかし、Redmineの「バージョン」の概念に違和感を持つ人も多い。
その人達の反応を聞くと、マイルストーンとリリースするバージョンは異なるでしょ、とのこと。
確かに、実際のシステム開発では、マイルストーンとバージョンを一致させるように必ず運用する必要はない。
普通は、1個のバージョンに対し、複数のマイルストーンが紐づく関係になるだろう。
Tracの「マイルストーン」と「バージョン」の概念は、まさに上記の指摘と同じだ。
Tracの「マイルストーン」の属性には、完了日付と完了ステータスON/OFFがあり、完了ステータスONにすると、そのTracの「マイルストーン」は「閉じられる」。
つまり、Tracのロードマップ上に閉じられた「マイルストーン」は表示されなくなる。
そして、Tracの「バージョン」はリリースするシステムのタグと同等。
でも、僕はTracの運用は面倒だと思っている。
マイルストーンとバージョンを一致させる意味は、Redmineの「バージョン」に紐づく全チケットが終了ステータスになれば、いつでもリリースできるということだ。
この「全チケットが終了すれば、いつでもリリースできる」おかげでXPの小規模リリースを開発プロセスへ実装できる。
イテレーションの概念こそがアジャイル開発の運用で最重要な点だと思っている。
【5】レポート出力機能
Tracはクエリ発行画面でいくらでも欲しいレポートを抽出できるのが最大の利点だ。
しかし、Redmineの「サマリ」「工数レポート」だけで僕は基本的に十分だと思う。
Redmineの「サマリ」が意味するものは、これが進捗報告そのものだからだ。
わざわざストーリーカードとタスクカードを別々のプロジェクトで管理するのは、各ワークフローが異なるだけでなく、ステータスごとのチケット集計結果が進捗報告になるようにしたいからだ。
逆の発想では、管理者がプロジェクト管理で必要な情報をレポート出力できる形で、チケット管理を行えばよい。
進捗管理ではステータスごとのチケット集計だし、品質管理では、バグのチケット累積数を出力できればよい。
他の観点でも同様の発想でチケットの属性を上手に利用すればよいと思う。
RedmineやTracは、BTSにプロジェクト管理機能を持たせる発想は同じでも、機能や運用は微妙に異なる。
しかし、二つのBTSの運用スタイルから重要な概念を抽出し抽象化させた開発プロセスが、チケット駆動開発だと思っている。
チケット駆動開発の面白さは、SW工学が提唱する上からのプロセス改善ではなく、現場でツールを駆使して、開発者が使いやすいように運用する下からのプロセス改善である点。
そのアイデアをもっと理論化してみたい。
」においても、ビルドに含めるテストケースに優先順位をつけたり、夜間ビルドと即ビルドを切り替える等の方策を提示している。
」本にラストマイル問題という話がある。
)のように、抽出とインライン化の組み合わせなどもあり、非常に有用だと思う。
のWindowsクライアントTortoiseHgは、Googleのニュースを読む限り、ようやく使えるレベルになったみたい。
」を読んで、高度情報処理試験の論文問題を解いているような気がしてきた。
」では、SEが上流工程で問題解決に関与する状況が多いと言う。
を初めて買った。
最近のコメント