[#TiDD] チケット駆動開発の事例を集めたい

ソフトウェアプロセスは選択的なタスクの集合です。「ソフトウェア開発に銀の弾丸はない」と言いますが、実は銀の弾丸があっても狼男だけではないので必ずしも死なないのだと思います。狼男には銀の弾丸、ドラキュラには太陽の光、フランケンには怪物くん、怪物くんには怪子ちゃんが必要なのです。

CMM/Iで有名なハンフリーさんの「ソフトウェアプロセス成熟度の改善」という本の序文に「『ソフトウェア』危機は死んだ！」とあります。確かにある種の危機は死んだかもしれませんが、それ以外の危機はCMM/Iでは、リーズナブルに殺すことが困難です。

規律正しい方法論や技術がすべての問題を解決することはありません。それは、わかり易く、体系的にまとめた反面、苦手なものもできてしまうのです。

より広範囲の問題を扱うには、抽象度を上げるという方法もあるでしょう。かつてプロセスモデリングがブームだったとき、プロセスの動的な変更を記述する技術が注目されました。抽象化するとたくさんの問題をまとめて議論することが可能になりますので、記述することで議論が容易になったのでしょう。しかし、その反面、具体性がなくなり、現場の問題と結びつけることは難しものになりました。

私がチケット駆動開発に期待しているのは逆のアプローチです。受け皿だけを用意して、具体的な事例を集めることです。

かつて、プラクティスにあだたぬチケット駆動開発という記事で「チケット駆動開発はソフトウェア開発の基盤プロセスであり、多くの目的を達成できる方法論」と書いたのはそんな気持ちからです。

たとえば、Redmineによるタスクマネジメント実践技法には、タスクすべてをチケットにする完全型と、WBSなど既存の仕組みを補うものをチケットにする補完型を定義しています。それ以外にも、ストーリカードを親チケットとする方法、ストーリカードを別の種別のチケットとする方法、Wikiに書いておくという方法もあるかもしれません。

そんな色々なチケット駆動開発の事例を集め、「こんなチケット駆動開発もある。こんな点が良かった」という議論をしてみたいと思っています。現場発の技術であるチケット駆動開発が、現場の問題を解決する方法の基盤となり、現場の問題を解決する選択的なタスクを増やしたいのです。

このような思いから、チケット駆動開発には「No ticket, No commit!」という基本的な規律以外にあまり規律を増やさない方が、たくさんの事例を収集することができ、より現場の問題に対応しやすくなると思っています。

追記：規律のセットの事例を集めるのは「あり」かもしれません。