スクラムの歴史
1970 年にウィンストン ロイスの「大規模ソフトウェア システム開発の管理」レポートが出版されて以来、多くの人がウォーターフォール開発モデルの欠点を解消できる方法論を見つけようと試みてきました。「ウォーターフォール」に代わる方法は、これから説明するスクラム手法でした。
スクラムという名前は、1986 年に竹内と野明の著作『新製品開発の新しいルール』に由来しています。この文書では、目標を達成するための最も効果的な方法は、開発者に明確な行動計画を与えることであると主張しています。
1995 年には、Sutherland と Schweiber による別のガイド「Software Development with Scrum」が出版されました。この出版物はその後数回更新されています。現在、これはこのメソッドの開発の主要なガイドとみなされています。スクラム ガイドの現在のバージョンには、2020 年に更新された情報が含まれています。
スクラム ガイドの主な規定では、プロジェクト管理テンプレートは、開発者が合意された時間枠 (スプリント) 内に最終製品を提供するという事実に基づく必要があると示唆しています。スクラムの実装を成功させるには、ロール、イベント、ルール、成果物などのいくつかの要素で構成される構造を使用することをお勧めします。
スクラムにおける役割
スクラムには 3 つの役割があり、すべてがスクラム チームを形成します。
ソフトウェア製品の顧客は、ビジネスにとってのその価値を完全に理解しているのはソフトウェア製品の顧客だけであるため、プロジェクトにおいて最も重要な人物です。顧客は将来の製品のユーザーのニーズを開発者に説明しますが、開発プロセスの技術的な部分については責任を負いません。また、製品に特定の要素や機能を作成する際の優先順位も顧客が決定します。
開発者は技術的なタスクの実装を任されており、その機能横断性はアプリケーションの範囲によって異なります。開発者は、スプリント バックログの作成、コードの作成、スプリントの目標に合わせたプロジェクトの調整、その他のタスクで忙しいです。
スクラム マスターはスクラム チームのファシリテーターです。顧客と開発者に支援を提供します。簡単に言えば、スクラム マスターは、プロジェクトに関与していない人々とコードを書いている人々との間のコミュニケーションに忙しいのです。同じ大企業内の異なるプログラマー チームが、これらのチームのスクラム マスターの総会で連絡し、調整することがあります。
スクラムのイベント
スクラム イベントには 5 種類あります。
スプリントはスクラムの最も重要な部分です。これには、スプリント計画、毎日のスタンドアップ (毎日のスクラム)、スプリントのレビューと振り返りが含まれます。
スプリント計画。スクラム チームのメンバー全員が将来のスプリントの計画の作成に参加します。ここで製品のアイデアが提示され、各チームメンバーが自分の意見、これについてどう思うかを表明できます。その後、会議で優先順位が決定され、期限が発表されます。
デイリー スクラムは、15 分以内の毎日の短いスクラム イベントです。通常、今日または明日のエンコーダーの作業を計画するために行われます。Daily Scrum では、現在の問題について話し合うことができます。プロジェクトに関与するすべての開発者は、このようなワークショップに参加する必要があります。スクラム マスターの存在は許可されていますが、必須ではありません。
スプリント レビュー (デモ) - スプリント中に作成された結果を表示します。通常、このイベントは最終段階で行われます。興味のある人は全員参加します。
スプリントのレトロスペクティブ - スプリントの結果についてのディスカッション。チームメンバーは、自分たちに割り当てられたタスクにどのように対処したか、そして今後の仕事の結果をどのように改善するかについて意見を共有します。
さらに、バックログの絞り込みが実行されることもあります - バックログの絞り込み。バックログ項目、次のスプリントの準備、現在のタスクの優先順位付けについて説明します。
アーティファクト
スクラム成果物は、プロジェクトまたはスプリントの最後に発生する作業です。製品バックログ、スプリント バックログ、増分という 3 つの成果物があります。それらはそれぞれ、ソフトウェアをユーザーにタイムリーに配信するために必要です。補助的なアーティファクト (バーンダウン チャートなど) もあります。
スプリント成果物に含まれるコンポーネント:
製品バックログ - インターフェイスとバックエンド機能。
スプリント バックログは、反復中に実行する必要があるタスクのリストです。これらはスプリントの開始前に合意されます。
増分 - スプリント中に作成されたソフトウェア バックログ アイテムの合計数と、その前に行われた増分値。完了した新しい増分は、スプリントの終了前に表示する必要があります。これは、スクラム チームの要件を満たす実用的なバージョンがあることを意味します。
製品バックログ項目 - スプリント反復中に完了する必要があります。原則として、要素はいくつかの小さなタスクに分割されます。
スプリントの目標は、完了する必要があるタスク (バックログ項目またはその他のタスクの作成) です。
スプリント バーンダウンとは、スプリントが終了する前に残された作業です。バーンダウン チャートは上昇または下降のいずれかです。それはすべて、チームメンバーが作業中に直面する困難によって異なります。これは進歩の指標ではなく、問題を解決する方法とインセンティブにすぎません。
製品リリース/製品バーンダウン チャートは、次のスプリントが終了する前にスクラム マスターによって作成されるチャートです。横軸はスプリント、縦軸は残りの作業量です。
スクラムフレームワークのルール
ロール、イベント、成果物はスクラムの基礎ですが、これ以外にもルールがあります。それらはすべて作業プロセスの効率を向上させます。これらのルールのリストは次のとおりです。
- スクラム チームには、ソフトウェア顧客、スクラム マスター、開発者が含まれます。
- すべてのスプリントは同じ長さである必要があります。
- 1 つのスプリントが完了すると、すぐに新しいスプリントの作業が始まります。
- スプリントは常に計画から始まります。
- チームメンバーは一日の仕事の始まりに朝のスクラムを行います。
- 各スプリントは各スプリント中にレビューされます。これにより、チームと関係者間のコミュニケーションが向上します。
- スプリント中にスプリント バックログを変更することはお勧めできません。
スクラムの制限
スクラムには明らかな利点がある一方で、欠点もあります。
- スクラムでは、共通の期限がないため、実行される作業量が減少することがよくあります。
- プロジェクト参加者の関与が低かったり、協力する気がなかったりすると、結果が失敗する可能性がかなり高くなります。
- スクラム構造は大規模なチームで使用するのは困難ですが、それでも使用することは可能です。これには、LeSS、SAFe、Nexus などのスケーリング フレームワークがあります。
- プロジェクトの途中で 1 人以上のメンバーがチームから離脱しても、プロジェクトにはあまり影響しません。