チケット駆動開発
本の感想を読んで、チケット駆動開発が進むべき道について考えたことをメモ。
【1】Twitter / SugiTK: Redmineの使い方なのかチケットの運用の仕方なのかというのも微妙な立ち位置になってしまってるかなと。例に挙げられていたERPの話と同様に、ツールをRedmineにすると決めたならそれに合わせて業務も変わるわけで、Redmineならこうしますというほうが。それは前著ですか…
Twitter / SugiTK: アンチパターン集は読みやすかったです。パターンテンプレートに沿っていたからでしょうか。既存のいい見本があると見やすくなるということはあるのかもしれませんね。
Twitter / SugiTK: 12章。「テーラリング」という単語はあまり一般的ではないのではなかろうかと。新卒のときの研修でPMBOKやQCのプロセスについてテーラリングするというのを部長から教わったのをなぜかよく覚えていますが、その後10年以上聞いたことがありません。
Twitter / SugiTK: 読後感としては「う?ん」と悩んでしまいました。本を書くのはやはり難しいんだなぁと。わたしは雑誌記事を10回程度しか経験がないですが、相当に大変でした。知っていることを全て表現できるわけでもなく、書いたことが全部伝わるわけでもない。難しいです。
【2】チケット駆動開発の感想 - ブクログ
宝探しが必要な本です。自分が深く関わったことがある部分に対しては、この本に書かれているノウハウがとスッっと入ってきてとても参考になったのですが、経験が浅い部分については何がポイントなのか、、、話が散逸していてよく分かりませんでした。
「プロジェクト管理の原理原則」、「チケット駆動開発により改善が進むポイント」、「実践のノウハウと実例（ツール）」と大きく3部に分けて整理し直すだけでものすごく良い本になるのではと思います。
手元に置いておいて、プロジェクトマネジメントで悩んだ時に、部分的に読み返すという使い方が良いかもしれません。
【3】Amazon.co.jp： チケット駆動開発
(引用開始)
導入部はよく書けていて期待が膨らんだが、完全に裏切られた。厳しいレビューとなりますがご容赦。
まるで思いつきを思いついた順に並べたような本だ。これではひとつの開発方法論という以前に、一冊の技術書として成立していないと思う。
全体がうまく構成されていないし、各論も要点が全く整理されておらず、何が言いたいのか不明な部分が多い。
技術的な誤りも多い。著者らの前著も突っ込み所満載といった印象だったが、この本はそれ以上にひどい。
同じことを何度も繰り返しつつ、ほかの文章を適当に引用してはいい加減な論評を繰り返し、脈絡なく「チケット駆動はこれを改善するでしょう」などと結ぶばかり。
自分が開発するシステムの仕様書がこんなふうに書かれていたら、私は激怒すると思う。
第一、BTSとSCMが連携する開発支援ツールはMicrosoftやPerforce、Rationalなどがずっと以前からリリースしているしこの本を読む限り、「チケット駆動」というのがBTS/ITSの新しい活用法を編み出したとは見えない。
これだけ厚い本なのに、「BTS/ITSを活用しましょう」という以上のメッセージは読み取れなかった。
著者らは、「チケット駆動」というわかりやすい言葉で、日本のソフトウェア業界にBTS/ITSの導入を啓蒙した。その大きな貢献は否定しない。
(そんなところから啓蒙しなくちゃいけない日本の業界もどうかとは思うが)
しかし、この本はあまりに技術書としての体裁を欠いている。ブログじゃないんだから。もう少し、まともな本に仕上げてほしかった。
これでは「チケット駆動」とは名前負けの看板倒れ、中身は何もないと言われても仕方がないだろう。
チケット駆動とは何か、何を価値とするのか、単純な原則を抽出して改めて体系づけ直すべきではないか。
次回は、要点だけをコンパクトにまとめた、現場でリファレンスとして使える本を期待したい。(日本発の開発方法論として、まだ期待してるんですよ。)
せめて、目次を見たらどこに何が書いてあるのかわかる程度には、内容を整理すべきだろう。
業界からの「チケット駆動」に対する期待と、著者らの業界に対する影響力の大きさを考慮して-1点。
(引用終了)
(引用開始)
障害管理、構成管理、アジャイル、SCMなどなど、幅広い内容が分散して書かれているため、チケット駆動開発の本質的なところ（この本が伝えたいこと）がよくわからない。
チケット駆動開発の基本のところで説明している内容を、ブレークダウンしていくつかのパターンに分類していってくれたら良かったのにと思います。
チケット駆動開発によってアジャイルが分かったとあったので、書籍もアジャイルにリファクタリングしながらつくられたのかと思ったのですが、現状だと寄せ集め感がすごくあるので、個々ではよいことが書いてある箇所はあっても、全体の読後感として、自分の現場でのアプローチに直結しない感じがしちゃう。勿体無い。
(引用終了)
【3】「チケット駆動とは何か、何を価値とするのか、単純な原則を抽出して改めて体系づけ直すべきではないか」という指摘に対しては、「チケット駆動開発」では、6.2節「チケット駆動開発はプラクティス？」の所で既に回答されています。
(引用開始)
チケット駆動開発をどう定義するか、それは難しい問題ですが、必ずしも解決しなくても構わない問題だと思います。できればそのままに広く情報交換して、それぞれのプロジェクトにふさわしい形でチケット駆動開発が実践できるようになればと思っています。
(引用終了)
でも、上記の回答では満足できず、チケット駆動開発の価値・原則・プラクティスを体系化して欲しいという要望に賛同する読者が多いという感想を持ちました。
また、「チケット駆動開発でアジャイルが分かった」と「Redmineによるタスクマネジメント実践技法
」「チケット駆動開発」の導入部で著者が書いたにもかかわらず、「現状だと寄せ集め感がすごくある」という指摘がありました。
自分としては、前作でチケット駆動によるアジャイル開発技法はほとんど書いたと思っていて、今作では、チケット駆動が障害管理から生まれたが故にその性質が本来のTiDDであることを説明しました。
そして、アジャイル開発に限らず、色んな可能性があることを言いたくて、チケット駆動開発のバリエーションとテーラリングガイドについて色々書きました。
しかしながら、逆に「チケット駆動開発の本質的なところ」が読み取りにくくなったようです。
上記の感想を読んで、「チケット駆動開発でアジャイルが分かった」という著者の体験が体系化されてないために読みにくく、テーラリングガイドよりもチケット駆動開発をアジャイル開発の文脈で体系化して欲しいという要望があるように受け取りました。
確かにその部分はきちんと書けていない部分だと思っています。
また、「Redmineによるタスクマネジメント実践技法」を第5刷まで更新しながら思ったことは、かなり細かな部分まで著者の意図を読み取ろうとしている人が多いことです。
誤字脱字だけでなく、流れからしてこの用語やアクティビティ図は使い方がおかしい、という指摘を台湾の読者から受け取った時もありました。
上記のAmazon感想の仙川さんも、2冊共にすぐに購読して感想をアップしてくれています。
感想の評価は厳しいけれども、きちんと読んでみると、本の内容をかなり詳細な部分まで読んで理解して指摘しているのが分かりました。
(チケット駆動開発に期待して、本の評価を落とすのは変ですが(笑))
【4】「チケット駆動開発をアジャイル開発の文脈で体系化した」場合、どんな方針で考えるべきか？
今は以下の方針を考えている。
一つ目は、チケット駆動開発からツールの説明をなくすこと。
チケット駆動開発を開発プロセスとして体系化する場合、ツールは不要だし、逆に邪魔になる。
運用フローを抽象的に取り出して、フレームワークとして明確に定義してみること。
2つ目は、チケット駆動開発をアジャイル開発の文脈で、価値・原則・プラクティスでフレームワーク化できるか試みること。
価値とは「何が望ましく何がふさわしくないのかという根拠や基準」。つまり価値観。
チケット駆動開発の文脈では、チケット管理の判断基準に相当する。
チケットの取捨選択で、何を基準にして、チケットを登録し、完了しているのか？
原則とは、ドメイン固有の不変な指針。価値とプラクティスをつなぐもの。
プラクティスは、経験に基づいて定義された実践方針。パターン言語を参考にして、プラクティスを「どんな状況(Context)でどんな問題(Problem)に対してどんな解決策(Solution)が有効なのか」を明確にする。
フレームワークは、道具・役割・プロセスの3つの観点。チケット駆動開発を実行するための体制や手続きに相当する。
これらの観点でチケット駆動開発を体系化し、明確にする。
3つ目は、チケット駆動からどんなアジャイルな効果が出てくるのか、そしてアジャイルになる原因をフレームワークから導き出せるかを試みること。
今考えている方針の前提条件は、基本的には、WF型開発などアジャイル開発でない開発プロセスは対象外であり、ソフトウェア開発以外のタスク管理は除く。
つまり、アジャイル開発へ適用したチケット駆動開発について考える。
しかし、これだけ「チケット駆動開発」という概念が広く普及した周囲を見ると、チケット駆動開発の導入によってアジャイルな要素を取り入れたいという動機が多い。
だからこそ、従来型のWF型開発にチケット駆動を導入して、アジャイルな特徴という利点を部分適用したいという考え方を持つ人が多く、注目されているのだろう。
チケット駆動開発の適用範囲: プログラマの思索
チケット駆動開発を開発プロセスとして体系化した場合、何故アジャイルな効果が出てくるのか、その原因を探ってみたい。
4つ目は、XPやScrumなどの他のアジャイル開発と似ている部分と異なる部分を明確に切り分けて、チケット駆動開発を特徴づけること。
そもそも、XPもScrumもFDDも、チケット駆動ではない。
チケットという概念すらない。
あくまでも、チケットをタスクカードのように扱うことで、アジャイルな要素が出てくる特徴はあるが、アジャイルな要素はそれだけではない。
逆に、他のアジャイル開発プロセスにはなく、チケット駆動だけに特有の特徴もあるはず。
その部分を明確に切り分けてみたい。
これらの方針で、チケット駆動開発をアジャイル開発プロセスとして体系化した場合、どんな特徴が出てくるのか見てみたい。
【5】2008年にチケット駆動開発をアジャイル開発へ適用した事例を発表してずっと経つけれど、著者が想像するよりも速いペースで、世間ではチケット駆動開発の概念が進化しているように思う。
例えば、PivotalTrackerならば、よりアジャイルなチケット管理がやりやすい。
僕も実際に使ってみて、その良さは何となく分かった。
「No Tikcet, No Commit」がなくても、十分にアジャイルな特徴がある。
例えば、GitやMercurialとRedmineを連携した使い方は、著者の想像以上に発展している。
そもそも「No Tikcet, No Commit」の運用ルールは、Trac＋Subversionの環境で生まれたからこそ、逆に、GitやMercurialでは、その運用ルールが古くなっている部分がある。
プライベートブランチまで「No Tikcet, No Commit」を適用するのは、開発速度を逆に落とす。
本当は、分散バージョン管理に関する使い方、考え方も「チケット駆動開発」本に書きたかったが、まだ他人に説明できるほど自分は理解できていないのであきらめた。
特に、分散バージョン管理とチケット管理の連携方法は、今後一番可能性がある分野だ。
そして、たくさんの人達が試行錯誤しながら、よりよい使い方を探している。
その使い方、考え方も綺麗に体系化してみたい。
色々考えてみる。
」を読んでみたら、構成管理・ビルド管理・障害管理の方法や概念、用語がうまく整理されて説明されていて、とても分かりやすかった。
」の著者の藤原さんが、Mercurialに取り込まれたコミュニティ由来の機能一覧を公開されていたので、リンクをメモ。
」の一節に、ソフトウェア構成管理の基本成分が書かれていたのでメモ。
最近のコメント