チケット駆動開発が進むべき道part6～ウォーターフォール型開発への適用の方向性

最近、Redmineの話を聞いてみると、チケット駆動開発を、アジャイル開発を導入する手段として使うのではなく、むしろ、従来のウォーターフォール型開発を補完するような形でチケット駆動開発を取り入れて機能強化しているように思える。
考えたことをラフなメモ書き。

【参考】
第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL

[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば

なぜ日本ではチケット駆動開発が注目されるのか？(ゲストブログ) | Atlassian Japan

チケット駆動開発を上手に運用するためのプラクティス（ゲストブログ） | Atlassian Japan

【1】日経SystemsではRedmineの記事が1年に1回は掲載されているが、その理由を聞くと、読者アンケートを取った結果では、Redmineの読者評価が高いらしい。
第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索に書いたけれども、SIerのマネージャ層がRedmineを導入して、プロジェクト管理を補完しようとしていると思われる。
もちろん、開発者が現場で使いやすいから、という理由もあるだろうが、上司の理解がなければ、そこまで興味を持たれて、実際に導入することもないだろう。

その方向性を考えると、日本のSIが従来から続けているウォーターフォール型開発に、チケット駆動開発を流用して、不足している部分を補完する動きのように思える。
つまり、チケット駆動開発をアジャイル開発の実装例として導入するのではなく、従来型のウォーターフォール型開発を機能強化する流れと言える。

【2】開発者の観点で見た場合、チケット駆動開発は、チケットとソースの相互リンクという機能が最も最優先だろう。
実際、ソースをコミットしながら、チケットを更新してCloseしていく時に、「No Ticket, No Commit」を運用して、チケットとソースをリンクさせる。
この運用ルールはトレーサビリティの強化につながるので、リリース後の保守で、リバースエンジニアリングしたり、仕様を理解するのに役立つ。

git-flowモデルと組み合わせて運用すれば、多数のブランチ管理もチケット管理と連動でき、ソースの変更理由を追跡しやすくなる。

TiDDとgit-flowを合わせた開発手法について | Technology-Gym

ゆえに、開発者としては、ソース管理が最初にありきで、チケット管理と連携させることで、タスク管理をより強化する方向にいく。
「ソース管理が最初にありき」という考え方は、出荷可能な製品を頻繁にリリースしながらアジャイルに開発していくスタイルと相性が良い。

【3】しかし、マネージャの観点の場合は、チケット駆動開発をメトリクス収集ツールとして扱い、進捗報告や品質管理、課題管理といった管理作業を楽にする機能を最優先するだろう。

彼らとしては、プロジェクトの進捗状況や品質をリアルタイムに見たい。
だから、チケット集計機能が最も重要になる。
タスクチケットをガントチャートで進捗管理したり、障害チケットからバグ収束曲線を出力してテストの終了条件を判定したりする。
また、チケットの予定工数と実績工数をwork_timeプラグインで入力してもらって、コスト管理に役立てることもできる。

チケットの集計条件を色々変えれば、いくらでも欲しいビューを出力することができる。
しかし、Redmineのチケット集計機能は、ロードマップ、ガントチャート、クエリぐらいしかなく、正直貧弱だ。
実際は、クエリでチケットをCSVで抽出し、Excelで整形するやり方が多いだろうと推測する。

【4】Redmineをベースにアジャイル開発として運用する場合と、ウォーターフォール型開発として運用する場合では、頻繁に見るビューが決定的に異なる。

アジャイル開発のように運用する場合は、Redmineのロードマップを基本にして、どのバージョンをいつリリースするのか、に力点をおいて進捗管理していく。
ロードマップ画面はリリース計画そのものであり、RedmineのバージョンはXPのイテレーション、Scrumのスプリントに相当する。
だから、ロードマップ画面による進捗管理を実践すると、自然にタイムボックス単位に開発する運用になる。

この運用の利点は、ロードマップを見れば、過去のリリース履歴から修正されたソースや仕様変更の経緯が書かれたチケットへ辿ることができる。
また、将来、どんな機能を優先してリリースするのか、も一目で分かる。

一方、ウォーターフォール型開発で運用する場合、Redmineのガントチャートを基本にして、当初の予定と実績にどれだけの差異が発生しているか、を中心に管理していく。
Redmineのチケットは、先行・後行関係を付けることもできるので、FS関係を実現できるから、ガントチャート上でクリティカルパスを見つけ出すことは実現可能だ。
ウォーターフォール型開発の進捗管理では、クリティカルパスを守るために有限な資源をリソースしていくやり方が多くなる。

RedmineのガントチャートはMS ProjectのWeb版になりうるか？: プログラマの思索

また、Redmineの最新版では、ガントチャート画面でイナズマ線が表示できるようになったので、どのタスクが遅れているのかが一目で分かるようになった。

Redmine 2.3の新機能: プログラマの思索

Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blog

【5】以上のように、Redmineの機能強化の方向性を追いかけてみると、ガントチャート画面を強化するなど、エンタープライズ向けを意識した観点が多く見られる。

実際、イナズマ線を実装したチケットのコメントを見ると、

Gantt progress line needs in Japanese enterprise.
Customer always requires it to developer.

と書かれている。

Feature #12122: Gantt progress lines (html only) - Redmine

Feature #3436: Show relations in Gantt diagram - Redmine

また、最近感じるのは、「Redmineによるタスクマネジメント実践技法」の第8章「チケット駆動開発を発展させるアイデア」の内容を実装した事例をちらほら見かけることだ。

例えば、EVMの実装の一部は、下記のEVMプラグインで既に実現されている。
EVMをRedmine上で実現できれば、コスト管理を予測しやすくなるだろう。

RedmineのEVMプラグイン: プログラマの思索

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

さらに、ITILの実装例としては、holonという会社が「Redmine for ITIL」というサービスで既に売り出している。
hinemosとも連携しているので、Redmine以外にも付加価値を高めている良い例だ。

Redmine for ITILが解決するもの: プログラマの思索

そんなことを考えると、EVMやITILのように既に理論はあるものの、従来のウォーターフォール型開発では運用しにくかった手法や実現しづらかった手法が、チケット駆動開発では簡単に実現できるため、その手法をRedmineの一機能として実現して適用しようとする方向性のように思える。

但し、その方向性は、アジャイル開発の利点を生かす流れではない。
あくまでも、従来のウォーターフォール型開発を変えることはなく、弱点を補完する機能だ。

この点は僕はあまり意識していなかったけれど、「アダプタブルウォーターフォール」とは違っており、ウォーターフォール型開発を改良する別の手法であるように思えるので、その根本原因や今後の動向を色々考えてみたい。