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

チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過

[nilab]

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

[teppeis]

「チケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。」

[shiumachi]

"優先度がごちゃ混ぜのバージョン"これは本当に困る。というか、優先度を決める権限のある人が真っ当に優先度つける仕事してくれないとチケット管理の威力はガタ落ちする。それでもないよりマシだけど

[ikasam_a]

確かにリーダーが常にチケット管理してないと無理だよね

[p260-2001fp]

『有効期限切れのチケット・放置されたチケット』『登録されていないタスク』苦しい・・・どうにかしてソフト以外の人間をTiDDに引き込みたい