自分が何を行っているかを分かっていれば、それは研究ではないだよ。

- アルベルト・アインシュタイン

スパイクの概要

スパイクはストーリーの一種であり、研究、設計、調査あるいはプロトタイプ作成などのような作業のために利用される。スパイクの目的は技術的なアプローチに関するリスクの低減、要求仕様に対するより良い理解、ストーリーの見積もりに関する信頼性の向上に関する必要な知識を得るためである。スパイクはもともとXPによって定義され、技術的スパイクと機能的なスパイクという2種類の形式がある。機能的なスパイクを用いて、集約した機能振る舞いを分析し、ブレークダウンの仕方や組み合わせ方及びリスクと複雑性はどこにあるかを決定する。結果的に実装に関する決定に影響を与える。技術的なスパイクは設計戦略の影響と実現性を決めるために用いられる。他のストーリーと同様、スパイクは見積もりされて、チームメンバーが担当し、反復の終盤にデモされる。スパイクは合意されたプロトコルとワークフローも提供する。アジャイルリリース列車は、これからのポートフォリオとプログラムエピックの実行可能性の確立を助けるために、これらを利用する。

詳細

XPのもう1つ発明であるスパイクは、ユーザーストーリーや他のプロジェクトの側面のリスクや不確実性を取り除くために使われる特別な種類のストーリーである。スパイクは以下いくつかの理由で用いられる。

  • 今後のフィーチャーを見積もるために、スパイクは用いられる可能性がある
  • 実現可能性分析や、ビジネスアーキテクチャーポートフォリオカンバンシステムにエピックの実行可能性を決めるために役に立つほかの活動に、スパイクが利用できる。
  • スパイクは、新しい技術や分野にチームが慣れるための基本的な調査に使われる場合がある
  • 一部のフィーチャーやストーリーが大きなリスクを含んでいる。アプローチに確信が持てるようにスパイクを利用できる
  • フィーチャーやストーリーが確信的に見積もりするには大きすぎる場合、見積もり可能な複数の部分に分割できるように暗示される振る舞いを分析するためにスパイクを利用できる

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

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

技術スパイクは、ソリューション領域の様々な技術的なアプローチを調査するために用いられる。例えば、構築するか購入するかを判断したり、新たなユーザーストーリーの潜在的な性能や負荷影響を評価したり、ソリューションに適用できる特定の実装技術を評価したり、もしくは、望ましいアプローチをチームがもっと自信を持って理解しなければならないというような理由で技術的なスパイクが使われるかもしれない。

機能スパイクは、ユーザーがシステムとやり取りする方法が著しく不確実である場合に用いられる。機能スパイクはユーザーインターフェースのモックアップであれ、ワイヤーフレームであれ、ページ遷移であれ、その他顧客や利害関係者からフィードバックを受けるのに最も適したどのようなテクニックであれ、なんらかのレベルのプロトタイピングを通じて評価することが最善であることが多い。

フィーチャーやユーザーストーリーによっては両方の種類のスパイクが必要なことがある。以下は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 15 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.