BTSをインシデント管理などに使う
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日が終わってしまう。
その場合は、稼働率は0%だろう。
大まかなスケジュールは管理者が作るとしても、細かなタスクのスケジュールは、メンバーの積極的なモチベーションを引き出すようにBTSをうまく使えばいいと思う。
BTSをITILのフレームワークに乗せるアイデアは更に考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「Redmine」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
「ソフトウェア工学」カテゴリの記事
- なぜInfrastructure as Codeが必要なのか?(2021.04.18)
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「Git・構成管理」カテゴリの記事
- なぜInfrastructure as Codeが必要なのか?(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
「チケット駆動開発」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
コメント