自分たちが何をしているかわかっていたら、それは研究とは呼ばないだろう。 エクストリームプログラミング（XP）で最初に定義されたもので、研究、設計、調査、探査、プロトタイピングなどの活動を表している。 その目的は、技術的アプローチのリスクを低減し、要件をよりよく理解し、ストーリー推定の信頼性を高めるために必要な知識を得ることである
他のストーリーと同様に、スパイクは反復の終わりに推定され、実証される。 また、アジャイルリリース列車（ART）がエピックの実行可能性を判断するために使用する、合意されたプロトコルおよびワークフローも提供する。 質問、リスク、または不確実性に直面したとき、アジャイルチームは、結果について推測したり、解決策に飛びつくのではなく、実装に移る前に小さな実験を行う。 チームは様々な状況でスパイクを使うことができる。
- 新しい機能および能力を推定し、暗黙の動作を分析し、それらをより小さく定量化可能な断片に分割するためのアプローチに関する洞察を与える
- 実現可能性分析および叙事詩の実行可能性を決定するのに役立つ他の活動を行う
- 新しい技術またはドメインに慣れるために基礎研究を行う
- 技術または機能アプローチに自信を得る。 リスクと不確実性の低減
スパイクには、新しい機能のいくつかの側面を実証する小規模なプログラム、研究活動、またはテストを作成することが含まれます。
技術的および機能的スパイク
スパイクには、主に技術的および機能的という 2 つの形式があります。
機能的スパイク -ソリューション全体の動作を分析し、以下を判断するために使用されます:
- How to break it down
- How to organize the work
- Where risk and complexity exist
- How to use insights to influence implementation decisions
Technical spikes -ソリューション領域における各種アプローチを調査するために使用されます。 たとえば、
- 構築対購入の決定を下す
- 新しいユーザー ストーリーの潜在的なパフォーマンスまたは負荷の影響を評価する
- 特定の技術実装アプローチを評価する
- 望ましいソリューション パスに関する確信を深める
一部の機能およびユーザー ストーリーには、両方のタイプのスパイクが必要となる場合があります。 以下はその例です。
「消費者として、過去、現在、および予測されるエネルギー消費をすばやく理解できるように、毎日のエネルギー使用をヒストグラムで確認したい。”
この場合、チームは両方のタイプのスパイクを作成する可能性があります。
- 技術的スパイク – 顧客ディスプレイを現在の使用状況に更新するのにかかる時間を調査し、通信要件、帯域幅、およびデータをプッシュするかプルするかを決定する
- 機能的スパイク – Web ポータルでヒストグラムを試作し、プレゼンテーション サイズ、スタイル、チャートに関するユーザーのフィードバックを得る
スパイクに関するガイドライン
スパイクが直接ユーザー値を提供しないので、控え目に使用します。
Quantifiable, Demonstrable, and Acceptable
他のストーリーと同様に、スパイクはチーム バックログに入れられ、見積もられ、反復に適合するサイズにされる。 スパイクの結果はストーリーとは異なり、スパイクは通常、作業コードではなく情報を生成する。 8957>
スパイクの出力は、チームと他のあらゆる利害関係者の両方に対して実証可能であり、研究とアーキテクチャの取り組みに可視性をもたらし、また、意思決定に対する集団的所有権と共有責任の構築を支援します。 プロダクトオーナーは、デモを行い、その受け入れ基準を満たしたスパイクを受け入れる。
Timing of Spikes
スパイクは1つまたは複数の潜在的なストーリーにおける不確実性を表すので、同じ反復におけるスパイクと結果のストーリーの両方の計画は、時にリスクが高い。 しかし、それが小さくて簡単で、迅速な解決策が見つかりそうな場合は、同じ反復で両方を行うことが非常に効率的である場合がある。 チームは、議論、コラボレーション、実験、および交渉を通じて、正しい解決策を発見します。 したがって、ある意味では、すべてのユーザー ストーリーには、技術的および機能的なリスクを特定するためのスパイクのような活動が含まれています。 アジャイルチームの目標は、各反復において不確実性に対処する方法を学ぶことである。
詳細はこちら
Leffingwell, Dean. アジャイルソフトウェア要件。 このような場合には、「アジャイルソフトウェア要件」と呼ばれる。 Addison Wesley, 2011.
Last update: 10 February 2021
このページの情報は、© 2010-2021 Scaled Agile, Inc.のもので、米国と国際著作権法により保護されています。 著作権者の書面による明確な許可なく、このサイトから画像やテキストをコピーすることはできません。 Scaled Agile FrameworkおよびSAFeは、Scaled Agile, Inc.の登録商標です。 Permissions FAQsをご覧いただき、許可を得てください。Author
- Richard Knaster –
