チケット駆動開発を誤解していた@HIROCASTERでございませう。
チケット駆動開発（TiDD）の提唱者である方の書籍が8/24(金)に発売されます。
 |
小川 明彦、阪井 誠 |
なんと、これまでチケット駆動開発は no ticket, no commit（チケットがなければコミットできない）というルールが絶対だと理解していたですが、著者みずからが、これはテーラリング（プロジェクトの特性に合わせて手直しする）の対象であると述べています。
基本的なルールですが必須ではありません。12章のテーラリングガイドの対象の一つになっています。 RT @ryuzee: チケット駆動開発本を買うかどうか悩んでいるのだが、No Ticket No Commitは僕は守るつもりのない行動なので、それが前提だとつらい。どうなんだろ
— さかば (@sakaba37) August 16, 2012
チケット駆動開発に対する考え
no ticket, no commitというルールは反対です。
チケットを書いている時間で、実際にfixするコードの変更は、現場でいくらでもあるからです。そういった小さな変更は、コードを追えば十分に理解できるし、それぐらい軽微な内容であることが多い。
よって、チケットから詳細をどうのこうのと、ふり返って調べるようなことも、ほとんどありません。むしろ、ソフトウェアはそれぐらい短時間で柔軟に修正できる状態を保つべきであると考えています。
チケットを使うこと自体は反対ではない
ですが、人間の記憶の曖昧さや、仕様の理解を深めるために、チケットを利用するというのは1つの方法として推奨します。実装するプログラマが最適だと思う方法をとれば良いと考えており、誰もが1つの厳格なルールに縛られる必要性はないと考えています。
なので、チケット駆動開発は、そうとうお堅い話だなぁ。という印象でした。その印象がガラッと変わったのです。
@ryuzeeさんも誤解していたようです。
@sakaba37 なるほどー。ありがとうございます！。テーラリングの対象だとすると、方法論の代名詞的に使われるのは僕みたいに誤解するかもしれないですね。。。
— Ryutaro YOSHIBA (@ryuzee) August 16, 2012
書籍「チケット駆動開発」で注目している内容
チケット駆動開発をアジャイル開発だけでなく障害管理・タスク管理・課題管理・インシデント管理・ストーリー管理など各状況でテーラリングするためのノウハウを整理してまとめました。
チケットをどう扱うか？どういうのを作成するか？削除するか？悩んだことがあるのではないでしょうか。こういったテーラリングのノウハウを整理されている本書は、現場に役立つ1冊になりそうです。
|
小川 明彦、阪井 誠 |
