[#TiDD] チケット駆動開発でちょうどいいプロセスをめざす - 「本当に使える開発プロセス」を読んで -

チケット駆動開発にふれた本が増えてきています(あきぴーさんの記事)。このうち「本当に使える開発プロセス 」ではテストの章でATDD(gihyo.jp BDDとATDD)やCI(Wikipedia)を含むALM(Wikipedia)の文脈で紹介されています。

アジャイル関連用語が多く出ていますが、帯には「ウォーターフォールでもない！アジャイルでもない！」と書かれていて、本文中にも以下の様に書かれています。

ウォーターフォールやアジャイルなど、特定のプロセスや方法論、お作法に捉われず、「ちょうどいい」と思えるシステム開発の進め方をデザイン(改善)することを目指します。(p.6)

第１章もシステム企画、要件定義、基本設計、詳細設計・プログラミング、テストという切に分かれていて、テストの節でチケット駆動開発に触れられています。
これは上流を強化したアダプタブルウォーターフォールの具体例とも言えるでしょう。構成としてはウォーターフォールなのですが、チケット駆動開発のところ(p.70)では

• チケットをプロジェクトの情報の中心とする
• チケットによる作業の割り振りと進捗管理を行う
• チケットなしのコミットは禁止とする

と言う原則のほか、

チケット駆動開発では、バグやテストの情報だけでなく、要件や課題、変更要求といった情報に関するすべてのタスクをチケットで表現します。(p.71)

とあり、テストに限らないチケットの利用にも言及されています。

このあたり、書籍「チケット駆動開発 」の構成で悩んだところです。より具体的な内容を整理して書くと「本当に使える開発プロセス 」のようになりますし、チケット駆動開発を中心にするとプロセス全体を具体的に書きにくくなってしまいます。

閑話休題。このほかにもリズミカルな開発やCIとの連携によるALMの話。さらには、ツールはプロセス改善の「足がかり」と題して、「ツールはシステム開発の業務システムである」として、ツールの導入可否を判定するチェックリストと判定基準も載っています。このあたり、著者の知見がまとめられています。

最後に「本当に使える開発プロセス 」で目指すちょうどいいプロセスを目指す際のチケット駆動開発のメリットを挙げておきます。

スモールスタート(ハードルを下げる)

障害管理から始められ、プロジェクトの問題にあわせて順次拡張できます。まずは、プロジェクトの最も大きな問題を解決できる様に導入すると良いでしょう。

インクリメンタルな改善(継続的な価値の提供)

プラクティス間の依存関係が少なく、段階的に導入できます。チームがイメージできる範囲で導入を進めていくと良いでしょう。

最適化可能なバリエーション(ちょうどいいプロセス)

チケット駆動開発のゴールは一つではありません。様々なバリエーションがあります。チームにちょうどいいプロセスを実現できます。

今回は業務システムの開発に向けての本でしたが、それ以外の分野にもチケット駆動開発は有効です(赤羽根さんのIT全般統制の事例などは秀逸ですね)。

今後もより多くのチケット駆動開発の事例が公開される事を期待しています。