スクラム (ソフトウェア開発)
スクラムは工程の枠組み・フレームワークである。すなわちスクラムの上に具体的なプロセスを配置し完成形のシステムとなる。ゆえに様々な技法・プロセス・パターンをスクラムとともに採用できる。以下が技法の例である。
テスト駆動開発
受け入れテスト駆動開発(英語版)
リファクタリング
継続的インテグレーション
ユーザーストーリー: 顧客要望の対話的分析、プロダクトゴール・スプリントゴールの表現
開発工程というブラックボックスを管理可能にする手法がある。結果を分析することで、プロジェクトマネージャは何らかの意思決定を行う。例えば、
バックログ項目数によりプロジェクトの規模を見積もる。
実装が完了したバックログ数からプロジェクトの進捗状況を見積もる。
リスクの定量化によってプロジェクトの複雑度を見積もる。
スクラムの制御はメタデータモデルで表される。
ベロシティは前回スプリントで達成したプロダクトバックログの相対見積り合計である。
適応型ソリューションを開発するために厳密で重厚なプロセス・手法を用意することも可能だが、スクラムは異なるアプローチをとる。スクラムは最低限で軽量な工程の枠組み(プロセスフレームワーク)のみを提供する。すなわちスクラムは開発の流れ、ポイントとなるイベントのみを定義する。実際のソリューション開発ではスクラムフレームワークに則った上で全体の具体的手順を構築する。このようにスクラムは軽量級フレームワークである。
プロダクトゴールはプロダクトの将来の状態である。すなわち将来のプロダクト利用が生み出すべき価値である。ゴールは評価可能であり、全員に共有され、一度に1つのみ設定される。
プロダクトゴールはプロダクトの目標である。これによりスクラムチームはプロダクトゴールの実現を目標として計画を立案できる。プロダクトゴールは評価可能である。これによりプロダクトの進捗が検査可能になり、プロダクトが適応できる。プロダクトゴールはチームとステークホルダーに共有される。これによりチームは提供すべき価値を把握して「なぜ(why)これを開発するのか」を理解でき、目的意識を持った自律的な開発が可能になる。プロダクトゴールは一度に1つのみ設定される。これによりチームは単一のゴールへ向け集中できる。
例えばタクシーサービスが掲げる「顧客は平均7分でタクシーを捕まえられる」は定量評価可能なユーザー体験であり、プロダクトゴールに相応しい。
1986年に野中郁次郎と竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載される。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum(スクラム)」として紹介した。
野中、竹内の論文に着想を得たJeff Sutherland、John Scumniotales、Jeff McKenna が、1993年にラウンドトリップ・エンジニアリング(一種の反復型開発)を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築し、実践したのがソフトウェア開発手法としてのスクラムの最初である。当時、素早い開発が求められており、要求仕様を簡単に動作するコードに変換する方法が求められていた。