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

チケット駆動開発のアンチパターンの事例のつぶやきを見つけたのでメモ。
とても面白い。

【元ネタ】
Twitter / kobachi_dearu: チケット駆動開発は好きである。だが、身の回りを見てみると、どうも使い方がこなれていないようである。アンチパターンのようなものを見つけたので記す。

Twitter / kobachi_dearu: 【期日・バージョンのない大量の『今すぐ』チケット】　リリース直後のバグ対策など今すぐやって欲しいのはわかるが、いつ本番反映するのかという計画がない。工数の見積もりもしていない。気分の問題でやっており、今やっている作業を止めてでもやるべきか、というマネジメントができていない。

Twitter / kobachi_dearu: 【モンスターチケット】　チケットが返ってきたかと思うと、違う作業が追記されている。バグチケットが復活して「バグなおってなかった！？」と焦っていると、仕様変更や文言修正が指示されている。もちろん期日はバグ修正の時のままである。

Twitter / kobachi_dearu: 【外部連携仕様確定前に実装チケット】　のちに大量のバグチケットを生むことが約束されている。タスク分割も十分でないのでプログラマーがタスク分割して「仕様」や「実装」チケットを割り振ることになる。プログラマーにもプロジェクトマネージャーの給料を払うべきである。

チケット駆動開発がうまく運用できていないチームを見ると、似たようなパターンが多い。
そんな失敗パターンをアンチパターンと呼ぶ。
アンチパターンを見かけると笑ってしまいがちだが、実際の自分たちのチームでも当てはまる時が多くないだろうか？

「期日・バージョンのない大量の『今すぐ』チケット」は、例えば、テスト工程で大量の障害が発生したために、チケットが乱発される時が多いだろう。
同一原因で発生した似たような障害(つまり同類バグ)がチケットに登録されたため、一つのチケットを直せば、ほとんどのチケットは解決できる時が多いはず。

「モンスターチケット」は、何度もよみがえる不死鳥のようなチケット。
つまり、フィードバック(差し戻し)が頻発するチケット。
「アート・オブ・プロジェクトマネジメント」では、ソフトウェアのバグ修正では10回のうち3回は別の障害を埋め込んでしまう、という話があった。
バグが直ったと思っても、デグレードしていない確認を取るコストは結構大きい。

「外部連携仕様確定前に実装チケット」は、チケットの粒度が大きすぎるアンチパターン。
つまり、肥満児のチケット。
PMBOKのようにWBSでタスク管理する場合、一つのワークパッケージ(WP)のサイズは２週間と言われる。
でも、実際の開発者の時間間隔では、１～３人日程度まで分割した方が作業しやすいし、現場リーダーも進捗管理を安心して行える。
肥満児のチケットになる原因は、作業を１人日程度まで分割できるほど、作業内容を見通せていない点にある。
つまり、この機能を実装するには、どのように実装すれば良いのか、というイメージが沸いていない。
結局は、マネージャに技術力がないから、開発者が作業できるレベルまでタスク分割できていないだけのことだ。

こういうアンチパターンにネーミングしておけば、TiDD初心者にもノウハウを共有できるし、重要な知見として役立つ。
11/10に開催される第４回品川Redmine勉強会では、参加者全員でTiDDのパターンやアンチパターンを議論したいと思っている。

第4回shinagawa.redmine勉強会 : ATND

自分が知らない現場でのチケット駆動開発の経験事例は、皆知りたがっているのではないだろうか？
是非お楽しみに！