5分間のスクラム学習

スクラムは、チームが反復的なソフトウェア開発プロセスを進めるのを可能にする、集中しながらも柔軟なプロジェクト管理アプローチです。スクラムは経験則に基づいており、チームが何かがどのように機能すべきかについて仮説を立て、それを検証し、経験を振り返り、適切な調整を行うための方法を提供します——フレームワークが正しく使用されている場合に限ります。

スクラムの構造により、チームは自身の環境にとって意味のある他のフレームワークの実践を組み合わせることができます。アジャイルの世界では、スクラムはソフトウェア開発の主要な手法となっています。スクラムの概念は信頼性が高く、世界中の数千の開発チームによって検証されています。スクラムは、複数の2〜4週間のイテレーションに分割される大量の作業を扱う製品開発環境で、クロスファンクショナルなチームが最も適しているとされています。

スクラムの起源

1986年：竹内と野中は『新しい新製品開発のゲーム』をハーバード・ビジネス・レビューに発表しました。この記事は、『慎重に選ばれた多様な専門分野を持つチームが、始まりから終わりまで一緒に働き、継続的な相互作用を通じて製品開発プロセスが生まれる』というラグビー風のアプローチを記述しています。この記事は、スクラムフレームワークのインスピレーションとして頻繁に引用されています。’

スクラムの価値（スクラムの価値)

以下の原則がスクラムの経験則的な性質を支えています：

透明性
チームは、全員が他のメンバーが直面する課題について把握できる環境で作業しなければなりません。チームは内部で問題を明らかにします——しばしば長年続く問題で、チームの成功を妨げるものです。

検査
フレームワークには、チームがプロセスの運用状況を振り返るための頻繁なチェックポイントが含まれます。これらのチェックポイントには、デイリースクラムとスプリントレビュー会議が含まれます。

適応
チームは進捗を継続的に評価し、効果が疑われる項目を調整します。

開発チーム（開発チーム)

プロダクトオーナー

「プロダクトオーナー」は、チームが提供しようとしている成果を達成するために、プロダクトバックログを管理する役割です。

プロダクトオーナーの役割は、何を構築すべきかを決める際に、複数の対立する方向性や方向性の欠如という課題に対処するためにスクラムに存在します。

スクラムマスター

「スクラムマスターチームメンバーがアジャイル価値観と原則を実践し、チームが使用することに合意したプロセスや実践を遵守することを確保する責任があります。

この称号は、他の人を導くことができるスクラムの専門家を指すために元々使用されていた。

この役割には通常、正式な権限がありません。この役割を担う人物は、影響力のある立場からリードしなければならず、通常はサービスリーダーシップの姿勢を取る必要があります。

開発チーム
その開発チームは、スプリント内に製品のインクリメントを提供する人々で構成されています。

開発チームの主な責任は、各スプリントで価値を生むインクリメントを提供することです。作業の割り当て方は、チームが現在の状況に基づいて決定します。

スクラムの成果物

製品バックログ
その製品バックログは、製品に可能なすべての変更の順序付けられたリストです。製品バックログ上の項目は、約束事ではなく選択肢であり、リストに掲載されているからといって納品が保証されるわけではありません。

製品所有者は継続的に管理する製品バックログを、その内容、明確さ、順序を含めて管理する。

スプリントバックログ
そのスプリントバックログは、スプリント中に納品するために選択された製品バックログ項目と、それらの項目を納品し、スプリント目標を達成するためにチームが必要と判断するタスクのセットです。

インクリメント
インクリメントは、スプリントの終了時に完了した製品バックログ項目の集合であり、スプリントチームの「完了の定義」を満たすものです。製品所有者は、将来のスプリントでインクリメントをリリースするか、それを基にさらに進めるかどうかを決定できます。

完了の定義
その完了の定義は、製品バックログ項目が完了と見なされる前に満たすべき基準について、チーム内で合意されたものである。

スクラムのイベント

スプリント
A 時間制限付き1か月以内の期間で、チームが潜在的に出荷可能な製品のインクリメントを提供するイベント。スプリントの典型的な特徴：

開発期間中を通して一貫した期間
前のスプリントが終了した直後に新しいスプリントが始まる
スプリントの開始日と終了日は固定されている

スプリント計画（スプリント計画)
チームはスプリントを開始する際に、製品バックログからどの項目を対象にするかを話し合います。スプリント計画の最終成果物はスプリントバックログ.

スプリント計画は通常、2つの部分に分けられます。最初の部分では、プロダクトオーナーと他のチームメンバーが、どの製品バックログ項目をスプリントに含めるかを合意します。

スプリント計画の2番目の部分では、チームは、特定された製品バックログ項目を潜在的に出荷可能な製品インクリメントの一部として成功裏に提供する方法を決定します。もしこれが彼らの慣習である場合、その達成に必要な具体的なタスクを特定するかもしれません。選択された製品バックログ項目（該当する場合）と特定されたタスクがスプリントバックログを構成します。

チームとプロダクトオーナーが製品バックログ項目の記述に基づいてスプリントの範囲に合意した後は、スプリントバックログに追加の項目を追加できなくなります。これにより、スプリント中に範囲が変更されるのを防ぎます。

デイリースタンドアップ（デイリースクラム）
デイリースクラムは短い（通常15分以内）会議で、チームが翌日の活動を調整するためのものです。デイリースクラムは状況報告や問題解決の場を目的としているわけではありません。

スプリントレビュー
スプリントの終了時に、全チーム（プロダクトオーナーを含む）が製品ステークホルダーとスプリントの成果をレビューします。この議論の目的は、レビュー、デモンストレーション、およびステークホルダーがインクリメントを使用してフィードバックを提供できるようにすることです。スプリントレビューは状況報告を提供するものではありません。スプリントレビューからのフィードバックは、将来の検討のために製品バックログに反映されます。

スプリントリトロスペクティブ
スプリントレビューの後、スプリントの終了時に、チーム（プロダクトオーナーを含む）は前のスプリントを振り返り、将来に向けた改善点を特定します。このリトロスペクティブは、次のスプリントのスプリントバックログに少なくとも1つのアクションアイテムを含む結果になります。

5つのコア価値

オープンさ
尊重
勇気
集中
献身

What is 3355 in Scrum Framework?

ライフサイクル

スクラムは、開発チームが変化する状況に柔軟に対応できるフレームワークです。このフレームワークは、チームが期待される成果から逸脱しないようにし、作業が進行中のうちに問題を特定・対処し、プロセスを調整できる十分な制御ポイントを提供します。

スクラムのライフサイクルは優先順位付けられたバックログから始まりますが、バックログの作成や優先順位付けについてのガイドラインは提供しません。

スクラムのライフサイクルは、最終的に出荷可能な製品のインクリメントに至る一連のスプリントから構成されています。これらのスプリントでは、製品開発に必要なすべての活動が全体の製品の一部に集中して行われます。以下に、スクラムライフサイクルの主要なステップを説明します：

製品バックログを作成する。
プロダクトオーナーと開発チームはスプリント計画を実施します。スプリント計画の第一段階でスプリントの範囲が定義され、第二段階でその範囲を実現するための計画が策定されます。
スプリントが進行するにつれて、開発チームは選択された製品バックログ項目を提供するために必要な作業を実施します。
毎日、開発チームは以下の通りに作業を調整します：デイリースクラム.
スプリント終了時に、開発チームはスプリント計画で選定した製品バックログ項目を提供します。チームは以下の通りに会議を開催します：スプリントレビューインクリメントを顧客に提示し、フィードバックを収集します。また、チームとプロダクトオーナーはスプリントの進捗を振り返り、リトロスペクティブでプロセスを適宜調整します。
チームはチームステップ2～5を繰り返し、望ましい製品の成果が得られるまで続けます。

主な利点

スクラムスクラムは、製品開発に参加する小さな協働チームの作業を、シンプルでありながら効果的な方法で管理できるようにすることで、ソフトウェア開発分野に大きな貢献をしています。適切なレベルの計画、作業管理、リスクの特定と軽減、問題の特定と解決を可能にするフレームワークとシンプルなルールを提供します。