昔からソフトウェアリリースはエンジニアリングとビジネスが手を握ることだと考えられている。エンジニアリングはテストしたコードをビジネスに渡し、次にビジネスがそれを市場に普及させることでサイクルが完成する。しかしながら、アジャイルではソフトウェアリリースは内部リリースと外部リリースの2つのカテゴリに入れられる。これは2つの間に緩い結合を作るのに役立つ。内部リリースはエンジニアリングによってなされ、ビジネスは外部リリースとして内部リリースのうちの1つを使う選択肢が与えられる。
Cutter Consortium (リンク)(ダウンロードコードはRELEASEMYTH) の最近の記事で、BMCのIsrael Gat氏 (リンク)がソフトウェア世界でこの2つのリリースを分けることについて興味深い議論を行っている。彼によると内部リリースと外部リリースは同じコインの表裏として考えられるべきだ。
ある機能と機能性を実現するコード本体は1つのものです。ビジネスの成果を出すために営業でこのコード本体を使うことは、まったく別のことです。2つの活動が異なるだけでなく、それらは1対1の関係で結ばれる必要はありません。
彼は1つが注入口でもう1つが排出口である2つのパイプがあるプールの興味深い例え話をした。彼は注入口のパイプをエンジニアリング、排出口のパイプをビジネスに例えた。
この例で、注入口をエンジニアリング、排出口をビジネスと考えます。エンジニアリングは自分のペースでリリースを提示できます。ビジネスは、提示されたリリースから選び出します。この例では、マーケティングは完成に応じてリリースを宣伝する義務は負いません。マーケティングは3ヵ月で宣伝するかもしれません。後になって現在のリリースを別のリリースのときに宣伝することを選ぶかもしれません。制限付きでリリースが利用できるようにするかもしれません。または、リリースを宣伝することはないかもしれません。
エンジニアリングは今ビジネスと緩く結び付けられているので、ソフトウェアが生き生きとして継続する流動的なリリースコンセプトに向かって動くことができるとIsrael氏は言った。エンジニアリングは、内部リリースに合った速さでリリースを繰り返し、ビジネスはどのリリースをいつ外部リリースとして顧客に出すか決めることができる。
この記事にコメントして、Ryan氏(リンク)は、Israel氏のチームが3つの内部リリースのうち1つを外部リリースするというさらなる洞察を加えた(リンク)。そして、この利点は有用なフィードバックを得て、外部リリースをビジネスでよりよく売り込めることだと示した。Ryan氏によると、
すごくうまくいきました! その結果、私は「内部リリース」のリズムをマーケティング、営業、そして、市場で使われるものの2倍早くして始めるように、ほとんどのアジャイルチームを指導します。このようにして、フィードバックが得られて、「外部リリース」を市場へよりよく導けるリリースを手に入れるのです。
Israel氏によると、アジャイルによって頻繁でより速い内部リリースがソフトウェアを生き生きとした流動的なものにする。これによって、従来のリリースプロセスは時代遅れになる。リリースを分けることは、エンジニアリングとビジネスがお互いのリリースの頻度に邪魔されることなく、リリースのパターンによって動く役に立つのだ。
原文はこちらです：http://www.infoq.com/news/2009/01/internal-external-release