Agile開発の肝はイテレーションにあり

Redmineでチケット駆動開発を運用するまで、Agile開発を体で理解できていなかった。
XPを実践したいと思っていても、本当のAgile開発は何か違うのでは？と思っていた。

何故、僕はTracではなくRedmineを使ってAgile開発を発見できたのだろうか？

RedmineがAgile開発と相性が良いのは、Redmineの「バージョン」の概念がAgile開発の「イテレーション」「スプリント」と自然に一致するからだ。

Redmineでは、バージョンに紐づくチケットが全て完了ステータスになって、進捗率が全て100％になれば、いつでもそのバージョンをリリースできる仕掛けが入っている。
つまり、バージョンをイテレーションと見なせば、各バージョンを次々にリリースしていけば、自然に小規模リリースを実現できる。
小規模リリースこそが漸進型開発、つまりインクリメンタル型開発の最大の特徴なのだ。

Agile開発は運用しにくい、と思っている人達の原因の殆どは、イテレーションという概念を自分たちのプロジェクトで見つけられてないのだろうと思っている。

僕がTracを初めて運用した時にうまく使いこなせなかったのは、イテレーションをTracの機能で見つけられなかったのが最大の理由だと思う。
だから、Redmineでチケット駆動開発を実践してAgile開発の運用に成功した後、Tracを再び使う事になった時、Tracの機能をもう一度精査し直した。

Tracには、マイルストーンとバージョンという概念がある。
Agile開発のイテレーションと一致するTracの機能は「マイルストーン」だ。
理由は、Tracのロードマップ画面に表示されるのはTracのマイルストーン単位の完了チケット率であり、TracのマイルストーンのライフサイクルはAgile開発のイテレーションと一致するからだ。
実際、Tracでは、マイルストーンの「完了」ステータスを選択すれば、そのマイルストーンはロードマップ画面から消える仕掛けになっている。
つまり、リリースされたので、Tracのマイルストーンは見せる必要がなくなったということ。

Tracの「バージョン」はSVNのタグのような機能に過ぎない。
だから、Tracの「バージョン」はイテレーションにはなりえない。

RedmineとTracの機能比較: プログラマの思索

だから、Tracのマイルストーン単位にタスクをチケットで分類して、小刻みにリリースする開発スタイルになってから、自然にテンポよくプロジェクトの作業が流れるようになった。

Mantisでもイテレーションの概念はある。
Agile開発のイテレーションの概念は、Mantisの「修正済みバージョン」に相当する。

Mantisの使い方: プログラマの思索

更に、Mantisにも「ロードマップ」「変更履歴」の機能があり、それらはRedmineと同等の機能だ。
実際、Mantisのロードマップは、修正済みバージョン(リリース済み・リリース予定バージョン)ごとにチケットがまとめられていて、変更履歴はリリース済みバージョンのチケットの履歴になっている。

Roadmap [MantisBT]

僕は、Redmine、Trac、Mantisを使ってみて、いずれのツールでもチケット駆動開発は可能であり、Agile開発のタスク管理を行うことは可能だと経験したし、確信している。

そして、イテレーションの概念や小規模リリースの利点は、開発チームにリズムが生まれること、そして、そのリズムがプロセス改善を生んでくれることだ。

イテレーション単位にリリースするから、ユーザもいち早くシステムに触ることができるし、開発チーム自身も実際のシステムに触れて、設計漏れや要件漏れにいち早く気づくことができる。
何よりも、定期的にリリースするリズムがあるから、メンバーもそのリズムに合わせるようにタスクを調整するようになる。

そして、リリース後にKPTでふりかえりミーティングを開けば、今回のリリースの良かった点だけでなく反省点を洗い出せるから、次のリリースに向けて、自分たちのプロセスを改善していく雰囲気が生まれる。
定期的なふりかえりによって、自分たちのチームの特徴にあった運用ルールを作りこんでいけばいい。

チケット駆動開発はツールに依存しすぎだ、と言われることもあったが、今は気にしていない。
Agile開発を確実に運用するには、従来のやり方とは違った手法が必要であり、高度なツールを必要とすることを体験できたからだ。

更に、ソフトウェア開発プロセスの基本は結局バグ管理であり、BTSをいかに使いこなすかにかかっているのではないか、と直感している。