チケット駆動開発の理想と現実

知人と話しながら、チケット駆動開発の理想と現実について気づいたことをメモ。
あくまでもメモであり、主張はない。

【1】Redmineを導入したならば、チケット駆動開発で運用するのが普通だと僕は思っていた。
しかし、実際の数多くの現場はそうではないですよ、と。
丁度、日本のソフトウェア開発の現場では、アジャイル開発ではなくWF型開発が主流であるのと同じように、と。

【1-1】チケット駆動開発はXPに影響を受けすぎているのでは？、と。
世間のアジャイル開発のイメージは、XPよりもScrumの方が有名だ。
Scrumのプロセスフレームワークの中で、タスクカードがチケットとして使われる場合が多いでしょう。

全ての作業をチケットにして作業をはじめる「チケット駆動」は特殊でしょう。
WF型開発の現場では、そうではない。
チケットの入力結果は、ガントチャートで確認する方が普通ですよ、と。

【1-2】チケット駆動開発のプラクティスは実際の現場では使いづらい時がある、と。

たとえば、No Ticket, No Workは確かに理想だけれども、実際は、チケット管理の対象は進捗管理だけでない。
また、Redmineというツールに頼りすぎるのも問題だ、という認識が現場にはある。

たとえば、No Ticket, No Commitもプログラマにとって評判は良くない時がある。
コミットログに逐一チケットNoを書くのが億劫だ。
また、ちょっとしたリファクタリングのコミットにもチケットNoを紐付けるべきなのか。
頻繁にコミットする場合、チケット一覧のコミット履歴が多すぎて、結局あまり使えない、と。

特に、GitHubのようなプルリクが使えないのもいまいちだね、と。

【2】僕が思っているチケット駆動開発は、理想にすぎないのかな。
「ソフトウェア開発の基本原理は、XPの小規模リリースと同じ」「頻繁にバージョンアップしながら、品質も機能も向上させていくのがソフトウェア開発の王道」と僕は思っているけど、違うのかな。

日本のソフトウェア開発は、製造業の成功体験を引きずりすぎていて、一度決めたら進路変更できない計画主導の開発プロセスにこだわり過ぎている、と思っているのは違うのかな。

僕の考えでは、チケット駆動開発は、アジャイル開発を実装する一プロセスであり、最も自然にアジャイル開発を実践できるプロセスの一つと思っているけど、そうではないのかな。

【3】チケット駆動開発は、フロー型プロセスでもあり、ストック型プロセスでもある二面性が利点を増幅させていると思っている。
チケットはカンバンでもあり、作業指示書や障害管理票のような記録できる帳票の二面性を持つ。
その部分の相互作用がすごく面白い。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

【3-1】「Issue」を「チケット」と訳したRedmineは偉いと思う。
チケットはメタな概念。
「Issue」を「問題」「課題」に訳してしまったら、タスク管理に使う発想は無かっただろう。
Redmineを障害管理やタスク管理だけでなく、ヘルプデスク管理、インシデント管理、台帳管理、議事録の管理、農作業の予実管理などに使おうという発想すら出現しなかっただろう。

akipiiさんはTwitterを使っています: "問題以外のスコープも含まれるからね。チケットはメタな概念かな。RT @g_maeda: @cyber_yoshida 当初は「問題」と訳されていましたがよい訳語がみつからず「チケット」になりました。先行して普及していたTracやMantisなどのBTSを参考にしたと思われます。"

akipiiさんはTwitterを使っています: "課題以外の用途があるからね?。台帳管理や農作業、議事録、などなど。チケットはメタな概念かな。RT @nmrmsys: @g_maeda @kawanishi_ameya issueって、やっぱ課題ではダメなんですか？"

【3-2】ソースそのものに修正履歴を残すのではなく、コミットログやチケットに記録することで、ソースは常に最新で綺麗な形に残せる。
そして、コミットログやチケットというメタな概念に修正履歴や変更理由が残るので、メタな開発プロセスをチケット上に実現できる。
さらには、蓄積されたコミットログやチケットを集計したり検索することで、エンピリカルなソフトウェア工学の知見を適用して、メトリクスの採集による傾向分析ができる。

さらには統計学やビッグデータを適用して、仮説に基づくプロセス検証ではなく、データ主導によるプロセス検証もできるかもしれない。

SCMコミットログはファイルのメタ情報: プログラマの思索

チケット駆動開発の展望part2: プログラマの思索

akipiiさんはTwitterを使っています: "良い記事。僕もPrivateファイルはMercurialで管理している。コメントや履歴のようなファイルのメタ情報はコミットログで保持すべき。重要ファイルはSubversionで管理する - Basic　http://t.co/kpARpCMu"

【3-3】チケット駆動開発のもう一つの側面として、パッチ駆動開発の顔もある。
パッチをチケットに添付して、コードレビューのやり取りをする。

Redmineによるチケット駆動開発はパッチ駆動開発と同じ: プログラマの思索

パッチ駆動が重要である理由は、「ソフトウェア開発は頻繁なバージョンアップで品質も機能も改善していく」手法が基本原理ならば、変更管理や構成管理が非常に重要になるからだ。
でも、この開発プロセスは、GitHubのプルリクエストが普及した現在、正直古くなっている部分もある。

RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRedmineの課題: プログラマの思索

RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索

チケット駆動開発にGitの良さも組み込んで、もっとアジャイルな開発基盤にしてしまいたい妄想を今後も考えてみる。