本来のチケット駆動開発とは何か？～アジリティと規律の絶妙なバランス #tidd

@sakaba37さんから「本来のTiDD」という言葉を聞いて分かってなかったけれど、皆さんのTwitterのおかげでようやく理解できたのでメモ。

【元ネタ】
Togetter - 「チケット駆動開発(TiDD)について思うこと」

Togetter - 「本来のチケット駆動開発(TiDD)とは何なのか？」

チケット駆動開発について思うこと - かおるんダイアリー

【１】チケット駆動開発はTracのチケット管理から生まれた。
提唱者のまちゅさんの独創性は「チケット無しのコミット不可(No Ticket, No Commit!)」にある。
つまり、成果物を更新する時は必ずチケットに変更理由を残す運用ルールを指す。

この運用ルールは、課題管理システム(ITS)と構成管理ツール(SCM)がTracではセットで提供されていることから実現した。
このルールを発展させると、成果物のトレーサビリティを実現できるので、上流工程の品質向上にも寄与することもできる。
但し、チケット駆動開発そのものはAgile開発もWF型開発も関係ない。
ITSとSCM、更にはCIツールの一体化という技術にTiDDの特徴がある。
個人的には、TiDDの本質はアジリティと規律の絶妙なバランスにあるだろうと直感している。

【２】僕は、チケット駆動開発を実践してみて、その特徴を経験できただけでなく、アジャイル開発そのものも体験することができた。
その体験では、何故アジャイル開発の運用が難しいのか、という経験も含んでいる。
僕の一意見では「並行開発」「漸進型開発(インクリメンタル)と反復型開発(イテレーティブ)」のキーワードで説明できると思っている。

更に、チケット駆動開発を運用するツールであるRedmineを通じて、今まで知られている各種のプロセスのプラクティスやアンチパターンも体で理解できた。
だから、チケット駆動開発はアジャイル開発の一つの実装形であると思っている。

【３】今の僕の興味は、チケット駆動開発を運用するツール群(ITS・SCM・CI)を使って、XP・Scrum・PF・PMBOK・ITILなどの各プロセスを実装してみて、どんな利点・弱点・課題・限界があるのか試してみたい点にある。

XP・Scrum・PF・PMBOK・ITIL・CMMI・テスト管理などの各種技法、プラクティス、アンチパターンは既に知られているにも関わらず、先人のアイデアにツールが追いついていないから、うまく運用できていない現場が多かった。
でも今は違う。
OSSの優れたツール(Redmine、Trac、Subversion、Git、Hudsonなど)、RubyやPythonのような強力な軽量言語のおかげで、プロセスの実装がやりやすくなっている。
今は、ソフトウェア開発のベストプラクティスをツールの一機能で実装してしまえばいいだけだ。

そして、TiDDのツールを通じて、ソフトウェア開発そのものの本質を理解したいと思っている。
僕の実感では、ソフトウェア開発には「一発リリースは危ない」「変化が多いので変更管理が大事なのに無駄な手続きが多い」という特徴があるように思う。
だから、WF型開発のような本番リリースが１回だけのプロセスはとても大変だし、変更管理を運用する時にアジリティと規律のバランスがとても難しいのだ。

それらツールの特徴を把握した上で、物理学者のような思考実験をしてみたいのだ。
物理学者は、複雑な自然現象をシンプルなモデルで設定するために、複雑なパラメータをどんどん削除して、本質的に必要なパラメータだけ残して、モデルから意味ある物理法則を導く。
同様に、SW開発で運用するプロセスの各種特徴はツールの一機能で実装してしまい、複雑な手続きや無駄なドキュメントを省いてしまえばいい。
そうすれば、開発プロセスというモデルはシンプルになるから、開発プロセスで本質的に必要な特徴は何なのか、が見えてくるはずだ。
すると、各プロセスのベストプラクティスやアンチパターンが見えてくるし、各プロセスの共通現象からソフトウェア開発の本質も見えてくるだろう、と思っている。

この辺りは又考えてみる。