「チケット駆動開発」の感想を集めてみたpart1

平鍋さん、前田剛さん、藤原さんが「チケット駆動開発」の感想をBlogで公開してくれています。
ありがとうございます。

書籍「チケット駆動開発」8月23日発売 | Redmine.JP Blog

(引用開始)
チケット駆動開発の考え方、チケット駆動開発を行うためのRedmineなどの課題管理システムの使いこなしなどが詳説されています。ツールの使い方ではなく運用を解説した資料は少ないので、著者のお二人の経験をもとにチケット駆動開発を論じた本書は大変貴重だと思います。
以下、発売元である翔泳社のwebサイトの紹介文です。

TiDDと呼ばれるチケット駆動開発手法は、「国内の」「現場で」編み出され、実践のなかで確立されてきた大きな特徴をもっています。本書ではその経緯に深く関わりながら、多くの実践例や勉強会、講演などを経てチケット駆動開発の開拓をリードしてきた二人による、まさに定番、原典ともいえる一冊です。チケット駆動開発の基本や考え方から、Mantis、Trac、Redmineなど代表的なツールによる導入事例、高度な運用方法、FAQ/アンチパターン集、用語集まで、チケット駆動開発を知り尽くし実践するための全てが収まっています。
(引用終了)

チケット駆動開発でツールを『使う』から『使いこなす』へ | 世界 - daipresents!!

(引用開始)
『チケット駆動開発』を献本いただきました。小川さん、阪井さんありがとうございます。
本のレビューにも参加させていただくことができましたが、実際に本になると感慨深いですね。初めてこの本を読んだ時に、ツールを活用したタスク管理の考え方がまとまった良書だなぁと思いました。
タスク管理に迷える子羊をみかけたら「ツール使っただけで『アジャイルだ』とか言う前に『チケット駆動開発』を読め」って言ってみようと思います。
(引用終了)

書籍『チケット駆動開発』が出版されました。：An Agile Way：ITmedia オルタナティブ・ブログ

(引用開始)
この本は、チケット駆動開発(TiDD)について書かれた本の、待ちに待った二冊目です。小川さん、阪井さん、おめでとうございます。

本の出版にあたって、まえがき、を書かせてもらいました。ここに、紹介文として掲載します。ぜひ、本を手にとって見てください。

日本でも「アジャイル」という言葉がよく聞かれるようになりました。その中の１つの手法である「スクラム」という言葉を先に知ったという方も少なくないでしょう。アジャイル開発では、チームが協調して動くソフトウェアを育てます。チームは現在の状況を透明化して共有し、顧客にも伝えます。状況共有の手法に「ストーリ」、「かんばん」、「バックログ」、「バーンダウン」等がありますが、これらを積極的なツール支援によってより分かりやすく、チームが使いやすい仕組みにしよう、というのがチケット駆動開発です。

逆に言えば、チケット駆動開発では、「チケット」という概念を一番先頭にもってくることによって、アジャイルに必要なルール（規律）を現場中心に作り出し、開発全体を進める（駆動する）手法だということができるでしょう。

具体的な行為と結びついたチケットは分かりやすく、「アジャイル」という言葉のように時に漠然とした議論に陥ることがありません。アジャイル開発をしているかどうかは判断が難しい場合が多いですが、チケット駆動開発をしているかどうかは、はっきりと分かるでしょう。ですから、アジャイル開発を始めるのに、チケットをまず使ってみる、という使い方も、よい出発点だと思います。

さらに、チケット駆動開発はアジャイルだけに特化した手法ではありません。ウォーターフォールのように行程を区切った開発を支援する手法としても十分使えるのです（本書の中ではAdaptable Waterfallという呼び名で呼ばれています）。このことも、日本での利用シーンの想定を広くしています。

私自身も、アジャイルの中のチームビルディング、コラボレーション、ファシリテーションのエッセンスを抜き出して、それをウォーターフォール開発でも実践できるようにと「プロジェクトファシリテーション」（本書の中にも何度か登場します）という手法を作って日本で多くの人たちに伝えてきました。チケット駆動開発もまた、急激にアジャイル開発を実践できない現場でも、取り入れることが可能で、かつ、メリットをすぐに享受できる手法なのです。

ちなみに、私はすべての開発がアジャイルであるべきだ、とか、アジャイルがどんな場面でも最も優れた開発手法だ、という風には思っていません。開発現場がそれぞれ違うのですから、それぞれが自分たちで手法を選択し、さらに適用を考えるべきです。その意味で、チケット駆動開発は分かりやすく、自分たちのやり方を考えるよい出発点になるでしょう。
(引用終了)

平鍋さんの記事にはいつも色々考えさせられます。
チケット駆動開発とは「「チケット」という概念を一番先頭にもってくることによって、アジャイルに必要なルール（規律）を現場中心に作り出し、開発全体を進める（駆動する）手法」とも言えるわけですね。

僕の考えでは、「アジャイルに必要なルール（規律）」が「No Ticket, No Commit」「Ticket First」に代表されるプラクティスないし運用ルールだと思っていて、その運用ルールを徹底すると「自然に」アジャイルの効果が湧き出てくるのだと思っています。
それは、XPのプラクティスを組み合わせて実践することで、XPのプラクティスでは語られていないソフトウェアの信頼性などの品質や開発の効率性が「自然に」出現してくる現象と同じだと直感しています。

Twitter / akipii: @sakaba37 テーラリングという場合、標準プロセスが既に定義されていて、標準プロセスを加工修正するというトップダウンの意味合いで捉えてます。チケット駆動開発はツールを使っていたら自然にプラクティスが現れてそれが運用ルールになったというボトムアップの感覚です。

Twitter / akipii:@sugimoto_kei アジャイル開発の個別のプラクティスは品質や効率、進捗管理について何一つ説明していないにも関わらず、複数のプラクティスを組み合わせて初めて高品質で高速な開発が実現されます。アジャイル開発のテーラリングは多分ありえないと思うのです。

Twitter / akipii:@sugimoto_kei はいアジャイル開発は標準プロセスのテーラリングでは断じてなく、プラクティスというパターンの組み合わせから発生すると思うのです。チケット駆動開発も同じ文脈で説明するようにしたいです。

Twitter / akipii: そうなんです。リーダーシップさえもプラクティスを実践すれば「自然に」身につくのです。RT @sugimoto_kei 特にXPでは、チームやメンバの主体性さえ、最初に与件として前提されているのではなく、プラクティスの中から「立ち上がってくる 」という面があるんですよね。

最初はスキルがなくても、知識がなくても、プラクティスを実践していれば、「自然に」アジャイルに慣れて、スキルが「自然に」身につくはず。
なぜなら、プラクティスとは、過去の開発者が苦労して編み出した経験知が含まれているから。
プラクティスは、アレキザンダーの言うパターン・ランゲージであり、人の心の中に生まれながらに持っている暗黙知だから、という気がしている。

平鍋さんがプロジェクトファシリテーションをアジャイルなプラクティスの集合知として提唱され、実際の現場で役立つ実践ノウハウとして紹介されているように、チケット駆動開発もアジャイル開発をサポートするプラクティス集として説明できるようにしたいと思ってます。