あきぴーさんの記事を読んで、そもそも scrum が組めていればそもそも起こらないんじゃないの?と思ったのでつらつら書いてみる(あきぴーさんも書いているけど) チケット駆動開発のアンチパターン: プログラマの思索 1-1,乱発されたチケット スプリントプランニングでタスク分割をメンバー全員で行う。 よって、チケットはメンバー全員で合意の上で作成されるので、乱発されることはない。 テスト時の不具合にしても、1イテレーション中での数はそれほど多くないと予想できるので、制御できないほどのチケットは作成されないと思われる。 1-2,有効期限切れのチケット・放置されたチケット スプリントプランニングで登録されたチケットは1スプリントですべてクローズされるはず。 残ったチケットはバックログ未完了になるので、振り返りで完了できない理由を明確にしたのち、再度振り分け(登録)される。 よって、放置されるのは
チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く