安定化スプリント - 必要悪か、それとも純粋な無駄か？

作者 Mark Levison , 翻訳者 和智 右桂 投稿日 2010年1月3日

セクション

プロセス/プラクティス

トピック

Delivering Quality ,

品質 ,

アジャイル技術 ,

Agile in the Enterprise ,

継続的な改善 ,

受け入れテスト ,

Agile ,

テスト

共有 |

原文(投稿日：2009/12/19)へのリンク

「安定化スプリント（"Stabilization Sprints"）」という言葉を耳にしたが、これはアジャイルの世界で標準的なものなのだろうか？安定化スプリントとは、製品をリリースする前、通常の開発サイクルの最後に付け加えられる付加的なスプリントである。名前が示している通り、このスプリントは通常、プロダクトを最後にもう一度叩き、最後のバグを出すためのものである。

Ilja Preuss氏は次のように言う。「安定化スプリントはあなたが使っている完了の定義が不十分か、従われていないことを示す兆候です。」

Sarath Kummamuru氏によれば、安定化スプリントがふさわしいケースがいくつかあると言う。

1. スプリントを終了させるのを急ぐことで発生してしまう技術的負債に対処するため（基本的には既存のコードベースをリファクタリングしたり、ユニットテストのカバレッジを改善したりといったもの）。
2. 各スプリントごとに完全な自動化テストと回帰テストが行えないことによって発生してしまう品質保証に関する負債に対処するため。これは自動化がそれほどされていないレガシーコードベースで作業をしている会社では、きわめて良く見られるケースである。
3. 複数のプラットフォームにリリースされる製品のテストと検証を行うため（例えば異なるアプリケーションサーバ上で動作保証を行ったり、製品が異なるOS上で動作することを保証しするもの）。
4. なんらかのパッケージングを行わなければならない場合には（例えばCDに焼くなど）、そういう作業は典型的にこのリリース／安定化スプリントで行われる。

氏によれば、安定化スプリントを必要なものと受け入れるということは、人に松葉杖を与えるようなもので、もう一度歩く手助けをすることでは決してないという。既存のコード全てのテストを自動化するには数年がかかるかもしれないが、それは現状に甘んじてよいことの理由にはならない。加えて、自動化された受入テストないしユニットテストがなければ、コードの品質は分からないのだ。そこにバグが隠れているかどうかが分からないのであり、（リーン的視点から見れば）これは事実上、無駄なのである。

Edward Arunaj氏は次のように言う。「典型的に言って、もし何か懸案があるのであれば、それは負債を貯めているということなのです。多くの場合、安定化のために１回以上のスプリントが必要になるかもしれず、それはいつリリースできるか予想できないということにつながります（ステークホルダは遅延以上に予測ができないことを嫌います）。」

Mark Woyna氏は、安定化スプリントを取り除くことが、目下経済的に妥当ではない場合の具体例を挙げている。この場合、テスト環境には800台のサーバを立てて（これは数百万ドルかかる）、一秒当たり300,000のオペレーションを行う必要がある。これらのサーバ上でのテストは3-4週間かかるので、サーバ間のアップグレードがゆっくり展開された場合に何が起こるか、チームはシュミレーションをしなければならない。しかし、Woyna氏によればこれは特殊なケースである。「安定化スプリントの間に実施される作業は、単にそれまでやってこなかったことだという点には賛成します。（中略）もしもソフトウェアに欠陥があるなら、早めに見つけたいと思うでしょう。」

最後に、Steve Gordon氏はこう言っている。

この欠陥だらけの作業について根本原因を修正するということこそが、物事を改善するのです。確かに私たちは目下の問題を修正する必要もあるのですが、それしかやらなければ、問題はまた戻ってきて、あなたは常に不十分な作業と「予期せぬ」欠陥とに悩まされることになるでしょう。

「安定化スプリント」を通常のいつも実施するプラクティスとして受け売れることは、単に目下の問題を修正するだけであり、同種の問題が再度発生することを受け入れるということなのです。

InfoQでは、以前にも「「完了」は「シップ可能」ということか？」という記事を取り上げている。