guidance-icon

自分が何を行っているかを分かっていれば、それは研究ではないだよ。
 
– アルベルト・アインシュタイン

スパイクの概要

SAFeでは、スパイクはイネイブラーストーリーの特別の一種である。スパイクはもともとXPによって定義され、研究、設計、調査あるいはプロトタイプ作成などのような作業のために利用される。スパイクの目的は技術的なアプローチに関するリスクの低減、要求仕様に対するより良い理解、ストーリーの見積もりに関する信頼性の向上に関する必要な知識を得るためである。

スパイクは技術的スパイクと機能的なスパイクという2種類の形式がある。機能的なスパイクを用いて、集約した機能振る舞いを分析し、ブレークダウンの仕方や組み合わせ方及びリスクと複雑性はどこにあるかを決定する。結果的に実装に関する決定に影響を与える。技術的なスパイクは設計戦略の影響と実現性を決めるために用いられる。

他のストーリーと同様、スパイクは見積もりされて、チームメンバーが担当し、反復の終盤にデモされる。スパイクは合意されたプロトコルとワークフローも提供する。アジャイルリリース列車は、これからのポートフォリオ、価値のストリームとプログラムエピックの実行可能性の確立を助けるために、これらを利用する。

詳細

アジャイルとリーンは推測より事実を重視する。質問、リスクや不確実性に直面する時、アジャイルチームは成果を推測したり、ソリューションへ飛び込みしたりせずに、実装に移る前に小さな実験を行う。スパークはもともとXPで定義されたが、SAFeではる特別な種類のイネイブラーである。チームは以下いくつかの理由でスパイクを利用する。

  • 潜在な振る舞いを分析するため、今後のフィーチャーやシステム能力を見積もる。それによってより小さな、見積もり可能な規模に分割する
  • エピックの変動可能性を決めるために、実現可能性分析や他役に立つ活動を行う
  • スパイクは、新しい技術や分野にチームが慣れるための基本的な調査に使われる場合がある
  • リスクを低減するため、技術や機能面のアプローチに確信を持つ

スパイクには、一般に、今後のフィーチャーの一部を示す小さなプログラム、調査活動、及びテストの作成が含まれます。

技術スパイクと機能スパイク

フィーチャーやストーリーが見積もりするには複雑すぎる場合、また、単純にスプリントに入る前にさらなる調査と理解が求められる場合、チームがスパイクを利用し、ソリューションを理解する。
一般的に、機能スパイクと技術スパイクという2種類のスパイクがある。

  • 機能スパイクは、ユーザーがシステムとやり取りする方法が著しく不確実である場合に用いられる。機能スパイクはユーザーインターフェースのモックアップであれ、ワイヤーフレームであれ、ページ遷移であれ、その他顧客や利害関係者からフィードバックを受けるのに最も適したどのようなテクニックであれ、なんらかのレベルのプロトタイピングを通じて評価することが最善であることが多い。
  • 技術スパイクは、ソリューション領域の様々な技術的なアプローチを調査するために用いられる。例えば、構築するか購入するかを判断したり、新たなユーザーストーリーの潜在的な性能や負荷影響を評価したり、ソリューションに適用できる特定の実装技術を評価したり、もしくは、望ましいアプローチをチームがもっと自信を持って理解しなければならないというような理由で技術的なスパイクが使われるかもしれない。

フィーチャーやユーザーストーリーによっては両方の種類のスパイクが必要なことがある。以下は1つの例である。

消費者として、私は毎日のエネルギー利用を棒グラフで見たい。それにより、私は自分の過去、現在、今後のエネルギー消費をすばやく理解できる。

この場合、チームは以下の2つのスパイクを作るかもしれない。

  • 技術スパイク: 顧客のディスプレイを現在の利用に更新するのに要する時間を調査し、通信に対する要求、帯域、データをプッシュするか、プルするかを決める。
  • 機能スパイク: Webポータルで棒グラフのプロトタイプを作り、表示サイズ、様式、グラフの属性についてユーザーのフィードバックを得る。

スパイクのガイドライン

スパイクは直接的にはユーザー価値を納品しないので、これらは控え目に注意して利用しなければならない。以下は利用ガイドラインである:

見積もり可能、デモ可能、受け入れ可能

他のストーリーと同じように、スパイクはチームバックログに組み込まれ、見積もられ、1回の反復に収まるように大きさを調整される。スパイクは一般的に動くコードではなく、情報を生み出すので、スパイクの結果はストーリーとは異なる。いずれの場合でも、スパイクではスパイクの下に隠れているストーリーを識別し、大きさが把握できるように不確実性を解決するためにちょうど十分な情報を作りだすべきである。

スパイクの出力は、チームと利害関係者の両方にデモ可能である。これにより、調査やアーキテクチャーに関する労力が可視化されるとともに、大事な判断に対する共同所有や責任の共有を築くことを助ける。そして、他のすべてのストーリーと同様に、スパイクに対する受け入れ基準が満たされた時点で、スパイクはプロダクトオーナー により受け入れられる。

スパイクの実施タイミング

スパイクは1つ以上の潜在的なストーリーにおける不確実性を表す。そのため、スパイクとその結果として得られるストーリーと同じ反復に計画することにはリスクがある。しかしながら、もしスパイクが小さくて簡単なものであり、すぐに解決策が見つかりそうであれば、同じ反復でスパイクをし、ストーリーを完成するのは非常に効率がよいだろう。

例外、ルールではない

すべてのユーザーストーリーに不確実性とリスクがあることが、アジャイル開発の性質である。チームは、議論、共同作業、実験、交渉を通じて適切なソリューションを発見する。そのため、ある意味では、すべてのユーザーストーリーに技術と機能のリスクを無くすためのスパイクレベルの作業が含まれている。アジャイルチームのゴールは、各反復でこの不確実性を受け入れ、効果的に対処する方法を学ぶことなのである。他方、スパイクストーリーはより深刻でより大きな未知の事柄のために取っておくべきである。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.(邦訳:邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014.)

Last update 4 October, 2015