チケット駆動開発 (TiDD) とアジャイル開発
チケット駆動開発とアジャイル開発の親和性について、つらつらと考えてみた。 確信は持てていないけど、今の考えをまとめておく。
チケット駆動開発について
2007年に開催された ITpro Challenge! の LT で、もうひとつのTDD開発としてチケット駆動開発を紹介してから1年半になる。 チケット駆動開発のポイントは「チケット無しでのコミット禁止」ということ。 必ずチケットを発行するルールによって、2つのメリットが生まれると考えていた。
- 開発メンバの仕事が把握しやすくなる
- ソースコードのコミット単位が明確になる (目的が異なる修正を同時に加えない)
1.は簡易版の Microsoft Project みたいなもの。 仕事を適切な単位に分割して、チケットとして開発メンバに割り振ることでプロジェクト全体の進行状況が把握できる。 簡易版と書いたのは、開発メンバの作業時間やクリティカルパスを把握するためには、 Trac にはもう少し機能が必要だと思うから。 Redmine は未使用なので分からない。 基本的にTracとMS Projectではプロジェクトの管理方法と管理項目が異なるので、連携させない方が良いという意見もあるみたい。 この辺はもうちょっと知りたいところ。
2.は「チケット無しでのコミット禁止」というルールで実現できる。 構成管理ツールのチェンジセット (ソースのdiff) とタスク管理ツール (チケット) を連携させることで、よりトレーサビリティの高い管理が可能になる。
1.と2.の両方を実現できるのが、チケット駆動開発の利点だと考えている。
アジャイル開発との親和性
このチケット駆動開発 (TiDD) だけど、どうやらアジャイル開発の親和性が高いらしい。
「らしい」というのは、僕がアジャイル開発の経験がないから。 リンク先の資料によると、以下のような流れみたい。
- アジャイルは短期間の繰り返し開発
- タスクを細分化し、ソースを頻繁に修正する
- → チケットを使って細分化されたタスクとソースの変更を管理する
僕が TiDD を実践したときも、たくさんの小さな修正を加えるシステムだった。 TiDDでは、ソースの変更と1対1で対応できる粒度までチケットを細分化するので、確かに1つ1つの修正が小さなケースの方が適用が容易かもしれない。
TiDDによるプロジェクト管理は可能か … ワークフローの大切さ
感覚的には、5人くらいまでのプロジェクトであれば、シンプルな TiDD でプロジェクトを管理できると思う。 10人を越えると、1人のリーダーが全てのソースの変更を把握するのは困難になる。 その場合は、チームを2つから3つのグループに分け、それぞれのグループを管理することになる。
TiDD で複数のサブグループを管理するときには、ワークフロー機能がより大切になる。 チケットを新規に発行し、チケットと対応する修正を加え、テストで機能を確認してチケットをクローズするという一連の流れで、適切にチームメンバに権限を割り振らなくちゃいけない。 他のメンバが知らないうちに、誰かが勝手にチケットを発行して、勝手にソースをコミットしちゃうと収集がつかなくなる。 なので、ワークフロー機能を使って、適切にプロセスが実行されていることを保証することが重要。
Trac のバージョン 0.11 ではワークフロー機能が強化されているし、 Redmine は従来からワークフロー機能が豊富みたい。
今後の普及のために
アジャイル開発で TiDD を適用するためには、おそらく Trac や Redmine などのタスク管理ツールよりも開発プロセスのほうが大切。 チーム体制に合わせて開発プロセスやチケットのワークフローをどう設定するかが、うまく適用できるかどうかのポイントになると思っている。 逆に、あらかじめワークフローを設定したタスク管理ツールを、構成管理ツールやCIツールとセットで提供できれば、もっともっと導入の敷居が低くなるかもしれない。 ちょうど、 GitHub がオープンソースの開発の敷居を下げたように。
追記
タスク管理ツールでのワークフローの大切さは、以下のページが参考になる。
上記のようなワークフローは、実際の現場で運用しながら作られたものなので、どんな開発プロセスや開発体制になっているのか、を考える参考資料になりうる。
ワークフローこそ厳格にプロセス管理すべき対象。ワークフロー管理がプロジェクト管理の要だと思う。
もう一つはこちら。
結局、チケット駆動開発を実践しようとして混乱する根本原因の一つは、ワークフローと言う概念を認識していないから、と言える。ワークフロー、つまり、チケットの状態遷移図は表裏一体の概念。