BTSをプロジェクト管理の汎用フレームワークとして使う

チケット駆動開発の戦略part2として、BTSをプロジェクト管理の汎用フレームワークとして使うアイデアをメモ。
#走り書きは後でまとめる。

【元ネタ】

【バグ管理の作法】Trac徹底活用！　第2回：なぜTracの導入に失敗するのか？

質問「BTSについて教えて下さい」に対するgaryoさんの回答

【1】BTSはシステム開発に特化したToDo用のワークフローとgaryoさんは言っている。

--------↓引用開始↓-----------
BTS自体は非常に使いやすいToDo用のワークフローシステムです。
「バグ」として登録している所を「機能(追加・要求)」にすれば開発管理（要求管理）になりますし、汎用的に「タスク」と捕らえればプロジェクト管理になります。
流れとしてはBTS→BTS+プロジェクト管理　となっていくと思います。
---------↑引用終了↑----------

BTSのチケットの中身は、バグ報告票だけでない。
お客からの問い合わせなどのインシデントも書ける。
更には、開発者からあがったリファクタリング、環境構築、ビルドスクリプト作成などの内部作業も書ける。

つまり、バグ解決プロセスはITILのインシデント管理、問題管理、変更管理、リリース管理に簡単に流用できるはずだ。
これは、BTS(Bug Tracking System)をITS(Issue Tracking System)へ汎用化・昇華させる発想。
このアイデアを色んな角度から考察してみる。

【2】WikipediaにあるBTSの解説を読むと、バグ解決フローは下記の流れになる。

新規　opened
　起票者(テスト担当者)がバグ報告を登録する
↓
担当　assigned
　管理者(又は起票者)がバグ修正の担当者(開発者)をアサインする
↓
解決　resolved
　担当者がバグ修正してバグを解決する
↓
検証完了　verified
　起票者がバグが再現するか検証して、解決したことを確認する
↓
終了　closed
　管理者がバグ報告票を閉じる

Redmineには、ステータスとユーザーの権限マトリクスを制御する仕組みがある。
例えば、担当者は、「担当→解決」しか操作できない。
起票者は、「新規→担当」「解決→検証完了」しか操作できない。
この仕組みによって、メンバーが5人、10人のようなチームでも混乱せずに運用できる。

ユーザ権限によってステータスを制御する仕組みは、情報系の業務システムでは良く使われている。
RedmineのDBを見ると、ステータスやユーザを増やしても使えるように非常に上手に作られている。

--------↓引用開始↓-----------
バグレポートもすぐ出力できます。
ソフト担当者は後どのバグがあるかと自分は何を対策すればいいのかが分かります
（複数の人で開発していると誰がどのバグを直すかというのも決めないといけません。
そうしないとバッティングしてしまいます）

また、評価担当者は自分が起票した不具合がいつ対策されてどのバージョンで対策版がリリースされるかわかります。
---------↑引用終了↑----------

起票者と修正担当者が異なる点は重要だ。
結合テスト、システムテストのプロセスでは、バグ修正する人とテストで検証する人は分ける。
理由は、品質保持のためだ。

また、Redmineには、「検証済み」のステータスは無いが、「フィードバック」「却下」というステータスがある。

実際は、担当者がバグ修正して「解決」したとしても、起票者が検証したらNGで「フィードバック」することもありうる。
また、管理者がバグ報告票を精査して、「このバグは仕様だから修正不要」と「却下」することもあるだろう。

また「検証完了」と「終了」の違いも重要だと考える。
開発環境で「検証完了」となってリリース用モジュールをビルドできたとしても、本番リリースするまでタイムラグがあるのが普通。
「終了」とは、管理者が顧客に報告済み、あるいは、本番環境にリリースして稼動している状態を意味する。
この辺りのリリース管理がしっかりしていないため、本番リリースでトラブルが起きる開発チームもあるのではなかろうか？

【3】BTSにはステータス変更時に次の担当者へメール送信する機能がある。

つまり、バグ解決フローのイベントをメール駆動にすれば、コーディングパイプラインを管理者が逐一管理する必要は無い。

--------↓引用開始↓-----------
BTSの便利な点は、バグの処理がワークフロー化されて自動的に処理されることです。

[起票者]バグ報告→[担当者]再現性確認→[担当者]対策済→[起票者]対策確認

このそれぞれで、必要な人にメールが飛びます。

新しくバグが登録されると担当者にメールが届き、担当者がより詳細な情報が欲しい場合は再度起票者にメールが飛びと面倒を見る人が居なくても自動的に処理が進みます。

（開発者やテスターが複数の部署や会社にまたがるとこの連絡をやり取りするだけで専用の担当者が必要になります）
---------↑引用終了↑----------

バグ解決フローがシステム開発で非常にコントロールしにくい理由はいくつかあると思う。
一つは、バグはテストして初めて出てくるため、テスト工程がリリース間際になると、バグ報告票が大量発生して限られた時間内に解決できなくなること。

もう一つは、バグ解決フローは、起票者、開発者(担当者)、管理者という複数の人間の間をバグ報告票が渡り合うため、役割のコンテキストスイッチに意外に時間がかかること。

前者は、システムをバージョン単位に機能を分割リリースするイテレーション計画を作り、リリースするバージョンにチケットをふるい分けるバージョン管理戦略を取る事が多くなるだろう。

後者は、BTSのメール送信機能やRSS機能、ニュース機能で、次の担当者へ自動通知する仕組みで対応する事が多くなるだろう。

開発が遅いチームは、起票者と担当者のやり取りがスムーズにいっていない時が多い。
そうなる原因は、担当者に割り込み作業が多かったり、バグ修正の件数が多くて、担当者のタスクが溢れている時が多い。
プロジェクトリーダーは、起票者と担当者のコーディングパイプラインが滞りなく動いているか、いつも見て、タスクの量を調整する重要な役割がある。

【4】不具合Noを採番することで、構成管理のインフラに流用できる。

例えば、テスト管理WebシステムのTestLinkにあるテストケースでNGとなったら、チケットNoを採番してBTSのチケットへバグ報告票へリンクする機能がある。

--------↓引用開始↓-----------
BTSなどで一番重要なことは「不具合を採番すること」だと思います。
このことにより、「不具合管理番号○○○○○○番」の不具合と言って話が通じるようになります。

また、どの不具合のバグが何件あるかという情報が共有できます。
---------↑引用終了↑----------

Redmineのロードマップでは、バージョン単位にチケットをグループ化するから、リリースするたびに、どのチケットのバグが解決されたのか、バージョンから探すことができる。

【5】僕の考えでは、BTSによるチケット駆動開発は、成果物志向の管理は多分実現が難しく、作業プロセス単位で管理した方が構成管理は実現しやすいと思う。

つまり、Redmineならチケット管理することで構成管理も可能だろう、と考える。
理由は、チケット駆動開発では、チケット＝作業タスクとして管理するから。

構成管理はバージョン管理だけでない。
構成管理の目的は、ソフトウェアの構成(影響)を特定し、構成の一貫性、追跡性を維持すること。

チケット駆動開発は、トレーサビリティのインフラも提供するから、構成アイテム(CI)の状況、変更の影響範囲を即座に把握できる。
例えば、チケットの状態から作業プロセスの状態を把握できる。
又、チケット集計結果から信頼度曲線が作れて、品質状況を確認できる。

従って、チケットを要件と成果物のトレーサビリティ、作業の状態チェックに使えば、CMMIレベル2を自然に実現できる。
チケット集計結果をプロセス改善に使えるなら、CMMIレベル5に達することさえできる。

BTSをうまく使えば、プロジェクト管理の汎用的なフレームワークへ昇華できるはずだ。