[#TiDD] 工程名のチケットがアンチパターンである３つの理由

開発作業をチケットで管理するチケット駆動開発には完全型と補完型があります。このうち、工程名のチケットは完全型に比較的多く見られます。

チケット駆動開発は従来型の開発でも利用可能で、従来の進捗管理からあふれた作業を管理する補完型が多く行われています(２つのアダプタブル・ウォーターフォール開発)。障害はもちろんのこと、仕様変更や課題を見える化できますので、経緯の確認に有益な履歴が残り、コミュニケーションが改善され、管理も容易になります。

チケット駆動開発はとても便利ですので、完全型に移行すればもっと効果が出るだろうと、既存の管理を置き換えようと考えられる方も多いでしょう。しかし、安易に置き換えるとメリットが感じられなくなってしまいます。

それはWBSのように、工程-成果物-作業の階層でチケットを作ってしまう場合です。このような階層をチケットに対応させると、変更に弱くなります。

クローズされないチケットは見える化を阻害する

チケット駆動開発はチケットのステータスを管理します。クローズされていないチケットを管理して作業の漏れや遅延を防ぐことができます。

工程名のチケットは進捗の集約には役立ちますが、工程の作業が終わるまでクローズされません。このようなチケットは、他の作業の遅れや遅延を見えにくくしていまいます。

仕様変更で混乱する

仕様変更の作業はそれまでの工程の作業を含みます。作業チケットやコミット時に色々な工程を関連づけると論理的であっても煩雑ですし、クローズしたチケットが更新されるのも管理を混乱させます。

仮に仕様変更を工程に含まれない作業としてしまうと、現在の工程の進捗が見えなくなってしまいます。そこで仕様変更は現在の工程の作業チケットとすることになりますが、これでは現在の工程のチケットは仕様変更がつづく限り、いつまでも閉じることができなくなります。

ゴールが曖昧になる

仕様変更が発生した場合、当初のリリース予定を延ばして良いとは限りません。すると一つの工程に対してリリースが複数になってしまいます。

こうなると、工程チケットとリリースが対応しなくなり、チケット駆動開発のメリットである管理も難しくなります。チケットがゴールを表さなくなるからです。

解決法

このような理由で、工程名のチケットはアンチパターンと言えます。WBSを用いて工数見積もりをする際に工程は便利なものですが、仕様変更の多い現場では工程のチケットは足かせになります。

そこで元々工程と考えていたものは、段階的な期間と考えます。この期間はゴールとなるマイルストーンまでの期間(ITSのマイルストーン/バージョン)と考えます。

チケットを階層化する際は、要件（ストーリー）に対応するチケットを作り、その子チケットとしてタスクのチケットを起票します。

これらの解決法は、アジャイル開発におけるチケット駆動開発と同じ方法です。もし、すべてのタスクをチケット化しなくても良いなら、進捗管理は従来のままに、想定外の作業をチケット化する補完型のチケット駆動開発を検討しても良いでしょう。

追記：工程をプロジェクトやバージョン(マイルストーン)に割り当てるのもアンチパターンと言われています。
プログラマの思索「WF型開発にとらわれすぎたTiDDのアンチパターン #tidd」