TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間

TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。
＃下記はロジカルでないので注意。

【元ネタ】
裏プロセスは並行プロセス: プログラマの思索

チケット駆動開発のモチーフ: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。
Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。
すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。

そして、リリース後にKPTによるふりかえりMTを開いて、リリースしたバージョンについて、KPTの観点でヒアリングして議論したら、自然にプロセス改善になっていた。
僕は、チケットの運用ルール改善や作業の品質改善を狙っていたのだが、メンバーからは、設計書のこういう部分が分かりにくいからバグが出た、このワークフローはやりにくい、チケットでタスクの見通しがよくなった、など、色んな意見が出て、紛糾した。
そして、次のバージョンへの対策も決まり、ちょっとずつ、開発チームの作業効率も上がった。

SW開発で最も嫌なのは、ゴールが見えず、残業や休日出勤が延々と続く状況。
いわゆるデスマーチ。
リリース前のシステムテスト、リリース直後の膨大な問合せや障害報告で起きる。
特に、ウォーターフォール開発で、ドカンと一発リリースした直後が大変。
ウォーターフォール開発では、イテレーションと言うリズムが無いのが一番嫌だ。

【2】アジャイル開発では、スコープをコントロールしながら、小刻みに機能拡張しながらリリースしていく。
だから、リリース後の障害報告や問合せもそれほど多くないし、開発チームがコントロールできる範囲内に抑えられる。
何よりも、スコープをイテレーションに閉じ込めて、イテレーションというリズムが生まれるのが気持ちいい。
XPやScrumならば、必ず２～４週間後にリリースというゴールがあるので、作業が見えやすい。

チケット駆動開発では、ロードマップ画面でリリース計画やチケットの取捨選択を行う。
つまり、ロードマップ画面で、スコープを制御しながら計画ゲームを行っている感覚だ。

イテレーションは通常２～４週間という小さいタイムボックスのため、納期やコストが固定だから機能というスコープで調整するしかない。
つまり、リリース計画を立てて、複数のバージョンを随時リリースしながら機能拡張するという小規模リリースを自然に行っていた。

小規模リリースという繰り返し型開発に気付いた瞬間が、これがアジャイルだ！と思った2番目の瞬間。

このロードマップは、チケット駆動開発で最も重要な機能だと思う。
ロードマップは、平鍋さんが提唱するプロジェクトファシリテーションの「見える化」の例で出てくる野球のスコアボードと同じだ。
ロードマップには、「最新の正しい情報」がバージョンの進捗率とチケット一覧が表示されていいる。
Webなので、「メンバーも現場リーダーも(できれば顧客も)」ロードマップを見れる環境にある。
そして、ロードマップにあるバージョンの予定や進捗から、直近のゴールはこれだ、と「次の行動」が誘発される。

チケット駆動開発はプロジェクトファシリテーションともすごく相性がいいと思う。

【3】Redmineは1プロジェクト＝1リポジトリという設計思想で、Subversionと連携できる。
更に、Redmineには複数プロジェクト機能がある。
だから、ブランチを別プロジェクトで管理してみたら、自然に並行開発になっているのに気付いた瞬間が、これがアジャイルだ！と思った3番目の瞬間。

Subversionをまともに使いこなすまで、ずっとtrunk1本だけのコードラインだったから、並行開発を意識する事はなかった。
しかし、小規模リリースしていくと、本番環境のソースはブランチ、裏で機能拡張中のソースはtrunkというソース管理に自然になる。
すると、マージ作業という面倒な作業が発生するので、Redmine導入前はSVNのタグを乱発してコントロールしにくかった。

Redmineでは、本番運用と開発中のチケットは別々に作り、マージ作業のチケットは発生源の障害修正のチケットとリンクすることで、開発者はすごく作業しやすくなったみたい。
管理者としても、マージ作業のタイミングを忘れる事がなくなったので、ありがたい。

上記の経験を通じて、繰り返し開発が難しい理由は並行開発という開発プロセスが隠れているからだ、と思うようになった。
一度リリースしたソースはそれで終わりではなく、ブランチとして次のリリースまで生き続ける。
開発チームは、次の開発をやりながら、本番運用のソースも保守しなくてはならない。
そして、裏で開発中のソースをリリースしたら、本番運用のブランチを新たに作り、以前のブランチを廃止するという運用サイクルが生まれる。

つまり、小規模リリースというプラクティスは、単なる小刻みな機能拡張による繰り返し開発だけでなく、複数のコードラインを常時保守する並行開発という開発プロセスが本質なのだ。

アジャイル開発が難しい理由は、この並行開発を制御できない点にあると思う。
ウォーターフォール開発であろうとも、組込み製品やパッケージ製品の開発では、複数の製品ラインを保守しながら本番運用と開発中の2系統のソース管理をしているのだから、もっと大変なはずだ。

逆に言うと、並行開発を意識している開発プロセス、開発チームは、自然にアジャイルな開発を行っているだろうと推測している。