補完チケット方式はチケット駆動開発の先祖返り

さかばさんの記事を読んで思ったことをメモ。

【元ネタ】
[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば

[#TiDD] チケット駆動でAdaptable Waterfall開発！: ソフトウェアさかば

いきなりBTS/ITSをベースに全ての作業をチケット化してタスク管理する完全チケット方式が難しい場合、補完チケット方式という手法がある。
補完チケット方式の具体例の一つは、テスト工程の障害管理。
又、チケット駆動開発をWF型開発に適用する場合、一番導入しやすいのはテスト工程の障害管理。

要件定義、設計、開発、単体テストと順調に進んでも、結合テスト以降のテスト工程は予期しないバグ修正や突然の仕様変更が頻発しやすい。
そこで、チケット駆動開発を導入したいなら、チケット管理システムをまさにバグ管理として導入して運用すればいい。
そうすれば、システムの修正にまつわるすべての事象、作業はBTSに集約され、ワークフロー管理でき、集計した結果から是正対策や予防対策を講じることもできる。

現代のソフトウェア開発ではITS/SCM/CIは必須ツールだと思うが、実際はBTSすら導入しておらずExcelでチマチマと課題一覧や障害一覧を保守しているプロジェクトも多い。
そんなプロジェクトには、いきなり完全チケット方式によるチケット駆動開発でAgileに開発するよりも、まずはBTSをバグ管理として運用する所から始めた方が確実だろう。

BTSで障害管理プロセスをきちんと学習できれば、バグ修正とバグ検証というコーディングパイプラインは、仕様変更にも新規開発にも運用保守にも拡張可能。
必ず二人の目を通して作業をチェックし合うというプロセスをスムーズに連携できなければ、チームで開発するのは難しいだろう。
そしてチケット駆動開発を意識すれば、BTSの機能を拡張したプラクティスを導入できて効果を発揮できるだろう。

BTSからチケット駆動開発へ進化した歴史から眺めれば、補完チケット方式は先祖返りの開発スタイル。
丁度、哺乳類が海から陸地に上がって進化した後、海に戻って活動領域を広げていったイルカやクジラに似ている。
でも普通の魚類とは違って、進化した哺乳類なのだ。