チケット駆動開発を日本発のアジャイル開発へ発展させるには？

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

【元ネタ】
[TiDD] 小規模開発の難しさを考える: ソフトウェアさかば

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

アジャイル開発は元来、小規模で変化の激しいプロジェクトが向いていると言われてきた。
しかし、XPが出現して10年も経つというのに、現場の実践例は非常に少ない。
ネット上でアジャイル開発の情報がこれだけ溢れていて、開発者も興味を持っているのに、事例になかなかお目にかからない。
情報処理試験の勉強でも、プロセス改善のセミナーでも、繰り返し型開発の重要性が叫ばれているのに、事例は非常に少ない。

その原因は、単純にアジャイル開発を実践できる技術力が足りないからだと思っている。
テスト駆動開発を実践するには、JUnitを使いこなさねばならない。
常時統合するには、Hudsonのようなビルド管理ツールが必須だ。
そして、イテレーション単位に頻繁にリリースするには、頻繁に変わるタスク管理を制御しなくてはならない。

アジャイル開発の最大の特徴は、超短期間の繰り返し型開発だ。
頻繁にリリースできる技術力、プロジェクト管理能力があるからこそ、スコープ・コスト・納期の三角形でプロジェクトマネジメントを行えるのだ。
頻繁にリリースしても品質を維持できる技術力がなければ、スコープを制御することは事実上不可能だ。

そして、チケット駆動開発は、まちゅさんがTracのチケット管理をタスク管理に使った所から生まれた。
更に、僕は、アジャイル開発のタスク管理にチケット駆動開発を適用することで、アジャイル開発が非常にスムーズに運用できた経験をした。
それは単に繰り返し型開発ができただけの意味ではない。
イテレーションと言うリズムがあるからこそ、現場リーダーが優先順位付けマシンになり、朝会で各自がタスクを確認し合い、リリース後にKPTでふりかえる雰囲気が開発チームに生まれた。

チケット駆動開発のインフラのおかげで、アジャイル開発がスムーズに運用できて、チーム内に変化が起きて、チームが成長する螺旋構造が生まれた。

そのチケット駆動開発は、BTSという従来のツールを駆使する。
僕の数少ない経験では、RedmineでもTracでもMantisでもチケット駆動開発は運用可能だ。

その中でもRedmineが最もアジャイル開発しやすい理由は、一目で進捗が分かるロードマップ機能と柔軟なワークフロー管理機能の2点にあると思う。

ロードマップこそがXPのイテレーション計画であり、Scrumのスプリントバックログへ適用できるのが一番の肝だ。
そして、リリース後は終了したロードマップはリリース履歴になる。

更に、柔軟なワークフロー管理機能のおかげで、バグ修正だけでなく、インシデント管理や課題管理などSW開発の全てのワークフローをBTS上へのせることができる。
特に、BTSチケットをバグ修正だけでなく仕様変更にも使うことをIssueTrackingと呼ぶ。
これはチケット駆動開発でもすごく重要な機能だ。

このチケット駆動開発を、たくさんの人の事例をプラクティスへ濃縮させて、日本発のアジャイル開発までブラッシュアップしたい。

日本のアジャイラーの第1人者の平鍋さんは、XPから始めて、プロジェクトファシリテーション(PF)を編み出した。
PFのアイデアの影響力はものすごく大きくて、色んな人が知的刺激を受けて、関東や関西、九州でPFPコミュニティが生まれた。
同様に、チケット駆動開発が実際の現場で働く人に刺激を与えて、良い方向に進められればと思う。