プログラマの思索

BTSをITILのインシデント管理などに使うアイデアをメモ。
#走り書きは後でまとめる。

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

【1】BTSをインシデント管理にも使いたい。

ITILのインシデント管理とは、業務で支障があった時の問い合わせの管理。
開発チームとしては、ユーザであるお客自身に、画面操作やデータ不整合などの問い合わせ、バグ、機能追加の要望をBTSのチケットを書かせたい。
ユーザが、開発してもらったシステムを使い込んでいるし、どこの機能を使いやすくして欲しいか知っているからだ。
つまり、インシデント管理は、サポートデスクのFAQ管理とも言える。

インシデント管理は、やり取りの履歴を後からすぐに検索できるのが重要だ。
問い合わせを採番することで、ユーザや開発者とコミュニケーションしやすくなる。
問い合わせの現象の件は、番号XXのことですね、と。

また、似たような問い合わせは、番号XX番を見て下さい、とかわすことができる。
インシデント管理の最終目的は、顧客からの無駄な問い合わせを減らして、開発者が本来の開発に専念できる環境を作ることだと思う。

Redmineならフォーラムに要望やバグをお客自身に書いてもらうとよいと思う。
管理者がフォーラムの要望を精査して初めてチケット登録する。
何でもかんでもチケットに登録するとチケットが発散するから。
　
つまり、フォーラム機能をチケット登録前のフィルタリングとして使う。

チケットには、使い方とかパスワード失念のような問い合わせというインシデントは書かない。
チケットはあくまでも、バグ修正や機能追加など、本来の開発にかかわる作業だけにする。
チケットの内容のスコープを濃縮したいから。

つまり、ITILの問題管理はBTSチケット、ITILのインシデント管理はBTSフォーラム機能と使い分けるやり方が良いと思う。
更に、ITILの構成管理は、SVNコミットログとチケットの紐づけ、チケットの作業履歴から可能なはず。
ITILのリリース管理は、CIツール(Continuous Integration)で代用できると考える。

【2】チケットの「終了」は管理者だけが行う権限とする。

テスト担当者は「新規→担当」「解決→検証完了」は操作できるが、「検証完了→終了」は操作させない。
理由は、作業の品質を最後は管理者がチェックする必要があるから。

駄目なプロジェクトは、メンバーが勝手にチケットをどんどんOpenしてはCloseしてしまう。
チケットを乱発して担当者のタスクが溢れる。
チケットの検証が不十分なまま、担当者が勝手にCloseしてしまう。

20人以上でTracを運用した時、チケットが乱発して、担当者のタスクがすぐに溢れた。
チケットをCloseしてもバグが直っていないこともしばしばあった。
修正担当者自身がチケットをCloseしていたから。

チケットのステータスを変更する時の作業の品質管理がチケット管理の肝だと思う。

【3】1つのバグ報告票に対するテスト担当者、開発者の役割切り替えは、RSS機能、メール自動送信機能を有効に使う。
この機能で、役割の切り替え時に管理者の手を煩わせる必要が無くなる。
Excelや紙のバグ報告票でやり取りしていた頃は、必ず管理者の手を通過させていたから、管理者はすぐにタスクが溢れてしまい、バグがなかなか収束しなかった。

だが、複数の会社に担当者がまたがった場合は、調整する役割を担うマネージャが必要。
オフショア開発、下請け開発など、複数の会社というレイヤーが多いと、誰が修正するのか、というマネジメントを誰かが担当しなければ解決できない。

BTSは万能ではない。

【4】スケジュール作成は、Pullスケジュールであるべきと思う。

つまり、PLが作ったスケジュールを押しつけるのではなく、各メンバーが自然にスケジュールを引き出して考える環境を作る。

Redmineには、チケットに予定工数という欄がある。
チームメンバーに自発的に工数を見積もりをしてもらう。
見積もりは上からの押し付けでない。
開発者自身の見積もりなので、精度は高いはず。
更に、チケットの仕様についてメンバー同士で調整したりして、チケットに作業履歴を書く。
XPのタスクカードの見積もりに相当するだろう。

開発者自身の工数見積もりと実績工数から、見積もり速度、つまり、1日の稼働率が分かる。
統計を取っていないので分からないけれど、普通は、1日8時間のうち、実際の稼働率は6時間ぐらいではなかろうか？
リリース直後にトラブル続出で、5分おきにユーザから大量の苦情電話に対応していたら、それだけで1日が終わってしまう。
その場合は、稼働率は０％だろう。

大まかなスケジュールは管理者が作るとしても、細かなタスクのスケジュールは、メンバーの積極的なモチベーションを引き出すようにBTSをうまく使えばいいと思う。

BTSをITILのフレームワークに乗せるアイデアは更に考えてみたい。