プログラマの思索

チケット駆動開発の肝の一つは、リリース予定バージョンとイテレーションを同一視する点にある。
イテレーションの扱い方がチケット駆動開発の重要な運用ノウハウの一つ。
大規模プロジェクトではイテレーションの扱い方に更に一工夫がいる。
考えたことをメモ。

【元ネタ】
開発プロセスの最適化手法

システムを小さく作って段階的にリリースすることが重要な理由 - 極北データモデリング

【1】小規模プロジェクトでチケット駆動開発を運用している場合、リリース予定バージョンがリリースモジュールのバージョンあるいは納品モジュールのバージョンに一致し、更にAgile開発のイテレーションと同一視できる。
だから、小刻みにリリースしながら機能も品質も拡張していく戦略が取りやすい。
小規模リリースを実際に運用するのはとても楽しい。

しかしながら、大規模プロジェクトになると、小規模リリースを実現するのが難しくなってくる。
理由は、複数チームのイテレーションを同期させるのが難しいからだ。

大規模プロジェクトでは、複数チームの成果物が揃って初めて一つの製品がリリースできる。
一つのコンポーネントができたとしても、それを他のコンポーネントと一緒に結合して初めて製品ができあがる。
その時に、他チームのコンポーネントが出来上がっていなければ、いくら自分のチームが頑張っても、全体としてリリースは遅れてしまう。
進捗が速くても伝播しにくいが、進捗の遅延はすぐに他チームに伝播する。
この辺りはTOCの制約の話に似ている。

だから、「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」によれば、複数チームのイテレーションを同期させるプラクティスであるアジャイルリリーストレインの重要性を述べている。
複数チーム間のイテレーションを全て歩調を合わせることによって、複数チームの成果物を結合してビルドするタイミングを一致させる。
これによって、製品のリリースタイミングがイテレーションの単位となる。

しかし、実際の開発では、アジャイルリリーストレインの運用は一筋縄ではいかない。

例えば、全チームの開発のイテレーションを合わせたとしても、ビルドした時に障害が判明したとする。
でも、次のイテレーションでは他のチームも自分のチームも新機能を追加するストーリーになっている場合、自分のチームだけが新機能の開発を取り止めて、バグ修正に専念することはできない時は多い。
自分のチームが作る新機能のライブラリを他チームが必要としている時があるから、新機能の開発を取りやめると他チームの進捗を遅らせてしまう。

あるいは、組込製品開発でハードウェア(HW)の開発チームとソフトウェア(SW)の開発チームが協調してAgileに開発していたとしよう
この時、HWのチームとSWのチームのイテレーションを同期させた場合、確かにイテレーション終了時にハードとソフトを結合できるタイミングが一致するが、一発で動作させるのは難しい時が多いだろう。
実際は、ハードウェアの事情、ソフトウェアの事情をお互いに融通を効かせながら、ちょっとずつ動かしては修正する試行錯誤の繰り返しでしか、開発は進まない。
イテレーションを同期させたとしても、WF型開発のビッグバン結合と何ら変わらない。

あるいは、RedmineやMantisの複数プロジェクト機能を使って、設計工程・開発/単体テスト工程・結合/総合テスト工程・運用保守工程などのように、工程別にプロジェクトを作っていたとしよう。
このような運用は、特に大規模プロジェクトでWF型開発に即して運用している時が多いだろう。

もちろん、プロジェクト(工程)単位にリリース予定バージョンが定められて、その単位でリリース可能になる。
しかし、各プロジェクト(工程)間のリリース予定バージョンが異なっていた場合、ビルドモジュールのバージョンと対応づけるのが難しくなる。
ビルドしてモジュールを作ってリリースした場合、当然、設計工程の仕様変更のチケットも含まれるし、開発工程の新規開発のチケットも含まれるし、結合テストの障害修正のチケットも含まれるだろう。
それらチケットが1個のビルドモジュールに含まれていることを示すために、バージョンを細かく作り、更に他プロジェクト(工程)間のバージョンと手作業で合わせるのは結構面倒だ。

【2】上記の問題点は、二つのことを示唆している。
一つは、複数チーム間のイテレーションを同期させたとしても、一発で全てのコンポーネントをビルドして製品を作るのは難しいこと。
もう一つは、RedmineやMantisの複数プロジェクト機能を使っている場合、現状の機能ではイテレーションを同期させるのが難しいことだ。

【2-1】前者の解決方法としては、段階リリース、イテレーションの階層化、反復型開発などの手法があると思う。
段階リリースとは、古くからのWF型開発で言われている小規模リリースの一つ。
フェーズ1、フェーズ2などのようにシステムをリリース可能なサブシステムへ分割し、段階的に開発してテストしてはリリースしていく手法を取る。
段階リリースでは、1回のリリースが完全な本番運用となるのは稀で、最初から数回のリリースはお試しシステムみたいなもの。
数回のリリースで機能を揃えてから、ようやく本番稼動する。
つまり、段階リリースとは、複数回の内部リリース(ベータバージョン)を経た後に最終リリースする開発スタイル。
この手法の利点は、WF型開発の一発リリースのリスクを許容可能なサイズに小さく出来ること。
XPの小規模リリースとの違いは、XPの場合はリリースは顧客価値のあるシステムを必ず届けることと呼ぶように、必ず本番リリースになる点に対し、段階リリースは内部リリースを含む点にあるだろう。
但し、XPの小規模リリースの場合、1個のイテレーションで設計・開発・テストを並行作業するのに対し、段階リリースでは1個のイテレーションで設計・開発・テストが直列作業に進むので、テストで火を噴くことが多い。

イテレーションの階層化は、XPJUG関西の細谷さんから教わった。
例えば、組込製品開発では、HWチームのイテレーション1個に対し、SWチームは3回のイテレーションを内部で繰り返す。
SWチームは内部リリースする度にHWチームにソフトウェアを届けて実機で試してもらい、SWチームへ障害などをフィードバックしてもらう。
そして、HWチームのイテレーションの最後で、SWチームは最終的なソフトウェアを届けて、最終リリースする戦略。
つまり、HWチームの親イテレーション1個に対し、SWチームは子イテレーションを複数個持つので、イテレーションが1対他の関係になる。

この手法の特徴は、身軽に動きやすく変化が激しい子チームのイテレーションを故意に分割して、複数回の内部リリースの成果物を親チームに届けやすくし、親チームのフィードバックを子チームが受け入れるように出来ること。
これによって、最終リリースのリスクを許容可能なサイズにできるだけでなく、実際にHWチームで実機を動かした内容のフィードバックを受けることで、変化を受け入れながら、品質も機能も拡張できる。

反復型開発(イテレーティブ・エボリューション)とは、漸進型開発とは違い、システム全体を薄く作りこんでいく開発スタイル。
この発想もXPJUG関西の細谷さんから教わった。

複数チームの数回のイテレーションは同期させながら機能拡張していくが、4～5回のイテレーションの後、特別な1回のイテレーションを作り、今までの結合作業で不具合が発生したバグを直す期間を設けること。
実際の開発では、全てのイテレーションで機能拡張だけやればいいわけではない。
時には障害修正に専念せねばならない時もある。
特に複数チームの成果物を結合した場合、一発でリリースできる品質にはならない時が多いから、わざとテストだけのイテレーションを作り、リファクタリングしたり、アーキテクチャを見直したり、品質をアップしたりする作業に専念する。

いずれの手法にしても、複数チームの成果物をイテレーション単位のビルド作業で結合させるのが難しい弱点をうまく補強している現実的な手法だと思う。

【2-2】後者の解決方法としては、Redmineのバージョンの継承機能とイテレーションの階層化を組み合わせて運用する方法があると思う。
複数プロジェクト機能を使う場合、Redmineのバージョン継承機能を使って、最上階のプロジェクトで本番リリースすべきイテレーションを定めて、子階層の全てのプロジェクトへ強制的にイテレーションを継承させればいい。
各プロジェクトでは、親プロジェクトのイテレーション1個に対し、イテレーションの階層化の手法を使って、複数回のイテレーションを作っておく。
そして、各プロジェクトで内部リリースしながら、品質も機能も拡張していく。

Redmineのバージョン継承機能はアジャイルリリーストレインを簡単に実現してくれる強力な機能の一つ。
実際の運用で上手に使えば、アジャイル開発のスケールアップを強力にサポートしてくれると思う。