チケット駆動開発の原点の記事のリンク

チケット駆動開発の原点の記事をリンクしておく。
自分が参照したいために残す。
主張はなし。

【参考1】
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」: プログラマの思索

SQIP2009経験論文「チケット駆動開発～BTS で Extreme Programming を改善する(Ticket Driven Development - An Improvement Method for Extreme Programming using BTS - )」

【参考2】
チケット駆動開発の戦略: プログラマの思索

(引用開始)
Redmineによるチケット駆動開発の凄い所は、下記3点だと思っている。

2-1.SVNリポジトリとRedmineチケットが紐づくので、要件とソースコードのトレーサビリティのインフラが整う。つまり、BTSが構成管理ツールになる。
2-2.BTS(Bug Tracking System)のワークフローは、ITS(Issue Tracking System)のように、プロジェクト管理のフレームワークへ昇華・汎用化できる。
2-3.チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

今の僕の興味は、BTSを構成管理ツールにして、BTSの運用をプロジェクト管理の汎用化したプロセスにして、最後はソフトウェア工学の知識を流用して、プロジェクトを改善する材料にしたい。
(引用終了)

ITの地殻変動はどこで起きているのか？: プログラマの思索
(引用開始)
チケット駆動開発のルーツは、BTS(バグ管理システム)。
古くは、Bugzilla、Mantis。

BTSは本来、障害管理に昔から使われていたが、このワークフローがとてもスムーズな為、障害だけでなくSW開発の一般タスクへ汎用化しようという発想が生まれた。
TracやRedmineは、チケット管理をメインとして、ガントチャート生成やバージョン管理との連携機能によって、プロジェクト管理機能を持つBTSを課題管理システム(Issue Tracking System)へ昇華させた。

そして、まちゅさんは、Tracのチケット管理からチケット駆動開発(Ticket Driven Development：TiDD)を提唱された。
まちゅさんの本来の主張は「チケット無しのソースコミット不可」。
このチケット駆動開発のアイデアを突き進めると、イテレーティブな開発を補完するアジャイルな開発プロセスであることが分かる。

チケット駆動開発の基本アイデアは、さかばさんによると、「BTSのチケットはXPのタスクカードと同じ」。
XPでは、アナログのタスクカードでPostItなどで運用する。
チケット駆動開発では、チケットとしてタスクカードをデジタル化する。

チケットは作業指示書でもあるから、ステータスや進捗率を入力すれば、リアルタイムに作業状態を追跡できる。
更には、作業開始・終了日、予定・実績工数を入力すれば、ガントチャートを自動生成できるから、進捗管理に使える。
チケットは本来、バグ報告票でもあるから、バグ修正に関するチケットの集計結果から、信頼度成長曲線を作成して、品質管理に使うこともできる。

つまり、プロジェクト管理をチケット管理に置き換えることによって、プロジェクト内部の作業全てをリアルタイムにモニタリングできる。
チケット入力の運用さえきちんとできれば、イテレーション計画の頻繁な変更もコントロールできる。
更には、チケット集計結果やSVNリポジトリ統計のメトリクスを、プロジェクト運営の意思決定の材料として出力できる。
(引用終了)

【参考3】
必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-: ソフトウェアさかば

(引用開始)
これらの一連の自動化を見ていると、新しいことなのに当たり前のような、凄く良いアイデアのようなのに「そうしなければならない」という印象を受けました。

それは、あきぴーさんの発表で意味がわかったような気がします。あきぴーさんのサブタイトルは「チケットに分割して統治せよ」で、TiDDの歴史、背景と効果、経験を語られました。この中で、「TiDDはWeb2.0のようなもの」と言われました。古い技術を使って新しいことをするという意味で言われていたのですが、これが実はTiDDをよく表していると思います。

上に書いたように、TiDDはある意味「当たり前のことをしていったら、こうなった」という印象があります。でも、何か新しく、開発の苦しみを和らげてくれそうな魅力を感じます。

その意味を考えているうちに、かつて川端さんにお願いしたソフトウェアシンポジウムのチュートリアルを思い出しました。このセミナーはXP入門ということでお願いしたのですが、実際はEclipseの実習が中心でした。これは、少人数でソフトウェア開発に向き合うと、ツールを中心に効率化を図るしかないということを意味しているのだと思います。

TiDD(チケット駆動開発)は、その背景の思想から生まれたものではなく、ツールを用いながらプロセスを改善していったら、必然的にそうなったものだと思います。かつての方法論が、背景の思想を元にツールを開発したために実践する際にやりにくい点が生じたのに対し、実践している中で生まれた方法論は、その体系をきれいにまとめられれば従来にない力を発揮できると思います。

今後、そのあたりをまとめたいと思いました。
(引用終了)

TiDD：チケット駆動開発: ソフトウェアさかば

(引用開始)
「チケット駆動開発」は、アジャイル開発(を中心とした)プロセス改善手法です。もちろんBTSがあれば便利に使えますが、ツールが無くてもプロセスを改善することができるはずです。
(中略)

チケット駆動開発もたぶんそうです。便利なタスクカードや「チケット駆動開発環境」というものがあれば、それがブームになるかもしれません。でも、それ以前に良くできたBTSがあったのです。最近のBTSは高機能化が進んでいて、チケットの状態管理、検索、グラフ化、ワークフロー管理、などなど、様々なことができます。その機能はチケット駆動開発に十分なものでした。

そんなチケット駆動開発は現場で生まれました。研究所で生まれたなら、たいそうな概念があって、見た目重視の専用ツールがあったでしょう。でもチケット駆動開発は違います。解決したい問題が先にあり、目の前にあったBTSを使ってやってみたらうまくいった。

その概念もあまり固まっていませんでした。私がここに書いていることも人によっては「ちがう！」と言われるかもしれません。でも、実践したらうまくいった。それが「チケット駆動開発」なのです。

「チケット駆動開発」を育てたのは、技術に対して貪欲で、意欲的な人たちです。いまやアジャイル開発も普通のことになりましたが、数年前までは目新しい概念でした。どの程度役に立つのか、あまりわからない状態でしたが、現場に問題を抱えていた技術者たちはアジャイラーになりました。そして進んで実践し、問題にぶつかり、チケット駆動開発を見出したのです。

私が「チケット駆動開発」に魅力を感じるのは、そんな技術を実践する人たちが育てているからかも知れません。オブジェクト指向も、アジャイル開発も、そんな人たちが育てたから、良いものになりました。きっと「チケット駆動開発」も良いものに育っていくだろうと思っています。
(引用終了)

【参考4】
「チケット駆動開発」について分かったことと、日本の開発現場での課題 - I18n and L10n in My Life

(引用開始)
チケット駆動開発って言葉は日本だけで使われている？

チケット駆動開発に対して、海外ではどのように考えられているのか興味をもったので、先ほど社内ウィキで聞いてみた。時差の関係で、ヨーロッパのエンジニア二人から回答があったが、そもそもチケット駆動開発 = ticket driven development という言葉を、アジャイルやXPというコンテキストで、聞いたことがない、と。

最初は、欧米ではチケット駆動開発が当たり前（当たり前かどうかは未確認）すぎて、そういった言葉をあえて使う必要がないのかと思った。だけど念のため、英語でググッてみた。すると、ヒットするページは日本人の作成したページばかり。どうやら和製英語である可能性が高そうだ。
さらに調査をすすめてみると一つの文献にぶちあたった。第28回 ソフトウェア品質シンポジウム2009の資料です。
「チケット駆動開発」-BTSでExtreme Programmingを改善する- (PDFファイル)
その文献の最後の方に「TiDD の名付け親のえと～さん」とあるではないですか！「えと～さん」がどなただか分かりませんが、これが本当だとしたら、やはり日本でできた言葉のようですね。
すいません、デベロッパーとしての現場経験のない中で、いろいろと考えて書いています。間違っているところ、トンチンカンなところがあったら遠慮無くご指摘ください。教えてください。特に上のパラグラフの方。
(引用終了)