Redmineを使って気付いたことpart7～イテレーションで追跡する

チケット駆動開発でアジャイルに開発しながら、「チケットではなくイテレーションで進捗やリスクを追跡する」意味が何となく分かってきた。
それについてメモ。

【1】チケット駆動開発の基本は、チケットファースト。
チケットがXPのタスクカードに相当する。

担当者は、チケットへ作業内容を記入してから、作業を開始する。
開発者は実際、チケットをToDoカードのように用いている。

SW開発のタスクは単にプログラミングだけではない。
お客様へ納品する設計書を作ることも必要だし、テスト仕様書を作ることも必要。
更には、ビルド環境を作ることも必要だし、テストデータを準備することも必要。

すると、チケットは終了するペースよりも登録する方がどんどん増える。
何もしなければ、チケットは乱発されて、放置状態になり、収拾が付かなくなる。

僕が初めてTracを運用した時、マイルストーンやバージョンが曖昧なままチケットを登録していたから、チケットが膨大に登録されて放置されてしまって、コントロールできなくなった苦い思い出がある。
Tracでは、マイルストーンやバージョンの本質が分かっていなかった。

Redmineを使い始めて、バージョンとマイルストーンを一致させるRedmineの思想に触れた。
Redmineでは、チケットをバージョン単位でグループ化して、小刻みにバージョンアップしていく。
つまり、Redmineのバージョンは、システムのバージョンであり、開発チームにとってリリースのマイルストーンでもある。
この運用で、初めてアジャイル開発の肝が分かった気がした。

【2】チケットをイテレーション単位でグループ化するのがチケット駆動開発の最大の肝なのだが、僕はこの運用に更に手を加えている。

普通、新規開発時は、管理者がWBSから洗い出したタスクをチケットとして一括登録していく。
この時のチケットは、一つの成果物を作る作業になる。
例えば、機能実装、設計書作成など。
そして、これらチケットを閉じた大きな機能単位として、イテレーション単位でグループ化して、小刻みにリリースしていく。

しかし、実際のSW開発では、上記以外のチケットが発生する。
開発者は、この機能はバグがあるかも、とか、ロジックが共通化されていないからリファクタリングしたい、などの不安をいつも抱えている。
僕は、それら開発者の意見も全てチケットへ登録し、内部課題と言う特別なイテレーションで管理している。

理由は、リスク管理の一環として。
実際のシステムは、開発者しか知らない仕様やバグは結構存在する。
それらは、情報共有されなければ、必ず問題として現れて、迅速に対応できる準備が無ければ、必ず火を噴く。
だから、管理者は、開発者が気付いた課題(まだ問題として顕現されていないもの)をチケットへ仮登録して、課題を見える化しておく。

システムはハードウェアの製品よりも非常に繊細。
特にリファクタリングが必要なロジックは、ファウラーが言う技術的負債に当たる。
技術的負債の工数を把握しておかないと、機能追加の工数見積で大きく狂う危険が高まるから。

但し、それらのチケットは、内部課題という特別なイテレーションへ入れて、終了期限を無しにしている。
理由は、将来問題として現れる可能性はあるが、今最優先で対処する課題ではないから。

この運用をし始めて、開発者は気付いた課題や不安を積極的にチケット登録するようになった。
管理者である僕は、それらチケットをいつも精査して、どのイテレーションで混ぜるべきか、どのチケットと関連しているか、見極めるようにしている。

そして、内部課題に挙がったチケットに手を付ける時、進行中のイテレーションに混ぜ込んで、終了したらそのイテレーションでリリースする。
理由は、そのリリースモジュールに、内部課題のチケットが反映されているから。
実際、Redmineでは「変更記録」というリリース結果のChangeLogに、内部課題のチケットも終了チケットとして表示される。

しかし、内部課題のままチケットを却下にする場合もある。
定期的に内部課題のチケットは棚卸しして、対処する必要が無くなれば、却下にしてCloseしていく。

これが「チケットではなくイテレーションで進捗やリスクを追跡する」意味。
この運用を始めて、チケットの取捨選択がアジャイル開発の肝なのだ、と強く痛感した。

チケットは単なるタスク管理ではない。
チケットへ将来発生するかもしれない課題も登録して、リスク管理として使う。
Redmineロードマップに現れたチケットは、単なるタスクだけでなく、プロジェクト内部で気付いたリスク全ても含む。

リスクの見える化は、管理者だけでなく開発者にも良い影響を与える。
一人の開発者の不安は、実は他の開発者が既に解決した内容の場合もあるから、お互いに情報共有し合う糸口にもなる。
特に新しいフレームワークを使った開発の場合、最初に誰かが人柱になってノウハウをためる。
そのノウハウを共有化するインフラもチケット駆動開発は与えてくれる。

【3】だが内部課題というイテレーションで解決できない問題も実際ある。

例えば、重大なセキュリティホールが判明して、フレームワークやハードウェアをVerUpしなければならないとしたとしよう。
あるいは、SQLインジェクション対応のために、システム全体をリファクタリングしなければならないとしたとしよう。

この場合、もはやイテレーションと言う短いサイクルでは開発を制御することは難しい。
そこで、Redmineの場合、子プロジェクトを新規に作り、セキュリティ対策用のプロジェクトにする。
そして、このRedmineプロジェクトへ、trunkから分岐させたbranchと紐付け、ソース修正用のチケットをどんどん追加していく。

これはいわゆるタスクブランチの発想。

理由は、このプロジェクトは、現行のtrunkのプロジェクトのライフサイクルと異なるから。
trunkへセキュリティ対策用の修正ソースや設定ファイル修正を混ぜたら、システムが不安定になる。
だから、別ブランチ上で、パッチが有効か試したり、フレームワークやハードのVerUpで解決できるか検証していく。

実際のシステムは、ミドルウェアやハードのVerUpが意外に多い。
VerUpしなければ、長く運用できないのがITの宿命。
しかし、VerUpは、システムが不安定になるリスクをいつも抱えている。
そのリスク検証のために、別プロジェクトで管理する。

他の場合では、インシデント管理もtrunkの開発とは異なる別プロジェクトで管理する。
顧客からの問合せやFAQ、ベンダーへの問合せなどは、SW開発とは異なるライフサイクル。
同じRedmineプロジェクトで運用すると混乱する。

初めてTracを使った時、Tracでは複数プロジェクトで管理ができないから、運用が異なるチケットを全て一つのプロジェクトに入れてしまい、混乱してしまったのだと思う。

【4】TracとRedmineではイテレーションの概念が大きく異なるように思う。

その違いは、イテレーションを管理者の立場で見るか、それとも、開発者の立場なのか、にあると思う。
管理者は、毎週の進捗報告のためにイテレーションを使いたい。
開発者は、リリースするまでのタスク管理のためにイテレーションを使いたい。

Tracのマイルストーンは、管理者が進捗報告のために区切った観点。
Tracのバージョンは、リリースモジュールのタグなので、開発者の観点のマイルストーン。

Tracに対してRedmineのバージョンは、リリースするシステムのバージョンなので、開発者の観点。
更に、バージョンの期限はマイルストーンでもあるから、管理者の観点でもある。

Redmineロードマップは、バージョン単位に終了と作業中の2種類の進捗率を表示するため、管理者の観点では、実質と見かけの2種類の進捗管理に使える。
Tracのロードマップは、終了チケットの進捗しか表示しないため、実質の進捗しか見れない。

Tracは、管理者と開発者の観点が同等。
TracよりもRedmineの方が開発者の観点が強い。

管理者の観点のマイルストーンは、開発中で完了していないイテレーションのスナップショットにすぎず、プロジェクトで最も大切なリリースの観念が弱い気がする。
そもそも、チケット駆動開発では進捗をリアルタイムに見れるため、毎週の進捗報告用のマイルストーンは不要だ。

イテレーションは単なるタイムボックスだけではない。
イテレーションはリリースする機能が入ったタイムボックスなのだ。
Tracは、イテレーションはリリースする単位であるという思想がRedmineほど徹底されていない気がする。
とはいえ、Tracでも同様に運用できる。

チケット駆動開発は、チケットへ登録してから全てが始まる。
しかし、進捗やリスクはイテレーションやプロジェクトと言う一つ上のレベルで追跡するのが肝なのだと思う。