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

チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。
以下メモ書き。

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

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

【1】チケットのアンチパターン
【1-1】乱発されたチケット

よくある最悪なパターンは下記2ケースがあるだろう。

設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。
あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。

そのままチケットに登録すると、チケットが乱発される。
そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。

こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。

【1-2】有効期限切れのチケット・放置されたチケット

終了予定日を過ぎて放置されたチケットを指す。
担当者がアサインされていないチケット、担当者も作業を忘れてしまったチケットが相当する。
こういうチケットが増えるたびに、チケットの精度も運用ルールも混乱していく。

対策としては2種類あると思う。
一つは、チケット管理の最終責任者は現場リーダーである事。
現場リーダーは、定期的に必ずチケットが最新の状態であるかチェックし、担当者へ逐一作業確認すべきだ。
担当者がアサインされていないチケット、リリース予定のバージョンがないチケットはすぐに保守すべきだ。
それが現場リーダーの本来の仕事であるからだ。

もう一つは、バックログのような特別なイテレーション、インシデント管理用プロジェクトのような特別なプロジェクトで管理すること。
顧客からの改善要望や問合せは、Scrumのプロダクトバックログのように、バックログのイテレーション又はインシデント管理用のプロジェクトで別管理する。
開発チームは、それらをチケットに登録しておくが、平時の開発作業とは別の作業であると認識し、リリース計画を立てる時に、顧客の要望や問合せを精査して、どのバージョンへリリースするか、取捨選択する。
つまり、XPの計画ゲーム、Scrumの計画プロセスに相当する作業を、バックログやインシデント管理プロジェクトで行う。

あるいは、ソースがコーディングルールに則っていない、とか、リファクタリングすべきだが優先度が低いなどの開発チーム内部の作業は、内部課題の特別のイテレーションで別管理する。
これらもチケットに登録しておくが、平時の開発で関係するチケットにリンクさせておく。
これらのチケットは、リスク管理に相当する。
工数見積もりが実績と大きく異なるのは、リファクタリング工数を見積もっていない場合がとても多いからだ。

【1-3】責任が重すぎるチケット

複雑で大変な作業、複雑な複数の成果物を作る作業を一人の担当者がアサインされた一つのチケットにしてしまう状況。
その担当者のプレッシャーは大きいし、担当者がもし新型インフルエンザにかかったら、誰もカバーできなくなる。

チケットは仕様書ではなく、作業指示書だ。
だからこそ、WBSのように成果物単位に細分化し、更に1個の成果物を一人の担当者が1週間以内に作業するまで細分化すべきだ。
実際の現場に合わせて、チケットの粒度はカスタマイズすればいい。

おそらくリリース後に集計したら、1人日以内のチケットへ細分化されているだろう。

【1-4】停滞したチケット

アサインされた担当者のチケットの進捗が進まない状況。
よくある状況は、進捗が90％のまま1週間経ってしまうこと。

対処としては2つある。
一つは、実績の進捗率は、0％・50％・100％の3種類と固定する方法のように、ルール化する。
つまり、チケットのステータスと進捗率を対応付けする。

もう一つは、チケットの中身を精査して、別作業を別チケットへ細分化すること。
チケットの進捗が悪い原因は、WBSの洗い出しが不十分だった時が多い。

例えば、1個の画面を実装するのに、実は複数の共通ライブラリ、モジュール、共通画面を作るために工数がかかっている、とか、新規の機能追加のはずなのに実はリファクタリングしていた、など、作業の予定と実績が大きく狂っている時が多い。
つまり、現場リーダーの作業割り振りが間違っているのが原因の大半だ。

【1-5】タスクがチケットに書かれない

開発チームでやるべき作業をチケットに登録していない状況。
例えば、ビルド作業、テストデータ作成作業、開発環境の構築作業などのように、顧客に無関係で開発チーム内部でやるべき作業を登録せずに、あうんの呼吸でやっている場合が多いだろう。

すると、やるべきタイミングで作業を忘れて、進捗が遅れたり、作業の品質そのものが落ちる。

この状況の根本原因は、WBSの洗い出しが不完全か、せっかく洗い出したWBSをチケットにすべて登録していないか、のどちらかだ。
つまり、現場リーダーがチケット駆動開発の運用ルールを徹底できていないのが根本原因だ。

【1-6】SCMと連携されてないチケット

SVNコミットする時に、チケットNoを書き込まず、チケットとSVNリビジョンが紐づかない状況。
まちゅさんは「No Ticket, No Commit!」と呼んで重視している運用ルール。
この状況では、せっかくのチケットが単なる作業履歴に過ぎない。

チケットとSCMが連携することによって、要件からソース、ビルドモジュールまでチケット経由で相互に追跡可能になる利点がある。
特に要件管理を実現したい場合に、とても強力な運用ルールだ。

【2】バージョンのアンチパターン
【2-1】ゴールの見えないバージョン

いつまで経ってもリリースできないバージョン。
よくある例は、顧客の改善要望の言いなりになって、バージョンへどんどんチケットを追加していくこと。
すると、いつまで経ってもリリースできないどころか、システムの品質がどんどん劣化していく。
機能追加すれば、必ずバグが紛れ込んでしまうからだ。

ScrumでもXPでも、スコープをあらかじめ制御しておくことを重視する。
イテレーション実施中に突然の仕様変更の要求が来たとしても、基本は次イテレーションに回して、すぐに対応しない方がいい。
機能追加よりも品質を重視する方が、手戻り作業が少なくなるからだ。

【2-2】優先度がごちゃ混ぜのバージョン

リリース計画、イテレーション計画がきちんと行われず、一つのバージョンに全てのチケットが放り込まれた状況。
例えば、顧客の問い合わせ・改善要望・障害報告、リファクタリングなどの作業が混じっていて、メンバーは、何から手をつければよいか、分からなくなっているだろう。

XPの計画ゲームでも、Scrumの計画プロセスでも、リリース計画をきちんと作る。
複数のバージョンを立てて、定期的に小刻みにリリースしていくという開発スタイルを取れば、チケットの優先度は自然に定まる。
顧客の要件の重要度と開発工数のバランスから、リリース計画が作られて、そのバージョンにチケットをアサインしていく。
上記の状況に陥った原因は、現場リーダーがプロジェクトのスコープをきちんと管理できていなかったことにあるだろう。

また、開発サイクルが異なるチケットは別管理にした方がいい。
例えば、顧客からの単なる質問やリファクタリングなどは、別のバージョンやプロジェクトで管理した方がいい。
本番運用のソースと新規開発中のソースをブランチで別管理するように、プロジェクトもブランチ単位で分けた方がいい。

【3】プロジェクトのアンチパターン
【3-1】大規模プロジェクトでごちゃ混ぜのプロジェクト

大規模プロジェクトでは、複数のサブチームのタスク管理が必要になるが、一つのプロジェクトに全てのサブチームのタスクが混在している状況。
TiDDを実践すると、経験的に5人以上のチームのタスク管理は非常に煩雑になる。
理由は、TiDDにおけるチケットの粒度は開発者視点なので、とても細かいからだ。

だから、複数プロジェクト機能を使って、サブチーム単位や工程単位などで分けた方が管理しやすいと思う。

また、チケット管理の専門担当者を配置し、随時チケットを保守させる。
更に、定期的に課題管理会議を開いて、チケットの棚卸を行った方が良い。
チケットに上がった問題が複数のサブチームが連携しなければ解決しない場合もあるので、調整作業が必要だからだ。
あるいは、どのチケットから手を付けた方が良いか、サブチームのリーダーの観点ではなく、もっと上層部のマネージャの観点で優先度を決めた方が良い場合も多々あるだろう。

他にも気付いたアンチパターンがあれば、随時追加していきたい。