BTSを構成管理ツールとして使う

チケット駆動開発の戦略part1として、BTSを構成管理ツールとして使うアイデアをメモ。
#走り書きは後でまとめる。

元ネタは、下記の記事。

チケット駆動開発 ITpro Challenge のライトニングトーク

Tracの最大の利点はSubversionとの連携にあり

【1】トレーサビリティ

Redmineのチケット管理をずっと続けると、要件からソースコードまでのトレーサビリティをすごく意識する。
実際の運用は下記になっている。

要件・仕様書・テスト仕様書のリンク、説明書き、作業履歴
←→チケット
←→SVNリビジョン

何度も思うことは、本番リリース後のシステム開発は、リアルタイムに保守されない仕様書よりも、バグ有りで動くプログラムが正しいことだ。
しかも、お客も、バグありの機能を知った上の運用フローを組んでいる。

設計者は、XPのように、動くプログラムを正として、プログラムから機能仕様をリバースして仕様書を作る時がすごく多い。
つまり、実際の仕様書作りは、本番稼動しているシステムを元ネタに作る時が実に多い。

この時に、SVNリビジョンとチケットが相互リンクされているので、ソース修正の意図がチケットに書かれている。
この手法によって、ソースコードから仕様をリバースするのがかなり楽になった。
つまり、3年前に書かれたパッチの修正理由をすぐに見つけることができる。

SEの仕事は、要件から業務のインターフェイスを決めること。
そして、要件とインターフェイスがMECEで対応していること、更には、要件からソースコードまでのトレーサビリティが保持されていること。
つまり、ソースコードで実装された機能やパッチが必ず要件管理IDに基づいていることを保障するのがSEの重要な仕事だと思う。

今まではトレーサビリティを実現するインフラが今まで無くて、Excelで書かれた膨大で散在したドキュメントしかなかった。
だから、欲しい仕様を膨大で散在したExcelの中から手作業で探すしかなかった。
でも、今は、Redmineによって、仕様は全てチケットに紐づけているから、チケットの履歴から探せる。
まさに、設計そのものもチケット中心。

このアイデアはバージョン管理、構成管理につながると直感している。

【2】SVNコミットログで「refs」と「fixes」を使い分ける運用も始めた。

2-1.チケットの仕様を実装中だが、一旦コミットしたい
↓
修正中のステータスなので「refs」を使って
「～の理由でコミット refs 123」
と書く。
↓
SVNリビジョンとチケットにリンクが張られるだけ

2-2.チケットの仕様を全て実装完了した
↓
修正完了のステータスなので「fixes」を使って
「～の機能を実装 fixes 123」
と書く
↓
SVNコミット時に、チケットの進捗＝100%かつステータス＝解決に変更されて紐付けられる

この運用を入れた理由は、SVNコミットログに修正ステータスも入れたいから。
そうすれば、リリース後にSVNコミットログを集計した時に、「fixes」「refs」の単語で何かしらのソフトウェアメトリクスを採取できるのではないか、と思う。
ソフトウェア・リポジトリ・マイニングでは、SVNコミットログの精度が高いほど意味のあるメトリクスを採取できるはず。

【3】プロジェクトの見える化

チケット駆動開発の最大の利点は、プロジェクト管理とソースコードがリアルタイムに結びついていること。
プロジェクト内部で発生する作業は、Redmineのチケット一覧を見れば、今誰が担当して、今どんな状態なのか、一目瞭然。
Redmineのロードマップで、バージョン単位にグループ化されたチケットの進捗率が分かる。

他には、Redmineなら、ガントチャートでチケットの進捗が分かる。
レポートで、トラッカー・機能・起票者などの分類ごとのチケットのステータス一覧が分かる。
統計では、SVNコミット回数、リビジョン回数がグラフ化されるから、開発者の生産性も一目瞭然。

そして、作業終了となったチケットは、リリース後の集計結果からソフトウェアメトリクスを採取できるので、チームメンバーでふりかえりを行うプロセス改善の材料にもなりうる。

開発者はRedmineのロードマップを毎朝見て、どの作業が自分の担当か判断するので、僕が逐一作業指示を出す必要も無くなった。
と言っても朝会を止めたわけではない。

朝会ではむしろ、ロードマップを見ながら、バージョンの戦略やチケットを担当してもらう意味を説明することが多くなった。
特に、バージョン管理戦略は、突然の仕様変更やバグ修正で大きく変わる時もあるので、開発者の意見や見積もりも聞きながら、対応するようにしている。

【4】バージョン管理

「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」によると、ソースだけでなく、仕様書もビルドスクリプトも開発環境もサードパーティのライブラリもSVNリポジトリへコミットすべきだと言う。
つまり、開発に関わる全ての成果物はバージョン管理すべきだ、と。
理由は、いつでも誰でも開発環境を再現できるようにしたいから。

実際の現場では、ソースコードはSVNで管理していても、ExcelやWordの仕様書、画像などのバイナリファイルはバージョン管理していない所が多くないか？
また、ビルドスクリプトやライブラリもバージョン管理していない所も多いのではないか？
だから、製品をリリースする時、しばらく時間が経った後に仕様変更で修正する時に、最近のビジネスのスピードについていけない時が多いだろう。

Redmineでチケット駆動開発を実施すると、バージョンという概念がシステム開発で重要なことを改めて認識させられる。
つまり、バージョンとはシステムに関わる全成果物のスナップショットなのだ。

例えば、Subversionのタグは、リリースしたソースのスナップショット。
Redmineのバージョンはリリースしたチケットの一覧。

Subversionのタグによって、ソースだけでなく、仕様書やビルドスクリプトなど一式もバージョン付けされる。

チケット駆動開発は、バージョン単位にチケットをグループ化して、システムを漸進的に進化させる開発スタイル。
バージョン履歴こそがシステム開発の作業履歴そのものなのだ。

Redmineにはニュースという機能がある。
ニュースはバージョン履歴の概略として使えるから、ここに書き記していく。

他に、Redmineチケット機能に変更記録という一覧があり、これは、ロードマップでステータス＝終了となったチケットの一覧を表示している。
これがバージョン履歴そのものと言える。

マイクロソフト製品はver3.0になって使いやすくなると揶揄された頃があった。
バージョンアップするたびに、品質が安定して、使いやすい機能が揃ってくるということ。
バージョン管理こそがプロジェクト管理の要。

【5】構成管理する目的は、下記2点に集約されるのではないか、と思う。

5-1.成果物をバージョン管理する
5-2.作業プロセスをトレースし、ソフトウェアメトリックスを採取する

5-1はSubversion(SCM)で実装可能。
5-2はRedmine(BTS)で実装可能。

組織の成熟度という話は、IT業界では、CMMIという概念がある。
CMMIでは下記の5段階が定義されている。

◆レベル1（初期段階）
　場当たり的な状態で、決まったプロセスがない
　
◆レベル2（反復可能な段階）
　初歩的管理は行われており、同じようなプロジェクトなら反復できるプロセスがある
　
◆レベル3（定義された段階）
　組織的に定義された標準プロセスがある
　
◆レベル4（管理された段階）
　プロセス・製品の精度、品質を管理し、定量的な分析が行われている状態
　
◆レベル5（最適化された段階）
　プロセス分析からのフィードバックにより、改善が継続的に行われている

BTSをプロジェクト管理のインフラにできれば、成果物をバージョン管理できて、作業をチケットでいつもトレースできるから、CMMIレベル2はクリアできる。
更にチケットの集計結果からソフトウェアメトリクスを採取して、そこからプロセスを改善できるならば、CMMIレベル5に達している。
BTSをうまく使えば、CMMIレベル5を目指すこともできるのではなかろうか？

プロジェクトリーダーはBTSを構成管理ツールとして使いこなせば、プロジェクト管理の最強インフラにできるはずだ。