[#TiDD] チケット駆動開発がもたらすプロセス その２

続きです。

では、チケット駆動開発でどのようにプロセスが変わるかというと

• チケットへの依存から、チケット中心の開発
• 2階層プロセスが明確になる
• リアルタイムに見える化される
• スコープの変更(計画ゲーム)が実施される
• 改善が始まる
• リリース回数が増える

という点です。

チケットへの依存から、チケット中心の管理へ

手作業による管理が難しい状況では、チケットによる管理は効果的です。チケットを使うことで、細かな作業、仕様変更、不具合が容易に管理できます。チケットを使い出すと、チケット以外のメディアとの2重管理は無駄です。すぐにチケットを中心とした開発に移行していきます。

チケットが中心になると、常にチケットを見ながら次の作業を考えるようになります。そして、1日の作業が、チケットの確認から始まり、目標設定、作業、進捗の登録といったリズムを持つようになります。

2階層プロセスが明確になる

チケットを中心とした開発では、プロジェクト全体の作業がチケットで駆動されるだけでなく、個人の作業もチケットで駆動されます。様々なタスクを記述したチケットは、プロジェクト全体の状況を示すだけでなく、個人毎の作業状況も示します。

プロジェクトの状況は全体のタスクをBTSの機能により、バージョンやマイルストーンごとに時系列で示したものです。チケット一覧のほか、ガントチャートデモ確認できます。また、個人毎の作業も容易に一覧で参照できます。同じチケットを使ってプロジェクト全体の状況と個人の状況を管理できます。

ここで注目すべきは、プロジェクトにおいても、個人においても、チケットは期限や重要度などで優先順位がつけられていることです。プロジェクトおよび個人の視点で、一日や次のリリースといったマイルストーンまでの作業が優先順位を考慮しながら実施されます。

リアルタイムに見える化される

チケットが更新されると、すべての作業はリアルタイムに見える化されます。短納期の開発、あるいは、短期間のリリースを繰り返す場合に、このリアルタイム性は重要です。良いことも悪いことも、進んでいても遅れていても常に見える化されます。

プロジェクトの計画は変更が必要か、それとも再計画が必要か、常に明確になるのです。

スコープの変更(計画ゲーム)が実施される

綿密なリリース計画であっても、それが実施不可能になったなら、計画を変更する必要があります。人を追加投入する、リリースを遅らせる、スコープを変更する、などの選択が必要です。

教育が必要なことから人の追加投入はあまり有効でないことが多いでしょう。リリースを遅らせれることは、リリース後に発覚する問題を先送りしていることになります。リスクベースに考えるなら、リリース時期をあまり変更せず、リリース対象(機能)を減らすようにスコープを変更することが現実的でしょう。それは計画ゲームそのものです。

同じことが個人のプロセスでも起こります。作業が多すぎる場合には減らすべきですし、少ない場合には他の開発者のチケットを引き受けて、スコープを変更します。

改善が始まる

チケット駆動で作業を行うようになっていたなら、日々の進捗や課題を確認する朝会や一定の区切り毎のふりかえりでは、チケットが活躍するようになります。残作業や進捗はもちろんのこと、、チケットを元に今後の計画を立てられるからです。また、チケットはプロセスの履歴ですから、当初の見積もりや作業割り当て、作業の進め方など、多くの問題を振り返ることができます。明確になった課題は、次のリリースに向けて改善されることでしょう。

リリース回数が増える

リリースにより、プログラムや仕様の問題が明らかになります。リスクベースに考えるなら、動かしてみないと分からないことや仕様が固まっている機能は早く開発し、先行する開発によって変更が予想される機能は、後回しにする方がリスクは低減します。

このようにリスクベースに考えると、リリースは複数回に分かれることになります。また、リリースごとにプロセスが改善されるようになると、一度だけのリリースではもったいないことに気付きます。作業の再割り当て、すなわち計画ゲームのタイミングであるリリースが有効に機能します。リリース作業も徐々に定型化、自動化されるでしょう。

このように、チケット駆動開発を進めると、徐々にあるべき姿に近づいていくのです。

続く