[TiDD] プラクティスから方法論へ

「チケット駆動開発」というキーワードで検索すると、名古屋で勉強会が開かれていたり、実際の仕事で試されている方がおられたり、色々なところで注目されていることがわかります。

そんな中で気になったのが、「チケット駆動開発の研究と実践」(livedoor 開発Blog)です。ここでは、チケットによる見える化や達成感というメリットのほか、こんなデメリットも書かれています。

「チケットを発行するときは楽しいのですが、クローズしたりステータスを変更するときはチケットが多いほど手間がかかります。」

そして、管理者をつけたほうが良いとのこと。確かに、たくさんの作業を見える化できることがTiDDの特長ですが、管理作業そのものは従来と同じですし、全体の状況となるとチケットを容易に増やせる分だけわかりにくくなるかもしれません。

実は関連する議論をしたことがあります。題して「TiDDは方法論か、プラクティスか」。アジャイル開発やテスト工程などでTiDDをプラクティスの一つとして用いるならば、大きな効果を挙げると思います。しかし、方法論として考えると、チケット駆動開発の基本である「チケットなしではコミットを許さない」というルールだけでは規模が大きくなると開発できません。

そのような現実から考えると、厳密にはTiDDはプラクティスと言えると思います。では、みなさんはどうされているかというと、あきぴーさんなどは上流はウォータフォール、製造はアジャイルをベースにTiDDを用いられているようです。

では、あきぴーさんの開発方法はTiDD開発方法論であるかというと、そうでもあるし、そうでもない。本人がそうだといえばそうなるのかもしれません。しかし、詳細が定まっていないものを方法論というのもおこがましいので、私とあきぴーさんで外部発表した際には「TiDDをアジャイル(あるいはXP)に適用した」という表現を使っています。

方法論とするには、いくつかの定義が必要だからです。具体的には

チケットの管理の方法：ワークフローの一般化。役割と作業の詳細な定義が必要です。また、チケットの統合や分割の定義も必要です。

作業の管理：チケットと紐づいた作業を日々どのように管理するか。作業が増えた際にどう管理するか。

要件あるいはストーリカードとチケットの関係：チケットをXPのタスクカードとするならば、ストーリーカードはどうなるのか。何らかの参照が必要なことはわかりますが、具体的な方法を示さなければなりません。

ほかにも色々あると思います。実際には、現実のプロジェクトが目の前にあるのですから、色々工夫をしながら具体的な事例積み重ねることだと思います。そしてそれらを元に、まとめていければと思っています。

(事例の提供者おられませんか？もし、論文を書きたいのなら、お手伝いならしますよ～)