プログラマの思索

昔、XPlannerというXPのアイデアを実現したWebアプリがあった。
そのソフトは、XPのタスクカード単位で進捗管理できるのがウリだった。
でも、正直使い勝手は良くなかった。

そして、最近、Redmineを触って初めて、XPを実現できそうなプロジェクト管理ツールだと直感した。

Redmineによるチケット駆動開発のアイデアをまとめてみる。

【1】Redmineの特徴は、プロジェクトの進捗の可視化

Redmineの最大の特徴は、ガントチャート。
チケットに作業内容と開始日、終了日を入れると、すぐにガントチャートが出来上がる。

これを初めて見た時は感動した。
プロジェクトリーダーは、ガントチャートを作って保守するために、殆どの時間を費やしている。
WBSさえ作って入力すれば、ガントチャートを自動生成してくれるのだ！

他に、カレンダーもある。
開発時だけでなく、運用保守時にリリースする日やDBメンテナンスする日が一覧で表示できるのがいい。

また、ロードマップは、マイルストーン単位の進捗率そのものを表示する。
バーンダーンチャートに近い。

プロジェクトリーダーは、ロードマップを見ながら、マイルストーンまでに後どれくらいのタスクが残っているか、をすぐに把握できる。

また、プロジェクトリーダーはロードマップを見ながら、遅れている開発があれば、開発者のアサインを変えたり、納期をずらすよう顧客を説得するなど、色んな手を考えるだろう。

ガントチャート・カレンダー・ロードマップは、プロジェクトの進捗を数字で可視化させてくれる、プロジェクトリーダーにとってありがたいツール。

【2】RedmineのチケットとSVNリポジトリを連携させる

【2－1】Redmineでは、リポジトリというViewがある。
リポジトリViewでSubversionを設定すると、Subversionにあるソースの一覧とコミットログが表示される。

更に、リビジョン単位でソースとコミットログも表示できる。
また、ソースの差分も色分け表示してくれる。

プロジェクトリーダーは、リポジトリを見ながら、いつでもソースインスペクションできる。

チケットとSVNリポジトリを連携させる時に最重要な点は、SVNコミットログをきちんと書くこと。
駄目なプロジェクトは、コミットログが空欄。
だから、何故ソースを改修したのか、すぐに理由を忘れて、デグレが発生しやすくなる。

チケットとの連携は、「refs チケットNo」というコメントをコミット時に入れるだけ。

$ svn commit -m '○○○機能を利用時の△△△な問題を修正。 refs 123'

これによって、チケットにリビジョンNoがリンクされる。
更に、リポジトリにあるソースのリビジョンにチケットNoリンクが逆に表示される。

この作業で、チケットとSVNリビジョンの行き来が簡単になる。

【2－2】TracやRedmineが、ExcelやMS Projectよりも優れている点は、ソースコードとチケット(作業タスク)を紐付けることができること。

つまり、チケットを経由して、ドキュメントとソースコードの紐づけができるので、上流工程から下流工程まで一貫して、要件をトレースできる。

要望書→設計書・テスト仕様書→【チケット】←ソースコード

このやり方は、結合テスト以降のバグ修正や、運用保守時の機能追加で大きな威力を発揮する。
なぜなら、結合テスト以降や運用保守の工程では、死んだドキュメントよりも、実際に稼動中のプログラムの方が重要だから。

チケットのおかげで、バグ修正や機能追加の作業で、誰がどのソースコードをどんな理由で触ったのか、すぐに分かる。

【2－3】これがチケット駆動開発のアイデアだ。

つまり、チケットNo無しのSVNコミットはご法度。
SVNにコミットできるソースは、チケットというちゃんとした理由があるものだけで、そうでない場合はコミット不可になる。

この運用ルールは、本番稼動後の運用保守フェーズで最重要だ。
何故なら、実際に稼動しているソースコードを理由無しに書き換えるのは危険だからだ。

【3】チケット管理の肝

実際にTracやRedmineでチケットを使って開発したことがあったが、上記のような理想的な開発とはならなかった。

その時は、各開発者が勝手にチケットを乱発し、そのチケットを誰が担当するのか、そしてチケットを解決してもデグレが発生したり、とか、うまくコントロールできなかった。

「第2回：なぜTracの導入に失敗するのか？」では、チケット管理の運用で主に問題点として下記をあげている。

１・チケットの優先度を決めるのが難しい
２・チケットのマイルストーンを決めるのが難しい
３・チケットに書き込む内容と工数はどれくらいの規模がいいのか？
４・チケットを閉じる時、どのようなタイミングで行うべきか？

１と２は、チケットの属性に関すること。
３はチケットの作業内容と工数に関わること。
４はチケットの作業状態に関すること。

結合テスト以前と、結合テスト以降、そして運用保守時の2つで使い分けるとよいと考える。

【3－1】結合テスト以前のチケットは、要望を詳細化した仕様そのもの。
開発者はチケットにある仕様を実現するために実装する。

チケットの優先度は全て同じでいい。
マイルストーンは、ガントチャートにあわせればよい。
理由は、動くプログラムをまず作ることに注力したいから。
チケットの属性にあまりこだわらなくていい。
プロジェクトリーダーがあらかじめ決めておけばいい。

このフェーズでは、チケットの粒度が重要。
1チケットで担当者1人にアサインし、1チケットが平均2.5人日程度になるように細分化する。
つまり、1週間でチケット2枚を開発者1人が担当する。

1人月＝8チケットぐらいのサイズ。
20人月なら160枚のチケットの規模になるだろう。

理由は、チケットを実装する工数が大きいと、進捗管理が難しくなるから。
開発者にとっても、チケットをこなす速度が上がれば、楽しくなるし。
プロジェクトリーダーは毎日、ロードマップでチケットの進捗率を見張っておく。

【3－2】結合テスト以降、そして運用保守時では、チケットの状態管理が重要だ。

この工程では、チケットはバグ修正や機能追加、仕様変更などの作業になる。
緊急のバグ修正のチケットなら、優先度＝緊急で、マイルストーンは本番リリース日になるだろう。

いわゆる課題管理は、チケットの優先順位、つまり、どのチケットから順に消化していくか、という作業になる。
このフェーズでは、プロジェクトリーダーが細心の注意を払って、優先度やマイルストーンという属性を決めることになる。

また、チケットを解決のステータスへ変更する時、2人の担当者を経由させるか、最後にプロジェクトリーダーが必ずチケットを確認するような運用にする。

理由は、チケットの品質管理を徹底させるためだ。

特に本番稼動後のバグ修正や仕様変更では、デグレが許されない。
だからこそ、チケットを実装した開発者とは別に、テスト担当者にそのチケットを検証させる。
最後は、プロジェクトリーダーが実際にチケットを検証する時もあるだろう。

【3－3】チケットの運用方法は、プロジェクトリーダーの采配に大きく依存する。

Redmineには、チケットに経過時間という項目があり、これが実績に当たる。
レポートでは、見積もり工数と実績の比較を一覧に出す機能もあるらしい。

Redmineは複数プロジェクトにも対応しているので、見積もり工数と実績の工数を収集して蓄積できる。
そうすれば、ソフトウェアメトリックスらしき測定値を収集することもできる。

チケットを上手に運用できれば、ソフトウェア工学で習った知識を実際に現場で生かせるのだ！

【4】チケット駆動開発はXPの計画ゲームそのものだ

チケット駆動開発は、アジャイル開発に最も適しているように思う。
つまり、チケットはXPのストーリーカードやタスクカードに見立てることができる。

XPの計画ゲームは、１イテレーションで実現する機能をストーリーカードやタスクカードへ落として、下記の4つでコントロールする。
（By　たけぷ～さん）

　・Ｔ：時間
　・Ｓ：スコープ（いわゆるストーリの数）
　・Ｒ：リソース（開発者数/コストに相当）
　・Ｑ：品質

チケットの工数、作業内容、優先度は、まさに上記4つのバランスで決まる。

チケットの状態は、Redmineのガントチャート・カレンダー・ロードマップで可視化できる。
チケットはSVNリポジトリと連携できているので、要件定義からソースコードまで一貫してトレースできる。

上手に運用できれば、プロジェクト管理を効率化できるはずと思う。