チケット駆動開発のアンチパターンpart2 - プログラマの思索

チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。 【元ネタ】 チケット駆動開発のアンチパターン: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】メトリクスの罠 RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。 管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。 メトリクスは万能ではない。 メトリクスだけではプロジェクトの現状を把握できないのが現実だ。 メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。 いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。 メトリクスはバッドノウハウの塊。過信しない方がいい。 【2】問合せは

[nobeans]

"メトリクスはバッドノウハウの塊。過信しない方がいい。" / "足りないステータス":"リリース後のふりかえりMTで、開発者とKPTしながら改善すればいいだろう。"

[shiumachi]

"顧客からの問合せや設計者への仕様の質問をチケットへ起票する時、そのチケットをバグ修正のワークフローで管理してしまいがち。"私のところは「問い合わせ」を別に作成してるな