チケット駆動開発のアンチパターンpart2

チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。

【元ネタ】
チケット駆動開発のアンチパターン: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

【1】メトリクスの罠

RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。
管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。
メトリクスは万能ではない。

メトリクスだけではプロジェクトの現状を把握できないのが現実だ。
メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。
いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。

メトリクスはバッドノウハウの塊。過信しない方がいい。

【2】問合せはバグ修正なり

顧客からの問合せや設計者への仕様の質問をチケットへ起票する時、そのチケットをバグ修正のワークフローで管理してしまいがち。
すると、問合せの作業状態を管理しにくいし、担当者がチケット更新方法をよく間違える。
「問合せ中」「回答済み」のステータスがバグ修正のどのステータスに相当するか、正直分かりにくい。

理由は、BTSのデフォルトの機能であるバグ修正のワークフローだけでは、SW開発の全ての作業をカバーできないから。
所詮、BTSはバグ管理にしか過ぎない面がある。

また、仕様の質問を問合せフローでチケットに起票しておけば、開発中やテスト中に、何故こんな仕様になったのか、要件を探す元ネタになりうるので役立つ。
あるいは、顧客の問合せなどのインシデント管理をチケットに残しておけば、どんな問合せが多いか分析できる。
例えば、「ログインのパスワード忘れた」という問合せが多いならば、パスワードリマインダーの機能を追加したら問合せ数が減りますね、という話に持っていける。

現場のメンバーと試行錯誤しながら、ワークフローを編み出した方がいい。

【3】チケットを決められない

特に大規模プロジェクトでは、担当タスクを他のサブチームに作業をお願いしたり、上級SEを通じて顧客へ問い合わせるなど、チーム外と連携する時が多い。
その時、チームから上がったチケットをどのように対処すればいいか、プロジェクトリーダーさえも対処しようが無い時がある。
こういう状況では、関係するステークホルダー全員で決めるしかない。

大規模プロジェクトでは、「進捗会議」「課題管理会議」と称して、サブチーム間で連携しなければ対処できないタスクを調整したり、溜まったタスクを関係者全員で棚卸しする会議がある。
いわゆる変更管理会議(CCB)、あるいは変更諮問会議(CAB)。

上記のようなチケットは、このような会議で一つの議題にしてもらい、ステークホルダー全員で、優先順位付け、対処方針を立てる、各チームの調整を行うのがよいと思う。
但し、会議で決めてもらう分、利害が対立しやすく、チケットの作業期間が長くなるので注意。

【4】足りないステータス

担当者の作業状態がチケットのステータスに紐づいていない状況。
例えば、レビュー中、テスト中、本番リリース前(開発環境にリリースして検証OKだが本番リリースしていない)などのステータスが無い場合が相当するだろう。

これらのステータスがなくてもプロジェクトが回るのならよいけれど、今誰がこのチケットを担当しているのか分からなくなるようなら、ステータスを増やした方がいい。
ステータスが無いために「このチケットは今どうなっている？」というやり取りが多いならば、無駄なコミュニケーションのコストがかかっている。

ステータスが不足していると思える状況は、BTS以外のツールと連携したり、ペア作業を行いたい時だ。
TestLinkとバグ検証を連携したり、Hudsonとデプロイ＆リリース作業を連携するならば、ステータスを増やした方がやりやすい。
また、バグ修正＆検証やコードレビューをペア作業する場合は、担当者ごとのステータスがあれば、作業状態や進捗情報を追跡しやすくなる。

リリース後のふりかえりMTで、開発者とKPTしながら改善すればいいだろう。

他にも気付いたら追加していく。