何故チケット駆動開発はタスクやイテレーションの変更に強いのか？

Redmine.JP | Redmine on Twitterを見ていて、下記の質問は、「何故、チケット駆動開発はアジャイル開発に使えるのか？」「何故、チケット駆動開発はタスクやイテレーションの変更に強いのか？」を示唆するヒントだと直感した。
考えた事をメモ。
#下記はあくまでも一つの参考意見。

【元ネタ】
Twitter / EG: Redmineとかtracとかで「ちょっと気になって ...

Redmineとかtracとかで「ちょっと気になってること→対応すべきこと」というレベルアップや「○○バグの修正」と「ソースの全般的な修正」のような規模の違うものをどう扱うのがいいのだろう

上記の質問に対する回答としては、二つあると思う。
一つ目は、タスクの内容に応じてワークフロー(トラッカー)を変えて管理する。

チケット駆動開発の基本ルールは「チケットファースト」。
プロジェクト内部の作業はチケットを受け取ってから始めるのが基本。
チケットがあれば作業履歴が残るし、作業状態や進捗情報をリアルタイムにモニタリングできる。

すると、チケットには、機能追加やバグ修正だけでなく、リファクタリングや設計作業、リリース作業、問合せなど各種の仕事がどんどん登録されてしまう。
だから、チケット駆動開発を使いこなすには、チケットを上手に使いこなすのが最優先だ。

Redmineでは、チケットの種類がトラッカーに相当し、ワークフローと1対1に対応している。
従って、作業の種類をトラッカーに対応付けて、作業特有のワークフローをチケットのワークフローで管理すれば、ソフトウェア開発の全ての作業をチケット駆動開発で制御できる。

つまり、ソフトウェア開発で発生する業務フローをきちんと設計ないしモデリングできていれば、トラッカーは自然に定まる。
この作業は、SIが各種業界の業務を設計してシステムを構築する作業と同一だ。
即ち、実は自分達のソフト開発業務をきちんと設計していない、つまり開発プロセスをきちんとモデリングできていない現場が多いから、混乱しているのだろう。

例えば、「ちょっと気になってること」は「ToDo」のチケット、「○○バグの修正」は「バグ修正」のチケット、「ソースの全般的な修正」は「リファクタリング」のチケットなどのようにワークフローを変えて登録しておけばいいと思う。

二つ目は、最初はチケットをToDoのように扱ってまずは登録しておき、そのチケットが必要になった時点で更に分割し、リリースするイテレーションにアサインしてから、作業を管理する。つまり「分割統治」の運用ルールを使う。

実際のソフトウェア開発では、WBSで洗い出したタスクをチケットへ一括インポートしてから作業するが、仕様変更や突発的なタスクの発生によって、当初登録したチケットの内容が変わり、更にチケット枚数は大幅に増える時が多い。
このタスク管理をExcelやMSProjectで行うと、度重なる変更に追いつかない時が多い。

RedmineやTracのようなチケット駆動開発をサポートするITSでは、チケットの登録や変更がすごく柔軟な利点がある。
本来BTSだったので、突然発生したバグ報告を登録しやすくする機能が付いているから、その機能を一般のタスク登録に拡張して運用すればいいからだ。
例えば、突然発生した仕様追加は、タスクの内容をチケットに登録して1枚作ればいい。

又、機能追加のチケットを担当しているのに、実はリファクタリング作業に工数がかかっているならば、リファクタリング用のチケットを別出しにして、そちらのチケットを最優先に作業すればいい。
そして、機能追加とリファクタリングのチケットを関連付けておけば、忘れる事もなくなる。

同様に、以前、ToDoのチケットを登録して、いざ作業を開始すると、作業の種類が変わったならば、トラッカーを変更して、その作業特有のワークフローへ切り替えればいい。
このパターンに当てはまる場合は、以前はToDoのチケットだったが、リファクタリングや機能追加のチケットに切り替えて作業を開始する時だろう。
当然、作業の開始日や期限日も現状に合わせて修正すればいい。

上記のようにチケットの内容だけでなく種類(トラッカー)も簡単に変更できるから、タスク変更がしやすいので、アジャイル開発しやすいのだ。

あるいは、Ver1.0のチケットは、ユーザと調整して後回しになった場合、そのチケットのリリース予定バージョンを新しく作ったVer1.1へ延期する時もあるだろう。
つまり、イテレーション計画やリリース計画を途中で変更しても、イテレーション間でチケットを移動すればいい。
そのイテレーションを2～4週間のサイクルで順次リリースしていけば、自然に「小規模リリース」を実現できる。

チケット駆動開発がアジャイル開発しやすいのは、上記のようなイテレーション管理もやりやすい利点があるからだろう。

以上のような運用が開発チームに馴染めば、システムのバージョンが自然にイテレーションとなり、自然にアジャイル開発になってくる。
イテレーションのリズムが生まれれば、プロセスがループする事によって、自然にプロセス改善できる。

チケット駆動開発が自然にアジャイル開発になる理由がそこにあるはずだ。