BTSを制する者がソフトウェア開発を制する

Redmine、Trac、Mantisを使ってみて、ソフトウェア開発はバグ管理が最も基本のプロセスだと改めて感じた。
「BTSを制する者がソフトウェア開発を制する」という気がする。
以下、BTSについて経験したこと、考えたことをロジカルでないメモ書き。

ウォーターフォール型開発でよくあるパターンは、要件定義、設計、開発、単体テストまで順調に進むが、結合テストでたくさんのバグが噴出して、初めて問題が現れる時が多い。
その時、障害管理のためにBTSを使って、見つけたバグを一つずつ潰していく。
アジャイル開発であろうとも、イテレーション期間中に見つけたバグは、BTSで管理しているだろう。

ソフトウェア開発では、障害管理のプロセスが重要な気がしている。
いくら設計しても、単体テストをやっても、ユーザの観点で動かさなければ、開発者も自分が作ったシステムの全貌を知ることはできない。
1回のリリースは100回の設計に勝る点がある。
リリースしてみて、当初の動きと異なった点は障害管理票として起票して、一つずつバグを潰していく。
ソフトウェア開発の殆どの作業は、この作業に尽きる。

障害管理のプロセスや方法については、従来から色々知られている。
でも、まとまった良い本がない気がする。
障害管理のプロセスをきちんと理論として理解して、現場で実践している所は意外と少ないのではないか？
つまり、障害管理を場当たり的にやってはいないだろうか？

普通は、BTS(バグ管理システム)で障害管理を行うのが普通だろう。
BTSとしては、Bugzilla、Mantis、Trac、Redmineなどがあげられるだろう。
BTSについてどれだけノウハウを持っているだろうか？

BTSの使い方について、下記の観点で洗い出してみる。

【チケットの属性】
BTSの障害報告票はチケットとも呼ばれる。
チケットの基本的な属性は、起票者、担当者、ステータス、起票日、完了日、内容があげられるだろう。
プロジェクトマネージャの観点では、チケットの属性はもっと増やしていきたい。
例えば、作業予定完了日を追加して、いつ頃終わるのかを把握したい。
あるいは、予定工数や実績工数を追加して、予定・実績の工数比較を行って、スケジュール管理をしたい。
開発環境アップ日、受入環境アップ日、本番リリース日などを入れて、障害修正が今どの環境にあるのかを把握したい、など。
だから、プロマネは属性を増やして、必須項目にさせる運用をしてしまいがち。

だが、チケットの属性を増やすほど、障害管理のプロセスは重くなり、障害報告票を起票するだけで1時間以上かかってしまう時もある。
そうすると、バグが多発した時に起票プロセスがボトルネックになる。
だからチケットの属性をどこまでに絞るか、という観点は、開発の速度に直結すると思う。

個人的には、Redmineの複数プロジェクト機能を使って、開発時の障害管理と本番運用時の障害管理を分けて、チケットの属性も分けた方がいいのではないかと思う。
少なくとも、本番運用時に発覚した障害管理は厳格に管理しないと、同類バグ調査や影響調査で手抜きを行ったり、デグレが発生したりする。
すると、顧客の信用を失うので、複雑なワークフローになりがち。

バランスが重要だと思う。

【重要度と優先度】
障害報告票には普通、重要度と優先度という属性が付属している。
その内容については既に書いた。

障害管理における重要度と優先度の使い分け: プログラマの思索

バグの優先度は意思決定プロセスの結果: プログラマの思索

一言で言えば、重要度はストーリーカード(顧客の観点)、優先度はタスクカード(開発チームの観点)で使い分けるべき。
開発チームにとって、優先度は作業の優先順位に直結する。

アート・オブ・プロジェクトマネジメント: プログラマの思索にも書いたけれど、プロジェクトマネージャは優先順位付けマシンそのもの。
だから、彼の第一の仕事は、たくさんあがってきた障害報告票に対し、重要度と優先度を付けて、どの障害を優先してリリースするのか、を決めることだ。

すなわち、優先度とチケットの取捨選択、更にはイテレーション計画やリリース計画は密接に絡んでいると思う。

【ステータスと解決状況】
ステータスと解決状況の違いに付いては下記に書いた。

BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索

一言で言えば、解決状況は障害修正の終了条件の属性の一つだ。
解決状況を集計して、テストプロセスやシステムの品質を推測するのに使いたいために、この属性を使うのが普通だろう。
但し、MantisやJiraでは、解決状況がシステム上特別な意味を持っているので、注意した方がいい。

【ステータスとワークフロー】
障害管理票で重要な属性は、ステータス(作業状態)だ。
そして、ステータスを制御するのがワークフロー。
BTSでは、ワークフローが普通はほぼ1つに決まっている。
何故なら、バグ修正とバグ検証の組み合わせがソフトウェア開発の最も基本的なプロセスだからだ。

このプロセスを「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」ではコーディングパイプラインと呼んでいる。
つまり、開発者とテスター(又は設計者)がペアになって、成果物をお互いにチェックし合う作業がソフトウェア開発の基本的なワークフローになっていることを意味している。
コーディングパイプラインが開発チームでスムーズに運用できていれば、バグ修正だけでなく、仕様変更にも同様に対応できるから、プロジェクト後半になるほど重要なプロセスになる。

アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する: プログラマの思索

アート・オブ・プロジェクトマネジメント: プログラマの思索

だが、ソフトウェア開発のワークフローはバグ修正だけではない。
RedmineやTrac、Mantisでは問合せや課題の管理がやりにくい、とよく言われるが、その原因は、問合せとバグ修正は全く違うワークフローなのに、バグ修正のワークフローで運用しようとしているからだ。
詳しくは下記に書いた。

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

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

ワークフロー管理はプロジェクト管理で最も重要な概念の一つ。
プロマネがワークフローを何種類持っていて、状況に応じてどのように使い分けているのか、を見れば、プロマネの能力は一目で分かるだろう。

【バグ収束曲線・メトリクス】
BTSの利点の一つは、過去の障害データが一括管理されているので、そこから各種のメトリクスを出力できることだ。
よく使われるのは、信頼度成長曲線(SRGM)、別名はバグ収束曲線だろう。
実際のテスト工程では、テスト消化曲線とバグ発生曲線を一つのグラフでまとめると、テストプロセスの品質が一目で分かる。
詳細は下記に書いた。

テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索

メトリクスでソフトウェア品質を見える化する: プログラマの思索

信頼度成長曲線(SRGM)は既に理論としては既に枯れているアイデアだが、そこからMTBFやMTTRを理論的に計算できる点が興味深い。
SRATSというフリーのExcelマクロを使えば、システムのMTBFを計算することも可能。

SRATSの使い方: プログラマの思索

個人的には、MTTRの方が重要な気がしている。
何故なら、平均修復時間(MTTR)はチケットの平均作業完了時間とほぼ同じ概念だからだ。
Mantisでは、チケットの平均作業完了日数がデフォルトで表示されているので便利。

Mantisのチケット集計機能にある最大放置日数と平均完了日数: プログラマの思索

MTTRが重要な理由の一つは、MTTRとイテレーションが密接に関係するからだ。
アジャイル開発では、MTBFを長くするよりも、MTTRを短くすることによって、稼働率を高めようとする方向が見受けられる。

アジャイル開発と品質管理の関係: プログラマの思索

XPやScrumのイテレーションは普通は1ヶ月だが、もちろんもっと短くすることも可能。
だが、理論上はMTTRよりもイテレーションを短くすることはできない。

【同類バグ・残存バグ・ブロッキングバグ・みなしバグ】
障害管理では単にバグ修正だけでなく、バグの原因分析や同類バグ(同種バグ)の調査の方が重要だ。
何故なら、バグの周囲には似たようなバグがたくさん潜んでいるからだ。
バグの原因には、特定の開発者が仕様を誤って理解しているがために、彼が開発したソース全てに影響がある時もある。
あるいは、バグの原因がとても繊細なため、そのバグが治っても、他の機能に影響があるために、他の修正方法を選択せざるを得ない時もある。
バグはマインスイーパーのように、同種バグがたくさんあるのが普通のため、修正工数よりも原因分析や影響調査の方に工数がかかる時が多い。

バグはマインスイーパーみたいだ: プログラマの思索

同類バグに似たような概念として、残存バグがある。
残存バグとは、テスト工程でバグを完全に潰しきれずに、残したまま本番リリースしてしまい、リリース後に発見したバグを指す。
残存バグが多いほど、そのシステムの品質は低い。
テスト技術や品質管理では、いかに残存バグを洗い出して、信頼性を高めていくか、を重視する。

バグの概念としては、ブロッキングバグやみなしバグなどがある。
普通は、一つのバグが発覚したら、そのバグのせいで、失敗したテストケースに依存するテストケースがブロック状態になる。
ブロッキングバグは文字通り、テストだけでなくプロジェクト全体をブロックしてしまう重大なバグを指す。
ブロッキングバグのせいで、実施しないテストケースも失敗になると分かっていたら、テストケースをみなしNGとして、そのバグはみなしバグと見なす。

テスト管理では、ブロッキングバグをいかに早く見つけて潰し、テストの進捗を妨げないように進めるか、が重要だ。
だから、TestLinkのブロックは、テスト管理で最も重要な技術の一つ。

TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念: プログラマの思索

バグ修正で怖いのは、バグ修正時に他のバグを入れ込んでしまう可能性があること。
「欠陥フィードバック率(FFR：Fault Feedback Ratio)」とは、バグ修正によって引き起こされるリグレッション率を指す。
「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」では、「10回バグ修正したら、1～3回もデグレ又は別のバグが発生する」と紹介されている。
おそらく普通のプロジェクトでも同じようなメトリクスになると思われるから、バグ修正した時は、バグの検証だけでなくコードレビューやデザインレビューで、デグレが起きてないことを確認したり、修正の影響がないことを見極めることが重要になってくる。
そうしなければ、デグレが起きてしまい、開発チームやテストチームのモチベーションを下げてしまう。

アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する: プログラマの思索

障害管理で嫌なのは、バグがもぐら叩きのようにでてくることだ。
TestLinkのアンチパターン: プログラマの思索でも書いたけれど、ブロックを使わないテストチームは、みなしバグがあると分かっているテストを行って、無駄にテスト工数を浪費してしまい、納期までに間に合わなくなる。
あるいは、ブロッキングバグの影響調査に工数をあまりかけずに安易に修正してOKとしてしまって、新たなバグを作ってしまう時もある。

バグの原因分析やデグレを起こさない回帰テストがテスト工程では重要な技術の一つ。

【ITSへ拡張】
障害管理はソフトウェア開発で最も基本的なワークフローであるがために、このワークフローを仕様変更や新規開発、課題管理などへ拡張して使おうという発想が生まれた。
この発想がIssue Trackingと呼ばれる概念になる。
チケット駆動開発は元々まちゅさんがTracのチケット管理として公開したアイデアだが、BTSをIssue Tracking Systemとして扱うだけでなく、高機能化したBTSをアジャイル開発のプロジェクト管理に使う流れにつながる。

チケット駆動開発については又改めて書く。