実践バグ管理―プロジェクトを成功に導くための
	クジラ飛行机 ソシム 2009-03 売り上げランキング : 263133 おすすめ平均 バグ管理手法にフォーカスを当てたプロジェクト管理手法読本 Amazonで詳しく見る by G-Tools

実践バグ管理の中で、ユースケース駆動開発という考え方を知った。
UMLのユースケース図を書いて、そのユースケースに合わせてチケットを発行するということか。チケットを発行する粒度として、ユースケースと成果物を元にしたほうが、自分が考える単位としてはちょうどいいんじゃないかという感触がある。

前は画面単位でやろうとしていたのだが、WebアプリもAJAXによって画面遷移なしで色々と機能を盛り込まれるようになってしまったので、それではなかなか収拾がつかなくなってしまったと感じている。そもそも俺は、AJAXで何でもかんでも1画面に入れてしまうようなやり方は好まないのだが。バグも把握しづらいし、リリースできる状態に持っていくまでに時間がかかる。リファクタリングもしにくい。ユーザにとって使いやすければ、AJAXでゴニョゴニョよりも、シンプルなほうがいいと思う。
（AJAXで一画面で色々やるようなアプリは何度も作ってるんだけどね～）

つまり、画面単位でのチケットだと、粒度がでかすぎて、チケットが終わる前に開発者が疲れる。開発者のモチベーションを保ってリズムに乗ってもらうためにも、ユースケース＆成果物単位にしたほうがええんじゃないかなと。それにチケット駆動開発を絡ませる、と。

チケット駆動開発にした場合、機能追加・バグ修正に関するログの漏れがなくなるので、開発者レベルでは手間が発生するが、どこを修正したか後で調査する手間がなくなる。一番無駄な時間というのは、探し物をする時間であると思う。一度その時間を省くことができれば、全員共通で無駄が省ける（運用方法がよければ）。

Tweet