[#TiDD] 書籍「チケット駆動開発」では広い議論を狙っています
かつてXPがブームになったとき、7つのプラクティスがありました。その7つのプラクティスには関連があり、すべて守らないとうまくいかないと思われました。しかし、実際のプロジェクトのお話を聞いてみると、顧客同席でなかったり、ペアプロをしていなかったり、色々なプロジェクトがありました。
プロジェクトにはいろいろな制約があり、プロジェクトの成功のためには犠牲にしなければいけないプラクティスがあったからです。しかし、そのようなプロジェクトであってもXPの効果は(一部であったかもしれませんが)得られていました。
参考:川端さんらとの論文PDF(日本語・英語)、スライド(日本語・英語)
チケット駆動開発は、“No Ticket, No Commit!”を基本ルールとした「プラクティス」として、現場で生まれました。このルールを適用する事で構成管理との関連付けができますので、プログラムの更新理由がチケットの内容である事を示せますし、チケットに議論があればその修正に至った経緯も示す事ができます。また、チケットのワークフロー機能を使えば、チケットの完了時の確認を確実に行う事ができます。
しかし、実際にチケット駆動開発を実践されている方のお話を聞いている方のお話を聞いていると、様々なバリエーションが存在していました。そこで書籍「チケット駆動開発」では、基本的な考え方を示しながら、バリエーションについても触れる事にしました。
Twitterを見ていると、このような内容はどうも誤解を与えるようですので、すこし整理しておきます。
1. チケットがないとコミットしてはいけない
チケット駆動開発の基本ルールです。守る事で上述のようなメリットがあるので、プロジェクト内でチケットが活用されるでしょう。しかし、従来法の事例では上流(例えば単体テストまで)では厳しく言わないようにされている場合も多いようです。また、最近の事例として“Pivotal tracker”を利用されている方もおられ、構成管理との連携はないものの、チケット駆動開発の部分的な効果を得られています。
2. コミットするなら細かな作業であっても、チケットを作成しないといけない
コミットとチケットは1対1でないといけないか、なるべくその方が良いでしょう。しかし、実際にはチケットの起票が煩雑になり、必要名項目であっても記入されなくなってしまうかもしれません。それよりは、汎用的なチケットを用意しておいて、同じチケットで何度もコミットする方が現実的でしょう。
3. チケット駆動開発はアジャイル開発である
アジャイル開発がマニュフェストをすべて遵守するという定義なら、上述のXPの様に多くのプロジェクトがアジャイルでないかもしれません。チケット駆動開発はアジャイル開発と親和性が良く、アジャイル開発を意識しながら運用したなら、アジャイル開発のメリットを感じる事ができるでしょう。しかし、チケット駆動開発はアジャイル宣言のすべての要素を含みませんし、従来法を補う形でも実施できますので、チケット駆動開発が常にアジャイル開発と言う訳ではありません(従来法を補う形のチケット駆動開発を本の中ではアダプタブル・ウォーターフォール開発と読んでいます)。
4. 組織のプロセスである
チケット駆動開発は組織プロセスとしても利用可能です。しかし、チケット駆動開発は現場から生まれました。いわばプロジェクト改善です。組織のプロセスと考えるよりもプロジェクト向けに最適化するツールボックスと考えた方が、チームの能力を最大限に引き出せるでしょう。
5. まとめ
チケット駆動開発は厳密な定義がなく、まるでバズワードの様に語られてきました。しかし、チケット駆動開発には多くの利点があり、事例を整理する事でよりプロジェクトにふさわしい方法で実践する事が可能だと思っています。書籍「チケット駆動開発」では、より多くの知見をあつめ、多くの議論ができる様に、従来考えられている要理も柔軟な幅広く議論できるように定義しました。
その言葉について多くの議論が集約できるようなものを、アンブレラワードと呼ぶそうです。よくわからないバズワードでなく、より現実的なアンブレラワードとして議論できること。それがより広いチケット駆動開発の定義を採用してテーラリングガイドを載せた理由です。
チケット駆動開発は現場から生まれました。現場のプロジェクトを成功させることが、チケット駆動開発の目的だと思います。より広い定義を採用して、少しでも多くのプロジェクトを成功に導きたいと思います。
« 自動化による信頼性向上 - オブジェクト指向とアジャイル開発 - | トップページ | TwitterとSNSの違い »
「チケット駆動開発」カテゴリの記事
- 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)
この記事へのコメントは終了しました。
コメント