スクラム

スクラムは、迅速なアプリケーション開発を可能にする、簡素化されたプロジェクト管理フレームワークです。 スクラムは、アジャイルプロジェクト管理とも呼ばれます。 スクラムは、部門横断的なアプローチを活用し、エンドユーザー（多くの場合は最終製品の開発に対して決定的な意見を持っている）などの技術リソースとビジネスリソースをまとめます。

スクラムは、適切な人材を定期的に集めて（スプリントといいます）、小さな作業を実行することで成立しています。 ユーザー情報とフィードバックを入力することで、リスクを軽減しながら作業の成果物をすばやく作成して改良し、短期間で提供できるよう構築されています。 実行する作業は、バックログというリストに記録されます。 各作業成果物は、ユーザーがすべき作業について説明するユーザーストーリーで定義されます。 

スクラムプロジェクトのアプリケーションユーザーストーリーの例は、次のとおりです。

• 銀行の利用客が、モバイルアプリから銀行取引明細書のPDFファイルを印刷したいと考えています。
• オンラインで子供の誕生日ケーキを注文する親が、Zelleで注文品の支払いをしたいと思っています。
• ゲーマーが、自分の金庫にどれくらい金があるかを確認したいと考えています。

プロジェクト管理とアプリケーション開発のフレームワークとして、スクラムは最も付加価値の高いストーリーを最初に開発し、アイデアを最初に正しく識別して提供し、従業員と顧客がプロセスに関与し、同意を促し満足度を高められるようにします。 

スクラムは、一般に受け入れられ、理解されているフレームワークです。 Pega Express^™では、スクラムを使用してクライアントがPegaプロジェクトを最大限に活用できるようにしています。 さらに、Pegaプラットフォーム^™は、スクラム環境での利用効果が高まるよう設計されています。 ウォーターフォールプロジェクト管理などの方法論とは異なり、スクラムは、プロジェクトチームがすばやく構築し、変更に対応し、継続的にデプロイし、フィードバックを簡単に収集できるようにするアプローチです。 クライアントは、プロジェクト管理アプローチとしてスクラムを使用することで、Pegaプラットフォームを最大限に活用します。

スクラムチームには多数の重要な役割があります。 2つは指導的役割です。企業を代表するプロダクトオーナー、チームの進行役を担うスクラムマスターです。

各役割の役目は次のとおりです。

プロダクトオーナー：

• 企業を代表し、ビジネスの意思決定のための唯一の連絡窓口となる
• 製品のバックログを管理
• 利害関係者の期待を設定
• スクラムチームの作業に優先順位を設定
• スクラムチームの質問に答え、詳細を明確に説明
• ユーザーストーリーの完了を承認または却下する

スクラムマスター：

• チームの障害や障壁を取り除く
• 毎日のスタンドアップコールとスプリントセレモニーを実行
• スクラムマスターとしてチームを全力でサポート
• スクラムについて説明し、フレームワークについてチームメンバーをコーチング
• 必要に応じて対話を促進
• ソフトウェア開発のベストプラクティスを推進
• プロダクトオーナーと開発チームとの協力を奨励

スプリントはタイムボックス化された作業サイクルです。最大4週間続き、その期間にチームが成果物を作成します。 スプリントの長さはプロジェクト全体で一定しており、1回のスプリントが終了すると、次のスプリントが開始し、新しいインクリメントが追加されます。 各スプリント内で複数のスクラムイベントが発生します。 各イベントでは、チームが作成した成果物を点検して調整できます。

スクラムイベントに含まれる事項は次のとおりです。

• ストーリーリファインメントと見積もり：ユーザーストーリーの長さと完全性を確認する時間を提供
• スプリント計画：プロダクトオーナーによる現在のスプリントのユーザーストーリーに対する優先順位付けが可能
• デイリースクラム：プロジェクトチームがミーティングを開き、進捗状況ついて話し合えるよう、毎日実施
• スプリントレビュー：現在のスプリントで作成した成果物を確認する機会をプロジェクトチームに提供
• スプリントレトロスペクティブ：現在のスプリントにおける成功点または改善点に基づき、次回のスプリントにおける変更点についてフィードバックを共有する機会をプロジェクトチームに提供

プロダクトバックログは、目標またはビジョンを実現するために必要なすべての機能と要件に優先順位を付けたリストです。 チームのToDoリストとして利用できます。 アイテムのリストとしてのバックログは、プロジェクトのライフサイクル全体で変化する場合があります。 プロダクトオーナーは、バックログ内のアイテムへの優先順位付けを担当します。 バックログ自体は、ユーザーストーリー、Minimum Lovable Product（MLP）リリースに関連する作業単位で構成されています。 Pegaプラットフォーム^™ Agile Studioなどのバックログ管理ツールでバックログを作成できます。

スクラムイベントの一環ではありませんが、バックログの改善はスクラム実施を成功させる鍵となります。 バックログリファインメントは、ユーザーストーリーの詳細を管理および追加するプロセスです。 バックログリファインメントにより、ユーザーストーリーの詳細を記載することで、プロダクトオーナーが内容を理解して優先順位を付けられるようになります。 

ストーリーリファインメントと見積もりのセッションは頻繁に行います。 こうしたセッションには、ビジネスアーキテクト、プロダクトオーナー、テスター、デベロッパーが参加します。
ストーリーリファインメントと見積もりのミーティング中にチームで行うことは次のとおりです。

• 開発チームが見積もりの準備ができているユーザーストーリーを理解したこと、ユーザーストーリーが準備完了の定義（DoR、ストーリー完了の判断基準）に該当することを確認します。
• 開発チームが、ユーザーストーリーが設定された完了の定義（DoD、ストーリー開発完了の判断基準）に該当するよう構成し、実際に該当するかどうかをテストするために必要な作業量（サイズ）を判断できるようにします。
• プロジェクトオーナーが次回のスプリント計画セッションでストーリーを検討できるように、ストーリーポイント（小さい = 1、非常に大きい = 13）を使用してストーリーのサイズを設定します。

ストーリーポイントを使用したストーリーのサイズ設定と見積もりの詳細については、Pega Academyのトピック「Getting Stories Ready」（ストーリーの準備）を参照してください。

スプリント計画は、次のスプリントが開始する直前に行い、定例会議としてスケジュールします。 スプリント計画は、プロダクトオーナーが優先順位を付けたユーザーストーリーをチームに提示して話し合う場となるスクラムセレモニーです。 チームはユーザーストーリーに対する理解を確認し、このユーザーストーリーをスプリントに含められることに同意します。  

ここで行う作業は次のとおりです。

• プロダクトオーナーが各ユーザーストーリーの詳細を説明する
• チームメンバーが質問をしてストーリーの詳細を確実に理解する
• 技術チームのメンバーが、依存関係（依存するユーザーストーリー）を特定するサポートをする
• チームがグループで、どのユーザーストーリーを含めるかを確認する
• チームで、ストーリーを構築する最適な順序について合意する

スプリントのキャパシティに応じて、スプリントに取り込むことのできるストーリーの数が決まります。 スプリントのキャパシティは、開発チームがテストリードおよびテクニカルリードと協力して計算します。 チームは、次のスプリントで目標とするストーリーポイントの数を決定します。 （ストーリーポイントに基づく）ストーリーの数が多すぎることが分かった場合は、次回のスプリント計画セッションで数を減らせます。 チームに処理能力があり、スプリントで達成できるストーリーポイントの数が多い場合には、ストーリーの数を増やせます。

時間の経過とともに、各スプリント中にチームが達成するストーリーポイントの数は安定し、スプリントベロシティと呼ばれる速度を形成するようになります。

進捗のレビューには、非公式なプレイバックと、より正式なスプリントレビューの2種類があります。

プレイバック

プレイバックは、デベロッパーが進捗状況を共有し、チームの達成した内容をプロダクトオーナーに説明する非公式の場であり、スプリントを通じて頻繁に行います。 成果物が完成するまで待つ必要はありません。 定期的に最新情報を共有することで、チームはスプリントの終了時にプロダクトオーナーからフィードバックと承認を得られます。 

スプリントレビュー

スプリントレビューは、スクラムマスターが開催する正式なセッションです。 レビューはスプリントの終了時に予定し、スプリントで完了した開発作業をすべて紹介します。 スプリントレビューには、ユーザーストーリーのウォークスルーと、ストーリーが完了の定義に準拠しているかの確認が含まれます。 次に、プロダクトオーナーと企業の代表者は、デベロッパーがスプリント中に構築した機能のデモを確認します。 

スクラムマスターは、予約された会議室とビデオ会議ツールへのアクセスを使用して、スプリントごとにこうした専用レビューセッションのスケジュールを担当します。 参加者は、プロジェクトチーム、プロダクトオーナー、テストリード、スクラムマスターなどです。 プロジェクトをサポートするビジネス分野のエキスパートを招くのが一般的です。

スプリントレトロスペクティブは、スプリントの終了時にスクラムマスターが設定するミーティングです。 スプリントレトロスペクティブは、チームメンバーに次のことを共有する機会を提供します。

• スプリントにおけるプロセス面での成功点
• 次回のスプリントが始まる前に改善できる点 

スプリントレトロスペクティブの参加者には、プロジェクトチーム、スクラムマスター、プロダクトオーナー、テストチームリードを含める必要があります。 スクラムマスターは、以降のスプリントを改善するためにレトロスペクティブから得られるアクションアイテムに責任を負います。

プログラムには、複数のスクラムチームが存在し、同時にアプリケーションソリューションとプロジェクトを提供する場合があります。 こうしたスクラムチーム間に共通点があり、ソリューションを再利用する機会がある場合は、スクラムオブスクラムを実施することをお勧めします。 スクラムオブスクラムは、テストの合理化や設計の再利用など、成果を最大限に引き出すためにスクラムチーム間の連携とコミュニケーションをサポートするミーティングです。 各スクラムチームは、参加するチームメンバーを指定します。 スクラムオブスクラムにより、主要なアーキテクチャ上の意思決定とスプリント計画の目標との整合性を確保しながら、再利用の機会を特定できます。

次の問題に答えて、理解度をチェックしましょう。