スクラム概要

スクラム概要

スクラムでは、プロジェクトマネージャーはスクラムマスターと呼ばれ、プロジェクトチームはスクラムチームと呼ばれます。製品バックログ上で開発される機能や要件の優先順位をつける製品オーナーが存在します。

スクラム手法はスプリントを用いて作業の小さなインクリメントを提供し、顧客からのフィードバックを収集します。

スクラムの柱は3つあります：

スクラム顧客のニーズが常に変化する状況に適応するために、実証主義的アプローチ（しばしば実証主義と呼ばれる）を採用しています。実証主義とは、実際の経験に基づいて意思決定を行う実践です。実証主義的アプローチとは、事実に基づき、経験に基づき、証拠に基づいて行動することを意味します。特に、進捗が広範な初期要件に基づく複雑な事前計画ではなく、現実の観察に基づく場合に特に重要です。

要するに、過去の失敗や経験から学び、改善します。すべての実装において実証的プロセス制御を支えるスクラムの3つの柱は：透明性、検査、適応であり、以下の図に示す通りです：

The Three Pillars of Scrum

  • 透明性 — 一貫性と共有された理解を確保するための共通の言語と基準。
  • 検査 — スクラムの進捗と成果物を頻繁にレビューしてフィードバックを得る。プロジェクトの進捗を隠さないことが重要です。
  • 適応 — 受けたフィードバックを簡単に取り入れ、問題が発生したときに迅速に対応する。

スクラムプロセスの構成要素

そのスクラムフレームワーク自体は非常にシンプルです。いくつかの一般的なガイドラインと少数のルール、役割, 成果物、およびイベントを定義しています。しかし、これらの各構成要素は重要であり、それぞれ特定の目的を果たし、フレームワークを成功裏に使用する上で不可欠です。

スクラムフレームワークの主な構成要素は：

以下の図は、スクラムフレームワークの主要な要素を示しています。このプロセスは、アジャイルソフトウェアツール — スクラムプロセスキャンバス.

Scrum Framework
スクラムフレームワーク

スクラム役割

組織がスクラムを採用することを決定した際、まず理解すべきことは、スクラムの役割が従来のプロジェクト実行の役割とどのように異なるかです。スクラムには3つの主要な役割しかありませんが、それらは私たちがよく知っている役職名と自動的に一致するわけではありません。それぞれの役割について簡単に定義から始めましょう：

プロダクトオーナー

プロダクトオーナーは、ビジネスまたはユーザーコミュニティを代表し、ユーザーグループと協力して製品リリースに含めるべき機能を決定するスクラムの役割です。プロダクトオーナーの主な責任は以下の通りです：

  • 製品またはサービスの方向性と戦略を設定し、短期および長期の目標を含む；
  • 製品またはサービスに関する知識を提供または収集する；
  • 開発チームが顧客のニーズを理解し、解釈できるように支援する；
  • 製品またはサービスの要件の収集、優先順位付け、および管理;
  • 製品またはサービスの予算に関するすべての責任（収益性を含む）を引き受ける;
  • 製品またはサービスの機能のリリース日を決定する;
  • 開発チームと毎日質問に答え、意思決定を行う;
  • スプリントに関連する完了した機能を受け入れたり拒否したりする;
  • 各スプリントの終了時に開発チームの主要な成果物を示す;
  • 製品バックログの責任を負う。

スクラムマスター

スクラムマスターはアジャイル開発チームのファシリテーターである。スクラムは、アジャイルの原則に従ってチームが自己組織化し、迅速な変更を実現できる方法である。スクラムマスターは情報交換のプロセスを管理する。スクラムマスターの主な責任は次のとおりである：

  • チームがスクラムの価値観と実践を守れるようにコーチとして振る舞う;
  • 障害の除去を支援し、チームを外部からの干渉から守る;
  • チームとステークホルダーの間の良好な連携を促進する;
  • チーム内での常識の促進;
  • チームを組織的な干渉から守る。

スクラムチーム

スクラムチーム（開発チームとも呼ばれる）は、製品またはサービスを提供するために必要なすべての技術的スキルを総合的に備えた3〜9人のメンバーで構成される。スクラムマスターから直接コーチングを受けるが、直接管理はされない。自己組織化され、多様な能力を持ち、すべての必要作業を完了できるだけの責任感を持つ必要がある。

開発チームは、分析、設計、開発、テスト、技術文書作成を含む各スプリントで、出荷可能な製品のインクリメントを提供する責任を負う。スクラムチームの主な特徴は次のとおりである：

  • チームは自己組織化されなければならない。すべてのチームメンバーは、割り当てられたタスクを完了するために自らの努力を管理しなければならない。アジャイルスクラムでは、チームリーダーやラインマネージャーのような人物は存在しない。全員が活動を遂行し、チームの成功に貢献できるだけのコミットメントを持つ必要がある。一人が失敗すれば、全員が失敗する。
  • チームはクロスファンクショナルでなければならない。すべてのチームメンバーは、完成し、即座に使用可能なサービスまたは製品を提供できるだけの知識とスキルを備えなければならない。必要に応じて専門家を活用できるが、チームへの知識移転や特定のギャップの埋め合わせのためのコーチとしてのみ利用できる。
  • プロダクトオーナーにはビジネスビジョンが必要。プロダクトオーナーは顧客の声を代表し、そのニーズをスクラムマスターおよび開発チームに伝える必要がある。これは通常、フルタイムの役割である。
  • スクラムマスターはラインマネージャーではない。彼らは開発チームに必要なコーチングを提供し、チームが直面するあらゆる障害の除去を支援する。

プロダクトバックログ

これは、プロジェクトで実施するすべての作業の順序付きリストである。通常、ユーザー・ストーリーと呼ばれる物語の形式で提示される。

ユーザー・ストーリー — ユーザーがプロジェクトの成果物（製品、サービス、または成果）とどのようにやり取りするかの異なる表現。ユーザー・ストーリーを通じて、成果物に必要な機能や仕様をチームは特定する。

したがって、プロダクトバックログには、製品／サービス／成果物に必要な優先順位付けされたユーザー・ストーリー（機能や仕様）が含まれる。バックログの優先順位付けはプロダクトオーナーの責任である。

注意：プロジェクト全体のすべてのストーリーを作成する必要はありません。作業を開始する前にすべてのストーリーを作成する必要はありません（これはアジャイルアプローチの利点の一つです）。既にわかっているストーリーから始め、学びが進むにつれてバックログに追加し、必要に応じて優先順位を再設定してください。

スプリント計画

ウォーターフォールアプローチとは異なり、アジャイルチームはすべてを事前に計画しません。ここでは、チームは少しだけ計画します。現在のスプリント（通常2〜4週間）に必要なものを、実行し、その経験から学び、次回のスプリントを再び計画します。

スクラムチームはプロダクトバックログをレビューし、スプリント時間枠内に完了できるユーザーストーリーの数を選びます。選ばれたユーザーストーリーがスプリントバックログになります。スプリントバックログはスプリントの目標を表しています。

完了の定義も確立されます。完了の定義は、バックログ項目に対する受入基準と考えることができます。

チームの能力に合わせた作業のみを計画してください。つまり、チームが各スプリントで実際に完了できる作業のみを計画してください。

デイリースクラムミーティング（デイリースタンドアップ）

チームはこの会議を、互いに小さな約束を交わし、問題を特定し、スプリントの作業がチーム内でスムーズに進行することを確認するために使用します。通常15分間です。チームは以下の質問に答えます：

  • 前回のスクラムミーティング以降に何を完了しましたか？
  • 今日の計画は何ですか？次回のスクラムミーティングまでに何を完了しようとしていますか？
  • 私が進捗を妨げる障害（問題、課題、リスク）はありますか？

思い出してください。この会議はステータス会議ではありません。問題の解決を目的とするものではなく、問題があるかどうかを認識することを目的としています（もしあれば）。問題を解決するための会議が必要な場合は、別途開催してください。

スプリントレビュー会議

各スプリントの終了時に、チームはすべての完了した作業項目をデモンストレーションします。このレビュー会議は、プロジェクトのステークホルダーからのフィードバックや変更要請を受け取るために使用されます。

計画段階で確立された完了の定義に従って100%完了していない作業項目は、デモンストレーションされないことに注意が必要です。なぜなら、それらは「完了」していないからです。

スプリントリトロスペクティブ会議

これはスプリントレビューの後に実施されます。目的は、チームがスプリントから学ぶことを支援することです。プロセスは、スプリント中にうまくいかなかった場合にチームを責めるのではなく、継続的な改善に焦点を当てます。

チームは、より効果的になる方法を振り返り、改善すべき他の領域を特定します。

スクラムマスターは各改善項目の重要性を評価し、その後チームは次回に実装する適切な数の改善項目を選定します。スプリント.

コメントを残す