[#TiDD] 二つのチケット駆動開発と「方法論」
「
Redmineによるタスクマネジメント実践技法
」がアマゾンで「なか見!検索」に対応したと思ったら、今度は初めてのレビューも載りました。ありがとうございます。「うまくまとまっていて読みやすかったけど」と評価していただきながらも
「ひとつの開発方法論というには、まだ未成熟ではないでしょうか。今後に期待します。」
とのことです。なかなか厳しいコメントですが、確かにそうだと思います。
この本に書いているチケット駆動開発には2つあります。
1.プラクティス
2.開発法
1のプラクティスは、既存のプロセスにチケット駆動開発を組み込むもので、補完型と呼んでいて、第一部で説明しています。
2の開発法はチケット駆動開発を中心とした開発法で完全型と呼び、第2部以降に書いています。必ずしもアジャイルに限らないと思いますが、この本では2部以降ににチケット駆動開発を中心としたアジャイル開発法を説明しています。
ご指摘の方法論としては、これからのところが色々あると思います。著者らの経験で色々言い切ると、方法論らしくなるのかもしれませんが、それは「No Ticket! No Commit!」というシンプルなルールを中心とするチケット駆動開発の良さをなくすように思います。
ここにわかりやすいKanbanとScrumの比較表が載っています(たぶん、こちらの資料がベースだと思います)。
これを見ていて気付いたのは、チケットはどちらにも利用できると言うことです。チケットは備忘録としての側面があり、とりあえず登録するほうがチケット駆動開発的ですが、マイルストーンやバージョンで区切ることでスプリント(イテレーション)を確定して、その間の集中を維持することもできます。
また、何でも登録できるからと言っても、それは容易に区別できます。tracだとチケットの種類、Redmineならトラッカーかカスタムフィールドなどによって、区別して表示することができます。
私の思うチケット駆動開発「方法論」は、そのような複数の選択肢とその良し悪しを示さなくてはならないと思っています。しかし、まだ議論や経験が不足しているので、これからに期待していただかなくてはいけません。
そこで、「プラクティス」あるいは「アジャイル『開発法』」として、細かな決め事でなく大切なことだけを載せています。初めてのチケット駆動開発の本である「
Redmineによるタスクマネジメント実践技法
」をきっかけに、多くの議論、経験を重ねて、いつかは方法論にできればと思っています。
ぜひ、皆様のレビュー・コメントをお願いします。
« アジャイルプラクティスの副効果 | トップページ | [#TiDD] チケット駆動開発とコーチング - SPI Japan 2010 - »
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
« アジャイルプラクティスの副効果 | トップページ | [#TiDD] チケット駆動開発とコーチング - SPI Japan 2010 - »
コメント